7342 Isam Fttu Olt Etsi r4.9.00 Product Information 3fe 55457 Aaaa Tczza

ETSI PRODUCT INFORMATION MANUAL
Alcatel-Lucent 7342
INTELLIGENT SERVICES ACCESS MANAGER FIBER TO THE USER |
P-OLT R4.9.00
ETSI PRODUCT INFORMATION MANUAL
3FE 55457 AAAA TCZZA Edition 01
Alcatel-Lucent Proprietary
This document contains proprietary information of Alcatel-Lucent and is not to be disclosed
or used except in accordance with applicable agreements.
Copyright 2013 © Alcatel-Lucent. All rights reserved.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented, which is
subject to change without notice.
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All
other trademarks are the property of their respective owners.
Copyright 2013 Alcatel-Lucent.

All rights reserved.
Disclaimers
Alcatel-Lucent products are intended for commercial uses. Without the appropriate network design
engineering, they must not be sold, licensed or otherwise distributed for use in any hazardous
environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft
navigation or communication systems, air traffic control, direct life-support machines, or weapons
systems, in which the failure of products could lead directly to death, personal injury, or severe physical
or environmental damage. The customer hereby agrees that the use, sale, license or other distribution
of the products for any such application without the prior written consent of Alcatel-Lucent, shall be at
the customer's sole risk. The customer hereby agrees to defend and hold Alcatel-Lucent harmless from
any claims for loss, cost, damage, expense or liability that may arise out of or in connection with the
use, sale, license or other distribution of the products in such applications.
This document may contain information regarding the use and installation of non-Alcatel-Lucent
products. Please note that this information is provided as a courtesy to assist you. While Alcatel-Lucent
tries to ensure that this information accurately reflects information provided by the supplier, please refer
to the materials provided with any non-Alcatel-Lucent product and contact the supplier for
confirmation. Alcatel-Lucent assumes no responsibility or liability for incorrect or incomplete
information provided about non-Alcatel-Lucent products.
However, this does not constitute a representation or warranty. The warranties provided for
Alcatel-Lucent products, if any, are set forth in contractual documentation entered into by
Alcatel-Lucent and its customers.
This document was originally written in English. If there is any conflict or inconsistency between the
English version and any other version of a document, the English version shall prevail.
When printed by Alcatel-Lucent, this document is printed on recycled paper.

Preface
This preface provides general information about the documentation set for the
7342 ISAM Fiber to the User (7342 ISAM FTTU).
Scope
This documentation set provides information about safety, features and
functionality, ordering, hardware installation and maintenance, CLI and TL1
commands, and software installation procedures.
Audience
This documentation set is intended for planners, administrators, operators, and
maintenance personnel involved in installing, upgrading, or maintaining the
7342 ISAM FTTU.
Prerequired knowledge
The reader must be familiar with general telecommunications principles.
Assistance and ordering phone numbers

Alcatel-Lucent provides global technical support through regional call centers.
Phone numbers for the regional call centers are available at the following URL:
http://support.alcatel-lucent.com.
For ordering information, contact your Alcatel-Lucent sales representative.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 iii

ETSI Product Information Manual
Preface
Alcatel-Lucent quality processes

Alcatel-Lucent’s 7342 ISAM FTTU optical network terminals (ONTs)
manufacturing, testing, and inspecting practices are in compliance with
GR-1252-CORE and TL 9000 requirements. These requirements are documented in
the Operations Quality Plan 8BD-00023-4204-QRZZA, the Alcatel North American
Quality Manual 8BD-00001-0000-QRZZA, and the Wireline Network Quality
Manual 8AB-83179-0001-QRAAA.
The quality plans and practices adequately ensure that technical requirements and
customer end-point requirements are met. The customer or its representatives may
be allowed to perform on-site quality surveillance audits, as agreed upon during
contract negotiations.
Safety information
This documentation set provides safety guidelines for specific ETSI or ANSI
markets.
Documents
Documentation available for the 7342 ISAM FTTU is listed in the 7342 ISAM FTTU
P-OLT Planning and Ordering Guide.
Procedure 1 To download an CD-ROM ISO image or ZIP file package

of the 7342 ISAM FTTU customer documentation
1 Navigate to http://www.alcatel-lucent.com/myaccess and enter your user name
and password. If you are a new user and require access to this service, please
contact your Alcatel-Lucent sales representative.
2 From the Technical Content for drop-down menu, choose 7342 ISAM FTTU.
3 Click on Downloads: Electronic Delivery.
4 Choose Documentation from the drop-down menu and click Next.
5 Select the image from the drop-down menu and click Next.
6 Follow the onscreen directions to download the file.
iv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Edition 01 3FE 55457 AAAA TCZZA
Preface
Procedure 2 To access individual documents
Individual PDFs of customer documents for the 7342 ISAM FTTU and other
Alcatel-Lucent products are also accessible through the Alcatel-Lucent Customer
Support website.
1 Navigate to http://www.alcatel-lucent.com/myaccess and enter your user name

and password. If you are a new user and require access to this service, please
contact your Alcatel-Lucent sales representative.
2 From the Technical Content for drop-down menu, choose 7342 ISAM FTTU.
3 Click on Manuals and Guides to display a list of customer documents by title and
part number. You can filter this list using the Release drop-down menu.
4 Click on the PDF to open or save the file.
Special information
The following are examples of how special information is presented in this
documentation set.
Danger — Danger indicates that the described activity or situation
may result in serious personal injury or death; for example, high
voltage or electric shock hazards.
Warning — Warning indicates that the described activity or situation

may, or will, cause equipment damage or serious performance
problems.
Caution — Caution indicates that the described activity or situation

may, or will, cause service interruption.
Note — A note provides information that is, or may be, of special

interest.
Procedures with options or substeps

In a procedure, options are identified by letters, substeps are identified by roman
numerals.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 v

Preface
Procedure 3 Example of options in a procedure
At step 1, you can choose option a or b. At step 2, you must do what the step indicates.
1 This step offers two options. You must choose one of the following:
a This is one option.
b This is another option.
2 You must perform this step.
Procedure 4 Example of required substeps in a procedure
At step 1, you must perform a series of substeps within a step. At step 2, you must do
what the step indicates.
1 This step has a series of substeps that you must perform to complete the step. You
must perform the following substeps:
i This is the first substep.
ii This is the second substep.
iii This is the third substep.
2 You must perform this step.
Multiple PDF document search

You can use Adobe Reader Release 6.0 and later to search multiple PDF files for a
common term. Adobe Reader displays the results in a single display panel. The
results are grouped by PDF file, and you can expand the entry for each file.
Note — The PDF files in which you search must be in the same
folder.
Procedure 5 To search multiple PDF files for a common term

1 Open Adobe Acrobat Reader.
2 Choose Edit→Search from the Acrobat Reader main menu. The Search PDF panel
appears.
3 Enter the search criteria.
vi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Preface
4 Click on the All PDF Documents In radio button.
5 Select the folder in which to search using the drop-down menu.
6 Click on the Search button.
Acrobat Reader displays the search results. You can expand the entries for each
document by clicking on the + symbol.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 vii

Preface
viii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

ETSI P-OLT safety guidelines
This chapter provides information about the mandatory regulations that govern the
installation and operation of the 7342 ISAM FTTU packet optical line termination
(P-OLT) system.
Safety instructions
This section describes the safety instructions that are provided in the
7342 ISAM FTTU customer documentation, equipment, and location where the
equipment resides.
Safety instruction boxes

The following are instructions provided in the 7342 ISAM FTTU customer
documentation. Observe the instructions whenever you see them to meet safety
requirements.
The following is an example of the Danger box.
Danger — Possibility of personal injury.
The Danger box indicates that the described activity or situation may pose a threat to
personal safety. It calls attention to a situation or procedure which, if not correctly
performed or adhered to, may result in death or serious physical harm.
Do not proceed beyond a Danger box until the indicated conditions are fully
understood and met.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 ix

The following is an example of the Warning box.

Warning 1 — Possibility of equipment damage.
Warning 2 — Possibility of data loss.
The Warning box indicates that the described activity or situation may, or will, cause
equipment damage, loss of data, or serious performance problems. It calls attention
to a possible equipment-damaging situation or provides essential information for
avoiding degradation of system operations or data.
Do not proceed beyond a Warning box until the indicated conditions are fully
understood and met.
The following is an example of the Caution box.
Caution 1 — Possibility of service interruption.
Caution 2 — Service interruption.
The Caution box indicates that the described activity or situation may, or will, cause
service interruption.
Do not proceed beyond a Caution box until the indicated conditions are fully
understood and met.
The following is an example of the Note box.
Note — Information of special interest.
The Note box provides information that assists the personnel working with
7342 ISAM FTTU. It does not provide safety related instructions.
Safety related labels

Safety warning labels are located on the P-OLT equipment. The following are
sample safety labels.
ESD warning label
Figure 1 shows the electrostatic discharge (ESD) warning label that contains the ESD
awareness symbol for devices and assemblies that are susceptible to ESD.
x October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Figure 1 ESD warning label
18456
Hazardous voltage warning label
Figure 2 shows the hazardous voltage warning label. The symbol calls attention to
the risk of electric shock. It is generally used for voltages in excess of 1000 V, but
can also be used for lower voltages if an explanation is provided in the
documentation.
Figure 2 Hazardous voltage warning label
18457
Laser warning labels
The following figures show the labels related to laser product, classification, and
warning.
Figure 3 shows a laser product label.
Figure 3 Laser product label
18455
Figure 4 shows a laser classification label. Laser classification labels may be

provided in other languages.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xi

Figure 4 Laser classification label
CLASS 1 LASER PRODUCT '

PRODUCTO LASER CLASE 1
'
CLASE 1 DEL LASER LASER CLASSE 1
18992
Figure 5 shows laser warning labels, including an explanatory label for laser
products. Explanatory labels may be provided in other languages. The explanatory
label provides the following information:
• a warning that calls attention to the invisible laser radiation
• an instruction against staring into the beam or viewing directly with optical
instruments
• wavelength
• normal output power
• maximum output power
xii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Figure 5 Laser warning labels
INVISIBLE LASER RADIATION

DO NOT STARE INTO BEAM
OR VIEW DIRECTLY WITH
OPTICAL INSTRUMENTS
Wavelength(s): xxxx nm
Normal output power: xx m W
Max output power: yyy m W
Laser Warning Label Laser Warning Label
CLASS 1 LASER PRODUCT
RAYONNEMENT LASER CLASSE 1

'
RAYONNEMENT LASER INVISIBLE
EVITER TOUTE EXPOSITION AU FAISCEAU
NE PAS DEMONTER. FAIRE APPEL A UN PERSONNELL QUALIFIE
CLASE 1 DEL LASER
RADIACION DE LASER INVISIBLE. EVITAR CUALOUIER EXPOSICION AL
RAYO LASER. NO DESMONTAR. LLAMAR A PERSONAL AUTORIZADO
INVISIBLE LASER RADIATION PRESENT AT FIBER OPTIC CABLE

WHEN NOT CONNECTED. AVOID DIRECT EXPOSURE TO BEAM.
Laser Warning Label

18993
Protective grounding terminal
Figure 6 and Figure 7 show the symbols indicating a terminal that must be connected
to earth ground before any other connections to the equipment can be made.
Figure 6 shows the symbol for a supply wire protective earth terminal. The symbol
is placed at the equipment earthing point and is mandatory for all grounding
equipment.
Figure 6 Supply wire protective earth terminal
9717
Figure 7 shows the symbol for an earth terminal.
Figure 7 Earth terminal
9718
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xiii

Safety standards compliance
This section describes the compliance of the P-OLT equipment to European safety
standards.
EMC, EMI, and ESD standards compliance

The P-OLT equipment has been tested for compliance with the following EMC,
EMI, and ESD standards:
• EN 300-386 V1.3.2 (2003-05): Electromagnetic Compatibility and Radio
Spectrum Matters (ERM): Telecommunications Network Equipment;
Electromagnetic Compatibility (EMC) requirements; Electrostatic Discharge
(ESD) requirements.
• EN55022 (1998): Class A, Information Technology Equipment, Radio
Disturbance Characteristics, limits and methods of measurement (OLTS-M
system configuration)
• EN55022 (1998): Class B, Information Technology Equipment, Radio
Disturbance Characteristics, limits and methods of measurement (ALTS-N
system configuration)
• EN55024 (1998): Information Technology Equipment, Immunity
Characteristics, limits and methods of measurement
• European Union EMC Directive 89/336/EEC of May 3 1989
Environmental standards compliance

The P-OLT equipment has been tested for compliance with the EN 300-019
European environmental standard.
Equipment safety standards compliance

The P-OLT equipment has been tested for compliance with the EN 60950-1
requirements for Safety of Information Technology Equipment for use in a restricted
location (R-269).
Laser product standards compliance

The P-OLT equipment has been tested for compliance with EN 60825-1 and IEC
60825-2 for laser products.
Resistibility requirements compliance

The ALTS-N (containing GLT2-A, EHNT-A, and ancillary cards) P-OLT
equipment has been tested and is compliant with to the requirements of ITU
Recommendation K.20 for resistibility of telecommunication equipment installed in
a telecommunication center to overvoltage and overcurrents.
xiv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Electrical safety guidelines
This section provides information about electrical safety guidelines for the P-OLT
rack equipment.
Equipment classification
The P-OLT equipment is classified as Class 1 according to its protection against
electric shock.
The P-OLT rack equipment is dc powered by:
• a branch battery A with one, two, or three feeders (A1, A2, A3) for the dc power
supply from battery A in the power plant
• a branch battery B with one, two, or three feeders (B1, B2, B3) for the dc power
supply from battery B in the power plant
• one, two, or three insulated BATRET conductors for battery return to both
batteries
The P-OLT rack equipment supports both 3-wire and 2-wire power configuration
options. For a 2-wire power supply, the ground is achieved by connecting the frame
ground connection to BATRET. For a 3-wire power supply, an additional PE
conductor is required to provide a path to ground for the metal rack structure on
external surfaces.
Note — In a 3-wire system with fixed shelf powering, feeders A1,

A2, B1, and B2 power the two shelves. Feeder A3 powers the upper
fan unit and feeder B3 powers the lower fan unit. One or two insulated
BATRET conductors provide battery return.
Protection against indirect contact must be provided by a circuit breaker or fuse

release.
Access area restriction for rack equipment

The P-OLT rack equipment is classified as permanently connected equipment and
must be installed in a restricted access location (RAL). The rack equipment is
installed in the central office or remote cabinet. Both locations are classified as an
RAL in accordance with EN 60950-1.
In an RAL, dangerous voltages or hazardous energy levels can cause personal harm
and equipment damage. Only qualified service personnel should have access to the
area where the rack equipment reside. The installation, operations, and maintenance
of the rack equipment must be restricted to qualified personnel.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xv

Observe the following danger and warnings:
Danger — Dangerous voltages and electrical shock by unintentional

contact with circuits exist inside the rack.
Warning — Possibility of equipment damage.
Note — There are no operator serviceable parts inside the P-OLT

equipment rack. Refer all service operations to qualified service
personnel.
Battery feed circuit breaker

Before replacing the P-OLT rack equipment, ensure that the battery feed circuit
breakers are off.
Battery voltage
There is a risk of personal injury from unintentional contact with connectors. Service
personnel must be protected against the battery voltage present on the connectors.
Observe the following warning:
Danger — Electrical shock hazard due to battery voltage present at

connectors.
Note — There are no operator serviceable parts inside the P-OLT

equipment rack. Refer all service operations to qualified service
personnel.
Electrical SFP cable safety

Use shielded CAT 5e or better grade Ethernet cables for use with electrical interfaces
on the NT cards.
Laser safety guidelines
In accordance with EN 60825-1, the P-OLT equipment is classified as a Class 1 laser

product based on the accessible emission at the P-OLT. The classification as a Class
1 laser product is based on the transmit optical outputs for the P-OLT.
xvi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Observe the following warning when performing installation, operations, and

maintenance tasks on the P-OLT equipment.
Danger — Invisible laser radiation could be present at the fiber optic

cable when the cable is removed from the connector. Avoid direct
exposure to the beam.
Only qualified service personnel who are thoroughly familiar with laser radiation
hazards should install or remove the fiber optic cables and units in this system.
Figure 3, Figure 4, and Figure 5 show the laser warning labels on the P-OLT
equipment.
Transmit optical output

The maximum transmit optical output of the P-OLT components are listed as
follows:
• SFPs and XFPs on NT cards: see the NT card unit data sheet in the
7342 ISAM FTTU Product Information Manual
• SFPs on LT cards: see the LT card unit data sheet in the 7342 ISAM FTTU
Product Information Manual
Laser classification
The P-OLT is a Class 1 laser product. According to the EN 60825-1 and IEC 60825-2
requirements, lasers must not exceed the accessible emission limit of Class 1 under
all condition of operations, maintenance, service, and failure.
The P-OLT equipment contains two network termination (NT) cards for redundancy.
Each NT card contains 1-GE SFP and 10-GE XFP pluggable optical modules. These
optical modules are classified as hazard level 1 laser product.
The following is a laser hazard warning box typically seen in the 7342 ISAM FTTU
P-OLT installation and maintenance procedures. Eyes can be damaged when they are
exposed to a laser beam. Take necessary precautions before plugging in the optical
modules.
Danger — Risk of eye damage by laser radiation.
Warning — Possibility of equipment damage.
Normal laser operation

The optical fiber communication systems used in the rack consist of a laser
transmitter module and an optical receiver. For connection to the external optical
cable system, optical connectors have been provided on the front panel of the NT
card for GE links.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xvii

In normal operation, the laser transmitter is enclosed by the optical connector and the
external optical fiber. Laser radiation is always present when the laser unit is
powered on, limited to maximum 1 mW.
Observe the following warning. Eyes can be damaged when they are exposed to a
laser beam. Operating personnel must observe the instructions on the laser
explanatory label before plugging in the optical module.
Danger — Risk of eye damage by laser radiation.
Location class
According to EN 60825-2, the laser device, when mounted in the rack, is classified
as a hazard level 1 product. The fiber cables pass through the bottom (or top) rack
entrance. The use of cable supports and guides protects the receptacles from strain.
The P-OLT rack equipment must be placed in the central office or remote cabinets,
which are an RAL. In an RAL, activities inside the rack equipment must be
conducted by qualified personnel only. Direct viewing of the laser beam is only
possible when there is a disconnected fiber in an open rack.
Note — The remote cabinet application requires that temperature

hardened optical modules be used in the NT card.
ESD safety guidelines
The P-OLT equipment is sensitive to ESD. See Figure 1 for the ESD awareness label.
During installation and maintenance, operating personnel must take precautions by
wearing a wrist strap to protect potential damages caused by ESD.
Alcatel-Lucent recommends that site preparation be performed before installing the
P-OLT equipment. In addition, there shall be measures to control relative humidity,
use static dissipating material for furniture or flooring, and restrict the use of air
conditioning.
Precautions
The necessary precautions must be taken to discharge operating personnel by the use
of approved discharge straps or links and a conductive layer on the exchange floor.
The following precautions must be observed.
• Wear an antistatic wristband when:
• replacing plug-in units and cards
• operating circuit breakers in the rack
• the ESD awareness label is present; see Figure 1
xviii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

• Do not wear or use clothes made of wool, nylon, or any synthetic material.
Such fabrics are major sources of static build-up.
• When handling cards, do not use gloves and finger covers, unless they are made
of cotton.
• Always handle the cards by the edges.
• Do not touch conductor paths with fingers or palms.
• Remove the antistatic wristband and connection cord from the rack after use.
They must not be left inside the rack when not used.
Earth bonding points for the wristband are provided on the rack, and are indicated by
the label shown in Figure 8.
Figure 8 Label for earth bonding point
EARTH
BONDING
POINT
17659
Environmental requirements
Observe the following environmental requirements when handling the P-OLT

equipment.
Storage
According to ETS 300-019-1-1 - Class 1.1, storage of P-OLT equipment must be in
Class 1.1, weather-protected, not temperature-controlled storage locations.
Transportation
According to EN 300-019-1-2 - Class 2.3, transportation of the P-OLT equipment
must be in packed, public transportation with no rain on packing allowed.
Stationary use
According to EN 300-019-1-3 - Class 3.1/3.2/3.E, stationary use of P-OLT
equipment must be in a temperature-controlled location, with no rain allowed, and
with no condensation allowed.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xix

Thermal limitations
When the P-OLT is installed in the CO or CEV, install air filters on the P-OLT. The
thermal limitations for P-OLT operation in a CO or CEV are:
• operating temperature: 5°C to 40°C (41°F to 104°F)°
• short-term temperature: –5°C to 50°C (23°F to 122°F)
• operating relative humidity: 5% to 85%
• short-term relative humidity: 5% to 95%, but not to exceed 0.024 kg of water/kg
End-of-life collection and treatment

At the end of their life, the P-OLT products are subject to the applicable local
legislations that implement the European Directive 2002/96EC on waste electrical
and electronic equipment (WEEE).
There can be different requirements for collection and treatment in different member
states of the European Union.
xx October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

ETSI environmental and CRoHS guidelines
This chapter provides information about the ETSI environmental China Restriction
of Hazardous Substances (CRoHS) regulations that govern the installation and
operation of the 7342 ISAM FTTU packet optical line termination (P-OLT) and
optical network termination (ONT) systems. This chapter also includes
environmental operation parameters of general interest.
Environmental labels
This section describes the environmental instructions that are provided with the
7342 ISAM FTTU customer documentation, equipment, and location where the
equipment resides.
Overview
CRoHS is applicable to Electronic Information Products (EIP) manufactured or sold
and imported in the territory of the mainland of the People’s Republic of China. EIP
refers to products and their accessories manufactured by using electronic information
technology, including electronic communications products and such subcomponents
as batteries and cables.
Environmental related labels

Environmental labels are located on appropriate equipment. The following are
sample labels.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxi

Products below Maximum Concentration Value (MCV) label
Figure 1 shows the label that indicates a product is below the maximum
concentration value, as defined by standard SJ/T11363-2006 (Requirements for
Concentration Limits for Certain Hazardous Substances in Electronic Information
Products). Products with this label are recyclable. The label may be found in this
documentation or on the product.
Figure 1 Products below MCV value label
18986
Products containing hazardous substances above Maximum Concentration

Value (MCV) label
Figure 2 shows the label that indicates a product is above the maximum
concentration value, as defined by standard SJ/T11363-2006 (Requirements for
Concentration Limits for Certain Hazardous Substances in Electronic Information
Products). The number contained inside the label indicates the
Environment-Friendly User Period (EFUP) value. The label may be found in this
documentation or on the product.
xxii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Figure 2 Products above MCV value label
18985
Together with major international telecommunications equipment companies,

Alcatel-Lucent has determined it is appropriate to use an EFUP of 50 years for
network infrastructure equipment and and EFUP of 20 years for handsets and
accessories. These values are based on manufacturers' extensive practical experience
of the design, manufacturing, maintenance, usage conditions, operating
environments, and physical condition of infrastructure and handsets after years of
service. The values reflect minimum values and refer to products operated according
to the intended use conditions. See “Hazardous Substances Table (HST)” for more
information.
Hazardous Substances Table (HST)
This section describes the compliance of the P-OLT and ONT equipment to the
CRoHS standard when the product and subassemblies contain hazardous substances
beyond the MCV value. This information is found in this user documentation where
part numbers for the product and subassemblies are listed. It may be referenced from
ordering information in other P-OLT and ONT documentation.
In accordance with the People’s Republic of China Electronic Industry Standard
Marking for the Control of Pollution Caused by Electronic Information Products
(SJ/T11364-2006), customers may access the Alcatel-Lucent Hazardous Substance
Table, in Chinese, from the following location:
• http://www.alcatel-sbell.com.cn/wwwroot/images/upload/private/1/media/ChinaR
oHS.pdf
Other environmental requirements
Observe the following environmental requirements when handling the P-OLT or

ONT equipment.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxiii

ONT environmental requirements

See the ONT technical specification documentation for more information about
temperature ranges.
Storage
According to ETS 300-019-1-1 - Class 1.1, storage of P-OLT equipment must be in
Class 1.1, weather-protected, temperature-controlled locations.
Transportation
According to EN 300-019-1-2 - Class 2.3, transportation of the P-OLT equipment
must be in packed, public transportation with no rain on packing allowed.
Stationary use
According to EN 300-019-1-3 - Class 3.1/3.2/3.E, stationary use of P-OLT
equipment must be in a temperature-controlled location, with no rain allowed, and
with no condensation allowed.
Thermal limitations
When the P-OLT is installed in the CO or CEV, install air filters on the P-OLT. The
thermal limitations for P-OLT operation in a CO or CEV are:
• operating temperature: 5°C to 40°C (41°F to 104°F)°
• short-term temperature: –5°C to 50°C (23°F to 122°F)
• operating relative humidity: 5% to 85%
• short-term relative humidity: 5% to 95%, but not to exceed 0.024 kg of water/kg
Material content compliance

European Union (EU) Directive 2002/95/EC, “Restriction of the use of certain
Hazardous Substances” (RoHS), restricts the use of lead, mercury, cadmium,
hexavalent chromium, and certain flame retardants in electrical and electronic
equipment. This Directive applies to electrical and electronic products placed on the
EU market after 1 July 2006, with various exemptions, including an exemption for
lead solder in network infrastructure equipment. Alcatel-Lucent products shipped to
the EU after 1 July 2006 comply with the EU RoHS Directive.
xxiv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

End-of-life collection and treatment

Electronic products bearing or referencing the symbol shown in Figure 3, when put
on the market within the European Union (EU), shall be collected and treated at the
end of their useful life, in compliance with applicable EU and local legislation. They
shall not be disposed of as part of unsorted municipal waste. Due to materials that
may be contained in the product, such as heavy metals or batteries, the environment
and human health may be negatively impacted as a result of inappropriate disposal.
Note — In the European Union, a solid bar under the symbol for a
crossed-out wheeled bin indicates that the product was put on the
market after 13 August 2005.
Figure 3 Recycling/take back/disposal of product symbol
At the end of their life, the P-OLT products are subject to the applicable local
legislations that implement the European Directive 2002/96EC on waste electrical
and electronic equipment (WEEE).
There can be different requirements for collection and treatment in different member
states of the European Union.
In compliance with legal requirements and contractual agreements, where
applicable, Alcatel-Lucent will offer to provide for the collection and treatment of
Alcatel-Lucent products bearing the logo shown in Figure 3 at the end of their useful
life, or products displaced by Alcatel-Lucent equipment offers. For information
regarding take-back of equipment by Alcatel-Lucent, or for more information
regarding the requirements for recycling/disposal of product, contact your
Alcatel-Lucent account manager or Alcatel-Lucent take back support at
[email protected].
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxv

xxvi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Preface iii
Scope ............................................................................................... iii
Audience ............................................................................................... iii
Prerequired knowledge ............................................................................... iii
Assistance and ordering phone numbers ........................................................... iii
Alcatel-Lucent quality processes .................................................................... iv
Safety information ..................................................................................... iv
Documents .............................................................................................. iv
Procedure 1 To download an CD-ROM ISO image or ZIP file package
of the 7342 ISAM FTTU customer documentation ........................... iv
Procedure 2 To access individual documents ...................................... v
Special information..................................................................................... v
Procedures with options or substeps ................................................. v
Procedure 3 Example of options in a procedure.................................. vi
Procedure 4 Example of required substeps in a procedure ..................... vi
Multiple PDF document search....................................................................... vi
Procedure 5 To search multiple PDF files for a common term ................. vi
ETSI P-OLT safety guidelines ix

Safety instructions ..................................................................................... ix
Safety instruction boxes .............................................................. ix
Safety related labels.................................................................... x
Safety standards compliance........................................................................xiv
EMC, EMI, and ESD standards compliance .........................................xiv
Environmental standards compliance ..............................................xiv
Equipment safety standards compliance ..........................................xiv
Laser product standards compliance ...............................................xiv
Resistibility requirements compliance .............................................xiv
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxvii

Contents
Electrical safety guidelines.......................................................................... xv

Equipment classification ............................................................. xv
Access area restriction for rack equipment ....................................... xv
Battery feed circuit breaker.........................................................xvi
Battery voltage ........................................................................xvi
Electrical SFP cable safety ..........................................................xvi
Laser safety guidelines...............................................................................xvi
Transmit optical output ............................................................. xvii
Laser classification................................................................... xvii
Normal laser operation .............................................................. xvii
Location class ........................................................................ xviii
ESD safety guidelines............................................................................... xviii
Precautions........................................................................... xviii
Environmental requirements ........................................................................xix
Storage..................................................................................xix
Transportation .........................................................................xix
Stationary use .........................................................................xix
Thermal limitations ................................................................... xx
End-of-life collection and treatment .............................................. xx
ETSI environmental and CRoHS guidelines xxi

Environmental labels .................................................................................xxi
Overview ...............................................................................xxi
Environmental related labels........................................................xxi
Hazardous Substances Table (HST)............................................................... xxiii
Other environmental requirements .............................................................. xxiii
ONT environmental requirements ................................................ xxiv
Storage................................................................................ xxiv
Transportation ....................................................................... xxiv
Stationary use ....................................................................... xxiv
Thermal limitations ................................................................. xxiv
Material content compliance ...................................................... xxiv
End-of-life collection and treatment ............................................. xxv
General system description
1— Overview 1-1
1.1 7342 ISAM FTTU overview.............................................................. 1-2
1.2 GPON features ........................................................................... 1-4
Extended PON operation ............................................................ 1-4
1.3 Service features ......................................................................... 1-5
Voice service.......................................................................... 1-5
Data and IPTV services .............................................................. 1-5
RF video service ...................................................................... 1-6
Wireless mobile backhaul services ................................................ 1-6
xxviii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
CES encapsulated DS1/E1 ........................................................... 1-8

GENIP service ......................................................................... 1-8
1.4 Network interfaces ..................................................................... 1-9
P-OLT interfaces ..................................................................... 1-9
V-OLT interfaces ..................................................................... 1-9
ONT interfaces....................................................................... 1-10
1.5 Element management system ........................................................ 1-10
5520 AMS ............................................................................. 1-10
GENIP service ........................................................................ 1-10
2— Feature descriptions 2-1

2.1 Overview ................................................................................. 2-3
2.2 Release R04.09.00 features ........................................................... 2-3
2.11 Release R04.07.00 features .......................................................... 2-14
2.14 Release R04.06.00 and R04.06.01 features ........................................ 2-17
3— R04.08.00 feature overview and configuration details 3-1

3.1 Overview ................................................................................. 3-3
3.2 Rogue ONT detection enhancements ................................................ 3-3
3.3 Security enhancements for SIP user name and password modification......... 3-3
3.4 OLT password security enhancement ................................................ 3-3
3.5 SIP improvements ....................................................................... 3-3
3.6 Support for OISGv1 and OISGv2 VoIP provisioning ................................. 3-4
3.7 Background Type-A downloads........................................................ 3-4
3.8 Video Rx sensitivity improvement and alarm update.............................. 3-4
3.9 Multicast Loss of Stream alarm enhancement ...................................... 3-4
3.10 Jitter, latency, RT performance report ............................................. 3-4
3.11 802.3ah OAM on ONT Ethernet interfaces........................................... 3-5
New TL1 commands.................................................................. 3-5
New alarms............................................................................ 3-5
3.12 SNMP support for TL1 user management ............................................ 3-5
3.13 OLT acts as an SNTP server ............................................................ 3-6
3.14 Global SSNAP modification ............................................................ 3-6
3.15 Multiple BFMU managers ............................................................... 3-6
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxix

Contents
4— Application notes 4-1

4.1 Overview ................................................................................. 4-2
4.2 Release FGU 04.04.xx application notes ............................................ 4-2
4.3 Release FGU 4.3.5 application notes................................................. 4-3
4.4 Release FGU 4.3.0 application notes................................................. 4-3
4.5 Release FGU 4.2 application notes ................................................... 4-4
5— Functional description 5-1

5.1 Overview ................................................................................. 5-2
5.2 7342 ISAM FTTU system architecture ................................................ 5-2
5.3 P-OLT functional blocks ................................................................ 5-2
Network termination ................................................................ 5-4
Line termination...................................................................... 5-7
5.4 V-OLT functional blocks................................................................ 5-9
RF video signal distribution......................................................... 5-9
RF video services ..................................................................... 5-9
Upstream signal and data channels .............................................. 5-10
RF video service management .................................................... 5-10
6— Equipment layout 6-1

6.1 Overview ................................................................................. 6-2
6.2 P-OLT equipment layout ............................................................... 6-2
OLT rack ............................................................................... 6-2
OLT ALTS-N shelf ..................................................................... 6-4
P-OLT OLTS-M shelf .................................................................. 6-6
OLT shelf backplane ................................................................. 6-7
Cards in the OLT shelf ............................................................... 6-7
6.3 V-OLT equipment layout ............................................................... 6-9
6.4 Video coupler equipment layout...................................................... 6-9
Video coupler fiber rack ........................................................... 6-10
Video coupler shelf ................................................................. 6-10
Video coupler WDM tray............................................................ 6-10
6.5 ONT equipment layout ................................................................ 6-12
ONT connection capacity .......................................................... 6-12
7— Operations, administration, and maintenance 7-1

7.1 Overview ................................................................................. 7-2
7.2 Management interfaces ................................................................ 7-2
Craft terminal ........................................................................ 7-4
TL1 and CLI access protocol options .............................................. 7-5
Ethernet ports on the AACU and the P-OLT backplane......................... 7-5
5520 AMS connection options ...................................................... 7-5
7.3 EMS functions ............................................................................ 7-5
5520 AMS .............................................................................. 7-6
GENIP service ......................................................................... 7-6
7.4 Operations, administration and maintenance ...................................... 7-6
Hardware operation, administration, and maintenance tasks ................ 7-6
ONT repair and return information................................................ 7-7
xxx October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
7.5 Troubleshooting ......................................................................... 7-7

7.6 OSMINE certification .................................................................... 7-7
8— Technical specifications 8-1

8.1 Overview ................................................................................. 8-2
8.2 P-OLT equipment........................................................................ 8-2
8.3 Video coupler equipment .............................................................. 8-3
8.4 System and service capacity specifications ......................................... 8-4
Service and system capacity ....................................................... 8-4
P-OLT performance and distance ................................................. 8-12
PON bandwidth ...................................................................... 8-12
P-OLT connection capacities ...................................................... 8-13
Video coupler connection capacity............................................... 8-13
8.5 GPON optical and RF line rates ...................................................... 8-13
8.6 P-OLT optical budgets ................................................................. 8-13
8.7 Video coupler optical budget ........................................................ 8-14
8.8 Environmental requirements ......................................................... 8-14
8.9 Power specifications................................................................... 8-15
P-OLT input voltage................................................................. 8-15
P-OLT power consumption ......................................................... 8-15
Detailed system description
9— Alarms and troubleshooting 9-1

9.1 Overview ................................................................................. 9-2
General ................................................................................ 9-2
Alarm storm prevention ............................................................ 9-2
9.2 Isolating faults indicated by alarms .................................................. 9-3
10 — DHCP 10-1
10.1 Overview ................................................................................ 10-2
10.2 DHCPv4 .................................................................................. 10-2
Layer 2 DHCP relay agent used by DHCPv4...................................... 10-2
DHCPv4 Option 82 ................................................................... 10-3
Operation of DHCPv4 ............................................................... 10-3
DHCP relay configuration parameters............................................ 10-4
10.3 DHCPv6 .................................................................................. 10-6
Lightweight DHCP relay agent .................................................... 10-6
Option 18 (interface ID) ............................................................ 10-7
Option 37 (relay agent remote ID) ............................................... 10-8
DHCPv6 trusted/untrusted port configuration.................................. 10-8
DHCPv6 specifications .............................................................. 10-8
DHCPv6 messages ................................................................... 10-9
DHCPv6 options.................................................................... 10-10
DHCPv6 message sequencing .................................................... 10-12
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxxi

Contents
11 — PPPoE 11-1
11.1 Overview ................................................................................ 11-2
11.2 PPPoE relay agent...................................................................... 11-2
11.3 PPPoE relay agent configuration parameters ...................................... 11-2
12 — ICMPv6 12-1
12.1 Overview ................................................................................ 12-2
12.2 ICMPv6 neighbor discovery (ND) ..................................................... 12-2
ICMPv6 secure filtering ............................................................. 12-2
12.3 ICMPv6 ND specifications ............................................................. 12-3
ICMPv6 messages .................................................................... 12-3
ICMPv6 options....................................................................... 12-4
ND message sequencing ............................................................ 12-5
13 — Fault isolation 13-1

13.1 Overview ................................................................................ 13-2
13.2 Monitoring OLT and ONT optics ...................................................... 13-2
Optical power levels ................................................................ 13-2
Optics module status ............................................................... 13-2
Downstream threshold monitor ................................................... 13-2
13.3 Ping....................................................................................... 13-3
13.4 RMON Ethernet statistics.............................................................. 13-3
13.5 Statistics and performance monitoring ............................................. 13-3
VoIP call statistics................................................................... 13-3
13.6 TCA counters and alarms ............................................................. 13-3
TCA alarms ........................................................................... 13-4
TCA provisioning..................................................................... 13-4
TCAs for backplane errors ......................................................... 13-5
13.7 DS1 and E1 loopbacks.................................................................. 13-5
13.8 Ethernet OAM ........................................................................... 13-6
Continuity check tests.............................................................. 13-7
Link trace tests ...................................................................... 13-8
Loopback tests....................................................................... 13-9
Jitter and latency measurements .............................................. 13-10
SES switch local SNI and AIS ..................................................... 13-10
Ethernet AIS........................................................................ 13-11
EFM OAM ............................................................................ 13-11
14 — IP multicast and IGMP 14-1

14.1 Overview ................................................................................ 14-2
Features .............................................................................. 14-2
14.2 IP multicast stream flow .............................................................. 14-4
14.3 IGMP infrastructure .................................................................... 14-4
14.4 IGMP signaling .......................................................................... 14-5
IGMP signaling between the network and NT ................................... 14-6
IGMP signaling between the NT and the LT card ............................... 14-6
IGMP signaling between the LT card and the ONT UNI port .................. 14-6
xxxii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
14.5 IGMP proxy .............................................................................. 14-6

IGMP proxy at the NT ............................................................... 14-7
IGMP proxy on the LT card......................................................... 14-8
IGMP half-proxy mode on the LT card ........................................... 14-8
14.6 IGMP snoop .............................................................................. 14-9
IGMP snoop versus IGMP proxy .................................................... 14-9
14.7 Subscriber access networks......................................................... 14-10
IPoE subscriber access network ................................................. 14-10
PPPoE subscriber access network............................................... 14-14
14.8 ASM and SSM multicast .............................................................. 14-17
ASM .................................................................................. 14-17
SSM .................................................................................. 14-17
Configuration considerations .................................................... 14-17
14.9 Preconfigured and nonconfigured multicast ..................................... 14-19
Dynamic and static multicast streams ......................................... 14-19
Forwarding in the data plane ................................................... 14-20
14.10 Join and leave messages ............................................................ 14-20
LT-to-ONT signaling mode enabled............................................. 14-21
LT-to-ONT signaling mode disabled (default)................................. 14-21
Processing of join messages on the LT card................................... 14-23
Processing limits .................................................................. 14-25
Fast channel change .............................................................. 14-26
14.11 Counters and alarms ................................................................. 14-27
Counters per VLAN ................................................................ 14-28
Counters per multicast stream.................................................. 14-28
Counters per subscriber .......................................................... 14-28
Counters per LT IGMP proxy module ........................................... 14-29
Subscriber and channel activity................................................. 14-30
On-demand alarms ................................................................ 14-30
Counters per PON for multicast GEM port..................................... 14-30
14.12 Subscriber and video management ................................................ 14-31
Terminology........................................................................ 14-31
Package ............................................................................. 14-32
Access control ..................................................................... 14-32
Access modes ...................................................................... 14-34
Control Data Records ............................................................. 14-34
Wholesale video through residential-bridging ................................ 14-35
14.13 IGMP protocol handling with no IGMP signaling channel ....................... 14-36
15 — Layer 2 forwarding 15-1

15.1 Overview ................................................................................ 15-2
15.2 Forwarding architecture .............................................................. 15-2
LT architecture ...................................................................... 15-2
NT architecture...................................................................... 15-4
ONT functionality and bridge port modeling.................................... 15-5
15.3 Layer 2 forwarding rules on the NT card ........................................... 15-6
Classifying interfaces ............................................................... 15-6
Switching flood traffic.............................................................. 15-7
Learning MAC addresses............................................................ 15-7
Limiting learned MAC addresses or C-VLAN IDs at the LT ..................... 15-8
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxxiii

Contents
15.4 Layer 2 forwarding modes on the LT card.......................................... 15-9

Residential bridge mode ......................................................... 15-10
VLAN transparent cross-connect mode ........................................ 15-12
C-VLAN learning mode............................................................ 15-14
Forwarding model summary ..................................................... 15-16
15.5 Duplicate MAC address and C-VLAN handling .................................... 15-17
Duplicate MAC address handling on the NT and the LT ..................... 15-17
Effect of enabling MAC movement on duplicate MAC address
handling....................................................................... 15-18
Duplicate C-VLAN handling on the LT .......................................... 15-18
15.6 Residential bridge mode configuration requirements .......................... 15-18
Upstream frame forwarding ..................................................... 15-18
Downstream frame forwarding.................................................. 15-19
Configuration requirements ..................................................... 15-19
15.7 C-VLAN learning mode configuration requirements ............................ 15-20
15.8 Cross-connect mode configuration requirements ............................... 15-21
Configuration requirements ..................................................... 15-21
Forwarding ......................................................................... 15-21
15.9 Transparent protocol forwarding .................................................. 15-22
15.10 MAC filters ............................................................................ 15-22
15.11 Pause frames.......................................................................... 15-22
15.12 Layer 2 forwarding for EVC and subscriber scalability implementations .... 15-23
Implementation considerations ................................................. 15-23
Restrictions and limitations ..................................................... 15-26
16 — NT redundancy 16-1
16.1 Overview ................................................................................ 16-2
16.2 Single bridge port configuration ..................................................... 16-2
16.3 Multiple bridge port configuration .................................................. 16-3
16.4 Multiple upstream switches configuration ......................................... 16-3
16.5 Uplink redundancy to multiple upstream switches ............................... 16-4
16.6 Multi uplink protection to upstream switches ..................................... 16-5
16.7 Redundancy between NT and LT cards ............................................. 16-5
16.8 Dynamic data synchronization ....................................................... 16-6
17 — Proxy ARP 17-1

17.1 Overview ................................................................................ 17-2
17.2 Functional description................................................................. 17-2
17.3 Proxy ARP process flow ............................................................... 17-2
17.4 ARP table persistence ................................................................. 17-3
17.5 Static ARP IP address .................................................................. 17-3
ARP snooping......................................................................... 17-4
18 — QoS 18-1
18.1 Overview ................................................................................ 18-2
18.2 QoS infrastructure ..................................................................... 18-2
18.3 Traffic classification and marking elements ....................................... 18-4
CoS .................................................................................... 18-4
P-bit ................................................................................... 18-4
xxxiv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
DSCP................................................................................... 18-5
DSCP to p-bit mapping ............................................................. 18-5
P-bit to CoS mapping ............................................................... 18-5
C-VLAN to S-VLAN p-bit translation .............................................. 18-6
UNI-side to network-side p-bit translation profile ............................. 18-6
QoS marker and session profiles .................................................. 18-7
18.4 Traffic policing elements ............................................................. 18-8
Traffic meter ........................................................................ 18-8
Ingress rate........................................................................... 18-8
Maximum burst size ................................................................. 18-8
Traffic flow .......................................................................... 18-8
Egress rate ........................................................................... 18-9
18.5 Congestion management elements .................................................. 18-9
Switch ................................................................................. 18-9
Ports................................................................................. 18-10
Scheduler and queues ............................................................ 18-10
P-bit to queue mapping .......................................................... 18-10
Traffic scheduler .................................................................. 18-11
Downstream hierarchical scheduler and rate limiting....................... 18-13
Priority queue profile............................................................. 18-17
T-CONTs and GEM ports .......................................................... 18-18
GEM traffic descriptors........................................................... 18-21
18.6 Traffic shaping elements............................................................ 18-22
PON bandwidth .................................................................... 18-23
Bandwidth profile ................................................................. 18-23
Reserved bandwidth .............................................................. 18-24
Dynamic bandwidth allocation (DBA) .......................................... 18-24
18.7 QoS configuration .................................................................... 18-28
18.8 End-to-end downstream queuing and scheduling ............................... 18-29
From the network (EMAN) to the NT ........................................... 18-30
From the NT to the LT............................................................ 18-30
From the LT across the GPON to the ONT ..................................... 18-30
From the ONT to the subscriber ................................................ 18-31
18.9 End-to-end upstream queuing and scheduling................................... 18-32
From the ONT to the LT .......................................................... 18-33
From the LT to the NT............................................................ 18-34
From the NT to the network (E-MAN) .......................................... 18-35
18.10 Multicast bandwidth considerations............................................... 18-35
18.11 Recommended DSCP to p-bit mapping............................................ 18-36
19 — Statistics and performance monitoring 19-1

19.1 Overview ................................................................................ 19-2
19.2 Statistics, counters, and performance monitoring................................ 19-2
15-min counters ..................................................................... 19-3
Rolling counters ..................................................................... 19-6
Status reports........................................................................ 19-6
Monitoring thresholds and levels ................................................. 19-7
19.3 P-OLT performance monitoring statistics counters ............................... 19-7
GPON-TC layer and GEM errored fragment statistics .......................... 19-7
VLAN statistics ....................................................................... 19-8
LT bridge port statistics............................................................ 19-9
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxxv

Contents
Network port statistics ............................................................. 19-9

IGMP statistics ..................................................................... 19-11
Backplane error performance monitoring ..................................... 19-14
19.4 RMON Ethernet statistics support for the P-OLT ................................ 19-15
20 — Security 20-1
20.1 Overview ................................................................................ 20-2
20.2 Secured MAC learning ................................................................. 20-3
20.3 Access control lists..................................................................... 20-3
20.4 RADIUS proxy and server .............................................................. 20-4
20.5 SNMP encryption ....................................................................... 20-6
20.6 SSH ....................................................................................... 20-7
20.7 802.1x authentication ............................................................... 20-11
802.1x support assumptions ..................................................... 20-11
Authentication protocols......................................................... 20-12
Port-based authentication ....................................................... 20-12
User session disconnection by system.......................................... 20-13
Statistics and operational data ................................................. 20-13
Restart scenarios .................................................................. 20-13
Re-authentication ................................................................. 20-14
20.8 System log for security and NE actions ........................................... 20-15
Logged message or information types ......................................... 20-15
Message filtering .................................................................. 20-16
Syslog format ...................................................................... 20-16
Syslog file destinations ........................................................... 20-17
20.9 User account management ......................................................... 20-17
20.10 IPSec ................................................................................... 20-17
Sun Solaris and OLT interworking............................................... 20-19
20.11 Anti-spoofing mechanism ........................................................... 20-19
Gratuitous ARP discard ........................................................... 20-19
Source address anti-spoofing (ONT only) ...................................... 20-20
Per-service anti-spoofing (ONT only) .......................................... 20-22
P-OLT level anti-spoofing ........................................................ 20-22
20.12 Denial of service prevention mechanisms ........................................ 20-23
Rate limiting of control traffic .................................................. 20-23
21 — VLANs and VPNs 21-1

21.1 Overview ................................................................................ 21-2
21.2 General description.................................................................... 21-2
Definition ............................................................................. 21-3
Purpose ............................................................................... 21-3
21.3 VLAN forwarding modes ............................................................... 21-4
Residential bridge mode ........................................................... 21-4
Cross-connect mode ................................................................ 21-5
C-VLAN learning mode.............................................................. 21-7
Flow mirroring mode ............................................................... 21-9
21.4 VLAN models .......................................................................... 21-10
VLAN per subscriber model ...................................................... 21-11
VLAN per service model .......................................................... 21-12
xxxvi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
21.5 VLAN tagging.......................................................................... 21-15

VLAN tagging modes at the LT .................................................. 21-16
P-bit marking modes at the LT.................................................. 21-17
Downstream tagging modes at the ONT UNI .................................. 21-18
Upstream tagging modes at the ONT UNI...................................... 21-19
Compatible tagging modes....................................................... 21-23
21.6 C-VLAN differentiated services on a UNI ......................................... 21-23
21.7 Frame processing at the LT......................................................... 21-24
Downstream tagging at the LT .................................................. 21-24
Upstream tagging at the LT ..................................................... 21-26
21.8 Frame processing at the ONT ...................................................... 21-29
Downstream tagging at the ONT ................................................ 21-29
Upstream tagging at the ONT ................................................... 21-30
21.9 Network interface CAC bandwidth check ........................................ 21-39
CAC at NT port or LAG............................................................ 21-39
CAC for S-VLAN capacity ......................................................... 21-40
PON CAC at the LT ................................................................ 21-40
GPON and SHub VLAN bandwidth synchronization ........................... 21-41
21.10 User-to-user communication ....................................................... 21-41
Restrictions ........................................................................ 21-41
Application ......................................................................... 21-41
21.11 VLAN bridging scalability............................................................ 21-42
21.12 VPNs .................................................................................... 21-42
Services descriptions
22 — VoIP overview 22-1

22.1 Overview ................................................................................ 22-2
VoIP service operation modes ..................................................... 22-2
TISPAN support ...................................................................... 22-3
Common service operation mode features...................................... 22-3
22.2 Voice gateway mode................................................................... 22-4
GR-303/TR008 mode................................................................ 22-5
V5 mode .............................................................................. 22-6
22.3 H.248 softswitch mode ................................................................ 22-7
Softswitch call flow ................................................................. 22-8
22.4 SIP modes................................................................................ 22-8
SIP service features ................................................................. 22-9
SIP call flow ........................................................................ 22-12
22.5 Dual SIP client mode using VEIP ................................................... 22-14
22.6 VoIP service configuration .......................................................... 22-18
Process for country-specific POTS configuration files ....................... 22-19
Service and protocol configuration............................................. 22-20
Configuration profile ............................................................. 22-21
iConfig .............................................................................. 22-22
22.7 SIP data model and XML profiles................................................... 22-23
Vendor profile (CDE).............................................................. 22-24
SIP protocol (local network profile and application profile) ............... 22-25
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxxvii

Contents
Identity data ....................................................................... 22-32

Analog local network profile .................................................... 22-34
Media local network profile ..................................................... 22-37
Service data set ................................................................... 22-40
22.8 Digit map .............................................................................. 22-63
Digit map digit collection ........................................................ 22-64
Digit map syntax, collection elements, and samples for package C, D,
E, F, and G ................................................................... 22-64
Digit map syntax, collection elements, and samples for package A,
B, and H....................................................................... 22-67
RFC2833 DTMF digit transmission............................................... 22-71
INFO-based DTMF digit transmission ........................................... 22-71
22.9 Security ................................................................................ 22-72
DHCP Option 90.................................................................... 22-72
HTTP digest ........................................................................ 22-73
22.10 VoIP call and performance monitoring statistics ................................ 22-73
Statistics collection using OMCIv1 .............................................. 22-73
Statistics collection for package A, B, and H using OMCIv2 ................ 22-75
RTCP failure alarm ................................................................ 22-77
23 — HSI service 23-1

23.1 Overview ................................................................................ 23-2
23.2 Network example ...................................................................... 23-2
Downstream flow across the 7342 ISAM FTTU access network ............... 23-2
Upstream flow across the 7342 ISAM FTTU access network .................. 23-3
23.3 HSI service configuration elements ................................................. 23-3
HSI elements ......................................................................... 23-4
Relationship among the HSI elements ........................................... 23-5
23.4 QoS characteristics .................................................................... 23-7
Data traffic........................................................................... 23-7
P-bit ................................................................................... 23-7
Traffic queuing and scheduling ................................................... 23-8
Tagging ............................................................................... 23-9
23.5 HSI service configuration example ................................................ 23-10
24 — RF video services 24-1

24.1 Overview ................................................................................ 24-2
Breakdown of the RF 1550 nm and 1490 nm overlay .......................... 24-3
24.2 Network example ...................................................................... 24-3
25 — Triple play service delivery architecture in access

network 25-1
25.1 Overview ................................................................................ 25-2
Configuration tools.................................................................. 25-2
Terminology.......................................................................... 25-2
25.2 Service delivery architecture ........................................................ 25-3
IP/MPLS network .................................................................... 25-4
IP edge aggregation and routing .................................................. 25-5
7342 ISAM FTTU access network .................................................. 25-7
xxxviii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
25.3 7342 ISAM FTTU functionality ...................................................... 25-10

25.4 Equipment............................................................................. 25-11
Configuring P-OLT equipment ................................................... 25-12
Configuring ONT equipment ..................................................... 25-12
Configuring interfaces ............................................................ 25-13
25.5 System management................................................................. 25-13
Configuring system................................................................ 25-13
Configuring network management.............................................. 25-14
Configuring security .............................................................. 25-14
Configuring STP.................................................................... 25-15
Configuring system logging and event management......................... 25-15
Performing OSWP download ..................................................... 25-16
25.6 QoS ..................................................................................... 25-17
Policing traffic..................................................................... 25-17
Creating QoS profiles ............................................................. 25-17
Performing CAC check ............................................................ 25-18
25.7 Filter policies ......................................................................... 25-18
Configuring MAC filters ........................................................... 25-18
Configuring ICMP filters .......................................................... 25-19
Configuring TCP filters ........................................................... 25-19
Configuring UDP filters ........................................................... 25-19
Configuring IP protocol filters................................................... 25-19
25.8 VLANs .................................................................................. 25-20
Configuring SHub VLANs .......................................................... 25-20
Configuring PON VLANs........................................................... 25-20
VLAN tag handling................................................................. 25-21
25.9 Layer 3 routing ....................................................................... 25-22
Configuring VRFs .................................................................. 25-23
Configuring RIP .................................................................... 25-23
25.10 Layer 2 forwarding ................................................................... 25-23
Setting aging timer................................................................ 25-24
Disabling MAC learning ........................................................... 25-24
Maintaining the VLAN FDB on the NT........................................... 25-24
Maintaining the VLAN FDB on the LT ........................................... 25-25
25.11 IGMP and IP multicast ............................................................... 25-25
Configuring IGMP proxy .......................................................... 25-26
Configuring IGMP snoop .......................................................... 25-26
Configuring multicast VLANs .................................................... 25-27
Configuring for preconfigured multicast ...................................... 25-27
Configuring for nonconfigured multicast ...................................... 25-27
Configuring multicast packages ................................................. 25-27
Configuring an IGMP signaling channel......................................... 25-28
Reserving multicast bandwidth on the PON................................... 25-28
25.12 Subscriber connections .............................................................. 25-28
Configuring DHCP.................................................................. 25-28
Configuring PPPoE................................................................. 25-30
Configuring Proxy ARP ............................................................ 25-30
25.13 ONT services .......................................................................... 25-30
Configuring ONT services ........................................................ 25-31
Configuring ONT UNI ports ....................................................... 25-31
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xxxix

Contents
25.14 Configuration examples ............................................................. 25-32

System configuration ............................................................. 25-34
P-OLT equipment configuration................................................. 25-37
IGMP and multicast configuration .............................................. 25-38
ONT equipment configuration................................................... 25-44
VLAN configuration ............................................................... 25-45
DHCP configuration ............................................................... 25-47
HSI service with IGMP signaling channel configuration...................... 25-48
VoIP service configuration ....................................................... 25-50
26 — CES DS1 and E1 interfaces 26-1

26.1 Overview ................................................................................ 26-2
26.2 Network example for layer 2 CES over Ethernet on a business ONT ........... 26-2
Service options ...................................................................... 26-3
26.3 Network example for layer 3 CES over IP pseudo-wire SAToP .................. 26-5
Service options ...................................................................... 26-5
26.4 Structured and unstructured DS1 and E1 services handling for Layer 2
CES over Ethernet ............................................................... 26-6
Structured DS1/E1 .................................................................. 26-6
Unstructured DS1/E1 ............................................................... 26-7
Payload size .......................................................................... 26-7
26.5 Jitter buffering, congestion handling, and alarms................................ 26-8
26.6 CES clocking and synchronization ................................................... 26-8
26.7 Configuring DS1 and E1 port parameters ........................................... 26-9
Structured and unstructured framing mode .................................... 26-9
Framing type ....................................................................... 26-10
Line encoding ...................................................................... 26-10
Line length and line impedance ................................................ 26-11
26.8 Configuring CES PW services ....................................................... 26-11
27 — Support for the micro span CES 27-1

27.1 Overview ................................................................................ 27-2
27.2 Network example ...................................................................... 27-2
High-level workflow ................................................................ 27-3
28 — Ethernet services for business and residential

applications 28-1
28.1 Overview ................................................................................ 28-2
28.2 Metro Ethernet services infrastructure ............................................. 28-4
28.3 Ethernet virtual connection .......................................................... 28-6
EVC types ............................................................................. 28-6
Implementation of EVC on the 7342 ISAM FTTU ................................ 28-8
Configuration elements ............................................................ 28-9
28.4 EVC models............................................................................ 28-11
Internal EVC models .............................................................. 28-12
External EVC models.............................................................. 28-16
xl October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
28.5 Constraints ............................................................................ 28-17

System constraints ................................................................ 28-17
Hardware constraints ............................................................. 28-17
Configuration constraints ........................................................ 28-19
29 — GENIP service 29-1

29.1 Overview ................................................................................ 29-2
29.2 GENIP service configuration elements .............................................. 29-2
Unit data sheets
30 — Index of unit data sheets 30-1

30.1 Overview ................................................................................ 30-2
30.2 Unit data sheet overview ............................................................. 30-2
30.3 Index list of unit data sheets for 7342 ISAM FTTU ................................ 30-2
31 — AACU-C unit data sheet 31-1

31.1 Identification ........................................................................... 31-2
31.2 Features and application notes ...................................................... 31-2
31.4 Alarm control function ................................................................ 31-4
CO alarm system .................................................................... 31-4
Telemetry alarm system ........................................................... 31-5
Rack-level alarms ................................................................... 31-5
31.5 Alarm LEDs .............................................................................. 31-5
31.6 Interfaces and connections ........................................................... 31-6
Interface to the TRU................................................................ 31-6
Interface for alarm input/output ................................................. 31-6
Interface for AACU OAM............................................................ 31-6
Interface for Ethernet OS port .................................................... 31-7
Interface to the NT cards .......................................................... 31-7
31.7 Physical description.................................................................... 31-8
32 — AFAN-H unit data sheet 32-1

32.1 Identification ........................................................................... 32-2
32.4 Front panel.............................................................................. 32-3
32.5 Back panel............................................................................... 32-3
32.6 Fan and cable assembly ............................................................... 32-4
32.7 Filter assembly ......................................................................... 32-4
32.8 Electrical specifications............................................................... 32-4
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xli

Contents
33 — AFAN-S unit data sheet 33-1

33.1 Identification ........................................................................... 33-2
33.4 Front panel.............................................................................. 33-3
33.5 Filter assembly ......................................................................... 33-3
33.6 Electrical specifications............................................................... 33-3
34 — ALTS-N unit data sheet 34-1

34.1 Identification ........................................................................... 34-2
34.4 Backplane connectors and cables ................................................... 34-4
34.5 Physical location identification ...................................................... 34-6
34.6 Power distribution ..................................................................... 34-6
34.7 Thermal limitation ..................................................................... 34-7
Front cover ........................................................................... 34-8
Rear cover............................................................................ 34-8
Fiber management kit .............................................................. 34-8
Specifications ........................................................................ 34-8
35 — ATRU-M unit data sheet 35-1

35.1 Identification ........................................................................... 35-2
35.4 Front panel.............................................................................. 35-3
Indicator LEDs and test button.................................................... 35-3
Circuit breakers ..................................................................... 35-4
Earth bonding point................................................................. 35-4
35.5 PBA-ATRU-G board ..................................................................... 35-4
36 — ATRU-N unit data sheet 36-1

36.1 Identification ........................................................................... 36-2
Front panel........................................................................... 36-5
Power input terminal blocks ...................................................... 36-7
PBA-ATRU-G board ................................................................ 36-10
CO interface connector .......................................................... 36-11
ACU/FAN alarm interface connectors.......................................... 36-13
Jumpers............................................................................. 36-16
Dimensions ......................................................................... 36-17
Safety requirements .............................................................. 36-17
Specifications ...................................................................... 36-18
xlii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
37 — ATRU-U unit data sheet 37-1

37.1 Identification ........................................................................... 37-2
37.4 Front panel.............................................................................. 37-3
Indicator LEDs and test button.................................................... 37-3
Circuit breakers ..................................................................... 37-4
Earth bonding point................................................................. 37-4
37.5 PBA-ATRU-G board ..................................................................... 37-4
38 — BITS-B unit data sheet 38-1

38.1 Identification ........................................................................... 38-2
38.4 Location ................................................................................. 38-3
39 — Blank LT filler plate unit data sheet 39-1

39.1 Identification ........................................................................... 39-2
40 — Blank NT filler plate unit data sheet 40-1

40.1 Identification ........................................................................... 40-2
41 — EHNT and pluggable optical modules unit data sheet 41-1

41.1 Identification ........................................................................... 41-2
41.4 Network interface modules........................................................... 41-8
41.5 Interfaces and connectors ............................................................ 41-8
41.6 Status LEDs .............................................................................. 41-8
41.7 Power .................................................................................. 41-10
41.8 Physical description.................................................................. 41-11
42 — EXNT-A and pluggable optical modules unit data sheet 42-1

42.1 Identification ........................................................................... 42-2
42.5 Interfaces and connectors ............................................................ 42-7
42.6 Status LEDs .............................................................................. 42-7
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xliii

Contents
42.7 Power .................................................................................... 42-9

43 — FILT-A and FILT-B unit data sheet 43-1

43.1 Identification ........................................................................... 43-2
Shelf power distribution ........................................................... 43-3
Power and grounding signals ...................................................... 43-3
44 — GLT2 unit data sheet 44-1

44.1 Identification ........................................................................... 44-2
44.4 Optical budgets......................................................................... 44-4
44.5 Status LEDs .............................................................................. 44-4
44.7 Power .................................................................................... 44-7
45 — GLT4 unit data sheet 45-1

45.1 Identification ........................................................................... 45-2
45.4 Optical budgets......................................................................... 45-3
45.5 Status LEDs .............................................................................. 45-3
45.7 Power .................................................................................... 45-5
46 — GLT8 and pluggable optical modules unit data sheet 46-1

46.1 Identification ........................................................................... 46-2
46.4 Optical budgets......................................................................... 46-4
46.5 Status LEDs .............................................................................. 46-4
46.7 Power .................................................................................... 46-7
46.9 Constraints .............................................................................. 46-8
47 — LT card unit data sheet 47-1

47.1 Identification ........................................................................... 47-2
47.4 Optical budgets for GLTx cards ...................................................... 47-3
xliv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
47.5 Status LEDs .............................................................................. 47-4

47.7 Power .................................................................................... 47-5
48 — NT card unit data sheet 48-1

48.1 Identification ........................................................................... 48-2
Optical module power and modulation frequencies ........................... 48-3
Optical budgets...................................................................... 48-4
48.5 Interfaces and connectors .......................................................... 48-17
48.6 Status LEDs ............................................................................ 48-17
48.7 Power .................................................................................. 48-17
48.9 Supported diagnostic parameters per SFP or XFP ............................... 48-18
49 — OLT rack unit data sheet 49-1

49.1 Identification ........................................................................... 49-2
50 — OLTS-M unit data sheet 50-1

50.1 Identification ........................................................................... 50-2
50.4 Backplane connectors and cables ................................................... 50-5
50.5 Physical location identification ...................................................... 50-6
50.6 Power distribution ..................................................................... 50-6
50.7 Thermal limitation ..................................................................... 50-7
P-OLT thermal defense for individual card protection ........................ 50-8
P-OLT thermal defense in FGU 4.6 and later systems ....................... 50-10
Front cover ......................................................................... 50-12
Fiber management shelf ......................................................... 50-13
Specifications ...................................................................... 50-13
51 — SANC-D unit data sheet 51-1

51.1 Identification ........................................................................... 51-2
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xlv

Contents
52 — Racks for video coupler unit data sheet 52-1

52.1 Identification ........................................................................... 52-2
Tyco ................................................................................... 52-2
LGX .................................................................................... 52-5
53 — Tyco video coupler subrack unit data sheet 53-1

53.1 Identification ........................................................................... 53-2
54 — Tyco VCS8-A unit data sheet 54-1

54.1 Identification ........................................................................... 54-2
54.4 Optical safety........................................................................... 54-3
54.5 Environment requirements ........................................................... 54-3
54.6 Connections ............................................................................. 54-4
55 — Tyco VCW4-A unit data sheet 55-1

55.1 Identification ........................................................................... 55-2
55.4 Optical safety........................................................................... 55-3
55.6 Connections ............................................................................. 55-3
56 — VCSL-A LGX unit data sheet 56-1

56.1 Identification ........................................................................... 56-2
56.4 Alarms.................................................................................... 56-3
56.5 Connections ............................................................................. 56-3
57 — LGX VCW2 unit data sheet 57-1

57.1 Identification ........................................................................... 57-2
57.4 Optical budget.......................................................................... 57-3
57.5 Optical safety........................................................................... 57-4
57.7 Connections ............................................................................. 57-5
xlvi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Glossary
Index
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xlvii

Contents
List of figures
Figure 1 ESD warning label .......................................................................... xi
Figure 2 Hazardous voltage warning label ........................................................ xi
Figure 3 Laser product label ........................................................................ xi
Figure 4 Laser classification label ................................................................. xii
Figure 5 Laser warning labels ..................................................................... xiii
Figure 6 Supply wire protective earth terminal ................................................ xiii
Figure 7 Earth terminal ............................................................................ xiii
Figure 8 Label for earth bonding point ...........................................................xix
Figure 1 Products below MCV value label ....................................................... xxii
Figure 2 Products above MCV value label ...................................................... xxiii
Figure 3 Recycling/take back/disposal of product symbol ................................... xxv
Figure 1-1 7342 ISAM FTTU GPON network topology .......................................... 1-3
Figure 1-2 Mobile backhaul network architecture ............................................. 1-7
Figure 5-1 P-OLT functional blocks with EXNT and GLT8-A .................................. 5-3
Figure 5-2 P-OLT functional blocks with an EHNT ............................................. 5-3
Figure 5-3 P-OLT functional blocks with an EXNT.............................................. 5-4
Figure 6-1 Rack mounted ATRU-M and P-OLT (ALTS-N) with cover attached.............. 6-3
Figure 6-2 Rack mounted ATRU-U and P-OLT (OLTS-M) ....................................... 6-4
Figure 6-3 OLT shelf with cards, fan tray, and fiber routing tray installed................ 6-5
Figure 6-4 OLTS-M shelf with cards installed ................................................... 6-6
Figure 6-5 Tyco video coupler fiber rack ....................................................... 6-11
Figure 7-1 AACU-C craft and Ethernet connections............................................ 7-2
Figure 7-2 ALTS-N backplane craft and Ethernet connections ............................... 7-3
Figure 7-3 OLTS-M backplane craft and Ethernet connections............................... 7-4
Figure 9-1 Alarm storm prevention............................................................... 9-3
Figure 10-1 IP address assignment with DHCPv4 .............................................. 10-4
Figure 13-1 Loopbacks............................................................................. 13-5
Figure 13-2 Ethernet OAM components ......................................................... 13-6
Figure 13-3 CC messages on ONTs ............................................................... 13-8
Figure 13-4 Link trace test sequence ........................................................... 13-9
Figure 13-5 Loopback test sequence .......................................................... 13-10
Figure 13-6 SES switch local SNI scenario .................................................... 13-11
Figure 14-1 IGMP infrastructure ................................................................. 14-5
Figure 14-2 IGMP half-proxy mode .............................................................. 14-9
Figure 14-3 IGMP snoop versus IGMP proxy .................................................. 14-10
Figure 14-4 IPoE subscriber access network architecture and signaling flow........... 14-11
Figure 14-5 Processing flow in IPoE half-proxy mode ...................................... 14-13
Figure 14-6 PPPoE subscriber access network architecture and signaling flow ........ 14-14
Figure 14-7 Processing flow in PPPoE half-proxy mode .................................... 14-16
Figure 14-8 IGMP SSM configuration........................................................... 14-18
Figure 14-9 Processing of IGMP messages at the ONT ...................................... 14-22
Figure 14-10 Processing of join messages on the LT card ................................. 14-24
Figure 14-11 Multicast source, multicast stream, and channel ........................... 14-32
Figure 14-12 Package example with sample subscribers................................... 14-32
Figure 14-13 Steps for creating multicast packages and providing access to
subscribers ..................................................................... 14-33
Figure 15-1 GLT4-A functional blocks........................................................... 15-3
Figure 15-2 EXNT-A functional components.................................................... 15-4
Figure 15-3 ONT building blocks ................................................................. 15-5
xlviii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Figure 15-4 ONT UNI to bridge port mapping .................................................. 15-6

Figure 15-5 T-CONT per Service with GEM port per subscriber ........................... 15-25
Figure 16-1 Single bridge port network topology ............................................. 16-2
Figure 16-2 Multiple bridge port network topology........................................... 16-3
Figure 16-3 Multiple upstream switches ........................................................ 16-4
Figure 16-4 Redundant uplinks to upstream switches ........................................ 16-4
Figure 16-5 Multi uplink protection to upstream switches .................................. 16-5
Figure 18-1 QoS infrastructure ................................................................... 18-3
Figure 18-2 C-VLAN to S-VLAN p-bit translation at the LT................................... 18-6
Figure 18-3 One-to-one p-bit translation, single-tagged frames ........................... 18-7
Figure 18-4 Many-to-one p-bit translation, single-tagged frames .......................... 18-7
Figure 18-5 Downstream scheduling and rate limiting at the LT ......................... 18-14
Figure 18-6 Per-ONT downstream rate limiting ............................................. 18-16
Figure 18-7 Per-service downstream rate limiting .......................................... 18-16
Figure 18-8 T-CONT per service model ....................................................... 18-19
Figure 18-9 T-CONTs and GEM ports .......................................................... 18-20
Figure 18-10 T-CONT per subscriber/per service model ................................... 18-20
Figure 18-11 Downstream queuing from EMAN to subscriber ............................. 18-29
Figure 18-12 Downstream queuing and scheduling at the ONT ........................... 18-32
Figure 18-13 Upstream queuing from subscriber to EMAN ................................. 18-33
Figure 18-14 Upstream scheduling at the ONT .............................................. 18-34
Figure 19-1 Collection points for frame statistics ............................................ 19-4
Figure 19-2 Collection points for network port, VLAN, and SHub statistics .............. 19-5
Figure 19-3 OLT backplane thresholds and LINKERR alarms............................... 19-15
Figure 20-1 7342 ISAM FTTU and network security features ................................ 20-2
Figure 20-2 RADIUS on the NT and SHub........................................................ 20-5
Figure 20-3 RADIUS operator authentication .................................................. 20-6
Figure 20-4 SSHv2 security........................................................................ 20-8
Figure 20-5 Syslog system....................................................................... 20-15
Figure 20-6 IPSec internal protocol suite..................................................... 20-18
Figure 20-7 ONT packet authorization ........................................................ 20-20
Figure 21-1 Example of VLAN .................................................................... 21-3
Figure 21-2 Residential bridge VLAN model.................................................... 21-5
Figure 21-3 C-VLAN cross-connection model................................................... 21-6
Figure 21-4 S/C-VLAN CC configuration example ............................................. 21-9
Figure 21-5 Network topology of the VLAN per subscriber model for two
subscribers ..................................................................... 21-11
Figure 21-6 VLAN per business ONT subscriber connection................................ 21-12
Figure 21-7 VLAN per service model .......................................................... 21-13
Figure 21-8 VLAN per service model with shared S-VLAN for VoIP ....................... 21-14
Figure 21-9 VLAN per service model for the business ONT ................................ 21-14
Figure 21-10 Tagging of an Ethernet frame .................................................. 21-15
Figure 21-11 Cross-connect VLAN in stacked VLAN mode.................................. 21-17
Figure 21-12 VLAN translation mode example............................................... 21-20
Figure 21-13 EtherType classification mode ................................................. 21-22
Figure 21-14 Translation algorithm in VLAN translation mode............................ 21-33
Figure 21-15 Tagging of upstream traffic in VLAN translation mode with
EtherType classification...................................................... 21-35
Figure 21-16 CAC bandwidth check ........................................................... 21-39
Figure 22-1 Voice gateway network topology ................................................. 22-5
Figure 22-2 Softswitch network topology ...................................................... 22-7
Figure 22-3 Call flow of a SIP call originating from the ONT .............................. 22-13
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xlix

Contents
Figure 22-4 Call flow of a SIP call terminated at the ONT................................. 22-14
Figure 22-5 VEIP and the relationship to TR-069 ............................................ 22-15
Figure 22-6 VEIP configuration inputs......................................................... 22-16
Figure 22-7 Dual SIP upstream and downstream tagging .................................. 22-17
Figure 22-8 Dual SIP DHCP request process .................................................. 22-17
Figure 22-9 TR-069 configuration process flow.............................................. 22-18
Figure 22-10 XML data application to ONT and MDUs. ..................................... 22-23
Figure 23-1 Delivery of data services across the TPSDA ..................................... 23-2
Figure 23-2 HSI service configuration elements in a networking topology................ 23-4
Figure 23-3 Relationships among HSI elements................................................ 23-5
Figure 23-4 Upstream traffic queuing for single priority queue profile ................... 23-8
Figure 23-5 Upstream traffic queuing with two priority queue profiles................... 23-9
Figure 24-1 1550 nm and 1490 nm RF overlay on the 7342 ISAM FTTU .................... 24-3
Figure 24-2 RF video service in 7342 ISAM FTTU .............................................. 24-4
Figure 25-1 7342 ISAM FTTU service delivery .................................................. 25-3
Figure 25-2 7342 ISAM FTTU service delivery architecture .................................. 25-4
Figure 25-3 Architectural elements of a router ............................................... 25-5
Figure 25-4 IP/MPLS network..................................................................... 25-6
Figure 25-5 7342 ISAM FTTU access network .................................................. 25-8
Figure 25-6 7342 ISAM FTTU equipment ...................................................... 25-12
Figure 25-7 Syslog system....................................................................... 25-16
Figure 25-8 Implementation of IGMP across the service delivery architecture ........ 25-26
Figure 25-9 Service delivery across the 7342 ISAM FTTU access network ............... 25-31
Figure 25-10 Subscriber service provisioning example ..................................... 25-32
Figure 25-11 Configuration entities in configuration examples........................... 25-33
Figure 25-12 SHub VLAN......................................................................... 25-45
Figure 26-1 Layer 2 and layer 3 CES service configuration .................................. 26-2
Figure 26-2 CES DS1 or E1 traffic between the ONT and PSTN over the GPON via
the P-OLT......................................................................... 26-3
Figure 26-3 CES over IP DS1 or E1 traffic....................................................... 26-5
Figure 26-4 Structured TDM frames encapsulated into CES MEF-8 packets ............... 26-7
Figure 26-5 Unstructured TDM traffic encapsulated into CES MEF-8 packets............. 26-7
Figure 27-1 Network example of micro span collocated with 7342 ISAM FTTU........... 27-2
Figure 27-2 CES VLAN example using micro span, 7342 ISAM FTTU, and ONTs ........... 27-3
Figure 28-1 Metro Ethernet services model .................................................... 28-4
Figure 28-2 Example of MEN...................................................................... 28-5
Figure 28-3 Point-to-point EVC .................................................................. 28-7
Figure 28-4 Multipoint-to-multipoint EVC ...................................................... 28-7
Figure 28-5 Rooted-multipoint EVC ............................................................. 28-8
Figure 28-6 Ethernet service element relationships .......................................... 28-9
Figure 28-7 EVC and Ethernet services configuration ...................................... 28-10
Figure 28-8 Internal EVC with bundling and single CoS .................................... 28-13
Figure 28-9 Internal EVC with all-to-one bundling and single CoS ....................... 28-14
Figure 31-1 AACU front and side views ......................................................... 31-4
Figure 32-1 Front, top, and side views of the AFAN-H fan unit............................. 32-3
Figure 32-2 AFAN-H front panel.................................................................. 32-3
Figure 32-3 AFAN-H back panel .................................................................. 32-3
Figure 32-4 Fan and cable assembly ............................................................ 32-4
Figure 33-1 Front view of the AFAN-S fan unit ................................................ 33-3
Figure 34-1 ALTS-N shelf with P-OLT cards and components ............................... 34-3
Figure 34-2 ALTS-N backplane ................................................................... 34-5
Figure 34-3 ALTS-N shelf .......................................................................... 34-8
l October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Figure 35-1 ATRU-M AA variant front panel .................................................... 35-3

Figure 35-2 PBA-ATRU-G connector and jumper locations .................................. 35-5
Figure 36-1 Diagram of ATRU-N for fixed shelf powering (up to two ALTS-N
shelves) ........................................................................... 36-4
Figure 36-2 Parts of the ATRU-N................................................................. 36-5
Figure 36-3 ATRU-N front panel ................................................................. 36-5
Figure 36-4 ATRU-N front panel LEDs ........................................................... 36-6
Figure 36-5 Power-input terminal blocks (two fabrication variants)....................... 36-7
Figure 36-6 Power connection of P-OLT rack to PDF ......................................... 36-9
Figure 36-7 Layout of the ATRU-G board (jumpers factory set) .......................... 36-11
Figure 36-8 D-SUB 37-pin connector .......................................................... 36-12
Figure 36-9 D-SUB 50-pin connector .......................................................... 36-14
Figure 37-1 ATRU-U front panel ................................................................. 37-3
Figure 37-2 PBA-ATRU-G connector and jumper locations .................................. 37-5
Figure 38-1 BITS-B card ........................................................................... 38-2
Figure 41-1 Front view of EHNT-A ............................................................... 41-9
Figure 41-2 Front view of EHNT-B ............................................................... 41-9
Figure 42-1 Front view of EXNT-A ............................................................... 42-8
Figure 43-1 FILT-A on the ALTS-N backplane .................................................. 43-3
Figure 43-2 Caution label on the shelf backplane ............................................ 43-4
Figure 44-1 Front view of the GLT2-A card .................................................... 44-5
Figure 44-2 Side view of the GLT2-A card...................................................... 44-6
Figure 45-1 Front view of the GLT4 card ....................................................... 45-4
Figure 45-2 Side view of the GLT4 card ........................................................ 45-5
Figure 46-1 Front view of the GLT8 card ....................................................... 46-6
Figure 46-2 Side view of the GLT8 card ........................................................ 46-7
Figure 48-1 Optical and electrical SFP module components ................................ 48-3
Figure 48-2 Electrical SFP in an NT card ....................................................... 48-3
Figure 50-1 OLTS-M shelf with P-OLT cards and 19in. mounting ears...................... 50-4
Figure 50-2 OLTS-M backplane ................................................................... 50-5
Figure 52-1 Video coupler fiber rack............................................................ 52-4
Figure 52-2 Rack for video coupler and recommended layout .............................. 52-6
Figure 53-1 Video coupler subrack, front view ................................................ 53-2
Figure 53-2 Open VCS with 5 trays .............................................................. 53-3
Figure 54-1 VCS8 tray ............................................................................. 54-4
Figure 55-1 VCW4 tray and connectors ......................................................... 55-4
Figure 56-1 VCSL-A shelf .......................................................................... 56-3
Figure 57-1 VCW2-C................................................................................ 57-3
Figure 57-2 VCW2-C input and output connectors ............................................ 57-5
List of tables
Table 1-1 ONT support information for extended PON operation ............................ 1-5
Table 2-1 Features for FGU 04.09.00 ............................................................. 2-3
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 li

Contents

Table 2-10 Features for FGU 04.07.00........................................................... 2-14
Table 2-11 Features for Release 04.06.06 ...................................................... 2-16
Table 2-12 Features for FGU 04.06.04........................................................... 2-17
Table 2-13 Features for Release 04.06.00 and 04.06.01...................................... 2-17
Table 4-1 Application notes for FGU 04.04.xx................................................... 4-2
Table 4-2 Application notes for FGU 4.3.5....................................................... 4-3
Table 4-3 Application notes for FGU 4.3.0....................................................... 4-3
Table 4-4 Application notes for FGU 4.2 ......................................................... 4-4
Table 6-1 Optical modules ......................................................................... 6-8
Table 8-1 P-OLT components ...................................................................... 8-2
Table 8-2 Installable and field-replaceable cards .............................................. 8-3
Table 8-3 P-OLT unit weight specifications...................................................... 8-3
Table 8-4 Video coupler equipment .............................................................. 8-4
Table 8-5 Service and system capacity ........................................................... 8-5
Table 8-6 Maximum number of UNI ports per LT card type .................................. 8-11
Table 8-7 Maximum UNI ports by UNI type per LT card....................................... 8-12
Table 8-8 P-OLT optical budgets ................................................................. 8-13
Table 8-9 P-OLT environmental requirements ................................................. 8-14
Table 8-10 Video coupler environmental requirements ...................................... 8-14
Table 8-11 P-OLT input voltage................................................................... 8-15
Table 8-12 P-OLT power consumption ........................................................... 8-15
Table 10-1 DHCP relay agent parameters ....................................................... 10-5
Table 10-2 DHCP LDRA filtering rules............................................................ 10-7
Table 10-3 DHCPv6 packets ....................................................................... 10-8
Table 10-4 DHCPv6 header ........................................................................ 10-9
Table 10-5 DHCPv6 messages ..................................................................... 10-9
Table 10-6 DHCpv6 options...................................................................... 10-10
Table 11-1 Vendor-specific tag format for PPPoE discover protocol messages ........... 11-3
Table 12-1 ICMPv6 secure filtering forwarding behaviors .................................... 12-2
Table 12-2 ICMPv6 packets ........................................................................ 12-3
Table 12-3 IMCPv6 messages ...................................................................... 12-3
Table 12-4 IMCPv6 options ........................................................................ 12-4
Table 13-1 Ethernet OAM components .......................................................... 13-7
Table 13-2 Ethernet OAM supported tools ...................................................... 13-7
Table 14-1 IP multicast features ................................................................. 14-3
Table 14-2 IGMP message types .................................................................. 14-5
Table 14-3 Processing limits .................................................................... 14-26
Table 14-4 Wholesale video through residential-bridging .................................. 14-35
Table 15-1 Unicast frame forwarding rules ..................................................... 15-7
Table 15-2 Rules for learning MAC addresses................................................... 15-7
Table 15-3 Summary of learned C-VLAN ID limits.............................................. 15-8
Table 15-4 Upstream layer 2 forwarding with C-VLAN learning mode.................... 15-14
Table 15-5 Forwarding model summary on the LT........................................... 15-16
Table 15-6 Residential bridge LT card configuration parameters ......................... 15-19
Table 15-7 Residential bridge system configuration parameters.......................... 15-19
Table 15-8 C-VLAN learning hardware limitations ........................................... 15-20
lii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Table 15-9 Cross-connect configuration parameters ........................................ 15-21

Table 15-10 Per-PON allocation of resources................................................. 15-25
Table 15-11 Subscriber scaling based on T-CONT and GEM usage......................... 15-25
Table 18-1 QoS infrastructure elements ........................................................ 18-3
Table 18-2 Scheduling of queues at the NT by weighting factor .......................... 18-12
Table 18-3 Scheduling of queues at the GLT2 by weighting factor ....................... 18-12
Table 18-4 Default traffic scheduler at the GLT2 ........................................... 18-12
Table 18-5 Upstream scheduling of queues at the ONT by weighting factor ............ 18-17
Table 18-6 T-CONT models ...................................................................... 18-18
Table 18-7 MinBW for Delay Tolerance ........................................................ 18-24
Table 18-8 Bandwidth types..................................................................... 18-25
Table 18-9 Allocation of bandwidth by T-CONT type ....................................... 18-26
Table 18-10 T-CONT prioritization ............................................................. 18-27
Table 18-11 QoS elements by configuration task ............................................ 18-28
Table 18-12 VLAN configurations ............................................................... 18-29
Table 18-13 Forwarding classes................................................................. 18-36
Table 18-14 Recommended CoS mapping ..................................................... 18-36
Table 19-1 15-min counters ....................................................................... 19-3
Table 19-2 Rolling counters ....................................................................... 19-6
Table 19-3 7342 ISAM FTTU supported OLT GPON TC-layer performance monitoring
counters .......................................................................... 19-8
Table 19-4 7342 ISAM FTTU supported VLAN performance monitoring counters ......... 19-9
Table 19-5 7342 ISAM FTTU supported OLT LT bridge port performance monitoring
counters .......................................................................... 19-9
Table 19-6 7342 ISAM FTTU supported OLT GPON network port performance
monitoring counters .......................................................... 19-10
Table 19-7 7342 ISAM FTTU supported OLT IGMP performance monitoring
counters ........................................................................ 19-12
Table 19-8 OLT backplane error performance monitoring statistics...................... 19-14
Table 19-9 RMON Ethernet statistics and definitions........................................ 19-15
Table 20-1 SSH and SNMPv3 security combinations............................................ 20-9
Table 20-2 Lockout times for failed login attempts ......................................... 20-10
Table 20-3 IPSec protocol suite................................................................. 20-17
Table 20-4 Anti-spoofing control types and traffic exemptions ........................... 20-21
Table 21-1 Tagging options for upstream and downstream VLAN traffic .................. 21-2
Table 21-2 Tagging specifications for mirror packets ....................................... 21-10
Table 21-3 Features of flow mirroring VLANs ................................................ 21-10
Table 21-4 P-bit marking mode ................................................................. 21-18
Table 21-5 Compatible configurations for p-bit marking mode ........................... 21-18
Table 21-6 VLAN translation configuration example ........................................ 21-20
Table 21-7 VLAN translation and EtherType classification for upstream
forwarding...................................................................... 21-21
Table 21-8 VLAN translation and EtherType classification for downstream
forwarding...................................................................... 21-21
Table 21-9 Downstream tagging at the LT .................................................... 21-24
Table 21-10 Downstream tagging at the LT in stacked VLAN mode....................... 21-25
Table 21-11 Downstream tagging at the LT in unstacked VLAN mode.................... 21-25
Table 21-12 Downstream tagging at the LT in VLAN pass-through mode ................ 21-26
Table 21-13 Upstream tagging at the LT ...................................................... 21-26
Table 21-14 Upstream tagging at the LT in stacked VLAN mode .......................... 21-27
Table 21-15 Upstream tagging at the LT in unstacked VLAN mode ....................... 21-28
Table 21-16 Upstream tagging at the LT in VLAN pass-through mode .................... 21-28
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 liii

Contents
Table 21-17 Downstream tagging at the ONT ................................................ 21-30

Table 21-18 P-bit marking rules for untagged frames....................................... 21-31
Table 21-19 Upstream tagging at the ONT in the untrusted mode........................ 21-31
Table 21-20 Upstream tagging at the ONT in the VLAN pass-through mode............. 21-32
Table 21-21 Upstream tagging at the ONT in VLAN translation mode .................... 21-34
Table 21-22 Upstream tagging at the ONT in VLAN translation mode with
EtherType classification...................................................... 21-36
Table 21-23 Upstream tagging at the ONT in EtherType classification mode ........... 21-36
Table 21-24 Upstream tagging at the ONT in flexible mode ............................... 21-38
Table 21-25 VLAN bridging scalability ......................................................... 21-42
Table 22-1 Common features of VoIP service operation modes ............................. 22-3
Table 22-2 SIP service features ................................................................... 22-9
Table 22-3 ETSI call feature configuration.................................................... 22-12
Table 22-4 Restrictions to configure an ONT VEIP port ..................................... 22-15
Table 22-5 Sources of SIP configuration data................................................. 22-19
Table 22-6 Voice gateway mode considerations ............................................. 22-20
Table 22-7 DHCP options and VoIP modes .................................................... 22-21
Table 22-8 SIP data model profiles............................................................. 22-24
Table 22-9 Vendor profile (CDE) provisioning parameters.................................. 22-25
Table 22-10 SIP protocol parameters .......................................................... 22-25
Table 22-11 Identity provisioning parameters................................................ 22-32
Table 22-12 Analog local network profile provisioning parameters....................... 22-34
Table 22-13 Media local network profile provisioning parameters........................ 22-37
Table 22-14 Service data provisioning parameters per port ............................... 22-41
Table 22-15 ONT digit map elements, symbols, and modifiers for package C, D, E,
F, and G ONTs ................................................................. 22-65
Table 22-16 ONT digit map elements, symbols, and modifiers for package A, B,
and H ONTs ..................................................................... 22-69
Table 22-17 Collected VoIP call statistics using OMCIv1 .................................... 22-73
Table 22-18 Package A, B, and H call-related performance monitoring statistics...... 22-75
Table 23-1 HSI service configuration elements ................................................ 23-4
Table 23-2 Relationships among HSI elements ................................................. 23-6
Table 23-3 Tagging modes ......................................................................... 23-9
Table 24-1 RF and MoCA channel breakdown................................................... 24-3
Table 25-1 IP edge aggregation and routing architectural elements ....................... 25-6
Table 25-2 7342 ISAM FTTU access network architectural elements ....................... 25-9
Table 25-3 Functional areas of the 7342 ISAM FTTU ........................................ 25-10
Table 25-4 QoS profiles .......................................................................... 25-17
Table 25-5 Layer 2 forwarding differences between NT and LT........................... 25-23
Table 25-6 MAC learning and C-VLAN learning on the LT................................... 25-24
Table 25-7 ONT UNI ports........................................................................ 25-32
Table 25-8 P-OLT equipment parameter values ............................................. 25-37
Table 25-9 Multicast source parameter values ............................................... 25-43
Table 25-10 ONT equipment parameter values .............................................. 25-44
Table 25-11 HSI service and IGMP signaling channel parameter values .................. 25-48
Table 25-12 VoIP service parameter values................................................... 25-50
Table 26-1 Voice, data, and video service options ............................................ 26-3
Table 26-2 Business ONT features ................................................................ 26-4
Table 26-3 Voice, data, and video service options ............................................ 26-5
Table 26-4 DS1 and E1 framing ................................................................. 26-10
Table 26-5 DS1 and E1 line encoding .......................................................... 26-10
Table 26-6 Line lengths supported for DS1 and DSX-1 ...................................... 26-11
liv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Table 28-1
Functionality supported by Ethernet services .................................... 28-2
Table 28-2
EVC and Ethernet service configuration elements ............................. 28-11
Table 28-3
Configuration for internal EVCs with bundling and single CoS ............... 28-13
Table 28-4
Configuration for internal EVCs with bundling and multiple CoSs ........... 28-14
Table 28-5
Configuration for internal EVCs with all-to-one bundling and single
CoS............................................................................... 28-15
Table 28-6 Configuration for internal EVCs with all-to-one bundling and multiple
CoSs ............................................................................. 28-15
Table 28-7 Configuration for external EVCs with one T-CONT per EVC .................. 28-16
Table 28-8 Configuration for external EVCs with one T-CONT per COS .................. 28-17
Table 28-9 Maximum number of portals per GLT card and system ....................... 28-18
Table 28-10 Ethernet services support for ONT types....................................... 28-18
Table 28-11 EVC configuration constraints ................................................... 28-19
Table 29-1 GENIP service configuration elements ............................................. 29-2
Table 30-1 Overview of unit data sheets for the 7342 ISAM FTTU .......................... 30-2
Table 30-2 Alphabetical list of unit data sheets by description ............................. 30-3
Table 31-1 Identification of ACCU-C ............................................................. 31-2
Table 31-2 Alarm LEDs ............................................................................. 31-6
Table 31-3 DB-9 connector pin assignment ..................................................... 31-7
Table 31-4 NT interface ........................................................................... 31-7
Table 31-5 AACU physical specifications ........................................................ 31-8
Table 32-1 Identification of AFAN-H ............................................................. 32-2
Table 32-2 AFAN-H physical specifications ..................................................... 32-5
Table 33-1 Identification of AFAN-S.............................................................. 33-2
Table 33-2 Status LED indications ................................................................ 33-3
Table 33-3 AFAN-S physical specifications ...................................................... 33-4
Table 34-1 Identification of ALTS-N.............................................................. 34-2
Table 34-2 Backplane connectors and related cables ......................................... 34-5
Table 34-3 Power and grounding signals ........................................................ 34-7
Table 34-4 Physical specifications of the ALTS-N .............................................. 34-9
Table 35-1 Identification of ATRU-M............................................................. 35-2
Table 35-2 Front panel LED indicators........................................................... 35-3
Table 35-3 CO connector pin layout ............................................................. 35-5
Table 35-4 ATRU-M physical specifications ..................................................... 35-6
Table 36-1 Identification of ATRU-N ............................................................. 36-2
Table 36-2 Front panel LEDs ...................................................................... 36-6
Table 36-3 Power input connection and grounding provisions ............................... 36-8
Table 36-4 PDF circuit breaker rating and power cable sections.......................... 36-10
Table 36-5 Pin layout of CO interface connector ............................................ 36-12
Table 36-6 Pin layout of ACU/FAN alarm connectors ....................................... 36-14
Table 36-7 Factory jumper settings............................................................ 36-16
Table 36-8 Application-dependent jumper setting .......................................... 36-16
Table 36-9 ATRU-N dimensions ................................................................. 36-17
Table 36-10 Physical specifications of the ATRU-N .......................................... 36-18
Table 37-1 Identification of ATRU-U ............................................................. 37-2
Table 37-2 Front panel LED indicators........................................................... 37-3
Table 37-3 Lamp rack connector (X311)......................................................... 37-5
Table 37-4 Door alarm connector (X312)........................................................ 37-6
Table 37-5 ATRU-U physical specifications ..................................................... 37-6
Table 38-1 Identification of BITS-B .............................................................. 38-2
Table 39-1 Identification of the blank LT filler plate ......................................... 39-2
Table 39-2 Dimensions of the LT filler plate ................................................... 39-3
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 lv

Contents
Table 40-1 Identification of the blank NT filler plate......................................... 40-2

Table 40-2 Dimensions of the NT filler plate ................................................... 40-2
Table 41-1 Identification of EHNT-A and the associated optical modules ................. 41-2
Table 41-2 Specific information for 1AB 35663 00XX modules............................... 41-5
Table 41-3 Specific information for 3FE 25771 XX CWDM modules ......................... 41-6
Table 41-4 EHNT port LEDs ...................................................................... 41-10
Table 41-5 EHNT diagnostic LEDs............................................................... 41-10
Table 41-6 EHNT physical specifications ...................................................... 41-11
Table 42-1 Identification of EXNT-A and the associated optical modules ................. 42-2
Table 42-2 Specific information for 3FE 25771 XX CWDM modules ......................... 42-5
Table 42-3 EXNT-A UNIT LEDs ..................................................................... 42-8
Table 42-4 NETWORK and O&M LEDs............................................................. 42-9
Table 42-5 EXNT-A physical specifications...................................................... 42-9
Table 43-1 Identification of FILT-A and FILT-B................................................. 43-2
Table 43-2 Signal identification .................................................................. 43-3
Table 43-3 FILT-A physical specifications ....................................................... 43-4
Table 43-4 FILT-B physical specifications ....................................................... 43-4
Table 44-1 Identification of GLT2 ................................................................ 44-2
Table 44-2 GLT2-A, GLT2-B and GLT2-C differences .......................................... 44-3
Table 44-3 GLT2 LEDs .............................................................................. 44-4
Table 44-4 GLT2 physical specifications ........................................................ 44-7
Table 45-1 Identification of GLT4 ................................................................ 45-2
Table 45-2 GLT4 LEDs .............................................................................. 45-4
Table 46-1 Identification of GLT8 and the associated optical modules .................... 46-2
Table 46-2 GLT8 LEDs .............................................................................. 46-4
Table 47-1 LT card identification information ................................................. 47-2
Table 47-2 LT card features and application notes............................................ 47-2
Table 47-3 LT card general description ......................................................... 47-3
Table 47-4 Optical budgets of the GLTx cards ................................................. 47-3
Table 47-5 LT card LEDs ........................................................................... 47-4
Table 47-6 LT card interfaces and connections ................................................ 47-5
Table 47-7 LT card physical specifications...................................................... 47-5
Table 48-1 NT card identification information ................................................. 48-2
Table 48-2 NT card features and application notes ........................................... 48-2
Table 48-3 NT card general description ......................................................... 48-2
Table 48-4 Power propagation and modulation frequencies of optical modules ......... 48-4
Table 48-5 Optical budgets for the 1-GE SFP (upstream),1310 nm tx, 1490 nm rx,
SMF, 10 km (3FE 25772 AA) .................................................... 48-5
Table 48-6 Optical budgets for the 1-GE SFP (downstream),1310 nm tx, 1490 nm
rx, SMF, 10 km (3FE 25772 AB) ................................................ 48-5
Table 48-7 Optical budgets for the 1-GE SFP, 850 nm, MMF, 550 m, temperature
hardened (3FE 25773 AA) ...................................................... 48-6
Table 48-8 Optical budgets for the 1-GE 850 nm 550 m SFP (3FE 25773 CA).............. 48-7
Table 48-9 Optical budgets for the 1-GE 1310 nm 10 km SFP (3FE 25774 AA) ............ 48-7
Table 48-10 Optical budgets for the 1-GE 1310 nm 40 km SFP (3FE 25775 AA) ........... 48-8
Table 48-11 Optical budgets for the 1-GE 1550 nm 80 km SFP (3FE 25776 AA) ........... 48-8
Table 48-12 Optical budgets for the 1-GE 1550 nm 80 km SFP (3FE 25776 BA) ........... 48-9
Table 48-13 Optical budgets for the 1-GE 1310 nm Tx/1550 nm Rx, 40 km SFP (3FE
28785 AA)......................................................................... 48-9
lvi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Contents
Table 48-14 Optical budgets for the 1-GE 1550 nm Tx/1310 nm Rx 40 km SFP (3FE
28785 AB) ....................................................................... 48-10
Table 48-15 Optical budgets for the 1-GE SFP (upstream),1310 nm tx, 1490 nm
rx, SMF, 40 km (3FE 65571 AA).............................................. 48-11
Table 48-16 Optical budgets for the 1-GE SFP (downstream),1310 nm tx, 1490 nm
rx, SMF, 40 km (3FE 65571 AB) .............................................. 48-11
Table 48-17 Optical budgets for the 1-GE SFP, CWDM, SMF, 80 km (3FE 25771 Dx) ... 48-12
Table 48-18 Optical budgets for the 10-GE 850 nm 300 m XFP (3FE 50712 AA)......... 48-13
Table 48-19 Optical budgets for the 10-GE 1310 nm 10 km XFP (3FE 50712 BA and
3FE 50712 BB).................................................................. 48-13
Table 48-20 Optical budgets for the 10-GE 1550 nm 40 km XFP (3FE 50712 CA and
3FE 50712 CB).................................................................. 48-14
Table 48-21 Optical budgets for the 10-GE 1550 nm 80 km XFP (3FE 50712 DA) ....... 48-14
Table 48-22 Optical budgets for the 10-GE XFP, 100GHz DWDM, SMF, 80 km (1AB
35663 00xx) .................................................................... 48-15
Table 48-23 Wavelength information for the 10-GE XFP, 100GHz DWDM, SMF, 80
km (1AB 35663 00xx).......................................................... 48-15
Table 48-24 NT card interfaces and connections ............................................ 48-17
Table 48-25 NT card LEDs ....................................................................... 48-17
Table 48-26 NT card power information ...................................................... 48-17
Table 48-27 EHNT physical specifications..................................................... 48-18
Table 48-28 Supported diagnostics per SPF and XFP ........................................ 48-18
Table 49-1 Identification of the OLT rack assembly........................................... 49-2
Table 49-2 OLT rack assembly components list ................................................ 49-3
Table 49-3 Physical specifications of ETSI racks ............................................... 49-4
Table 50-1 Identification of OLTS-M ............................................................. 50-2
Table 50-2 Backplane connectors and related cables ......................................... 50-6
Table 50-3 Power and grounding signals ........................................................ 50-7
Table 50-4 Physical specifications of the OLTS-M ........................................... 50-13
Table 51-1 Identification of the SANC-D ........................................................ 51-2
Table 52-1 Identification of the rack for the video coupler.................................. 52-2
Table 52-2 Physical dimensions of the Tyco video coupler fiber rack ...................... 52-7
Table 52-3 54.82 cm (23 in) rack dimensions................................................... 52-7
Table 53-1 Identification of the subrack for video coupler .................................. 53-2
Table 54-1 Identification of VCS8-A.............................................................. 54-2
Table 54-2 Extreme rating for optical components ........................................... 54-4
Table 55-1 Identification of VCW4-A............................................................. 55-2
Table 56-1 Identification of VCSL-A.............................................................. 56-2
Table 56-2 Physical specifications ............................................................... 56-3
Table 57-1 Identification of VCW2-C............................................................. 57-2
Table 57-2 Optical budget of VCW2 connectors ............................................... 57-3
Table 57-3 Optical budget of WDM............................................................... 57-3
Table 57-5 VCW2 physical specifications........................................................ 57-5
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 lvii

Contents
List of procedures
Procedure 1 To download an CD-ROM ISO image or ZIP file package of the
7342 ISAM FTTU customer documentation ..................................... iv
Procedure 2 To access individual documents...................................................... v
Procedure 3 Example of options in a procedure ................................................. vi
Procedure 4 Example of required substeps in a procedure..................................... vi
Procedure 5 To search multiple PDF files for a common term................................. vi
lviii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

General system description
1 — Overview
2 — Feature descriptions
3 — R04.08.00 feature overview and configuration details
4 — Application notes
5 — Functional description
6 — Equipment layout
7 — Operations, administration, and maintenance
8 — Technical specifications
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013

October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00
1— Overview
1.1 7342 ISAM FTTU overview 1-2
1.2 GPON features 1-4
1.3 Service features 1-5
1.4 Network interfaces 1-9
1.5 Element management system 1-10
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 1-1

1 — Overview
1.1 7342 ISAM FTTU overview
The 7342 ISAM FTTU is a set of all-optical fiber-to-the-user systems that delivers
voice, data, and video services to residential and business subscribers. The
7342 ISAM FTTU collects and distributes high-speed digital information, using the
gigabit passive optical network (GPON) technology.
The 7342 ISAM FTTU consists of the following equipment:
• P-OLT: the packet optical line termination unit that provides central processing,
switching, and control functions
• V-OLT: the video optical line termination unit that distributes video signals
across the GPON
• ONT: the optical network terminal located at the subscriber premises
• EMS: the 5520 AMS element management system
Figure 1-1 shows the 7342 ISAM FTTU equipment deployed in a GPON network
topology.
1-2 October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

1 — Overview
Figure 1-1 7342 ISAM FTTU GPON network topology
Network Central office or Fiber Passive ONTs End user

remote terminal distribution outside
plan
Optical link length 1
Optional RF
overlay
RF Video 1,550 nm
provider V-OLT/EDFA
network
IPTV
Ethernet MDU
1,490 nm
WDM 1,550 nm 2.4 Gb/s
Internet 1,310 nm 1.2 Gb/s

Edge switch
router P-OLT
PSTN
Voice
gateway
EMS/NMS
Class 5 Softswitch
switch
1 The maximum optical link length depends on the specific equipment and deployment conditions
21069
The GPON optical fiber network connecting the P-OLT and the ONTs is a passive
optical network (PON) with no active or powered elements. The G.984.x series of
standards define how traffic is packetized and transported over the GPON.
Each GPON network connection from the P-OLT is a single optical fiber connection
that supports line rates of 2.4 Gb/s downstream and 1.2 Gb/s upstream as per the
ITU-T G.984 protocol.
Note — Video performance varies according to the unique

characteristics of the customer-specific setup, such as channel
loading, video backbone, and delivery service quality. Due to high
variations in customer requirements, contact your Alcatel-Lucent
sales representative to determine the guaranteed video performance
for your specific network and video application.

1 — Overview
The P-OLT supports up to a maximum of 32 GPON network connections.

The 7342 ISAM FTTU supports multiple services over the GPON, including: voice,
data, and video. Using the V-OLT, the 7342 ISAM FTTU supports standard cable
television video services, as well as analog and digital channels. The V-OLT
supports the full radio frequency (RF) spectrum of 47 MHz to 862 MHz.
1.2 GPON features
The 7342 ISAM FTTU provides the following GPON features:

• bidirectional voice, data, and IPTV services for a maximum of 64 outdoor, indoor
or business ONTs per PON
• forward error correction (FEC) on PON interface
• RF video distribution services that support analog and digital channels
• Raman reduction on PON interface for RF video service
• configuration support for Multimedia over Coaxial Alliance (MoCA) for ONTs
that support MoCA
• line rates of 2.488 Gb/s downstream and 1.244 Gb/s upstream
• a maximum of 37.3 miles (60 km) PON reach capacity
• GEM-based encapsulation on the GPON
• compliance with full service access network (FSAN) standards
Extended PON operation

The 7342 ISAM FTTU P-OLT equipment supports extended PON deployments that
allow you to configure each PON with the ability to provide a 20 km, 34 km, and a
40 km differential window for ranging and ONT operation depending on the optical
link budget supported by the LT card used, the PON reach specified based on
network deployments, and the loss of optical fiber, connectors, splitters, and so on.
The default operation of the PON is to operate over a 20 km reach capacity and the
maximum reach capacity is 60 km. TL1 commands can be used to enable this
differential window. When a new differential window is enabled, all ONTs on the
PON will re-range. You can extend the PON operation if the closest ONT parameter
is defined as ‘X’ km, so the ONTs on the PON will operate up to ‘X’km plus the
‘provisioned differential window’ km, where the total does not exceed 60 km. The
AMS GUI will also support the modification of the differential window.
Note — See 7342 ISAM FTTU Operations and Maintenance

Procedures Guide using TL1 and CLI for more information about
provisioning extended PON operation.
Table 1-1 shows the differential reach capabilities supported by the various types of
ONTs and their limitations.

1 — Overview
Table 1-1 ONT support information for extended PON operation
ONT type Deployment Limitations

differential
Package B ONTs and 20 km —

Package C ONTs and 34 km
MDUs
40 km
Package A ONTs 20 km If the PON is provisioned for a 40km differential

including SFU and 34 km window, the Package A ONTs can only reside on the
SOHO MoCA ONTs PON between 6 km and 40 km.
For a mixed PON (Package A and B), designated for a
40 km differential window option, the ONTs can be
deployed if between 6 km and 40 km from the closest
ONT.
Package A MDUs 20 km If MDUs operate with FGU 04.07.00 compatible

34 km software, all differential window options will be
supported.
40 km
34 km If MDUs do not operate with FGU 04.07.04 compatible

software, the PON deployment differential is
restricted from the farthest ONT designation for the
PON differential window.
If MDUs operate with pre-FGU 04.07.04 compatible
software, the PON must be deployed within the
defined differential reach capability to allow a
software upgrade to FGU 04.07.04.
1.3 Service features
The 7342 ISAM FTTU supports multiple services, including: voice, data and IPTV,
RF video, wireless mobile backhaul, and CES encapsulated DS1 or E1 over the
packet-switched network (PSN). A special service type, known as GENIP service, is
supported to allow provisioning of management channel related parameters on some
ONTs so that they can be managed directly via an EMS.
Voice service
The 7342 ISAM FTTU interoperates with both the traditional Class 5 switches over
the public switched telephone network (PSTN) and the softswitches over the
broadband data network to provide voice over IP (VoIP) service to subscribers. The
VoIP service supports protocols that include H.248/Megaco, and session initiation
protocol (SIP).
Data and IPTV services

The 7342 ISAM FTTU supports data and IPTV services that are delivered through
the same high-speed Ethernet interface. The IPTV service is provided in-band of the
Ethernet data service. Subscribers need a set-top box to use the IPTV service.

1 — Overview
RF video service
The 7342 ISAM FTTU supports RF video service. The RF video service supports the
full cable television (CATV) spectrum from 47 MHz to 862 MHz. The CATV
service options supported include: video on demand (VOD), interactive video for
games, and standard or premium analog and digital channels. Service provider
supplies and installs a set-top box at the subscriber premises for access to RF video
service.
Consider the following when planning video deployments:
• ONTs supporting video overlays only support a 1:4 split ratio
• The maximum supported length of RG9 or RG59 coax cable is 100 ft (30.48 m)
Wireless mobile backhaul services

The 7342 ISAM FTTU supports mobile backhaul services where a portion of the
network is dedicated to delivering traffic from mobile base stations (example, GSM,
UMTS, LTE) to network aggregation points (example, BSC). The framework for
mobile aggregation and backhaul transport of traffic from the cell site to the Mobile
Telephone Switching Office (MTSO) is based on Mobile Evolution Transport
Architecture (META) which integrates many mobile transport technologies. These
technologies support any type of access including; TDM/PDH, SDH/SONET,
Ethernet, ATM, IP/MPLS, Optical, Microwave, DSL, GPON, LTE radio, and IMS
for an end-to-end network architecture that provides seamless IP-based services such
as voice, video, multimedia and data. Wireless broadband services support all mobile
generations including 4G and beyond, with guaranteed QoS. Figure 1-2 shows the
mobile backhaul network architecture.

1 — Overview
Figure 1-2 Mobile backhaul network architecture
BTS Controllers
NodeB
ATM/IMA or T1/E1 TDM
ML-PPP
5520 AMS
BTS/NodeB/
WiMAX Ethernet
Ethernet
GPON GE
7705 SAR-M
7342 OLT 7450 7750
T1/E1 (TDM)
CES Dynamic MPLS PW with FRR/PW redundancy
CPE 5620 SAM

7705 SAR-M
T1/E1 (TDM)
CES
T1/E1 (TDM)
CES Ethernet
CPE
CPE CPE
21075
Note — In Figure 1-2, the 7342 ISAM FTTU can equally be a

7330 ISAM FTTN. For more information; see 7330 ISAM FTTN
Product Information.
The 7342 ISAM FTTU inter-operates with the following Alcatel-Lucent products to
support wireless mobile backhaul network services:
• 7705 SAR-M/ME
• 5520 AMS
• 5620 SAM
• 7450 ESS

1 — Overview
• 7750 SR
• 7330 ISAM FTTN GPON LT or 7342 ISAM FTTU O-010G-A GPON module
Note — For more information about these Alcatel-Lucent products

and how they inter-operate with 7342 ISAM FTTU, see the
following:
• 7705 SAR-M/ME GPON Module Installation Guide
• 5520 AMS User Guide
• 5620 SAM User Guide
• 7450 ESS guide
• 7750 SR OS Services Guide
• 7330 ISAM FTTN Product Information
• 7302 ISAM HYNT Product Information Guide
• 7342 ISAM FTTU ONT Product Information Manual
Wireless mobile backhaul services are available through GPON technology that can
be provided by a 7342 ISAM FTTU OLT or a 7330 ISAM FTTN convergence
platform. The 5520 AMS manages the PON interface between the 7705 SAR-M/ME
and the OLT and includes the provisioning of L2 connections between the GPON
module and a 7342 ISAM FTTU LT or a 7330 ISAM FTTN. These products
inter-operate and act as the L1 GPON cross-connection between the O-010G-A
GPON module (which functions as an ONT) and the OLT. The 5620 SAM manages
all of the other aspects of the 7705 SAR, 7450 ESS, and the 7750 SR including
service provisioning, operations and maintenance, SAA and maintenance. All
additional services are provisioned through 5620 SAM.
Caution — Services provisioned through 5620 SAM are independent
of the O-010G-A GPON module and the 5520 AMS. This means that
you cannot provision services through the O-010G-A GPON module
ONT or the 5520 AMS. These services must be provisioned using
CLI on the 7705 SAR or the 5620 SAM.
CES encapsulated DS1/E1

The 7342 ISAM FTTU P-OLT seamlessly passes CES DS1 or E1 traffic across the
Ethernet-based GPON packet-switched network. The P-OLT receives packetized
TDM traffic from the service provider through one of the Gigabit Ethernet network
connections on the NT unit, or from the GPON on any of the GPON GEM ports of
the LT unit.
GENIP service
The 7342 ISAM FTTU P-OLT let you provision management channel related
parameters so that an ONT can be managed directly via an EMS. The ONT must be
an ONT general IP UNI, such as the 7353 ISAM FTTB ONU. The P-OLT lets you
create a SNMP service on the ONT using TL1, and it allows configuration and
retrieval of the IP host, IP service and SNMP parameters using TL1 and SNMP.

1 — Overview
1.4 Network interfaces
The 7342 ISAM FTTU provides a high-speed and high-bandwidth access network.
This access network includes the following interfaces:
• the P-OLT interfaces between the gigabit Ethernet (GE) network and the ONTs
• the V-OLT interfaces between the video service provider network and the ONTs
• the ONT interfaces between the P-OLT and the subscriber equipment
The interfaces support the following connectors:
• P-OLT optical network connection to the Ethernet network: LC/UPC
• P-OLT optical network connection to the GPON: SC/UPC
• ONT optical network connection to the GPON: SC/APC
P-OLT interfaces
The P-OLT system provides the core processing, switching, and control functions.
In the upstream direction, the P-OLT interacts with the Ethernet switch and voice
gateway using the network termination (NT) cards.
In the downstream direction, the P-OLT distributes voice, data and in-band video,
and CES DS1 or E1 traffic to the ONTs over the GPON. At the P-OLT, line
termination (LT) cards terminate the GPON connections.
The P-OLT also contains an alarm control card and craft interfaces that allows EMS
access to the 7342 ISAM FTTU system for operation, administration, and
maintenance (OAM) purposes.
Each P-OLT system supports a maximum of:
• two NT cards
• 16 LT cards
• 32 PONs per P-OLT with each LT card supporting two PONs
• 64 indoor ONTs, outdoor ONTs, or business ONTs per PON
• 48-Gb/s switching capability
V-OLT interfaces
The V-OLT distributes RF video services across the PON from the video service
provider to the subscribers.
The V-OLT provides the interface between the video service provider network and
wavelength division multiplexing (WDM) unit. The ONTs connect to the video
service provider network using the GPON and WDM.
The video coupler amplifies the video signal that is carried over a PON using the
erbium doped fiber amplifiers (EDFAs).

1 — Overview
ONT interfaces
See the 7342 ISAM FTTU ONT Product Information Manual for more information
about ONT interfaces.
1.5 Element management system
The EMS manages the P-OLT and its connected ONTs remotely from a central
location. Some ONTs can be managed directly via the EMS through GENIP service.
5520 AMS
The 5520 AMS provides an intelligent GUI to translate simple point-and-click
actions to complex MIB variables and sequences of TL1 or SNMP commands. The
5520 AMS uses a UNIX-based client-server architecture.
The network manager allows the 7342 ISAM FTTU components that are far from
the CO to be managed from one location. The network manager can perform remote
fault management, including 24 hour/day remote alarm surveillance with logs and
alarm history. This includes real-time alarm and event monitoring with user-defined
alarm views. It can also perform daily performance monitoring, including
performance history, traffic monitoring, test management, and diagnostics. It allows
TL1 cut-through and flow-through provisioning.
The 5520 AMS has a Java-based platform and provides advanced OSS interfaces
based on Web Services (XML/SOAP).
For more information, see the 7342 ISAM FTTU Operations and Maintenance using
5520 AMS.
GENIP service
an ONT general IP UNI, such as the 7353 ISAM FTTB ONU.

2— Feature descriptions
2.1 Overview 2-3
2.2 Release R04.09.00 features 2-3
2.14 Release R04.06.00 and R04.06.01 features 2-17


2.1 Overview
This chapter provides a brief description of the features for the 7342 ISAM FTTU.
2.2 Release R04.09.00 features
Table 2-1 describes the features for 7342 ISAM FTTU FGU 04.09.00.
Table 2-1 Features for FGU 04.09.00
Feature Description
GLT8-A The GLT8-A is a line termination (LT) card that supports GPON line termination for eight
PONs asymmetric, XAUI, temperature hardened, fiber routing down, and RSSI capability.
It is a replacement for the GLT4 card, with the capability to support eight PONs instead
of four PONs.
Enhanced support for handling The 7342 ISAM FTTU allows the following to operate at the same time:
IGMP messages and IGMP • IGMP messages corresponding to IPTV service are processed for video replication
signaling channels using IGMP signaling channels
• IGMP messages on the signaling VLAN are transparently forwarded without using
IGMP signaling channels
P-OLT level anti-spoofing The 7342 ISAM FTTU product line has provided anti-spoofing functionality at the ONT
UNI level and now provides the option of anti-spoofing at the P-OLT side by enabling it
on a per VLAN level. Note this is supported for IPv4 packets handled by the GLT4 line
cards.
Modified multicast provisioning Modified handling of multicast provisioning commands for ONTs
Provision for Alarm Reporting TL1 alarms can be set to be reported in UTC time or in local time (local time is GMT plus
via UTC time a configured time zone offset).
p-bit override of upstream Using L2 ACL filters, LANX can now overwrite upstream p-bits on the outer VLAN tag with
packets at LANX a provisioned p-bit value.
Support of 64-bit uplink 64-bit uplink counters provide high capacity statistics for network ports on the SHub and
counters for LAGs.
Configurable rate limiting by Upstream rate-limiting of IPv4 control packets (DHCP and ARP) at the ONT is
enable/disable at the ONT configurable so that it can be enabled or disabled or configured for a value between 1
and 16 pps.
EHNT-B dynamic buffer The EHNT-B card supports dynamic buffer optimization through oversubscription of
optimization dynamic buffers by providing a dynamic pool of buffers available for each port. This
oversubscription of dynamic buffers provides the ability to handle simultaneous bursts
of traffic from multiple services.
DS1 loopback alarms and ARP An alarm is raised when a line or terminal loopback has been enabled at a DS1 interface.
failure alarm The ARP failure alarm is raised when there is an ARP failure to detect the MAC address
of the DS1 pseudo-wire termination peer.
DS1 Transmitted packets PM PM counters TTLTRPKTS and MISORDRDPD are added for CESPW and CESOIPPW services.
counters for pseudo-wire

Feature Description
Logical ID and password In addition to authenticating an ONU connected to the PON system based on the physical
support for ONU authentication identifier (serial number or SLID), the OLT supports the option of ONU authentication
using the logic identifier (logical ONU ID and password, or just the logical ONU ID). The
method of authentication is configurable at the OLT on a PON basis. The default is the
physical identifier authentication method.
This feature is supported on the I-240W-Q and I-240E-Q.
C-VLAN differentiated services With this feature the OLT allows provisioning of various services on an ONT UNI that
on a UNI share the same stacked S-VLAN, but are differentiated by unique C-VLANs. Within the
C-VLAN, this feature allows further traffic classification based on p-bits.
Such a S-VLAN is configurable using a new attribute called the “p-bit overlapping”
attribute. This attribute is set to disabled by default, allowing a legacy stacked S-VLAN
behavior.
This feature is supported on GLT4 cards.
MAC address movement for The OLT allows configuring a VLAN to permit the movement of a MAC address from one
Wi-Fi roaming bridge port to another within the VLAN when multiple WiFi access points are being used.
This feature provides support for mobile devices where the MAC address may not have
aged out of the forwarding database on a previous bridge port before it is observed on
a new bridge port. The default is to disable support for MAC address movement.
This feature is supported on GLT4 cards when the existing and new bridge ports are
located on the same physical GLT4 card. The existing duplicate MAC address alarm
behavior is retained for MAC address movement between LT cards, or if it involves a
network port or a static forwarding database entry.
7353 ISAM FTTB GPON A new ONT service type (GENIP service) has been added to the OLT to enable
management channel setup provisioning of management channel related parameters on a 7353 ISAM FTTB ONU. The
7353 ISAM FTTB ONU can then be managed directly via an EMS. The OLT lets you create
an SNMP service on the 7353 ISAM FTTB ONU using TL1, and it allows configuration and
retrieval of the IP host, IP service and SNMP parameters using TL1 and SNMP.
In order to use GENIP service, the ONT must support general IP UNI (virtual UNI) and be
controlled by the 7342 ISAM FTTU. The 7353 ISAM FTTB ONU supports GENIP service.
Voice XML file downloading You can configure the OLT so that the ONT uses OMCI channel (instead of an FTP server
or a SIPPING server) to obtain the XML files that have VoIP configuration information for
the ONT.
The XML file is downloaded from the OLT filesystem to the ONT using the OMCI channel.
If the XML file is not already present on the OLT it will first be downloaded to the OLT
filesystem from the provisioned server by FTP using the OLT's management IP interface.
This feature is supported on the O-24240E-Q.
L2 VPN support The OLT supports L2 VPNs where the lease line for the SME (small medium enterprise)
domain is pure L2 transparent in terms of user-to-user traffic (for example, to allow
downstream/upstream ARP broadcasts).
Support for third party The OLT allows you disable ONT software version control management by the OLT so
management tools to control that third party management tools, like ITMS (Integrated Terminal Management
ONT software management System), can control ONT software management. This means that the OLT will not
control the software activation procedure for ONTs managed by third party tools.
Support for additional RSSI On a limited basis the OLT supports configurable threshold crossing alerts on select ONTs
(Receive Signal Strength for the following:
Indication) TCAs • low optical Tx on OLT and ONT
• high laser bias current on OLT and ONT
• high temperature on OLT and ONT
• high voltage on OLT and ONT

Feature Description
Support for DHCP Option 100 If an ONT is configured to use DHCP and the DHCP server used by the ONT supports DHCP
Option 100, the ONT incorporates time information such as time zone and daylight
savings settings from the DHCP server.
Enhancement to BDINIT (Board An LT card which does not initialize successfully will reattempt the initialization process
Initialization) alarm behavior two additional times.
Rate limiting of ARP, DHCP, For Package B ONTs with MOCA:

IGMP, and CFM packets for • Upstream rate limitations for ARP and DHCP control packets have been removed.
Package B ONTs with MOCA has
been removed
• Upstream rate limitation of 10 pps for IGMP control packets is only implemented
while IGMP channels are created, based on the MAXMSGRATE provisioned on the
IGMP channel. There is no rate limitation of IGMP control packets if IGMP traffic is
flowing and there are no IGMP channels.
• Downstream rate limitations for CFM control packets have been removed.
Increase the number The GLT4 card supports up to 256 transparent protocol PON VLANs.
transparent protocol PON
VLANs
Feature Description
Expanding configured multicast The operator can provision multicast group IP in a range (GIP start address, GIP end
source table entries address) reducing the number of entries in the Multicast Source Table by allowing
grouping of entries with identical configurations.
DHCP relay and PPPoE relay The system allows IPoE traffic and PPPoE traffic within the same S-VLAN by permitting
allowed in same S-VLAN the customer to configure DHCP relay and PPPoE relay on the same S-VLAN.
TCAs on NT uplink ports The system allows an operator to set two alarm thresholds on each LANX port (EXNT-A
only):
• IN/OUT error packets alarm threshold
• IN/OUT discard packets alarm threshold

Feature Description
Global priority queue profile The system allows an operator to apply a different priority queue profile to a configured
modifications service while it is in service, or to modify a priority queue profile that is in use.
If the priority queue profile is modified in commitment mode, the system raises the
alarm GLOBALPQCHGIP, and applies the modifications to all services that use the
profile. The operator can check the status of the commitment using the TL1 command
REPT-OPSTAT-PQPROFEDIT.
Dropping of failed IGMP join In IPoE half-proxy mode, the operator can configure the IGMP proxy facility at the LT to
requests from subscriber drop the IGMP join requests that fail the IGMP CAC checks from the multicast VLANs and
C-VLANs optionally the subscriber C-VLANs.
Creation of multicast service The operator can create service context profiles to group multiple multicast sources and
context profiles multicast subscribers (IGMP signaling channels) by service provider.
See the 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1 and
CLI for configuration details.
OLT and ONT support for The following OLT and ONT support for IPv6-based data services is provided.
IPv6-based data services • DHCP snooping function, if used on the OLT, supports DHCPv6.
• ARP proxy function on the OLT, if present, supports IPv6.
• The OLT and ONT support IPv6 on their Ethernet interfaces.
• The OLT supports IPv4 and IPv6 simultaneously.
• The ONT supports IPv4 and IPv6 simultaneously.
• The OLT supports ICMPv6 as defined in RFC 4443.
Background Type-A downloads Type-A software files are automatically downloaded to LT cards when the OSWP is
downloaded to the P-OLT. The operator may disable the default action of automatic
download when issuing the DL-OSWP command.
OLT password security The following enhancements have been added for password security:
enhancements • Allowable password length is expanded to a maximum of 32 characters.
• Minimum password length can be set for the system, with a range from 6 to 32
characters.
• A password reuse policy has been defined and the password history can be set in a
range of 0 (zero) to 36 passwords. A value of 0 (zero) means no restriction for
password reuse.
OLT support for MoCA2.0 The 7342 ISAM FTTU has the ability to manage features, functionality and provide
service for MoCA2.0 enabled ONTs when they become available.
Video Rx sensitivity The dynamic range alarm reporting threshold has been changed to -12dBm for the ONT
improvement RF video Rx.
Optical power levels on the 1550 nm wavelength will also be reported in dBm.
Multicast Loss of Stream alarm Enhanced multicast monitoring can be enabled to monitor all 1024 possible dynamic
enhancement multicast streams to determine loss of stream at the OLT.
Jitter, latency and RT ITU-T Recommendation Y.1731 additional functionality for Ethernet OAM is supported.
performance report
ONT Ethernet interfaces EFM OAM support for Discovery and Variable retrieval between the ONT and RG Ethernet
support 802.3ah OAM interfaces.
SNMP support for TL1 user SNMP manager can be given secure access to TL1 user security tables in the OLT to
management manage username and passwords.
OLT acts as an SNTP server The 7342 ISAM FTTU can support a SNTP server application toward the ONTs. The SNTP
server application will send unsolicited multicast messages downstream to provide
timing updates and respond to unicast SNTP request messages from the ONT.
Restrictions are:
• supported on GLT4 cards only
• limited to 3 S-VLANs system wide
(1 of 2)

Feature Description
Global SSNAP modification A SIPPING Server Network Address Profile can be edited to change the network address
of the iConfig server used by ONTs for VoIP service. A version parameter has also been
added to help manage the profiles.
Multiple BFMU managers SNMP manager can request an on-demand Direct Fast MIB Upload data collection from
MIB objects that have been defined in a Direct Configuration text file.
(2 of 2)
Feature Description
MAC limiting on a per-service The system supports configurable limits on the number of learned MAC addresses or
basis C-VLAN IDs at the LT, not only on a per bridge port, but also on a per-service basis to
support deployments in an open access environment. The operator can specify a
per-service limit when configuring an HSI service or service flow on an ONT UNI port.
The system implements per-service limiting at the LT on a per (bridge port, S-VLAN)
basis. The system internally calculates the limit for a (bridge port, S-VLAN) combination
based on the bridge port limit and the limit set for each service on the bridge port that
shares the same S-VLAN as follows:
• If one of the supported services in the S-VLAN has a limit of zero, limiting is enforced
at the bridge port level only.
• If all of the supported services in the S-VLAN have a non-zero limit, the (bridge port,
S-VLAN) limit is set to the sum of the per-service limits, where the sum of the
per-service limits cannot exceed the bridge port limit.
GEM port network CTP as per The 7342 ISAM FTTU implements OMCI in two modes to enable multi-vendor
984.4 standard interoperability between the OLT and the ONT:
• proprietary mode
• non proprietary (standard) mode to support GEM port network CTP as per 984.4
standard
In non proprietary mode, the OLT creates GEM traffic descriptors that characterize and
regulate upstream and downstream traffic flows identified by a GEM port ID or MAC
bridge port on the ONT side as per the 984.4 standard, based on the option attribute
value of the ONT-G traffic ME.
The implementation of GEM traffic descriptors provide a more granular level of QoS to
access nodes in support of open access services.
• The OLT rate limits traffic at the T-CONT or portal level on the OLT side using DBA
mechanism.
• The ONT rate limits traffic at the service flow level using the GEM traffic descriptor
on the ONT side.
IGMP CAC check at the ONT When LT-to-ONT signaling is disabled, the ONT performs the IGMP CAC check when a
level subscriber join request is received, and ensures the following:
• The subscriber can view the requested multicast channel.
• The subscriber UNI port can support the multicast stream.
• The maximum number of hosts that are allowed to receive the same multicast
stream on a UNI port is not exceeded.
IGMP CAC checks at the ONT are implemented through standard OMCI.
(1 of 2)

Feature Description
Multiple maintenance points on The system now supports the ability to configure at least 2 maintenance points and the
an ONT UNI configuration of MEP and MIP at the same time on the ONT.
Support for OISGv2 The OLT is compliant with both OISG v1 and v2 standards. This allows for OLT
configuration of functions using TL1 that was formerly only supported using proprietary
methods, such as VoIP configuration.
The FSAN standards group created an OMCI Interoperability Study Group (OISG) that
focus on creating an OMCI implementers' guide that provide guidance and agreement
between all GPON vendors on a unique OMCI implementation that will be interoperable
between all vendors.
CFM 802.1ag enhancement The OLT will forward CCM packets from an ONT upstream to the edge router.
Multicast incidental broadcast Support for the OLT to transparently pass incidental broadcast/multicast traffic of RipV2
GEM port and SAPv1 from the network to the ONT using a unicast VLAN on a GEM port that is not
the multicast GEM port.
(2 of 2)
Feature Description
Bidirectional 40km SFP Support for extended reach 40km bidirectional SFP
Multicast VLAN translation Support for multicast VLAN translation on the EXNT card from a network-side to a
subscriber-side multicast VLAN in the downstream, and from a subscriber-side to a
network-side multicast VLAN in the upstream
Source-specific multicast (SSM) Support for SSM to allow overlapping multicast IP addresses on different multicast
VLANs. Where multicast sources use the same multicast group IP address for different
channels, the SSM model can ensure that the correct multicast channel is delivered to
the subscriber by limiting the source IP address to the requested video server.
Nonconfigured multicast Support for nonconfigured multicast. Nonconfigured multicast is initiated when a
subscriber requests to join a multicast group that is not in the multicast source table.
The system processes the join request after validating the join request for acceptance.
ASM-to-SSM mapping The operator can create a mapping of source IP addresses on a per multicast group per
VLAN basis. The mapping supports deployments where the network equipment only
supports SSM, and the subscriber equipment, that is the set-top box, only supports
any-source multicast (ASM). The NT derives the source IP address of the network
equipment that is sourcing the multicast stream from the mapping, and converts an ASM
request to an SSM request before sending it out to the network.
Enhancements to OAM Enhancements were made to the QoS, IGMP and IP multicast, VLAN tagging, HSI service,
guidelines and procedures and Ethernet services configuration guidelines in the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI, and to their related DLPs.
End-to-end overview and Enhancements were made to the triple play chapter in the 7342 ISAM FTTU Product
configuration of Information Manual, which provides an end-to-end overview and configuration of the
7342 ISAM FTTU 7342 ISAM FTTU.
Increase the number of uplinks Support for multiple uplink active-standby protection for network redundancy.
to 8 for static LAGs

Feature Description
Scalability on the PON Increase in the number of UNI ports per PON on a EXNT-A and GLT4 system
ONT HPNA Support for the ONT HPNA, which includes:

• configuration of HPNA card
• configuration of HPNA port
• ONT HPNA alarms including
• HPNASVCMIS—service mismatch
• HPNALOS—loss of signal
TL1 training The TL1 training chapter in the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI has been enhanced to provide information about TL1
and how TL1 commands and parameters are documented in procedures. The TNG
includes the following sections:
• TL1
• TL1 messages including command, acknowledgement, response, and autonomous
messages
• TL1 syntax
• command verbs
• TL1 entry modes
• how TL1 commands are documented
• how TL1 parameters are documented
• sample procedure
Enhancements to OAM Enhancements were made to the P-OLT equipment, ONT equipment, and ONT UNI
guidelines and procedures configuration guidelines in the 7342 ISAM FTTU Operations and Maintenance Procedures
Guide using TL1 and CLI, and to their related DLPs.
Feature Description
Multicast GEM port PM counters Support for performance management to provide additional counters for multicast GEM
port on both the OLT and ONT sides TC layer (GEM based) counters, making it easier for
you to troubleshoot and trace IP-TV issues
(1 of 6)

Feature Description
DHCP configuration alarms Provision of new alarms for DHCP failures

See the 7342 ISAM FTTU P-OLT and ONT Fault Isolation and Troubleshooting guide for
more information.
New DHCP configuration alarms that replace the VDHCPERR alarm:

• VDHCPTO
• VDHCPMAL
• VDHCPNOADD
• VDHCPLEASE
Descoped DHCP configuration alarm:

• VDHCPERR
NOTE: This alarm condition will not be eliminated for PPPoE and Megaco applications,
but not supported for IPoE/DHCP SIP applications.
VoIP configuration alarms Support for finer alarm granularity based on the UNI specifications to provide new
alarms for the three areas of interaction with the iConfig server: subscription, notify and
HTTP retrieval for VoIP Client failures
more information.
New VoIP iConfig server subscription alarms:
• VICNFSUBDNS
• VICNFSUBAUTH
• VICNFSUBTO
• VICNFSUBERR
• VICNFSUBREFERR
• VICNFNOTREFERR
• VICNFERR
New VoIP iConfig server notify alarms:
• VICNFNOTTO
• VICNFNOTREFTO
• VICNFNOTMAL
• VICNFNOTREJ
New VoIP iConfig server HTTP alarms:

• VICNFHTTPDNS
• VICNFHTTPTCP
• VICNFHTTPTLS
• VICNFHTTPAUTH
• VICNFHTTPTO
• VICNFHTTPERR
• VICNFHTTPMAL
Descoped VoIP configuration alarms:

• VICONFIGSUBFAIL
• VICONFIGNOTIFYFAIL
• VICONFIGHTTPFAIL
(2 of 6)

Feature Description
POTS configuration alarms Support for finer alarm granularity based on the UNI specifications to provide new
alarms for the three areas of interaction with the iConfig server: subscription, notify and
HTTP retrieval for POTS port failures
more information.
New POTS iConfig server subscription alarms:

• PICNFSUBDNS
• PICNFSUBAUTH
• PICNFSUBTO
• PICNFSUBERR
• PICNFSUBREFERR
• PICNFNOTREFERR
• PICNFERR
• PICNFINSUFF
New POTS iConfig server notify alarms:

• PICNFNOTTO
• PICNFNOTREFTO
• PICNFNOTMAL
• PICNFNOTREJ
New POTS iConfig server HTTP alarms:

• PICNFHTTPDNS
• PICNFHTTPTCP
• PICNFHTTPTLS
• PICNFHTTPAUTH
• PICNFHTTPTO
• PICNFHTTPERR
• PICNFHTTPMAL
Descoped POTS configuration alarms:

• PICONFIGSUBFAIL
• PICONFIGNOTIFYFAIL
• PICONFIGHTTPFAIL
• SIPREGFAIL
• SIPINVITEFAIL
POTS registration alarms Support for finer alarm granularity based on the UNI specifications to provide new
alarms for SIP registration failures that can occur for POTS ports only
more information.
New POTS SIP registration alarms to replace the SIPREGFAIL alarm:

• SIPREGDNS
• SIPREGAUTH
• SIPREGTO
• SIPREGERR
(3 of 6)

Feature Description
POTS invite alarms Support for finer alarm granularity based on the UNI specifications to provide new
alarms for SIP invite failures that can occur for POTS ports only
more information.
New POTS SIP invite alarms to replace the SIPINVITEFAIL alarm:

• SIPINVITEDNS
• SIPINVITEAUTH
• SIPINVITETO
• SIPINVITEERR
iConfig profile status Support for profile status visibility where the ONT will maintain a status for each iConfig
profile that can be retrieved by OMCI on request, then displayed using TL1 or AMS
The new TL1 commands REPT-OPSTAT-VOIPVIPPROF and REPT-OPSTAT-VOIPPIPPROF
allow you to retrieve the download status of iConfig profiles for VoIP and for each POTS
line.
YP serial number The TL1 command RTRV-ONT also displays the YP (yellow pages) serial number, which
enables an ONT to be traced after it is installed at the subscriber site.
MoCA UNI and BHR MAC The TL1 command REPT-OPSTAT-ONTMOCA displays the MAC address for both the MoCA
addresses UNI (near end of the MoCA link) and the broadband home router (BHR) (far end of the
MoCA link). The TL1 command only displayed the latter one.
IPoE half-proxy The IGMP proxy on the LT card can be configured in IPoE half-proxy mode. In this mode,
the gateway router sends IGMP general and group-specific queries to the subscribers,
and receives IGMP joins and leaves from the subscribers over an IPoE stream to maintain
the status of streams. This configuration is suitable for deployments where network-side
equipment performs subscriber accounting of channel usage and CACing of IPTV requests
from subscribers, and uses the proxy facilities at the P-OLT to maintain the multicast
forwarding databases and to replicate downstream multicast traffic received on a
multicast VLAN.
CDR support for rejected joins You can enable the generation of a control data record (CDR) for joins that are rejected
due to CAC check due to CAC check, including date and time, originating UNI port, requested stream, and
reason for rejection.
Access to SLID after ONT is The ONT has a configurable security setting that allows a field technician to access the
connected to PON and is ranged SLID at the ONT, after an ONT is connected to the PON and is ranged, using a GUI-based
HTTP interface or menu-based CLI interface.
HTTP and CLI interfaces A GUI-based HTTP interface and a menu-based CLI interface support the management
of an ONT at a local site. The interfaces provide utilities that enable a field technician
to:
• retrieve product information about an ONT, such as vendor name, firmware, type of
ONT, and serial number
• retrieve operational information about an ONT, to monitor events such as the
operational states, uptime, receive signal strength indication (RSSI), status of LEDs,
and ranging state of the ONT
• monitor a software download to an ONT
• reboot or reset an ONT to recover from connection, power, software download, and
other failures
• perform OMCI and protocol tracing for problem diagnosis and resolution
• enter the SLID at an ONT, to activate ONTs with their provisioning data and services
using the SLID method, and to clear the SLID when an ONT is removed
An ONT has a configurable security setting that specifies the user access level. The user
access level determines the interface features that are available to a field technician
after the ONT is connected to the PON and is ranged.
The HTTP interface is accessible through an Ethernet connection on indoor ONTs with
an HTTP server.The CLI interface is accessible through an Ethernet connection on indoor
ONTs, and a craft connection on outdoor ONTs.
(4 of 6)

Feature Description
LT card with Class C+ optics Support for GLT4-D card with provides four GPON interfaces with Class C+ optics for
extended reach (60 km) service.
Troubleshooting capabilities Support for enhanced troubleshooting capabilities for SIP applications. You can view the
for SIP applications status of each configuration file to determine if an ONT is operating to the desired user
agent parameters.
In addition, you can view a subset of the user agent parameters directly from the GUI,
in a user-friendly format, to help facilitate the job of tier one support in determining
the proper action in response to issues.
The following user agent parameters and their values are retrievable:
• registrar_route
• outbound_proxy
• registrar_uri
• address_of_record
• realm
• username
• password
• contact_uri_user
• outbound_uri_suffix
Business service support on the The Current Generation ONTs (I-24x, I-040, B-0404-A) must be enabled for port-to-port
Next Generation ONTs communication to support the flexible mode; in this communication mode, a business
(I-x4xG-B) service can only be configured on port 1, and the service is replicated on the other
enabled ports.
The Next Generation ONTs (I-x4xG-B) do not have to be in port-to-port communication
to support the flexible mode, and support business services separately on each of their
4 UNI ports.
DHCP counter improvements Support for additional DHCP counters which indicate what type of DHCP messages are
transmitted and received by the OLT.
Background Fast MIB Upload Support for fast MIB upload using FTP or SFTP
PPPoE session messages Support for PPPoE relay agent counters for upstream and downstream frames.
counters
Readable SFP/XFP inventory Support for retrieving SFP/XFP module inventory information and diagnostic statistics.
data
DGN-PON enhancement Support for an additional PON diagnostic test for detecting and isolating rogue ONTs.
The additional test is a pattern test that is initiated on the target ONT.
(5 of 6)

Feature Description
Extended PON operation Support for full operation across an increased ONT differential window of 20 km, 34 km,
and 40 km. The differential window for ranging and ONT operation is provisionable per
PON.
The TL1 commands ED/RTRV-PON include the new parameter DIFFREACH, that will allow
you to enable PON deployments from 20 km up to 40km and beyond, using the
CLOSESTONT parameter to extend the PON length capability.
New alarm definitions are used for any freescale ONTs deployed beyond a 34 km
differential from the closest ONT and will be disabled when the location on the PON has
exceeded its differential reach capability to prevent rogue ONT behavior.
New ONT PLOAM alarm condition:

• DIFREACH
New SFU PLOAM alarm condition:

• DIFREACH-SFU
New SOHO PLOAM alarm condition:

• DIFREACH-SOHO
New MDU PLOAM alarm condition:

• DIFREACH-MDU
Modified OLT GENERAL alarm condition NEWONT to include:

• DIFREACH
(6 of 6)
Feature Description
Support of colored SFP Support for eight wavelengths of the 1-GE SFP CWDM pluggable optical modules.
Time zone offset with daylight Support for configuring the time zone offset with daylight savings time indication on
savings time indication the P-OLT, with SNTP enabled or disabled for the NE clock.
Configurable ACU Ethernet port Support for the manual configuration of the ACU Ethernet port.
ACU Ethernet port PM statistics Support for retrieving frame performance monitoring data, for the EHNT and EXNT ACU
Ethernet port, via TL1 over craft port
ONT software integrity check Support for the OLT to perform an integrity check when ONT software is downloaded,
to ensure the ONT software file is complete. If an incomplete ONT software download
is detected, the partial file is removed from the NT.
Enhancements to environmental Support for longer environmental alarm description strings and the ability to filter on
alarms the environmental alarm number.
Alarm time and date stamps Support for alarm date (in mm-dd format) and time (in 24-hour clock hh-mm-ss format)
stamping, to facilitate better fault and alarm management.
ONT ping Support for the ability to ping from an ONT to another piece of network equipment.
(1 of 3)

Feature Description
ONT alarm differentiation Support for core ONT alarms being split into three families of alarms, making it easier
between ONT types for customers to prioritize service and support activities. Alarm type 40 alarms (ONT
PLOAM alarms) and alarm type 41 alarms (ONT general alarms) are differentiated into
the following (alarm differentiation is not enabled by default):
• XXX-SFU alarms, indicating that the PLOAM or general ONT alarm is against a single
family unit indoor or outdoor ONT; typically one customer is affected
• XXX-SOHO alarms, indicating that the PLOAM or general ONT alarm is against a
small office home office indoor or outdoor ONT; typically a small business or small
number of customers are affected
• XXX-MDU alarms, indicating that the PLOAM or general MDU alarm is against a
multi-dwelling unit device; typically multiple customers are affected
Alarm on LT reset Support for raising a SWRESET alarm when an already installed LT card has a software
reset, including details on the slot where the reset occurred.
Enhancements to the crash log Support for additional details in the crash log file for NT and LANX resets.
file
Background audit Support for a system-run background audit that checks for NT database consistency.
When inconsistencies that could potentially affect resets are found, an informational
alarm is raised.
Performance management Support for performance management counters and alarms to ensure continuity of
counters and alarms counters and the generation of alarms in the case of backplane communication errors:
enhancements • EHNT-B maintains PM coding error counters associated with the received traffic
from each LT interface. The PM counters count the number of intervals with an
error (errored seconds)
• GLT2-x and GLT4-x with EHNT-B maintains PM coding error counters associated
with the received traffic from each LT interface. The PM counters count the
number of intervals with an error (errored seconds)
• EXNT-A maintains PM coding error counters associated with the received traffic
from each LT interface. The PM counters count the number of intervals with an
error (errored seconds)
• GLT4-x with EXNT-A maintains PM coding error counters associated with the
received traffic from each LT interface. The PM counters count the number of
intervals with an error (errored seconds)
OLT configuration file Support for a customer specific configuration file that will alter static parameters that
are not able to be changed using a standard system management interface (TL1, CLI or
network management system). Parameters for the following features can be altered:
• P-OLT backplane alarms threshold interval and threshold value
• ONT alarm hysteresis settings for ONT alarm display activation and deactivation on
the P-OLT
ONT alarm hysteresis Support for ONT alarms hysteresis is to minimize the setting and clearing of faulty ONT
alarms by the P-OLT. The ONT configuration file is used to set the alarm type with its
activation debounce time and deactivation debounce time parameters.
PON feeder redundancy Support for 1+1 protection of the PON fiber between the OLT and the ONT.
Bitswap enabled on Support for bitswap, a VDSL2 PHY-layer feature, on VDSL-capable MDUs. Bitswap is
VDSL2-capable MDUs enabled by the MDU software and requires no provisioning by the user.
ONT SLID provisioning using a Support for provisioning the SLID on an ONT using a computer with a HTTP client and
HTTP server connected to a HTTP server.
Active/Standby uplinks on OLT Support for a protection configuration of two NT uplink ports, one active and one
standby, to two different upstream routers.
RSSI support Support for RSSI capabilities with a new variant of the GLT4-A card
(2 of 3)

Feature Description
Manual and auto-negotiation Support for manual or auto-negotiation configuration of network interfaces is provided
modes for network interfaces for NT cards. Manual mode supported for 1GigE interface at 1 Gb/s, with data transfer
in full duplex. Auto-negotiation mode supported for automatic configuration of
negotiation speeds, in full duplex mode. Optical and 10/100/1000 Electrical SFPs are
supported.
CPU utilization statistics Support for retrieval of memory and CPU utilization statistics for the NT and the LANX,
using CLI or TL1.
Additional PM interval statistics Support for interval performance monitoring statistics for SHub bridge ports of the
for SHub bridge port P-OLT, including unicast, broadcast, multicast, and error frames received or
transmitted on network interface.
Vendor-specific MAC filtering Support for configuring anti-spoofing filtering using vendor-specific MAC addresses.
for anti-spoofing
Link aggregation monitor and Support for link aggregation monitoring with configurable monitoring window and
5-minute PM statistics intervals. Ability to retrieve statistics at 5-minute intervals including received,
transmitted, and discarded packets, and receive and transmit rates for configured
intervals.
OMCI G.984.4 standard 802.1ag, Implementation of 802.1ag, performance monitoring statistics, alarms, and counters
performance monitoring according to the latest OMCI G.984.4 standard, on the 7342 ISAM FTTU OLT and ONTs
statistics, alarms, and counters. that support the standard. See 7342 ISAM FTTU ONT Product Information Manual for
ONT product information.
RF video service timer Support for configuring RF video service timer for ONTs that support the RF video
service. Ability to specify the amount of time (in hours) the ONT will sustain the RF
video service, after ranging between the OLT and ONT is lost.
IGMP channels multicast Ability to disable LT monitoring of multicast bandwidth consumption by the ONT UNI
bandwidth usage at ONT UNI for IGMP channels, to support vendor-specific applications.
MoCA ONT interface Phy rate Support for retrieving the MoCA ONT interface Phy rate and current operational MoCA
and version version (1.0 or 1.1)
Transparent protocol handling Support for per VLAN transparent passthrough of L2/L3 protocols including DHCP and
ARP for residential bridge, C-VLAN learning, and cross connect VLANs.
GLT2-B/C C-VLAN learning The GLT2-B/C cards support configuration of C-VLAN learning forwarding VLANs, using
forwarding static forwarding entries.
Per service anti-spoofing Support for per service anti-spoofing that uses only IP address(es) that have been leased
enhancements for the specific service.
(3 of 3)
Table 2-11 Features for Release 04.06.06
Feature Description
ARP snooping Support for ARP snooping on residential bridge PON VLANs for GLT4-A cards, to monitor
ARP dialog between CPE devices and the network in order to learn the MAC/IP binding
and to populate the ARP table entries for downstream ARP request packets. This
function is useful for deployments where IP addresses that are statically assigned to
hosts cannot be entered manually in the system, such as Video-on-Demand

Feature Description
VoIP configuration and For SIP:

functionality changes • change to the configuration value to determine a different method of putting calls
on hold using the ‘inactive’ method
• change to the far_end_symmetry parameter behavior
For MEGACO:
• change to the configuration value to determine a different method of putting calls
on hold using the ‘inactive’ method
Increase in the configurable The ONT Ethernet port supports up to 2048 dynamic and/or static configured MAC
number of MAC addresses addresses.
Configurable LT slot ranges The operator can configure the lt_slot range that is used in DHCP Option 82, 802.1x,
and other messaging. The allowable ranges are 1-18 and 3-20.
Interoperability enhancements The operator can configure some parameters that apply to certain third-party ONTs, to
with third-party ONTs make interoperability easier.
Configurable ENV alarm The operator can configure the description of an ENV environmental condition alarm,
description field to make the alarm more representative of the condition it is reporting.
VoIP service alarm change The VDHCPERR alarm is renamed to VNTWKERR, to better represent that the cause of
a service error alarm may be due to DHCP problems.
Remove IP addresses from ARP You can, per VRF, identify and remove a specific IP address or range of IP addresses
table from the ARP table
Multicast translation in The operator can configure the system to use RIP to analyze downstream packets from
different VLANs a specific VLAN and have those packets replicated to associated GEM ports.
2.14 Release R04.06.00 and R04.06.01 features
Table 2-13 describes the features for 7342 ISAM FTTU 04.06.00 and 04.06.01.
Table 2-13 Features for Release 04.06.00 and 04.06.01
Feature Description
SNMP community names The system now supports SNMP community name configuration for up to forty entries
increased or managers, or both (different communities or network access rules, or both) on the
P-OLT and SHub.
Downstream rate-limiting to Downstream rate-limiting can be configured on an ONT to operate in one of two ways:
ONT on a per-service basis on a per-ONT basis or a per-service basis. In the latter case, downstream rate-limiting
service schedulers are created and applied to HSI, CES PW, and VoIP services, and to
portals.
T-CONT per EVC The T-CONT per EVC model allows multiple services for a single subscriber to share the
same T-CONT.
(1 of 4)

Feature Description
T-CONT per CoS The T-CONT per CoS model allows multiple services for different subscribers to share
the same T-CONT.
T-CONT per service The T-CONT per service model allows multiple subscribers of the same service to share
the same T-CONT.
Port-to-port communications The system supports enabling and disabling of port-to-port communications on the I-24x
and I-040 indoor series ONTs.
ONT-to-ONT communications ONT-to-ONT communication using the LT cards is configurable, to allow ONT-to-ONT
for VoIP services VoIP VLANs.
FTP server security You can configure an FTP server username and password, to secure XML configuration
configuration support file downloading.
NT reboot alarm support An alarm is raised when an NT card reboots.
SNMP error log message IDs You can use RTRV-ERRORLOG to view the reasons why some SNMP Gets and Sets failed.
Additional RSSI capabilities Ability to enable or disable the collection of the ONT RSSI levels and to display the
history using the TL1 command REPT-OPSTAT-OPTICSHIST.
Report distance between ONT Additional parameter of the REPT-OPSTAT-ONT command to display the estimated
and OLT distance between an ONT and the OLT.
Lowercase support for TID and Both the TID and SID can contain any combination of lowercase and uppercase letters,
SID numbers, and hyphens, and are case-sensitive when compared to each other.
Thermal status of P-OLT The system supports the retrieval of thermal readings for NT, ACU, and LT cards.
equipment
Prioritization of IP filters The IP filter number uniquely identifies an IP filter, and also designates the priority of
the IP filter relative to others, such that the lowest numbered filter has the highest
priority.
Delivery of SLID to P-OLT The system supports two modes to deliver a permanent SLID from the ONT to the P-OLT:
• The proprietary mode uses the proprietary PLOAM message used in the predecessor
to FGU 04.06.00.
• The registration ID mode uses the password PLOAM message defined in G.984.3.
The system uses the proprietary PLOAM message to deliver a volatile SLID.
(2 of 4)

Feature Description
Ethernet services for business The system supports Ethernet services for business and residential applications, which
and residential applications provide the following functionality:
• six basic models to configure a leg of an EVC on the 7342 ISAM FTTU, including:
• bundling and single CoS
• bundling and multiple CoS
• all-to-one bundling and single CoS
• all-to-one bundling with multiple CoS
• T-CONT per EVC
• T-CONT per CoS
• single-tagged frames in a stacked VLAN, to support all-to-one bundling
• transparent pass-through of untagged frames from the CPE, to support all-to-one
bundling
• transparent pass-through of double-tagged frames across the FTTU access network,
to support wholesaling services on the PON, and mixed business services, such as
point-to-point and xDSL.
• setting of p-bit in the outer S-VLAN tag to a defined value while retaining the
subscriber p-bit, to support the bundling of a number of C-VLANs in a single S-VLAN
for a network service provider
• mapping of business traffic at the LT to the CoS in the aggregation network, while
retaining the subscriber p-bit
• mapping and translation of both the customer p-bit and VLAN ID on the UNI side to
their equivalent customer p-bit and C-VLAN ID on the network side
• multiple cross-connect VLANs on the same ONT UNI
• T-CONT sharing across multiple ONT UNIs on the same ONT for a single service
• T-CONT sharing across multiple services on the same ONT UNI
• T-CONT sharing across multiple services across multiple ONT UNIs on the same ONT
• upstream segregation of single- and double-tagged frames in the same service to
GEM ports
Subscriber scalability Subscriber scalability is supported by the ability to disable MAC learning and enable
subscribers of a service to share a T-CONT as follows:
• disable MAC learning for LT ports on a range of VLANS on the SHub
• configure a T-CONT per service EVC model that supports T-CONT sharing across
multiple UNIs on an ONT for a single service
Decimal IGMP package numbers IGMP package numbers may now be entered as decimal values, in addition to the
hexadecimal format currently supported.
AES disable support In cases where an ONT supporting AES is replaced by an ONT that does not support AES,
the system will automatically disable AES for that particular ONT. No profile change is
required.
Increased number of IGMP The maximum number of IGMP packages is increased to 1024.
packages
Increased IGMP signaling The maximum number of IGMP signaling channels per PON is increased to 288.
channels The maximum number of IGMP signaling channels per GLT2 is increased to 576.
The maximum number of IGMP signaling channels per GLT4 is increased to 1152.
Support for mis-sequenced and To minimize the number of mis-sequenced or dropped packets when a blocked link is
dropped packets on the SHub removed and reconnected, ensure that the root bridge forward delay time for the SHub
caused by reconvergence of a matches the ageing time-out for dynamic MAC entries. For more information, see
blocked link 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1 and CLI.
Support for Cisco routers Typically, a proxy ARP request is sent from the LT to the CPE with a source IP address
of 0.0.0.0. The ONT can now send the proxy ARP packet to the CPE with the source IP
address set to the destination IP address, for routers that validate the source IP
address.
Retrieve PON bandwidth Ability to retrieve the booked and currently provisioned aggregated PON bandwidth
details, such as CIR, AIR, and EIR.
(3 of 4)

Feature Description
LT card software download Ability to trigger the download of an LT card OSWP load to a user-specified range of
cards.
ONT software version control Table entries that associate an ONT hardware version and hardware variant to an ONT
table software file. An automatic ONT software download is accomplished if ONT is set for
auto download and the hardware criteria matches the table entry.
(4 of 4)
Table 2-14 describes the features for 7342 ISAM FTTU 04.05.06.
Feature Description
2048 kHz clock source The BITS interface on the EHNT-B and EXNT-A supports a 2048 kHz clock source.
Additional optical SFP and XFP Support for new optical modules, allowing greater flexibility in deployment lengths and
modules wavelength management.
Virtual Router Redundancy The facility to enable multicast flooding on a SHub VLAN basis is provided, so that VRRP
Protocol (VRRP) transparency packets are not blocked and are forwarded to a second network port.
Migration of dynamic data on In some cases, the ODMT did not migrate the dynamic data on the SHub. The ODMT now
the SHub migrates both the static and dynamic data on the SHub whenever possible. Migration of
the dynamic data lessens the load on the SHub, and enables fast recovery of the system
as tables do not have to be rebuilt and entries re-learned. Traffic such as multicast
traffic, resumes more quickly.
Wholesale video Wholesale video is available through residential-bridging.

SLID The P-OLT can also communicate with the ONT if the ONT is installed and the P-OLT
knows the SLID of the ONT. Configuration of the ONT and its services can be done at
the P-OLT before or after the ONT is installed. After the P-OLT polls the PON for new
ONTS and the ONT sends its SLID, range, and registration information, the P-OLT
searches the P-OLT database for the same SLID. If a match is found, the P-OLT registers
the serial number of the ONT, and downloads ONT and service configuration data to the
ONT.
Table 2-15 describes the features for 7342 ISAM FTTU Release 04.05.05.
Feature Description
Increase in number of The number of provisionable bandwidth profiles increases from 50 to 250.
bandwidth profiles
Network interface port statistics The ability to retrieve 32-bit performance monitoring counters for a network interface
port on the SHub using CLI is provided.
(1 of 3)

Feature Description
Ethernet port auto detection The parameter values for Ethernet port auto detection are updated.
Protocol type filtering The ability to filter on protocol type only (also known as EtherType) is provided. The
CLI commands configure transport shub mac-filter and show transport shub mac have
been modified to allow and show protocol filtering across all source and destination
MAC addresses. For the CLI command configure transport shub mac-filter, the filter
parameter has been modified to allow filtering on the range of any source MAC address
to any destination MAC address. For example, this feature enables you to block LLTD
(Link Layer Topology Discovery) in Windows Vista based on EtherType 88d9.
Gratuitous ARP discard The 7342 ISAM FTTU supports a discard mechanism that filters incoming traffic for
gratuitous ARP requests. When gratuitous ARP discard is enabled, incoming gratuitous
ARP requests are discarded. Gratuitous ARP discard is configured on an ONT UNI port
basis.
Support for T-CONT type 2 and The ITU-T G.984.3 standard classifies T-CONTs into five types of containers. The DBA
T-CONT type 3 algorithm now supports T-CONT types 1 through 5. T-CONT type 2, assured bandwidth,
and T-CONT type 3, assured bandwidth and non-assured bandwidth, are available.
Dynamic source address Where the IP or MAC source addresses are not known, dynamic source address
anti-spoofing with DHCP anti-spoofing is available.When dynamic anti-spoofing is enabled, an IP address is
dynamically added to the anti-spoofing table of authorizing source addresses when a
host sends a DHCP ACK message, and is deleted when the DHCP lease expires.
VDSL2 supported in lieu of VDSL consists of two versions: VDSL1, which is the original VDSL, and VDSL2. The
VDSL1 7342 ISAM FTTU system no longer supports VDSL1 configuration. However, VDSL2 is still
configurable using xDSL TL1 commands. The upgrade to FGU 4.05.05 requires the
migration of existing VDSL1 services to VDSL2. However, a modem with VDSL1 firmware
can transparently convert a VDSL2 service to VDSL1.
EXNT support for OLTS-M The ETSI configuration for the 7342 ISAM FTTU system using the OLTS-M shelf, now
supports the use of the EXNT card.
RSSI: Measure optic power levels The ability to provide on demand RSSI values for a GLT4 PON 1490nm transmit, a GLT4
on OLT/ONT PON 1310nm receive and a specified ONT 1490nm receive. The optical power level is
reported as a dBm value and has an accuracy of +/-3dB.
Support for IEEE-1588v2 The EXNT-A card can be configured to use the Precision Timing Protocol (PTP) to
network clock synchronization synchronize the 7342 ISAM FTTU system clock to the 1588 master clock in the network.
LT event logging Protection switching events and LT card resets are both logged by syslog. The syslog
output can be reviewed to track LT card behavior.
Secondary softswitch IP address A second softswitch IP address can be configured using TL1, eliminating the need for a
configuration DHCP server in some network configurations.
Emergency call in progress Support for a new alarm that alerts the network equipment operator that an emergency
alarm call is in progress on an ONT or MDU.
Flushing of learned MAC address When an Ethernet port goes out of service, the learned MAC address entries in the VLAN
entries forwarding database for the port are flushed. This feature enables an installer to move
from one ONT to another using the same MAC source address, without having to wait
for the learned MAC address entries to age.
Duplicate MAC filters on LT card The BridgePort does not get blocked when a duplicate MAC address is detected.
When a duplicate MAC address is detected, a MAC filter is installed on the LT card to
drop subsequent packets from the BridgePort with the same source MAC address.
Frames with different source MAC addresses are not discarded; traffic destined to the
duplicate MAC address is forwarded to the first BridgePort where the duplicate MAC
address was learned.
To handle duplicate MACs, the GLT4 reserves 64 MAC filters and the GLT2 reserves 32
MAC filters. When all reserved MAC filters are installed, the bridge port is blocked when
an additional duplicate MAC address is detected.
(2 of 3)

Feature Description
Optical reach The 7342 ISAM FTTU system typically supports a maximum of 18.6 mile (30 km) span,
for all GLT cards.
Layer 3 support on EXNT-A The EXNT-A card provides layer 3 support. Layer 3 is the network layer of the OSI model
that determines how data is transferred from a source to a destination through the
network, while maintaining QoS service level agreements.
(3 of 3)
Table 2-16 describes the features for 7342 ISAM FTTU Release 04.05.00.
Feature Description
Increase of number of The number of provisionable entries in the multicast source table increases from 2048
provisionable multicast sources to 4096.
EXNT-A High Capacity NT Introduction of a new NT card that supports redundant XAUI links to GLT4-A and GLT2-C
cards in the OLTS-L and OLTS-M shelf types.
Failure/Fault data captured Failure data is captured if the NT crashes. This data includes NT and LANX information
and is retrieved using TFTP.
SMAC alarm Alarm indicating a problem with the SMAC card on the OLT shelf.
Ping the LANX VRF using CLI Perform a ping test to a VRF ID on the SHub.
Bridgeport disabled alarm Alarm indicating when a bridge port has been disabled as the result of too many
exceptions.
Card synchronization alarm Alarm indicating a card synchronization clock input failure.
Deletion of dynamic MAC The capability to delete a MAC address entry that is learned dynamically in a VLAN
address entries forwarding table at the LT card is provided.
64-bit counters The P-OLT supports 64-bit counters for the SHub bridge ports.
Megaco pull/break dial tone test The Megaco (H.248) pull/break dial tone test returns time measurements in 0.1 second
increments for both the pull and break portions of the test, if the test result is with
data.
Physical address format of The ability to set the physical address format for the Option 82 field is provided.
Option 82 field
Configurable p-bit setting for The ability to configure the p-bit setting for IGMP signaling is provided at both the
IGMP signaling system and subscriber level.
Gigabit Ethernet interface Maximum Ethernet frame size of 2000 bytes supported at the OLT and ONT interface.
requirements

3— R04.08.00 feature overview and
configuration details
3.1 Overview 3-3
3.2 Rogue ONT detection enhancements 3-3
3.3 Security enhancements for SIP user name and password

modification 3-3
3.4 OLT password security enhancement 3-3
3.5 SIP improvements 3-3
3.6 Support for OISGv1 and OISGv2 VoIP provisioning 3-4
3.7 Background Type-A downloads 3-4
3.8 Video Rx sensitivity improvement and alarm update 3-4
3.9 Multicast Loss of Stream alarm enhancement 3-4
3.10 Jitter, latency, RT performance report 3-4
3.11 802.3ah OAM on ONT Ethernet interfaces 3-5
3.12 SNMP support for TL1 user management 3-5
3.13 OLT acts as an SNTP server 3-6
3.14 Global SSNAP modification 3-6

3.15 Multiple BFMU managers 3-6

3.1 Overview
This chapter is provided so that experienced 7342 ISAM FTTUusers can get updated
configuration and overview information for R04.08.00 features without having to
search throughout the documentation suite for that information.
3.2 Rogue ONT detection enhancements
You can now run a twice daily background rogue ONT detection monitoring
program to try and find ONTs that may cause problems on the PON. The background
rogue ONT detection monitoring also checks new ONTs added to a PON. When a
rogue ONT is detected, the OLT immediately disables the ONT to prevent PON
issues. By default, the rogue ONT monitoring test is disabled.
Use the DGN-ONT command mode parameter to enable or disable the background
rogue ONT detection test. Use the new RTRV-PON command BKGDROGUEONT
parameter to determine whether background rogue ONT detection monitoring is
enabled or disabled.
3.3 Security enhancements for SIP user name and password

modification
You can now change the SIPing server user name, password, and client ID without
having to delete and recreate the service using the TL1 SERVICE-VOIP command.
Now use ENT-SERVICE-VOIP to modify the SPGUNAME, CLIENTID, and
SPGPASS parameters.
3.4 OLT password security enhancement
You can now configure the OLT to prevent re-use of a password that was previously
used as a password. As well, you can configure the necessary length of a new
password to improve the quality of passwords picked by users. Using the TL1
SET-SECU-SYS command, the MINPASS parameter can be modified to set
minimum password length of 6 up to 32 characters, the PASSHIST parameter can
prevent re-use of a previous password, and SNMPSECURITY can be set to enable
read/write access to user security information by an SNMP manager. By default, this
user security information is inaccessible to an SNMP manager.
3.5 SIP improvements
You can now configure the release treatment applied when a port that has originated
a call remains off hook after the called party has hung up. Use the release_treatment
parameter to specify different methods of handling the situation.

3.6 Support for OISGv1 and OISGv2 VoIP provisioning
You can configure VoIP using the legacy, proprietary method used in R04.07.10 and
earlier, or you can use the standards-compliant OISGv2 provisioning. Each method
provides separate and unique TL1 commands, MIBs, XML parameters, and
OLT-to-ONT provisioning interfaces.
Set the VOIPCAPABILITY parameter of the ENT-ONT command to determine
whether the earlier OISGv1 method (ONT) is used or whether the new OISGv2
method (IPHOST) is used.
3.7 Background Type-A downloads
You can now have the Type-A software files automatically downloaded to all LT
cards installed in the 7342 ISAM FTTU when a new OSWP is downloaded. The file
download to each LT is ran in the background and is non-service affecting.
Pre-downloading of the Type-A files will reduce the service outage time when
performing a system software upgrade or software migration.
The autodownloadtolt parameter of the DL-OSWP command enables (default
setting) or disables the automatic background download of the Type-A files.
3.8 Video Rx sensitivity improvement and alarm update
To support improvements in RF video sensitivity at the ONT, the 7342 ISAM FTTU
has changed the RF video Rx dynamic range alarm reporting threshold from -9dBm
to -12dBm for all applicable alarms and management interfaces. The upper optical
threshold alarm (ALMHI) default has been changed to +1.0dBm.
TL1 commands that report optical power levels on the 1550 nm wavelength will now
display the levels in dBm units in addition to dBuW units.
3.9 Multicast Loss of Stream alarm enhancement
The enhanced multicast monitoring mode enables the monitoring of all active
multicast streams (up to 1024) and generate the MCASTLOSS alarm when loss of
traffic is detected.
The previous on demand monitoring of eight (8) multicast sources, now referred to
as legacy mode, is still supported but is limited to monitoring multicast streams at the
LT card if enhanced mode is enabled.
3.10 Jitter, latency, RT performance report
Additional functionality is supported for Ethernet OAM messages. A ONT-UNI

MEP can be configured to respond to a Peer-MEP, located at the Network Edge,
ETH-LM/DM messages. The ONT-UNI MEP will respond with a
ETH-LMR/DMR-PDU containing information that the Peer-MEP can process to
calculate loss, delay or jitter values.

3.11 802.3ah OAM on ONT Ethernet interfaces
You can now enable fault and performance management over the Ethernet interface
between the ONT and the RG in the subscriber access network. The EFM OAM
management supports discovery and variable retrieval functions in accordance with
802.3ah standards. Functions that are supported for this release are:
• Discovery of a RG (in active or passive mode)
• Transmit OAMPDU to RG
• Send Variable Request to RG
• Receive Variable Response from RG
• Receive Variable Request from RG
• Send Variable Response to RG
• Receive event notifications from RG (ONT sends alarm to OLT using OMCI)
New TL1 commands

TL1 commands have been added to support EFM OAM functions:
• ED-EFMOAM - to enable the application and set operational parameters
• RTRV-EFMOAM - to view the configuration of the EFM OAM
• RTRV-EFMOAM-LOCALINFO - to view the configuration and operational
state at the ONT
• RTRV-EFMOAM-PEERINFO - to view the configuration and operational state
at the RG
• REPT-OPSTAT-EFMOAM - to view the operational statistics of the ONT
Ethernet interface
• TST-EFMOAM-MAC - to view the operational statistics of the RG Ethernet
interface
New alarms
Alarms that have been added are:
• CPELF - received Link Fault indication reported by RG
• CPEDG - received Dying Gasp indication from RG
• CPECE - received Critical Event indication from RG
3.12 SNMP support for TL1 user management
You can now enable the 7342 ISAM FTTU to allow TL1 user accounts to be
managed by a SNMP manager. When user accounts are set or modified through the
5520 AMS GUI, the information shall also be updated in the OLT.

The feature is enabled globally at the OLT using the TL1 command
SET-SECU-SYS, using the new parameter SNMPSECURITY. With SNMP security
enabled, read and write access is granted to the user security tables if the SNMP
transactions are SNMPv3 with authentication and privacy. The SNMP manager can
perform the equivalent of the following commands:
• ENT/ED/DLT/RTRV-SECU-USER
• ED/RTRV-SECU-CID
• ED/RTRV-SECU-CMD
• SET/RTRV-SECU-SYS
• ED-SECU-PID
• RTRV-SECU-UPC
If a SNMP command is received that is not encrypted, it will be rejected but if

subsequent encrypted commands are received they will be allowed.
3.13 OLT acts as an SNTP server
You can enable the SNTP Proxy server application on GLT4 cards and configure a
SNTP proxy enabled VLAN to respond to all unicast SNTP request messages
originating from ONTs or downstream SNTP client applications. The feature can be
enabled on a maximum of 3 S-VLANs using the TL1 commands
ED/ENT-PONVLAN.
3.14 Global SSNAP modification
You can now edit the network address profile to specify a new network address for
the iConfig server used by the ONT for additional SIP configuration information.
A TL1 command has been added, ED-PROFILE-NWADDRSCS, to support the
modification of the network address and the version number of an existing profile.
Modification of the network address triggers the OLT to send an updated network
address to all ONTs that are using the profile that was edited.
New parameters that have been added to existing TL1 commands are:
• VERSION - added to ENT/RTRV-PROFILE-NWADDRSCS to specify the
version of the particular profile
• REFCOUNT - added to RTRV-PROFILE-NWADDRSCS to indicate if any
entities are currently using this profile. If the profile is in use it cannot be deleted.
3.15 Multiple BFMU managers
You can now use a one shot on-demand background fast MIB upload that can run in
parallel with the scheduled PM data collection BFMU. This Direct Fast MIB Upload
is triggered by a SNMP request, setting the MIB object “asamBfmuState” to
initiated. This triggers the collection of data from the OID s that are identified in the
configuration text file.

The manager uses xFTP to transfer the configuration text file to the
7342 ISAM FTTU and to retrieve the data collection GZIP file from the NE.


4— Application notes
4.1 Overview 4-2
4.2 Release FGU 04.04.xx application notes 4-2
4.3 Release FGU 4.3.5 application notes 4-3
4.4 Release FGU 4.3.0 application notes 4-3
4.5 Release FGU 4.2 application notes 4-4

4.1 Overview
This chapter provides a brief description application notes of interest to

7342 ISAM FTTU users. These application notes were first reported in the
7342 ISAM FTTU Customer Release Notes for the FGU release.
See the 7342 ISAM FTTU ONT Product Information Manual for application notes
for ONTs.
4.2 Release FGU 04.04.xx application notes
Table 4-1 describes the application notes for 7342 ISAM FTTU FGU 04.04.xx
releases.
Table 4-1 Application notes for FGU 04.04.xx
Application note Details Reference
Hardware considerations
Equipment considerations. The OLTS-L only accepts the EHNT-B, AACU, GLT2-C, and See the 7342 ISAM FTTU
the GLT4-A for R04.04.00 and later. The OLTS-K only P-OLT Hardware
accepts the EHNT-A, GLT2-C, GLT2-B, and the ACCU-C Installation and
cards. Maintenance Guide
Initialization
Forwarding table retrieval When the LANX is down or resetting in a simplex system, —
the L2 forwarding tables cannot be retrieved until the NE
is back in service and the audit of LT cards is complete.
Provisioning
The hot reset command does not The command INIT-SYS::LT-1-1x:::5 is not performed if See the 7342 ISAM FTTU
apply to GLT2 cards. entered. TL1 Commands and
Messages Reference
Session and marker profiles Session and marker profile editing is not supported. The See the 7342 ISAM FTTU
network manager does not inhibit modification of these TL1 Commands and
profiles. Changing these profiles is service affecting. Messages Reference
GLT4 card editing Editing a GLT4 card to a GLT2 card is not supported. —
OAM MP support The maximum number of MPs supported is 200. —
Services
Operator-triggered switchovers If all four active ports are on the active NT, and all four —
standby ports are on the standby NT, performing an
operator-triggered switchover may result in traffic
interruption for less than 3 s.
PQ profiles. Changing PQ profile for any service requires configuration See the 7342 ISAM FTTU
of the queues on the ONT. It is advisable not to make such P-OLT and ONT Operations
fundamental changes during operation of the ONT. If such and Maintenance
changes are required, make sure the ONT is reinitialized Procedures
immediately for the changes to take effect.
Other
Management channel The outage time of the TL1 management channel —

following a system reset is 15 min on a fully provisioned
system.
(1 of 2)

ACCU port. The port does not auto-negotiate the speed to 10 Mbps. —
It operates at 100 Mbps full or half duplex. Set the
terminals connected to the port to 100 Mbps.
Inhibit switchover note Before applying inhibit switchover on a standby NT, shut —
down the network port to avoid traffic loss.
(2 of 2)
4.3 Release FGU 4.3.5 application notes
Table 4-2 describes the application notes for 7342 ISAM FTTU FGU 4.3.5.
Table 4-2 Application notes for FGU 4.3.5
Initialization
You must configure the network If you use CLI to log in, then reset the system time and See the 7342 ISAM FTTU
time and date before using CLI date, all CLI account passwords immediately expire. CLI Commands Guide
to log in.
Services
Static multicast streams are not The provisioning of a static multicast stream does not fail —
included in the PON multicast due to exceeding the maximum allowed PON bandwidth.
CAC calculation.
Do not use the TSLOTMAP Use the TSLOTMAP parameter in the ED-SERVICE-CESPW See the 7342 ISAM FTTU
parameter to increase or TL1 command to rearrange DS0s. TL1 Commands and
decrease the number of DS0s to Messages Reference
carry on a CES pseudo wire
service.
4.4 Release FGU 4.3.0 application notes
Table 4-3 describes the application notes for 7342 ISAM FTTU FGU 4.3.0.
Table 4-3 Application notes for FGU 4.3.0
Initialization
Ethernet interface state When the operational state of network-bound Ethernet —

reporting interfaces is down, changes to the interface’s
administrative state are not reported to the management
system.
Provisioning
(1 of 2)

802.1x session timeouts Changes to the 802.1x session timeout value does not See chapter 20.
apply to existing sessions, but does apply to subsequent For timeout value
sessions. If the session timeout value is set to 0, existing information, see the
sessions do not time out. These sessions must be deleted 7342 ISAM FTTU CLI
to force a new session to use the non-0 value. Commands Guide
Services
Performance monitoring • When both port- and VLAN-specific, and flow-specific See chapter 19
counters are enabled for the same port, only the
flow-specific counter is incrimented.
• Ethernet counters on the network interface are not
initialized after 15-minute interval counter retrieval.
OAM
RMON counter restriction The etherStatsDropEvents RMON counter on an NT See chapter 19

network port does not increment for packet discards
(2 of 2)
4.5 Release FGU 4.2 application notes
Table 4-4 describes the application notes for 7342 ISAM FTTU FGU 4.2.
Table 4-4 Application notes for FGU 4.2

Hardware considerations
Certification testing of The P-OLT equipment has completed UL, FCC, NEBS1, See the appropriate safety
hardware and CE certification. information at the
Certification of NEBS Level 3 functionality is currently beginning of each
ongoing by a third-party testing facility. 7342 ISAM FTTU document
for more information.
Detailed test reports can be made available on request.
Thermal limitations Thermal limitations limit the maximum number of ALTS-N —

shelves on rack to two.
Use of non-Alcatel-Lucent SFPs Do not use unauthorized SFPs or XFPs. Such misuse See DLP 110 in the ETSI
and XFPs adversely affects the P-OLT and requires operator 7342 ISAM FTTU P-OLT
intervention. Authorized SFPs and XFPs are labeled with Hardware Installation and
the Alcatel-Lucent brand and approved CLEI codes. Maintenance.
If an SFP or XFP is replaced with an authorized SFP or XFP, See “EHNT and pluggable
run the following CLI command to synchronize the port optical modules unit data
state: sheet” for identification
tables listing the CLEI
configure interface shub port codes for authorized SFPs
<port-number> admin-status down and XFPs.
configure interface shub port

<port-number> admin-status up
Initialization
(1 of 3)

Compliance with RADIUS FGU 4.3 is compliant with the RADIUS protocol as defined See section 20.4 for more
protocol by the RFC 2865. information about RADIUS
The operation of the RADIUS implementation is servers.
compatible with the RADIUS server available from
Juniper Networks (formerly FUNK Software Inc), and the
SteelBeltedRADIUS server version 5.03 on the UNIX
system with Solaris v2.8.
Refer to the RADIUS server manuals for details regarding
the configuration of the RADIUS server dictionary
information.
No support of concurrent SFTP The P-OLT supports a single SFTP transfer at a time. Do —
transfers not perform concurrent transfers.
Changing NT interfaces from The NT board must be reset to activate changes when the DLP 104 in the
manual IP to BOOTP NT interface configuration is changed from manual IP to 7342 ISAM FTTU P-OLT
BOOTP. Software Installation
Procedures
NT boards in a redundant system Do not manually pull out the active NT in a redundant See DLP 110 in the ETSI
system for at least 60 s after issuing a provisioning 7342 ISAM FTTU P-OLT
command. Hardware Installation and
Maintenance.
Provisioning
Alarm application notes • the SWCAP alarm is raised for the second NT card See chapter 9
when the system is configured in simplex NT mode
• the SWCAP alarm is raised when Shub data is
provisioned, while the two NTs are synchronized;
however, the alarm will not be seen if the amount of
provisioning is minimal
• to avoid excessive P-OLT loading, clear all
extraneous ONT alarms by setting inactive ONTs
out-of-service
GigE links and RSTP • when two or more GigE links are used to connect the See DLP 114 in the ANSI or
P-OLT to an upstream switch, ensure ETSI version of the
auto-negotiation is enabled on the 7342 ISAM FTTU 7342 ISAM FTTU P-OLT
and the upstream switch Software Installation
• configure the bridge priority of the Shub greater than Procedures.
32678 to ensure the upstream switch is always the See chapter 16
root bridge in an RSTP configuration
• GigE links between a GenBand G6 and a Layer 2
switch should not be enabled for STP, RSTP, or link
aggregation
PPOoE Option 82 slot numbering Slot numbering begins at 3 on the 7342 ISAM FTTU. See chapter 10
Actions when maximum number When the MAXMACNUM value is reached, the LT receives See the appropriate
of unicast MAC addresses messages indicating that the maximum number of unicast service provisioning DLP in
reached MAC addresses has been exceeded for the ONT. the 7342 ISAM FTTU ONT
This causes anti-spoofing mechanisms to disable the port. Software Installation
The port recovers automatically when the P-OLT detects Procedures
no further messages from the additional MAC address.
Time to Live parameter for Set the TTL to greater than two for multicast traffic sent See DLP 109 in the
multicast traffic to the P-OLT. 7342 ISAM FTTU P-OLT
Software Installation
Procedures
Other
(2 of 3)

SanDisk and NT cards • when replacing a defective NT due to hardware See DLP 102 in the
failure, the SanDisk in the new NT should be replaced 7342 ISAM FTTU P-OLT
with the SanDisk from the defective NT Software Installation
• reset the system when a SanDisk is replaced Procedures
MAC filters When both specific and generic MAC filter counters are See chapter 15
enabled for the same port and VLAN, only the specific
counter is incrimented.
(3 of 3)

5— Functional description
5.1 Overview 5-2
5.2 7342 ISAM FTTU system architecture 5-2
5.3 P-OLT functional blocks 5-2
5.4 V-OLT functional blocks 5-9

5.1 Overview
This chapter provides a functional description of the 7342 intelligent services access
manager fiber to the user (7342 ISAM FTTU) P-OLT and V-OLT system
components, which are typically installed at the CO or CEV.
5.2 7342 ISAM FTTU system architecture
The 7342 ISAM FTTU provides a gigabit passive optical network (GPON)-based
access network and has three main components:
• the packet optical line termination (P-OLT) unit that provides the central
switching, processing, and control functions
• the video optical line termination (V-OLT) unit that provides the processing and
distribution of video services
• the optical network terminal (ONT) unit that provides local switching,
processing, and control functions.
See the 7342 ISAM FTTU ONT Product Information Manual for functional
descriptions of the ONTs, which terminate services from the GPON at the
subscriber’s premise.
5.3 P-OLT functional blocks
The P-OLT consists of two main functional blocks:

• network termination (NT)
• line termination (LT)
Figures 5-2 and 5-3 show the functional blocks of the P-OLT.

Figure 5-1 P-OLT functional blocks with EXNT and GLT8-A
Management/craft interface Network interface
Network termination Line termination
ACU
LT cards (1-18)
NT card A Software
OBC TM
OBC 200-GE FPGA
layer 2
Software switch PONS
40-GE Sanibel
XAU (IWF & GPON MACS)
Software Software
200-GE Software
OBC OBC layer 2
switch
NT card B
23729
Figure 5-2 P-OLT functional blocks with an EHNT
ACU NT I/O module
NT card A Software LT cards (1-16)

OBC OBC 48-GE Local GPON
EHNM eHCL GLOB
layer 2 switch
Software switch EHLM
FPGA
10-GE Software
XAUI
Software Software
eHCL
48-GE
layer 2 EHNM
OBC OBC
switch
NT card B
18404

Figure 5-3 P-OLT functional blocks with an EXNT
ACU NT I/O module
NT card A Software LT cards (1-16)

OBC OBC 200-GE Local GPON
layer 2 eHCL 2 GLOB
switch
Software switch
FPGA
20-GE Software
XAUI
Software Software
eHCL 2
200-GE
OBC OBC layer 2
switch
NT card B
23383
The functional blocks are built on the platform with tiers of software applications,
including communication and management protocols, core service and management
applications, and transport applications.
Network termination
The NT functional block contains a pair of NT cards and ACU cards that provide the
following key functions:
• layer 2 switching • network synchronization

• NT redundancy • connections
• control and management
Layer 2 switching
The NT and LT cards work together to provide the layer 2 switching function. The
NT cards provide the layer 2 virtual local area network (VLAN) bridging
management function. This function controls port mappings, including
user-to-network interface (UNI)-to-bridge port and GPON encapsulated module
(GEM) port-to-VLAN mapping. The LT cards provide layer 2 switching in either
cross-connect or residential bridge mode.
Physical UNIs that do not have a direct association with a bridge port, such as the
plain old telephone service (POTS) UNIs, are not included in the UNI-to-bridge port
mapping.

NT redundancy
The two layer 2 switches are provisioned for load sharing. Under normal
circumstances when both NT cards are operational, the on-board controller (OBC)
on the primary layer 2 switch functions as the master that controls the operation of
both switches.
Control and management

The layer 2 switch has an OBC that is dedicated to controlling the Internet protocol
(IP) routing functions. The switch is managed separately from the NT card. The
switch has its own management information base (MIB) that can be accessed directly
using simple network management protocol (SNMP) via a supported network
management system, or indirectly using transaction language 1 (TL1) or command
line interface (CLI).
The OBC on the primary NT cards controls the functioning of the entire P-OLT shelf.
The NT OBC has a fast Ethernet (FE) link that connects to the peer OBC on the layer
2 switch to synchronize the databases. The NT OBC has its own MIB that can be
accessed directly using SNMP via a supported network management system or
indirectly using TL1 or CLI. The MIB controls the applications that are related to the
P-OLT shelf.
The NT OBC determines which layer 2 switch is active or functions as the master,
based on the link failure indication from the layer 2 switch or other board fault
conditions.
Network synchronization
The 7342 ISAM FTTU system must be synchronized to a network timing reference
to support synchronization-sensitive services, such as voice, video and circuit
emulation service (CES). The system can be configured for network synchronization
using either the building integrated timing supply (BITS) interface or the IEEE
1588v2 capabilities of the EXNT network interface. Both timing configurations
support clock redundancy with redundant NT cards in the system.
The P-OLT system clock on the NT card is synchronized to the configured network
timing reference. The system clock is distributed to the LT interface, which
synchronizes the PON output clock with the timing reference. The ONTs derive the
timing for voice, video and CES traffic from the PON clock, which is traceable to the
network timing reference.
The clocking is used to drive the transmit side of the interface. The effect of timing
on a network is dependent on the nature of the type of traffic carried on the network.
With bit-wise traffic, for example, traditional circuit-based voice or video,
non-synchronous transmissions cause a loss of information in the streams. This can
affect performance. With packet-based traffic, the applications expect and handle
jitter and latency inherit in packet-based networks. When a packet-based network is
used to carry voice or video traffic, the applications use data compression and
buffering to compensate for jitter and latency. The network itself relies on QoS
definitions and network provisioning to further minimize the jitter and latency the
application may experience.
Note — For P-OLTs deployed remotely from a central office (CO),
the service provider should plan to use the IEEE 1588v2 network
timing reference at the remote location to ensure proper
synchronization of the P-OLT and its ONTs.

Connections
The EHNT card uses a point-to-point Ethernet-based high capacity link (eHCL)
track on the P-OLT backplane to carry up to 2 Gb/s of unicast, multicast, and in-band
management traffic to each LT (up to 4 Gb/s from both NT cards). A 10 gigabit
Ethernet (GE) attachment unit interface (XAUI) is used between the two NTs.
The layer 2 switch provides 48 GE ports and two 10-GE ports. The ports provide the
following functions:
• Upstream or network interfaces: four 1-GE ports and one 10-GE port terminate
on the front panel to provide an interface to the Ethernet metropolitan area
network (E-MAN).
• Downstream or user interfaces with two-port LT cards: a maximum of 32 ports
terminate at the back panel to provide interfaces for the LT cards. Each LT card
requires two GE ports.
• Downstream or user interfaces with four-port LT cards on an OLTS-M shelf: a
maximum of 56 ports terminate at the back panel to provide interfaces for the LT
cards. Each LT card requires four GE ports.
• NT redundancy connection: one 10-GE port provides an interface to the
redundant NT card for load sharing and communication associated with the
forwarding database.
• NT OBC and layer 2 switch OBC connection: one GE port of the switch matrix
provides an interface between the OBC on the NT card and the OBC on the layer
2 switch.
• NT I/O: four ports are available in ETSI shelves for expansion.
The EXNT card uses a point-to-point Ethernet-based extreme capacity link (XAUI)
on the P-OLT backplane to carry up to 10 Gb/s of unicast, multicast, and in-band
management traffic to each LT (up to 20 Gb/s from both NT cards). Two 10 gigabit
Ethernet (GE) attachment unit interfaces (XAUI) are used in the shelf backplane
between the two NTs.
The layer 2 switch provides 1-GE ports and 10-GE ports. The ports provide the
following functions:
• Upstream or network interfaces: two 1-GE ports and two 10-GE ports terminate
on the front panel to provide an interface to the Ethernet metropolitan area
network (E-MAN).
• Downstream or user interfaces with two-port LT cards: a maximum of 28 ports
terminate at the back panel to provide interfaces for the LT cards. Each LT card
requires two GE ports.
• Downstream or user interfaces with four-port LT cards on an OLTS-M shelf: a
maximum of 56 ports terminate at the back panel to provide interfaces for the LT
cards. Each LT card requires four GE ports.
• NT redundancy connection: one 10-GE backplane connection provides an
interface to the redundant NT card for load sharing and communication
associated with the forwarding database.
• NT OBC and layer 2 switch OBC connection: one GE port of the switch matrix
provides an interface between the OBC on the NT card and the OBC on the layer
2 switch.
• NT I/O: four ports are available in ETSI shelves for expansion.

Management console
The management console provides the operations, administration, and maintenance
(OAM) functions. The management console for the P-OLT system can use a local
craft port or remote network (in-band) connection. A local management console uses
the local craft port that is located on the faceplate of the alarm control unit (ACU)
card. A remote management console uses the network connection to the NT cards.
See chapter 7 for more information.
Line termination
The P-OLT provides the LT function using the LT cards. The LT card provides the
following main functions:
• interfaces to the GPON
• interfaces to the NT cards
• layer 2 switching
• card control and management
Interfaces to GPON
Each LT card provides interfaces to the GPON. The GPON interface supports
forward error correction (FEC) and Raman reduction.
The LT card requires the use of FEC to obtain its full optical link budget on Class C+
optics. FEC support is enabled or disabled using TL1 commands. For more
information about the TL1 commands, see the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI.
Occasionally, when fiber and equipment in the GPON network are shared, Raman
effect can occur where signals cross over from downstream digital signals in the
lower spectrum and cause visible lines on overlaid broadcast radio frequency (RF)
video signals. The effect is usually more prominent in the low end video channels
that are in the 1550 to 1560 nm range.
You can enable Raman crosstalk reduction for each optical GPON link on the LT
card that is installed in the P-OLT using the TL1 interface. Raman crosstalk
reduction is disabled by default. For more information about enabling or disabling
Raman crosstalk reduction, see the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI.
Raman crosstalk reduction is a feature to reduce the power fluctuation of the intensity
of the baseband 1490nm wavelength interference to the 1550nm. This is done by the
system by continuously sending idle data when user data is not being sent so that the
power spectral density of a signal carried by at least one channel is shifted in order
to reduce the crosstalk.

PON fiber feeder protection
The four PON LT cards can be configured for 1+1 fiber protection. A maximum of
two protection groups are supported on each LT card, PON-1 and PON-2 for a
protection group and PON-3 and PON-4 for the other group. Diverse routing of the
two fibers is required so that a single incident does not damage both fibers. Down
stream the two fibers will connect to a 2:N optical splitter for signal distribution to
the ONT units.
For more information about PON fiber feeder protection configuration and
management, see the 7342 ISAM FTTU Operations and Maintenance Procedures
Guide using TL1 and CLI.
Interfaces to NT cards
Each LT card interconnects with the NT cards through redundant communication
links. The type of communication link is dependant upon the NT card type in the
shelf.
With the EHNT installed the eHCL link is used. An eHCL is an Ethernet
packet-based interface that provides point-to-point transmission to and from the NT
cards for network access. The eHCL links supports a throughput capacity of 4 Gb/s
in receive (Rx) and transmit (Tx) to the NT cards.
With the EXNT installed the XAUI link is used. An XAUI is an Ethernet
packet-based interface that provides point-to-point transmission to and from the NT
cards for network access. The XAUI links, on the two port LT cards, supports a
throughput capacity of 5 Gb/s in receive (Rx) and transmit (Tx) to the NT cards. The
XAUI links, on the four port LT cards, supports a throughput capacity of 20 Gb/s in
receive (Rx) and transmit (Tx) to the NT cards.
Layer 2 switching
The LT functional block provides the layer 2 switching specific to the access
environment by supporting cross-connect mode and residential bridge modes. The
LT block serves as a layer 2 switch that is independent of the NT block, which serves
as a standard bridge. Both the LT and NT learn and age independently on media
access control (MAC) addresses.
The LT block also provides multicast traffic duplication. Multicast duplication on the
LT card can increase the efficiency of the bandwidth on the eHCL links between the
NT cards and LT cards. Each PON can simultaneously support up to 2.4 Gb/s of
multicast with this approach, although the NT to LT capacity is 4 Gb/s.
The LT functional block provides the GPON management function that controls the
transport functions, such as setting up the GEM flows on the PON. The GPON
management function establishes association between slots, ports, or services and
UNIs. The LT card conveys transmission container (T-CONT) to allocation
identification (ID), port ID and priority-bit mapping and quality of service (QoS)
information to individual ONTs. T-CONTs are used to manage the upstream
bandwidth allocation in the PON section of the transmission convergence layer. The
ONTs use the T-CONTs and the dynamic bandwidth assignment to request upstream
bandwidth. T-CONT type 5 accommodates QoS. Fixed bandwidth is derived from
the sum of all provisioned bandwidth for the port IDs within the T-CONT.

Control and management

The LT OBC sends ONT management information through the OAM VLAN to the
NT cards. The information includes alarm and state change events that occur on the
ONTs supported by the LT card.
When 802.1x sessions are set up at the LT card, authentication is requested via the
NT, using input/output channel manager (IOCM) internal communication. The LT
initiates and controls the IOCM communication.
Even though the aging timer is independent on the NT and the LT card, for proper
operation, it should be configured the same. The aging timer on the LT card is
common for all line interface modules (LIMs).
5.4 V-OLT functional blocks
The 7342 ISAM FTTU uses the V-OLT to distribute video signal from service
providers across the PON to the ONTs. The V-OLT uses erbium doped fiber
amplifiers (EDFA). The distribution requires wavelength division multiplexer
(WDM) to be overlaid into the fiber path. The WDM function is provided through
the video coupler.
RF video signal distribution

The distribution of the optical video signal is described as follows:
• The V-OLT receives an incoming wavelength optical signal with embedded
video channels through a fiber path from the cable TV head-end equipment.
• The V-OLT amplifies and splits the optical signal into multiple optical feeds to
the video coupler.
• The video coupler merges the video signal over the fiber paths.
• The fiber paths carry the optical signals between the P-OLT and PON and the
ONTs that are associated with the PON.
RF video services
The V-OLT supports the full cable television (CATV) spectrum from 47 MHz to 862
MHz.
The V-OLT supports most of the CATV service options, such as video on demand
(VOD), interactive video for games, and standard or premium analog and digital
channels. Access to video services may require a set-top box (STB) between the
video output of the ONT equipment and customer premises equipment (CPE).
The 7342 ISAM FTTU provides Raman crosstalk reduction if distortion, caused by
downstream digital data signals on the GPON network, is visible on the lower
spectrum video channels. See the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI for more information about enabling and
disabling Raman reduction. See section 5.3 for a description of Raman reduction.

Upstream signal and data channels

An Ethernet connection between the set-top box and the local area network (LAN)
port is required to provide a upstream signaling channel. This channel carries service
requests through a separate virtual channel between the ONT and the P-OLT. The
upstream data channel uses one of LANs available at the ONT.
RF video service management

The V-OLT requires a separate element management system (EMS) to control video
output signals from the V-OLT equipment.
For subscribers to access video services, the ONTs can be provisioned remotely
using a supported network management system.

6— Equipment layout
6.1 Overview 6-2
6.2 P-OLT equipment layout 6-2
6.3 V-OLT equipment layout 6-9
6.4 Video coupler equipment layout 6-9
6.5 ONT equipment layout 6-12

6.1 Overview
This chapter describes the layout of the 7342 ISAM FTTU physical equipment.
The 7342 ISAM FTTU system provides an access network based on the gigabit
passive optical network (GPON) technology, using the following equipment:
• central office (CO) equipment:
• packet optical line termination (P-OLT) equipment
• video optical line termination (V-OLT) equipment (required when radio frequency
(RF) video service is supported)
• video coupler (required when V-OLT is supported)
• customer premises equipment: optical network terminals (ONTs)
6.2 P-OLT equipment layout
The P-OLT equipment is typically located in a CO or in a controlled environment

vault (CEV). Each P-OLT consists of one optical line termination (OLT) shelf,
mounted in an equipment rack. The OLT equipment rack contains:
• top rack unit (TRU)
• one or more OLT shelves
• one fan unit per shelf
• rack power cable
• rack alarm cable
OLT rack
The OLT rack can accommodate a maximum of two P-OLT shelves and one TRU,
which distributes power and collects alarms.
The following TRUs are supported:
• ATRU-M
• ATRU-N
• ATRU-U
Figure 6-1 shows a P-OLT (ALTS-N) and ATRU-M installed in an equipment rack.
Figure 6-2 shows two P-OLT shelves (OLTS-M) and ATRU-U installed in an
equipment rack.

Figure 6-1 Rack mounted ATRU-M and P-OLT (ALTS-N) with cover attached
ATRU-M
IR
C
JA
M
NI
M
EG SU SAU
F
UR ATL
TA OV
-R 01
W
P
1R
S
2R 02
S
RB
TS LB 02
ET RA
LA
03
A1/4
A
A2L
/30A SAU
A2R 01
/30A
02
A3/4
A
02
03
A1/4
A
A2L
/30A
A2R
/30A
A3/4
A
P-OLT with
cover installed
18834

Figure 6-2 Rack mounted ATRU-U and P-OLT (OLTS-M)
SAU 01 02 FAN1 FAN2 SAU 01 02 FAN1 FAN2
CRI
MAJ
MIN
GTRU-B
FUS
VOLTAGE
PWR-ATRU ESD
PWRB1 PWRB1
PWRB2 PWRB2 ARTH
E
UNUSED UNUSED
B ON
INT
TEST
O
D
ING P
CB\A A01/35 A02/35 A04/6 AO5/6 CB\B B01/35 B02/35 B04/6 BO5/6
P-OLT shelf 2
with cover
installed
SOLID
FAN UNIT STATUS
BLINKING
GREEN - INITIALIZING
GREEN - ACTIVE
RED - FAN FAILURE
AMBER - OVER TEMPERATURE
Fan shelf 2
P-OLT shelf 1
with cover
installed
SOLID
FAN UNIT STATUS
BLINKING
GREEN - INITIALIZING
GREEN - ACTIVE
RED - FAN FAILURE
AMBER - OVER TEMPERATURE
Fan shelf 1
19345
OLT ALTS-N shelf

The ALTS-N optical line termination (OLT) shelf is the frame in which the cards and
other units that comprise the P-OLT are installed. The shelf is mounted in a rack.
Figure 6-3 shows a P-OLT (ALTS-N).

Figure 6-3 OLT shelf with cards, fan tray, and fiber routing tray installed
Energy Hazard
AACU-C EHNT EHNT GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A GLT2-A
ALM PWR ACT ALM PWR ACT

CRI PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR PWR
MAJ ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM ALM
ALM ACT ALM PWR ACT
MIN
ALM
ACO
623.75 mm
ETHERNET
CRAFT
247.2 mm 497.4 mm
284.5 mm 515 mm
529.4 mm
18835
The ALTS-N shelf has three main areas:

• cable routing and shelf connector area
• card cage
• fan tray
The card cage is the large central area of the shelf that accommodates plug-in cards,
including, from left to right, 1 ACU slot, 2 NT slots (NTA and NTB), and 16 LT
slots. Blank filler plates are installed in any empty slots in the card cage area. The
MAC address for the shelf is located on a label that is affixed on the left side of the
shelf, beside the ACU slot.
The topmost area of the shelf is the cable routing and shelf connector area, and a fan
unit is installed in the horizontal fan tray area along the bottom of the shelf.
The top rack unit (TRU) is a separate unit located above the shelf in the equipment
rack that distributes power and telco alarms to the shelf. The shelf distributes the
power to the fan unit and other components via the shelf backplane. A circuit breaker
for the fan unit is located in the TRU. As well, a GMT fuse in the TRU protects the
fan unit’s power circuit.

Individual fans in the fan unit have a non-field replaceable fuse to protect a short in
one fan from causing all fans to fail. If a single fan fails, the other fans automatically
compensate by adjusting their speed so that the proper air flow is maintained. Fan
speed also automatically adjusts according to the ambient temperature to save power
and minimize acoustic noise.
P-OLT OLTS-M shelf

The OLTS-M optical line termination (OLT) shelf is the frame in which the cards
and other units that comprise the P-OLT are installed. The shelf is mounted in a rack.
Figure 6-4 shows a P-OLT (OLTS-M).
Figure 6-4 OLTS-M shelf with cards installed
19.0158
18.3110
11.1181 17.2334
BATRET BAT A BAT B
GLT4-A GLT4-A GLT4-A GLT4-A GLT4-A GLT4-A GLT4-A GLT4-A GLT4-A EHNT-B AACU-C EHNT-B GLT4-A GLT4-A GLT4-A GLT4-A GLT4-A
PWR PWR PWR PWR PWR PWR PWR PWR PWR CRI PWR PWR PWR PWR PWR
UNIT
UNIT
ALM ALM ALM ALM ALM ALM ALM ALM ALM MAJ ALM ALM ALM ALM ALM
1 1 1 1 1 1 1 1 1 MIN 1 1 1 1 1
LNK TX RX LNK TX RX
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
2 2 2 2 2 2 2 2 2 GE-1 ALM GE-1 2 2 2 2 2
3 3 3 3 3 3 3 3 3 GE-2 ACO GE-2 3 3 3 3 3
NETWORK
NETWORK
4 4 4 4 4 4 4 4 4 GE-3 GE-3 4 4 4 4 4
GE-4 GE-4
10G 10G
O&M O&M
Tx Tx
Rx Rx
GE-1 GE-1
DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER DANGER
INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER INVISIBLE LASER
RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN RADIATION WHEN
DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED DISCONNECTED
AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT AVOIDE DIRECT
EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM EXPOSURE TO BEAM
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
24.4646
ETHERNET
GE-2 GE-2
GE-3 GE-3
CRAFT
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
GE-4 GE-4
10G 10G
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
19321
The OLTS-M shelf has three main areas:

• shelf power and connector area
• card cage
• cable routing tray

The card cage is the large central area of the shelf that accommodates plug-in cards,
including, from left to right, 9 LT slots (LT1 through LT9), 1 NT slot (NTA), 1 ACU
slot, 1 NT slot (NTB), and 5 LT slots (LT10 through LT14). Blank filler plates are
installed in any empty slots in the card cage area. The MAC address for the shelf is
located on a label that is affixed on the left side of the shelf, beside the LT1 slot.
The topmost area of the shelf is the power and connector area. Redundant -48 V dc
power feeds from the TRU supply the shelf with power. The BITS-B card is mounted
here and provides RJ-45 connectors for the BITS interface (primary and secondary)
and the LAN interface (out of band management). A DB-9 connector for the Craft 2
Interface, the Fan Alarm connector and a 50 pin D connector for the ACU alarm
cable is located in this area.
The top rack unit (ATRU-U) is a separate unit installed at the top of the equipment
rack that distributes power and telco alarms to the shelf. The shelf distributes the
power to shelf components via the shelf backplane.
A separate fan unit (AFAN-S) is located below the OLT shelf and provides forced
air cooling to the shelf components. If a single fan fails, the other fans automatically
compensate by adjusting their speed so that the proper air flow is maintained. Fan
speed also automatically adjusts according to the ambient temperature to save power
and minimize acoustic noise.
OLT shelf backplane

The backplane of the OLT shelf is a printed circuit board that provides connectivity
between the units used in the shelf. The backplane is preinstalled and is not field
replaceable.
The backplane provides two types of buses: the IQ buses and the HCL buses. The IQ
buses are used for timing distribution. The HCL buses are used for the eHCL signals
for all the data and control traffic.
For more information, see the 7342 ISAM FTTU Hardware Installation and
Maintenance Practices.
Cards in the OLT shelf

The OLT shelf contains NT, LT, and ACU cards.
NT cards
The NT cards support the layer 2 switching function and management function for
the P-OLT shelf where both the NT and LT cards reside. The P-OLT can be
configured to have a primary and secondary NT card for load sharing: NT card A and
NT card B.
The 7342 ISAM FTTU system supports two NT card types, which provide GE
optical connectivity to a high-bandwidth IP services network and support either
Ethernet high-capacity links (eHCL) or XAUI links to LT cards, dependant on NT
card type:
• EHNT-A and EHNT-B
• EXNT-A

For details on each NT card type, see the appropriate unit data sheets.
Optical modules
Table 6-1 provides information about the supported 1 GE and 10 GE pluggable
modules for the NT cards.
Table 6-1 Optical modules
Module Type Rate Wavelength (nm) Reach
SFP 1 GE Electrical 100 m
850 550 m
1310 10 km
1310 40 km
1550 80 km
XFP 10 GE Electrical 300 m
850 10k m
1310 40 km
1550 80 km
The NT cards are not shipped with the optical modules installed. The optical modules
are orderable items. See 7342 ISAM FTTU P-OLT Planning and Ordering Guide for
ordering information.
LT cards
The LT card provides connection between the NT card and the ONT at the customer
premises.
• For the connection to the ONTs, the LT card provides GPON interfaces. Each
GPON interface can support 32 or 64 ONTs, dependant on LT card type.
• For the connection to the NTs, the LT card provides either eHCL or XAUI
interfaces to the NTs, dependant on NT card type.
• For the connection to EHNT card types, the LT provides redundant eHCL busses.
The eHCL connections support a maximum of 4 Gb/s bidirectional bandwidth.
• For the connection to EXNT card types, the LT provides redundant XAUI busses.
The XAUI connections support a maximum of 10 Gb/s bidirectional bandwidth.
The optical implementation of the GPON can be optimized for different performance
and reach levels. The GLT2 card has two versions: GLT2-A and GLT2-B. The
GLT2-B version has increased size for both the GPON interface and the eHCLs to
support functions such as forward error correction (FEC). The GLT2-B also supports
the multicast duplication.The GLT4 card has two versions: GLT4-A and GLT4-D.
The GLT8 card has one version: GLT8-A.
For details on each LT card type, see the appropriate unit data sheet.

ACU card
The ACU card performs alarm control function for each shelf. The ACU card
provides alarm indication for CO alarms, telemetry alarms, and rack-level alarms.
The alarm indication are visual as well as audible.
The ACU card provides two RS-232 local craft ports and two Ethernet ports for
operations and maintenance activities. One craft port and one Ethernet port are
located at the ACU front panel. The other craft port and Ethernet port are located on
the backplane of the OLT shelf.
SANC-D unit
The SANC-D unit provides the building integrated timing supply (BITS) and local
network connection function for the ALTS-N shelf. In an NT card, the system clock
can be locked on one pair of BITS signals. The SANC-D unit receives two pairs of
BITS input signals through the front panel. These signals are routed through the
backplane to the associated NT unit. The primary NT unit received primary BITS
and the secondary NT unit receives secondary BITS.
BITS-B unit
The BITS-B card is mounted on the OLTS-M backplane at J67 and provides an
RJ-45 connector to connect the primary (PRI) BITS and secondary (SEC) BITS
timing references to the NT cards. A second RJ-45 connector on the cards provides
a 10/100 Mbps Ethernet interface.
The BITS-B card provides protection and attenuation for the BITS signals and also
provides termination for unused Ethernet signals.
FILT-A installation kit or FILT-B
The FILT-A installation kit is installed on the ALTS-N shelf and provides power
filtering. The power filtering is for the –48 V dc that is fed from the TRU. The
FILT-B comes pre-installed in the OLTS-M shelf.
6.3 V-OLT equipment layout
The V-OLT equipment is supplied by Scientific Atlanta. See documentation

provided by the supplier for more information.
6.4 Video coupler equipment layout
The video coupler equipment consists of a video coupler fiber rack, video coupler
shelves (VCSs), and video coupler WDM trays for 4 PONs (VCW4) or video coupler
WDM trays with splitters for 8 PONs (VCS8).

Video coupler fiber rack

The video coupler fiber rack is provided by Tyco. The rack can hold a maximum of
15 video coupler subracks, including one subrack for sparing. For more information
about the rack, refer to related Tyco documentation.
Video coupler shelf

The video coupler shelf is provided by Tyco or LGX. The shelf can hold a maximum
of three VCW4 trays. The subrack also provides cable routing management from the
VCW4 trays to the sides of the subrack.
Video coupler WDM tray

There are the following types of video coupler trays:
• VCW4
• VCS8
• VCSL
• VCW2
The VCW4 is provided by Tyco. The VCW4 tray is provided in pairs of left and right
trays. Each tray supports 4 PONs. A pair of trays supports 8 PONs. A video coupler
system using VCW4 trays requires a separate splitter rack to hold the splitters.
The VCS8 is provided by Tyco. The VCS8 tray is provided in pairs of left and right
trays. Each tray support 8 PONs. A pair of trays supports 16 PONs. The VCS8 tray
integrates the splitter into the tray and eliminates the need for a splitter rack.
The VCSL and VCW2 are provided by LGX.
Figure 6-5 shows the Tyco video coupler rack loaded with 14 shelves.

Figure 6-5 Tyco video coupler fiber rack

6.5 ONT equipment layout
In the 7342 ISAM FTTU system, multiple ONTs connect to LT units installed in the
P-OLT shelf over the GPON network. The ONT installs at the subscriber’s premises
and the P-OLT installs at the CO or CEV. ONT units provide a single entry point for
services at the subscriber’s premises. ONTs can provide multiple services to
single-family residences, small office, home office, and business users.
Note — The maximum number of ONT units that can be connected

to the PON is determined by the bandwidth utilization of each ONT
and the types of ONT units that are connected.
See the 7342 ISAM FTTU ONT Product Information Manual for more information
about ONT units, including the equipment layout.
ONT connection capacity

See the deployment planning chapter of the 7342 ISAM FTTU ONT Product
Information Manual for more information.

7— Operations, administration, and
maintenance
7.1 Overview 7-2
7.2 Management interfaces 7-2
7.3 EMS functions 7-5
7.4 Operations, administration and maintenance 7-6
7.5 Troubleshooting 7-7
7.6 OSMINE certification 7-7

7.1 Overview
This chapter provides information about the OAM functions of the

7342 ISAM FTTU.
The 7342 ISAM FTTU system is operated, administered, and maintained through an
interface provided by an element management system or by manually manipulating
the hardware components.
The operations and maintenance procedures you can perform with the
7342 ISAM FTTU system are documented in the 7342 ISAM FTTU Operations and
7.2 Management interfaces
A management interface allows the performance of management activities, such as

configuration, provisioning, alarm monitoring, and troubleshooting. The
7342 ISAM FTTU supports the following management interfaces for local and
remote management:
• the craft port or the Ethernet port on the AACU card for a locally connected craft
terminal; see Figure 7-1
• the craft 2 port on the P-OLT backplane for a remotely connected craft terminal,
as shown in Figures 7-2 and 7-3
• the Ethernet port on the P-OLT backplane for out-of-band connectivity to a
remotely connected craft terminal via a network management system through an
IP network
• a gigabit Ethernet (GE) port on the NT card for in-band connectivity to a remotely
connected craft terminal via a network management system through the IP
network
Figure 7-1 AACU-C craft and Ethernet connections
Craft terminal
port
AACU-C
ACO
ALM
MAJ
MIN
CRI
ETHERNET CRAFT
Ethernet port
18911

Figure 7-2 ALTS-N backplane craft and Ethernet connections
Remote Craft Port Lan connector

(RCFT)
Energy Hazard

ALM ACT ALM PWR ACT
MIN
ALM
ACO
ETHERNET
Local Craft
CRAFT
Interface
19680

Figure 7-3 OLTS-M backplane craft and Ethernet connections
Lan connector
BATRET BAT A BAT B
Craft 2
Interface
UNIT
UNIT
1 1 1 1 1 1 1 1 1 MIN 1 1 1 1 1
LNK TX RX LNK TX RX
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
2 2 2 2 2 2 2 2 2 GE-1 ALM GE-1 2 2 2 2 2
3 3 3 3 3 3 3 3 3 GE-2 ACO GE-2 3 3 3 3 3
NETWORK
NETWORK
4 4 4 4 4 4 4 4 4 GE-3 GE-3 4 4 4 4 4
GE-4 GE-4
10G 10G
O&M O&M
Tx Tx
Rx Rx
GE-1 GE-1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
ETHERNET
GE-2 GE-2
GE-3 GE-3
Local Craft
CRAFT
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
Interface
GE-4 GE-4
10G 10G
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
19679
Craft terminal
Management tasks for the 7342 ISAM FTTU can be performed using the CLI and
TL1 commands through local or remote connections to the craft terminal. The
P-OLT provides two craft interface options.
A craft interface is located on the AACU card in the shelf; see Figure 7-1. The craft
interface is an RS-232 interface with a DB-9 connector. The terminal end of the cable
can use either a DB-9 or DB-25 connector depending on the type of craft terminal
used. The craft interface on the AACU card is typically used for local access.
A remote craft interface is located in the connector area of the P-OLT shelf. This is
a DB-9 connector which is labeled RCFT (remote craft) on the ALTS-N shelf and is
labeled CRAFT 2 INTERFACE on the OLTS-M shelf. The other end of the cable
can use a DB-9 or DB-25 connector depending on the type of craft terminal, or
modem used. The craft 2 interface is typically connected to a modem that can be
remotely accessed.
Maintenance Practices and the 7342 ISAM FTTU Operations and Maintenance

TL1 and CLI access protocol options

The 7342 ISAM FTTU supports the following TL1 and CLI access protocol options:
• CLI via Telnet and SSH
• TL1 via Telnet, SSH, and UDP
Note 1 — The TL1 via Telnet option uses a non standard port. Contact
your local support representative to obtain the port number.
Note 2 — For information on enabling or disabling protocol access
for CLI or TL1, see the DLP for configuring SSH in the
7342 ISAM FTTU Operations and Maintenance Procedures Guide
using TL1 and CLI.
Ethernet ports on the AACU and the P-OLT backplane

The P-OLT provides two Ethernet ports that can be used for management tasks. One
Ethernet port is on the AACU and the other is on the P-OLT backplane. They can be
used as an Ethernet craft port or for out-of-band IP network connectivity to an EMS.
Only one Ethernet port can be used at a time.
The Ethernet port can be configured in the following ways:
• as a craft terminal when the inband management channel is through the GE ports
on the NT card
• for out-of-band management when the GE ports are used for data traffic only
• not used
Maintenance Practices and the 7342 ISAM FTTU Operations and Maintenance
5520 AMS connection options

Management tasks for the 7342 ISAM FTTU can be performed through the GUI
provided by the 5520 AMS. The 5520 AMS is remotely connected to the
7342 ISAM FTTU system through network connectivity to the GE ports on the NT,
or to the Ethernet port on the P-OLT backplane. TL1 and CLI cut-through options
are available.
For more information, see the 5520 AMS operations and maintenance guide.
7.3 EMS functions
The 7342 ISAM FTTU provides element management system (EMS) functions
through the 5520 AMS.

5520 AMS
The 5520 AMS is an element manager that delivers a complete management solution
for the 7342 ISAM FTTU platform.
The 5520 AMS supports the following management functions:
• configuration and productivity management, such as provisioning, software
download for network element equipment, backup and restore, and management
operations
• performance monitoring management, such as history data collection, storage,
and retrieval for the line units
• alarms and fault management, such as surveillance, notification control, and
alarm history for network elements
• security manager for network element access control, network management
system security control, and management privilege control
• database management, such as system data, software version, and database
backup
• GUI with high-level system, equipment, and table views
• advanced management for inventory, large-scale release updates, and
service-oriented troubleshooting
• advanced OSS integration capabilities
• scalability up to one million lines and 100 operator positions
The 5520 AMS allows the 7342 ISAM FTTU components that are far from the CO
to be managed from one location. After the component is installed, the 5520 AMS
remote functionality allows all of the local functionality to be accessible remotely.
GENIP service
an ONT general IP UNI, such as the 7353 ISAM FTTB ONU, that is controlled by
the 7342 ISAM FTTU. See chapter 29 for more information about GENIP service.
7.4 Operations, administration and maintenance
You can perform operation, administration, and maintenance tasks for the
7342 ISAM FTTU.
Hardware operation, administration, and maintenance tasks

Hardware operation, administration, and maintenance tasks for the
7342 ISAM FTTU include:
• powering up 7342 ISAM FTTU
• responding to LED indications
• replacing or adding cards
• troubleshooting physical symptoms

For more information about hardware operation, administration, and maintenance

tasks, see the 7342 ISAM FTTU Hardware Installation and Maintenance Practices.
ONT repair and return information

Repair and return information that is stored in volatile RAM at the ONT can be
retrieved from FLASH memory using an EMS management session with the P-OLT.
A push button on the ONT can also be used to collect the latest information. Once
initiated, the ONT information that is stored in RAM is saved to FLASH memory,
from which the information can be retrieved for viewing using the 5520 AMS.
7.5 Troubleshooting
The 7342 ISAM FTTU provides methods to collect information for troubleshooting,
including:
• local and remote CES loopbacks
• optical power level monitoring
• ping support on the GPON
• remote monitoring (RMON) Ethernet statistics
• statistics reports and performance monitoring counters
• system-generated alarms
• VoIP call statistics collection
See chapter 13 for more information about troubleshooting and fault isolation.
7.6 OSMINE certification
The 7342 ISAM FTTU is certified for operations systems modification for the
integration of network elements (OSMINE).


8— Technical specifications
8.1 Overview 8-2
8.2 P-OLT equipment 8-2
8.3 Video coupler equipment 8-3
8.4 System and service capacity specifications 8-4
8.5 GPON optical and RF line rates 8-13
8.6 P-OLT optical budgets 8-13
8.7 Video coupler optical budget 8-14
8.8 Environmental requirements 8-14
8.9 Power specifications 8-15

8.1 Overview
This chapter provides information about the technical specifications for the central
office equipment, including the packet optical line termination (P-OLT) and the
video coupler equipment.
Note — The video optical line termination (V-OLT) equipment is an

erdium-doped fiber amplifier (EDFA). For information about the
V-OLT equipment, see the EDFA customer documentation.
8.2 P-OLT equipment
Table 8-1 provides information about the P-OLT components.
Table 8-1 P-OLT components
Component Mnemonic Description
Shelf ALTS-N A standard shelf with an integrated fan unit
OLTS-M XAUI shelf without fan unit
Fan Unit AFAN-S Variable speed, redundant fans for OLTS-M shelf
cooling
Network termination EHNT-A 48 Gb/s NT card

(NT) cards EHNT-B 48 Gb/s NT card (OLTS-M only)
EXNT-A 200 Gb/s NT card (OLTS-M only)

Line termination (LT) GLT2-A, GLT2-B GPON LT with two GPON interfaces
cards
GLT4-x GPON LT with four GPON interfaces
GLT8-A GPON LT with eight GPON interfaces

SFPs and XFPs — Pluggable optical modules can be additional
components on supported units. See the
respective unit data sheets for SFP or XFP
technical information.
TRU Top rack unit, version M, version N, or version U

ATRU-M
ATRU-N
ATRU-U
Alarm control unit AACU-C Alarm control unit, version C
Table 8-2 lists the field-installable or field-replaceable units and the quantity
supported for the P-OLT.

Table 8-2 Installable and field-replaceable cards
Cards Quantity
Alarm control unit 1
Fan unit 1
NT unit 2
LT unit with two GPON interfaces 16 for ALTS-N
LT unit with four GPON interfaces 14 for OLTS-M
LT unit with eight GPON interfaces 14 for OLTS-M

Filler plate As required
Note — Filler plates must be installed in all unused NT or LT slots.

For information about ordering a filler plate, see the
7342 ISAM FTTU P-OLT Planning and Ordering Guide.
Table 8-3 lists the weight specifications of the P-OLT units.
Table 8-3 P-OLT unit weight specifications
Unit Weight
AACU-C 1.5 lb (0.68 kg)
AFAN-H 11.02 - 12.35 lb (5 - 5.6 kg)
AFAN-S 11.0 lb (5.0 kg)

ATRU-M 13.23 lb (6 kg)
ATRU-N 12.35 lb (5.6 kg)
ATRU-U 13.23 lb (6 kg)

NT 3.5 lb (1.59 kg)
GLT2 2.0 lb (0.91 kg)
GLT4 2.5 lb (1.13 kg)
GLT8 2.8 lb. (1.3 kg)
ALTS-N 62.61 lb (28.4 kg)
OLTS-M 37 lb (16.8 kg)
Rack 340 - 379 lb (154-172 kg)
8.3 Video coupler equipment
Table 8-4 describes the components of the video coupler equipment.

Table 8-4 Video coupler equipment
Component Mnemonic Description
Rack — Rack for video coupler
Shelf VCS Video coupler shelf
Video coupler VCW4-A Video coupler WDM tray supporting 4 PONs (VCW4)
Video coupler VCS8-A Video coupler WDM tray with splitters supporting 8 PONs
with splitters (VCW8)
8.4 System and service capacity specifications
This section provides information about the 7342 ISAM FTTU services and system
capacity specifications.
Service and system capacity

Table 8-5 lists the service and system capacity of the P-OLT.

Table 8-5 Service and system capacity
Description Maximum Notes
Maximum Ethernet frame size 2008 byte The exception is the GLT2-A, which supports an 1800 byte maximum
(GLT4-x) Ethernet frame size.
Maximum Ethernet frame size 2008 byte —

(GLT8-A)
User-to-network interfaces EHNT: 240 —

per NT card
EXNT: 288 —
VLANs
VLANs per system 4094 VLAN ID 2 to 4094. VLAN IDs 1 and 4095 are reserved by standard.
Residential bridge or 4089 VLAN IDs 1 and 4094 are reserved by standard.
cross-connect VLANs per Three other VLANs ID are required by the system for internal use:
system
• management VLAN
• stacking VLAN
• Trace and debug VLAN
Maximum VLANs per LT card GLT2: 260 System limit is the maximum number of VLANs per LT card
multiplied by the number of LT slots on the OLT shelf.
GLT4: 516
GLT8: 1028
MAC addresses
MAC addresses per LANX 16 384 This number combines static and dynamic MAC addresses.
system The sum of the MAC addresses learned on the each LANX port
(network ports + LT ports) can not be larger then 16384.
The limit of the allowed number of MAC addresses on the LANX has
to be considered when scaling the MAC addresses per LT, per ONT,
and per service.
Static MAC addresses per VLAN 16 000 If MAC learning is required on the LANX
147 456 If no MAC learning on the LANX (8192 * 18 EXNT)
Dynamic MAC addresses per
VLAN 73 728 If no MAC learning on the LANX (4096 * 18 EHNT)
MAC addresses per system
MAC addresses per bridgeport 2048 —
MAC addresses per logical-svc 2048 Sum of individual per service limits should not exceed maximum
MAC addresses per bridgeport
MAC addresses on LT
(1 of 7)

MAC address learning on LT — To learn a MAC address on a service on an LT, the LT has to create
a FIB entry for each p-bit value (0 to 7) that is configured on any of
the priority queues that are used in the priority queue profile of the
service.
Examples:
• A service uses a PQ profile with a single priority queue having all
p-bits mapped to the single queue would mean 8 FIB entries are
created on the LT for each learned MAC address.
• A service uses a PQ profile with 8 priority queues, and one p-bit
mapped to each of the 8 priority queues would mean 8 FIB
entries are created on the LT for each learned MAC address.
• A service uses a PQ profile with 2 queues. P-bit 0 is mapped to
queue 1. P-bits 4 and 6 are mapped to queue 2, which would
mean 3 FIB entries are created on the LT for each learned MAC
address.
• A service uses a PQ profile with a single priority queue having
only 1 p-bit mapped to that single queue would mean 1 FIB entry
is created on the LT for each learned MAC address.
MAC addresses per LT GLT2-x: 2048 Based on less than 576 UNIs per GLT2 × 4 MAC addresses per UNI
GLT4-x: 4096 Based on 288 UNIs per PON × 4 PONS per GLT4 × MAC addresses per
UNI
GLT8-A: 8192 Based on 288 UNIs per PON × 8 PONS per GLT8 × 4 MAC addresses per
UNI
FIB entries per GLT2-A 4096 There can only be 2048 FIB entries per PON.
FIB entries per GLT2-B, GLT-C 4096 There is no per PON limitation for this hardware. The 4096 FIB
entries can be split between PONs or on a single PON.
FIB entries per GLT4-x 8192 There is no per PON limitation for this hardware. The 8192 FIB
entries can be split between PONs or on a single PON.
FIB entries per GLT8-A 16,384 —
Maximum number of MAC Varies Depending on the number of p-bit values (0 to 7) that are mapped
addresses that can be learned to queues of the PQ profile of the services on which the MAC
per GLT2-A PON based on the addresses are learned. The numbers below assume that all services
number of p-bits mapped to on which a MAC address is learned have the same number of mapped
PQ profiles p-bit values:
• 8 p-bits = 256
• 7 p-bits = 293
• 6 p-bits = 341
• 5 p-bits = 410
• 4 p-bits = 512
• 3 p-bits = 683
• 2 p-bits = 1024
• 1 p-bit = 2048
(2 of 7)

(GLT2-B, GLT2-C) based on addresses are learned. The numbers below assume that all services
the number of p-bits mapped on which a MAC address is learned have the same number of mapped
to PQ profiles p-bit values:
• 8 p-bits = 512
• 7 p-bits = 585
• 6 p-bits = 683
• 5 p-bits = 819
• 4 p-bits = 1024
• 3 p-bits = 1365
• 2 p-bits = 2048
• 1 p-bit = 4096
(GLT4-x) based on the number addresses are learned. The numbers below assume that all services
of p-bits mapped to PQ on which a MAC address is learned have the same number of mapped
profiles p-bit values:
• 8 p-bits = 1024
• 7 p-bits = 1170
• 6 p-bits = 1365
• 5 p-bits = 1638
• 4 p-bits = 2048
• 3 p-bits = 2730
• 2 p-bits = 4096
• 1 p-bit = 8192
Maximum number of MAC 8192 Based on 512 UNIs per PON * 8 PONS per GLT8 * 1 MAC addresses per
addresses that can be learned UNI
(GLT8-A)
Formula to determine MAC Varies (p-bits per service A + p-bits per service x) * (ONTs per PON) * PONs
address allowances on GLT4 if = FIB entries.
only one MAC address is For example if each ONT on the PON was configured with 3 services
learned for each service and the total of all services used 14 p-bits in the PQ profiles, then
(14) * 64 * 4 = 3584 FIB entries per GLT.
MAC address calculation — Each ONT on the LT has 3 services that use a total of 14 p-bits in the
sample 1 PQ profiles. Service 1 uses p-bits 0, 1, 2, 3, 4, and 5, service 2 uses
p-bits 1, 2, 3, 4, 5, and 6, and service 3 uses p-bits 4 and 6. If each
ONT must learn 2 MAC addresses for service 1, and 1 MAC address
for each of services 2 and 3, then the ONT will use 20 FIBs per ONT
(2*6 +1*6 + 1*2).
20 FIBx * 64 ONTs on a PON = 1280 FIBs * 2 PONs on a fully equipped
GLT2=x card = 2560 FIBs and 1280*4 = 5120 FIBs on a fully equipped
GLT4-x card.
This scenario is feasible as the required number of FIBs falls below
the limits for each LT type.
(3 of 7)

MAC address calculation — Per ONT MAC address learning on a GLT4-x system.
sample 2 (assuming fully • 32 MAC addresses if they are learned on services that use a PQ
equipped LT) profile with 1 mapped p-bit value
• 16 MAC addresses if they are learned on services that use a PQ
profile with 2 p-bits mapped to a priority queue
• 10 MAC addresses if they are learned on services that use a PQ
• 8 MAC addresses if they are all learned on services that use a PQ
profile with 7 or 8 p-bits mapped to a priority queue
• 5 MAC addresses learned on services that use a PQ profile with
4 p-bits mapped to a priority queue and 4 MAC addresses on
services that use a PQ profile with 3 p-bit values mapped to a
priority queue.
2MAC addresses on services which use a PQ profile with 7 pbit values

mapped to a priority queue + 2 MACs on services that use a PQ
profile with 6 pbit values mapped to a priority queue + 1 MAC on a
service that uses a PQ profile with 5 pbit values mapped to a priority
queue.
When less than 32 FIBs are used for each ONT, the unused FIBs mean
that some additional MAC addresses can be learned on the LT. For
example, each ONT simultaneously learns 10 MAC addresses, each
learned on services that use a PQ profile with 3 p-bits mapped to a
priority queue.
Each ont only uses 3*10 FIBs or 30 FIBs. This leaves 2 unused FIBs per
ONT. So 2 FIBs*64 PONs * 4 PONs = 512 FIBs still available on the LT.
So an additional 170 MAC addresses can be learned on this LT
(assuming these MACs will also all be learned on services which use
a PQ profile with 3 pbit values mapped to a priority queue).
ARP entries
Address resolution protocol 16 000 16 000 if MAC learning is required on the LANX
(ARP) entries per system 16 5888 16 5888 if no MAC learning on the LANX
Same as maximum MAC address per system
ARP entries per LT card GTL2: 2048 Same as maximum MAC address entries
GLT4: 4096
GLT8: 8192
802.1x sessions
802.1x sessions per LT card GTL2: 576 (EXNT) Need one per UNI
GTL2: 480 (EHNT)
GLT4: 1152 Need one per UNI (288 UNIs × 4 PONs only
(EXNT)
GLT4: 960 (EHNT)
GLT8: 2304 Need one per UNI (288 UNIs × 8 PONs)

(EXNT)
802.1x sessions per system 41 472 (EXNT) 2304 × 18 = 41 472

17 280 (EHNT) 960 × 18 = 17 280
(4 of 7)

802.1x simultaneous setup per 32 —

LT
802.1x simultaneous setup per 100 —

system
T-CONTS and GEM ports

GEM ports per PON 800 or 864 The limit of 800 GEM ports is for Release 04.05.xx and earlier. The
limit of 864 Gemports is for Release 04.06.00 and later.
Each queue in a PQ profile uses a GEM port. For example, when the
limit is 800, if you create PQ profiles that use 8 queues per service,
then only 100 services using those profiles can be created on that
PON.
Further, there is a limit of 22 GEM ports per ONT. Three of those
GEM ports are reserved and cannot be used for priority queues. For
example, if there are 2 HSI services on an ONT UNI with 8 priority
queues defined per service, then those 16 priority queues use 16
GEM ports. Another service using another 8 priority queues cannot
be created, as that would exceed the maximum allowed number of
GEM ports.
T-CONTs per PON 440 440 = 512 total T-CONTs - 64 used for OMCI - 8 reserved.
In configurations using the maximum number of services per PON,
upstream packet loss may occur when DT values less than three are
used for all services.
More than one service per T-CONT is possible in FLEX mode
Bridge ports
Maximum bridge ports per LT GLT2: See Notes For GLT2-x and EXNT-x systems, the limit is 576 bridge ports (288
card UNIs per PON x 2 PONs)
(The maximum number of For GLT2-x and EHNT-x systems, the limit is 480 bridge ports (240
bridge ports is determined by UNIs per PON x 2 PONs)
LT card type, NT card type,
and ONT type.) GLT4: See Notes For GLT4-x and EXNT-x systems, the limit is 2048 bridgeports (512
UNIs per PON x 4 PONs)
For GLT4-x and EHNT-x systems, the limit is 960 bridgeports (240
GLT8: See Notes For GLT8-A and EXNT-x systems, the limit is 4096 bridgeports (512
Maximum bridge ports per 64990 (EXNT) —

residential bridge 17280 (EHNT)
(The maximum number of
bridge ports is determined by
and ONT type.)
Maximum bridge ports per 65534 (EXNT) The total bridge ports per system is the number per residential
system 17312 (EHNT) bridge plus 32 more reserved bridgeports.
bridge ports is determined by
and ONT type.)
C-VLANs
(5 of 7)

Maximum C-VLANs per LT card GLT2: 256 64 ONTs per PON * 2 C-VLANS per PON * 2 PONs
GLT4: 512 64 ONTs per PON * 2 C-VLANs per PON * 4 PONs

Combined limit of 4608 per LT card for learned C-VLANs and MAC
addresses
GLT8:1024 64 ONTs per PON × 2 C-VLANS per PON × 8 PONs
Maximum C-VLANs per system 9216 (EHNT) This is the limit on the number of C-VLANS that can be learned
18 432 (EXNT)
Service flows
Maximum service flows per LT GLT2: See Notes For GLT2-x and EXNT-x systems, the limit is 1728 flows
card For GLT2-x and EHNT-x systems, the limit is 1440 flows
service flows is determined by GLT4: See Notes For GLT4-x and EXNT-x systems, the limit is 3456 flows
LT card type and NT card For GLT4-x and EHNT-x systems, the limit is 2880 flows
type.)
GLT8: See Notes For GLT8-A and EXNT-x systems, the limit is 6912 flows
Maximum service flows per 12 4416 (EXNT) —

system 51 840 (EHNT)
service flows is determined by
LT card, NT card type, and
number of LT slots.)
Service portals
Maximum service portals per GLT2: 880 —
LT card
GLT4: 1760 —
GLT8: 3520 —
Maximum service portals per 63360 (EXNT) —
system 31680 (EHNT)
Services
HSI services per PON 440 Limitation due to number of T-CONTs

GLT8-A supports 1024 but is currently limited by QoS to 440
HSI services per LT card GTL2: 880 440 * 2
GLT4: 1760 440 * 4
GLT8: 3520 440 * 8
HSI Services per system 63 360 480 × 8 × 18 = 63 360
POTS lines per PON 192 —
VoIP clients per PON 64 One VoIP client per ONU = 64 VoIP clients per PON.
VDSL2 subscribers per PON 512 ports x ONTs/MDUs per PON
Depends on the ONT/MDU. For example, O-00240V-A MDU supports
24 ports.VDSL2 subscribers per PON would then be 24 ports x 21
MDUs per PON = 504 VDSL2 ports per PON.
VDSL2 subscribers per PON per 2048 ports x ONTs/MDUs per PON x number of PONs on a GLT4
GLT4 Depends on the ONT/MDU. For example, O-00240V-A MDU supports
24 ports. VDSL2 subscribers per GLT4 would be 24 ports x 21 MDUs
per PON x 4 PONs per GLT4 = 2016 VDSL2 ports per GLT4.
(6 of 7)

IGMP signaling channels per 288 (EXNT) —

PON 240 (EHNT)
IGMP signaling channels per LT GLT2: 576 (EXNT) —

card GLT2: 480 (EHNT)
GLT4: 1152 —
(EXNT)
GLT4: 960 (EHNT)
GLT8: 2304 —
(EXNT)
IPv6
DHCPv6 summary counters GLT2-x: not —

supported
GLT4-x: 2048
GLT8-A: 4096
DHCPv6 detailed counters GLT2-x: not —
supported
GLT4-x: 2048
GLT8-A: 4096
IPv6 user sessions GLT2-x: not —

supported
GLT4-x: 10 240
GLT8-A: 20 480
(7 of 7)
Note 1 — The combined number of UNI ports cannot exceed the

maximum number of UNI ports. Table 8-6 shows the maximum
number of UNI ports per LT card type. Table 8-7 shows the maximum
number of UNI ports by UNI type per LT card type.
Note 2 — Although the 7342 ISAM FTTU supports up to 512 UNIs
per PON on an EXNT-A and GLT4 system, provisioning more than
440 UNIs per PON up to the 512 limit requires the use of FLEX mode,
portals, and flows.
Table 8-6 Maximum number of UNI ports per LT card type
LT card NT card Maximum UNI ports
Per PON Per LT card
GLT2-x EXNT-x 288 576
EHNT-x 240 480
GLT4-x EXNT-x 512 2048
EHNT-x 240 960
GLT8-A EXNT-x 512 4096

Table 8-7 Maximum UNI ports by UNI type per LT card
UNI type GLT2-x GLT4-x GLT8-A
EXNT-x EHNT-x EXNT-x EHNT-x EXNT-x
Ethernet 576 480 2048 960 4096
VDSL 576 480 384 384 768
VDSL2 576 480 2048 960 4096
MoCA 256 256 256 256 512
HPNA 256 256 256 256 512
POTS 768 768 768 768 1536

VIDEO 256 256 256 256 512
CES 256 256 256 256 512
VoIP 256 256 256 256 512
VEIP 2048 960 2048 960 4096
Combined 576 480 2048 960 4096

total
P-OLT performance and distance

The P-OLT provides performance and distance capacity of 2.488 Gb/s downstream
and 1.244 Gb/s upstream, within a 18.6 mile (30 km) span with GLT2-x cards and
within 37.3 miles (60 km) span with GLT4-A and GLT4-D cards. The GLT8-A card
is within a 18.6 mile (30 km) span with Class B+ optics, and within 37.3 miles (60
km) span with Class C+ optics. Extended PON deployment is supported allowing
you to configure each PON with the ability to provide a 20 km, 34 km, and a 40 km
differential window for ranging and ONT operation depending on the optical link
budget supported by the LT card used, the PON reach specified based on network
deployments, and the loss of optical fiber, connectors, and splitters, and so on. See
7342 ISAM FTTU Product Information Manual and 7342 ISAM FTTU Operations
and Maintenance Procedures Guide using TL1 and CLI for more information about
extended PON operation.
The optical link budget is defined by both loss and bandwidth characteristics. The
loss characteristic is determined by the difference between the optical transmitter and
optical receiver for each direction, and is typically 28 dB. The bandwidth
characteristic is determined by the maximum link distance parameter of each OLT
and ONT transmitter specification, and is limited by the smaller of the upstream and
downstream values.
PON bandwidth
The number of optical network terminals (ONTs) on the PON affects the bandwidth
available to each subscriber. See the 7342 ISAM FTTU ONT Product Information
Manual deployment planning chapter for more information.

P-OLT connection capacities

The P-OLT can accommodate a maximum of 16 LT units on the ALTS-N or 14 LT
units on the OLTS-M. Each LT unit provides two, four, or eight ports.Only four port
LT cards are supported on the OLTS-M.
Video coupler connection capacity

The video coupler rack can accommodate a maximum of 15 video coupler shelves,
including a spare video coupler. Each shelf can hold a maximum of three pairs of
video coupler trays. One left and one right tray are connected as a pair. There are two
types of WDM trays. The VCW4 tray contains four WDMs with a total of 12 port
connections. The VCS8 tray contains eight WDMs with a total of 18 port
connections.
8.5 GPON optical and RF line rates
The 7342 ISAM FTTU system supports the GPON line rate of 2.488 Gbp/s
downstream and 1.244 Gbp/s upstream between the P-OLT and the ONTs, based on
the ITU-T G.984 protocol.
Consider the following when planning video deployments:
• ONTs supporting video overlays only support a 1:4 split ratio
• The maximum supported length of RG9 or RG59 coax cable is 100 ft (30.48 m)
See the RF video service DLP in the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI for more information about video deployment
configurations.
Note — Video performance varies according to the unique

characteristics of the customer-specific setup, such as channel
loading, video backbone, and delivery service quality. Due to high
variations in customer requirements, contact your Alcatel-Lucent
sales representative to determine the guaranteed video performance
for your specific network and video application.
The V-OLT supports the full radio frequency (RF) spectrum of 47 MHz to 862 MHz.
8.6 P-OLT optical budgets
The optical budgets for NT and LT cards are described in the unit data sheet (UDS)
of the NT and LT cards. Table 8-8 describes the information provided in the NT and
LT UDSs.
Table 8-8 P-OLT optical budgets
Chapter Title Content
41 EHNT and pluggable optical modules Summary of optical modules and optical
unit data sheet budgets
(1 of 2)

Chapter Title Content
42 EXNT-A and pluggable optical modules Summary of optical modules and optical
unit data sheet budgets
44 GLT2 unit data sheet Optical budgets
45 GLT4 unit data sheet Optical budgets
46 GLT8 and pluggable optical modules Optical budgets

unit data sheet
(2 of 2)
8.7 Video coupler optical budget
See chapter 57 “LGX VCW2 unit data sheet” for information about the optical
budget of the VCW2 connectors and the WDM.
8.8 Environmental requirements
Table 8-9 describes the environmental requirements of the P-OLT.
Table 8-9 P-OLT environmental requirements
Location Temperature Relative

humidity
Minimum Normal Maximum

Central office 23°F (–5°C) 32°F (0°C) to 104°F (40°C) 122°F (50°C) 5 to 95%
Remote (temperature –40°F (–40°C) 23°F (–-5°C) to 122°F (50°C) 149°F (65°C) 5 to 100%
hardened)
Storage –40°F (–40°C) — 158°F (70°C) 5 to 95%
Table 8-10 describes the environmental requirements of the video coupler.
Table 8-10 Video coupler environmental requirements
Mode Temperature Relative humidity

(non-condensing)
Storage or shipping –40°F (–40°C) to 185°F (85°C) 5% to 85%
Operating –40°F (–40°C) to 185°F (85°C) 5% to 85% (1)
Note
(1) Under normal operating and storage conditions, 90% short term.

8.9 Power specifications
This section provides the following information about the 7342 ISAM FTTU:
• input voltage
• power consumption
See the 7342 ISAM FTTU ONT Product Information Manual deployment planning
chapter for ONT power information.
P-OLT input voltage

Table 8-11 describes the input voltage for the P-OLT.
Table 8-11 P-OLT input voltage
Operating condition Power input

Operating range –72 V dc to –40 V dc
Nominal input voltage –48 V dc
No damage to equipment 0 V dc to –72 V dc
P-OLT power consumption

Table 8-12 describes the power consumption for components of the P-OLT shelf.
Table 8-12 P-OLT power consumption
Unit Typical Maximum Quantity range
ACCU-C 5W 7.5 W 1/shelf

AFAN-H 48 W 130 W 1/shelf
AFAN-S 48 W 216 W 1/shelf
EHNT-A or EHNT-B 67 W 81 W 2/shelf
EXNT-A with GLT2-x cards 87 W 90 W at -5/+50 W unit power 2/shelf

draw
113 W at -40/+65 W unit power
draw
EXNT-A with GLT4-x cards 92.2 W at -5/+50 W unit power 92.7 W at -5/+50 W unit power 2/shelf
draw draw
96.8 W at -40/+65 W unit 97.3 W at -40/+65 W unit
power draw power draw
GLT2-A 35 W 40 W 16/shelf
GLT2-B 39 W 45 W 16/shelf
(1 of 2)

Unit Typical Maximum Quantity range
GLT4-x with EHNT-B 62 W 70 W at -5/+50 W unit power 14/shelf

draw
80 W at -40/+65 W unit power
draw
GLT4-x with EXNT-A 67.2 W at -5/+50 W unit power 74.3 W at -5/+50 W unit power 14/shelf
draw draw
70.6 W at -40/+65 W unit 78 W at -40/+65 W unit power
power draw draw
GLT8-A 55 W 60 W 14/shelf
1-GE SFP 1W 1W 4 to 8
10-GE XFP 2.5 W 2.5 W 1 to 2
ATRU-M , 5W 10 W 1/rack
ATRU-N
ATRU-U
GTRU-B
(2 of 2)
To calculate the total typical power consumption of a component per shelf, multiply
the typical consumption of the component times the quantity per shelf. To calculate
the total maximum power consumption of a component per shelf, multiply the
maximum consumption of the component times the quantity per shelf.

Detailed system description
9 — Alarms and troubleshooting
10 — DHCP
11 — PPPoE
12 — ICMPv6
13 — Fault isolation
14 — IP multicast and IGMP
15 — Layer 2 forwarding
16 — NT redundancy
17 — Proxy ARP
18 — QoS
19 — Statistics and performance monitoring
20 — Security
21 — VLANs and VPNs

9— Alarms and troubleshooting
9.1 Overview 9-2
9.2 Isolating faults indicated by alarms 9-3

9.1 Overview
This chapter provides information on how to:

• view the P-OLT alarms that can be raised
• determine the problem indicated by a P-OLT alarm
See the alarms chapter in the 7342 ISAM FTTU P-OLT and ONT Fault Isolation and
Troubleshooting for more information about ONT alarms.
General
Resolve P-OLT alarms that affect service before the alarms that do not affect service.
Use local procedures to correct problems associated with customized alarms.
Contact Alcatel-Lucent customer technical assistance at 1-888-252-2832
(1-888-ALCATEC) when a problem cannot be corrected. Many of the UNIX
troubleshooting protocols and most of the UNIX commands require root access. If
this is the case, Alcatel-Lucent recommends that a UNIX system administrator
perform the troubleshooting.
P-OLT alarms are grouped by alarm type, as shown in the 7342 ISAM FTTU P-OLT
and ONT Fault Isolation and Troubleshooting.
Except where otherwise specified, the report and logging modes for each alarm are
enabled.
Note 1 — See the alarms chapter in the 7342 ISAM FTTU P-OLT and
ONT Fault Isolation and Troubleshooting for more information about
ONT alarms.
Note 2 — To avoid excessing loading on the P-OLT, clear all
extraneous ONT alarms by making inactive ONTs out-of-service.
Alarm storm prevention

The following conditions may generate alarm storms.
1 Weather or other natural phenomenon in a given geographic area.
2 During software migration.
3 When a PONLOS alarm is declared due to multiple INACT alarms issued from
connected ONTs
You can suppress alarms due to weather or INACT alarms, as shown in Figure 9-1.

Figure 9-1 Alarm storm prevention
INACT
alarms
suppressed
ONT
X
PONLOS alarm triggered
X
LT PON ONT
X X
Fiber cut or
7342 other outage
ONT
Configure suppression
of alarm storms
18998
When weather causes geographically concentrated alarm storms, you can lower
alarm reporting thresholds from NEs in that area.
When a fiber cut generates multiple INACT alarms on all affected ONTs connected
to the PON, the alarm storm prevention function uses a timing mechanism to buffer
all the INACT alarms. When the higher level PONLOS alarm is raised, all the
INACT alarms are discarded.
You can use the alarm filtering feature to remove reporting of the base alarms and
show the derived alarms. See the 7342 ISAM FTTU P-OLT and ONT Fault Isolation
and Troubleshooting for more information.
9.2 Isolating faults indicated by alarms
See the 7342 ISAM FTTU P-OLT and ONT Fault Isolation and Troubleshooting for
more information about listing, isolating, and fixing alarm issues.


10 — DHCP
10.1 Overview 10-2
10.2 DHCPv4 10-2
10.3 DHCPv6 10-6

10 — DHCP
10.1 Overview
This chapter provides a detailed description of the Dynamic Host Configuration

Protocol (DHCP). The 7342 ISAM FTTU supports two versions of DHCP:
• DHCPv4 is the DHCP version used for IPv4, as defined in IETF RFC 2131
• DHCPv6 is the DHCP version used for IPv6
Although both versions bear the same name and perform the same purpose, the
details of the protocol for IPv4 and IPv6 are sufficiently different that they can be
considered separate protocols.
Note 1 — The 7342 ISAM FTTU supports both DHCP and PPPoE
relay agents on the same ONT user-to-network interface (UNI).
Note 2 — With 7342 ISAM FTTU, FGU4.8.04 and later, both DHCP
and PPPoE relay can be supported on the same VLAN. Earlier
software releases required these two services be on different
S-VLANs.
Note 3 — For instruction on how to configure DHCPv4 or DHCPv6,
see the 7342 ISAM FTTU Operations and Maintenance Procedures
10.2 DHCPv4
DHCP, an enhanced version of BOOTP, is a client-server protocol that enables a host

at the subscriber residence to obtain configuration information from a DHCP server
over a specified period of lease time after the host starts up. The configuration
information includes the IP address, subnet mask, DNS server address, and default
router address. Because the configuration information is stored on a server, it
centralizes IP address management, reduces the number of IP addresses to be used,
and simplifies maintenance.
The DHCP client must communicate with the DHCP server. This is achieved by the
DHCP client starting the communication with a broadcast message. The DHCP
server receives the message if the server is connected to the same layer 2 network as
the client. IETF RFC 2131 and RFC 3046 define a DHCP relay agent for DHCPv4
when this is not the case.
Layer 2 DHCP relay agent used by DHCPv4

In a general networking application, the DHCP relay agent function is required when
a LAN does not have BOOTP or a DHCP server directly attached. In a LAN, a host
on the LAN broadcasts a DHCP request message on the network. Every DHCP
server that receives the message replies with a DHCPv4 offer message, which allows
the client to choose a server based on the host client configuration. A server on the
LAN can be configured to relay the requests to the DHCP server that may be located
elsewhere on the network. The DHCP relay agent function also passes the responses
from the server to the client that initiated the request.
The 7342 ISAM FTTU uses the LT card to provide the DHCP relay agent function.
The LT card supports only the Layer 2 relay agent function.

10 — DHCP
The 7342 ISAM FTTU supports multiple instances of the DHCP relay agent
function. Generally, one DHCP relay agent is configured for each VLAN. Each
VLAN can be connected to its own edge routers and DHCP servers. The service
providers can allocate private addresses to the CPE.
Note 1 — If private IP addresses are used, the service provider must
provide the NAT function in the edge router.
Note 2 — The proxy ARP function is activated on an residential
bridge VLAN when the DHCP relay is enabled on the residential
bridge VLAN. For information about proxy ARP, see Chapter 17.
DHCPv4 Option 82
Option 82 allows a managed device, such as the OLT, to append circuit-specific
information to a DHCPv4 request message that is being forwarded to a DHCP server
to identify where the DHCPv4 request originated.
Option 82 is enabled on a per-VLAN basis. If enabled, the DHCP server returns the
Option 82 parameter in the DHCPv4 response, so that the DHCP relay agent relays
the response only on the originating circuit.
Option 82 works by setting two parameters:
• circuit ID—can be the physical address of the circuit on which the DHCPv4
request originated, or the service specific customer ID. The operator can specify
the format of the physical address at the system level; the same format is applied
to all physical addresses.
• remote ID—designed to carry information relating to the remote host end of the
circuit. The operator can set this parameter to use the service specific customer
ID, or disable it.
When another device is configured as the DHCP server, and the 7342 ISAM FTTU
is configured as a DHCP relay agent, the Option 82 parameter should be enabled on
both devices, to ensure traffic passes correctly between the devices.
Operation of DHCPv4
The operation of DHCPv4 is shown in Figure 10-1.

10 — DHCP
Figure 10-1 IP address assignment with DHCPv4
VPLS
BSR BSA 7342 ISAM Residential Client

FTTU gateway device
DHCP
server Access node
inserts Option 82
DHCP DHCP discover DHCP discover

relay Option 82 = Subscriber port
Initial lease
request:
DHCP DHCP offer
relay
DHCP DHCP request

relay Option 82 = Subscriber port
Confirm offer
or renew lease
DHCP DHCP ack DHCP
relay snoop
DHCP lease table populated

from snooped DHCP Ack
19431
The sequence of events for DHCPv4 is as follows.

1 During startup, the host sends a DHCPv4 discover message to get an IP address
from the DHCP server. The discover message contains the destination MAC
address, the source MAC address, and the MAC address of the host device.
If Option 82 is configured, the layer 2 DHCP snooping function on the LT card
adds the relay option field that indicates the physical location, such as shelf, slot,
and port, of the host.
2 The DHCP server looks up the host MAC address and optionally Option 82
information in the database. If the host is recognized and authorized to access the
network, an IP address is assigned and a DHCP offer message is returned. The
BSR and the BSA relay the offer message to the host.
3 The discover message may reach more than one DCHP server, and therefore
more than one offer may be returned. The host chooses one of the offered IP
addresses and confirms the choice in a DHCPv4 request message to the
originating DHCP server.
4 The DHCP server confirms that the IP address is available, updates the database
to indicate that the server is now in use, and replies with a DHCPv4 ack message
to the host.
DHCP relay configuration parameters

The DHCP relay agent function requires the configuration of the DHCP relay agent
and virtual router DCHP parameters.

10 — DHCP
DHCP relay agent configuration parameters
Table 10-1 describes the parameters used to configure the DHCP relay agent
function. To view the current DHCP relay parameter settings, see the
7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1 and
CLI.
Table 10-1 DHCP relay agent parameters
Parameter Description
Relaying When enabled, the relay agent is active.
Server When enabled, the relay agent forwards the packets to a

specific DHCP server.
Server IP IP address of the DHCP server to which the packets are to

be forwarded
secs-threshold/hops-threshold Thresholds for Option 82
Option 82 Agent circuit ID (CID) For each VLAN, use one of the following formats:
• do not add
• physical line ID (1)
• customer ID (2)
Option 82 Remote node ID (RID) For each VLAN, use one of the following formats:
• do not add
• customer ID (2)
Notes
(1) The physical line ID must use the same access node identifier as the Option 82 value. The format
of the physical line ID is:
<access-node-identifier>PON<rack>/<shelf>/<slot>/<PON>:<ONT>.<ONT-slot>.<UNI>. Slot
numbering for Option 82 begins at 1. The physical line ID can be toggled to start with 01 or 03
depending whether the PONIDSYNTAX parameter is set to Legacy or Logical.
(2) The format of the customer ID is an ASCII string that is configurable for each UNI and for each
service.
The following restrictions apply when configuring DHCP relay:

• Before you enable the DHCP relay agent, you must configure the static routes to
the DHCP servers on a virtual routing and forwarding (VRF) IP interface.
• Up to four DHCP servers can be configured on a VRF.
• The S-VLAN ID of the HSI service that is configured for DHCP relay at the LT
card (layer 2) must match the VLAN ID that is entered in the VRF routing table
for layer 3.
Virtual router DHCP relay configuration parameters
The 7342 ISAM FTTU supports up to 128 virtual routers. Each virtual router
represents a dedicated IP routing space. Individual virtual routers cannot exchange
traffic between them. Each virtual router has a DHCP agent that is used exclusively
within its dedicated IP routing space.

10 — DHCP
You can configure the following DHCP relay parameters for each virtual router:
• DHCP relay agent: The agent can be enabled or disabled.
• Option 82 insertion: The option can be enabled or disabled. This is configured
independent of the DHCP relay agent status. When another device is configured
as the DHCP server, and the 7342 ISAM FTTU is configured as a DHCP relay
agent, the Option 82 parameter should be enabled on both devices, to ensure
traffic passes correctly between the devices.
• Relay agent IP address: This parameter is the IP address of one of the VRF IP
interfaces.
10.3 DHCPv6
Like DHCPv4, DHCPv6 is a client-server protocol that enables DHCP servers to

configure Internet hosts. DHCP is defined on top of UDP/IP.
The OLT identifies DHCPv6 messages, tracks IPv6 addresses that are assigned to
subscribers, acts as a DHCPv6 relay agent, and optionally inserts DHCPv6 Options
18 and 37 in relayed messages based on how the VLAN is configured.
By default, the OLT snoops all DHPCv6 messages to identify any changes to the
IPv6 addresses that are assigned to subscribers. However, the OLT will not act as a
DHCPv6 relay agent nor drop any messages received without further VLAN
configuration. After an operator configures a VLAN to have either
DHCPv6 Option 18 or DHCPv6 Option 37 enabled, the lightweight DHCPv6 relay
agent (LDRA) is enabled for the VLAN.
Lightweight DHCP relay agent

When a VLAN is configured for Option 18 or Option 37, the OLT acts as a LDRA
as described in Internet-Draft of Lightweight DHCPv6 Relay Agent, and the DHCP
server (or edge router) acts as a DHCPv6 relay agent. The OLT encapsulates any
valid message from the client in a relay-forward towards the DHCP server, and
expects relay-reply messages from the DHCP server, The LDRA strips out the
relay-reply part of the message before sending the message to the client, so that the
client does not know that it is talking to an agent instead of a server.
Table 10-2 specifies how LDRA drops and validates messages given to it.
Note — The LDRA is enabled when either Option 18 or Option 37 is
enabled, and the LDRA is disabled when both Option 18 and Option
37 are disabled. The operator can enable or disable the insertion of
option 18 or option 37 into upstream DHCPv6 messages on a
per-VLAN basis.

10 — DHCP
Table 10-2 DHCP LDRA filtering rules
DHCP message type LDRA disabled LDRA enabled
Upstream Downstream Upstream Downstream
Solicit Forward Forward Relay-forward Forward
Advertise Forward Forward Drop Forward
Request Forward Forward Relay-forward Forward

Confirm Forward Forward Relay-forward Forward
Renew Forward Forward Relay-forward Forward
Rebind Forward Forward Relay-forward Forward
Release Forward Forward Relay-forward Forward
Decline Forward Forward Relay-forward Forward
Reply Forward Forward Drop Forward
Reconfigure Forward Forward Drop Forward
Information request Forward Forward Relay-forward Forward
Relay-forward Forward Forward Forward Forward
Relay-reply Forward Forward Drop Reply
Note — All received DHCPv6 packets are sent to the DHCPv6

application to populate the anti-spoofing table. The DHCPv6
application will reinsert forwarded packets, and drop dropped
DHCPv6 packets.
The DHCPv6 application encapsulates relay-forward packets in a
relay-forward message before reinserting forwarded packets, The
DHCPv6 application deconstructs a downstream relay-reply into a
reply message if the LDRA was the trigger for the message;
otherwise, the DHCPv6 forwards the relay-reply to the next relay,
Option 18 (interface ID)
Relay agents add the interface ID option 18 to identify the physical port on which the
client message was received. This information is used by the server to determine the
IP addresses to assign, and by the relay agent to know where to the send the server’s
response.
The following interface ID Option 18 configurations apply:
• do not add the interface ID
• set the interface ID to customer ID
• set the interface ID to an auto-generated physical line ID

10 — DHCP
Option 37 (relay agent remote ID)

The relay agent adds Option 37 to identify any circuit or remote ID that further
identifies the client to the DHCP server. However, the relay agent does not require
the remote ID to forward the response from the DHCP server to the client.
The following relay agent remote ID Option 37 configurations apply:
• do not add the relay agent remote ID
• set the remote ID to customer ID
• set the remote ID to an auto-generated physical line ID
The remote ID also contains a configurable or default enterprise number.
DHCPv6 trusted/untrusted port configuration

The interface (VLAN) where the LDRA is enabled, can be configured as a trusted or
untrusted interface.
• When the interface is configured as trusted, then the LDRA accepts DHCPv6
relay-forward messages from the subscriber side with options 18 and/or 37
already inserted. The 7342 ISAM FTTU will relay these relay-forward messages
in accordance with the Internet-Draft of LDRA. In that case, hop count is
incremented in the upstream and is decremented in the downstream.
• When the interface is configured as untrusted, then LDRA will discard and not
relay these relay-forward messages from the subscriber side with option 18 or
option 37 already inserted.
DHCPv6 specifications
DHCPv6 packets are IPv6 packets that have a UDP header with a UDP source and
destination port of 546 or 547, as shown in Table 10-3. The UDP source and
destination port vary between 546 and 547 depending on whether the client is
sending to or receiving from the server.
Table 10-3 DHCPv6 packets
Version = 0X6 | Traffic class (8 bits) | Flow label (20 bits)
Payload bits (16 bits) | Next header = 0x11 | Hop limit (8 bits)
IPv6 source address (128 bits)
IPv6 destination address (128 bits)
UDP source port (16 bits) UDP destination port (16 bits)
Payload length (16 bits) Payload length (16 bits)
DHCPv6 messages also contain a fixed length DHCP header followed with variable
length options, as shown in Table 10-4.

10 — DHCP
Table 10-4 DHCPv6 header
Message type Transaction ID (24 bits)
Options (variable; see DHCPv6 options)
DHCPv6 messages
Table 10-5 describes the DHCPv6 messages, their type, and requirements.
Table 10-5 DHCPv6 messages
Message Message type Description and requirements
Solicit message 0x01 A solicit message is sent by a DHCP client to find a

DHCP server.
A solicit message must have a client ID option, and be
sent to a multicast address.
Advertise message 0x02 An advertise message IS sent by a DHCP server to a

DHCP client in response to a solicit message.
An advertise message must have a client ID and server
ID option.
Request message 0x03 A request message is sent by a DHCP client to obtain

configuration information.
A request message must have a client ID and a server
ID option.
Confirm message 0x04 A confirm message is sent by a DHCP client to verify its
configuration information.
A confirm message must have a client ID option, and be
Renew message 0x05 A renew message is sent by a DHCP client to the DHCP
server that granted its configuration to extend the
duration of its configuration information.
A renew message must have a client ID and a server ID
option.
Rebind message 0x06 A rebind message is sent by a DHCP client to a different

DHCP server from the one that originally granted its
configuration to renew the duration of its
configuration.
A rebind message must have a client ID option, and be
Reply message 0x07 A reply message is sent by a DHCP server to a DHCP

client in response to a request, renew, rebind,
confirm, decline, release, or information request
message.
A reply message must have a server ID option, and a
client ID option if a client ID option was provided in the
message initiating the reply.
Release message 0x08 A release message is sent by a DHCP client to a DHCP

server to indicate that it is no longer using its
configuration.
A release message must have a client ID and a server ID
option.
(1 of 2)

10 — DHCP
Message Message type Description and requirements
Decline message 0x09 A decline message is sent by a DHCP client to a DHCP

server to reject the configuration granted to it because
the address is already in use.
A decline message must have a client ID and a server ID
option.
Reconfigure message 0x0A A reconfigure message is sent by a DHCP server to a

managed client to inform the client to re-request
configuration to obtain updated configuration
information.
A reconfigure message must have a server ID, Client ID,
reconfigure, and authentication option, and be sent to
a multicast address.
Information request 0x0B An information request message is sent by a DHCP

message client to request configuration information with no
assigned address.
Relay-forward message 0x0C A relay-forward message is used when clients
communicate through relays to the DHCP server. A
relay-forward message is added between the relay
agent and the server.
A relay-forward message must have the relayed
message option.
Relay-reply message 0x0D A relay-reply message is used when a server responds

to messages sent through a relay agent.
A relay-reply message must have the relayed message
option.
(2 of 2)
DHCPv6 options
DHCP options have the following format:
• 16-bit option identifier (or type)
• 16 bits of the option length (in bytes, not including the header)
• option
A message can have multiple options strung together; however, a message is usually
allowed to have only one option of each option type.
Table 10-6 describes the DHCPv6 options.
Table 10-6 DHCpv6 options
DHCPv6 option Description
Client ID option The client ID option uniquely identifies a client so that servers can
differentiate clients.
Server ID option The server ID option also uses the DUID to provide clients a unique ID to
distinguish one DHCP server from another. As with the client ID DUID,
the DUID is not just an imbedded link-layer address.
Identity association for The identity association for non-temporary addresses is used for the
non-temporary assignment of addresses to clients.
addresses option
(1 of 2)

10 — DHCP
DHCPv6 option Description
Identity association for The identity association for temporary addresses is used for the
temporary addresses assignment of temporary addresses to clients, as defined in RFC 3041.
option
IA address option The IA address option is used only as part of an identity association for
either non-temporary or temporary addresses
Option request option The option request option is used by clients to inquire about information
shared through options, or by a server during a reconfigure message to
tell the client what to inquire about.
Preference option Servers use the preference option to influence clients to choose or not
choose certain DHCP servers if advertisements from multiple servers are
received.
Elapsed time option The elapsed time option is used to determine how long a client has been
attempting a DHCP message exchange.
Relay message option The relay message option is used during relay-forward or relay-reply
messages.
Authentication option The authentication option is used when network administrators want
additional security during DHCP exchanges.
Server unicast option The server unicast option is used to allow clients to send messages
directly to the DHCP server. This option should only be used if the server
knows that there are no DHCP relay agents between the server and the
client.
Status code option The status code option is used to provide feedback on the success or
failure of an operation.
Rapid commit Option Clients use the rapid commit option to perform rapid commit address
assignment.
User class option Clients and servers use the user class option to distinguish between
different types of users. Servers may choose to treat classes differently,
such as placing everyone of class A into the same subnet.
Vendor class option The vendor class option is used to identify the vendor of the hardware
on which the DHCP client is running.
Vendor-specific Clients and servers use the vendor-specific Information option to

information option exchange vendor-specific information
Interface-ID option Relay agents use the interface ID option to identify the interface from
which a client request came.
Reconfigure message The server uses the reconfigure message option during a reconfigure
option message exchange to inform the client how they should obtain the new
information.
Reconfigure accept The reconfigure accept option is used to identify if the client is willing
option to accept reconfigure messages. By default, clients do not accept
reconfigure messages, and servers should not be expected to send these
messages.
Relay agent remote ID DHCP relay agents add the relay agent remote ID option to give servers
option (Option-37) more information about the interfaces to which these servers are
assigning addresses.
(2 of 2)

10 — DHCP
DHCPv6 message sequencing

The following subsections describe how the messages and options are used to
perform DHCP services.
Note — In the examples that follow, if the router is a DHCP

relay-agent, any message from the client will be forwarded to the
server with a relay-forward message, and any message from the server
will be sent to the agent by a relay-reply message.
Server solicitation
Server solicitation occurs when a client connects to a network, and needs to know
what servers are offering DHCP services.
After connecting to a new network, the client creates a solicitation message, and
sends the message upstream using the All DHCP servers and relay-agents multicast
address, FF02::1:2. Any DHCP server (or relay agent) replies with an advertise
message to the DHCP client that initiated the message. The client can then process
other DHCP tasks, such as obtaining configuration for its interfaces.
Rapid commit
Rapid commit is a special case of server solicitation, when a client discovers the
available DHCP servers, and also obtains an address in a single transmit-receive
message pair.
A rapid commit occurs similarly to a server solicitation. The client sends a
solicitation message to the All DHCP servers and relay-agents multicast address, and
also includes the rapid commit option in the message. DHCP servers that choose to
support rapid commit respond with a reply message with the client’s configuration
and address. A server that chooses not to support rapid commit sends an advertise
message, and the client would then need to proceed with address assignment.
Note — Multiple servers may respond to the same client request for
rapid commit with no feedback to let the servers know what address
the client selected.
Address assignment
Address assignment is how most clients obtain their IP address from the DHCP
server.
After a client has obtained a list of valid DHCP servers through server solicitation, a
client may then attempt to reserve an address by sending out a request message to
one of the DHCP servers. The DHCP server responds with a reply message with the
requested configuration if request is successful, or the error that occurred if the
request fails.
Address confirmation
If a client goes offline for any reason, a client can use an address confirmation to ask
the DHCP server if its address is still assigned.

10 — DHCP
After going back online, the client composes and sends a confirm message to the
DHPC server if the client thinks that its lease is still valid. The DHCP server
responds with a reply confirming or denying the previous leases. If the leases are
denied or there is no response from the DHCP server, the client must perform an
address assignment.
Address renewal
The client uses the address renewal to renew a lease that is expiring.
When T1 from the identity association expires, the client is expected to attempt to
renew the lease from the original DHCP server. The client composes a renew
message and sends it to the DHCP server. The DHCP server then composes and
sends a reply message to confirm the renewal. If the DHCP server does not reply in
a timely manner, the client must rebind its address with a different DHCP server.
Address rebinding
If a client attempts to renew an address and the DHCP server is not responding, the
client must rebind its address with a different DHCP server through address
rebinding.
If a client has failed to obtain a renewal from the original DHCP server and T2 of the
identity association has expired, the client must then attempt address rebinding by
sending a rebind message to the All DHCP servers and relay-agents multicast
address, FF02:1:2. A DHCP server responds with a reply message to confirm that the
address is bound to it. The client must then treat the new DHCP server as the
originator of the address, and continue as normal.
Declining an address
If a client questions the validity of an address given to it by a server (for example, the
client thinks that some other client is using the address), the client may decline the
address, and then attempt to obtain a new address through address assignment
When the client wants to decline an address, the client sends a decline message to the
DHCP server using the All DHCP servers and relay-agents multicast address,
FF02::1:2. The DHCP server responds with a reply message to confirm the decline,
and the client is then expected to obtain a new address
Address freeing
When a client is finished with its address, the client may free the address for other
clients to use it through address freeing.
To free an address, a client sends a release message to the DHCP server that assigned
the address. The DHCP server then responds with a reply, and is free to assign the
address to a different client. The original client is expected not to use this address,
unless the client obtains the same address through a new address assignment.
Reconfiguration
In certain cases, the DHCP server may need to update the configuration on the client,
without the client having communicated with the server. In these cases,
reconfiguration is used.

10 — DHCP
Be default, clients do not support reconfiguration. Reconfiguration is supported only

if a client sends a message containing the reconfigure accept option indicating that
the client is willing to accept reconfigurations. A server can then, when necessary,
send down a reconfigure message to the client, asking the client to send up a renew
message to obtain updated information. After the client receives the reconfigure
message, the flow continues as a standard renewal.

11 — PPPoE
11.1 Overview 11-2
11.2 PPPoE relay agent 11-2
11.3 PPPoE relay agent configuration parameters 11-2

11 — PPPoE
11.1 Overview
This chapter describes the Point-to-Point Protocol over Ethernet (PPPoE).

Note 1 — The 7342 ISAM FTTU supports both DHCP and PPPoE
relay agents on the same ONT user-to-network interface (UNI).
Note 2 — With 7342 ISAM FTTU, FGU4.8.04 and later, both DHCP
and PPPoE relay can be supported on the same VLAN. Earlier
software releases required these two services be on different
S-VLANs.
Note 3 — For instruction on how to configure PPPoE, see the
using TL1 and CLI.
11.2 PPPoE relay agent
Service providers can use PPPoE to provide high-speed Internet (HSI) services.
When a service provider chooses to use PPPoE, the PPPoE relay agent provides
information to the broadband remote access server (BRAS) about which subscriber
is setting up a PPPoE session. The PPPoE relay agent is used to provide the
information to BRAS. The BRAS returns the parameter so that the relay agent can
relay it only to the circuit from which the PPPoE request originates.
If enabled, the PPPoE relay agent can insert circuit ID and remote ID information.
value is inserted in the PPPoE session establishment messages to identify the circuit
that the requesting client is connected to.
The P-OLT can be configured to enable or disable the PPPoE relay agent for each
S-VLAN as part of the layer 2 forwarding and bridging function. The P-OLT
supports PPPoE relay agents for stacked and unstacked residential bridge mode.
The P-OLT supports both PPPoE and DHCP relay on the same UNI. For example,
one service may use PPPoE and another service may use DHCP. With FGU4.8.04
and later software, PPPoE service and DHCP service can be enabled on the same
S-VLANs. Prior P-OLT software releases did not support both PPPoE and DHCP
relay agent functions on the same VLAN.
11.3 PPPoE relay agent configuration parameters
When a PPPoE relay agent is enabled on a VLAN, the P-OLT must be configured
with a vendor-specific tag that can be added to the PPPoE discovery protocol
messages (PADI, PADR, PADT) in the upstream direction.
Note — The packet is dropped if the packet exceeds the maximum

Ethernet frame size of 2008 bytes after the vendor-specific tag is
added. (The GLT2-A does not support 2008 byte frames and will drop
packets larger than 1800 bytes.)
Table 11-1 lists the format and specifications of the vendor-specific tag.

11 — PPPoE
Table 11-1 Vendor-specific tag format for PPPoE discover protocol messages
Format Specifications
Tag type 0 x 0105
Tag value Enterprise code
Suboption 1 Circuit ID — configurable for each VLAN in one of the following

formats:
• physical line ID (1)
• customer ID (2)
Suboption 2 Remote ID — configurable for each VLAN in one of the following

formats:
• not add
• customer ID (2)
Notes
(1) The physical line ID must use the same access node identifier as the Option 82 value. The format
of the physical line ID is:
<access-node-identifier>PON<rack>/<shelf>/<slot>/<PON>:<ONT>.<ONT-slot>.<UNI>. Slot
numbering for Option 82 begins at 1. The physical line ID can be toggled to start with 01 or 03
depending whether the PONIDSYNTAX parameter is set to Legacy or Logical.
(2) The format of the customer ID is an ASCII string that is configurable for each UNI and for each
service.

11 — PPPoE

12 — ICMPv6
12.1 Overview 12-2
12.2 ICMPv6 neighbor discovery (ND) 12-2
12.3 ICMPv6 ND specifications 12-3

12 — ICMPv6
12.1 Overview
This chapter describes the protocol ICMPv6 as implemented on the

7342 ISAM FTTU
12.2 ICMPv6 neighbor discovery (ND)
The 7342 OLT validates ICMPv6 ND messages, and forwards any valid and
applicable message through the OLT. For example, the following messages would
be considered invalid or non-applicable, and would be discarded:
• ND message with an option length of 0 is an invalid message and is therefore
discarded.
• An upstream redirect message is not applicable because the hosts on the ONU
side should not be acting as routers, and is therefore discarded.
This behavior is enabled through provisioning.

With the implementation of the DHCPv6 application, the 7342 ISAM FTTU may
also use information from the DHCPv6 application to further validate ND messages,
to ensure that a host does not advertise an IP-link layer address combination that was
not assigned through DHCPv6. However, this validation could break stateless
address auto configuration (RFC 4862) because ICMPv6 secure filtering may drop
packets used by hosts to reserve their address. Therefore, stateless address
autoconfiguration may not function properly if ICMPv6 secure filtering is enabled.
ICMPv6 secure filtering

ICMPv6 secure filtering is configured on a per-VLAN basis and ensures that
ICMPv6 messages passing through the VLAN contain data that is consistent with
DHCPv6 and architectural assumptions, such as no user-side node should be acting
as a router. By default, ICMPv6 secure filtering is disabled.
Table 12-1 identifies the forwarding behavior of ICMPv6 messages by message type
in the upstream and downstream, when ICMPv6 secure filtering is enabled and
disabled.
• When ICMPv6 secure filtering is disabled, all ICMPv6 messages are forwarded
through the 7342 ISAM FTTU untouched by the ND application.
• When ICMPv6 secure filtering is enabled, ICMPv6 ND messages are either
forwarded or discarded.
Table 12-1 ICMPv6 secure filtering forwarding behaviors
ICMP message type ICMPv6 secure filtering disabled ICMPv6 secure filtering enabled
Router solicitation Forward Forward Validate Drop
Router advertisement Forward Forward Drop Validate
(1 of 2)

12 — ICMPv6
ICMP message type ICMPv6 secure filtering disabled ICMPv6 secure filtering enabled
Neighbor solicitation Forward Forward Validate Validate
Neighbor advertisement Forward Forward Validate Validate
Redirect Forward Forward Drop Validate

MLD Forward Forward Forward Forward
Other/unknown ICMP Forward Forward Forward Forward
(2 of 2)
12.3 ICMPv6 ND specifications
ICMPv6 packets are IPv6 (EtherType 0x86DD) as shown in Table 12-2 with an
additional ICMPv6 header specific to the type of ICMP message.
Table 12-2 ICMPv6 packets
Version = 0X6 | Traffic class (8 bits) | Flow label (20 bits)

Payload bits (16 bits) | Next header = 0x3A | Hop limit (8 bits)
IPv6 source address (128 bits)
IPv6 destination address (128 bits)

Additional headers and payloads...
ICMPv6 messages
ND support five ICMPv6 messages:
• router solicitation
• router advertisement
• neighbor solicitation
• neighbor advertisement
• redirect
Table 12-3 describes the IMCPv6 messages.
Table 12-3 IMCPv6 messages
ICMP message type Description
Router solicitation Router solicitation messages are sent from hosts when hosts
want routers to send out router advertisement messages.
Options valid for a router solicitation would be the link-layer
address (MAC) of the sender, if the source address in the IPv6
header was specified (non-zero).
(1 of 2)

12 — ICMPv6
ICMP message type Description
Router advertisement Router advertisement messages are sent periodically to all

nodes, or as a response to a router solicitation message.
Options available for the router advertisement messages are the
source link layer (MAC) address, MTU, and prefix information
Neighbor solicitation Nodes send neighbor solicitation messages to resolve unknown

addresses while providing information about their own
addresses.
An option for a neighbor solicitation is the source link-layer
address (MAC) that should be included if the source IP is known.
Neighbor advertisement Nodes send neighbor advertisements in response to neighbor

solicitation messages, or unsolicited messages to propagate new
information quickly.
An option for a neighbor advertisement is the target link-layer
(MAC) address.
Redirect Routers can use the redirect message to inform hosts of better
first-hop routes.
Possible options are the target link-layer (MAC) address and the
redirected header.
(2 of 2)
ICMPv6 options
ND packets have five possible option types:
• source link-layer address
• target link-layer address
• prefix information
• redirected header
• MTU (maximum transmission unit)
All options are variable length in units of 64 bits, and all option headers include the
size of the option (including the header) in these units. Any option with a length of
zero is discarded.
Table 12-4 describes the IMCPv6 options.
Table 12-4 IMCPv6 options
ICMPv6 option Description
Source link-layer address option The link-layer address options include the link-layer
address, which is either the source IP in the IPv6 header of
Target link-layer address option the packet, or the target IP in the ICMPv6 ND header of the
packet. In the 7342 ISAM FTTU, all link-layer addresses
will be MAC addresses (length = 1).
Prefix information The prefix information option is used to provide hosts

information about on-link prefixes and address
autoconfiguration.
Redirected header The redirected header option is used to provide the packet
that triggered the redirection back to the sender.
(1 of 2)

12 — ICMPv6
ICMPv6 option Description
MTU (maximum transmission unit The MTU option is used for MTU discovery on variable links.
Because the 7342 ISAM FTTU uses Ethernet for external
links, the MTU will likely be the same as Ethernet’s, 1500.
(2 of 2)
ND message sequencing
Several message sequences and flows can be identified for ND, which can be
grouped by the function that they provide as follows:
• router/prefix discovery
• address resolution
• neighbor unreachability detection
• redirection
Router/prefix discovery
Router/prefix discovery is used by hosts to find which routers are currently available
for forwarding traffic, and to provide prefix (subnet) information to the hosts.
Router/prefix discovery is done through solicited and unsolicited router
advertisements.
• Solicited router advertisement
During a solicited router advertisement, a host sends a router solicitation message
(usually after being initialized) addressed to the all-routers multicast channel.
Any active first-hop routers should receive this message and reply with a router
advertisement message directed to the host who sent the solicitation.
• Unsolicited router advertisement
Routers periodically send out router advertisement messages without external
stimuli. These messages are sent out on the all-nodes multicast channel and are
used to keep cache entries refreshed. When hosts receive these messages, the
hosts only need to update or refresh their cache data. When other routers receive
these messages, other routers only act if a data-consistency issue is found in the
received advertisement. If a data-consistency issue is found, the router informs
the system operator about a possible router misconfiguration. No other action is
required.
Address resolution
Address resolution is used by hosts to determine which link-address to use given
only an IP address, which is done through solicited and unsolicited neighbor
advertisements.
• Solicited neighbor advertisements
If a host has a destination IP address but does not know the corresponding
destination link-layer address, the host will send a neighbor solicitation to the
all-nodes multicast channel. The neighbor solicitation states the IP address for
which the host wants link-layer information, and the host’s IP and link layer

12 — ICMPv6
address. The target node (or a node who knows the target information will
respond with a neighbor advertisement directly to the host with the requested
link-layer information.
• Unsolicited neighbor advertisements
Occasionally, a node may wish to advertise proactively a change to its link-layer
address to all attached nodes. In this case, the node may choose to send neighbor
advertisements with the new information. Although this method is considered
unreliable and unnecessary because neighbor unreachability detection cleans up
old entries, it is also considered useful as a performance enhancement tool to
prevent extra messages from occurring if the advertisement is successful.
Neighbor unreachability detection

Neighbor unreachability detection is used to detect route changes (links breaking)
and to remove old entries from routing tables. Although this can be done through the
help of higher-layer protocols such as TCP, it is also done through a modified form
of address resolution.
When a host wishes to perform neighbor unreachability detection with address
resolution, the host will send a unicast neighbor solicitation directed to the neighbor
whose reachability is in question. If a neighbor advertisement is received as a
response from the neighbor, the host can conclude that the neighbor is reachable. If
no response is received, the neighbor can conclude that the neighbor is not reachable,
and can delete the corresponding cache entry.
Redirection
Redirection is used to provide nodes with better routes to their destination. If a router
receives a packet where it knows the source has a better route to the destination, the
router will perform redirection.
When a router receives a message and knows that the source has a better route to the
destination, the router will respond to that source with a redirect message. When the
source receives this redirect message, the source will take the redirected packet,
update its cache accordingly, and send the packet to the new destination.

13.1 Overview 13-2
13.2 Monitoring OLT and ONT optics 13-2
13.3 Ping 13-3
13.4 RMON Ethernet statistics 13-3
13.5 Statistics and performance monitoring 13-3
13.6 TCA counters and alarms 13-3
13.7 DS1 and E1 loopbacks 13-5
13.8 Ethernet OAM 13-6

13.1 Overview
This chapter provides a detailed description of the 7342 ISAM FTTU fault isolation
features.
13.2 Monitoring OLT and ONT optics
The 7342 ISAM FTTU supports monitoring of the downstream and upstream optics
operating status for each ONT GPON connection using a TL1 or an element
management system (EMS) management session with the P-OLT.
Optical power levels

A report summary of the current OLT and ONT optical power levels can be viewed.
• ONT receive optical signal level (1490 nm)
• ONT transmit optical signal level (1310 nm)
• OLT receive optical signal level from a specific ONT (1310 nm)
• OLT transmit optical signal level (1490 nm)
Optics module status

The status of the optics modules in the GLT4 card and the ONT units are monitored.
The report summary will display the current:
• temperature of the optics module
• laser bias voltage level
• laser bias current
Downstream threshold monitor

In addition to monitoring optical power levels, you can set high and low optical
power level thresholds for the downstream signals. An alarm is raised in the system
if either the upper or the lower power level threshold is crossed. Use TL1 to
configure optical power level thresholds.
The following wavelengths are used for downstream traffic between the P-OLT and
the ONTs across the GPON:
• 1490 nm downstream signals for data, VoIP, and packetized CES DS1/E1
• 1550 nm downstream signals for overlaid RF video
See the 7342 ISAM FTTU Operations and Maintenance Procedures Guide using
TL1 and CLI and the 7342 ISAM FTTU Fault Isolation and Troubleshooting Guide
documents for details about monitoring ONT optical GPON line power levels and
setting the high and low thresholds.

13.3 Ping
The ping feature is available for troubleshooting layer 3 network connections

between an ONT device and voice gateways or servers on the GPON. From a TL1
management session with the P-OLT, you can initiate a ping from the ONT to any
host device or server on the GPON. For the ping feature to work, the device on the
GPON must be on the same VoIP VLAN as the ONT and VoIP must be provisioned
on the ONT. Only after VoIP is provisioned is the ONT assigned an IP address.
To ping a server on the network, enter the IP address of the server using standard
dotted decimal notation. As a security measure, you can disable the ONT from
responding to ping requests received from devices on the GPON to avoid flooding.
The ONT ping feature is disabled by default. For configuration information, see the
7342 ISAM FTTU Fault Isolation and Troubleshooting Guide.
13.4 RMON Ethernet statistics
The RMON Ethernet statistics (RFC 2819) can be used to track P-OLT Ethernet port
statistics on the NT using any RMON SNMP manager. The statistics can be used to
determine network performance. For example, frame throughput rates, as well as
bandwidth transmit and receive averages and peaks, can be measured by the type of
frame (unicast, multicast, or broadcast), and by the size of the frame.
13.5 Statistics and performance monitoring
Statistics counters and reports are useful for data collection, monitoring system
performance, and for troubleshooting performance on targeted segments of your
network. You can view statistics from a management session with the P-OLT using
TL1 or the EMS interface. Use the TL1 interface to configure performance
monitoring counters. For more information about statistics and performance
monitoring counters, see chapter 19.
VoIP call statistics

VoIP call statistics are useful for troubleshooting voice-related issues and for
information gathering. Statistics are gathered for the last incoming or outgoing call
on each POTS port configured for VoIP on the ONT. You can view VoIP call
statistics from a management session with the P-OLT using TL1 or the EMS
interface. For more information about VoIP call statistics, see chapter 19.
13.6 TCA counters and alarms
The following performance monitoring counters can generate TCA alarms:

• errored or lost Tx and Rx fragments for upstream traffic across all GEM ports on
the GLT2 card on the outdoor ONTs
• lost fragments or bad GEM headers received downstream on aggregate GEM
ports on the outdoor ONTs

• dropped frames (upstream and downstream) for Ethernet traffic on all MoCA,
and Ethernet ports on the outdoor ONT
• Rx errored frames for ports on the ONT configured for MoCA
• Rx errored, severely errored, and unavailable seconds for a VDSL2 transmission
• IN/OUT errored packets at the NT uplink ports
• IN/OUT discarded packets at the NT uplink
TCA alarms
TCA thresholds are applied to 15-min counters. An alarm is raised if the number of
events occurring within a 15-min period exceeds the specified threshold.
The following PON or ONT interface and service alarms are raised:
• PONOLTTC alarms
• PONOLTTCONT alarms
• PONONTTC alarms
• ONTL2UNI alarms
• ONTMOCA alarms
• xDSL (VDSL2) alarms
The following LANX interface alarms are raised (EXNT-A only):

• LANXPORTINERRTCA alarms
• LANXPORTOUTERRTCA alarms
• LANXPORTINDISCTCA alarms
• LANXPORTOUTDISCTCA alarms
TCA alarms are raised if configured thresholds are crossed at the PON optics
interface on OLT or ONT for the following:
• low optical power level
• high optical power level
• low optical Tx level
• high temperature level
• high voltage level
• high laser bias current level
TCA provisioning
Performance monitoring counters are provisioned using either TL1 commands, CLI
commands or an EMS management session with the P-OLT. TCA on the interface
and service is disabled by default. To enable TCA, you must do one of the following,
depending on the interface type.
For a PON or ONT interface and service alarms:
• Set the threshold value using the appropriate TL1 set TCA threshold command.
• Enable TCA using the appropriate TL1 set performance monitoring mode
command.

For LANX interface alarms:

• Set the SHub port administrative state to up, using the appropriate CLI command.
• Set the threshold value using the CLI “configure interface shub port” command.
For configuration information, see 7342 ISAM FTTU Operations and Maintenance
TCAs for backplane errors

See section 19.3 for more information.
13.7 DS1 and E1 loopbacks
You can perform remote loopbacks on DS1 and E1 TDM links at the business ONT
using a TL1 or an element management system (EMS) management session with the
P-OLT.
Caution — Service disruptions will occur on any link that has a
loopback test applied. Services on that link are disrupted for as long
as the loopback test is applied to that link. You must manually
deactivate an active loopback test.
Note — You must put the link in the out-of-service (OOS) state
before you can perform a loopback test on that link.
There are two types of remote loopbacks:

• line loopback (also known as a subscriber-side loopback)
• loops TDM traffic back towards the subscriber on the connected DS1 or E1 links at
the ONT
• terminal loopback (also known as an inward loopback or a network-side
loopback)
• loops traffic back towards the GPON
Figure 13-1 shows the types of loopbacks.
Figure 13-1 Loopbacks
PHY PON
framer interface
Line loopback Terminal loopback

(subscriber-side loopback) (Network-side loopback)
23854

See the 7342 ISAM FTTU P-OLT and ONT Fault Isolation and Troubleshooting for
more information about loopbacks, including considerations when enabling or
disabling loopbacks and instructions on how to perform DS1 and E1 loopback tests
on the business ONT.
13.8 Ethernet OAM
The transition to Ethernet-based aggregation networks requires new operations and

maintenance fault management tools. The 802.1ag standard defines OAM
mechanisms for Ethernet and ITU-T Recommendation Y.1731 defines additional
functionality. See the 7342 ISAM FTTU Fault Isolation and Troubleshooting Guide
for procedural information.
The EFM OAM management supports discovery and variable retrieval functionality
between the ONT and RG ethernet interfaces to perform low level diagnostics on a
per link basis as defined in IEEE 802.3ah. The EFM OAM uses slow protocol,
subtype 3, packets to exchange the information.
Figure 13-2 shows the components of 802.1ag-compliant Ethernet OAM.
Figure 13-2 Ethernet OAM components
GPON access scope
Customer MP Link trace

messages
Access link MEP
Intra-carrier MEP MP MP
Link trace
replies
Trusted Edge Ethernet
router edge/SES 7342 ISAM FTTU ONT RGW/CPE
NT LT NID
Customer MID level

Operator MD level
SES, Local SNI
Access link MEP No

Untrusted Intra-carrier MEP Loopback message
messages
x
MP x MP
x
Customer MEP Customer MEP Loopback
replies No
Source reply
of fault
MEP Maintenance association NID Network Interface Device

Ports
MIPs Continuity checks
19054
Table 13-1 lists details of the OAM components.

Table 13-1 Ethernet OAM components
Component Details Configuration
Maintenance domain (MD) MD levels divide the network into multiple administrative Create domains using
OAM domains. TL1
Maintenance association MA is an OAM maintenance entity per service instance in the Create MAs using TL1
(MA) MD, such as a VLAN. An MA associates maintenance end points
or maintenance intermediate points into one OAM
maintenance entity, for example, the endpoints and
intermediate points of a VLAN.
Maintenance end points MEPs are configured on ports, services such as a VLAN, or MD. Create MIPs and MPs
(MEPs) MEPs either start or terminate an OAM test, such as a using TL1
loopback or continuity check.
Maintenance MIPs passively process and allow the transit of an OAM packet N/A
Intermediation points to or from a MEP.
(MIPs)
Table 13-2 lists the supported OAM Ethernet tools.
Table 13-2 Ethernet OAM supported tools
OAM tool Details See
Continuity check (CC) Use CCs to have MEPs send multicast connectivity check Continuity check tests
messages periodically. All MEPs and MIPs in the MD receive
the messages, and update its database to know the status
between itself and the MEP sending the CC message.
Link trace Use link traces to trace the path between MPs in a single MD. Link trace tests
All intermediate MIPs between the MPs respond with a link
trace reply until the MP at the end of the domain is reached.
The link trace results are used to determine the path for a
loopback by providing MAC addresses of all MIP and MP
devices.
Loopback Use loopbacks to determine the source of a fault along an MA. Loopback tests
The MP issues a loopback message to MIPs.
The MIP just before the fault point will issue a loopback reply.
The MIP just after the fault will not issue a loopback reply.
Alarm Indication Signal Use AIS to indicate an alarm from an ONT towards an SES SES switch local SNI and
(AIS) switch when there is a UNI port failure AIS
Continuity check tests

All peer MPs in the same MA exchange CC messages. All MIPs and MPs along the
same MA build a database of their peers. Only one MIP on the 7342 ISAM FTTU
processes CC messages.
Downstream CC messages will be dropped by the LT card.

Upstream CC messages can be sent from the ONT. The upstream messages will be
passed transparently by the LT and LANX, as shown in Figure 13-3.
Note — For the ONT CCM to pass transparently if no MEP is

created, flooding will need to be enabled on the LANX VLAN.
Figure 13-3 CC messages on ONTs
AMS/ Router or LANX/NT LT ONT RG

CLI/ Switch Trusted and untrusted
TL1
7342 ISAM FTTU Service provider/
ONT/RG generated CCM toward Upstream Switch Customer level
LANX forwards CCM messages

to the NW ports based
on MD level.
19059
Link trace tests

A link trace acts like an ICMP traceroute command. Multicast link trace messages
(LTMs) are sent from the originating OAM MP. Each MIP along the trace path
inspects the message to determine whether the target MAC address of the LTM is
known. If the MIP knows the MAC address, the MIP forwards the LTM to the next
MIP, and a response in the form of a link trace reply (LTR) message is sent back to
the MP. A MIP that does not know the target MAC address does not send back an
LTR. When the target MP responds with a successful LTR message, the link trace
test is successfully completed.
Note — Only downstream Link trace tests are supported.
Figure 13-4 shows the sequence for an link trace. In a link trace, the MP is on the
ONT.

Figure 13-4 Link trace test sequence
7342 ISAM FTTU
NMS Router or NT LT ONT RG

CLI/ Switch
TL1
Perform link test
(access-level, S-VLAN,
C-VLAN, MEP ID, p-bit)
The 7342 ISAM FTTU checks VLAN and

port membership. It obtains the MAC
address from MP ID internally. It forms
a link trace message packet with given
destination MAC address and p-bit and
forwards to LT ports only.
LT checks if MAC address exists in

forwarding database. If yes, LT
forwards it on GEM PORT
corresponding to service and p-bits
ONT extracts the packet based

on MAC address and Ethertype.
It sends a link trace message
reply with same p-bit and C-VLAN.
LT forwards LTM
reply to NT
Response (LT success/failure; (no processing)
ONT success/failure
19057
Loopback tests
A loopback acts like an ICMP ping command. Multicast or unicast loopback
messages (LBMs) are sent from the originating OAM MP with the MAC address of
the destination MP. Each MIP along the loopback forwards the LBM to the next
MIP. When the target MP receives the LBM with the matching MAC address, the
destination MP sends back a unicast or multicast loopback response (LBR) message
to the originating MP. When the originating MP receives the LBR, the loopback is
complete.
Note — Only downstream Loopback tests are supported.
Figure 13-5 shows the sequence for an loopback. In this loopback, the MP is on the
ONT.

Figure 13-5 Loopback test sequence
7342 ISAM FTTU
WMS/ Router or NT LT ONT RG

CLI/ Switch
TL1
Perform loop back (based on access-level,
S VLAN, C VLAN, including MEP ID, p-bit)
NT checks V LAN and

port membership. It obtains the MAC
address from MEP ID internally. It forms
a loopback message packet with given
destination MAC address and p-bit and
forwards to LT ports only.
LT forwards the loopback message

like any other packet based on
S-VLAN, C VLAN, MAC address
and p-bits.
ONT extracts the packet based

on MAC address and Ethertype.
It sends a link trace message
reply with same p-bit and C-VLAN.
LT forwards loopback
message reply to NT
Response (success or failure)
19060
Jitter and latency measurements

Provisioning of the primary S-VLAN and C-VLAN for the MEP at the ONT UNI,
the MEP becomes VLAN aware and can now process and respond to
ETH-LMM-PDUs and ETH-DMM-PDUs from a Peer-MEP, on the Network Edge,
on the same MEG level.
The MEPs at the ONT UNI behave like a Passive End-Point and can not generate
ETH-LM/DM request messages toward the Peer-MEP. The Peer-MEP (at the
Network Edge) is expected to be an Active End-Point that generates periodic
ETH-LM/DM messages toward the ONT-UNI MEP and process ETH-LMR/DMR
messages from the ONT-UNI MEP to calculate the path loss, delay and jitter values.
The OLT, both the LT and the LANX will transparently forward all ETH-LM/DM
messages in the datapath. For this forwarding to occur at the LANX, no MEP should
be created at the LANX and flooding shall be enabled on the Primary S-VLAN.
SES switch local SNI and AIS

Allows the user to isolate faults between two end points, where an intermediate point
can divide the MD into two regions:
• SES switch (MEP) to LT (MIP), and
• LT (MIP) to ONT (MEP)

Figure 13-5 shows the scenarios for an SES switch and local SNI.
Figure 13-6 SES switch local SNI scenario
SES OLT ONT NID CPE

switch
LT
Customer MD level
Loopback
Provider MD level
CC
Loopback
Intra provider MD level
MEP
MIP
22794
Ethernet AIS
Generation of ETH-AIS by the ONT-UNI MEP can be enabled so that upon
detection of a local link failure, (LOS), an ETH-AIS-PDU is sent toward the network
on the provisioned VLAN and MEG level.
Note — One ETH-AIS-PDU is generated immediately upon

detection of failure and then one ETH-AIS-PDU is generated at one
minute intervals until the failure condition is cleared.
EFM OAM
The EFM OAM is enabled on a per link basis to implement the following
functionality:
• discovery of a RG (in active or passive mode)
• transmit OAMPDU to RG
• send Variable Request to RG
• receive Variable Response from RG
• receive Variable Request from RG
• send Variable Response to RG
• receive critical link events from RG so ONT can send alarms to OLT using OMCI


14.1 Overview 14-2
14.2 IP multicast stream flow 14-4
14.3 IGMP infrastructure 14-4
14.4 IGMP signaling 14-5
14.5 IGMP proxy 14-6
14.6 IGMP snoop 14-9
14.7 Subscriber access networks 14-10
14.8 ASM and SSM multicast 14-17
14.9 Preconfigured and nonconfigured multicast 14-19
14.10 Join and leave messages 14-20
14.11 Counters and alarms 14-27
14.12 Subscriber and video management 14-31
14.13 IGMP protocol handling with no IGMP signaling channel 14-36

14.1 Overview
The 7342 ISAM FTTU delivers video streams on demand to IPTV video subscribers
using the IP multicast technology.
IP multicast is a technology that can send a single copy of data using a single address
for a group of recipients.
IP multicast is delivered to a group of subscribers that request a particular data
stream. The membership of the group is not restricted by the locations. These
members are hosts on the IP network. The group is identified by a single destination
IP address that must be within the “Class D” range.
Hosts that need to receive a data stream delivered to a particular group must join the
group through the Internet Group Management Protocol (IGMP). IGMP is a protocol
used by hosts and multicast routers in a single physical network to establish hosts
memberships in particular multicast groups. The 7342 ISAM FTTU supports two
versions of IGMP:
• IGMP version 2 (IGMPv2) is described in RFC 2236. IGMPv2 provides support
for low leave latency by reducing the amount of time that it takes for a multicast
router to learn that there are no longer any members of a particular group present
on an attached network.
• IGMP version 3 (IGMPv3) is described in RFC 3376. IGMPv3 provides support
for multiple group records in a single report.
TL1 and CLI for multicast and IGMP configuration procedures.
Features
Table 14-1 provides information about the IP multicast features.

Table 14-1 IP multicast features
Features Description
IGMP system The IGMP system consists of:

• IGMP proxy at the NT to manage a multicast forwarding database to control
forwarding of IP multicast streams from the network to the LT card
• IGMP proxy at the LT to manage a multicast forwarding database to control
forwarding of IP multicast streams from the LT card to the multicast GEM port
ID
• IGMP snoop at the ONT to manage a multicast forwarding database to control
forwarding of IP multicast streams from the multicast GEM port ID to
requesting UNI ports
IP multicast The IP multicast supports replication and forwarding from the NT cards to LT
stream cards over point-to-point eHCL links. The LT can receive multicast traffic at the
processing full 4 Gb/s throughput capacity on the eHCL links if required. The individual link
between the NT and LT is selected using a source IP address plus destination IP
address based hashing method.
On the LT card, the multicast data stream is replicated so that each GPON can
share the same IP multicast stream if there are subscribers requesting the same
stream on each GPON. For example, if an IP multicast stream is sent to one GPON
on the LT at 1.5 Gb/s, the LT replicates the stream so that the other GPON can
receive the same IP multicast stream. Multicast replication on the LT can increase
the efficiency of bandwidth utilization on the eHCL links between the NT and the
LT. Each GPON can simultaneously support up to 2.4 Gb/s of multicast traffic with
this approach, although the NT to LT capacity is 4 Gb/s.
IGMP message The IP multicast supports both IPoE and PPPoE encapsulated IGMP messages.
encapsulation
IGMP versions The IP multicast supports:
• IGMP version 2 as defined in RFC 2236
• IGMP version 3 as defined in RFC 3376 with source-specific multicast (SSM) in
the control plane
• IGMPv2/IGMPv3 selectable per subscriber at the ONT UNI port level
IGMP signaling • 256 IGMP messages/second per PON

• 512 IGMP messages/second per GLT2
• 1024 IGMP messages/second per GLT4
• 100 ms max per ZAP in the access network
• fast channel leave through source MAC address tracking
Multicast support • Support for preconfigured and nonconfigured multicast

• multiple service providers with non-overlapping IP multicast addresses
through Any Source Multicast (ASM)
• multiple service providers with overlapping IP multicast addresses through
source-specific multicast (SSM)
Multicast Configured IP multicast streams are treated as members of the IPTV domain.
streams capacity • 4096 provisioned multicast streams
• 1024 active multicast streams per NT
• 1024 active multicast streams per LT PON
• 8 system-wide static multicast streams
• 64 active multicast streams per ONT UNI port
Video • 1024 channel packages and access control

management • channel preview
• viewer statistics through Call Data Records (CDR) and SYSLOG
Bandwidth and The IGMP proxy on the LT card can control the amount of bandwidth used across
streams control the GPON for support of the IP multicast service. It can also control the number
of streams allowed to be delivered to a subscriber.
(1 of 2)

Features Description
Multicast stream Eight on-demand traffic flow monitors

monitoring
(2 of 2)
Note — For some ONTs, only one UNI port at a time can be
configured for multicast streams. For more information about ONTs
and multicast support, see the 7342 ISAM FTTU ONT Product
Information Manual
14.2 IP multicast stream flow
The content of IP multicast streams can include various types of information, such
as video, audio, data carousel, and electronic multicast guides. An IP multicast
stream flows from the network to the subscriber as follows:
1 Network equipment
• Provides source of the IP multicast stream
• Delivers the requested IP multicast stream to the NT card through external ports that
connect the network equipment to the NT card
2 NT card
• Replicates the IP multicast stream for each requesting LT card
• Forwards the requested stream to the LT card through internal ports over the
multicast VLAN associated with the IPTV service provider
3 LT card
• Replicates the IP multicast stream for each requesting GPON
• Forwards the IP multicast stream to a single GEM port ID on the requesting GPON
using its interworking function
4 GPON
• Allows the IP multicast stream to be distributed to multiple subscribers on the
GPON because of its broadcast nature
5 ONT
• Replicates the IP multicast stream for each requesting UNI port
• Forwards the requested stream from the multicast GEM port ID on the GPON to the
user-to-network (UNI) port that connects the subscriber equipment to the ONT
6 Subscriber equipment
• Receives and plays the requested IP multicast stream to the subscriber through a
host on the UNI port
• Sends IGMP join and leave messages requested from the subscriber to the ONT
through the UNI port
14.3 IGMP infrastructure
Figure 14-1 is a high-level view of the IGMP infrastructure that is implemented on

the 7342 ISAM FTTU system to support multicast forwarding of a stream from the
network equipment to the subscriber equipment.

Figure 14-1 IGMP infrastructure
P-OLT NT P-OLT LT ONT
IGMP IGMP IGMP

Proxy Proxy Snoop
IGMP Joins, Leaves

and Reports
IGMP GMQs, GSQs

and GSSQs
Network Subscriber
Equipment Equipment
Multicast Forwarding
upstream
downstream
19241
The elements of the IGMP infrastructure include the following:

• IGMP signaling
• between each network interface port on the NT and the NT
• between the NT and LT cards
• between the LT and each user-to-network interface (UNI) port on the ONT
• IGMP proxy
• on the NT card
• on the LT card
• IGMP snoop on the ONT
• subscriber access network
• IPoE subscriber access network
• PPPoE subscriber access network
These infrastructure elements are described in the sections that follow.
14.4 IGMP signaling
IGMP signaling is a protocol used to add and remove IP multicast streams. IGMP
signaling consists of a set of IGMP messages that communicate the requirements for
delivery of IP multicast streams. Table 14-2 lists the IGMP message types.
Table 14-2 IGMP message types
IGMP message type Description
Join A request to send an IP multicast stream
Leave A request to stop an IP multicast stream
(1 of 2)

IGMP message type Description
Query A request about the usage status of an IP multicast

stream, which includes the following queries:
• general membership query (GMQ)
• group specific query (GSQ)
• group source specific query (GSSQ)
Report A status report on the usage of an IP multicast stream
(2 of 2)
IGMP signaling between the network and NT

The NT receives query messages from the network, and responds to the network with
report messages. The NT sends to the network a “first” join message to start the
delivery of an IP multicast stream, and a “last” leave message to stop the delivery of
an IP multicast stream when the stream is no longer in use.
IGMP signaling between the NT and the LT card

The LT card receives query messages from the NT and forwards join, leave, and
report messages to the NT over the multicast VLAN associated with the IPTV
service provider.
IGMP signaling between the LT card and the ONT UNI port
An ONT can support one or more UNI ports. The port is either a 10/100 Base-T or a
10/100/1000 Base-T Ethernet, or a VDSL2 port. Each Ethernet/VDSL2 port is
associated with a single subscriber and is supported by eight subscriber GEM port
IDs on the GPON side. Each subscriber GEM port ID maps to a different priority
level and carries join, leave, and report messages upstream from the ONT to the LT
card, and query messages downstream from the LT card to the ONT.
Note — For some ONTs, only one UNI port at a time can be
configured for multicast streams. For more information about ONTs
and multicast support, see the 7342 ISAM FTTU ONT Product
Information Manual.
14.5 IGMP proxy
IGMP proxy is a facility that acts on behalf of hosts. IGMP proxy manages a
multicast forwarding database that lets routers know which IP multicast streams are
to be delivered to subscribers, by performing the following functions:
• Sends query messages to determine the usage status of IP multicast streams
• Receives join, leave, and report messages
• Adds or removes an entry in the multicast forwarding database in response to
join, leave, and report messages
• Sends a “first” join message to the network to start the delivery of an IP multicast
stream

• Sends a “last” leave message to the network to stop the delivery of an IP multicast
stream
• Responds to incoming query messages from the network on the usage status of IP
multicast streams
IGMP proxy is implemented at both the NT and the LT card, which optimizes the
utilization of bandwidth by allowing the IP multicast streams to be delivered
on-demand to the subscribers without replicating them.
The IGMP proxy facility on the LT card can operate in half-proxy mode where the
LT does not behave as a proxy on the subscriber side. In this mode, the network-side
equipment sends its own IGMP query messages to subscribers, and receives IGMP
leave, join, and report messages from the subscribers. The LT monitors the PPPoE
or IPoE stream of IGMP messages between the network-side equipment and the
subscribers.
The OLT supports “data plane” hardware based multicast forwarding using (VLAN
ID, group IP address). Multicast streams are replicated at the OLT-NT to each
requesting OLT-LT. The OLT-LT replicates each stream to each requesting PON. A
single copy of a requested multicast stream is delivered across the PON. The
hardware based multicast forwarding is maintained by the IGMP proxy facility at
both the OLT-NT and OLT-LT.
The OLT supports the provisioning of 4096 IPTV channels from which 1024 can by
simultaneously active across the OLT.
IGMP proxy at the NT

In the downstream direction, the IGMP proxy at the NT sends query messages to the
LT card to determine the status of active IP multicast streams. The IGMP proxy also
adds and removes entries in the multicast forwarding database in response to join,
leave, and report messages received from the LT card.
In the upstream direction, the IGMP proxy at the NT responds to query messages
received from the network by sending report messages that indicate the IP multicast
streams that are still required. The IGMP proxy also sends to the network a “first”
join message to start the delivery of an IP multicast stream and a “last” leave message
to stop the delivery of an IP multicast stream.
Querier election is used when more than one network-side router will send
IGMP GMQ and IGMP GSQ messages. The router with the lowest source IP address
in its IGMP GMQ and IGMP GSQ messages is elected the querier. The other routers
move to a passive state until queries from the elected router are no longer seen, at
which point the querier election process resumes. For more information, see RFC
3376 (IGMPv3), section 6.6.2 Querier Election.
The 7342 ISAM FTTU enables querier election when a VLAN has more than one
static router port. When an IGMP GMQ or IGMP GSQ message is received on one
of the static router ports, the IGMP proxy facility at the NT floods the message to all
the other static router ports for the VLAN. The IGMP proxy uses the elected router
port to send its network-side IGMP join, leave and report messages. If a router port
has not been elected, the IGMP proxy sends its messages on all router ports.

IGMP proxy on the LT card

In the downstream direction, the IGMP proxy on the LT card sends query messages
to the subscribers to maintain the status of active multicast streams on the GPON.
The IGMP proxy on the LT card receives and responds to join, leave, and report
messages received from the subscribers.
In the upstream direction, the IGMP proxy on the LT card responds to query
messages received from the NT, and sends join, leave, and report messages to the NT
requesting the addition or removal of an IP multicast stream.
IGMP half-proxy mode on the LT card

The IGMP proxy on the LT card can be configured in PPPoE or IPoE half-proxy
mode. In half-proxy mode, the LT only acts as a proxy on the network side, but not
on the subscriber side. On the network side, the LT receives IGMP queries from the
NT, and responds with IGMP reports. The LT, however, does not generate IGMP
queries to subscribers on behalf of network-side equipment.
• In the downstream, a network-side equipment, such as a broadband remote access
server (BRAS) or a gateway router (GWR), sends IGMP GMQ and GSQ
messages to the subscribers on the customer VLAN (C-VLAN) to maintain the
status of streams.
• In the upstream, the subscribers send IGMP joins, leaves, and reports to the
network-side equipment on the C-VLAN. The IGMP proxy on the LT snoops
these upstream IGMP messages from the subscribers to maintain its forwarding
database, and sends IGMP leaves and joins to the NT on the multicast VLAN
when an IP multicast stream must be added or removed.
Note 1 — The IGMP half-proxy on the LT card does, however,

aggregate IGMP reports and leaves from the RG to network-side
equipment.
Note 2 — IGMP signaling between the NT and the network-side
equipment can be disabled using the CLI; see the 7342 ISAM FTTU
Operations and Maintenance Procedures Guide using TL1 and CLI
for configuration information.
Note 3 — In IPoE half-proxy mode, you can configure the IGMP
proxy facility at the LT to drop the IGMP join requests that fail the
IGMP CAC checks from the multicast VLANs and optionally the
subscriber C-VLANs.
Figure 14-2 illustrates this configuration.

Figure 14-2 IGMP half-proxy mode
Multicast VLAN
IPTV Payload MC VLAN IPTV Payload MC VLAN IPTV Payload
IGMP join in multicast VLAN*

IGMP leave in multicast VLAN*
Multicast Channel in MC VLAN
Ethernet IP or
edge Ethernet
router
RGW ONT OLT 7750 SR
IGMP join/report in customer VLAN
IGMP leave in customer VLAN
IGMP GSQ, GMQ
Payload Payload CVLAN Payload CVLAN SVLAN
*The IGMP signaling between the NT and the Customer VLAN

network side equipment is configurable
20877
The configuration is suitable for deployments where network-side equipment

performs subscriber accounting of channel usage and CACing of IPTV requests from
subscribers, and uses the proxy facilities at the P-OLT to maintain the multicast
forwarding databases and to replicate downstream multicast traffic received on a
multicast VLAN.
See IPoE half-proxy mode and PPPoE half-proxy mode for more information about
the half-proxy mode.
14.6 IGMP snoop
The ONT supports an IGMP snoop facility. The IGMP snoop facility snoops (looks
into) upstream join and leave messages, and maintains the multicast forwarding
database supported by the ONT hardware, which keeps track of the IP multicast
streams that subscribers are currently viewing.
Note — The IGMP snoop facility only drops an IGMP message if the
IGMP message rate limit is exceeded.
IGMP snoop versus IGMP proxy

Subscribers (hosts) send IGMP directly to IGMP proxy, which can regenerate IGMP
if required; IGMP snoop can only look into IGMP. Figure 14-3 illustrates this
difference.

Figure 14-3 IGMP snoop versus IGMP proxy
IGMP snoop (to snoop = to dig into, to look into)

A Subscribers (hosts) directly address IGMP proxy at the LT card.
B IGMP snoop at the ONT only monitors.
IGMP proxy (to proxy = to delegate, to authorize someone else to do)

C IGMP proxy at the LT card regenerates IGMP if required, and directs it to IGMP Proxy at the NT.
D IGMP proxy at the NT regenerates IGMP if required, and directs it to the multicast router.
NT LT card ONT
IGMP IGMP IGMP Hosts
proxy proxy snoop
D C B H A
IGMP H IGMP IGMP
R R H R
IGMP
H
H Host
R Router
Multicast forwarding database
19336
The IGMP messages sent by the subscribers terminate at the router interface of the
IGMP proxy on the LT card.
If a message represents a first join to an IP multicast stream or a last leave of an IP
multicast stream, the IGMP proxy on the LT card generates and sends, on its host
interface, an IGMP message to the IGMP proxy at the NT to start or stop the delivery
of the IP multicast stream.
If required, the IGMP proxy at the NT generates and sends, on its host interface, a
first join or last leave IGMP message to the multicast router.
14.7 Subscriber access networks
The 7342 ISAM FTTU supports two types of subscriber access network for IP
multicast services: IPoE and PPPoE.
IPoE subscriber access network

The IPoE subscriber access network is an IP-based end-to-end architecture that
integrates network routers and switches, such as Alcatel-Lucent 7750 Service Router
and the 7450 ESS, with the access network provided by the 7342 ISAM FTTU and
a residential gateway at customer premises.
Figure 14-4 shows the IPoE subscriber access network architecture and the signaling
flow.

Figure 14-4 IPoE subscriber access network architecture and signaling flow
Video server 7750/7450 7342 OLT-NT 7342 OLT- 7342 ONT RGW Set-top box
LT
IP termination IGMP IP termination
IP termination IGMP proxy IGMP proxy snooping IGMP proxy
IGMP termination IGMP
termination
IPoE (IGMP IPoE (IGMP Report/Leave) IPoE

Report/Leave)
IPoE (IGMP GSQ/GMQ/GSSQ) IPoE
IPoE (IGMP
GSQ/GMQ/GSSQ)
IPoE (UDP/RTP multicast stream)

19242
The 7342 ISAM FTTU supports layer 2 QoS based on the ITU-T 802.1q
prioritization and frame scheduling. The network routers, switches, and residential
gateway support layer 3 QoS requirements that are using differentiated services and
rate shaping.
IGMP messages across the access network are encapsulated in IP packets.
Time-critical IP multicast streams such as video on demand and broadcast video are
rate shaped at the video source, the video server, network routers, and switches, and
forwarded to subscribers encapsulated in IP packets.
The IPoE multicast service supports a VLAN for each subscriber or a VLAN for each
service deployment model. IP multicast streams are sourced from one or more
VLANs.
The residential gateway and the LT card support an IGMP proxy and encapsulate
IGMP signaling messages using IP. The LT cards also support IGMP statistics and
fast leave. Fast leave is an enhancement to the standard leave facility introduced in
IGMP v.2 (RFP 2236) and quickly removes unused multicast streams to recover
transport resources.
The 7342 ISAM FTTU controls multicast forwarding by supporting IGMP proxy on
NT cards and IGMP snoop on the ONTs.
IPoE half-proxy mode

IGMP messages between the GWR and the RG are encapsulated in subscriber IPoE
sessions. IP multicast streams originate from the GWR and are forwarded to
subscribers encapsulated in IP packets. IGMP messages between the GWR and the
NT card are encapsulated in IPoE. However, IGMP signaling between the GWR and
the NT can be disabled.
The RG supports an IGMP proxy and encapsulates IGMP signaling messages using
IPoE. The RG only responds to IPoE encapsulated IGMP queries from the GWR.
To support this architecture (see Figure 14-5), the 7342 ISAM FTTU IP multicast
service supports the following:
• IGMP proxy facility on the NT card and IGMP snoop facility at the ONTs
• a half IGMP proxy facility on the LT card

The IGMP proxy on the LT can be configured in IPoE half proxy mode. In this mode,
the proxy module behaves as a normal proxy on the network side. The LT sends
IGMP report and leave messages as required to the NT, and responds to IGMP
queries received from the NT.
However, the IGMP proxy on the LT card does not generate and send IGMP GMQ
and GSQ messages to the subscribers on behalf of the GWR. The GWR generates
and sends its own IGMP queries to the subscriber on the C-VLAN to audit the status
of streams.
The IPoE session flow between the subscriber RG and the network GWR is not
interrupted. The subscriber sends IGMP join, leave, and report messages over the
IPoE session to the GWR on the C-VLAN. The LT sends a copy of these IPoE
encapsulated IGMP join, leave, and report messages to the LT-OBC to maintain its
multicast forwarding database. The LT tags the original messages with their
S-VLAN and forwards them to the GWR to ensure an uninterrupted IPoE stream
between the GWR and the RG.
Note — The multicast VLAN and the C-VLAN cannot be the same.
The multicast VLAN is entered in the multicast source table; a
C-VLAN cannot be entered in the multicast source table.
Figure 14-5 shows the processing flow in IPoE half-proxy mode.

Figure 14-5 Processing flow in IPoE half-proxy mode
Multicast source table GWR

- Forwarding table
update
IPoE 5 IPoE 7
4
EHNT -OBC EHNT -B
IGMP Proxy
3
GLT-OBC GLT2/4
IGMP Proxy Half Proxy 2
IPoE IPoE
Multicast Source Table ONT

- CAC function IGMP Snoop
- Forwarding table
update
IPoE IPoE
6 1
RG
IGMP Proxy
IPoE
STB STB PC
20878
The sequence of events, as numbered in Figure 14-5, is as follows:

1 The set-top box (STB) sends an IGMP join, leave, or IGMP query report
message to the RG, which sends the message over the subscriber's IPoE session.
2 A copy of the IGMP message is forwarded to the OBC on the LT card for
processing, and the original IGMP message is forwarded upstream towards the
GWR on the C-VLAN. The LT adds the S-VLAN tag to the original IGMP
message before forwarding it upstream.
3 The LT updates its multicast forwarding database, based on the subscriber’s
request. If a requested multicast stream is not in the multicast forwarding
database of active streams, the LT forwards the request to the NT.
4 The NT updates its multicast forwarding database, as required, based on the
request received from the LT.
5 The GWR forwards the requested stream to the NT, where it is forwarded from
the NT to the LT to the appropriate PON(s).

6 The RG forwards the requested stream to the STB.

7 The GWR sends IGMP GMQ and GSQ messages to the subscriber over the IPoE
session to maintain the streams.
In half-proxy mode, the IGMP proxy does not support the standard leave algorithm
(see IGMP standard leave). Therefore, the IGMP proxy on the LT card depends on
the GMQ and GSQ time-outs to determine when to remove a stream from a PON or
a UNI port. Care must be taken to ensure that the robustness count and the GMQ and
GSQ timers that are configured for the GRW are not greater than the corresponding
values at the LT. The ONT IGMP snoop facilities depends on source MAC address
tracking and stream aging to determine when to remove a stream from the GPON or
UNI port respectively.
The IGMP fast leave algorithm (see IGMP fast leave), which is implemented on the
LT and the ONT, removes a stream from the GPON or the UNI port before the
configured time to respond to an GWR IGMP GSQ expires.
PPPoE subscriber access network

The PPPoE subscriber access network is a legacy access network as specified in
TR-025 and TR-059. This access network supports PPPoE subscriber protocols as
described in TR-043.
Figure 14-6 shows the PPPoE subscriber access network architecture and signaling
flow.
Figure 14-6 PPPoE subscriber access network architecture and signaling flow
BRAS 7342 OLT-NT 7342 OLT- 7342 ONT RG Set-top box

GLT2
PPPoE IGMP IGMP PPPoE IP termination
termination proxy IGMP snooping termination
IGMP snooping/proxy IGMP proxy IGMP
termination termination
PPPoE (IGMP Report/Leave) IPoE
PPPoE (IGMP GSQ/GMQ/GSSQ) IPoE
Video server
IPoE (IGMP GSQ/GMQ/GSSQ)
IP termination
IPoE (IGMP Report/Leave)
IPoE (UDP/RTP multicast stream)
18192
The PPPoE subscriber access network can be upgraded to support an Ethernet-based

architecture using the WT-101 migration guidelines while preserving the existing
PPPoE-based subscriber management infrastructure.
The 7342 ISAM FTTU IP multicast service supports half proxy mode.

PPPoE half-proxy mode

IGMP messages between the BRAS and the RG are encapsulated in subscriber
PPPoE sessions. IP multicast streams originate separately at an edge multicast router
and are forwarded to subscribers encapsulated in IP packets. IGMP messages
between the edge multicast router and the NT card are encapsulated in IPoE.
The RG supports an IGMP proxy and encapsulates IGMP signaling messages using
PPPoE. The RG only responds to PPPoE encapsulated IGMP queries from the
BRAS.
To support this architecture (see Figure 14-7), the 7342 ISAM FTTU IP multicast
service supports the following:
• IGMP proxy facility on the NT card and IGMP snoop facility at the ONTs
• a half IGMP proxy facility on the LT card
In PPPoE half-proxy mode, the IGMP proxy module behaves as a normal proxy on
the network side. The LT sends IGMP report and leave messages as required to the
NT, and responds to IGMP queries received from the NT.
However, the IGMP proxy on the LT card does not generate and send IGMP GMQ
and GSQ messages to the subscribers on behalf of the BRAS. The BRAS generates
and sends its own IGMP queries to the subscriber to audit the status of streams.
The PPPoE session flow between the subscriber RG and network BRAS is not
interrupted. The subscriber sends IGMP join, leave, and report messages over the
PPPoE session to the BRAS. The LT sends a copy of these PPPoE encapsulated
IGMP join, leave, and report messages to the LT-OBC to maintain its multicast
forwarding database. The LT tags the original messages with their S-VLAN and
forwards them to the BRAS to ensure an uninterrupted PPPoE stream between the
BRAS and the RG.
Note — The multicast VLAN and the C-VLAN cannot be the same.
The multicast VLAN is entered in the multicast source table; a
C-VLAN cannot be entered in the multicast source table.
Figure 14-7 shows the processing flow in PPPoE half-proxy mode.

Figure 14-7 Processing flow in PPPoE half-proxy mode
Multicast source table

- IP multicast address
- Peak bit rate Multicast
edge router BRAS
- Sustained bit rate
- Source VLAN ID
IPoE 4 PPPoE 6
3
GLT-OBC GLT-IWF
IGMP Proxy 2
IPoE PPPoE
ONT
IGMP Snoop
IPoE PPPoE
5
RG
First report “John” IGMP Proxy
Last leave
over PPPoE
1
IPoE
STB STB PC
20879
The sequence of events, as numbered in Figure 14-7, is as follows:

1 The set-top box (STB) sends an IGMP join message to the RG, which sends the
message over the subscriber's PPPoE session.
2 A copy of the IGMP join message is forwarded to the OBC on the LT card for
processing. If the IP multicast address is found in the multicast source table, an
entry is added to the multicast forwarding table.
3 If the stream is not on the PON, the IGMP proxy on the LT sends an IGMP join
message to the multicast edge router to request the stream. The IGMP proxy also
responds to IGMP queries from the multicast edge router.
4 The multicast edge router forwards the requested stream to the LT through the
NT, and the LT forwards the stream to the appropriate PON(s).
5 The RG forwards the requested stream to the STB.
6 The BRAS sends IGMP GMQ and GSQ messages to the subscriber over the
PPPoE session to maintain the status of the streams.

In half-proxy mode, the IGMP proxy does not support the standard leave algorithm
(see IGMP standard leave). The IGMP proxy on the LT card must depend on GMQ
and GSQ time-outs to determine when to remove a stream from a PON or a UNI port.
Care must be taken to ensure that the robustness count and the GMQ and GSQ timers
that are configured for the BRAS are not greater than the corresponding values at the
LT. The ONT IGMP snoop facilities must depend on source MAC address tracking
and stream aging to determine when to remove a stream from the GPON or UNI port
respectively.
The IGMP fast leave algorithm (see IGMP fast leave), which is implemented on the
LT and the ONT, removes a stream from the GPON or the UNI port before the
configured time to respond to a BRAS IGMP GSQ expires.
14.8 ASM and SSM multicast
The 7342 ISAM FTTU supports both ASM and SSM.
ASM
In the ASM service, a subscriber expresses interest in traffic to a multicast address.
The multicast network must discover all multicast sources sending to that address,
and route data from all sources to the subscriber. This behavior is particularly well
suited to groupware applications where all participants in the group want to be aware
of all other participants, and the list of participants is not known in advance.
SSM
In an aggregation network, different video or media content providers may have their
own VLANs. Typically, the video or media content providers choose the group
addresses (the multicast IP addresses) for the channels. In this scenario, some
addresses may overlap. The ASM service method does not allow for the
distinguishing of channels from different video or media providers.
In the SSM model, the only multicast packets that are delivered to a subscriber are
those originating from a specific source address requested by the subscriber. SSM
requires that the subscriber specify the source address, which is possible only in
IGMPv3 for IPv4. The source IP address is carried in the IGMP join request, and in
the downstream multicast stream. SSM is supported in the control plane where
lookups in the multicast source table can be performed using (VID, GIP, SIP) and
(VID, GIP, *).
Configuration considerations
Using SSM in the control plane eliminates the ASM inability to distinguish channels
by identifying channels both by the multicast IP address and by the source IP address.
Figure 14-8 shows this configuration.

Figure 14-8 IGMP SSM configuration
List of preconfigured channels

Group IP@ Source IP@ VLAN
G S1 A
G S2 B
VLAN A
Port 6 Port
multicast bridge Preconfigured stream (G, S1)
VLAN Group IP@ Egress port list

A G (Port6, ...) VLAN B
Port
multicast bridge Preconfigured stream (G, S2)
VLAN Group IP@ Egress port list

B G (Port6, ...)
20394
1 The IGMP client sends the IGMP join request for a specified group address and
the source address.
2 The IGMP proxy performs a lookup on the IP multicast address (in the ASM
case) or the IP multicast address and the source address (in the SSM case) in the
multicast source table.
3 The IGMP proxy adds the IP multicast address and the source VLAN ID of the
requested IP multicast stream to its forwarding database and associates it with the
multicast GEM port ID.
4 If the request is a first join, the IGMP proxy sends a “first” join message to the
NT using the multicast VLAN.
5 When the IP multicast stream arrives from the NT card over the multicast VLAN,
the LT forwards it across the GPON using the multicast GEM port ID.
Following are restrictions that apply to SSM configuration.

• SSM cannot be used with ASM in a VLAN.
• There is no support for exclude filters on the LT (for example, no filters for
limiting IGMP requests to join channels with a specific group IP address and with
a specific source address).
• In an environment where some video and media providers use SSM and others do
not, ensure that group IP addresses used for ASM do not overlap; separate address
ranges are recommended when ASM and SSM are mixed.

• SSM can be used for preconfigured channels for which the system maintains a list
of applicable VLANs, and nonconfigured multicast. If the IGMP VLAN selection
is enabled, the system includes the NSP VLAN ID in the IGMP signaling channel
supporting the subscriber, or the S-VLAN ID of the HSI or service flow
supporting the IGMP signaling channel in the lookup.
• SSM is possible only in IGMPv3 for IPv4.
14.9 Preconfigured and nonconfigured multicast
A multicast source is typically configured when the multicast source is offered as a

multicast channel to subscribers. The system supports preconfigured and
nonconfigured multicast. The difference is as follows.
• A preconfigured multicast group is configured with an IP address in the multicast
source table, the multicast VLAN ID of the network service provider (NSP), and
optionally a source IP address. The multicast stream is carried to the subscriber
in the multicast VLAN of the NSP.
• A nonconfigured multicast group is not configured in the multicast source table.
The multicast stream is carried in the service VLAN of the HSI service that is
supporting the IGMP signaling channel, or the service provider VLAN
configured for the IGMP signaling channel that is supporting the subscriber.
The LT supports a multicast source table of up to 4096 entries. The LT uses the GIP
and SIP from the IGMP join request, and optionally a VLAN ID to search the
multicast source table for a preconfigured multicast channel. If an entry is not found,
the request is processed as a nonconfigured multicast channel.
If the IGMP proxy on the LT is enabled for VLAN selection, the LT includes the
VLAN ID in the multicast source table lookup. The LT then uses the NSP VLAN ID
configured for the IGMP signaling that is supporting the subscriber, or the S-VLAN
ID of the HSI service supporting the IGMP signaling channel if the IGMP signaling
channel does not have a configured NSP VLAN ID. If the IGMP proxy on the LT is
not enabled for VLAN selection, the LT does not include a VLAN ID in the table
lookup.
Dynamic and static multicast streams

The 7342 ISAM FTTU supports both dynamic and static multicast routing to provide
reliable transport of multicast stream content between the network and CPE. The
type of multicast stream is provisioned by setting a command parameter to either
dynamic or static. The parameter setting is stored in the multicast source table as an
entry with other multicast configuration data.
Note 1 — See the “ENT-PONMCSRC” command in the
using TL1 and CLI for LT provisioning information.
Note 2 — See the SHub Multicast Filtering Database Configuration
command and the SHub Multicast Filtering Port List Configuration
Command in the 7342 ISAM FTTU CLI Commands Guide for NT
provisioning information.

Dynamic multicast stream
In the 7342 ISAM FTTU, a dynamic multicast stream is provisioned in the multicast
source table and is activated or deactivated using IGMP signaling. The IGMP
signaling is used to add or remove an entry in the multicast forwarding databases
supported at the NT, LT, and ONT.
Static multicast stream
A static multicast stream is provisioned in the multicast source table, but is not
activated using IGMP signaling. When a provisioned static multicast stream is found
during system startup, the stream is immediately activated by adding a (VID, GIP)
entry to the multicast forwarding databases supported at the NT, LT, and ONT. A
static multicast stream is forwarded to all ONT UNI ports.
Static multicast streams are usually very low bit rate streams that are carrying
background system information, such as router table and network time updates. A
maximum of eight static multicast entries are supported. Static multicast streams can
be associated with a PON to ensure availability of bandwidth.
Note — Static multicast channels support RIPv2 on both the NT and

the LT.
Forwarding in the data plane

The NT and LT forward dynamic multicast streams in the data plane using
(VID, GIP, *).
The ONT forwards dynamic multicast streams in the data plane based on the value
of LT-to-ONT signaling.
• If LT-to-ONT signaling is enabled, the ONT uses (VID, GIP, *).
• If LT-to-ONT signaling is disabled, the ONT uses (*, GIP, *).
The NT, LT, and ONT forward static multicast streams in the data plane using (VID,
GIP) only.
The control plane supports lookups in the multicast source table using (VID, GIP,
SIP), and (VID, GIP, *).
14.10 Join and leave messages
Subscribers send IGMP join and leave messages from a host on the UNI port. More
than one host can be on the same UNI port and can be simultaneously receiving the
same stream.

A UNI port can be provisioned for LT-to-ONT signaling.

• When LT-to-ONT signaling is enabled:
• The multicast forwarding database holds the (VID, GIP).
• Pre-view channels are supported.
• The ONT forwards the join and leave messages to the LT card for processing.
• The LT validates the join request, and performs an IGMP CAC check.
• When LT-to-ONT signaling is disabled:
• The multicast forwarding database holds (*, GIP) and (SIP, GIP).
• Pre-view channels are not supported.
• The ONT processes the join and leave messages.
• The ONT validates the join request, and performs an IGMP CAC check.
An IGMP CAC check validates a join request for the following:
• maximum bandwidth of IGMP signaling channel is not exceeded
• maximum stream count of IGMP signaling channel is not exceeded
• subscriber has access rights to the multicast stream
• message is valid
The following sections describe the processing of join and leave messages from
subscribers on the 7342 ISAM FTTU when the IGMP proxy on the LT is configured
in full proxy mode.
LT-to-ONT signaling mode enabled

LT-to-ONT signaling is typical for deployments where the 7342 ISAM FTTU
system is not integrated with a third-party IPTV middleware application. In such
cases, the 7342 ISAM FTTU system is required to control access to IP multicast
streams and to provide facilities to collect and report viewer statistics.
If LT-to-ONT signaling is enabled, the ONT forwards join and leave messages from
the subscriber to the LT card. When a join request is received from the ONT, the LT
card validates the join request, and performs an IGMP CAC check.
For validated join messages, if no other host on the UNI port is receiving the stream,
the LT card signals the ONT to forward the IP multicast stream from the GPON to
the UNI port.
When the LT card receives a leave request from the ONT, the LT card validates that
the message is valid. If no other host on the UNI port is receiving the stream, the LT
card signals the ONT to stop sending the stream to the UNI port.
LT-to-ONT signaling mode disabled (default)

If LT-to-ONT signaling is disabled, join and leave messages are processed by the
ONT. This mode is typical for deployments where the 7342 ISAM FTTU system is
integrated with a third-party IPTV middleware application, such as MSTV, and the
access control and viewer statistics provided by the 7342 ISAM FTTU system are
not required.
The following sections describe the processing of join and leave messages on the
ONT, when LT-to-ONT signaling is disabled.

Processing of join messages on the ONT

When the ONT receives a join message, the following events occur, as numbered in
Figure 14-9.
Figure 14-9 Processing of IGMP messages at the ONT
IGMP signaling
channel
IGMP snoop
GPON UNI
5
Multicast GEM port ID 1
Priority=0 GEM port ID Ethernet/VDSL port

4
6
Priority=7 GEM port ID
Multicast forwarding
ONT bridge database
Downstream
Upstream
Traffic flow
Data retrieval or updates
19253
1 The ONT forwards a copy of the request to the IGMP snoop facility.
2 The IGMP snoop facility determines that the maximum number of IP multicast
streams allowed on the UNI port is not exceeded.
3 The ONT snoop facility adds the MAC multicast address (first 23 bits of the IP
multicast address) to its forwarding database and associates the MAC multicast
address with the UNI port.
4 The ONT forwards the original join message to one of the eight GEM port IDs
associated with the UNI port based on p-bit. The join message is carried
upstream to the LT card.
5 When the IP multicast stream is available on the GPON, the ONT validates the
destination IP multicast address in the multicast frames. Non-validated frames
are dropped; validated frames are forwarded from the GPON to the UNI port of
the subscriber.
6 The LT card sends periodic queries to the subscriber to audit the stream usage
using the multicast GEM port ID.
When the original join message is forwarded upstream from the ONT, the message
is carried across the GPON using the subscriber GEM port ID and is terminated at
the GPON-side router interface of the IGMP proxy on the LT card. If the requested
IP multicast stream is already on the GPON, no further action is required.

If the requested IP multicast stream is not on the GPON, the LT card processes the
join request (see “Processing of join messages on the LT card”).
Processing of leave messages on the ONT

When the ONT receives a request from a subscriber to leave an IP multicast stream,
the ONT IGMP snoop facility snoops the message and stops forwarding the stream
from the multicast GEM port ID to the subscriber if no other host on the UNI port is
receiving the stream. If the ONT supports more than one subscriber, the ONT stops
forwarding the IP multicast stream only if there is no other subscriber using the
stream.
The IGMP proxy on the LT card determines if other subscribers are interested in the
IP multicast stream. If no other interested subscribers are found, the IGMP proxy on
the LT card stops forwarding the IP multicast stream to the GPON, sends a “last”
leave message to the NT card to stop the delivery of the IP multicast stream, and
removes it from its multicast forwarding database.
The IGMP proxy at the NT determines if other LT cards require the IP multicast
stream. If no other LT card is found, the IGMP proxy at the NT sends a “last” leave
message to the network to stop the delivery of the IP multicast stream, and removes
the stream from its multicast forwarding database.
Processing of join messages on the LT card

When the LT card receives a join request, the following events occur, as numbered
in Figure 14-10.

Figure 14-10 Processing of join messages on the LT card
Multicast source
table
IGMP proxy
GigE 4 GPON
A VLAN ID Multicast GEM port ID

5
Priority=0 GEM port ID
Multicast forwarding Priority=7 GEM port ID

1
database
LT bridge
Downstream
A For preconfigured: Upstream
- multicast VLAN ID
For nonconfigured:
- NSP VLAN ID of IGMP signaling channel, or
- S-VLAN ID of HSI service
Traffic flow
Data retrieval or updates
19254
1 The LT card extracts the join message from the traffic flow and forwards it to
IGMP proxy.
2 The IGMP proxy performs a lookup in the multicast source table in one of three
ways.
• If IGMP proxy is disabled for VLAN selection, lookup is performed using GIP and
SIP from the join.
• If IGMP proxy is enabled for VLAN selection and the IGMP signaling channel
supporting the subscriber has a configured NSP VLAN ID, lookup is performed
using the GIP and SIP from the join request, and the NSP VLAN ID from the IGMP
signaling channel.
• If IGMP proxy is enabled for VLAN selection and the IGMP signaling channel
supporting the subscriber does not have a configured NSP VLAN ID, lookup is
performed using the GIP and SIP from the join request, and S-VLAN ID of the HSI
service supporting the IGMP signaling channel.
3 If the lookup is successful, the join is processed as preconfigured multicast; if the
lookup is not successful, the join is processed as nonconfigured multicast. The
IGMP proxy adds the GIP and one of the following VLAN IDs to its forwarding
database and associates it with the multicast GEM port ID:
• for preconfigured multicast, multicast VLAN from the multicast source table
• for nonconfigured multicast, NSP VLAN ID of the IGMP signaling channel that is
supporting the subscriber, if the IGMP signaling channel has a configured NSP
VLAN
• for nonconfigured multicast, S-VLAN ID of the HSI service supporting the IGMP
signaling channel, if the IGMP signaling channel that is supporting the subscriber
does not have a configured NSP VLAN

4 If the request is a first join, the IGMP proxy sends a “first” join message to the
NT over one of the following VLANS:
VLAN
5 When the IP multicast stream arrives from the NT card over one of the following
VLANs, the LT forwards it to the GPON using the multicast GEM port ID:
VLAN
The following rules apply.

• The system drops IGMP report and leave messages that are received from the
network.
• The system drops non-requested multicast streams that are received from the
network.
• The system forwards preconfigured or nonconfigured multicast streams that are
requested by subscribers only to the UNI-side multicast GEM port ID.
• ONTs only support ASM when LT-to-ONT is disabled. When LT-to-ONT is
disabled, IP multicast addresses cannot overlap across network-side multicast
sourcing VLANs.
• For nonconfigured multicast, multiple copies of the multicast stream can
potentially be carried across the PON; for preconfigured multicast, only a single
copy is carried across the PON.
Processing limits
The maximum number of IGMP messages that are allowed within a one second
interval is configurable by UNI port. The IGMP message rate per second is also
affected by the collection of CDR records. Enabling CDR record generations lowers
IGMP message rates. CDR records are configurable system wide. When the message
rate exceeds the threshold value, the IGMP message processing is suspended for the
current and the next one-second time intervals.

The following threshold values are configurable by both GPON and UNI port:
• the maximum bandwidth that can be consumed
• the maximum number of streams that are allowed
Note — If required for vendor-specific applications, the multicast bit

rate can be set to zero for IGMP signaling channels, in which case the
LT will not monitor bandwidth consumption by the ONT UNI. The
PON multicast bandwidth monitoring will still be applicable.
When threshold values are exceeded, requests to join the IP multicast groups are
denied. Table 14-3 identifies the division of tasks between the LT card and the ONT
in tracking and enforcing these limits.
Table 14-3 Processing limits
Network element Item
LT tracks and limits The amount of bandwidth consumed across the GPON
The number of streams that are allowed to be transported
across the GPON
LT tracks The amount of bandwidth consumed across an ONT UNI port.

Note that the maximum multicast bit rate can be set to zero for
IGMP signaling channels, in which case the LT will not monitor
bandwidth consumption by the ONT UNI.
The number of streams that are being transported across each

UNI port
The number of hosts on each UNI port that are simultaneously

receiving the same stream
ONT tracks and limits The number of streams that are allowed to be transported
across each UNI port
The number of hosts on each port that can simultaneously be

receiving the same stream
Fast channel change

When the IGMP proxy on the LT card receives an IGMP leave message from a
subscriber, the IGMP proxy must determine whether it is safe to remove the
multicast stream that is being delivered to the subscriber. There may be other
equipment at the subscriber's premise using the stream.
A typical multicast channel change from subscriber equipment involves two IGMP
messages:
• an IGMP leave to leave the requested channel
• an IGMP join to join a different channel
The amount of latency between these two messages is in the order of 100-200
milliseconds and varies among vendor products.

If there is enough bandwidth to deliver the stream being left and the stream being
joined, then the IGMP proxy has more time to determine whether it is safe to stop
sending the stream being left by the subscriber.
If there is not enough bandwidth to deliver the stream being joined, then the IGMP
proxy must determine quickly if the stream being left can be immediately removed
or if there is another lower priority stream that can be removed to free up bandwidth
to deliver the stream being joined.
IGMP standard leave
Standard leave was introduced in IGMPv2. When the IGMP proxy receives an IGMP
leave message, the IGMP proxy immediately responds by sending the subscriber an
IGMP GSQ message, which is also called a last member query. If the subscriber does
not respond with an IGMP report message within the required time, the IGMP proxy
assumes that the stream is no longer required and stops sending the stream to the
subscriber. The required response time is a configured value, with a default value of
2 seconds (2 query attempts with a 1 second response time for each attempt).
IGMP fast leave
When a subscriber changes from one channel to another channel, the IGMP fast
leave function immediately causes the removal of a stream. This quick reaction
allows for the recovery of the bandwidth used by the old channel before the new
channel is delivered.
The IGMP fast leave is supported by both the P-OLT and the ONTs as follows.
• When there are no subscribers accessing the stream on the ONT UNI port, the
stream is removed by the ONT from the port.
• When there are no subscribers accessing the stream on the GPON, the stream is
removed by the LT card from the GPON.
14.11 Counters and alarms
The 7342 ISAM FTTU maintains the following counters and data for performance
monitoring and fault isolation purposes:
• counters per VLAN
• counters per multicast stream
• counters per subscriber
• counters per LT IGMP proxy module
• subscriber and channel activity
• on-demand alarms
• counters per PON for multicast GEM port

Counters per VLAN

Per-VLAN counters include:
• number of IGMPv3 membership reports of type IS_EX received for the VLAN
on the host port
• number of IGMPv3 membership reports of type TO_IN received for the VLAN
on the host port
• number of IGMPv3 membership reports of type TO_EX received for the VLAN
on the host port
• number of IGMPv3 membership reports of type ALLOW received for the VLAN
on the host port
• number of IGMPv3 membership reports of type BLOCK received for the VLAN
on the host port
• number of IGMPv2 leave messages received for the VLAN on the host port
• number of general queries transmitted for the VLAN on the network port when it
is acting as a querier
• number of IGMPv2 leave messages transmitted for the VLAN on the network
port
• number of erroneous IGMP packets dropped for the VLAN due to failure in
IGMP checksum calculation Or Maximum multicast entries are exhausted
• number of IGMP v1 packets dropped for the VLAN. It is assumed that there is no
IGMP v1 devices in the towards network or LT
• number of IGMP packets received for the VLAN with mismatch between the
version configured for the VLAN and the version of the IGMP packet received.
These packets are dropped
Counters per multicast stream

The per multicast stream counters include:
• peak number of subscribed IGMP channels that have members connected to the
source since the last statistics reset
• network time in seconds when the peak number of subscribed IGMP channels for
the source occurred. When this parameter is reset, the value is 0.
• current number of subscribed IGMP channels for the source
• number of unsuccessful join requests
• number of successful join requests
Counters per subscriber

The per-subscriber counters include:
• number of times that an IGMP join message failed to trigger a multicast
connection because the resultant bandwidth exceeded the maximum total bit rate
allowed for the ONT UNI port
• number of times that an IGMP join message failed to trigger a multicast
connection because the resultant bandwidth exceeded the maximum total bit rate
allowed on the PON

• number of times that the IP address: 1) is not a multicast address, 2) is a reserved

multicast address, or 3) is not in multicast source table, 4) is a static multicast
address, 5) violates a multicast uniqueness rule, or 6) is not a valid multicast
source IP
• unused bit rate for the multicast traffic (downstream) supported by this channel
• number of channels that the user (UNI side port) is currently receiving (or has
joined). It is incremented on each IGMP join and decremented on each IGMP
leave
• number of times that a join fails because the resultant number of simultaneous
streams was higher than the maximum allowed on the ONT UNI
• number of times that an IGMP join fails because the resultant number of groups
was higher than the maximum number of multicast groups allowed on the PON
• number of times that request to join a multicast channel has been attempted for
which the IGMP channel has no permission
• number of preview multicast groups that the IGMP channel is joined currently
• for each multicast source, number of times the IGMP channel has previewed the
source
• the number of GSSQs that have been transmitted on the ONT UNI
• the number of IGMPv3 reports with a wrong mode (group record type) that were
received on the ONT UNI
Counters per LT IGMP proxy module

The following counters per LT IGMP proxy module include:
• number of messages received from users, including IGMP messages and invalid
messages
• number of IGMP messages, which includes join and leave requests from users,
(both successful and unsuccessful)
• number of join requests from users, which includes successful and unsuccessful
attempts
• number of successful join requests from users which includes new joins (which
make a new connection) and re-joins (which already have a connection)
• number of unsuccessful new join requests from users. The failures could be due
to the following reasons: betrayed failure, lack of resource or invalid group
address.
• number of leave requests from users
• number of invalid messages from users. These messages could be invalid for the
following reasons: 1) invalid IGMP message type, 2) invalid IGMP message
CRC, 3) invalid IGMP message size, 4) non-IGMP frame received, 5) unexpected
IGMP Query (GSQ or GMQ) received, 6) MAC layer errors, or 7) IP layer errors
• number of connects due to successful new IGMP join requests from users
• number of disconnects to users. They can be due to 1) GSQ or GMQ timer expiry
or 2) the triggering of fast channel changes
• peak number of multicast branch connections performed per second since the
statistics were last cleared. This object is defined based on successful JOIN from
users.

• network time in seconds indicating when the peak number of connects performed
per second occurred. This object is defined based on successful JOIN from users.
When this parameter is reset, the value is all 0s.
• peak number of disconnects to users performed per second
• network time in seconds of when the peak number of disconnects to users
performed per second occurred. When this parameter is reset, the value is all 0s.
• peak number of messages received from users per second
• network time in seconds of when the peak number of messages received from
users per second occurred. When this parameter is reset, the value is all 0s.
• number of the connected groups
• network time in seconds of when the module-wide statistics were last reset. When
this parameter is reset, the value is current time
• number of GMQ requests from network
• number of GSQ requests from network
• number of the connected groups that are configured in the multicast source table
• number of the connected groups that are in reserve state, which means that they
have no member, but doesn't leave to avoid frequently joining and leaving
• the number of GSSQ requests from the NT
Subscriber and channel activity

The following subscriber and channel activity is available:
• List of channels for a particular subscriber (ONT UNI ports)
• List of subscribers (ONT UNI ports) for a particular channel
• List of entries in the multicast forwarding table
On-demand alarms
On-demand alarms include loss of traffic.
Counters per PON for multicast GEM port

Multicast GEM port counters are added to the OLT-side TC-layer and the ONT-side
TC-layer GEM-based counters. There are thirty-two 15 min counters provided to
form 8 hours of PM data. The counters for multicast GEM port include:
• number of blocks transmitted downstream over a 15 min interval for type
TXBLOCKS, supported by the OLT
• number of frames transmitted downstream over a 15 min interval for type
TXFRAGS, supported by the OLT
• number of blocks transmitted downstream over an 8 hr interval for type
TXBLOCKS, supported by the OLT
• number of frames transmitted downstream over an 8 hr interval for type
TXFRAGS, supported by the OLT
• number of blocks received downstream over a 15 min interval for type
RXBLOCKS, supported by the ONU
• number of frames received downstream over a 15 min interval for type
RXFRAGS, supported by the ONU

• number of lost fragments received downstream over a 15 min interval for type
LOSTFRAGS, supported by the ONU
• number of blocks received downstream over an 8 hr interval for type
RXBLOCKS, supported by the ONU
• number of frames received downstream over an 8 hr interval for type RXFRAGS,
supported by the ONU
• number of lost fragments received downstream over an 8 hr interval for type
LOSTFRAGS, supported by the ONU
14.12 Subscriber and video management
Tasks for the management of subscribers and video services include authentication,
authorization, and accounting. For these functions, the 7342 ISAM FTTU supports
middleware applications, such as Alcatel-Lucent FSD-ICE Open Media suite or
Microsoft TV2.
The 7342 ISAM FTTU system supports a package feature that allows each multicast
source to be associated to one or more multicast packages that are offered to the
subscribers. The subscriber can choose to subscribe to a package for a pre-view
session or for a full-view session. The package feature is typical for deployments
where operators have developed their own IPTV middleware application.
Terminology
Multicast source, multicast stream, and channel share the same IP multicast address
and are used in this section as follows:
• multicast source refers to a multicast group that a subscriber can join
• multicast stream refers to an IP data stream that is sent out into the network and
is organized into multicast packages
• channel refers to the means by which a subscriber accesses a multicast stream in
a multicast package
Figure 14-11 illustrates the relationship among the terms multicast source, multicast
stream, and channel.

Figure 14-11 Multicast source, multicast stream, and channel
Video server
Multicast
source
Package 1
Multicast stream
Package 2
Package n
Channel
19140
Package
A package is a group of multicast streams that share a common access permission.
The service provider can deliver different levels of services to subscribers by
grouping multicast streams into one or more multicast packages. Up to 1024
multicast packages are supported. The service provider can assign names to the
available package numbers. Figure 14-12 shows an example of a package with
sample subscribers.
Figure 14-12 Package example with sample subscribers
BBC
NBC Subscriber 1 Basic
Basic
Weather channel
...
Subscriber 2 Basic News
CNN
BBC World News
... Subscriber 3 Basic News Sports
Eurosport
Sky sports Sports Subscriber 4 News Sports
...
19131
Access control
The steps for creating multicast packages and providing subscriber access to them
are shown in Figure 14-13.

Figure 14-13 Steps for creating multicast packages and providing access to subscribers
Multicast sources Packages IGMP channel
Multicast
2 source 1 5
Configure data IGMP
Number and Configure
multicast name packages IGMP channel channel ID
sources Signaling
requirement
Package IGMP
data channel
data
IP multicast address 4 Pre-view 7
Pre-view limits data Multicast IGMP IGMP
Set pre-view source package channel Enable LT-to-ONT
limits table table table signaling
Full-view packages
Pre-view packages
3 Package 6
IP multicast address bitmap IGMP
Categorize Package Package Provide access channel ID
multicast sources number number rights to Subscriptions
into packages subscribers
19138
The implementation steps are as follows:

1 Number and name the multicast packages.
2 Configure the multicast sources.
3 Categorize the multicast sources into multicast packages.
4 Set pre-view limits for multicast stream.
5 Configure an IGMP channel for a subscriber and associate the IGMP channel
with the subscriber HSI service.
6 Provide access rights to the subscriber by indicating the multicast packages the
subscriber is entitled to request (according to subscriptions).
7 Enable or disable LT-to-ONT signaling.
Note — The following steps can be done concurrently:
• steps 2, 3, and 4
• steps 5, 6, and 7
See the Multicast IGMP service configuration section of the
using TL1 and CLI.

Access modes
For a particular multicast package, the following access modes are offered:
• Full-view: The subscriber can join the multicast stream at any time with unlimited
view duration.
• Pre-view: The subscriber can join the multicast stream with a limited pre-view
frequency and view duration.
• No-view: The subscriber cannot join the multicast stream, neither in pre-view nor
in full-view mode.
The access mode applies to all hosts on the same service.

With pre-view rights for a multicast group, the subscriber can subsequently access
the channel up to some predefined period. The frequency of subsequent pre-views
and the duration between consecutive pre-views are limited per multicast stream to
avoid service theft. All hosts on the same service share the same pre-view counts, so
that the pre-view expires at the same time for all of them.
If the LT-to-ONT signaling is enabled, the LT notifies the ONT to stop forwarding
the multicast stream from the PON to the subscriber when the pre-view time expires.
Control Data Records

The 7342 ISAM FTTU supports Call Data Records (CDRs). CDRs are audit trail
records that reflect the viewing behavior of subscribers. CDRs support the operator
with an overview of the multicast join and leave activities on the UNI. They can be
used by an operator for marketing or monitoring purposes as follows:
• For marketing: allows the operator to collect statistics regarding the popularity of
a multicast stream
• For monitoring: allows the operator to ensure that subscribers are successfully
accessing the channels within their subscription range
The generation of CDR records is configurable at the system level.When the operator
explicitly enables this feature, the NE generates autonomous CDR records. A CDR
record can be generated for one or more of the following events:
• a join of a pre-view session
• a join and leave of a full-view session
• a join outside the access rights of the subscriber
• a join of a pre-view session when the maximum number threshold has been
exceeded
• a join of a pre-view session during the black-out period
• an interim viewing of a full-view or pre-view session
• a join that is rejected because the maximum multicast bandwidth allowed on the
UNI or PON is exceeded, or the maximum number of streams allowed on the
PON or UNI is exceeded

The generated CDR records are temporarily stored in volatile memory buffers on the
LT cards. At predefined time intervals, the NT retrieves these memory buffers and
stores the records in one of two ways for later retrieval by the operator:
• local file storage: the NT stores the records as a local file on the
Alcatel-Lucent-approved flash storage device; the file can be retrieved using
TFTP
• remote logging storage: the NT forwards the CDR records to the syslog system
for local logging to the syslog RAM disk or remote logging to a network server
A CDR record contains the following information:

• a sequence number to uniquely identify a CDR record by LT card
• the multicast stream being subscribed
• the multicast source sending the multicast stream
• the multicast VLAN that is carrying the multicast stream
• source address of the subscriber
• the service interface
• the multicast mode
• the reason for which the CDR record was generated
• the type of CDR record that has been generated
• the session number
• the view duration
• the date and time of CDR record
Wholesale video through residential-bridging

Table 14-4 describes the steps required to provide wholesale video through
residential-bridging.
Table 14-4 Wholesale video through residential-bridging
Data configuration Description

requirement
SHub Create a residential-bridge service VLAN on the SHub and enable

downstream multicast flooding over the S-VLAN (ENT-LANXVLAN).
Associate the service VLAN to a network-side port and one or more

LT-side ports (SET-LANXVLANPORT).
LT Create a service VLAN on the PON with the following characteristics

(ENT-PONVLAN):
• C-VLAN learning mode
• Stacked VLAN tagging mode
• enabling of downstream multicast traffic in the C-VLAN
Create a C-VLAN based static bridge port that links the C-VLAN to the
service VLAN on the PON (ENT-PONCFDBSTATIC).
(1 of 2)

Data configuration Description

requirement
ONT Create the services with an upstream tagging mode of VLAN translation
using ENT-SERVICE-HSI, and associate the UNI-side VLAN (C-VLAN) with
the same network-side VLAN (S-VLAN).
Create an IGMP signaling channel and associate the channel with one of
the services.
(2 of 2)
14.13 IGMP protocol handling with no IGMP signaling channel
There are two models when it comes to IGMP protocol handling and IGMP signaling
channels:
• the node processes IGMP messages corresponding to IPTV service for video
replication using IGMP signaling channels; this model requires IGMP signaling
channel provisioning
• the node transparently forwards IGMP messages on the signaling VLAN with no
IGMP signaling channels; this model does not require IGMP signaling channel
provisioning
The 7342 ISAM FTTU supports both models and allows them to operate at the same
time.
The 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1
and CLI describes configuration for both models.

15.1 Overview 15-2
15.2 Forwarding architecture 15-2
15.3 Layer 2 forwarding rules on the NT card 15-6
15.4 Layer 2 forwarding modes on the LT card 15-9
15.5 Duplicate MAC address and C-VLAN handling 15-17
15.6 Residential bridge mode configuration requirements 15-18
15.7 C-VLAN learning mode configuration requirements 15-20
15.8 Cross-connect mode configuration requirements 15-21
15.9 Transparent protocol forwarding 15-22
15.10 MAC filters 15-22
15.11 Pause frames 15-22
15.12 Layer 2 forwarding for EVC and subscriber scalability

implementations 15-23

15.1 Overview
This chapter describes the layer 2 forwarding function used by the

7342 ISAM FTTU. The 7342 ISAM FTTU uses the layer 2 forwarding protocol to
create a secure path for data and video traffic across the IP network.
The 7342 ISAM FTTU uses the NT and LT cards to provide the layer 2 forwarding
function. The NT and LT cards are two independent layer 2 systems. They both learn
and age independently on MAC addresses. Where C-VLAN forwarding is used, the
LT card also learns and ages on C-VLAN.
Note — The maximum Ethernet frame size supported at the OLT and
ONT interface is 2008 bytes. However, the GLT2-A does not support
2008 byte frames and will drop packets larger than 1800 bytes.
Typically, a VLAN is created for residential bridge (RB) or transparent

cross-connect (CC) mode and assigned to ports on the NT SHub and to bridge ports
on the LT. The forwarding mode and the tagging mode are defined on the LT card.
15.2 Forwarding architecture
The combination of NT, LT, and ONT serve as an end-to-end chain for both QoS and
forwarding functionalities. Also, to understand VLAN tagging behavior from the
subscriber interface at the ONU toward the EMAN NT interfaces, the individual
responsibilities of the respective building blocks must be understood to configure
and emulate customer requirements.
From the software perspective, a set of functional blocks is built on the platform with
“tiers” of software applications, including communication and management
protocols, core service and management applications, and transport applications.
Each of these tiers provides a different layer of functionality, either in a very generic
way, or in an application-specific way. The most application-specific tier, transport
applications, is composed of various subsystems that manage IP-centric connection
establishment and transport, GPON-specific access equipment control and user
service configuration. This tier, which includes 802.1x security management, VLAN
bridge management, QoS management, DHCP relay, ARP proxy, and IGMP
management, is the core of the forwarding implementation.
This section describes the layer 2 forwarding functionalities as implemented in the
respective building blocks.
LT architecture
The principal components of an LT card include the following:
• interfaces to the GPON through the GPON MAC interworking function
implementing GPON PHY and TC layers per individual GPON interface
• interfaces to the NT cards through the LT FPGA backplane interface. These
packet-based interfaces provide point-to-point transmission to and from the NT
cards for network access.

• layer 2 switching and traffic management, which performs VLAN bridging and
cross-connect functions, VLAN processing, destination selection in upstream and
downstream, multicast replication to the PON interfaces, and other forwarding
and QoS related features. As well as the VLAN aware switching capabilities, the
switch is also used for snooping the received packets to filter for control packets,
such as 802.1x, DHCP, IGMP, and ARP.
• an on-board controller (OBC), which is the master for the bridging functionality
supported by 7342 ISAM FTTU. The LT OBC maintains information about the
switch ports and GEM port IDs, performs the MAC learning, and programs the
traffic manager switch with the new entries. The switch will then use the
programmed entries to forward the packets upstream and downstream. As well as
being a master for secure MAC learning, the LT OBC also provides access
features like 802.1x authentication for the ONT LAN ports, DHCP relay with
Option 82, IGMP proxy for dynamic multicast, and proxy ARP towards the
network.
Ultimately, the OBC performs card control and management functions. The LT
OBC receives management information through the OAM VLAN from the NT
cards or the ONT. This information includes alarm, state change, and
configuration events triggered by the EMS or from events that occur on the ONTs
supported by the LT card. The traffic manager and the LT OBC exchange this
information as Ethernet frames where the OBC translates the control and
management info from and into OMCI messages that are sent from and to the
ONT.
Figure 15-1 shows the functional blocks on a GLT4-A as an example LT card.
Figure 15-1 GLT4-A functional blocks
On-board controller Memory, power, mgmt,

(OBC) clock tree, ...
XAUI to/ PON 1

from NT-A GPON MAC IWF
PON 2
Backplane Traffic
I/f FPGA manager
PON 3
XAUI to/ GPON MAC IWF
from NT-B
PON 4
Ethernet frames GEM frames

20714
The traffic manager is the core of the forwarding operation within the OLT, and is
the focus for discussing the layer 2 LT functionalities.

NT architecture
The SHub components of the NT comprise a Broadcom (BCM) chipset that
implements an Ethernet switch with the following port allocations:
• ports terminate on the NT front panel to provide upstream interfaces to the
EMAN
• ports used in stacking mode between redundant NTs for load sharing and
communications associated with the forwarding database
• 18 ports that interface to the LTs, one for each LT
• connections on the switch to interconnect the two BCM devices
• a link to provide a communication channel between the SHub and the main OBC
on the NT
• a link to provide connectivity to the ACU card slot
Figure 15-2 shows the components of the EHNT-A as an example of an NT card.
Figure 15-2 EXNT-A functional components
On-board controller Memory, power, mgmt,

(OBC) BITS, input, ...
EMAN sHub Backplane

interfaces interfaces
1-GE XAUI 1 to LT-1

200 Gb Ethernet switch
BCM 56800
20 * 10 GE ports
1-GE XAUI 1 to LT-9
to peer
to peer NT
NT (unused)
10-GE
XAUI 1 to LT-10
10-GE 200 Gb Ethernet switch
BCM 56800
20 * 10 GE ports
XAUI 1 to LT-14
to
ACI
(unused)
20715
Note that the SHub has an associated OBC dedicated to controlling the IP functions,
which is not indicated in Figure 15-2. The SHub switch is managed separately from
the NT card and has its own management information base (MIB). The OBC on the
primary NT card controls the functioning of the entire OLT shelf. The NT OBC has
a fast Ethernet (FE) link that connects to the peer OBC on the layer 2 SHub switch
to synchronize the databases. Also, the NT OBC has its own MIB that can be
accessed directly using SNMP or indirectly using CLI. The MIB controls the
applications that are related to the P-OLT shelf. The NT OBC determines which
layer 2 switch is active or functions as the master, based on the link failure indication
from the layer 2 switch or other board fault conditions.

In a redundant NT configuration, the SHub hardware and software behaves as a

single switch. In load-sharing mode where two NTs are active and operational, one
SHub OBC will be designated the "master", and will control the operation of both
sides of the switch. Ultimately, the determination of which NT is "active" or
"master" will be made by the main NT OBC, based on link failure indications from
the SHub or other board fault conditions.
ONT functionality and bridge port modeling

The ONT transparently passes all data traffic between a subscriber ONT UNI port
and the subscriber GEM port IDs. The association between a subscriber ONT UNI
port and the subscriber GEM port IDs functions as a hard-wired, point-to-point,
switch connection. The ONT IWF provides tagging and prioritization facilities in
both the upstream and downstream directions, as well as IGMP snoop facilities, and
is controlled through provisioning.
Upstream traffic from a subscriber UNI port is switched to a GEM port ID, based on
classification criteria such as VLAN ID, 802.1p value, and Ethertype. Downstream
traffic between subscriber GEM port IDs and the associated subscriber UNI port is
switched directly to the associated subscriber UNI port, as shown in Figure 15-3.
Figure 15-3 ONT building blocks
On-board controller Power, mgmt,

(OBC) memory, ...
IWF + GPON POTS UNI

MAC
POTS client
Ethernet/VDSL UNI
GEM Port ID
ISI 1
GEM Port ID
ISI 2
GEM Port ID PON
GEM Port ID E1 UNI
CES
GEM Port ID
GEM frames Ethernet frames

20716
No MAC learning is performed at the ONT UNI itself. To provide secure MAC
learning functionality (for example, MAC anti-spoofing), the ONT UNI and its
related services are modeled as a bridge port, part of the LT switch, as shown in
Figure 15-4. A bridge port is associated with one or more GEM port IDs. This
association is made from the priority queue profiles defined on each service that is
created and associated with the UNI.

Figure 15-4 ONT UNI to bridge port mapping
LT PON ONT
IWF + GPON IWF + GPON POTS UNI

MAC MAC
Bridgeport = = UNI
POTS client
BP L/F GPON
MAC
Ethernet/VDSL UNI
GEM Port ID
HSI 1
GEM Port ID
XAUI to NT_A
HSI 2
Bridge GEM Port ID PON
XAUI to NT_B GEM Port ID E1 UNI
CES
GEM Port ID
GEM frames Ethernet frames

20873
The LT implements the RB, CC, and the C-VLAN learning forwarding models per
VLAN, while the ONT implements GEM port IDs to LAN port cross-connects. With
the suggested bridge port modeling, the forwarding operations are centralized at the
OLT. In this context, the ONT UNIs or bridge ports can be considered as an
extension of the OLT backplane.
Therefore, the further discussion of forwarding will focus on OLT only. Note that for
VLAN tagging operations, such as the translation of a VLAN tag from the
subscriber, the ONT still plays an important role.
15.3 Layer 2 forwarding rules on the NT card
The NT card provides the following layer 2 forwarding features:

• classifying interfaces
• switching flood traffic
• learning MAC addresses
Classifying interfaces
For layer 2 forwarding, the 7342 ISAM FTTU classifies the interfaces into the
following categories:
• network interface
• access interface
• control interface
Table 15-1 describes the layer 2 forwarding rules for the unicast frames between the
interfaces.

Table 15-1 Unicast frame forwarding rules
Interface Layer 2 forwarding rules
Network interface Frames received on a network interface can be forwarded to another

network interface and the control interface.
Access interface Frames received on an access interface can be forwarded to the

network interface.
Control interface Frames received on the control interface can be forwarded to the
network and access interface.
These rules can be forced or further restricted by VLAN port configuration. For
example, only one access interface can belong to a VLAN in CC mode.
Switching flood traffic

Flooding in the Ethernet switch is limited to 500 packets/s per type per port for
security. The types of flooding are:
• broadcast
• unknown destination
• unknown multicast
The forwarding of broadcast frames or frames with unknown (unicast or multicast)
destination MAC address uses the rule to flood to all allowed interfaces.
Learning MAC addresses

Duplicate MAC addresses cannot be learned by an NT card. The learning of MAC
addresses depends on the type of NT interface (see Classifying interfaces); different
priority information is provided to the learning interfaces. Table 15-2 describes the
priority information about the learning interfaces.
Table 15-2 Rules for learning MAC addresses
Learning interface Priority
Control interface The control interface has priority over a network or an access
interface regardless of the order of learning.
Network interface The network interface has priority over an access interface
regardless of the order of learning.
Two network interfaces If a MAC address is received over two network interfaces, the last
network interface takes priority and MAC movement is performed.
Two access interfaces If a MAC address is received over two access interfaces, the first
access interface takes priority and MAC movement is not performed.

Limiting learned MAC addresses or C-VLAN IDs at the LT

The system has configurable and nonconfigurable limits on the number of learned
MAC addresses or C-VLANs in the LT VLAN forwarding database. See Table 8-5
for the MAC address learning limits of an LT card.
• The operator can limit the number of learned MAC addresses or C-VLAN IDs on
a per bridge port basis when configuring an ONT UNI port.
• The operator can configure a limit on the number of learned MAC addresses or
C-VLAN IDs on a per-service basis when configuring an HSI service or service
flow, which the system implements on a per (bridge port, S-VLAN) basis.
• The system derives an internal limit on the number of learned MAC addresses or
C-VLAN IDs for a (bridge port, S-VLAN) association based on the limits set for
the bridge port and the supported services that share the same S-VLAN as
follows.
• If the supported service or services have a limit of zero, limiting is enforced at the
bridge port level.
• If the supported service or services have a non-zero limit, the (bridgeport, S-VLAN)
association limit is internally set to the sum of the per-service limits, where the sum
of the per-service limits cannot exceed the bridge port limit.
If a frame is accepted from a bridge port into an RB VLAN, the LT learns the source
MAC address of the frame if the following conditions are met:
• The source MAC address is not already present in the dynamic forwarding
database.
• The source MAC address is not a multicast or broadcast address.
• The total number of MAC addresses for that bridge port does not exceed the limit
configured for the bridge port.
• The total number of MAC addresses for the (BridgePort, VLAN) association does
not exceed the internally derived limit for the (bridge port, VLAN) combination.
• The total number of dynamic forwarding entries on the LT card does not exceed
the system-set limit for the LT card.
• The total number of dynamic forwarding entries in the S-VLAN does not exceed
the system-set limit for a VLAN.
Table 15-3 is a summary of the learned C-VLAN ID limits that the system enforces.
Table 15-3 Summary of learned C-VLAN ID limits
C-VLAN ID address limit Type of limit Values
Per bridge port Configured Range is 0 to 2048.
(1 of 2)

C-VLAN ID address limit Type of limit Values
Per (bridge port, S-VLAN) System-derived as follows: Range is 0 to 2048.

• Set to bridge port limit if
one or more limits for
supported services in the
same S-VLAN are zero
• Set to sum of limits for
supported services in the
same S-VLAN if all
per-service limits are
non-zero
Per LT card System set 512 with a combined total of MAC

addresses and C-VLAN IDs not
exceeding 4096
Per VLAN System set 16 384
(2 of 2)
If a frame is accepted from a bridge port into an C-VLAN learning VLAN, the LT
learns the C-VLAN ID of the frame if the following conditions are met:
• The C-VLAN ID is not already present in the dynamic forwarding database.
• The total number of C-VLAN IDs for that bridge port does not exceed the limit
set for the bridge port.
• The total number of C-VLAN IDs for the (BridgePort, S-VLAN) association does
not exceed the internally derived limit for the (bridge port, S-VLAN)
combination.
• The total number of dynamic forwarding entries on the LT card does not exceed
the system-set limit for the LT card.
• The total number of dynamic C-VLAN ID forwarding entries on the LT card does
not exceed the C-VLAN limit for the LT card.
• The total number of dynamic forwarding entries in the S-VLAN does not exceed
the system limit for a VLAN.
If the source MAC address or C-VLAN from a bridge port is already associated with
the same bridge port in the VLAN forwarding database, the time stamp of the VLAN
forwarding database entry is refreshed.
15.4 Layer 2 forwarding modes on the LT card
As part of the outer S-VLAN (that is, PONVLAN) configuration, the appropriate
forwarding mode should be specified for the respective services, flows, or portals
linked to this S-VLAN. In this context, the system supports the following three
forwarding modes:
• RB mode
• transparent CC mode
• C-VLAN learning mode, which can be configured as a protocol-aware CC mode
or S/C-VLAN CC
The following sections describe these forwarding modes. See section 21.3 in
chapter 21 “VLANs and VPNs” for more information about these forwarding
modes.

Residential bridge mode

RB mode is a forwarding model that is suitable for residential subscribers. Typically,
RB mode is used for high-speed Internet access (HSI), voice over IP (VoIP), or other
applications in a multi-service (provider) scenario, where multiple network service
providers (NSPs) are connected to the 7342 ISAM FTTU using a VLAN.
Several subscriber bridge ports could be members of an RB VLAN. Multiple
services could be created per subscriber bridge port. The bridge ports could belong
to the same or different ONTs. From this, the following two models could be
considered.
• VLAN per service model: The S-VLAN is used on multiple bridge ports that use
the same service. Each bridge port will have a service created that has GEM ports
mapping to this S-VLAN.
• VLAN per subscriber model: Every ONT has a unique RB VLAN. This means
that all the user services and GEM ports will be attached to the same VLAN,
including the bridge port(s) for its ONT.
See section 21.4 in chapter 21 “VLANs and VPNs” for more information about the
VLAN per service and the VLAN per subscriber models.
In the multiple NSP scenario, the subscriber ports are connected to the VLAN of their
corresponding NSP. Multiple subscriber ports can be associated with a single
VLAN. When a subscriber generates a frame or a frame is received from the
upstream NT card, the P-OLT performs a MAC address lookup in the forwarding
table identified by the VLAN. Each VLAN has a forwarding table in the P-OLT.
RB VLANs support the DHCP relay function with Option 82.
Features
RB mode has the following features compared to standard bridging:
• Network and user ports
RB mode makes a distinction between network ports and subscriber ports, in
contrast with standard bridging where all ports are treated equally. User-to-user
communication is disabled by default on all VLANs, which ensures that upstream
traffic from subscribers is sent toward the NSP except for traffic destined for the
P-OLT. However, user-to-user communication can be enabled on a per-VLAN
basis. See section 21.10 for more information about user-to-user communication.
• Prevention of broadcast problems
To prevent broadcast storms, the amount of broadcast traffic on each port can be
limited.
When standard bridging is used, a broadcast (ARP, PPPoE, DHCP) or multicast
frame will be sent to all ports in a particular VLAN. In RB mode, broadcast from
the subscriber only goes to the network. Broadcast from the network only goes to
the LT. The LT responds to ARP requests, if the PON VLAN is enabled for
DHCP relay.
Also, broadcast as a consequence of flooding, which happens with standard
bridging when the MAC DA is unknown or with multicast, is avoided in RB
mode.

• MAC address learning

In RB mode, the MAC addresses are learned in a different way than with standard
bridging. A protection is built in to prevent the use of one specific MAC address
by multiple ports in one particular VLAN. This prevents a MAC address learned
on one port from receiving service on another port and prevents DoS and spoofing
attacks. This protection is disabled if MAC address movement is enabled; see
section 15.5 for more information about MAC address movement.
It is important to note that the VLAN must be unique between the P-OLT and the
NSP IP router in the Ethernet network to support RB mode. If the network
configuration uses a single VLAN for two P-OLTs and an NSP router, there could
be direct subscriber-to-subscriber communication and the consequence of broadcast
and flooding.
Forwarding table lookup key

The traffic manager on the LT card maintains a bridge lookup table for layer 2
forwarding, with different lookup keys for each direction:
• the upstream lookup key is used to check whether a source MAC address and
p-bit combination is already learned on the bridge port. It is also used for adding
the S-VLAN tag for packets received on the GEM port ID.
• The downstream key is used to determine the GEM port ID used in the
downstream direction for an S-VLAN ID, p-bit, and DST MAC address
combination.
Secure MAC learning

Incoming packets without entry in the forwarding table undergo a “secure MAC
learning” process at the LT card. The learning bridge performs this source learning
on the level of the bridge. Alternatively, the system also supports statically
configured forwarding entries using the ENT-PONFDBSTATIC command.
In the learning process, RB mode makes a distinction between network ports and
user (or access) ports, in contrast with standard bridging where all ports are treated
equally. With residential bridging, frames received from a user will always be sent
toward the network and never to another user. There is no learning of network side
MAC addresses on the GLT.
The various steps involved in this process are as follows:
1 When a packet arrives from the PON into the traffic manager on the LT card, the
traffic manager checks the upstream learning table that it maintains, to see if this
combination of GEM port ID and MAC address exists. If an entry does not exist,
the packet is sent to the OBC.

2 The LT OBC is the master for the learning process. When a frame is received on
a GEM port ID, the LT OBC determines the bridge port that corresponds to the
GEM port ID. The LT learns this MAC address with the following restrictions:
• If the number of MAC addresses already learned has reached the maximum number
(see “Limiting learned MAC addresses or C-VLAN IDs at the LT”), the MAC
address is not learned and the frame is dropped. If the user sends more than 300
packets with the unlearned MAC address in 15 s., the OLT will shut down the user
port for 15 s.
• If the MAC address is already learned on another bridge port of the same VLAN,
the new MAC address is not learned and the frame is dropped (see Duplicate MAC
address handling on the NT and the LT).
• Well-known MAC addresses, such as multicast MAC addresses and MAC
addresses allocated for IEEE protocols, will not be learned.
• Only independent VLAN learning is supported; that is, a MAC address is unique
within a VLAN, but not across VLANs and bridge ports. If a bridge port is
connected to two VLANs, the MAC address is learned twice.
• If 802.1x is enabled on the UNI port, the OBC learns the source MAC address only
if the port is authenticated.
• The 7342 ISAM FTTU also supports MAC and IP anti-spoofing mechanism per
bridge port. The static MAC address provisioned on the bridge port will be sent to
the ONT via OMCI, which will install the appropriate anti-spoofing filters.
3 When previous steps are completed successfully the traffic manager will have its
table populated. Any upstream data packet, that is, not a control packet, with the
same source MAC address on the same bridge port is forwarded through the LT
without processor intervention. The traffic manager will consult the lookup table
with the upstream lookup key to find the corresponding S-VLAN ID and perform
the appropriate tag operation.
Control frame forwarding

Control frames like 802.1x (and EAL3), DHCP, ARP, L2CP and IGMP are
processed by their respective modules in the OBC. Therefore, arriving traffic will be
snooped by the traffic manager module and forwarded to the OBC for the appropriate
processing.
Control packets with unknown MAC addresses will be sent to the OBC as part of the
learning process. It is then the responsibility of the OBC to check if the received
frame is a control frame.
PPPoE traffic will also be sent to the OBC to insert the PPPoE relay agent
information.
VLAN transparent cross-connect mode

The VLAN transparent CC mode is useful for business customers. This approach
basically consists in building a connection-oriented model across the connectionless
Ethernet access network by means of VLANs.
Multiple (transparent) S-VLAN CC services can be created per bridge port; only one
bridge port is contained in an S-VLAN. A subscriber is identified across the entire
network by a VLAN ID in VLAN CC mode. The S-VLAN identifying the CC VLAN
is used for the forwarding at the NT, LT, and bridge port level; this means that the
S-VLAN should be unused and cannot be reused within the OLT.

The limitation of the VLAN in CC mode is scalability. A particular VLAN ID can

be configured only once on any of the subscriber ports in the P-OLT. The same
VLAN ID can configured only once over all P-OLTs in the complete Ethernet
network to which the P-OLT is connected. If VLAN stacking is not used, the VLAN
cross-connections should only be used in small networks where the P-OLT is directly
connected to the IP router of an NSP, or for business customers.
Note — VLAN stacking introduces an additional VLAN layer. In
VLAN stacking, an outer layer can bundle a number of inner VLANs.
The outer VLAN is the S-VLAN. The inner VLAN is the C-VLAN.
VLAN stacking allows the user to use the same ID for multiple
VLANs. See chapter 21 for more information about VLAN stacking.
A VLAN in CC mode shares two common features with a VLAN in RB mode: there
will be no subscriber-to-subscriber communication and no broadcast storms.
Supported models
There are several VLAN CC models supported:
• basic VLAN CC: C-VLAN CC
• VLAN stacking for business users: S-VLAN CC
For information about VLANs and VLAN stacking, see chapter 21.
Forwarding table lookup

In the upstream direction, the incoming GEM port ID without the MAC address is
sufficient to identify the outgoing upstream port and the VLAN tag. In the
downstream direction, the S-VLAN ID only (that is, without MAC DA) identifies the
outgoing user port and GEM port ID. For tag handling of packets, the handling is the
same as RB.
It is verified at configuration time that only one bridge port belongs to the VLAN.
In CC mode, the LT card forwards all downstream traffic within the VLAN to the
bridge port, including unicast frames, broadcast frames, and multicast frames.
Control frame forwarding

With transparent CC support, the IEEE 802.1ad provider bridge requires the
transport of customer layer 2 control protocol (L2CP) frames through the network.
Typically the frames will be tunneled between one customer network and a second
customer network. Therefore, the system supports the configuration of provider
bridge mode on a per-VLAN basis.
When provider bridge mode is enabled, it is possible to configure, on a per VLAN
basis and for each protocol, whether that protocol should be tunneled or discarded.
Broadcast handling
As a truly transparent system, both the downstream and upstream broadcast traffic
does not undergo special treatment and is broadcast within the user CC VLAN.

C-VLAN learning mode

Some forwarding models require behavior where the downstream lookup on the LT
involves both the S-VLAN and C-VLAN ID, something which is not supported by
the RB and CC mode. In addition, in the CC mode, the S-VLAN must be unique for
each subscriber UNI, and as such the S-VLAN cannot be shared over multiple users.
The proposed model, called C-VLAN learning, is a forwarding model that is suitable
for both residential and business subscribers. It can be configured as a
protocol-aware CC VLAN or a transparent S/C-VLAN CC.
Several bridge ports, each belonging to an ONT, could be members of a C-VLAN
learning S-VLAN. This means that a similar model for the RB mode is supported.
Therefore, multiple (transparent) C-VLAN learning services can be created per
bridge port. The S-VLAN identifying the C-VLAN learning VLAN could be re-used
by multiple services on different bridge ports, just like in the VLAN per service
model.
Forwarding table lookup

The C-VLAN mode applies to stacked VLANs where each subscriber is identified
by a combination of S-VLAN and C-VLAN. Forwarding of downstream traffic is
based on C-VLAN; the MAC destination address is not used. The forwarding and
learning process is quite similar to those of the RB mode. The traffic manager on the
LT card maintains a bridge lookup table for layer 2 forwarding with different lookup
keys for each direction:
• The upstream lookup key is used to check whether a source C-VLAN ID/p-bit
combination is already learned on the bridge port. The key is also used for adding
the S-VLAN tag for packets received on the GEM port ID.
• The downstream key is used to determine the GEM port ID used in the
downstream direction for a given S-VLAN ID, p-bit, and C-VLAN ID
combination. The destination MAC address is not used for forwarding.
A protection is built in to prevent the use of one specific C-VLAN by multiple ports
in one particular VLAN. If a duplicate C-VLAN is detected on the LT across bridge
ports, an alarm is raised.
Table 15-4 describes the layer 2 forwarding process on the LT card when using
C-VLAN learning mode.
Table 15-4 Upstream layer 2 forwarding with C-VLAN learning mode
Interface Description
LIM When a frame is received from the GEM port ID, the LT card checks whether there
is memory to learn the new C-VLAN. When there is memory, the LT card learns the
C-VLAN, adds the S-VLAN tag, and forwards the frame to the NT card.
LT card The LT card verifies the uniqueness of the learned C-VLAN. If the address is unique
within its S-VLAN, there are no more actions on the LIM. If the address is not unique,
the LT card removes the C-VLAN, blocks the bridge port, generates a notification to
the NT card, and unblocks the bridge port when the C-VLAN ages on the first bridge
port.
(1 of 2)

Interface Description
NT card The NT card reflects the disabled state of the bridge port in its managed data and
generates a duplicate C-VLAN alarm to the element management system (EMS). The
alarm contains the C-VLAN and the identification of the two bridge ports involved.
(2 of 2)
Secure C-VLAN learning

Incoming packets without an entry in the forwarding table undergo a C-VLAN
learning process at the LT card. The learning bridge performs the C-VLAN learning
at the level of the bridge. Alternatively, the system also supports statically configured
forwarding entries (instead of learning) using the ENT-PONCFDBSTATIC
command.
The various steps involved in this process are as follows:
1 When a packet arrives from the PON into the traffic manager on the LT card, the
traffic manager checks the upstream learning table that it maintains, to see if the
combination of GEM port ID and C-VLAN ID exists. If an entry does not exist,
the packet is sent to the OBC.
2 The LT OBC is the master for the learning process. When a frame is received on
a GEM port ID, the LT OBC determines the bridge port that corresponds to the
GEM port ID. The LT learns this C-VLAN ID with the following restrictions:
• If the number of C-VLAN IDs already learned on a user port has reached the
maximum (see “Limiting learned MAC addresses or C-VLAN IDs at the LT”), the
C-VLAN ID is not learned and the frame is dropped. If the user sends more than 300
packets with the unlearned C-VLAN ID in 15 s., the OLT will shut down the user
port for 15 s.
• If the C-VLAN ID address is already learned on another bridge port of the same
VLAN, the new CVLAN ID is not learned and the frame is dropped. Duplicate
C-VLANs across different LTs cannot be detected. So, the C-VLAN ID must be
unique for each subscriber within an S-VLAN: two subscribers within the same
S-VLAN cannot have the same C-VLAN.
• Only independent VLAN learning is supported; that is, a C-VLAN ID is unique
within a VLAN, but not across VLANs and bridge ports. If a port is connected to
two VLANs, the C-VLAN ID is learned twice. So, duplicate C-VLAN IDs in
different C-VLAN learning S-VLANs is allowed.
• If 802.1x is enabled on the UNI port, the OBC learns the source MAC address only
if the port is authenticated.
• The 7342 ISAM FTTU also supports a C-VLAN check for the incoming VLAN at
the ONT. The C-VLAN ID provisioned as the UNI-side VLAN will only be allowed
if specifically provisioned for the subscriber service.

Control frame forwarding on the LT

The handling of IGMP, DHCP, PPPoE, and 802.1 packets is configurable:
• IGMP multicast: the handling of IP multicast packets can be modified to achieve
a normal CC, or alternatively can be enabled to become a protocol-aware CC
• PPPoE relay and DHCP relay (note that unlike in RB mode, ARP proxy is not
enabled, if DHCP relay is enabled)
• L2CP: when provider bridge mode is enabled, it is possible to configure, on a
per-VLAN basis and for each protocol, whether that protocol should be tunneled
or discarded
Broadcast handling
The handling of broadcast, other than control packets, by the C-VLAN learning
VLAN is like a CC VLAN, as the broadcast MAC address is not considered in a
CVLAN learning VLAN. This means that both the downstream and upstream
broadcast traffic does not undergo special treatment and is broadcast within the
subscriber C-VLAN learning VLAN.
Forwarding model summary

Table 15-5 provides a summary of the features of each forwarding model on the LT.
Table 15-5 Forwarding model summary on the LT
Item Residential bridge Cross-connect C-VLAN learning
Application Residential Business Residential and Business
Bridge port constellation One or multiple bridge ports One or multiple CC services One or multiple bridge ports
per RB per bridge port per C-VLAN learning VLAN
One or multiple RB services Unique S-VLAN CC per OLT One or multiple C-VLAN
per bridge port learning services per bridge
port
Downstream forwarding S-VLAN ID, destination MAC S-VLAN ID S-VLAN ID, C-VLAN ID, p-bit
lookup key address, p-bit
FDB learning Secure MAC learning, or via No FDB learning Secure C-VLAN learning;
static entries duplicate C-VLANs across
different LTs cannot be
detected, or via static
entries
Downstream multicast IGMP proxy Transparent pass-through Configurable: transparent

handling or IGMP proxy
Control frame handling ARP, DHCP (and ARP), IGMP, L2CP configurable Configurable: DHCP (ARP
802.1x, L2CP always transparent), IGMP,
L2CP
Upstream/Downstream Upstream: transparent Upstream/downstream: Upstream/downstream:

broadcast handling pass-through or limit on transparent pass-through transparent pass-through or
SHub limit on NT
Downstream: control
frames handling or blocked

15.5 Duplicate MAC address and C-VLAN handling
The following sub-sections describe how duplicate MAC addresses and C-VLANs
are handled.
Duplicate MAC address handling on the NT and the LT

The LT performs the duplicate MAC address handling. Duplicate MAC addresses
can be discovered by the NT and the LT:
• when the NT receives a frame from an LT card with a MAC address that was
learned on a different LT card. In that case, the NT returns the frame to the LT
card with a destination MAC address of the card itself, and blocks traffic with that
destination MAC address to the LT card.
• when the LT card discovers a source MAC address that is already learned on
another bridge port of the same VLAN on the same LT card
To handle duplicate MAC addresses, the GLT8 and GLT4 cards reserve 64 filters
and the GLT2 card reserves 32 filters. If the LT card receives a duplicate MAC
address, the LT card:
• discards the frame
• notifies the NT card. The NT card reflects the disabled state of the bridge port in
its managed data and generates a duplicate MAC alarm to the element
management system (EMS). The alarm contains the MAC address and the
identification of the two bridge ports involved.
• blocks traffic as follows:
• installs a reserved filter on the LT card, if available, to discard subsequent frames
from the bridge port with the same source MAC address. Frames with different
source MAC addresses will not be discarded; frames destined to the duplicate MAC
address will be forwarded to the first bridge port where the duplicate MAC address
was learned.
• if all reserved filters are in use, blocks the bridge port
• provides a mechanism to automatically remove the filter and to clear the alarm as
follows:
• The filter is removed after the MAC address ages on the first bridge port where the
MAC address was learned.
• The bridge port is unblocked after a minimum time period.
• The duplicate MAC alarm is cleared when the MAC address ages.
• The alarm timer is re-started if the duplicate MAC re-occurs after the filter is
removed and before the duplicate MAC alarm is cleared.
MAC address flushing

Learned MAC addresses are flushed from the VLAN forwarding database as
follows:
• Aged-out MAC address entries are flushed.
• After an Ethernet connection is disconnected from the UNI of an ONT, the
learned MAC address entries for the ONT UNI port are flushed.

• After the maximum MAC value on a port is changed to a lower number by an

operator, the learned MAC address entries for the ONT UNI port are flushed.
• After a port is authenticated, the learned MAC address entries for the ONT UNI
port are flushed.
Effect of enabling MAC movement on duplicate MAC address handling

When the MAC address movement feature is enabled on a VLAN, it changes the way
duplicate MAC address conflicts are resolved between bridgeports on the same LT
card. If a MAC address is detected on two ports and the MAC address movement
feature is enabled, instead of raising a duplicate MAC address alarm, the conflict is
resolved in favor of the most recent port on which the MAC address was received.
The forwarding database will be updated to reflect the new port and downstream
traffic will be forwarded accordingly.
MAC address movement is useful when multiple WiFi access points are being used,
as it provides support for mobile devices where the MAC address may not have aged
out of the forwarding database on a previous bridge port before it is observed on a
new bridge port. In order to support MAC address movement, the VLAN must be a
residential bridge, the new bridge port must be on the same physical GLT4 card, and
the MAC address must be a dynamic forwarding database entry.
Duplicate MAC addresses between two bridge ports in the VLAN are not permitted
if the VLAN is not configured to permit MAC address movement. An alarm will be
raised to indicate the duplicate MAC addresses.
Duplicate MAC addresses are not supported if it involves a network port or a static
forwarding database entry.
Duplicate C-VLAN handling on the LT

The C-VLAN ID must be unique for each subscriber within an S-VLAN. An alarm
is raised if a duplicate C-VLAN occurs. This results in the temporary blocking of the
second subscriber just as with RB VLANs.
Duplicate C-VLANs across different LT cards cannot be detected at the LT nor at the
NT.
15.6 Residential bridge mode configuration requirements
The RB mode requires the following:

• a VLAN configured in the NT card
• all access links or interfaces added to the VLAN
Upstream frame forwarding

Upstream frames are bridged by the NT card in the VLAN to one of the network
interfaces. The forwarding is based on the MAC addresses learned at the network
interface. If the destination MAC address is unknown, the frame is flooded to all of
the network ports in the system.

Downstream frame forwarding

Downstream frames are bridged by the NT card in the VLAN to the access interface
based on the learned information. If the destination MAC address is unknown, the
frames are flooded to all of the access interfaces in the LAN.
Frames that are forwarded contain the VLAN tag and p-bits. The VLAN tag is the
same one as received over the interface or is the port-based default in case an
untagged or priority-tagged frame is received. The p-bits are passed transparently or
are passed with the port-based default.
Configuration requirements
RB mode provides bridging that is suitable for residential subscribers. Different
bridge ports that belong to the same ONT can be members of the same RB VLAN.
RB supports voice, data, and video services.
Table 15-6 describes the RB configuration parameters on the LT card.
Table 15-6 Residential bridge LT card configuration parameters
VLAN ID The VLAN IDs can be used for RB configuration. The range is 2 to 4094; 1 and
4095 are reserved by standards. VLAN ID 4095 is reserved for internal use.
Member bridge Multiple bridge ports can be configured as member bridge ports of the RB. The
port GE ports on the LT card must be added as member bridge ports by default.
S-VLAN A default S-VLAN can be configured for a bridge port.
Bandwidth and Sustained bandwidth, peak bandwidth, and number of queues (GEM port IDs)
number of can be configured for T-CONTs of the RB. There can be multiple T-CONTs
queues associated with a bridge port (M:1). Upstream granting is based on T-CONTs,
and not on bridge ports.
Table 15-7 describes the system configuration parameters for RB.
Table 15-7 Residential bridge system configuration parameters
Multiple VLANs The 7342 ISAM FTTU allows the configuration of multiple VLANs that are used
for RB. There is a limit to the maximum number of RB VLANs for each system.
Removal of When a bridge port is deleted as a member of the RB, all MAC entries associated
residential with the port are automatically deleted.
bridge member
bridge port
Aging timer An aging timer can be configured for aging the dynamic entries that are learned
in a VLAN forwarding table. The aging timer applies globally to all VLANs in the
system that support MAC learning.
To minimize mis-sequenced or dropped packets when a blocked link is removed
and reconnected, ensure that the aging timer for dynamic MAC entries on the
SHub matches the root bridge forward delay timer for the SHub. For more
information, see 7342 ISAM FTTU Operations and Maintenance Procedures
(1 of 2)

DSCP-to-802.1p The P-OLT can be configured in the QoS profile to indicate that DSCP-to-802.1p
marking marking is enabled on a bridge port. The marking occurs at the ONTs, and is
applied to upstream IP frames that are received untagged.
DSCP-to-802.1p There are DSCP-to-802.1p mapping profiles. A profile can be associated with a
mapping profile bridge port.
Stacked or VLANs can be configured as stacked or unstacked VLANs.

unstacked VLAN
(2 of 2)
15.7 C-VLAN learning mode configuration requirements
C-VLAN learning S-VLANs support a forwarding behavior where the downstream

lookup on the LT is based on S-VLAN, C-VLAN, and p-bits, rather than S-VLAN,
MAC address, and p-bits, as is done in traditional bridge VLANs.
For upstream traffic, packets are tagged with their C-VLAN ID as follows:
• In trusted mode, the residential gateway tags the packets.
• In untrusted mode, the ONT tags the packets.
In the upstream direction, the LT will learn unknown C-VLANs. It is also possible
to statically configure forwarding entries (instead of learning) using the
ENT-PONCFDBSTATIC command.
The C-VLAN ID must be unique for each subscriber within an S-VLAN. An alarm
is raised if a duplicate C-VLAN occurs. This results in the temporary blocking of the
second subscriber.
The handling of non-unicast packets by the C-VLAN learning VLAN can be
configured to behave similarly to the CC VLAN, so that both broadcast and multicast
traffic will be forwarded, both in upstream and downstream directions.
Table 15-8 describes hardware limitations that apply for C-VLAN learning
forwarding on RB VLANs.
Table 15-8 C-VLAN learning hardware limitations
Applies to Limitation
GLT8-A Supports C-VLAN learning
GLT4-A/D Supports C-VLAN learning
GLT2-A Does not support C-VLAN learning
GLT2-B/C Supports partial C-VLAN learning (1)
Note
(1) The GLT2-B/C supports configuration of C-VLAN learning VLANs. However, only static forwarding
entries are permitted. The GLT2-B/C supports configuration of statically configured C-VLAN
forwarding entries using the ENT-PONCFBDSTATIC command. See 7342 ISAM FTTU Operations and

15.8 Cross-connect mode configuration requirements
The purpose of the VLAN CC mode is to create a bit pipe between a VLAN
configured at a network interface and a subscriber interface.
Configuration requirements
The VLAN CC mode requires the NT card to be configured with a VLAN and only
one access interface can be associated with this VLAN. The unicast frames pass
transparently.
In a CC VLAN, a single bridge port is associated with a single VLAN. Only one
bridge port can be configured in a CC VLAN. Table 15-9 describes the CC
configuration parameters.
Table 15-9 Cross-connect configuration parameters
Cross-connect The P-OLT supports the configuration of a VLAN as a CC VLAN.

VLAN
MAC learning The GLT2 card performs MAC learning in a CC VLAN. There are no rules for MAC
movement within the CC VLAN. The GLT8 and GLT4 cards do not perform MAC
learning.
Limit of The P-OLT supports a limit on the maximum number of CC VLANs allowed in
cross-connect each LT card.
VLAN
Stacked S-VLAN The CC VLAN supports configuration of the stacked S-VLAN.
Forwarding
When the frames sent through the bit pipe are IPoE frames, various protocol
messages such as DHCP or IGMP can be snooped. These functions are disabled so
that these frames are handled as data traffic.
Due to this handling, there can be downstream multicast frames, but there is no
corresponding multicast tree. When there is no multicast tree, the frames are flooded
to all access interfaces. In VLAN CC mode, since there is only one access interface,
all frames flood this access interface. The multicast frames pass transparently.
The broadcast frames are forwarded in the same way as multicast frames.
In this configuration, the layer 2 control protocol frames are discarded. The layer 2
frames are link related and are not handled within the scope of a VLAN.

15.9 Transparent protocol forwarding
The 7342 ISAM FTTU supports transparent protocol forwarding on a per-VLAN

basis, for RB, C-VLAN learning, and CC VLANs. Transparent forwarding is
supported for the following protocols:
• ARP
• DHCP
• IGMP
• L2CP
• PPPoE
• 802.1x
You can enable transparent forwarding for a combination of protocols on a VLAN.

When protocol transparency is configured on the VLAN for all protocols, the VLAN
becomes a transparent bitstream.
Transparent forwarding takes precedence over all other settings for the protocol. For
example, if DHCP relay is enabled, it will be ignored if DHCP is specified for
TRANSPROTO. ARP messages will be processed by the ARP proxy, but the ARP
table will not be populated by DHCP snooping.
Note — Where one S-VLAN is used per PON, the filters that are
enabled for transparent pass-through are specific to the LT.
See the PONVLAN configuration procedures in the 7342 ISAM FTTU Operations
and Maintenance Procedures Guide using TL1 and CLI.
15.10 MAC filters
The 7342 ISAM FTTU uses global MAC filters. The filters are applied to the bridge
port to accept or deny preconfigured MAC source and destination addresses. The NT
card supports the filter function.
When both specific and generic MAC filters are enabled for the same port and
VLAN, only the specific filter counter is incremented.
15.11 Pause frames
Pause frames are used for flow control as specified in IEEE 802.3x by definition, a
standard. The LT card does not generate pause frames when it cannot process all of
the data frames from the NT card. The LT card discards the data frames it cannot
process without sending a pause frame. This applies to both upstream and
downstream traffic.
Although there is no pause frame to indicate the discard of the unprocessed frames,
the 7342 ISAM FTTU performance monitoring function collects information about
the events.

The NT card normally does not send pause frames to the LT card. If the LT card
receives a pause frame, the pause frame is discarded.
The NT card can receive and process pause frames. In response to a pause frame, the
NT card stops generating upstream traffic on the interface that sends the pause frame
for the time indicated in the pause frame. Traffic is buffered and QoS-aware
scheduling is performed at due time.
15.12 Layer 2 forwarding for EVC and subscriber scalability

implementations
The 7342 ISAM FTTU supports the ability to disable MAC learning on a range of
SHub VLANs on the NT, to enable layer 2 forwarding based on VLAN ID instead
of MAC addresses. This supports subscriber scalability implementations (typically
residential) and EVC implementations for businesses with large numbers of MAC
addresses (typically CC).
In the case of residential applications, a large number of subscribers might be
connected to the 7342 ISAM FTTU. In this case, the PON must be able to support up
to 288 UNIs, which implies the ability to learn a large number of MAC addresses. In
order to address MAC learning limitations of the SHub (up to 16 384 MACs), it is
desirable to disable MAC learning on the SHub VLAN range.
For Ethernet virtual connections (EVCs), business customer CCs can carry a large
number of different MAC addresses, if a large private network is behind the
deployed ONT. Since the 7342 ISAM FTTU does not need to learn all these MAC
addresses, it is possible to disable MAC learning for the VLAN range.
An Ethernet services model that utilizes a T-CONT per-service per-subscriber
configuration should also be implemented when MAC learning is disabled on the
VLAN range. This implementation makes use of T-CONT sharing across multiple
UNIs.
Implementation considerations
Disabling of MAC learning on a range of VLANs places the following limitations on
the VLANs:
• For RB VLANs, MAC scalability is supported by disabling MAC learning on
user ports only (ports toward the LT). In this case, the network ports continue to
learn, so there is no limit to the number of network ports or trunks in these
VLANs.
• For CC VLANs, MAC learning can be disabled on both network and user ports.
• Each VLAN must be restricted to a single LT. This limitation is required to avoid
flooding of unicast traffic to multiple LTs.
• In the case of CC VLANs, it is recommended to limit the VLAN to a single
network port (or trunk), to avoid flooding of unicast traffic to multiple network
ports. If multiple network ports are configured, they should be configured either
as a link aggregation group (trunk), or using STP protocol. If a link aggregation
group is used, unicast traffic will be forwarded on a single link of the group. If

STP is used, the 7342 ISAM FTTU should be configured as non-root, so that
redundant links will be placed in blocking state. This will enable unicast traffic to
be forwarded on the single link.
Note — Packet processing behavior is inherited from the VLAN

mode (RB or CC) specified for the VLANs in the range.
The downstream forwarding for a VLAN range that has MAC learning disabled can
be configured in one of two modes:
• Flood to the LT—when user and network ports are disabled, DLF traffic is layer
2 forwarded to user and network member ports without learning the SMAC.
When user ports only are disabled, traffic is forwarded after SMAC learning.
• Redirect to the LT—when the user and network ports are disabled, DLF traffic is
layer 2 forwarded to the user but not to other network member ports, without
SMAC learning. When user ports only are disabled, traffic is forwarded after
SMAC learning.
These two modes provide different handling toward the LT links, which are
configured as a link aggregation, with redundant links to both NTs.
The redirect mode has the advantage that the selection of the egress LT port is
decided in the ingress chip. Flooding results in packets being sent to both NTs, which
then use hashing on trunk block masks to determine whether to forward or not.
Note 1 — All residential features such as anti-spoofing and
authentication are fully functional when subscriber scalability is
implemented.
Note 2 — The GLT4 can manage 1024 IGMP packets per second with
a 40% processor loading. Assuming 288 UNIs on all 4 PONs (1152
UNIs), this corresponds to a maximum of approximately 0.9 IGMP
packets per subscriber per second, on average.
For Business services CC configurations, an external EVC with a T-CONT per class
of service should also be implemented, with MAC learning disabled on the
applicable SHub VLANs.
For subscriber scalability, a T-CONT per-service per-subscriber model should also
be implemented, similar to the Ethernet services configuration that supports
T-CONT sharing across multiple UNIs on an ONT, for a single service. Figure 15-5
illustrates this configuration model.
See the section “Ethernet services for business and residential applications” for
information about Ethernet services configurations. See the 7342 ISAM FTTU
Operations and Maintenance Procedures Guide using TL1 and CLI for Ethernet
services TNG and layer 2 forwarding procedures with MAC learning disabled.

Figure 15-5 T-CONT per Service with GEM port per subscriber
OLT PON ONT
Tag GEM GEM Tag Tag

UNI
Tag GEM GEM Tag Tag
T-CONT T-CONT WRR
Tag GEM GEM Tag Tag
UNI
Tag GEM GEM Tag Tag
Uplink
Tag GEM GEM Tag Tag

UNI
Tag GEM GEM Tag Tag
T-CONT T-CONT WRR
Tag GEM GEM Tag Tag
UNI
Tag GEM GEM Tag Tag
20070
Table 15-11 lists subscriber scaling that can be implemented based on T-CONT
per-service and GEM port per-subscriber usage and bridging table limits. The
subscriber scaling model only serves as an example, and assumes an MDU
implementation with 24 subscribers on the ONT side, and the allocation of
T-CONTs, GEM ports, and MAC learning entries on a per-PON basis as shown in
Table 15-10 on the OLT side.
Table 15-10 Per-PON allocation of resources
Resources Available for Reserved for Total

subscriber other traffic
services
T-CONTs per PON 440 72 512
GEM ports per PON 864 160 1024
MAC learning entries per PON 1908 140 2048
Table 15-11 Subscriber scaling based on T-CONT and GEM usage
Subscribers Services MAC Maximum T-CONT GEM Bridging table

per ONT address subscribers determined limit determined determined limit
per PON (440 * 24 / limit (1908 / (number of
(number of (864 / MAC addresses))
services)) (number of
services))
24 3 6 288 3520 288 318
24 3 8 239 3520 288 239
(1 of 2)

Subscribers Services MAC Maximum T-CONT GEM Bridging table

per ONT address subscribers determined limit determined determined limit
per PON (440 * 24 / limit (1908 / (number of
(number of (864 / MAC addresses))
services)) (number of
services))
24 4 8 216 2640 216 239
(2 of 2)
Restrictions and limitations

Certain restrictions and limitations should be considered when disabling MAC
learning to implement subscriber scalability.
• Due to a shortage of packet processing hardware filters, subscriber scalability
configuration is permitted on a VLAN range only, and not individual VLANs.
• The VLANs in the range and the VLAN ports must be configured on the SHub,
with all other parameters specified, and all the VLANs in the range must use the
same LT port.
• The VLAN mode must be the same (RB or CC) for all VLANs in the range.
• For VLANs in the range, user-to-user communication must be disabled because
MAC learning will be disabled on user ports.
• Layer 3 functionality is not supported when MAC learning is disabled on user
ports. The outgoing port information of layer 3 next hop MAC cannot be
determined, so you cannot configure VLANs in the range with a layer 3 interface.
• The upstream traffic intended for a specific network port will be duplicated on
other network ports in forwarding state, resulting in bandwidth wastage on those
network ports. Therefore, it is strongly recommended that the network ports be
configured with a single port (or trunk) in forwarding state.

16.1 Overview 16-2
16.2 Single bridge port configuration 16-2
16.3 Multiple bridge port configuration 16-3
16.4 Multiple upstream switches configuration 16-3
16.5 Uplink redundancy to multiple upstream switches 16-4
16.6 Multi uplink protection to upstream switches 16-5
16.7 Redundancy between NT and LT cards 16-5
16.8 Dynamic data synchronization 16-6

16.1 Overview
This chapter provides information about the redundancy of the NT cards that use a
load-balancing scheme. The information includes the architectural aspects of the LT
cards that are required to support the NT redundancy.
Note — The P-OLT provides a fast switch-over in case of link or

equipment failures. The operator must ensure that other upstream
devices such as switches and routers do provide a similar fast
switch-over to ensure end-to-end fast switch-over in case of link or
equipment failures. Such a fast switch-over capability will be critical
for voice, video, and CES services.
TL1 and CLI for more information.
16.2 Single bridge port configuration
7342 ISAM FTTU can be configured as a single bridge port connected to an

upstream switch. Figure 16-1 shows the network topology of the single bridge port
connected to an upstream switch.
Figure 16-1 Single bridge port network topology
Upstream switch
NT-A NT-B
18196
The links as a whole are configured as a single 802.3ad link aggregation group so
that there is one single bridge port connecting 7342 ISAM FTTU and the upstream
switch. The links are terminated on NT-A and NT-B.
The links work in a load-balancing mode. In this mode, a flow is always assigned to
the same link. There are no sequencing issues. If one of the links fails, the other links
will share the remaining load. The bridge port is kept active.
If an NT card fails, two of the network links in the group will fail. The network bridge
port is still active because the other NT card will share the remaining load.
The time to detect the link failures and reconfigure the link group is less than a
second. There is no need to relearn any of the network MAC addresses after a link
failure or recovery since the state of the bridge port does not change.
In this mode, there is a single bridge port running the STP. When there is a failure of
a link of an NT card, the STP state is not affected. There is no need to recompute a
new spanning tree. The 7342 ISAM FTTU platform implements a distributed STP
algorithm that runs on NT-A and NT-B at the same time.

16.3 Multiple bridge port configuration
7342 ISAM FTTU can be configured as multiple bridge ports connected to one
upstream switch. Figure 16-2 shows the network architecture of the multiple bridge
port configuration.
Figure 16-2 Multiple bridge port network topology
Upstream switch
NT-A NT-B
18197
The links are grouped into separate 802.3ad link aggregation groups. One group is
terminated on NT-A and the other is terminated on NT-B. Each link aggregation
group runs RSTP. When forwarding NT-A fails, RSTP reconverges.
Both bridge ports run RSTP, but only one of the bridge ports is in the forwarding
state. This is the way used by the RSTP algorithm to prevent a loop between the
7342 ISAM FTTU and the upstream switch.
Note — RSTP must be disabled between the upstream switch (such

as the 7450 Ethernet Service Switch) and the G6 gateway.
When a link fails on the primary NT card, the bridge port is kept active by the other
links in the group.
When one of the NT cards fails, there is a need to recompute a new spanning tree
since the STP state is affected. The recomputing stops the traffic flow for a few
seconds when the STP algorithm converges. Use of the RSTP algorithm can speed
up the convergence.
The failure of an NT card also requires the network addresses to be relearned after
the switch-over, since no traffic has passed through the secondary NT card. If link
aggregation is used on the LTs, subscriber MAC addresses do not need to be
relearned by NT-B.
The disadvantage of this connection topology is that only half of the network links
are used at any given time. There is also a short service interruption when there is a
card failure.
16.4 Multiple upstream switches configuration
7342 ISAM FTTU can be configured into multiple link aggregation groups
connecting to multiple upstream switches. Figure 16-3 shows the multiple upstream
switches.

Figure 16-3 Multiple upstream switches
Upstream Upstream
switch 1 switch 2
NT-A NT-B
18247
In this configuration, each link aggregation group functions as a bridge port. Each
link aggregation group runs RSTP.
When the forwarding NT-A fails, RSTP reconverges.
Note — RSTP must be disabled between the upstream switch (such
as 7450 ESS) and the G6 gateway.
16.5 Uplink redundancy to multiple upstream switches
The 7342 ISAM FTTU can be configured to have an active uplink and a standby
uplink to multiple upstream switches. Figure 16-4 shows this configuration.
The two links on the OLT will be configured as a static link aggregation group with
one link designated as “active” and the other as “standby”. The IP address and MAC
address of the links on the two routers will be the exact same address toward the
OLT. Network traffic will only be carried on the active link. If the active link fails,
all network traffic will switch to the standby link. There will be no need for MAC
learning or ARP entry refresh because the IP and MAC addresses of the two links
will be the same.
Figure 16-4 Redundant uplinks to upstream switches
Upstream Upstream
Router-1 Router-2
Static
LAG
NT-A NT-B
20507

16.6 Multi uplink protection to upstream switches
The 7342 ISAM FTTU can be configured for network redundancy with multi uplink
protection using the path connectivity check and protection (PCCP) feature to
guarantee network connectivity between the FTTU and its default gateway.
Figure 16-5 shows a configuration using four network ports in a PCCP protection
group.
A PCCP group can have as many ports associated with it as the NT hardware
supports (eight ports with EHNTs and four ports with EXNTs). Each port of the
group must have similar properties and can be either individual ports or LAG ports.
A maximum of four PCCP groups is supported.
Figure 16-5 Multi uplink protection to upstream switches
VRRP
PE Router PE Router
L2/L3 L2/L3
switch switch
PCCP Group
FTTU
21695
16.7 Redundancy between NT and LT cards
The 7342 ISAM FTTU supports redundancy between the NT and LT cards.
The redundancy is supported through static link aggregation. Since each LT card
supports several ONTs and subscribers on each ONT may have different MAC
addresses, flow assignment is based on source MAC and destination MAC.
If one of the NT cards fails, the subscriber MAC and multicast membership is
automatically available on the secondary NT card.
RIPv2 supports redundant NT cards. When that standby NT card comes up, the
RIPv2 module can be restarted and no reprovisioning is required on the standby NT.

16.8 Dynamic data synchronization
Dynamic data is synchronized between the two NT cards to minimize service

interruption if one of the NT cards fails.
Dynamic data includes the following:
• MAC addresses in the FDB tables that have been learned on a port
• IGMP multicast membership data
• unsaved configuration data
• authentication data
When link aggregation is used with one link from each NT card, all MAC addresses
are learned on both links.
The NT cards synchronize the AAA server and RADIUS client information. With
the synchronization, the operator-initiated disconnections and subscriber-initiated
disconnections can work normally after a switch-over.
If the operator performs provisioning tasks on the layer 2 switch, there is a window
of time when the two NT cards are out of synchronization until the data is copied to
the standby NT card. During this window, the standby NT card is in cold-standby
state and the SWCAP alarm is raised. However, it is possible that this alarm is not
visible if the amount of provisioning is small and the synchronization can therefore
be very quick.
With RIPv2, there is no need to dynamically synchronize the RIPv2 database when
the standby NT comes up.

17 — Proxy ARP
17.1 Overview 17-2
17.2 Functional description 17-2
17.3 Proxy ARP process flow 17-2
17.4 ARP table persistence 17-3
17.5 Static ARP IP address 17-3

17 — Proxy ARP
17.1 Overview
This chapter provides a detailed description of the proxy address resolution protocol
(ARP) used in the 7342 ISAM FTTU.
17.2 Functional description
Proxy ARP provides a proxy that answers ARP requests intended for another host
and routes packets to the destination host. This function helps hosts on a subnet reach
remote subnet hosts without configuring routing or a default gateway.
In the 7342 ISAM FTTU, a host on a customer premises equipment (CPE) from a
subscriber residence sends an ARP request as a broadcast frame. After verifying that
the host IP address and MAC address are valid, the LT forwards the request upstream
to the gigabit Ethernet (GE) port. The upstream edge router responds to the ARP
request with a unicast message that is forwarded to the designated host based on
MAC lookup. No special ARP handling is required to forward a unicast message
downstream to the host.
However, when the edge router sends an ARP request for a host on a CPE, special
ARP handling is required on the LT card because broadcast frames are not forwarded
downstream in residential bridge VLANs. This special ARP handling is the proxy
ARP function.
17.3 Proxy ARP process flow
The proxy ARP function is activated on a residential bridge VLAN when the DHCP
relay is enabled on the residential bridge VLAN. The proxy ARP function does not
work if DHCP relay is not enabled. The proxy ARP process works as follows:
1 After snooping the DHCP ACK packages, the LT adds the IP address to the lease
table and creates an ARP entry with the corresponding MAC address.
2 After the ARP entry ages out, the LT periodically sends ARP requests to the
allocated IP address on the bridge port that sent out the DHCP request message.
3 If an ARP response is received, the corresponding ARP entry is refreshed in the
ARP table for the ARP aging period. The forwarding table of the VLAN is also
updated with the MAC address of the client (host) for the same period.
4 If there is no response to an ARP request, the ARP entry and FDB entries are
de-activated. However, the IP address in the lease table is not deleted. The IP
address is deleted only when the lease period expires.
5 If the client resumes sending traffic after being inactive, the LT activates the
ARP and FDB entries for the client. The client does not need to initiate a new
DHCP request.
6 If the edge router sends an ARP request for a client, the LT sends an ARP
response to the edge router with the MAC address of the CPE, after verifying that
there is an entry corresponding to the IP address in the ARP table.

17 — Proxy ARP
7 After snooping DHCP release packages, the LT deletes the MAC entry in the
ARP table after verifying that an entry corresponding to the client IP address is
in the lease table.
8 After the lease expires, the IP address in the lease table and the MAC entry in the
ARP table are deleted.
17.4 ARP table persistence
The DHCP force renew mechanism described in the preceding process is not
supported by all residential gateways and hosts. This can be resolved by making the
ARP tables persistent on the network termination (NT) card.
Persistent ARP tables are stored in the file system on the NT cards. Persistent ARP
tables are available to the line termination (LT) cards after an LT restart or LT
replacement. Because the file system is replicated across the two NT cards, the ARP
table can also survive an NT switch-over or NT replacement.
If operating personnel want to replace both of the NT cards, they must back up the
database and restore it after installing the new NT cards. When the ARP file is
restored from the element management system (EMS), the NT card downloads the
ARP tables to the LT cards.
After an NT switch-over, the newly activated NT performs an audit of the ARP table
by retrieving the tables from the LTs and updating any entries that are missing in its
database.
The LT cards need to download the ARP tables from the active NT after a restart.
The LT cards need to check if any entries have aged out and flush the aged-out
entries from the table.
17.5 Static ARP IP address
The 7342 ISAM FTTU supports the addition and deletion of a static IP address in a
residential bridge VLAN that is enabled for the DHCP relay agent function. When
the proxy ARP and static IP are used on the VLAN, the DHCP packets are relayed
in the VLAN without adding Option 82 parameters to the packets.
Static IP addresses can be created in the ARP table for a specific bridge port. Periodic
ARP requests can be sent for static IP addresses to learn the MAC addresses of the
hosts.
If the DHCP server snoops an IP address that is a static IP address in the VLAN, the
static IP address takes precedent over dynamic IP addresses. If the DHCP server
assigns the same IP address as a static IP address, the static IP address overwrites the
dynamic IP address.
TL1 and CLI for static ARP configuration procedures.

17 — Proxy ARP
ARP snooping
The ARP snooping function on the LT snoops the ARP response to an ARP request
from a host on the subscriber side. The 7342 ISAM FTTU uses this function to learn
the IP address and MAC address of a host. After the LT snoops a successful ARP
request and ARP response, the 7342 ISAM FTTU dynamically adds an entry for the
host in the ARP table. To avoid service theft, the entry is made static so that the IP
address is fixed to the ONT UNI.
The ARP snooping function can snoop multiple IP addresses on the same ONT UNI.
The 7342 ISAM FTTU limits the number to the maximum number of MAC
addresses allowed on the ONT UNI. To refresh the ARP table, the Proxy ARP
function periodically sends an ARP request to a snooped IP address. After a response
is not received to three consecutive ARP requests, the Proxy ARP function removes
the entry from the ARP table.
The ARP snooping function is supported by the 7342 ISAM FTTU GLT4, and GLT8
cards. The ARP snooping function is enabled on the LT on a per VLAN basis, and is
useful for handling deployments of subscriber services, such as Video-on-Demand,
where IP addresses that are statically assigned to hosts cannot be entered manually
in the system.
TL1 and CLI for procedures to configure ARP snooping.

18 — QoS
18.1 Overview 18-2
18.2 QoS infrastructure 18-2
18.3 Traffic classification and marking elements 18-4
18.4 Traffic policing elements 18-8
18.5 Congestion management elements 18-9
18.6 Traffic shaping elements 18-22
18.7 QoS configuration 18-28
18.8 End-to-end downstream queuing and scheduling 18-29
18.9 End-to-end upstream queuing and scheduling 18-32
18.10 Multicast bandwidth considerations 18-35
18.11 Recommended DSCP to p-bit mapping 18-36

18 — QoS
18.1 Overview
This chapter describes the QoS functions used by the 7342 ISAM FTTU.
The 7342 ISAM FTTU ONT and OLT uses the 802.1p bits QoS model, which relies
on traffic segregation into classes of service (CoS) by p-bit. Each traffic class can be
configured with different QoS characteristics, insuring preferential treatment for
higher priority traffic on the network, such as video and voice traffic.
TL1 and CLI for QoS configuration procedures.
18.2 QoS infrastructure
QoS provides the ability to differentiate levels of service priority by CoS. A service
level is typically described in terms of network delay, bandwidth, and jitter. For
example, much data traffic is tolerant of delays and packet drops. However, voice
and video are intolerant of jitter. Video can also be bursty at times.
To ensure that traffic is serviced according to its behavior and to service level
requirements, QoS provides support to the following functions:
• classifying and marking traffic according to type and importance based on
policies and the behavior of traffic
• policing traffic by limiting the egress and ingress traffic
• managing congestion by prioritizing traffic based on marking and by configuring
queuing and scheduling that respond to traffic classes
• traffic shaping by specifying guaranteed and non-guaranteed traffic rates to
maximize the use of bandwidth
Figure 18-1 shows the high-level view of the QoS infrastructure that is implemented
on the 7342 ISAM FTTU.

18 — QoS
Figure 18-1 QoS infrastructure
Upstream scheduling
OLT Guaranteed BW ONT

Extra BW
GEM port GEM port
T-CONT SP/
Network eHCL LT SP/ DBA GEM port GEM port WRR Service
NT SP/ Classifier
port scheduler GPON port
WRR WRR
GEM port T-CONT GEM port
Grants
Downstream scheduling
OLT ONT
GEM port
Network NT SP/ eHCL LT SP/ GEM port SP Service
port GPON port
WRR WRR
GEM port
19084
Elements of the QoS infrastructure are hardware, software, and data-related, and are
listed by function in Table 18-1.
Table 18-1 QoS infrastructure elements
Function Element
Traffic classification and marking CoS

P-bit
DSCP
DSCP to p-bit mapping
P-bit to CoS mapping
QoS marker and session profiles
Traffic policing Traffic meter
Ingress rate
Maximum burst size
Traffic flow
Egress rate
(1 of 2)

18 — QoS
Function Element
Congestion management Switch
Ports
Scheduler and queues

P-bit to queue mapping
Traffic scheduler
Downstream hierarchical scheduler and rate limiting
Priority queue profile
T-CONTs and GEM ports
GEM traffic descriptors
Traffic shaping Bandwidth profile
Reserved bandwidth
Dynamic bandwidth allocation (DBA)
(2 of 2)
18.3 Traffic classification and marking elements
Traffic classification and marking elements described in this section are:

• CoS
• P-bit
• DSCP
• DSCP to p-bit mapping
• P-bit to CoS mapping
• QoS marker and session profiles
CoS
A CoS is a grouping of similar traffic types that has its own level of service priority.
The 7342 ISAM FTTU recognizes up to eight CoS.
P-bit
The system uses the priority-bit (p-bit) to differentiate traffic into CoS. The p-bit is
an integer value from 0 to 7 that is either encoded in the tag header of a
priority-tagged and VLAN-tagged frame, or derived from the DSCP number in the
IP header of an untagged frame.
Traffic is marked with a p-bit according to its type and importance. Time-critical,
delay-sensitive, and jitter-sensitive traffic, such as network control data, voice, and
video, receive the higher value p-bits. Less time-sensitive traffic, such as data,
receive the lower value p-bits.

18 — QoS
Traffic types include ethernet data, IGMP, multicast, voice signaling, voice bearer,
CES, and OMCI.
Note — The following definitions apply.
• An untagged frame is a frame that does not carry a tag header

following the source MAC address.
• A priority-tagged frame is a frame that carries a tag header with
priority information, but with no VLAN ID.
• A VLAN-tagged frame is a frame that carries a tag header with
both priority information and VLAN ID.
DSCP
The DSCP is an integer value from 0 to 63 that is encoded in a six-bit field in the IP
header. The six-bit field allows for 64 (26 = 64) possible forwarding behaviors. Each
forwarding behavior maps to one of eight p-bit values.
DSCP to p-bit mapping

A DSCP to p-bit mapping maps blocks of DSCP numbers to p-bits. The mapping is
used to mark untagged frames with their p-bit. When an upstream untagged IP frame
from a trusted subscriber is received, the mapping is used to convert the DSCP
number in the IP header of the frame to a p-bit.
You can configure DSCP to p-bit mappings at the following two levels:
• system-wide level
• ONT UNI port level
See Table 18-14 for the Alcatel-Lucent recommended mapping of DSCP numbers to
p-bits.
System default DSCP to p-bit mapping

Blocks of DSCP numbers are mapped to p-bits to serve as system defaults for ONT
UNI ports.
Customized DSCP to p-bit mapping

Customized mappings of DSCP numbers to p-bits can be configured for an ONT
UNI port.
P-bit to CoS mapping

The P-bits 0 to 6 are system mapped to one of eight CoS (or queues). P-bit 7 is
reserved for management traffic, such as OMCI. The mapping is used for upstream
traffic at the NT.

18 — QoS
C-VLAN to S-VLAN p-bit translation

An optional p-bit translation profile can be configured and associated with a stacked
S-VLAN, to map C-VLAN p-bit values (0 to 7) to S-VLAN p-bit values (0 to 7). The
LT uses the translation profile to perform priority marking of upstream traffic.
The LT adds an outer S-VLAN tag to the frame, and uses the associated translation
profile to derive the corresponding S-VLAN p-bit. An S-VLAN that is configured in
this mode could be used by either an EVC flow or an HSI service.
Figure 18-2 shows an example of a C-VLAN to S-VLAN p-bit translation that is
performed at the LT.
Figure 18-2 C-VLAN to S-VLAN p-bit translation at the LT
7750 7342 OLT/LT ONT LiveBox

HSI Traffic HSI Traffic
SVLAN = 1035/pbit = 0 HSI Traffic CVLAN = 835/pbit = 0
VoD Traffic VoD Traffic

SVLAN = 1238/pbit = 4 VoD Traffic CVLAN = 838/pbit = 4
TVNum Traffic TVNum Traffic

SVLAN = 1340/pbit = 4 TVNum Traffic CVLAN = 840/pbit = 5
VoIP Traffic VoIP Traffic

SVLAN = 1451/pbit = 6 VoIP Traffic CVLAN = 851/pbit = 6
20056
UNI-side to network-side p-bit translation profile

When configuring Ethernet services flows, a p-bit translation profile can be applied
to a flow for the ONT, to translate priority marked traffic from the UNI-side
(subscriber) to network-side (network service provider) p-bit values.
Traffic is directed toward a GEM port, based on the specified p-bit mapping, the
outer VLAN key, and the priority queue profile. After the VLAN tagging and
translation process is complete, the specified p-bit value is used to map to a specific
GEM port. Package A, C, and H (current generation) ONTs do not support
downstream pbit translation in VLAN translation mode.
The application of p-bit translation depends on the type of flow. For a default flow
using p-bit translation, all UNI-side p-bits must translate to only one network-side
p-bit in the p-bit translation profile.
A “wildcard” flow accepts any outer-tag VLAN-ID entering the UNI and requires a
p-bit mapping profile to translate UNI-side to network-side p-bits. If multiple
wildcard flows are configured on the same ONT UNI port, the flows cannot have
overlapping UNI-side p-bits in the p-bit translation profile.
See chapter 28 for additional information about Ethernet services. For flow and p-bit
configuration details see the 7342 ISAM FTTU Operations and Maintenance
Figure 18-3 shows an example of one-to-one p-bit translation at the ONT with
VLAN translation also supported.

18 — QoS
Figure 18-3 One-to-one p-bit translation, single-tagged frames
Upstream single-tagged with VID translation and P-bit translation
From UNI C-VLAN ID C-P-bit C-VLAN ID C-P-bit To GEM Port

(C-VID), C-P-bit)
Translate 1:1
Downstream single-tagged with VID translation and P-bit translation
To UNI C-VLAN ID C-P-bit C-VLAN ID C-P-bit From GEM port
Translate 1:1
20079
Figure 18-4 shows a many-to-one p-bit translation that uses a many-to-one mapping
of UNI-side to network-side p-bit values. For example, you might use this when a
flow is configured as the default flow for the UNI.
Figure 18-4 Many-to-one p-bit translation, single-tagged frames
Upstream single-tagged with 1:1 translation and N:1P-bit translation
From UNI Default

C-VLAN ID C-P-bit C-VLAN ID C-P-bit
Translate 1:1
Overwrite
Downstream single-tagged with VID translation and P-bit pass through
From UNI C-VLAN ID C-P-bit C-VLAN

C-VID ID C-P-bit From GEM port
Translate 1:1
Pass through
20080

The QoS marker profile establishes policies for marking and tagging downstream
and upstream frames at the ONT to guarantee various levels of service.

18 — QoS
A QoS marker profile is configurable for an ONT UNI port, and includes information
such as:
• default p-bit for untagged upstream traffic
• downstream tagging behavior
• upstream tagging behavior
The QoS session profile associates a QoS marker profile with an ONT UNI port. The
same marking and tagging rules are applied to all services across an ONT UNI port.
18.4 Traffic policing elements
Traffic policing is a process that measures the transmission rate of traffic across a
port and compares the rate to acceptable threshold levels. Traffic policing can be
implemented at a network port to monitor ingress traffic for ingress rate and
maximum burst size, and egress traffic for egress rate.
Traffic policing elements described in this section are:
• Traffic meter
• Ingress rate
• Maximum burst size
• Traffic flow
• Egress rate
Traffic meter
Traffic meters specify both the maximum rate of traffic that can ingress a SHub port,
and the maximum burst size allowed. Traffic meters are applied to network ports.
Ingress rate
Ingress rate is the maximum rate of traffic that can ingress a port. Ingress rate is
configurable for a network port, and can be monitored for different traffic flow types.
Maximum burst size

Maximum burst size is the maximum number of bytes that can travel through a port
without causing packet loss, and is configurable for a network port.
Traffic flow
Ingress traffic can be monitored for the following traffic flow types:
• port—all traffic on a port
• VLAN—all traffic associated with a VLAN
• VLAN and p-bit—all traffic associated with a VLAN and having the same p-bit
• VLAN and DSCP—all traffic associated with a VLAN and having the same
DSCP number

18 — QoS
Egress rate
Egress rate is the maximum rate of traffic that can leave a port. A network port can
be configured for egress rate, and can be enabled or disabled to receive pause frames.
18.5 Congestion management elements
The p-bit value directs the assignment of traffic to queues. Queues can be sized and
scheduled to meet the service needs of traffic classes. Traffic schedulers are
configurable by port.
Congestion management elements described in this section are:
• Switch
• Ports
• Scheduler and queues
• P-bit to queue mapping
• Traffic scheduler
• Downstream hierarchical scheduler and rate limiting
• Priority queue profile
• T-CONTs and GEM ports
• GEM traffic descriptors
Switch
The switch is a device with ports that directs incoming data from multiple input ports
to the output port that will take it to its final destination. The switch performs the
following tasks:
• scheduling—deciding which packet to send when packets from multiple input
ports are intended for the same output port
• data forwarding—forwarding the packet to the intended output port, under the
control of the scheduler
• queue management—managing queues to minimize packet loss rates and to
optimize throughput
The P-OLT hardware has two switch devices: a large switch located on the NT card,
which is called the SHub, and a small switch located on the LT card. Queuing and
scheduling functions can be performed by both switches if required. The size of the
switch varies based on card type. For switch sizes, see Chapter 5.
The switch on the LT card operates at electrical speeds in both upstream and
downstream directions, although congestion may occur on individual ports.

18 — QoS
Ports
The 7342 ISAM FTTU receives and transmits data through external ports, internal
ports, and virtual ports.
• External ports include SHub ports on the NT and ONT UNI ports.
• SHub ports include 1 Gb/s and 10 Gb/s ports located on the NT.
• ONT UNI ports include Ethernet ports (RJ-45), VDSL2 ports, MoCA ports, DS1/E1
ports, POTS port (RJ-11), and RF video ports.
• Internal ports include GE and OBC ports, which are implemented by the Ethernet
switch.
• Virtual ports are GEM ports that are used to carry traffic across the GPON from
the LT card to the ONT and from the ONT to the LT card.
Scheduler and queues

A port is equipped with a scheduler, which has up to eight queues. The queue is
where the data is held while it awaits forwarding; the scheduler is what decides
which queues to process and in what order. Each queue is provided with a size and a
weight.

A mapping of p-bits to queues directs traffic of a specified CoS to one of eight
queues.
Mappings of p-bit to queues are configured at the LT, ONT, and service levels.
P-bit to queue mapping at the LT

A single p-bit to queue mapping directs the queuing of downstream and upstream
traffic at the LT:
• from the LT to the GPON
• from the LT to the NT
The mapping of p-bits 0 through 6 to queues 1 through 7 is configurable. Queue 0 is
reserved for internal VLAN (4095) traffic; p-bit 7 is automatically mapped to the
same queue as p-bit 6.
P-bit to queue mapping at the ONT

At the ONT, a mapping of p-bit to queues is included in the downstream rate limiting
scheduler for the ONT.
P-bit to queue mapping at the service level

At the service level, a mapping of p-bit to queues is included in the priority queue
profile associated with the service, and applies to upstream traffic on the service.

18 — QoS
Traffic scheduler
A customized traffic scheduler provides more flexible scheduling capabilities over
the system default traffic scheduler. Traffic schedulers regulate the depth and
scheduling of queues of a port, and can be configured for ports at the NT and at the
LT. Ports include:
• at the NT
• from the NT to the LT
• from the NT to the network
• at the LT
• from the LT to the GPON
• from the LT to the NT (GLT2 scheduling stage)
• from the LT to the NT (GLT4 fixed non-configurable queuing mechanism)
• from the LT to the NT (GLT8 fixed non-configurable queuing mechanism)
Note — There are two stages of downstream scheduling in the LT:
• scheduling stage associated with the internal switch, which is

supported on the GLT2, as described in this section. See Traffic
scheduler at the LT for more information.
• hierarchical scheduling stage that allows ONT level scheduling
and PON level scheduling, which is supported on all LT card types
except the GLT2-A. See Downstream hierarchical scheduler and
rate limiting for information.
The traffic scheduler specifies:

• weight of a queue
• internal buffer size in bytes of a queue
• size of buffer to be shared dynamically among the queues
The internal buffer size affects latency, as latency increases with size of queue.
The weighted priority of a queue determines how the queue is scheduled. A queue
can be scheduled in one of two ways:
• strict priority (SP)
• weighted round robin (WRR)
SP scheduling ensures that highly critical or sensitive traffic is forwarded with
minimal delay. WRR scheduling gives precedence to higher priority traffic and
ensures that lower priority traffic is serviced satisfactorily. The queue wit ha lower
number has a higher weighting, e.g. a queue with a weight of 155 gets processed later
than a queue with weight 55. When the port is not congested, all weighted queues are
treated equally. When congestion occurs, the weight is used to give weighted priority
to higher priority traffic.
Traffic scheduler at the NT
Table 18-2 identifies scheduling of queues at the NT by weighting factor.

18 — QoS
Table 18-2 Scheduling of queues at the NT by weighting factor
Weight Scheduling
Queue 0 SP
Queue with a weight of 0
Queue with a weight of 1 to 15 WRR
Queue with a weight of 16 Not used
Traffic scheduler at the LT
Table 18-3 identifies scheduling of queues at the GLT2 LT by weighting factor.
Table 18-3 Scheduling of queues at the GLT2 by weighting factor
Weight Scheduling
Queue 0 (1) SP
Queue with a weight of 0
Queue with a weight of 1 to 15 WRR
Note
(1) Queue 0 is always SP and is reserved for internal VLAN traffic.
Where a traffic scheduler is not configured for a port at the GLT2, the system default
traffic scheduler is assumed. Table 18-4 identifies the parameter values in the system
default traffic scheduler at the GLT2 and default p-bit mapping.
Table 18-4 Default traffic scheduler at the GLT2
Queue Weight Size P-bit mapping
0 (1) 0 11648 —
1 0 11648 6, 7
2 0 11648 4, 5
3 2 11648 2, 3
4 1 11648 0, 1
5 16 (not used) 0 — (2)
6 16 (not used) 0 — (2)
7 16 (not used) 0 — (2)
Dynamic area — 58240 —

18 — QoS
Notes
(1) Queue 0 is reserved for internal VLAN traffic.
(2) P-bits are not assigned to unused queues.
Downstream hierarchical scheduler and rate limiting

The transmission on the PON in the downstream requires rate shaping capabilities to:
• guarantee bandwidth fairness between the different ONTs, or between the
services on one ONT
• to control the rate of traffic sent to the ONT so that the ONT does not receive
more traffic than its ONT UNI ports can support
Therefore, the GLT8 and GLT4 LT cards support scheduling and rate limiting of
traffic at the ONT level, and scheduling of traffic at the PON level. This is not
supported on the GLT2. Certain traffic types, such as OMCI, optionally voice, and
multicast, bypass the scheduling at the ONT level, and are scheduled at the PON
level only. Figure 18-5 illustrates downstream scheduling and rate limiting at the LT,
which include the following elements:
• OMCI queue
• voice queue
• multicast traffic spacer
• ONT rate shaper
• GPON SP/WFQ scheduler

18 — QoS
Figure 18-5 Downstream scheduling and rate limiting at the LT
OMCI SP
Voice SP
Multicast
traffic R WFQ
spacer
Queue 0
ONU1 SP/
... R WFQ
Queue 7 WFQ
ONT 1 rate shaper

Packet GPON GPON
dispacher SP/WFQ
Queue 0 scheduler
ONU2 SP/
... R WFQ
Queue 7 WFQ
ONT 2 rate shaper

...
Queue 0
ONU64 SP/
... R WFQ
Queue 7 WFQ
ONT 64 rate shaper
18982
OMCI queue
The OMCI queue consists of a single queue; the queue contains all downstream
communication from the P-OLT to the ONT. The input to the queue originates solely
from the LT card processor. The fill rate is never expected to exceed 10 Mb/s.
Voice queue
The voice queue is optional. Voice can have a global queue at the GPON level, or
can be provisioned to have a queue at the ONT level.
Multicast traffic spacer

The multicast traffic spacer consists of a single queue. Because a guaranteed portion
of the PON bandwidth is provisionally reserved for multicast service (see Reserved
bandwidth), and because the number of IP multicast streams is provisioned per ONT,
there is no need to rate limit multicast on an ONT level. Therefore, multicast is rate
limited on a PON basis.

18 — QoS
ONT rate shaper
The traffic management module on the LT card provides 64 rate shaper blocks per
PON interface, one for each ONT. Within each rate shaper block are eight queues,
with a flexible scheduling mechanism (SP or WFQ) for each queue. Each queue is
configurable for scheduler weight, and for maximum and guaranteed buffer sizes to
limit the depth of the queue.
A queue operates with a tail drop discard mechanism. If the queue size reaches the
configured maximum buffer size, or if the buffer pool has no remaining buffer space,
arriving packets are dropped until the queue has room to accept the packets.
The LT supports fully provisionable rate limiting at the following levels within the
rate shaper block to guarantee bandwidth fairness between different ONTs, or
between services of one ONT:
• per-ONT rate shaping—shaping of aggregate bandwidth of all the services or
flows provisioned on the ONT
• per-service rate shaping—shaping of the individual bandwidth of each service or
flow provisioned on the ONT. This mechanism provides finer granularity than the
per-ONT rate limiting. However, the per-ONT rate limiting is suitable for certain
applications, such as business services, where typically a complete, transparent
bandwidth pipe is allocated to the enterprise as a whole.
Capabilities are provided to configure this behavior on the level of the individual
ONT. The RATELIMITOPT parameter of the ENT-ONT TL1 command indicates
the type of downstream rate-limiting choice for a dedicated ONT:
• The value ENABLE means service-based downstream rate-limiting is in effect.
• The value DISABLE means ONT-based downstream rate-limiting is in effect.
These rate shaper blocks are fundamentally different for the two downstream rate
limiting approaches.
• Per-ONT rate shaping provides aggregate rate limiting capabilities. A per-ONT
downstream rate limiting scheduler maps traffic to queues based on p-bits, and
specifies the scheduler weights and sizes of the individual queues in the per ONT
rate shaper. The output of each scheduler is rate limited based on the aggregated
EIR bandwidth. The rate limit is the sum of the EIRs from the downstream
bandwidth profiles that are assigned to each service or flow activated on the ONT.
Figure 18-6 illustrates downstream rate limiting on a per-ONT basis.
• Per-service rate shaping provides rate limiting capabilities per individual queue.
Each service or flow is mapped to a different queue; p-bits are ignored in the
queuing process. A per-service downstream rate limiting scheduler specifies the
scheduler weight and size of the service queue. Each service is rate limited to its
respective EIR. Figure 18-7 illustrates downstream rate-limiting on a per-service
basis.
Note 1 — A per-service downstream rate limiting scheduler can also
disable rate limiting for the service, while enabling queuing and
scheduling for the same service.
Note 2 — Per-service downstream rate limiting scheduler is
supported by the GLT8 and GLT4 cards, but not by the GLT2 cards.

18 — QoS
Figure 18-6 Per-ONT downstream rate limiting
LT ONT
Packets are queued by p-bit.

GEM p-bit
port
0
1
MAC 1 1 256
VLANx
2 256 1
MAC 1 2 257
VLANx MAC 1 1 257 2 ENET1 MAC 1
MAC 2 2 258
VLANx MAC 1 2 3
MAC 2 3 259 VLANy
VLANy MAC 2 2 258 2
X 4
VLANy MAC 2 3 259 3 ENET2 MAC 2
VLANz MAC 3 6 5
VLANz
VLANz MAC 3 7 260 6
6 VOIP
MAC 3 6 260 261 7 MAC 3
7
MAC 3 7 261
Per-ONT downstream rate-limiting
scheduler specifies queue sizes
and scheduler weights.
The per-ONT downstream rate limiting scheduler profile
includes a configurable p-bit to queue mapping.
19960
Figure 18-7 Per-service downstream rate limiting
LT ONT
MAC 1 1 256
0 GEM p-bit
MAC 1 2 257 port
MAC 2 2 258 1
MAC 2 3 259
VLANx
VLANx MAC 1 1 256 1
MAC 3 6 260 2
VLANx MAC 1 2 257 2 ENET1 MAC 1
MAC 3 7 261
VLANy MAC 2 2
X VLANy
3
VLANy MAC 2 3 258 2
VLANz MAC 3 6 259 3 ENET2 MAC 2
4
VLANz MAC 3 7 VLANz
5 260 6
VOIP
261 7 MAC 3
6
7
Per-service downstream rate-limiting
Packets are directed scheduler specifies individual queue size
to queues by service. and scheduler weight.
19961

18 — QoS
GPON SP/WFQ scheduler

The GPON SP/WFQ scheduler has eight queues and operates in a combination of SP
and weighted fair queuing (WFQ) for the inputs to the scheduler.
• The OMCI and voice (if any) queues are treated as SP with the OMCI queue
having a higher priority than the voice queue.
• Multicast packets are scheduled in WFQ fashion. The weight is calculated based
on provisioned GPON multicast bandwidth.
• The input from each of the 64 individual ONT or per-service shapers is scheduled
in WFQ fashion, and given a weight that is calculated in software. The weight
calculation is based on the sum of the CIR bandwidth values specified in the
downstream bandwidth profiles of each service or flow that is activated on the
ONT.

A priority queue profile defines up to eight priority queues; each queue represents a
GEM port in a T-CONT that carries traffic across the GPON from the ONT to the
LT. After tagging is complete, traffic is directed to one of the GEM ports.
The number of available GEM ports per ONT UNI (22, with 3 reserved for internal
use for a maximum of 19) limits the number of priority queues that can be used for
each service on the ONT UNI. For example, if 8 priority queues are used per HSI
service, there are not enough GEM ports available to have a third HSI service with 8
queues.
The priority queue profile includes the scheduling weight of each priority queue, and
the distribution of p-bits to the priority queues. The weight directs the scheduling of
queues at the ONT as described in Table 18-5; the p-bit mapping directs
priority-marked service traffic to a priority queue.
Table 18-5 Upstream scheduling of queues at the ONT by weighting factor
Weight Scheduling
Queue with a weight of 0 SP
Queue with a weight of 1 to 255 with 255 being lowest WRR

priority. Queues with a lower number have a higher
weighting, e.g. a queue with a weight of 155 gets
processed later than a queue with weight 55.
Priority queue profiles are applied to flows and traditional services on an ONT UNI
port.

18 — QoS
T-CONTs and GEM ports

T-CONTs are traffic containers for GEM ports. A GEM port is a virtual port that is
used to transport data across the PON from the LT to the ONT and from the ONT to
the LT. Each GEM port has an identifier (GEM port ID) that is unique to a PON port.
Up to 512 T-CONTs can be supported per PON port. Each T-CONT can support up
to eight GEM ports.
After tagging frames, the 7342 ISAM FTTU segregates frames into GEM ports, and
GEM ports into T-CONTS depending on how the services are configured.
Table 18-6 identifies the T-CONT models supported by the 7342 ISAM FTTU and
the service configurations to which they apply.
Table 18-6 T-CONT models
T-CONT model EVC and Ethernet service Traditional service

configuration configuration (HSI,
CES PW, CESOIPPW, VoIP,
DSL2)
T-CONT per EVC model ✓
T-CONT per CoS model ✓
T-CONT per service model ✓
T-CONT per subscriber/per service ✓ ✓

model
The T-CONT models are described in the following sections. For more information
about tagging, see Chapter 21 on VLANs and VPNs.
T-CONT per EVC model
The T-CONT per EVC model allows multiple services for a single subscriber to
share the same T-CONT. In this model, a T-CONT is dedicated to an EVC, and an
EVC is dedicated to a subscriber. A T-CONT is represented by a portal, and can be
shared across multiple services for a subscriber. Each GEM port is associated with a
service bound to the T-CONT.
On an ONT UNI port, a flow can be defined by any combination of VLAN ID, p-bits,
and number of tags. The service is allocated a set of GEM ports. After tagging is
performed, upstream frames having the specified number of tags, and the same p-bit
and VLAN ID in their outer tag are directed to the same GEM port. GEM ports
having the same VLAN ID are grouped together with the same T-CONT.
T-CONT per CoS model
The T-CONT per CoS model allows multiple services for different subscribers to
share the same T-CONT. In this model, a T-CONT can be shared across multiple
ONT UNIs on the same ONT; a GEM port is uniquely identified by an ONT UNI
port, VLAN ID, and p-bit.
After tagging is performed, upstream frames having the same ONT UNI, and p-bit
and VLAN ID in their outer tag, are directed to the same GEM port. GEM ports
having the same p-bit are grouped together with the same T-CONT.

18 — QoS
T-CONT per service model
The T-CONT per service model allows multiple subscribers of the same service to
share the same T-CONT. In this model, a T-CONT maps to one service on the PON;
each GEM port maps to a single subscriber of the service. In this model, the T-CONT
can be shared across multiple ONT UNIs on the same ONT. The model obtains
maximum subscriber scalability on the PON and allows efficient use of the GPON
TC layer.
After tagging is performed, upstream frames are directed to a GEM port based on the
ONT UNI, p-bit, and C-VLAN ID. GEM ports having the same C-VLAN ID are
grouped together with the same T-CONT.
Figure 18-8 illustrates the T-CONT per service model.
Figure 18-8 T-CONT per service model
OLT PON ONT
Tag GEM GEM Tag Tag

UNI
Tag GEM GEM Tag Tag
T-CONT T-CONT WRR
Tag GEM GEM Tag Tag
UNI
Tag GEM GEM Tag Tag
Uplink
Tag GEM GEM Tag Tag

UNI
Tag GEM GEM Tag Tag
T-CONT T-CONT WRR
Tag GEM GEM Tag Tag
UNI
Tag GEM GEM Tag Tag
20070
T-CONT per subscriber/per service model
In the T-CONT per subscriber/per service model, a T-CONT is reserved for a single
service on a single ONT UNI, with a GEM port for each priority queue within the
service.
When a service is created, the 7342 ISAM FTTU creates autonomous instances of a
T-CONT and GEM ports, and associates them as follows:
• the T-CONT is associated with the priority queue profile of the service
• each queue in the priority queue profile is associated with a unique GEM port; the
GEM port inherits the same p-bits as the queue
Where more than one service is configured on the same ONT UNI port, multiple
T-CONTs support traffic from the ONT UNI port. However, because the number of
GEM ports across the ONT UNI port cannot exceed eight, the operator must ensure
that each priority queue profile uses fewer than eight queues.

18 — QoS
After frames are tagged, frames are directed to GEM ports based on their p-bit.
Figure 18-9 shows the relationships among the elements.
Figure 18-9 T-CONTs and GEM ports
Where more than one service is configured,

multiple T-CONTs can support traffic
across an ONT UNI port.
Priority
ONT UNI queue
ONT port Service T-CONT
profile
A priority queue
profile has one to
eight queues.
An ONT UNI port can A T-CONT
have a maximum of A p-bit maps contains
eight GEM ports. to one queue. one to eight
P-bit GEM ports.
mapping Queue
Each queue has its own

GEM port; the GEM port
takes on the same p-bit
as its queue.
GEM
port
One-to-one mapping
One-to-many or many-to-one mapping
19473
Figure 18-10 illustrates the T-CONT per subscriber/per service model.
Figure 18-10 T-CONT per subscriber/per service model
OLT PON ONT
Tag GEM GEM
T-CONT T-CONT
Tag GEM GEM
UNI
Uplink
Tag GEM GEM

T-CONT T-CONT
Tag GEM GEM
20071

18 — QoS
GEM traffic descriptors

The OMCI is used by the OLT to control an ONT. This protocol allows the OLT to:
• establish and release connections across the ONT
• manage the UNIs at the ONT
• request configuration information and performance statistics
• autonomously inform the system operator of events such as link failures
The OMCI protocol is asymmetric: the controller in the OLT is the master and the
one in the ONT is the slave.
The 7342 ISAM FTTU implements OMCI in two modes to enable multi-vendor
interoperability between the OLT and the ONT:
• proprietary mode
• non proprietary (standard) mode to support GEM port network CTP as per 984.4
standard; this mode is supported on the 00160V-Q and the 00240V-Q and is not
planned to be supported on any single family ONUs
Traffic management using GEM traffic descriptors

As per the 984.4 standard, the GEM traffic descriptor is a management entity (ME)
that characterizes and regulates upstream and downstream traffic flows identified by
a GEM port ID or MAC bridge port on the ONT side.
The OLT creates GEM traffic descriptors for upstream and downstream traffic flows
based on the option attribute value of the ONT-G traffic ME.
• If the option attribute value is one or two, non proprietary mode is assumed and
a GEM traffic descriptor ME is created and associated with GEM port network
CTP.
• If the option attribute value is zero, proprietary mode is assumed and no GEM
traffic descriptor is created.
The mandatory and the optional parameters of this ME include:

• managed entity ID
• committed information rate (CIR)
• peak information rate (PIR)
• committed block size (CBS)
• peak block size (PBS)
• color mode
• ingress color marking
• egress color marking
• meter type

18 — QoS
The implementation of GEM traffic descriptors provide a more granular level of QoS
to access nodes in support of open access services.
• The OLT rate limits traffic at the T-CONT or portal level on the OLT side using
DBA mechanism.
• The ONT rate limits traffic at the service flow level using the GEM traffic
descriptor on the ONT side.
Configuration considerations
After an HSI service or service flow is created, the OLT creates GEM traffic
descriptors as follows, if the option attribute value of the ONT-G traffic ME is one
or two.
• If the subscriber service uses the same bandwidth profile for both upstream and
downstream traffic, the OLT creates one GEM traffic descriptor for the
subscriber service.
• If the subscriber service uses different bandwidth profiles for upstream and
downstream traffic, the OLT creates two GEM traffic descriptors for the
subscriber service.
The OLT uses the values in the bandwidth profiles of the subscriber service to set the
PIR, CIR, CBS, and PBS values in the GEM traffic descriptor. If the option attribute
of the ONT-G ME is one (which means rate controlled only) or two (which means
priority and rate controlled), the traffic descriptor ME instance is set up with the
following values:
• The OLT sets the PIR to the EIR value in the bandwidth profile.
• The OLT sets the CIR to the CIR value in the bandwidth profile.
• The OLT sets the CBS and PBS to a default value of zero.
Note — Since the bandwidth values at the OLT are configured at the
per-flow level (and not at the per-GEM port level), the operator
should ensure that a single GEM port is configured per HSI service or
service flow for this feature to work.
18.6 Traffic shaping elements
An integral part of traffic shaping is the optimization of bandwidth to reduce the

burstiness of traffic.
Traffic shaping elements described in this section are:
• PON bandwidth
• Bandwidth profile
• Reserved bandwidth
• Dynamic bandwidth allocation (DBA)

18 — QoS
PON bandwidth
The bandwidth available on the PON can be considered when configuring the system
for maximum performance. The following information is available for a specific
PON:
• aggregate upstream provisioned CIR
• aggregate upstream provisioned AIR
• guaranteed upstream bandwidth that remains for further provisioning
• aggregate downstream provisioned CIR
• guaranteed downstream bandwidth that remains for further provisioning
• maximum downstream multicast bandwidth allowed
The operator can use this information to determine how much bandwidth is left to
allot in the upstream or downstream direction.
Bandwidth profile
A bandwidth profile specifies the bandwidth characteristics of ONT services.
Bandwidth profiles allow you to:
• engineer your network resources to provide performance assurances
• offer bandwidth to subscribers in increments less than the UNI speed
• offer multiple service instances per UNI and each service can have its own
bandwidth profile
Bandwidth characteristics include the following traffic parameters:

• CIR
• AIR
• EIR
• DT
The CIR guarantees a committed bandwidth under peak demand conditions, and the
EIR guarantees superior service when network utilization is low. The DT specifies
the longest delay between two upstream grants for the service. The upstream
granting rate may be more frequent than what the DT specifies if the bandwidth
requires it.
Bandwidth profiles can be applied to a portal, a flow, or a service. When the
bandwidth is applied to a portal or a service, the bandwidth profile provides the
bandwidth requirements for the T-CONT. When the bandwidth profile is applied to
a flow, the bandwidth requirements for the T-CONT are calculated by adding the
bandwidth of the individual flows in the portal.

18 — QoS
The bandwidth characteristics provide input to the following processes:

• DBA requires CIR, AIR, and EIR to allocate upstream bandwidth.
• CAC requires CIR, AIR, and EIR to check for the availability of bandwidth when
a new service is added to a GPON or S-VLAN.
• You must consider the EIR of the services to set threshold levels for queues when
configuring downstream rate-limiting schedulers.
• The delay tolerance parameter determines the upstream grant frequency to
achieve provisioned maximum delay variation (DT).
The AIR and DT have no significance in the downstream direction.
Reserved bandwidth
Multicast traffic is forwarded downstream to a single GEM port ID and is not
replicated on the GPON. The bandwidth required for multicast traffic is reserved at
the GPON level to ensure that multicast traffic is accounted for in the CAC check.
Dynamic bandwidth allocation (DBA)

DBA is the process by which ONTs and their associated T-CONTs request upstream
bandwidth and whereby the P-OLT re-assigns bandwidth accordingly. The P-OLT
allocates upstream bandwidth on a T-CONT basis, and not on a GEM port, queue, or
VLAN priority basis. The characteristics of the T-CONT determine the quality of
upstream traffic. VLAN priority affects traffic quality only indirectly.
The 7342 Dynamic Bandwidth Allocation (DBA) mechanism grants upstream
bandwidth to ONUs in increments of 32bytes. The guaranteed minimum bandwidth
assigned to an ONU by the DBA mechanism is derived from the CIR, AIR, and
Delay Tolerance (DT) values provisioned in the Bandwidth Profile for an HSI
service. The minimum bandwidth value is determined by comparing the BW profile's
provisioned CIR value to a calculated minimum bandwidth based on the BW
profile's provisioned DT value. The formula for calculating the minimum bandwidth
based on the BW profile's provisioned DT value is: DT_MinBW =[(8000
transmission time slots per second/Provisioned DT)*32 bytes]. Refer to Table 18-7.
If the upstream CIR and/or AIR bandwidth parameters defined in the HSI's BW
profile are configured less than the calculated DT_MinBW value, the
RTRV-PONBW command will display the calculated DT_MinBW value for the
UPCIR and UPAIR parameters. Otherwise the configured CIR and AIR values will
be displayed.
Table 18-7 MinBW for Delay Tolerance
MinBW Delay Tolerance Number
2048 Kbps 1
1024 Kbps 2
512 Kbps 4
256 kbps 8
128 Kbps 16
(1 of 2)

18 — QoS
MinBW Delay Tolerance Number
64 Kbps 32
32 Kbps 64
(2 of 2)
The 7342 ISAM FTTU supports DBA according to the ITU-T G.984.3
recommendation, which specifies four types of bandwidth and classifies T-CONTs
into five types of containers. A T-CONT is allocated one or more types of bandwidth
based on its container type.
Table 18-8 describes the bandwidth types and the order in which they are reserved.
Table 18-8 Bandwidth types
Bandwidth type Description Reservation

Priority
Fixed bandwidth Fixed bandwidth has the following characteristics: 1

• is entirely reserved and is cyclically allocated to achieve
a low cell transfer delay
• guarantees cell transfer delay, delay variation, and
transmission rate
Fixed bandwidth is treated as guaranteed bandwidth in the

CAC check.
Assured Assured bandwidth has the following characteristics: 2

bandwidth • means fixed average bandwidth over some specified time
interval. While fixed bandwidth guarantees cell transfer
delay, delay variation, and transmission rate, assured
bandwidth guarantees the average transmission rate
only.
• is always available to a T-CONT if the T-CONT has data to
transmit
• is available to other T-CONTs if the T-CONT does not
have data to transmit
Assured bandwidth is treated as guaranteed bandwidth in the

CAC check.
Non-assured Non-assured bandwidth is surplus bandwidth that a T-CONT 3

bandwidth can use, which is not committed to fixed bandwidth or
assured bandwidth.
Best effort Best effort bandwidth is surplus bandwidth that a T-CONT 4

bandwidth can use after all other bandwidth types have been assigned.
Fixed bandwidth is reserved first, including slot location to minimize delay and delay
variation. Assured bandwidth is reserved next with the remaining bandwidth.
Bandwidth that is still not reserved is released to the pool of surplus bandwidth for
non-assured bandwidth and best effort bandwidth, with non-assured bandwidth
having higher priority over best effort bandwidth.
The DBA does not allocate assured bandwidth until the P-OLT receives a bandwidth
request from the ONT. Therefore, assured bandwidth is available for best effort
traffic.

18 — QoS
The DBA allocates assured bandwidth explicitly through idle-cell monitoring.

• A part of AIR is always allocated to observe bandwidth demands.
• When bandwidth is granted, the T-CONT sends an idle cell to the P-OLT, if the
T-CONT has no upstream data to transport. The DBA reduces the bandwidth to
a minimum and re-assigns it to other T-CONTs that do not send idle cells.
The 7342 ISAM FTTU categorizes a T-CONT by container type based on the CIR,
AIR, and EIR requirements of the T-CONT, and allocates bandwidth to a T-CONT
according to its type. Table 18-9 describes the allocation of bandwidth by T-CONT
type and the corresponding bandwidth settings, and identifies the services to which
the T-CONT types are best suited.
Table 18-9 Allocation of bandwidth by T-CONT type
T-CONT type Bandwidth Bandwidth settings Suited to

Allocation
CIR AIR EIR
Type 1 Fixed bandwidth only >0 AIR = CIR EIR = CIR VoIP service and
T-CONT type 1 guarantees cell transfer CES
delay, delay variation, and transmission
rate. Upstream bandwidth is reserved and is
cyclically allocated with a fixed rate and
controlled cell transfer delay.
Type 2 Assured bandwidth only 0 >0 EIR = AIR VoIP service and
T-CONT Type 2 guarantees the average other services
transmission rate only. with a constant
bit rate and some
tolerance to
delay (1)
Type 3 Assured bandwidth and non-assured 0 >0 EIR > AIR VoIP service and
bandwidth other services
T-CONT type 3 has both assured bandwidth with a constant
and non-assured bandwidth, and is allocated bit rate and some
bandwidth up to its EIR amount as follows: tolerance to
delay (1)
• Assured bandwidth is fully allocated if
there is data waiting for assured
bandwidth.
• Non-assured bandwidth is allocated up
to the EIR amount in a WRR manner
across all T-CONTs that have assured
bandwidth and are requesting additional
bandwidth. The assured bandwidth
determines the weight.
Type 4 Best effort bandwidth only 0 0 >0 HSI service

T-CONT type 4 uses surplus bandwidth that is
not allocated to fixed, assured, and
non-assured bandwidth types. Each T-CONT
type 4 is allocated bandwidth equally up to
the maximum peak attainable bandwidth
(EIR) without any guaranteed bandwidth in a
round robin fashion.
(1 of 2)

18 — QoS
T-CONT type Bandwidth Bandwidth settings Suited to

Allocation
CIR AIR EIR
Type 5 Maximum bandwidth >0 AIR ≥ CIR EIR ≥ AIR Premium HSI
T-CONT type 5 is a mix of all service service (with
categories. The maximum amount of fixed, assured,
bandwidth that can be granted is allocated non-assured, and
to the T-CONT up to the EIR amount for all best effort
services contained in the T-CONT. bandwidth)
If assured bandwidth is not provisioned, that
is AIR is equal to CIR, then the difference
between EIR and CIR is treated as best effort
bandwidth and is allocated in a round robin
fashion up to the EIR amount.
(2 of 2)
Note
(1) T-CONT types 2 and 3 are suitable for VoIP and other services that have a constant bit rate and can tolerate some delay;
T-CONT types 2 and 3 are not suitable for CES.
When a service of T-CONT type 2, 3, 4, or 5 is configured, the system must allocate

a minimum bandwidth to observe bandwidth demands. For assured bandwidth, the
system performs the following:
• system allocates 128 kb/s in addition to any fixed bandwidth (CIR)
• if the amount of the idle cell is less than 128 kb/s, then the AIR bandwidth is
granted
• system deallocates assured bandwidth if the AIR bandwidth is not used after a
certain period of time
For a service of type T-CONT type 4, the system internally allocates a minimum
bandwidth to observe idle cells.
Table 18-10 describes how the DBA issues grants to T-CONTs based on a system of
prioritization:
Table 18-10 T-CONT prioritization
Priority Bandwidth
High Fixed bandwidth, which is represented by:

• CIR of T-CONT type 1
• CIR of T-CONT type 5
Medium high Assured bandwidth, which is represented by:

• AIR minus CIR of T-CONT type 2
Medium low Non-assured bandwidth, which is represented by:

• EIR minus AIR of T-CONT type 3
• EIR minus AIR of T-CONT type 5
Low Best effort, which is represented by:

• EIR of T-CONT type 4
• EIR minus AIR of T-CONT type 5 if CIR equals AIR

18 — QoS
The proper selection of grant size and delay tolerance are critical per service to meet
service level agreements, such as bandwidth guarantees, bounded latency, and
reduced packet loss.
18.7 QoS configuration
The following represents the workflow to implement QoS.

1 Configure traffic policing at network ports
2 Configure QoS at the NT
3 Configure QoS at the LT
4 Reserve bandwidth for multicast traffic
5 Configure QoS at the ONT
6 Configure QoS for the ONT UNI
7 Configure QoS for ONT services
Table 18-11 identifies the QoS elements by configuration task.
Table 18-11 QoS elements by configuration task
Task Element
Configure traffic policing at network ports Egress rate
Traffic meter
Traffic flow
Configure QoS at the NT P-bit to CoS mapping
Traffic scheduler at the NT
Configure QoS at the LT C-VLAN to S-VLAN p-bit translation

Traffic scheduler at the LT
Reserve bandwidth for multicast Reserved bandwidth
Configure QoS for the ONT Downstream hierarchical scheduler and rate
limiting
Configure QoS for the ONT UNI DSCP to p-bit mapping
Configure QoS for ONT services Bandwidth profile
UNI-side to network-side p-bit translation profile
VLAN configurations are required so that the 7342 ISAM FTTU can tag frames with
their VLAN ID and p-bit for QoS purposes. Table 18-12 identifies where VLAN
configuration information can be found in Chapter 21 on VLANs and VPNs.

18 — QoS
Table 18-12 VLAN configurations
VLAN configuration See
VLAN forwarding modes Section 21.3
VLAN models Section 21.4
VLAN tagging Section 21.5
Frame processing at the LT Section 21.7
Frame processing at the ONT Section 21.8
18.8 End-to-end downstream queuing and scheduling
The 7342 ISAM FTTU processes downstream traffic as follows:

• from the network (EMAN) to the NT
• from the NT to the LT
• from the LT across the GPON to the ONT
• from the ONT to the subscriber
Figure 18-11 illustrates downstream queuing from the EMAN to the subscriber.
Figure 18-11 Downstream queuing from EMAN to subscriber
ONT
NT A LT 1
10-Gb/s
eHCL GPON 1
Subscriber
1-Gb/s
1-Gb/s
IP network NT B
GPON 2
Queues for
service ports
10-Gb/s
Queues for
SHub ports eHCL PON interface ports
1-Gb/s
1-Gb/s
Queues for
LT interface ports
19337

18 — QoS
From the network (EMAN) to the NT

When a traffic meter is associated with a SHub port and traffic flow type, the flow of
traffic through the SHub port is monitored. The traffic meter controls the burst and
maximum transmission rate of network traffic entering the port on a per-flow basis.
When the traffic flow reaches the configured maximum ingress rate, excess traffic is
dropped.
From the NT to the LT

As packets are received from the network on the NT card, the 7342 ISAM FTTU
differentiates the packets by traffic class and directs the packets to an egress queue
on an LT-facing port.
Packets are in the queue awaiting transmission. The scheduler decides which queue
to take the next packet for transmission, and uses the traffic scheduler attached to the
physical port to make these scheduling decisions. If the physical port does not have
a traffic scheduler, the scheduler uses the system default traffic scheduler.
See Traffic scheduler at the NT for more information.
Each switch port on the NT features a hierarchical scheduler with up to eight queues.
SP and WRR scheduling are available. The traffic scheduler specifies the size and
priorities of the queues.
From the LT across the GPON to the ONT

The LT has two stages of downstream scheduling:
• scheduling stage associated with the internal switch, which is supported on the
GLT2 cards, as described in Downstream scheduling at the switch for GLT2
cards only
• hierarchical scheduling stage that allows ONT level scheduling and PON level
scheduling, which is supported on all LT card types except GLT2-A, and is
described in Downstream hierarchical scheduling and rate limiting
Downstream scheduling at the switch for GLT2 cards only

The GLT2 cards support eight queues in the downstream direction towards each
GPON interface.
The system mapping of p-bits to queues at the LT directs the queuing of traffic to the
GPON, where queue 0 is reserved for internal VLAN (4095) traffic, and p-bit 7 is
automatically mapped to the same queue as p-bit 6.
SP and WRR scheduling are available.
A system default traffic scheduler is available. A customized traffic scheduler can be
associated with the GPON interface port to specify the buffer size, scheduling
method, and priorities of the queues. See Traffic scheduler at the LT for more
information.

18 — QoS
Traffic backlog handling

In general, the LT is configured not to send a pause frame to any port, when it can
not process all the data frames received from the NT card. When a queue reaches its
maximum capacity as defined by its internal buffer size, the LT card uses the queue
management algorithm tail drop to drop arriving packets until the queue is free to
accept traffic. The 7342 ISAM FTTU performance monitoring function collects
information about the events.
The NT card does not normally send a pause frame to the LT. If the LT card receives
a pause frame, the pause frame is automatically generated.
Downstream hierarchical scheduling and rate limiting
In the downstream direction, the LT provides an ONT rate limitation feature that
limits the aggregate ONT traffic or the per-service traffic for each ONT, because the
ONT tends to receive more traffic from the GPON than its ONT UNI ports can
support.
• Per-ONT downstream rate limiting ensures that the ONT does not receive more
downstream traffic than the sum of the EIRs of all services or flows configured
on the ONT.
• Per-service downstream rate limiting rate limits the traffic to the EIR of the
service or portal.
OMCI, multicast traffic, and optionally voice are scheduled independently, and only
unicast traffic is accounted for in the per-ONT rate limiter. Each of the ONT rate
limiter provides eight QoS queues; the size (minimum guaranteed and maximum
allowed) of these queues is operator provisionable.
See Downstream hierarchical scheduler and rate limiting for more information.
From the ONT to the subscriber

In the downstream direction, the ONT terminates the GEM layer, extracts the
Ethernet packets, performs any VLAN and p-bit translation that is required (see
Chapter 21 for information about VLAN tagging), and forwards them into the right
downstream priority queue based on their p-bit. Figure 18-12 illustrates the queuing
and scheduling of downstream traffic at the ONT.

18 — QoS
Figure 18-12 Downstream queuing and scheduling at the ONT
ONT
Queue 0
Trusted/Untrusted
C Queue 1 Residential gateway
SP Ethernet/VDSL2 port
Ethernet
F
Queue 7
P-OLT GPON CES C

A DS1/E1 port
D Signaling
POTS phone
Bearer SP POTS port
OMCI E
OBC
A Downstream traffic B Ethernet traffic is C CES traffic has D POTS traffic is E OMCi has its F Only strict
is shaped at the queued based on its own queue. queued based own queue. priority
P-OLT/Aggregation Switch priority tags p-bit. on whether it is scheduling
and marked with p-bit. signaling or bearer. is done.
19323
The ONT may be receiving more data than its egress ports can support. A substantial
amount of data buffering is provided to absorb any data bursts until they can be
transported towards the subscriber. The UNI supports a SP scheduling mechanism in
the downstream direction to provide the right precedence to the highest priority
traffic, as all traffic types contend for the same UNI port.
Each ONT UNI port is equipped with up to eight queues. Ethernet traffic is assigned
to queues based on p-bit only, whereby the highest priority p-bit is allocated to the
highest priority queue. CES and OMCI traffic each have their own queue. Voice
traffic is segregated into two priority queues: one for signaling and the other for
bearer traffic. All queues are serviced in a SP manner.
18.9 End-to-end upstream queuing and scheduling
The 7342 ISAM FTTU processes upstream traffic as follows:

• from the ONT to the LT
• from the LT to the NT
• from the NT to the network (E-MAN)
Figure 18-13 illustrates upstream queuing from the subscriber to the EMAN.

18 — QoS
Figure 18-13 Upstream queuing from subscriber to EMAN
ONT
NT A LT 1
10-Gb/s
eHCL GPON 1
Subscriber
1-Gb/s
GPON 2
1-Gb/s
NT B
IP network
10-Gb/s
Queues for
eHCL NT interface ports
1-Gb/s
1-Gb/s
Queues for
SHub ports
19343
From the ONT to the LT

The ONT receives untagged, priority-tagged, single-tagged, and double-tagged
packets from a subscriber. On a packet basis, the ONT tags and marks the received
frames with their p-bit and C-VLAN ID based on the tagging requirements of the
ONT UNI port and the service or flow. See Upstream tagging at the ONT in
Chapter 21 for more information.
The ONT uses the Priority queue profile of the service or flow to map the p-bit to a
queue.
The ONT UNI port can support multiple priority queue profiles (traffic schedulers)
in the upstream direction, where each priority queue profile is allocated to an
individual service or flow on the UNI. The priority queue profile attached to a service
determines:
• how queues are scheduled
• how priority-marked service traffic is mapped to queues
An ONT UNI port is associated with an eight-queue scheduler. The scheduler can
perform SP or WRR scheduling on an individual queue. The relative weights of the
queues are configurable; SP is achieved by allocating a zero weight to the queues,
whereas a value between 1 and 255 will trigger WRR handling. See Priority queue
profile for more information.

18 — QoS
Each queue is associated with a GEM port. Packets are carried across the GPON in
the GEM port associated with the queue. The GEM port is contained in a T-CONT
(see T-CONTs and GEM ports). CES, voice, and OMCI are carried across the
GPON, each in their own T-CONT, separate from subscriber traffic.
Figure 18-14 illustrates upstream scheduling at the ONT.
Figure 18-14 Upstream scheduling at the ONT
Bandwidth
Allocation
Based on
Services
Provisioned
ONT
Priority 6, 5, 4
T-CONT Trusted/Untrusted
Priority 3 Residential gateway
A
E
SP/ Ethernet/VDSL2 port
T-CONT
WRR
Priority 0
OLT GPON CES D

T-CONT DS1/E1 port
Signaling
POTS phone
SP/
T-CONT WRR Bearer POTS port
B C
OMCI
T-CONT
A T-CONTs are assigned B Traffic schedulers C POTS traffic has a D CES traffic has E Ethernet traffic can
guaranteed and for a service dedicated T-CONT its own T-CONT. have one or more
dynamic BW by DBA. can be provisioned and is separated T-CONTs and each
to prioritize traffic into two queues T-CONT can support
based on strict priority for signaling and bearer. up to 8 queues.
(SP) or weighted round
robin (WRR) or combination
of the two.
19324
The LT card is equipped with a granting engine called a DBA scheduler. The DBA
is associated with only one GPON and allocates bandwidth to specific T-CONTs
based on their type. For information on the allocation of bandwidth by T-CONT
type, see Table 18-9.
From the LT to the NT

In the upstream direction, the P-OLT performs a concentration function. The
network bandwidth of network links (GEM ports) is less than the bandwidth of LT
ports. Some statistical multiplexing is occurring based on the assumption that not all
subscribers are sending traffic at the same time.

18 — QoS
On a packet basis, the LT tags and marks the received frames with their p-bit and
S-VLAN ID based on the tagging requirements of the service VLAN on the PON.
See Upstream tagging at the LT in Chapter 21 for more information.
The LT supports eight queues in the upstream direction towards each NT-facing port.
The system-wide mapping of p-bits to queues, which is configured for the LT, directs
the queuing of traffic, where queue 0 is reserved for internal VLAN (4095) traffic
and p-bit 7 is automatically mapped to the same queue as p-bit 6.
SP and WRR scheduling are available.
A customized traffic scheduler can be applied to individual NT-facing ports to
specify the buffer size, scheduling method, and priorities of their queues. A system
default traffic scheduler is automatically generated. See Traffic scheduler at the LT
From the NT to the network (E-MAN)

The NT supports up to eight queues in the upstream direction towards each SHub
port. SP and WRR scheduling are available.
A customized traffic scheduler can be attached to a SHub port to specify the size and
scheduling priorities of its queues. See Traffic scheduler at the NT for more
information. If a traffic scheduler is not configured for a port, the system default
traffic scheduler is automatically used.
The system monitors a SHub port for egress rate. When the traffic flow rate reaches
the configured maximum egress rate, excess traffic is dropped.
18.10 Multicast bandwidth considerations
To provide an efficient implementation of multicast traffic, the 7342 ISAM FTTU

platform supports IGMP snooping at the ONT, and IGMP proxy functionality at the
OLT. With this mechanism, identical streams requested by the same or even different
subscribers on the same PON are never duplicated on the PON link.
Further multicast bandwidth optimization is achieved by the “dynamic reservation”
of multicast bandwidth. At provisioning, the operator defines the maximum PON
bandwidth required. The system performs a dynamic CAC check each time an
additional multicast stream is sent downstream the PON. If the provisioned PON
multicast bandwidth is not fully utilized, the remainder, that is, the pre-provisioned
minus the actual bandwidth, is released to the bandwidth pool where it can be
consumed by other services as best-effort bandwidth.
Provisioning includes creation of an IGMP signaling channel for each subscriber and
associating the channel with the subscriber’s HSI service or service flow. For each
channel, the IGMP protocol version, maximum multicast bandwidth, maximum
number of streams, maximum number of hosts and maximum message rate is
defined.
As stated by ITU-T G.984, the multicast streams are delivered over a dedicated
multicast GEM port ID (4095).

18 — QoS
18.11 Recommended DSCP to p-bit mapping
Although the DSCP allows for 64 possible forwarding behaviors, the DiffServ model
aggregates traffic into four standard per-hop behaviors, which provide eight
forwarding classes; see Table 18-13.
Table 18-13 Forwarding classes
Per-hop behavior Forwarding class
Best effort BE
Assured forwarding AF-1

AF-2
AF-3
AF-4
Expedited forwarding EF
Class selector CS-1
CS-2
Table 18-14 lists the Alcatel-Lucent recommended DSCP and p-bit mapping for the
optimal CoS treatment in a triple play network.
Table 18-14 Recommended CoS mapping
DSCP Binary DSCP P-bit Forwarding Traffic type Scheduling

Number Class type
000000-000111 0 to 7 0 BE Ethernet data WRR
001000-001111 8 to 15 1 AF-1 —
010000-010111 16 to 23 2 AF-2 —
011000-011111 24 to 31 3 AF-3 ICMP
100000-100111 32 to 39 4 AF-4 Multicast data
101000-101111 40 to 47 5 — Voice signaling, SP

IGMP, DHCP, and
other control
101110 46 6 EF Voice-bearer
101110 46 6 EF CES
110000-110111 48 to 55 6 — —
111000-111111 56 to 63 7 — —
110000 48 6 CS-1 —
111000 56 7 CS-2 OMCI

19 — Statistics and performance
monitoring
19.1 Overview 19-2
19.2 Statistics, counters, and performance monitoring 19-2
19.3 P-OLT performance monitoring statistics counters 19-7
19.4 RMON Ethernet statistics support for the P-OLT 19-15

19.1 Overview
This chapter provides a detailed description of the 7342 ISAM FTTU statistics and
performance monitoring features.
TL1 and CLI for statistics and performance monitoring related procedures.
19.2 Statistics, counters, and performance monitoring
Statistics counters and reports are available for collecting operational statistics for
the 7342 ISAM FTTU. The statistics counters and reports are useful for monitoring
and for troubleshooting the performance of 7342 ISAM FTTU components and
network connections. Status reports display information in a static format, whereas
counters track the number of occurrences of statistics parameters dynamically.
Performance monitoring is performed at the P-OLT and at ONT units. See the
7342 ISAM FTTU ONT Product Information Manual for information about statistics
supported on ONT units.
Operators can view system statistics and monitor performance using a TL1, CLI, or
an element management system (EMS) management session with the P-OLT. Use
the TL1 interface to enable counters and to set filters. You must use a remote
monitoring (RMON) SNMP manager to access RMON statistics. See section 19.4
for information about RMON statistics support on the 7342 ISAM FTTU.
The 7342 ISAM FTTU has the following types of statistics collecting counters:
• 15-min counters
• 5-min counters
• rolling counters
Note 1 — Threshold crossing alarm (TCA) is not supported on rolling

counters. See chapter 13 for information about TCA-related alarms
and performance statistics.
Note 2 — When the system date changes; for example, due to the
move to daylight savings time, performance statistics collection is
affected and an interval is either repeated or lost.
Statistics collection for voice over IP (VoIP) calls at the ONT is also available. See
the 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1
and CLI for VoIP call statistics information.

15-min counters
The 7342 ISAM FTTU uses 15-min counters to collect statistics continuously in
15-min intervals. The P-OLT collects and maintains all performance monitoring
statistics for retrieval upon request. When a counter is enabled using TL1, the system
starts counting statistics occurring over a 15-min period and records the number as
an integer in a log file. A total of 32 15-min intervals occurring over an 8-hr period
are logged. After the 8 hr has elapsed, new 15-min intervals overwrite the oldest
entry recorded in the log file. If a command to retrieve performance statistics
includes the current 15-min interval, a snapshot of the count at the time of the
retrieval request is provided. The 15-min counters are disabled by default.
Note 1 — During an LT unit initialization, the current count of the
first 15-min interval may be forced to restart due to the
synchronization procedure between the LT unit on the P-OLT and the
ONT.
Note 2 — Alcatel-Lucent recommends that users should wait for 30
seconds after the expiration of an interval before retrieving last
interval counts. This ensure reliable results as synchronization is then
correct between the P-OLT and the ONTs.
Note 3 — A maximum of 31 counters can be active at the same time
on each GPON, or for each service type configured on the same
GPON interface port on the LT card. An alarm is raised when the
number of simultaneous counters exceeds the limit.
Table 19-1 lists the 15-min counters the 7342 ISAM FTTU uses to collect
performance monitoring statistics.
Table 19-1 15-min counters
Counter description P-OLT ONT
QoS at the LT ✓
TC-layer of the gigabit passive optical network (GPON) connection ✓ ✓
SHUB and NT port ✓
VLAN traffic ✓ ✓
LT bridge port ✓
IGMP counters ✓
Backplane errors ✓
CES PW counters ✓
CES UNI counters ✓
ONTENET counters ✓
ONTL2UNI counters ✓
ONTMOCA counters ✓
PONONTTC (aggregate) counters ✓
PONONTTC counters ✓
PONONTBCTC counters ✓
(1 of 2)

Counter description P-OLT ONT
PONONTMCTC counters ✓
PONONTTCCES counters ✓
PONONTTCFLOW counters ✓
PONONTTCHSI counters ✓
PONONTTCVOIP counters ✓
X/VDSL bearer/channel counters ✓
X/VDSL line counters ✓
(2 of 2)
Figures 19-1 and 19-2 show some of the collection points of performance monitoring
statistics 15 minute counters.
Figure 19-1 Collection points for frame statistics
LT PON ONT
Bridgeport = UNI POTS UNI

IWF
GPON POTS
BP GPON MAC client
I/F MAC
Ethernet/
NT_A xDSL UNI
Bridge PON Service
NT_B Service
Ethernet/
xDSL UNI
Service
Ethernet frames GEM frames Ethernet frames

22341

Figure 19-2 Collection points for network port, VLAN, and SHub statistics
On-Board Controller Memory, Power Mgmt,

(OBC) BITS input, ...
EMAN SHUB Backplane

interfaces interfaces
1-GE eHCL to LT_1

48 Gb Ethernet Switch
1-GE 20 * 1 GE ports
eHCL to LT_9
1-GE to peer NT
(unused)
1-GE to peer
RTR NT LT
1-GE eHCL to LT_10
48 Gb Ethernet Switch
20 * 1 GE ports ONT
eHCL to LT_14
CPE
to
(unused) ACU
Port Network SHUB LT ONT

statistics statistics
VLAN statistics (NT, LT, PON)
22342
See the 7342 ISAM FTTU ONT Product Information Manual for information about
15-min counters supported on ONT units. When you retrieve performance statistics,
you can use filters to define the scope of statistics that are collected for viewing. All
statistics within the specified range are retrieved from the log file. Depending upon
the type of statistic you are retrieving, you can set filters to define any combination
of the following:
• selected group of statistical parameters
• date range
• time range
• direction (Tx or Rx)
• location (near-end or far-end)
• count thresholds
See the 7342 ISAM FTTU TL1 Commands and Messages Reference document for
the command syntax of filters and which filters are supported for the different types
of 15-min counters. You can set TCA thresholds for 15-min counters using TL1 for
frame statistics (Fig 19-1) and CLI for network port, VLAN and SHub statistics
(Fig 19-2). If the number of events occurring within a 15-min period exceeds the
specified threshold, a TCA alarm event is raised in the system. See chapter 13 for
information about TCA-related alarms and performance statistics. See the
7342 ISAM FTTU TL1 Commands and Messages Reference and the
7342 ISAM FTTU CLI Commands Guide for details about restrictions for the use of
statistics collecting counters and TCA support.

Rolling counters
Rolling counters start at zero and count up to a maximum value. When the maximum
value is reached, the counter restarts at zero. No logs are maintained for rolling
counters and TCA is not supported. You can enable and disable rolling counters
using TL1. When a counter is enabled, you can retrieve the current count using a TL1
or an EMS management session with the P-OLT. A snapshot of the current value in
the rolling counter is displayed as an integer.
Table 19-2 lists the rolling counters the 7342 ISAM FTTU uses to collect
performance monitoring statistics.
Table 19-2 Rolling counters
Counter description P-OLT
IGMP per user channel ✓
IGMP per LT card ✓
IGMP multicast sources ✓
VLAN-based traffic ✓
There are restrictions as to how many rolling counters you can enable
simultaneously. Also, some rolling counters can be set to automatically reset to zero
after being retrieved. See the 7342 ISAM FTTU TL1 Commands and Messages
Reference document for restrictions, maximum count ranges, and the resetting of
rolling counters.
Status reports
Status reports are available for the following:
• 802.1 end-user or operator authentication
• LAGs
• residential bridges
See the 7342 ISAM FTTU TL1 Commands and Messages Reference document for
statistical parameters that are displayed in status reports.

Monitoring thresholds and levels

For many performance management statistics retrieved using TL1, some or all of the
following filter criteria apply. With a filter applied, only a matching subset of
statistics counters are collected and displayed.
1 Monitoring level using the monlev parameter values [level, direction]. Only
monitored values that meet the threshold specified are displayed. Where level is
the threshold level and is an integer value (0...4294967295) and direction is a
direction UP or DN. 1-UP is the default.
When the level is >=0, the value represents the threshold of stats counter to show.
When the direction is UP or DN, the value represents increase/decrease from
threshold for counter to show.
For example, a configuration of [5,UP] would show only counters with values
>=5, while a configuration of [10,DN] would show only counters with values
<=10.
2 Facility location using the locn parameter values [NEND, FEND]. Where NEND
if near end and FEND is far end.
3 Direction using the dirn parameter values (TX or RX) for the transmit or receive
direction.
4 Monitoring period of either 15 minutes or 1 hour intervals.
19.3 P-OLT performance monitoring statistics counters
The 7342 ISAM FTTU supports the following performance monitoring statistics
counters for the P-OLT:
• GPON TC-layer and errored fragments
• LT bridge port
• Network port statistics
• VLANs
• IGMP (for user channel, LT card, and multicast sources)
• backplane errors (LT to NT communication)
You can view statistics collected for the P-OLT using a TL1, CLI, or an EMS
management session with the P-OLT. To enable and disable counters, use TL1.
Counters are disabled by default unless indicated otherwise. For 15-min counters,
you can use filters to define the scope of statistical data retrieved from the log file.
Some counters have restrictions for the total number that you can activate at the same
time. See the 7342 ISAM FTTU TL1 Commands and Messages Reference document
for information about filters and restrictions that apply.
GPON-TC layer and GEM errored fragment statistics

Table 19-3 describes the GPON TC-layer and GPON errored fragment counters that
support OLT performance monitoring statistics on the 7342 ISAM FTTU. These
statistics cannot be collected on HPNA ONTs.

Table 19-3 7342 ISAM FTTU supported OLT GPON TC-layer performance monitoring counters
Counter type Interval Montype Counter description
PONOLTTC 15 min TXBLOCKS Transmitted GEM blocks upstream. A GEM block is a fixed
PONOLTMCTC 48-byte data chunk of payload at the ONT PON interface for the
specific ONT or service. A discrepancy in GEM block statistics on
PONOLTBCTC the OLT and ONT may indicate a PON transmission problem.
PONOLTTCHSI
TXFRAGS Transmitted GEM fragments upstream. This indicates
PONOLTTCONT
fragmented or unfragmented GEM frames at the ONT PON
PONOLTTCFLOW interface for the specific ONT or service.
PONOLTTCCES
RXBLOCKS Received GEM blocks downstream. A GEM block is a fixed
PONOLTTVCVOIP 48-byte data chunk of payload at the ONT PON interface for the
PON-level statistics specific ONT or service. A discrepancy in GEM block statistics on
provide GEM the OLT and ONT may indicate a PON transmission problem.
counters at the ONT
and OLT side which RXFRAGS Received GEM fragments downstream.This indicates
allows comparison of fragmented or unfragmented GEM frames at the ONT PON
Tx/Rx traffic interface for the specific ONT or service.
between the OLT
LOSTFRAGS Transmitted and received lost GEM fragments downstream and
and ONT and can
upstream. May indicate errored fragments. May impact
help verify the
customer service traffic.
transmission quality
of the PON. BADGEMHDRS Received malformed GEM fragments downstream by the ONT.
Indicates an issue with the transmission medium or hardware.
ERRFRAGSPON Received errored GEM fragments.
VLAN statistics
For wide-scale deployment scenarios, when troubleshooting a service outage it is
useful to narrow the statistics collection down to the per VLAN level, rather than at
the SHUB or NT level. This also depends on whether the VLAN per service or
VLAN per subscriber model is used.
VLAN performance monitoring statistics are collected on the NT (toward the
network and toward the LT) and on the LT (toward the NT and toward the PON) You
can filter these statistics based on the LT slot or NT port, and by:
• source (scr) or destination (dst) MAC address
• CVLAN ID
• p-bits
Table 19-4 describes the VLAN counters that support OLT performance monitoring
on the 7342 ISAM FTTU.

Table 19-4 7342 ISAM FTTU supported VLAN performance monitoring counters
rept-opstat-vlanpm 15 min NtIngresFromNet Total frames ingressing the NT from the network side.
Enable the VLAN
NtIngresFromLt Total frames ingressing the NT from the LT side.
performance
monitoring statistics LtIngresFromPon Total frames ingressing the LT from the PON side.
collection first using
the set-opstat-vlanpm LtIngresFromNt Total frames ingressing the LT from the NT side.
command as shown in
the 7342 ISAM FTTU
Operations and
Maintenance
Procedures Guide using
TL1 and CLI
LT bridge port statistics

The bridge port on an LT is a logical interface that maps to an ONT UNI. Statistics
can be used to see whether packets are flowing from the LT towards the PON for the
bridge port, whether packets are coming off the PON to the LT, and whether packets
are discarded on the LT. Table 19-5 describes the LT bridge port counters that
support OLT performance monitoring statistics on the 7342 ISAM FTTU
Table 19-5 7342 ISAM FTTU supported OLT LT bridge port performance monitoring counters

BRGPORT 15 min BYTEDISCDN, Bytes dropped at the LT that were to be sent towards
The Ethernet byte and BYTEDISCUP the UNI and from the UNI towards the LT. Cannot be
frame counters at the (Discarded bytes) collected without collecting the discarded frames
LT bridge port can be counter.
correlated to the
FRMDISCDN, Ethernet frames dropped at the LT that were to be sent
counters at the L2 UNI.
FRMDISCUP towards the UNI and from the UNI towards the LT. This
Discarded traffic can
(Discarded frames) impacts customer service traffic.
also occur at the PON,
in which case GEM-level BYTEFWDDN, Bytes sent from the LT toward the UNI and from the UNI
performance BYTEFWDUP toward the LT. Cannot be collected without collecting
monitoring statistics (Forwarded bytes) the forwarded frames counter.
should capture it.
FRMFWDDN, Forwarded frames in the upstream and downstream.
FRMFWDUP
(Forwarded frames)
Network port statistics

Table 19-6 describes the network port statistics counters that support OLT
performance monitoring statistics on the 7342 ISAM FTTU

Table 19-6 7342 ISAM FTTU supported OLT GPON network port performance monitoring counters
show-bridge 15-min FCSE Count of frame check sequence errors. These are corrupted
network-port x frames for which the CRC check failed. Indicates faulty medium
show interface stats x or hardware.
show interface stats y
or z
Y or Z are the internal
SHUB port interfaces,
which is useful for
determining whether
traffic is being
discarded on the
SHubs or the LT. There
are two SHUB ports
that face each LT slot,
one from each of the
SoCs. Look at all
internal ports to see
traffic transmitted to
or from a card slot.
EC Count of excessive collisions. This indicates that a frame was to

be transmitted but was discarded. Indicates that there may be
excessive traffic on the Ethernet network, and in a very
congested state could lead to service disruption.
LC Count of late collision. Indicates that multiple Ethernet devices

transmitted at the same time. This does not indicate an issue.
SCF Count of successfully transmitted single collision frames. Does

not indicate traffic loss. Should be kept to less than 1% of
transmitted Ethernet frames.
MCF Count of successfully transmitted multi-collision frame. Does

not indicate traffic loss. Should be kept to less than 1% of
transmitted Ethernet frames.
DT Count of frames delayed due to deferred transmission. These

are frames sent with a delay. Deferred and retransmissions
should be kept to under 5% of transmitted Ethernet frames.
IMTE Count of unsuccessfully transmitted frames due to internal MAC

transit errors
mtu-exceeded Frames too long. Indicates that the received frame was greater
-discard (FTL) than 2008 bytes long. Indicates fault hardware or software from
the transmitting device.
CSE Count of carrier sense errors. No carrier is detected for frame

transmission. Indicates a hardware problem.
AE Count of frames with alignment errors. This indicates that part

of an octet is missing and an FCS error. Indicates faulty medium
or hardware.
SQE Signal quality errors. Indicates faulty medium or hardware.
in-overflow-fr Receive or transmit overflow frames due to internal NT/SHUB

ames (RBO) queue overflow. If this counter continues to increment, then
revisit the QoS model used for the SHUB VLAN.
out-overflow-f
rames (TBO)
(TBD) Receive or transmit pause frames used for flow control. Does
not indicate a problem.
(1 of 2)

discard-valid-f Count of dropped frames downstream. Indicates the number of

rames frames discarded. Impacts customer service traffic.
(DSDRPDFRMS)
discard-valid-f Count of dropped frames upstream. Indicates the number of

rames frames discarded. Impacts customer service traffic.
(USDRPDFRMS)
in-frames Count of frames upstream on the UNI

(USFRAMES)
out-frames Count of frames downstream on the UNI

(DSFRAMES)
bcast-out-fra Count of multicast frames sent or received on the UNI with the
mes and broadcast/multicast destination MAC address.
mcast-out-fra
mes
(MCFRAMES)
(2 of 2)
IGMP statistics
Table 19-6 describes the IGMP statistics that support OLT performance monitoring
counters on the 7342 ISAM FTTU.

Table 19-7 7342 ISAM FTTU supported OLT IGMP performance monitoring counters
rept-opstat-ponig 15-min TOTMSG Count of IGMP messages received.

mpmdl
TOTIGMPMSG Count of IGMP messages received in both upstream and
Shows LT-wide
downstream.
IGMP message
statistics to get an TOTINVMSG Count of invalid IGMP messages.
overall view of the
IGMP state. Clear TOTJOINREQ Count of IGMP join requests both successful and failed.
counters with
SET-PONIGMPSTAT TOTSUCCJOIN Count of successful IGMP join requests.
S:::;
TOTFAILJOIN Count of failed IGMP join requests. Join request may be shown as
failed for a valid reason, for example, mulitcast access control
restrictions.
TOTCONNECT Count of new channel connections due to successful joins.
TOTLEAVEREQ Count of channel leave messages.
TOTDISC Count of channel disconnected due to leaves.
PEAKCONN Count of peak connect rate per second.
PEAKDISC Count of peak connect rate per second.
CONNPEAKTIME Timestamp of the peak connect rate time.
DISCPEAKTIME Timestamp of the peak disconnect rate time.

PEAKMSG Maximum rate of IGMP messages per second.
TOTMCGRPS Count of active multicast groups on the LT.
TOTGMQ Count of group member queries.
TOTGSQ Count of group specific queries
ROOTCGCFGD Count of connected groups that are provisioned in the multicast

source table.
ROOTCGUNCFGD Count of connected groups that are not provisioned in the

multicast source table.
ROOTCGNOMEM Count of groups in reserve state that have no members and for
which a leave was not issued by the LT proxy.
rept-opstat-ponig 15-min RATEFAILJOINS Count of IGMP failed joins because the maximum multicast
mpchn bandwidth on the UNI was exceeded.
Shows per UNI
NUMFAILJOINS Count of IGMP failed joins because the maximum number of
IGMP message
concurrent groups was exceeded.
statistics to get an
view of the IGMP ADDRFAIL Count of failed joins because of an invalid multicast group
state per LT for a address.
specific UNI. Clear
counters for an UNUSEDMCBR Current unused bandwidth on the UNI in Kb/s.
individual UNI
with the RESET | CURRNUMGROUP Count of currently active multicast groups.
NORESET
SYSNUMFAILJOIN Count of failed IGMP join requests because the maximum number
parameter
of unconfigured groups was exceeded.
SYSRATEFAILJOIN Count of failed IGMP join requests because the bandwidth

available on the PON was exceeded.
NOPERMISSION Count of failed IGMP join requests because of a mismatch in

multicast group membership.
CURRPREV Count of all multicast channels previewed on the UNI.
(1 of 2)

TXGMQ Count of transmitted group member queries.
RXGSQ Count of received group specific queries
RXV2REPORT(V3) Count of report messages, including channel join messages.

RXv2LEAVE Count of channel leave messages.
RXVALID Count of all IGMP messages received by the LT proxy.
RXINVALID Count of all invalid IGMP messages dropped by the LT proxy,

based on the specific type of error RXUNKNOWNTYPE,
RXBADLENGTH, RXBADIPCHKSUM, and RXBADISGMPCHKSUM.
rept-opstat-ponm 15-min PEAKSUBS Maximum number of simultaneous users subscribed.

csrc
PEAKSUBSTIME Timestamp of the time when the maximum number of
Shows IGMP
simultaneous users were subscribed.
counters for a
specific multicast CURRSUBS Count of current active users subscribed.
group on a specific
LT. Clear counters CONNFAILS Count of failed joins for the multicast group.
with
SET-PONIGMPSTAT SUBSUCC Count of successful joins for the multicast group.
S:::;
show igmp shub 15-min rcv-gen-queries Count of received queries at the NT.
igmp-vlan-stats
XXXX detail tx-gen-queries Count of transmitted queries at the NT.
Shows rolling rcv-group-queries Count of received group queries at the NT.
counters for IGMP
signaling messages tx-group-queries Count of transmitted group queries at the NT.
on a per multicast
VLAN (VLAN ID for rcv-group-src-quer Count of received group and source specific queries.
XXXX) basis as ies
processed by the
NT IGMP proxy rcv-igmp-reports Count of received IGMP report messages.
tx-igmp-reports Count of transmitted IGMP report messages.
rcv-v3-reports Count of received IGMP V3 report messages.
tx-v3-reports Count of transmitted IGMP V3 report messages.
rcv-v3-is-in/ex-ms Count of received IGMP V3 report messages of type IS_EX and

gs IS_IN.
rcv-v3-to-in/ex-m Count of received IGMP V3 report messages of type TO_EX and

sgs TO_IN.
rcv-v3-allow-msgs Count of received IGMP V3 allowed messages.
rcv-v3-block-msgs Count of received IGMP V3 blocked messages.
rcv-leave-msgs Count of received IGMP leave messages.
tx-leave-msgs Count of transmitted IGMP leave messages.
dropped-packets Count of IGMP dropped packets. These are likely dropped due to
a misconfiguration of IGMP on the SHub.
ver-mismatch-pkts Count of packets dropped due to an IGMP version mismatch

between the SHub and the network side of the LT proxy.
(2 of 2)

Backplane error performance monitoring

OLT backplane error performance monitoring provides a way to monitor all ingress
and egress points of the system to ensure that traffic is not being discarded for any
reason. The intent is to ensure that the OLT and ONT system components can be
checked as part of end-to-end troubleshooting of network issues, such as video
pixilation. These rolling counters count errored events detected within a period of
time determined using the OLT system CONFIG configuration file.
Based on the collected backplane error performance monitoring counters, the system
raises alarms for link failures (LINKERRA and LINKERRB) when the NT reports a
link failure after losing communication with an LT
The system generates or suppresses these alarms based on the setting configured
using the OLT system CONFIG configuration file.
The OLT configuration file provides a means by which some numeric constants that
are not settable by other means, such as CLI or TL1, can be configured to meet
individual customer needs. The constants that can be configured include:
• P-OLT backplane error alarms threshold interval and threshold value settings
• ONT alarm hysteresis settings for ONT alarm display activation and deactivation
Authorized configuration files are separate from the 7342 ISAM FTTU system
software package and are issued by Alcatel-Lucent to meet individual customer
requirements.
Table 19-8 describes the backplane error monitoring statistics.
Table 19-8 OLT backplane error performance monitoring statistics
Interface Description of Performance monitoring statistics collected

capabilities
EHNT-B The EHNT-B and EXNT-x nt-frame-err

NT cards maintain lt-frame-err
GLT2-x and performance monitoring
GLT4-x with counters associated with
EHNT-B cards the receive traffic
interface from each LT
EXNT-A
card. Counters are
GLT4-x with updated at each event,
EXNT-A cards and can be collected on
demand via command
GLT8-A with line or network
EXNT-A card management interface.
The counters count the
number of times slots
with an error. The time
slot value is derived
from the OLT system
configuration file.
Figure 19-3 shows how the configuration file is used to set thresholds that can trigger
a LINKERR alarm.

Figure 19-3 OLT backplane thresholds and LINKERR alarms
NT-A
CONFIG File LINKERRA

1) Threshold
2) Threshold interval
for error counters LT card slot
5520 AMS
CLI or TCI NT-B
CONFIG File LT card slot

1) Threshold
2) Threshold interval
for error counters
LINKERRB
20496
19.4 RMON Ethernet statistics support for the P-OLT
The P-OLT supports the collection of remote monitoring (RMON) Ethernet statistics
as defined in RFC 2819. The RMON Ethernet statistics can be gathered from the NT
Ethernet ports of the P-OLT using any RMON SNMP manager.
The RMON implementation does not count packets larger than 1526 bytes. The only
oversized packets that are counted are those that fall between 1518 and 1526 bytes.
Larger packets are discarded.
The RMON manager must set the SNMP packets that it sends with a community
string defined for the P-OLT that it is monitoring.
Table 19-9 describes the RMON Ethernet statistics.
Table 19-9 RMON Ethernet statistics and definitions
Statistic Description
EtherStatsEntry A collection of RMON Ethernet statistics for a specific Ethernet interface. For
example, an instance of the etherStatsPkts object may be named etherStatsPkts.1.
etherStatsIndex The value of this object uniquely identifies the etherStats entry.
etherStatsDataSource This object identifies the source of the data that this etherStats entry is configured
to analyze. This source can be any ethernet interface on this device.
etherStatsDropEvents The total number of events in which packets were dropped by the probe because of
a lack of resources. This number is not necessarily the number of packets dropped;
but is the number of times that this condition was been detected.
On NT network ports, packet discards are not incremented.
(1 of 2)

Statistic Description
etherStatsOctets The total number of data octets that was received on the network including those in
bad packets and FCS octets, and excluding framing bits.
etherStatsPkts The total number of packets that were received including bad packets, broadcast
packets, and multicast packets.
etherStatsBroadcastPkts The total number of good packets received that were directed to the broadcast
address excluding multicast packets.
etherStatsMulticastPkts The total number of good packets received that were directed to a multicast address
excluding packets directed to the broadcast address.
etherStatsCRCAlignErrors The total number of packets received that were between 64 and 1518 octets
excluding framing bits, but including FCS octets inclusive, but had either a bad Frame
Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with
a non-integral number of octets (Alignment Error).
etherStatsUndersizePkts The total number of packets received that were less than 64 octets including FCS
octets, but were otherwise well formed and excluding framing bits.
etherStatsOversizePkts The total number of packets received that were greater than 1518 octets including
FCS octets and were otherwise well formed but excluding framing bits.
etherStatsFragments (1) The total number of packets received that were less than 64 octets including FCS
octets but excluding framing bits, and had either a bad FCS with an integral number
of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment
Error).
etherStatsJabbers The total number of packets received that were greater than 1518 octets including
FCS octets excluding framing bits, and had either a bad FCS with an integral number
of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment
Error).
etherStatsCollisions An estimate of the total number of collisions on this Ethernet segment.

etherStatsPkts64Octets The total number of packets including bad packets received that were 64 octets and
including FCS octets but excluding framing bits.
etherStatsPkts65to127Octets The total number of packets including bad packets received that were between 65
and 127 octets excluding framing bits but including FCS octets.
etherStatsPkts128to255Octets The total number of packets including bad packets received and FCS octets that were
between 128 and 255 octets excluding framing bits.
etherStatsOwner The entity that configured this entry and is therefore using the resources assigned to
it.
etherStatsStatus The status of this etherStats entry.
(2 of 2)
Note
(1) It is normal for the etherStatsFragments statistic to increment because it counts both runts, which are normal
occurrences due to collisions, and noise hits.

20 — Security
20.1 Overview 20-2
20.2 Secured MAC learning 20-3
20.3 Access control lists 20-3
20.4 RADIUS proxy and server 20-4
20.5 SNMP encryption 20-6
20.6 SSH 20-7
20.7 802.1x authentication 20-11
20.8 System log for security and NE actions 20-15
20.9 User account management 20-17
20.10 IPSec 20-17
20.11 Anti-spoofing mechanism 20-19
20.12 Denial of service prevention mechanisms 20-23

20 — Security
20.1 Overview
This chapter describes the security features supported by the 7342 ISAM FTTU:
• secured MAC learning
• RADIUS proxy and server
• SNMP encryption
• SSH
• 802.1x authentication
• system logs
• user account management
• IPSec
• anti-spoofing mechanism
• denial of service protection mechanisms
Figure 20-1 shows the possible security features in the network.
Figure 20-1 7342 ISAM FTTU and network security features
OSS application
Firewall Telnet Firewall

user ID/password
IPSec
SNMPv3 USM/VACM
User ID/ NMS
server Managed
password SSHv2 or telnet network
HTTP/RMI user ID/password (G6+ 7342
Local
security ISAM FTTU)
NMS FTP/SCP user ID/password
client GUI data
User authorization and
authentication
requests
NMS RADIUS
display terminal
18969
TL1 and CLI for security configuration procedures.

20 — Security
20.2 Secured MAC learning
When a frame is received with an unknown media access control (MAC) source
address or the MAC source address is received on a different port than previously
learned, the 7342 ISAM FTTU learns this MAC address with the following
restrictions. These restrictions are valid in both residential bridge mode and virtual
local area network (VLAN) cross-connect mode.
• If the MAC address is learned on a user port and the number of MAC addresses
already learned on that user port has reached the maximum set in the
MAXMANUM parameter, the MAC address is not learned and the frame is
dropped. If the user sends more than 300 packets with the unlearned MAC
address in 15 s., the OLT will shut down the user port for 15 s.
• If the MAC address is learned on a user port and the same MAC address has
already been learned on an Ethernet network interface in the same VLAN as the
user port, then the MAC address is not learned and the frame is dropped.
• If the MAC address is learned on a user port and the same MAC address is already
on another user port and both user ports are in a RB VLAN that has not been
configured to support MAC address movement, then the new MAC address is not
learned and the frame is dropped. MAC address movement is used to provide
support for mobile devices where the MAC address may not have aged out of the
forwarding database on a previous bridge port before it is observed on a new
bridge port.
• If the MAC address is first learned on a user port and then on an Ethernet network
interface, then this movement is accepted and the MAC address will be learned.
This means that the MAC address is removed on the user port.
• Well-known MAC addresses, such as multicast MAC addresses, and MAC
addresses allocated for IEEE protocols, will not be learned.
Only independent VLAN learning is supported; that is, a MAC address is unique
within a VLAN, but not across VLANs. If a port is connected to two VLANs, the
MAC address is learned twice.
20.3 Access control lists
Filter policies, also referred to as Access Control Lists (ACLs), are applied to
VLANs, protocols, NT cards, or LT cards to control traffic into or out of the system.
The filters can be based on MAC matching criteria, or on EtherType only.
You can configure the following 7342 ISAM FTTU MAC-based filters, to enable or
prevent the forwarding to or the distribution from specific MAC addresses:
• source MAC address
• destination MAC address
• source and destination MAC address
• any source and destination MAC address, used for EtherType only filtering

20 — Security
20.4 RADIUS proxy and server
The remote authentication dial-in user service (RADIUS) is a standardized method

of information exchange between the RADIUS client, a device that provides network
access to users, and the RADIUS server, a device that contains authentication and
profile information about the users. The 7342 ISAM FTTU supports RADIUS for
both layer 2 and layer 3 forwarding. The 7342 ISAM FTTU supports the RADIUS
protocol, as defined by RFC 2865. Compatible RADIUS servers include, but are not
limited to, SteelBeltedRADIUS server Release 5.03 for Solaris 2.8. Refer to the
appropriate RADIUS server user documentation for more information about
configuring RADIUS server dictionary information
The NT card can contact RADIUS servers over the internal VLAN and the external
VLAN. When the internal VLAN is used, the RADIUS proxy on the NT card is used
as the destination. The RADIUS proxy contacts the RADIUS servers of the ISPs.
When the external VLAN is used, the destination is the external RADIUS server or
proxy. The RADIUS proxy in the NT card selects the RADIUS server based on the
domain name. This domain name maps to a specific Internet service provider (ISP).
The IP addresses of the RADIUS servers are in the ISP profile.
Applications such as 802.1x that need RADIUS server access for authentication use
the internal VLAN to contact the RADIUS client on the NT card. The RADIUS
client on the NT card contacts a RADIUS server outside of the 7342 ISAM FTTU
system. When a response is received from the RADIUS server, the client on the NT
card sends the success or failure indication to the 802.1x application on the LT card
using the internal VLAN.
To route the RADIUS packets towards the RADIUS servers, the system performs an
IP lookup in the context of the Internet service provider (ISP). The ISP profile
contains configuration for the virtual routing and forwarding (VRF) application. The
VRF configuration provides a route for each of the RADIUS servers used by the ISP.
If multiple RADIUS servers are configured for redundancy, the RADIUS client on
the NT card selects the appropriate RADIUS server.
Caution — If a higher priority RADIUS server is not responding,

authentication is retried until the dead-interval expiration value is
reached. The 7342 ISAM FTTU then tries to authenticate using a
lower priority RADIUS server. This may lead to authentication and
service outages.
The following features are supported:

• User authentication via an external RADIUS authentication server.
• The RADIUS Authentication client encrypts all password fields in the messages.
• Multiple RADIUS Authentication servers.
• A flexible authentication mechanism: that supports Password Authentication
Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP)
authentication, as well as support of Extensible Authentication Protocol (EAP)
• RADIUS authentication for CLI and TL1 users
• User authentication via external RADIUS servers
• Fall back to local authentication when no RADIUS server is available. "Fallback
to a configurable default operator profile when the RADIUS server does not
support vendor specific attribute.

20 — Security
Figure 20-2 shows RADIUS on the NT and SHub.
Figure 20-2 RADIUS on the NT and SHub
Applications like 802.1x A RADIUS packet from NT control on the Internal OAM
and PPP server talk via VLAN is handled by the RADIUS proxy.
the internal OAM VLAN A RADIUS packet from NT control on the External OAM
to NT control to perform VLAN is bridged
authentication
7342 ISAM
FTTU Ethernet
ONT RADIUS
ER RADIUS
NT server
control
When an application requests for authentication, NT control will

perform authentication using the local authentication database,
or it will use RADIUS.
In case of RADIUS, the external OAM VLAN is used to contact an
external RADIUS server, or the internal OAM VLAN is used
towards the SHub, which will perform RADIUS proxy.
18971
CLI and TL1 operators can be authenticated either locally on each

7342 ISAM FTTU or remotely centralized at a RADIUS server. There is one
restriction: if CLI or TL1 over SSH with key authentication is used, the
authentication has to be done locally as RADIUS does not support keys.
This functionality is only supported for CLI and TL1. It does not apply for SNMP
operators as SNMP does not work with the concept of a session. That would mean
that, for each SNMP request, communication with a RADIUS server would have to
be setup to authenticate the originator. In case of CLI and TL1, the authentication
occurs once for a complete session.
A centralized authentication server has a lot of benefits for the management of
operator accounts, but is a danger with regard to availability and security. It is
advisable to support redundant RADIUS servers (this is supported by the NE). In
addition, the NE will fallback to local authentication in case the communication with
the RADIUS server fails.
As an operator will either choose for local or centralized authentication, typically the
local database will only contain the administrator account in case RADIUS is used.
To prevent isolation, the operator can configure one default local operator profile
that applies when RADIUS is not reachable and the operator is not configured in the
local database.
Figure 20-3 shows RADIUS operator authentication.

20 — Security
Figure 20-3 RADIUS operator authentication
NMS
7342 ISAM
FTTU Ethernet
ONT RADIUS
ER RADIUS
NT server
control
When a CLI or TL1 operator requests for authentication, NT control will perform
authentication using the local authentication database, or it will use RADIUS.
In case of RADIUS, the external OAM VLAN is used to contact an external
RADIUS server, or the internal OAM VLAN is used towards the SHub,
which will perform RADIUS proxy.
18972
TL1 and CLI for configuration information.
20.5 SNMP encryption
The 7342 ISAM FTTU provides the simple network management protocol (SNMP)
version 3 privacy and authentication features of the user-based security model
(USM). The privacy feature uses DES-56 to encrypt SNMP version 1 and SNMP
version 2 packets. Authentication is provided by keyed-hash message authentication
code (HMAC) signatures (HMAC-SHA-96 or HMAC-SHA-96). Access control lists
for managers and community string can also be provisioned in addition to USM or
used without USM.
The security mechanisms defined in SNMPv3 protect against threats as masquerade,
modification of information, message stream modification, and disclosure and
provide:
• data origin authentication
• data integrity checks
• timeliness indicator
• encryption
SNMPv3 allows for different security levels. Messages between agent and manager
can be:
• unauthenticated and unencrypted
• authenticated but unencrypted
• both authenticated and encrypted

20 — Security
SNMPv3 defines two security-related capabilities: the User-based Security Model

(USM) and View-based Access Control Model (VACM)
The USM provides authentication and privacy (encryption) functions and operates at
the message level. In addition, it includes a key management capability that provides
for key localization and key updates. The USM is used to authenticate entities, and
provides encryption services to secure communication between agents and
managers. Each agent keeps track of the authorized user allowable access via an
internal table of user/secrets/access entries. Both authentication and encryption
utilize symmetric keys, which can be generated from a password. Localization of the
authentication and encryption keys by hashing the generated key with the ID of each
agent entity is strongly recommended.
The VACM verifies that a given user is allowed to access a particular MIB object
and perform particular functions (MIB views: read, write or notify access). The
VACM makes an access control decision on the basis of:
• the principal asking for access
• the security model and security level used for communicating the request
• the context to which access is requested
• the type of access requested (read, write, notify)
• the actual object to which access is requested
SNMPv3 implements security by adding a security header to a standard SNMP PDU,

allowing entities to support non-SNMPv3-aware agents and managers.
See DLP for SNMPv3 configuration in the 7342 ISAM FTTU Operations and
Maintenance Using the 5520 AMS or the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI for more information.
During creation, modification, or deletion of a 7342 ISAM FTTU, you can configure
the security level of communication between the network manager and the
7342 ISAM FTTU. See security DLP 7342 ISAM FTTU Operations and
Maintenance Using the 5520 AMS or the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI for more information.
The available supported security levels are NoAuthNoPriv, AuthNoPriv, and
AuthPriv:
• NoAuthNoPriv: Indicates that messages between the agent and the manager are
unauthenticated and unencrypted
• authNoPriv: Indicates that messages between the agent and the manager are
authenticated by unencrypted
• authPriv: Indicates that messages between the agent and the manager are both
authenticated and encrypted
20.6 SSH
The secure shell (SSH) provides a secure and authenticated stream over the transport
control protocol (TCP) layer. The 7342 ISAM FTTU implements SSH version 2. On
top of this protocol, SSH implementations offer secure replacements for rsh, rlogin,
rcp, ftp, and telnet.

20 — Security
The main capabilities of SSH are:

• Secure Command shell is the secure version of the typical shell. It enables
commands and applications to be executed from the command line.
• Secure file transfer (SFTP) handles secure file transfers by encrypting usernames,
passwords, and data while using the same port as the SSH server, which prevents
the opening of another port.
Note — For the SSH server and SFTP client feature, the
7342 ISAM FTTU supports a single SFTP transfer at a time. Do not
perform concurrent transfers to the P-OLT. See the 7342 ISAM FTTU
Operations and Maintenance Procedures Guide using TL1 and CLI
for configuration information.
Figure 20-4 shows how SSHv2 secures communications.
Figure 20-4 SSHv2 security
SSH CLI SSH Appl. protocol SSH CLI

client appl server appl
SSH transport
ssh client ssh server
authentic, conn.
NMS 7342 ISAM FTTU

DB of client pubKeys
SSH Secure link for CLI/TL1 SSH or passwords
client Server
ISAM pubKey
Secure link for SFTP InterPeak SFTP ISAM privkey
SFTP Server
client supported algos
SFTP
Client SFTP client
File uname/pwd
SFTP
Secure link Server Secure link for the transfer
for SW&DB from file server to 7342 ISAM FTTU (SW&dDB)
18968
The SSH transport layer provides authentication, encryption, and integrity.

Encryption is provided by a negotiated Diffie-Hellman or public-private key
exchange to negotiate a shared session secret: the symmetric key for 3DES. The
connection layer provides multiplexing of different streams over the transport layer.
User authentication provides authentication of client to server. Secure FTP is the
FTP client. It is used to download or upload files to or from the platform.
Table 20-1 shows the 7342 ISAM FTTU platform SSH and SNMP authentication
and authorization configurations.

20 — Security
Table 20-1 SSH and SNMPv3 security combinations
Security Encryption Authentication Authentication Combinations

protocol algorithm algorithm mechanism
SSH • 3DES • Hmac-sha-1 • Username and • Nothing

SFTP • blowfish • Hmac-sha-1-96 password • Encryption only
• AES • Username and • Authentication only
Public/Private
• DES-56
key
• Encryption and authentication
SNMPv3 DES-56 • Hmac-sha-1 Username and • Nothing

• Hmac-md5 password. A • Authentication only
different
username and
• Encryption and authentication
password are
required for each
SNMP engine
The SSH authentication algorithm manages password and public key login attempts
as follows:
• When a user attempts to connect via telnet, the system verifies whether the IP
address is locked and responds as follows:
• If the IP address is locked, the system closes the connection.
• If the IP address is not locked, the user can make up to three connection attempts.
The number of connection attempts permitted depends on the value configured for
the SSH server connection parameter.
• If a login attempt fails (because a username and password are mismatched, a timeout
occurs, or a connection breaks), the system logs a login failure event.
• If a login attempt succeeds, the system logs a login success event.
• When a login failure occurs, the system begins monitoring failed login attempts
as follows:
• If the system is monitoring individual IP addresses, it increases the IP address login
failure counter by one, and adjusts the global last fail time to the current time.
• If the system assumes an attack is occurring, it monitors login failures globally.
Each time a failure occurs, the system increases the global login failure counter by
one, and updates the global last fail time to the current time.
• If the system is monitoring less than five IP addresses globally when a connection
failure occurs for another IP address, it starts monitoring the new login failure, sets
the login failure counter to one, and adjusts the global last fail time to the current
time.
• If the system is monitoring five IP addresses globally when a login failure occurs for
another IP address, it sets the global login failure counter to the sum of the failed
login counters for the five IP addresses plus one, adjusts the global last fail time to
the current time, and stops monitoring individual IP addresses.
• If a successful login occurs, the system responds as follows:

• If the system is monitoring login failures globally, it stops global monitoring and
resets the count of all previous failures.
• If the system is monitoring login failures for an IP address, it stops monitoring the
IP address and resets the login failure counter for that IP address.

20 — Security
• The system monitors the failed login times and counters as follows:
• The system decreases the failed login counter (global or IP address) by one when the
current time is greater than the value determined by the following calculation:
current time > last failed login time + 15 minutes
• The system stops monitoring failed login attempts when the applicable failed login
counter (global or IP address) is zero.
• A login attempt is permitted as follows:
• When the applicable login failure counter (global or IP address) is less than three.
• When the current time is greater than the value determined by the following
calculation (the applicable global or IP address login failures are used):
current time > last fail time + max(15, (login failures - 3) * 2)
Table 20-2 shows lockout times that the SSH authentication algorithm enforces for
assumed password attacks.
Table 20-2 Lockout times for failed login attempts
Failed login attempts (1) Number of IP Lockout time(2)

addresses
1st failed login group 1-5 no effect
1st failed login group (IP address a) 6

2nd failed login group 1-5 no effect
2nd failed login group (IP address b) 6
3rd failed login group 1 2 minutes
2-5 no effect
3rd failed login group (IP address c) 6
4th failed login group 1-2 4 minutes
3-5 no effect
4th failed login group (IP address d) 6
4-5 no effect
5th failed login group (IP address e) 6
5 no effect
6th failed login group (IP address f) 6
7th failed login for any group 6
(1 of 2)

20 — Security
Failed login attempts (1) Number of IP Lockout time(2)

addresses

(2 of 2)
Notes
(1) If the user attempts to log in from another IP, there is no delay.
(2) The system returns to normal 2.5 hours (10 x 15 minutes) after the attack stops.
20.7 802.1x authentication
The 7342 ISAM FTTU implements the authenticator part of the IEEE 802.1x
protocol to authenticate ONT LAN user ports for IPoE traffic. The 802.1x protocol
is only applicable to residential bridge mode. In residential bridge mode,
VLAN-tagged frames are not supported for 802.1x.
The P-OLT maintains the 802.1x authentication state by terminating the 802.1x
protocol and authenticates the user using the RADIUS server. Authentication is only
performed by the RADIUS server. Local authentication is not supported. The optical
network terminal (ONT) provides the filters for blocking and unblocking a local area
network (LAN) port.
There is no interaction between 802.1x and dynamic host configuration protocol
(DHCP) or Point-to-Point Protocol (PPP). After the system authenticates a port using
802.1x, the user can use DHCP or PPP.
802.1x support assumptions

The 7342 ISAM FTTU supports 802.1x authentication based on the following
assumptions:
• Authentication is supported only on LAN ports at the ONT and not for the plain
old telephone system (POTS) lines.
• Authentication is performed on an ONT UNI basis. The highest priority GPON
encapsulation module (GEM) port ID that is configured on the user network
interface (UNI) is used for authentication.

20 — Security
• The user does not send user IDs and the domain name during authentication. The
system uses the default domain.
• The disconnection of servers is not required.
• Support for non-EAP RADIUS servers is not required.
• The assignment of VLANs by the RADIUS server is not required.
• There is no local authentication for 802.1x when the RADIUS server fails.
Authentication protocols
The 7342 ISAM FTTU supports extensible authentication protocol (EAP) over
RADIUS between the P-OLT and the RADIUS server for 802.1x authentication. The
following authentication protocols are supported when the EAP is used:
• MD5-Challenge, as defined in RFC 2284
• OTP, as defined in RFC 2284
• generic token card, as defined in RFC 2284
• TLS, as defined in RFC 2716
The 7342 ISAM FTTU system is not required to support VLAN selection based on
RADIUS response.
The 802.1x protocol can be enabled or disabled for each 7342 ISAM FTTU system
or for each ONT UNI.
Port-based authentication
The 7342 ISAM FTTU supports port-based authentication. The port is the ONT
UNI. MAC-based authentication is not required. Accounting is based on each port,
not on the MAC. The accounting session is linked to the session of the first
authenticated user. Interim accounting is supported and is based on a configurable
time interval.
There are two MAC configuration scenarios for authentication:
• When MAXMAC is 1, the first MAC address to be authenticated is learned on the
bridge port for the duration of session timeout (not the FDB aging timeout). The
MAC address is learned on all VLANs configured on the bridge port. No other
MAC addresses are learned.
• When MAXMAC is greater than 1, MAC learning occurs after authentication is
successful. All MAC addresses are learned dynamically and age out using the
FDB aging timer. The system responds with EAP-Success message if other users
on the port try to authenticate after the port is authorized for traffic.
When the authenticated user logs out, the system performs the following actions:
• closes the port for traffic
• stops accounting for the port
• sends an identity request as multicast over the port to invite any potential users of
the port for authentication
• opens the port for traffic again only after a successful authentication

20 — Security
• sends new identity requests only after the held period expires if the authentication
fails
• sends periodic identity request messages until the port is authenticated
• does not require re-authentication
• flushes the FDB entries that correspond to the port
When the maximum MAC value on a bridge port is changed by the operator to a
lower value, the system performs the following actions:
• flushes all the forward database (FDB) entries on the port
• closes the associated ONT UNI for data traffic
• sends identity request as multicast over the port in order to invite any potential
users of the port for authentication
• opens the port for traffic after successful authentication
User session disconnection by system

The 7342 ISAM FTTU supports the following three types of user disconnections:
• When the RADIUS requests disconnection, the system does not send an
accounting stop message. The system sends a failure message to the first
authenticated user on the port and initiates the authentication of other users on the
port.
• When the maximum session duration is expired. The system sends a failure
message to the first authenticated user on the port and initiates other users on the
port to start authentication.
• When there is a request to disable or delete a user port, the system gracefully
terminates the user sessions on the port before the port is disabled or deleted. User
session accounting data is sent to the RADIUS accounting servers when the
session is terminated.
Statistics and operational data

The 7342 ISAM FTTU provides statistics and operational data for the authenticator,
as described in the IEEE 802.1x MIB requirement document.
The system provides visibility to the intermediate 802.1x states during the
authentication phase of a user session.
Restart scenarios
If the NT card restarts or is removed, all 802.1x sessions are terminated gracefully.
After the restart, an accounting-on message (if enabled) is sent to each potential
RADIUS server. An EAP Request Identity is sent to all 802.1x-enabled ports in the
system to re-initiate the authentication of users.
If the NT card switches over, the existing 802.1x sessions are retained. However, the
sessions that are being authenticated are lost.

20 — Security
If the LT card restarts or is removed, all 802.1x sessions are terminated and a logout
message is not sent. An accounting-stop message is sent to RADIUS server for each
session. An EAP Request Identity is sent to all 802.1x-enabled ports on the LT to
re-initiate the authentication of users.
If the operator requests reboot on the LT card, the 802.1x sessions that were created
on the LT card are terminated and a logout message is not sent. An accounting-stop
message is sent to the RADIUS server for each session. An EAP Request Identity is
sent to the 802.1x enabled ports on the LT to re-initiate the authentication of users.
If all RADIUS servers of a VRF are unreachable, such as during an NT restart or
network problems, the OLT provides two options: accept or reject all authentication
requests. The default is to reject all authentication requests, which means there is no
local authentication. When Accept All is configured, an EAP success message is
returned to the ports that are trying to authenticate with a lease time of 30 min.
Re-authentication
To ensure that there is no service interruption during re-authentication, it is required
re-authentication of the supplicant must occur before the session expires. The
supplicant does not cause any service interruption during re-authentication. New
accounting-stop or accounting-start messages are not sent due to re-authentication.
The P-OLT supports the re-authentication state. The configuration of the
re-authentication function is made on a port basis and includes enabling or disabling
re-authentication and setting the re-authentication period.
The RADIUS Termination Action attribute is supported. If a Termination Action is
received, re-authentication is performed only at the request of the RADIUS server.
The RADIUS server overrides local configuration of re-authentication in the P-OLT.
If re-authentication is enabled on a port, the Session Timeout value returned by
RADIUS service is used as the re-authentication period. If the RADIUS server does
not return a Session Timeout value, the re-authentication timer for the port that is
configured by the management system is used.
If there is no response from an RADIUS server for re-authentication due to an NT
card switchover, the P-OLT treats the re-authentication as a successful one for 30
min.
If re-authentication is disabled for a port, the Session Timeout value returned by
RADIUS server is used to terminate the sessions. Re-authentication initiated by the
management system is not required.
During re-authentication, traffic to and from the user is not interrupted. The port
forwards bidirectional traffic until re-authentication is completed. If
re-authentication fails, the port is changed to unauthorized state.
An EAP Request Identity message is sent to the port when the re-authentication timer
expires.

20 — Security
20.8 System log for security and NE actions
The NE supports system logs, also known as syslog. This system log contains actions
performed on the NE, behavior of the NE that may provide troubleshooting
information, even after a reset, and security-related information for administrators.
Based on information contained in the syslog, the administrator can:
• trace and audit the behavior of the NE
• review operator actions
• change the security settings
Figure 20-5 shows the syslog system.
Figure 20-5 Syslog system
Syslog record
storage
SHub logs Configuration

Authentication query results
CLI configurations
Syslog Local file system
system
TL1 configurations
View management Send syslogs to

from stations remote servers
18901
All syslog messages include a timestamp, based on the NE system clock, to identify
the time the logged action or event occurred. System log messages also provide a
description of the action that is being logged, and identifies the remote host terminal
of the user performing the logged action.
Users with root, administrator, or security access control can view the syslog files.
Logged message or information types

The following types of messages are logged:
• unauthorized login attempts or security attacks
• when a login identifier is changed, added, or deleted
• when an ACL is created, modified, or deleted
• when software is modified
• when a login password is changed, added, or deleted

20 — Security
• when a login password aging threshold is changed, added, or deleted

• when an authorized login or logout occurs
For NE system logging, the following information on the state of the NE is logged:
• BCM counters
• resource failure statistics
• memory error counters
• port link status
• CPU packet counter
• protocol packet counters
• event triggered logging for application resets and watchdog timer resets
• LT card resets and LT card transitions to the operational state
• protection switch events
Message filtering
Security administrators can control what is seen in the syslog. Syslog entries can be
filtered based on the severity level of the message. Severity levels ranked highest to
lowest, showing the parameter filter name in parentheses, are:
• emergency (EM)
• alert (AL)
• critical (CR)
• error (ER)
• warning (WN)
• notice (NO)
• info (IN)
• debug (DBG)
Syslog format
Consider the following format information when viewing system log information.
• The message length can be up to 1024 bytes; longer messages that have been
truncated are indicated in the TRUNCATE field.
• The message type is indicated in the FACILITY field.
• The message severity is indicated in the SEVERITY field.
• The HOSTNAME indicates the static IP address, system name, or dynamic IP
address, in that order.
• The application generating the message is indicated in the APP-NAME field.
• Only ASCII characters are used in the MSG field.

20 — Security
Syslog file destinations

Security administrators can specify the destination for logging. When the system log
data is configured to be sent to a file, and the file is configured to be uploaded, the
syslog file is uploaded to the remote server based on the IP address and directory path
specified. Possible syslog destinations include:
• all CLI terminals
• all TL1 terminals
• local file
• remote syslog server, to house system logs
20.9 User account management
The NE supports user account management, which allows administrators to:

• disable the threshold for the maximum number of login attempts before a user is
locked out
• set login identifier and password length
• set minimum password length
• set password history
• age passwords
• restore a locked out session
• disable user IDs that have not been used for a specified period of time
• enable SNMP manager read/write access to user security tables
• SNMP commands must be SNMPv3 with authentication and privacy
• TL1 users accounts updated using the 5520 AMS GUI are also updated at the OLT
20.10 IPSec
Internet protocol security (IPSec) is a suite of protocols and support components that
provide security at the network or IP packet processing layer of network
communication. The 7342 ISAM FTTU implements IP version 4 and supports only
transport mode.
Table 20-3 lists the protocols and components that make up the IPSec protocol suite.
Table 20-3 IPSec protocol suite
IPSec core protocols IPSec support components
IPSec authentication header (AH) Encryption/hashing algorithms
Encapsulating security payload (ESP) Security policies/security associations

— Internet key exchange (IKE)/key management

20 — Security
The combination of these core protocols and support components provide varying
levels of security. IPSec provides two different types of security at the IP layer:
• Authentication which protects the integrity of the message and ensures that the
data has not been changed during transmission. Authentication also protects
against certain types of attacks, such as replay attacks. Both IPSec core protocols,
AH and ESP, support authentication.
• Privacy which encrypts the contents of the message using hashing algorithms
such as message digest 5 (MD5) or secure hash algorithm (SHA-1). These
hashing algorithms require that an initial key be set up. This key can be created
manually using configuration or automatically assigned using the IKE protocol.
Of the two IPSec core protocols, ESP supports payload encryption while AH does
not.
When IPSec is enabled, all inbound and outbound packets must pass through a filter
called the security policy database (SPD) to determine if each packet maps to a
security association (SA). The SPD checks its rule table to determine whether a
packet maps to an SA and, if so, how IPSec should process this packet.
Figure 20-6 shows the internal structure of the IPSec protocol suite.
Figure 20-6 IPSec internal protocol suite
Application
Error logs to system audit file process
IKE Application
Negotiates, modifies, and deletes SAs protocol
System manager
API
Configures
IPSec
policies SAD Asks for
SA creation Socket layer
Consults
Points to Transport protocol (TCP/UDP)
Consults Security protocol
SPD AH, ESP IP
Link layer protocol
19066
Each SA describes a secure connection for data traffic traveling in one direction only
between devices. Bidirectional protection between two devices requires that
individual SAs be set up for traffic traveling in each direction.
Setting up a SA between devices requires that initial keys be exchanged between the
devices. Key exchange is performed either statically, by provisioning both devices
manually, or dynamically using the IKE protocol. The dynamic provisioning option
provides application programming interfaces (APIs) that allow IPSec core protocols
to request dynamic setup of a SA. Dynamic provisioning is more commonly used
than static provisioning.

20 — Security
A set of three parameters containing the security parameter index (SPI), IP

destination address, and security protocol identifier is used to identify individual
SAs. These parameters are added to AH or ESP packet headers by the transmitting
device to link each secure packet with an SA. The receiving device can then use the
parameter information to return an index to the security association database (SAD)
action table to determine what type of IPSec action must be applied to the incoming
packet. SAD index entries are made either manually, by provisioning a static SA
entry into the database, or dynamically by the IKE protocol after the completion of
a SA negotiation.
See the procedures for configuring IPSec and IKE in the 7342 ISAM FTTU
Operations and Maintenance Procedures Guide using TL1 and CLI.
Sun Solaris and OLT interworking

The following issues should be noted while configuring your IPSec service:
• When setting up a SA between a device running Sun Microsystems Solaris 10 and
the optical line termination (OLT), it is recommended that the duration of the SA
on the OLT be provisioned to last for a shorter time than the duration provisioned
using Solaris. When the SA is provisioned in this way, the OLT initiates the
re-keying process and the SA is renewed at the end of phase 1 without any error.
If the SA duration is provisioned using Solaris to be shorter than the duration for
OLT, then Solaris initiates the re-keying process. In addition to the usual handling
of this situation according to a protocol, Solaris 10 sends an initial contact
message. Rather than allow the SA to pass on to phase 2, Solaris treats the SA as
if it is complete and causes the protocol to request the establishment of a new
session.
• When retrieving ESP keys using Sun Microsystems Solaris 10, the characters in
the string will differ from those you saved. The discrepancy in ESP key values is
due to Solaris performing error detection by inserting an odd parity bit following
seven bits of key data. For example, 4E/01001110 changes to 4F/01001111
because Solaris inserts an additional 1 at the end of the string in order to prevent
there being an even number of 1s in the string.
20.11 Anti-spoofing mechanism
The 7342 ISAM FTTU supports the following features to protect against spoofing:
• gratuitous ARP discard
• ONT level anti-spoofing
• P-OLT level anti-spoofing
Gratuitous ARP discard

A gratuitous ARP request is an ARP packet where the sender IP address and the
target IP address are the same. Attackers can use gratuitous ARP requests to corrupt
the ARP cache of a router by sending out a gratuitous ARP request that claims to be
the default router.

20 — Security
The 7342 ISAM FTTU supports a discard mechanism that filters incoming traffic for
gratuitous ARP requests. When gratuitous ARP discard is enabled, incoming
gratuitous ARP requests are discarded.
Gratuitous ARP discard is implemented on a per ONT UNI port basis. See
CLI for configuration information.
Note — Gratuitous ARP discard only applies for residential bridge

VLANs; in VLAN cross-connect mode, gratuitous ARP requests are
always forwarded.
Source address anti-spoofing (ONT only)

Source address spoofing is an attempt to gain entry to a system by posing as a trusted
source. Although the packet cannot be routed back to the initial source, source
address spoofing can lead to unnecessary network congestion and to possible denial
of service.
To block unauthorized traffic, the 7342 ISAM FTTU supports an anti-spoofing
mechanism that limits source address spoofing. Upstream traffic arriving at the ONT
is validated for source address. Authorized packets are forwarded and non-validated
packets are discarded, as illustrated in Figure 20-7.
Figure 20-7 ONT packet authorization
ONT
Forward authorized packets Upstream packets

Authorize
packets
Discard Authorized
unauthorized source addresses
packets
19075
Source address anti-spoofing is implemented in either static or dynamic mode.

• Static mode enables the table of authorized source addresses to be provisioned
statically by an operator for one of the following anti-spoofing control types:
• MAC only
• MAC organization unique identifier (OUI)
• IP only
• MAC and IP
• Dynamic mode enables the table of authorized source addresses to be provisioned
both statically by an operator and dynamically through DHCP, and supports the
anti-spoofing control type IP-only.

20 — Security
Source address anti-spoofing filters are applied as follows:

• For IP-only anti-spoofing, packets that match a configured IP source address are
forwarded, and non matching packets are dropped.
• For MAC and IP anti-spoofing, packets that match a configured pair of MAC
source address and IP source address are forwarded, and non-matching packets
are dropped.
• MAC-only anti-spoofing can be implemented in one of two modes:
• Inclusive mode forwards packets that match a configured MAC source address, and
drops non matching packets.
• Exclusive mode forwards packets that do not match a configured MAC source
address, and drops matching packets.
Exclusive mode is used when you want to protect the 7342 ISAM FTTU against
virus-infected computers that send traffic using the MAC address of the default
router, which is in the computer’s ARP cache table.
• MAC-OUI anti-spoofing can be statically provisioned, in inclusive mode. It
supports anti-spoofing filtering that only permits MAC addresses with the
specified OUI. The first 3 bytes of the source MAC address are checked and if
matching, the packet is allowed.
Not all anti-spoofing control types apply to all traffic. Table 20-4 identifies the
anti-spoofing control types and any traffic exemptions by source address
anti-spoofing mode.
Table 20-4 Anti-spoofing control types and traffic exemptions
Source address Anti-spoofing control type Traffic exemptions

anti-spoofing mode
Static MAC-only anti-spoofing Is applied to all data traffic
MAC-OUI anti-spoofing Is applied to all data traffic

IP-only anti-spoofing Is not applied to non-IP traffic,
such as:
MAC and IP anti-spoofing
• PPPoE
Dynamic IP-only anti-spoofing • ARP
• EAPOL, EAP
Is not applied to DHCP packets to

allow a subscriber to obtain a
DHCP lease.
The anti-spoofing control type limits the number of authorized source address
entries.
When static or dynamic source address anti-spoofing is enabled at the ONT level, the
LT card downloads the static entries provisioned for an ONT UNI port to the ONT
by way of OMCI. When a static entry is removed or anti-spoofing is disabled, the LT
card notifies the ONT to remove the corresponding anti-spoofing filter(s).

20 — Security
When dynamic anti-spoofing is enabled, the LT card forwards the currently leased
IP addresses to the ONT by way of OMCI after an IP address is leased, or a DHCP
lease expires or is released. When a UNI port has reached its maximum allowed
number of IP source addresses, the LT card drops any subsequent DHCP ACKs with
a leased IP address that is not in the lease table. IP source addresses that are added
dynamically through DHCP survive ONT restarts, LT restarts, and NT switchovers
and they survive NT resets if NTP is set.
See 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1
and CLI for configuration information.
Per-service anti-spoofing (ONT only)

You can configure dynamic or static IP anti-spoofing on a per-service basis, for
example, an HSI service. The dynamic IP anti-spoofing allows up to eight IP
addresses to be learned. The static IP anti-spoofing allows up to eight IP addresses
to be specified by the operator.
When the dynamic service control type is specified for the ONT UNI and per service
anti-spoofing is enabled for an HSI service, packets are allowed with a combination
of leased IP address and the C-VLAN ID of the service. A packet sent upstream (user
to network) over the HIS service is permitted only if the incoming packet’s source IP
address is that of the IP address leased for that service. In the case of static IP
addresses (configured IP addresses), the C-VLAN check is not performed for the
service in the ONT UNI and hence filtering is only based on static IP address.
See 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1
Note — For some ONTs, the filtering is always based on IP address

only. See the 7342 ISAM FTTU ONT Product Information Manual
for details.
P-OLT level anti-spoofing

P-OLT level anti-spoofing provides anti-spoofing at the P-OLT rather than at the
ONT UNI to provide anti-spoofing for 7342 ISAM FTTU systems that have ONTs
that do not support anti-spoofing.
P-OLT level anti-spoofing is supported on 7342 ISAM FTTU systems that have
GLT4 cards and IPv4 is used.
The P-OLT prevents user IP address spoofing by discarding upstream IP packets
received from user interfaces that do not match the configured or DHCP discovered
source IP address. The P-OLT does a check of the source IP address contained in
upstream IP frames using a list of valid IP addresses constructed from:
• snooping of leased IP addresses in DHCP ACK
• configured static IP addresses

20 — Security
P-OLT level anti-spoofing always permits the following frame types:

• non-IP frames
• all upstream IP packets (including DHCP frames) with source IP address of
0.0.0.0
When P-OLT anti-spoofing is enabled, the P-OLT supports a list of valid IP

addresses containing up to nine IP addresses per ONT UNI.
The 7342 ISAM FTTU supports ONT level anti-spoofing and P-OLT level
anti-spoofing at the same time, meaning that some subscribers on a PON can have
ONT level anti-spoofing and other subscribers on the same PON can have P-OLT
level anti-spoofing. However ONT level anti-spoofing and P-OLT level
anti-spoofing are mutually exclusive at the UNI level.
When P-OLT level anti-spoofing is configured, the P-OLT also supports
anti-spoofing at the VLAN level.
20.12 Denial of service prevention mechanisms
The 7342 ISAM FTTU supports the following mechanisms to protect against denial
of service:
• Duplicate MAC protection and limiting the number of MAC addresses allowed;
see section 15.5
• Prevention of address spoofing: see section 20.11
• Rate limiting of control traffic
Rate limiting of control traffic

The 7342 ISAM FTTU uses rate limiting of control traffic to protect against denial
of service by preventing overloading of the OLT CPUs. The following methods are
used for rate limiting of control traffic:
• ONT rate limiting: This rate limiting is done in software, so it does not protect the
ONT OBC itself but is intended to protect the OLT.
• LT rate limiting: see section 18.5, but note that VLANs can be configured as
“transparent bitstream” which effectively turns off rate limiting since all
protocols are forwarded transparently.
• LANX rate limiting using the following non-configurable values:
• DHCP packets: 384 Kbps (20 packets per second * 1500 packet size * (8/1000))
• RIP packets: 256 Kbps (125 packets per second * 400 packet size * (8/1000))
• ARP packets: 200 packets per second per EHNT or EXNT (simplex or duplex)
• SLF packets: 200 packets per second per EHNT or EXNT (simplex or duplex)
• Other protocols such as LACP, RSTP: 2000 packets per second per EHNT or EXNT
(simplex or duplex)
• Rate limit value for packets forwarded to the control port (NT OBC port): 1 Mbps

20 — Security

21.1 Overview 21-2
21.2 General description 21-2
21.3 VLAN forwarding modes 21-4
21.4 VLAN models 21-10
21.5 VLAN tagging 21-15
21.6 C-VLAN differentiated services on a UNI 21-23
21.7 Frame processing at the LT 21-24
21.8 Frame processing at the ONT 21-29
21.9 Network interface CAC bandwidth check 21-39
21.10 User-to-user communication 21-41
21.11 VLAN bridging scalability 21-42
21.12 VPNs 21-42

21.1 Overview
This chapter provides information about the virtual local area network (VLAN)
strategy for the 7342 ISAM FTTU.
The P-OLT and the ONT uses Ethernet layer 2 for services and data transport, which
supports VLANs as defined in the IEEE 802.1q.
Traffic from the Ethernet network is always tagged with a VLAN membership and
uses residential bridge (RB) or a cross-connect (CC) mode. Traffic from the
subscriber side can be tagged or untagged.
Each VLAN on the LT and each UNI port on an ONT are configurable for upstream
and downstream traffic. The tagging options of traffic are shown in Table 21-1. For
additional tag handling information, see:
• VLAN tagging
• Frame processing at the LT
• Frame processing at the ONT
Table 21-1 Tagging options for upstream and downstream VLAN traffic
Traffic direction Tagging options See
Upstream and Stacked VLAN Section 21.5

downstream at the
LT Unstacked VLAN
VLAN pass-through mode
Upstream at the Untrusted Section 21.5

ONT
VLAN pass-through
VLAN translation
EtherType/VLAN translation
EtherType classification
Flexible
Downstream at the Transmit tagged traffic Section 21.5

ONT
Transmit untagged traffic
TL1 and CLI for VLAN configuration procedures.
21.2 General description
The following sections define the purpose of VLANs in the 7342 ISAM FTTU.

Definition
A LAN is a local area network and is defined as all devices in the same broadcast
domain. A VLAN divides a physical LAN into multiple virtual LANs whose
membership is not necessarily based on location. Each VLAN represents a different
broadcast domain.
VLAN specifications are contained in the Institute of Electrical and Electronics
Engineers (IEEE) 802.1q standards.
Purpose
A VLAN is typically used to group physically dispersed end-stations into a single
broadcast domain. Even though end-stations may be physically attached to different
LAN segments in different physical locations, they can communicate as if they were
on a common LAN when the end-stations are associated to a VLAN.
You can create broadcast domains by putting switch ports in VLANs. All ports in a
single VLAN are in a single broadcast domain. Figure 21-1 shows an example of
three VLANs: VLAN A, VLAN B, and VLAN C, where:
• ports 1, 7, and 8 on switch A and ports 4 and 7 on switch B are in VLAN A and
are therefore in the same broadcast domain
• ports 2, 4, 6, and 9 on switch A and ports 3 and 6 on switch B are in VLAN B,
and therefore are in the same broadcast domain
• ports 3 and 5 on switch A and ports 1, 2, 5, and 8, and 9 on switch B are in
VLAN C, and therefore are in the same broadcast domain
Figure 21-1 Example of VLAN
Network
Switch Switch
1 2 3456 7 89 123456 7 8 9
VLAN
A
VLAN
B
VLAN
C
17877

The 7342 ISAM FTTU uses VLANs to facilitate the communication between
network service providers (NSPs) and subscribers and to deliver services over the
GPON. Subscriber-to-subscriber communication is not how VLANs are intended to
be used with the 7342 ISAM FTTU.
Services from NSPs are delivered to the 77342 ISAM FTTU over the Ethernet
metropolitan area network (EMAN) connection using VLANs. You can associate
multiple VLANs from NSPs to a network port on the NT card installed in the P-OLT,
and then associate those VLANs to an LT-interface port on the NT card, and a GPON
port on the LT card for GPON access. Depending on the VLAN mode, a VLAN from
the NSP can be attached to multiple LT cards and GPON ports. Management,
subscriber, HSI, and multicast traffic are carried between the NSP and the
subscribers connected to the GPON through these VLANs.
VLANs are manually configured using a management session with the P-OLT.
The 7342 ISAM FTTU supports four VLAN forwarding modes: RB, CC, C-VLAN
learning, and flow mirroring. In addition, the 7342 ISAM FTTU supports two
VLAN configuration models: the VLAN per subscriber model and the VLAN per
service model.
21.3 VLAN forwarding modes
The 7342 ISAM FTTU supports four forwarding modes for VLANs on the LT:
• Residential bridge mode
• Cross-connect mode
• C-VLAN learning mode
• Flow mirroring mode
For downstream forwarding of traffic, the LT learns and ages on MAC addresses for
RB VLANs, and on C-VLANs for C-VLAN learning VLANs. Learning and aging
do not apply to CC and flow-mirroring VLANs. See chapter 15 for more information.
The VLAN forwarding modes are described in the following sections. See also
section 15.4 in chapter 15 “Layer 2 forwarding” for more information.
Residential bridge mode

In the RB mode, multiple subscribers can be associated to a single VLAN from an
NSP to allow those subscribers to access the services of the NSP using a single
VLAN ID. User-to-user communication is disabled by default on all VLANs, which
ensures that upstream traffic from subscribers is sent towards the NSP. However,
user-to-user communication can be enabled on a per-VLAN basis. See 21.10 for
more information about user-to-user communication.
Caution — You cannot have the same VLAN between the NSP and
multiple P-OLTs on the same EMAN. The VLAN between the
P-OLT and NSP in the Ethernet network must have a unique ID. The
risk of flooding caused by broadcast frames from other P-OLTs on the
network could cause performance degradation.
Figure 21-2 shows a basic RB VLAN.

Figure 21-2 Residential bridge VLAN model
NSP IP
network
NSP 1
User A
User B NSP 1
User C NSP IP
User D NSP 2 network
EMAN
User E NSP 2
User F NSP 3
User G
7342 FTTU
NSP IP
network
NSP 3
= NSP 1-VLAN
= NSP 2-VLAN
= NSP 3-VLAN
18917
In Figure 21-2, users A through C can access NSP 1-VLAN, users D and E can
access NSP 2-VLAN, and users F and G can access NSP 3-VLAN. Each NSP has its
own forwarding table in the P-OLT that is associated with its VLAN ID. When a
subscriber generates a frame, or a frame is received from the NSP, a MAC address
lookup is performed in the forwarding table identified by the VLAN ID.
The RB VLAN supports unidirectional multicast downstream traffic where
broadcasting towards all subscribers on the GPON is not desired. You can configure
precisely which subscribers have access to a VLAN. This type of VLAN is also used
for IGMP signaling.
Note — Separate multicast VLANs between the ONT and the P-OLT
must be configured to carry multicast data traffic and IGMP signaling
traffic for IPTV services. At least one multicast VLAN must be
configured between the edge equipment and the P-OLT. Multicast
VLANs are unidirectional in the downstream direction only.
The RB VLAN can be configured to permit the movement of a MAC address from
one bridge port to another within the VLAN. This is useful when multiple WiFi
access points are being used, as it provides support for mobile devices where the
MAC address may not have aged out of the forwarding database on a previous bridge
port before it is observed on a new bridge port.
Cross-connect mode
In VLAN CC mode, there is a one-to-one mapping between the VLAN from the NSP
and the subscriber. A CC VLAN can only be associated with one user port on the LT
card installed in the P-OLT. A single subscriber at the ONT side of the GPON
connection is associated with that CC VLAN. However, a single user port can have
multiple CC VLANs. Each CC VLAN on the network requires a unique VLAN ID.
Any traffic issued by the subscriber is passed transparently towards the network
using the selected CC VLAN.

Figure 21-3 shows the basic VLAN cross connect with three C-VLANs from an NSP
on the EMAN side. Each C-VLAN connects to different GPON ports on the
7342 ISAM FTTU P-OLT, and each C-VLAN is associated with a single subscriber
connected to the GPON through an ONT. Every subscriber requires a unique
C-VLAN for bidirectional communication with the NSP.
Figure 21-3 C-VLAN cross-connection model
C-VLAN to GPON port

cross-connects
EMAN P-OLT GPON
GPON ports
C-VLANs C-VLANs
to NSPs to ONTs
18924
The incoming C-VLAN from the NSP on the EMAN has a unique VLAN ID. This
VLAN ID is mapped to a specific GPON port on one of the LT cards installed in the
P-OLT, which is connected to the GPON. Traffic from the NSP is broadcast over the
GPON to all ONTs connected to the GPON. Any subscriber UNI port on an ONT
that is configured with HSI services associated to the VLAN ID that is being
broadcast can accept the traffic. Consequently, traffic issued by the subscriber is
transparently forwarded to the network-side using that VLAN ID.
Each subscriber requires their own unique C-VLAN. When configuring an Ethernet
UNI port at the ONT, you must enter the unique VLAN ID from the NSP. This
associates the NSP C-VLAN to the subscriber.
The subscriber’s C-VLAN is used for HSI services and carries all bidirectional
traffic, including: HSI, VoIP, VOD, MS TV unicast streams, and instant channel
change transactions.
The CC mode is also used for Ethernet services. Ethernet services for business and
residential applications are implemented on the 7342 ISAM FTTU using an Ethernet
virtual connection (EVC) model. The EVC model can be configured in a number of
ways to provide a single service to multiple subscribers, or multiple services to a
single subscriber. Internal EVCs with all-to-one bundling and external EVCs are
configured in CC mode. See section 28.4 in chapter 28 “Ethernet services for
business and residential applications” for more information.
Note that the standard CC VLAN uses a single S-VLAN to identify a subscriber.
However, there is a second type of CC VLAN that uses the (S-VLAN, C-VLAN) pair
to identify the subscriber. In this case, the CC VLAN is configured in C-VLAN
learning mode on the LT to enable downstream forwarding by (S-VLAN, C-VLAN).
See S/C-VLAN cross-connect VLAN for more information.


Unlike RB VLANs where the LT uses the destination MAC address for forwarding,
in C-VLAN learning mode the LT uses the C-VLAN for forwarding. In the
downstream, the LT uses the S-VLAN, C-VLAN, and p-bit to identify the GEM port;
in the upstream, the LT learns and ages on the C-VLAN. An alarm is raised when a
duplicate C-VLAN is detected across bridge ports.
The C-VLAN learning is not supported on the NT. The operator can configure the
VLAN on the NT as either an RB or CC VLAN.
• For RB VLANs, the VLAN is associated with one or more ports on both the
network side and the subscriber side.
• For CC VLANs, the VLAN is associated with a single port on the network side
and a single port on the subscriber side.
A C-VLAN learning VLAN can have protocol awareness for each of the following:
• IGMP proxy
• DHCP relay
• ARP proxy
• PPPoE relay
A C-VLAN learning VLAN handles non-unicast packets differently from a RB

VLAN or a CC VLAN.
• Broadcast packets are forwarded both upstream and downstream.
• IP multicast packets, that is packets with a destination MAC in the form
01-00-5e-xx-xx-xx, are only forwarded downstream if the multicast group
address is configured in the multicast source table either by IGMP proxy or by
static configuration. In the upstream, IP multicast packets are always forwarded.
• Non-IP multicast packets are forwarded both upstream and downstream.
Restrictions
Support for C-VLAN learning is as follows:
• GLT8-A: fully supported
• GLT4-A: fully supported
• GLT2-A: not supported
• GLT2-B/C: supported but only for statically configured C-VLANs. The LT card
does no support learning of C-VLANs.
S/C-VLAN cross-connect VLAN

The CC mode uses a single S-VLAN tag to forward packets. A second type of
CC VLAN uses both the S-VLAN and C-VLAN tags for downstream forwarding at
the LT. This type of CC VLAN must be configured in C-VLAN learning mode, and
is known as the S/C-VLAN cross-connect (CC).

The S/C-VLAN CC is uniquely identified by the (S-VLAN, C-VLAN) pair, and is

associated with a single bridge port. In the downstream, the LT uses the S-VLAN,
C-VLAN, and p-bit to identify the GEM port; in the upstream, the LT learns and ages
on the C-VLAN. To allow packets to be forwarded downstream before any packets
are forwarded upstream, forwarding entries can be configured statically.
All broadcast and multicast packets are forwarded both upstream and downstream.
Unlike the usual CC VLAN, the S/C-VLAN CC may require extraction of protocol
packets. In this case, the VLAN is called a protocol-aware S/C-VLAN CC. The
following protocol-aware functions can be used with the S/C-VLAN CC:
• IGMP proxy
• DHCP relay (see following note regarding ARP proxy)
• PPPoE relay
Note — If DHCP relay is enabled, ARP proxy is not enabled. This

deviates from the standard behavior for an RB VLAN or C-VLAN
learning VLAN, where ARP proxy is enabled automatically when
DHCP relay is enabled. With the ARP proxy disabled, ARP requests
from upstream are not handled by the proxy, but are passed through
to the ONT.
C-VLAN learning is not supported on the NT. The operator can configure the
S/C-VLAN CC on the NT as either an RB or CC VLAN. If IGMP proxy is required,
the VLAN must be configured as an RB VLAN on the NT, with multicast flooding
enabled.
Figure 21-4 shows an example of an S/C-VLAN CC configuration:
• Each subscriber will have the same three services identified by C-VLAN IDs 2,
6, and 7.
• The three C-VLAN IDs are translated to the common C-VLAN ID 40, which
uniquely identifies the subscriber.
• Each service uses a stacked VLAN, with a different S-VLAN ID for each service.
The S-VLANs are per service and are shared across all subscribers that share the
same service provider. Although the services are all configured as HSI services, they
are used for HSI (C-VLAN 2), voice (C-VLAN 6), and video (C-VLAN 7).

Figure 21-4 S/C-VLAN CC configuration example
C-VLAN tagged C-VLAN tagged

(VID = 40) (VID = 2)
S-VLAN 100

(VID = 40) ONT 1 (VID = 6)
S-VLAN 200

(VID = 40) (VID = 7)
S-VLAN 300
20717
Ethernet services and C-VLAN learning mode

C-VLAN learning mode is also used for Ethernet services. Ethernet services for
business and residential applications are implemented on the 7342 ISAM FTTU
using an Ethernet virtual connection (EVC) model. The EVC model can be
configured in a number of ways to provide a single service to multiple subscribers,
or multiple services to a single subscriber. An internal EVC with bundling is
configured in C-VLAN learning mode. See section 28.4 in chapter 28 “Ethernet
services for business and residential applications” for more information.
Flow mirroring mode

The 7342 ISAM FTTU supports mirroring of subscriber traffic. Mirroring is the
process of duplicating packets. The original packets are forwarded to their
destination and a copy is sent to a mirror VLAN. The mirror packets can be viewed
using a packet sniffer device that is attached to the destination mirror port.
Mirroring can be used to:
• troubleshoot problems with subscriber packet delivery and content
• help service providers meet regulations by providing itemized call records and
wiretaps, as authorized by investigative authorities
The 7342 ISAM FTTU supports up to 16 flow mirroring VLANs. Each flow
mirroring VLAN can be associated with one or more bridge ports, including:
• ONT Ethernet port
• MoCA port
• VoIP client
• VDSL2 port
Mirroring is available for upstream and downstream unicast traffic; multicast traffic
is not mirrored.

Tagging of mirror packets
Mirroring of traffic occurs on the LT card. The mirror packet inherits the source and
destination MAC addresses, and the priority level of the original packet; the outer
VLAN ID is replaced with the VLAN ID of the flow mirroring VLAN. Table 21-2
lists the field specifications for tagging of mirror packets.
Table 21-2 Tagging specifications for mirror packets
Field Value
MAC source address MAC source address of original packet
MAC destination address MAC destination address of original packet
VLAN ID VLAN ID of flow mirroring VLAN
p-bit p-bit of original packet
The original downstream packets are forwarded to the subscriber, the original
upstream packets are forwarded to the network, and the mirror packets are forwarded
to their new VLAN. No learning of MAC or C-VLAN addresses is performed for
these VLANs.
Summary of features
Table 21-3 summarizes the 7342 ISAM FTTU features of the flow mirroring
VLANs.
Table 21-3 Features of flow mirroring VLANs
Feature Support
Support for up to 16 flow mirroring VLANs ✓

Mirroring of multiple bridge ports to the same flow mirroring VLAN ✓
Mirroring of downstream traffic from the network side ✓
Mirroring of upstream traffic originating from a subscriber port ✓
No learning of MAC or C-VLAN addresses ✓
21.4 VLAN models
The 7342 ISAM FTTU supports two VLAN configuration models:

• VLAN per subscriber model
• VLAN per service model
Each model is described in the following sections.

VLAN per subscriber model

In the VLAN per subscriber model, each ONT has a unique RB or CC VLAN.
Figure 21-5 shows the network topology of the VLAN per subscriber model for two
subscribers. One subscriber is connected using a modular ONT (M-series) and the
other is shown connected using either an indoor ONT (I-series) or an outdoor ONT
(O-series).
Figure 21-5 Network topology of the VLAN per subscriber model for two subscribers
O-series ONT
NT LT I-series ONT RG
VLAN Ethernet
(subscriber)
10/100/1000 Base T 10/100
Base T
Computer
VLAN IPTV
(IPTV)
Voice Phone
Phone
Set-top box
M-series VDSL
ONT VDSL modem RG
VLAN Ethernet
(subscriber) 10/100/ 10/100
1000 Base T
IPTV Base T Computer
Voice
Phone
Voice
Set-top box
Phone Phone
18194
Figure 21-6 shows the connection of a subscriber using the business ONT.

Figure 21-6 VLAN per business ONT subscriber connection
Business
NT LT ONT RG
VLAN Ethernet
(subscriber)
10/100/1000 Base T 10/100/1000
Base T
Computer
VLAN IPTV
(IPTV)
Voice Phone
Phone
VLAN MEF-8
(CES DS1/E1) DS1/E1 Set-top box
18959
There can be a maximum of eight GPON encapsulated module (GEM) port

identifications (IDs) for each Ethernet UNI port at the ONT. This means that each
service must use less than eight priority bits and less than eight port IDs if there is
more than one service on a UNI.
A VLAN per subscriber carries traffic with all levels of priority to the network. Each
LAN port may have one or more GEM port IDs on the GPON interface, but the
port IDs are all attached to the same VLAN as a single bridge port.
At startup, the residential gateway (RGW) or router sends a dynamic host
configuration protocol (DHCP) request to get the IP address allocated. The gateway
can set the priority bits for each service in the Ethernet frames that it sends upstream.
Alternatively, the ONT can perform differentiated service code point (DSCP) to
priority bit (p-bit) marking.
The voice GEM port ID must be a separate bridge port in this model, but is attached
to the same VLAN for the subscriber as the other port ID of the subscriber.
Alternatively, the voice bridge port from all subscribers are attached to a dedicated
voice VLAN.
For the business ONT, a separate VLAN and bridge port are used for CES DS1 and
E1 traffic across the GPON using MEF-8 layer 2 Ethernet packetization.
The VLAN per subscriber model supports configuration for stacked VLANs or
unstacked VLANs. In unstacked VLANs, the service VLAN (S-VLAN) is unique to
a subscriber; in stacked VLANs, the combination of (S-VLAN, C-VLAN) is unique
to a subscriber.
VLAN per service model

In the VLAN per service model, every service is assigned a RB VLAN. All
subscriber bridge ports associated with a service are attached to the corresponding
VLAN.
Figure 21-7 shows the network topology of the VLAN per service model where
subscribers have three different services: voice, IPTV, and data. Each of these
services is provided through a separate bridge port and a separate VLAN.

Figure 21-7 VLAN per service model
O-series ONT
VLAN Ethernet
(Data)
10/100/1000 Base T 10/100
Base T
Computer
VLAN IPTV
(IPTV)
Voice Phone
Phone
Set-top box
M-series VDSL
ONT VDSL modem RG
VLAN Ethernet
(Voice) 10/100/ 10/100
1000 Base T
Voice
Phone
Voice
Set-top box
Phone Phone
18227
Figure 21-8 shows the network topology of the VLAN per service model where
subscribers have three different services: voice, IPTV, and data. In this case, the
shared S-VLAN for VoIP services allows ONT to ONT communication via the LT
card. Each of these services is provided through a separate bridge port and a separate
VLAN.

Figure 21-8 VLAN per service model with shared S-VLAN for VoIP
O-series ONT
VLAN Ethernet
(Data)
10/100/1000 Base T 10/100
Base T
Computer
VLAN IPTV
(IPTV)
Voice Phone
Phone
Shared
S-VLAN
Set-top box
M-series VDSL
ONT VDSL modem RG
VLAN Ethernet
(Voice) 10/100/ 10/100
1000 Base T
Voice
Phone
Voice
Set-top box
Phone Phone
20049
Figure 21-9 shows the VLAN per service model for a business ONT that has four
services: voice, IPTV, data, and CES DS1 or E1. The DS1 or E1 traffic is
encapsulated as layer 2 Ethernet using MEF-8 for transport across the GPON.
Figure 21-9 VLAN per service model for the business ONT
Business
NT LT ONT RG
VLAN Ethernet
(data)
10/100/1000 Base T 10/100/1000
Base T
Computer
VLAN IPTV
(IPTV)
VLAN Voice Phone
(voice)
Phone
VLAN MEF-8
(CES DS1/E1) DS1/E1 Set-top box
18958

21.5 VLAN tagging
VLAN tag support affects service frame delivery and performance. Tagging of an
Ethernet frame consists in adding a IEEE.802.1q tag of four bytes that specifies the
VLAN ID and the p-bit (from 0 to 7). Figure 21-10 shows tagging of an untagged
frame. Because a VLAN tag is added, the trunking device recalculates the frame
check sequence (FCS) on the modified Ethernet frame.
Figure 21-10 Tagging of an Ethernet frame
DA X
SA TYPE/LEN DATA FCS Untagged Frame
DA SA TAG TYPE/LEN DATA FCS Tagged Frame

20035
Frames coming from the network side are generally tagged with a VLAN used in
either RB or CC mode. Untagged frames might also be received, for example, when
a network port is attached to a VLAN-unaware device. In this special case, a
port-based default VLAN is normally required on the network port. Where a
port-based default VLAN is not specified, untagged frames are discarded.
Frames coming from the subscriber side can be tagged or untagged.
Each S-VLAN and ONT UNI are configurable for tagging:
• An S-VLAN on the PON is configurable for tagging in one of three VLAN
tagging modes, and in one of three upstream p-bit marking modes.
• An ONT UNI is configurable for tagging in one of two downstream tagging
modes, and in one of six upstream tagging modes.
The 7342 ISAM FTTU alters the frame at the LT based on the tagging configuration
of the S-VLAN, and at the ONT based on the upstream and downstream tagging
configuration of the ONT UNI. The 7342 ISAM FTTU applies the same VLAN
tagging configuration to all traffic in the same S-VLAN, and the same upstream and
downstream ONT UNI tagging configuration to all services and flows on the same
port.
The following sections describe:
• VLAN tagging modes at the LT
• P-bit marking modes at the LT
• Downstream tagging modes at the ONT UNI
• Upstream tagging modes at the ONT UNI
• Compatible tagging modes

VLAN tagging modes at the LT

The 7342 ISAM FTTU supports the following S-VLAN tagging modes:
• Stacked VLAN mode
• Unstacked VLAN mode
• VLAN pass-through mode
The VLAN tagging modes are described in the following sections.
Stacked VLAN mode
VLAN stacking is a technique that allows the VLAN space in a network to be

scalable beyond the traditional 4000-VLAN space. VLAN stacking introduces
another VLAN layer. One “outer” VLAN can bundle a number of “inner” VLANs,
similar to one LAN bundling a number of VLANs. One service-VLAN (S-VLAN)
bundles multiple smaller customer-VLANs (C-VLANs).
VLAN stacking supports an aggregation model such that you can assign multiple
subscribers to the same S-VLAN. Each subscriber is assigned a unique C-VLAN.
In VLAN stacking, the NSP can specify subscriber end-to-end connectivity while
remaining transparent to the EMAN. The S-VLAN at the EMAN side is associated
with a GPON port at the LT card. In the downstream direction, the LT strips the
frames of their outer tag, and C-VLANs, which were carried within the S-VLAN, are
then passed through to the subscribers that are associated with the GPON port.
In the upstream direction, the P-OLT receives frames from the ONTs that are either
priority-tagged or C-VLAN tagged. The P-OLT adds the S-VLAN tag and sends the
frames to the network with both tags attached. In some cases, such as for internal
EVCs with all-to-one bundling, triple-tagged frames are sent and received from the
network. All traffic in the S-VLAN is forwarded to the NSP.
In a frame, the S-VLAN is distinguished from the C-VLAN through EtherType:
• EtherType of the S-VLAN is provisionable at the system level using the CLI
command configure system with a default value of 8100 hexadecimal
• EtherType of the C-VLAN is always 8100 hexadecimal
A stacked VLAN can also be enabled for single-tagged frames. In this case,
single-tagged frames are passed through downstream to the subscribers as untagged
frames, and upstream to the network as singled-tagged frames.
Figure 21-11 shows a CC VLAN in stacked VLAN mode.

Figure 21-11 Cross-connect VLAN in stacked VLAN mode
C-VLAN to GPON port

cross-connects
EMAN P-OLT GPON
S-VLAN GPON ports
C-VLANs C-VLANs
to NSPs to ONTs
18925
Note — In stacked VLAN mode, a single C-VLAN per ONT can be

configured for all voice traffic originating from the ONT. In this
provisioning scenario, both bearer and signaling traffic use the same
C-VLAN. This feature is not applicable for the M-300 series modular
ONTs.
Unstacked VLAN mode
Unstacked VLANs carry frames that are singled-tagged. When VLANs are
configured as unstacked, the P-OLT sends frames to the network with a single
S-VLAN tag, and frames to the ONT as priority-tagged.
Starting from 7342 R4.7, it is possible to perform downstream VLAN translation
based on the network side C-VLAN. It should be noted that this mode is not
supported on some of the legacy ONTs (that is, Package A ONTs only support
downstream translation of all the traffic in a particular GEM port to a UNI side
CVLAN). To avoid issues on these ONTs, it is recommended to change from
unstacked VLAN mode to VLAN pass-through mode.
VLAN pass-through mode allows single- and double-tagged frames to be

transparently passed through unchanged from the network to the RGW, and from the
RGW to the network. In the VLAN pass-through mode, the RGW is responsible for
tagging the frames with their C-VLAN ID and p-bit.
P-bit marking modes at the LT

An S-VLAN is configurable for p-bit marking in one of three modes. The LT sets the
p-bit in the outer tag of an upstream frame based on the p-bit marking mode of the
S-VLAN that is carrying the frame, as described in Table 21-4. The LT does not
change the p-bit in a downstream frame.

Table 21-4 P-bit marking mode
P-bit marking mode Description
copy The LT sets the p-bit in the S-VLAN tag to the p-bit in the C-VLAN tag of
the frame.
set The LT sets the p-bit in the S-VLAN tag to the default p-bit specified for
the S-VLAN.
map The LT translates the p-bit in the C-VLAN tag to an S-VLAN p-bit using the
C-VLAN to S-VLAN mapping profile, and sets the p-bit in the S-VLAN tag
to the translated value.
The option copy applies to three VLAN tagging modes (stacked, unstacked, and
pass-through). The option set applies to stacked or unstacked mode. The option map
applies only to an S-VLAN in stacked VLAN mode, to enable a network provider to
bundle a number of C-VLANs in an S-VLAN for a NSP while retaining the
subscriber p-bit. For a VLAN in either unstacked VLAN mode or pass-through
mode, the C-VLAN p-bit inserted by the CPE must be preserved in the S-VLAN tag.
A check mark in Table 21-5 shows compatible configurations.
Table 21-5 Compatible configurations for p-bit marking mode
VLAN mode VLAN tagging P-bit marking mode

mode
Copy Set Map
Residential Stacked ✓ ✓ ✓
bridge
Unstacked ✓ ✓
Pass- ✓
through
Cross-connect Stacked ✓ ✓ ✓
Unstacked ✓ ✓
Pass- ✓
through
CVLAN-learning Stacked ✓ ✓ ✓
Downstream tagging modes at the ONT UNI

The 7342 ISAM FTTU supports the following downstream ONT UNI tagging
modes:
• Transmit to port with a tag
• Transmit to port without a tag
Transmit to port with a tag
The transmit to port with a tag allows the frames to pass through from the ONT to
the CPE as tagged frames.

Transmit to port without a tag
The transmit to port without a tag strips the frames of their outer tag. Therefore,
double-tagged frames received at the ONT UNI are passed through as singled-tagged
frames; all others are passed through as untagged frames.
Upstream tagging modes at the ONT UNI

The 7342 ISAM FTTU supports the following upstream ONT UNI tagging modes:
• Untrusted mode
• VLAN translation mode
• VLAN translation mode with EtherType classification
• EtherType classification mode
• Flexible mode
Whereas all downstream traffic is considered trusted, upstream traffic can be either
trusted or untrusted. When the CPE is not a trusted device, the ONT UNI is
configured for upstream tagging in untrusted mode. All other tagging modes are
reserved for traffic from a trusted device.
The upstream tagging modes are described in the following sections.
Untrusted mode
The untrusted mode supports traffic from an untrusted CPE. The ONT does not trust
the markings in the frame. The ONT will overwrite the p-bit and C-VLAN ID of the
frames with the values configured for that particular ONT UNI.
In the VLAN pass-through mode, the ONT accepts the markings inserted by the
CPE, and processes the frames, based on the tags received from the subscriber. If an
IP frame is not tagged by the subscriber, the ONT can optionally derive the p-bit
from the DSCP in the IP header of the frame or use the port-based default.
VLAN translation mode
VLAN translation mode provides flexibility in managing VLANs; it supports VLAN

swapping. It allows the customer to map a C-VLAN on the subscriber side to a
C-VLAN on the network side, so that when a VLAN is sent upstream, the same
VLAN is returned. The network provider can configure a mapping table between
C-VLANs and S-VLANs to accommodate C-VLAN to S-VLAN translation
according to WT-101. Package A, C, and H (current generation) ONTs do not
support downstream p-bit translation when in VLAN translation mode
The network-side VLAN is typically configured in VLAN pass-through mode,
although VLAN translation mode can also operate in both the stacked and unstacked
VLAN modes. In both the stacked and unstacked VLAN modes, when a subscriber
sends a C-VLAN upstream, the same C-VLAN tag is returned.

Figure 21-12 provides a VLAN translation mode example.
Figure 21-12 VLAN translation mode example
ONT translates
C-VLAN 200 to C-VLAN 500
C-VLAN 300 to C-VLAN 600
C-VLAN400 to C-VLAN 700
Default C-VLAN to C-VLAN 800
or drop
RGW adds C-VLANs.

OLT passes C-VLANs thru Any service can
as S-VLANS (do not use any p-bit
Service-1 overwrite VID or P-bits)
1
PC
4
Service-2 2 RG 5
ONT 6 Phone
OLT
3
HSI Service-1 Trusted
PORTID 101, Mode STB
Service-3 102: pbits 0-7
HSI Service-2
PORTID 103,
104: pbits 0-7
HSI Service-3
PORTID 105,
106: pbits 0-7
1 S-VLAN = 500 4 C-VLAN = 200

2 S-VLAN = 600 5 C-VLAN = 300
3 S-VLAN = 700 6 C-VLAN = 400
19046
In this example, HSI services one, two, and three are configured in VLAN translation
mode on the same ONT. Table 21-6 shows the VLAN mapping of UNI-side
C-VLANs to network-side C-VLANs for each HSI service. The S-VLANs to which
the HSI services are bound are configured in the VLAN pass through mode.
Table 21-6 VLAN translation configuration example
Service UNI-side C-VLAN Network-side C-VLAN
1 200 500
2 300 600
3 400 700

VLAN translation mode with EtherType classification
The VLAN translation with EtherType classification mode allows a VLAN on the
subscriber side to be mapped to a VLAN on the network side base. The ONT uses
the C-VLAN ID, EtherType field, and p-bit in the frame to locate the corresponding
service.
For VLAN translation in combination with EtherType classification in unstacked,
pass-through mode, you can provision the EtherType, UNI C-VLAN, and network
C-VLAN combination, as required. This allows PPPoE and IPoE data paths that are
identified using the same p-bit and the same C-VLAN to be mapped to different
network VLANs. The p-bit and EtherType values are preserved during VLAN
translation. The combination of EtherType, p-bit, and C-VLAN values are used to
identify the network-side VLAN in the upstream direction. Downstream, the
network-side VLAN is translated into the appropriate C-VLAN. Package A, C, and
H (current generation) ONTs do not support downstream p-bit translation when in
VLAN translation mode.
By configuring the UNI with the correct EtherType and VLAN translation
combination, you can map the correct upstream and downstream forwarding
combinations. Table 21-7 shows the upstream forwarding configurations.
Table 21-7 VLAN translation and EtherType classification for upstream forwarding
Incoming Incoming Incoming Outgoing Outgoing Outgoing Outgoing

C-VID p-bit EtherType C-VID p-bit EtherType port ID
200 5 IPoE 600 5 IPoE 2000
200 6 IPoE 600 6 IPoE 2000
200 2 PPPoE 700 2 PPPoE 2005

300 5 IPoE 800 5 IPoE 2006
300 6 IPoE 800 6 IPoE 2007
Table 21-8 shows the downstream forwarding configurations.
Table 21-8 VLAN translation and EtherType classification for downstream forwarding
Incoming Incoming Incoming Incoming Outgoing Outgoing Outgoing

port ID C-VID p-bit EtherType C-VID p-bit EtherType
2000 600 5 IPoE 200 5 IPoE

2000 600 6 IPoE 200 6 IPoE
2005 700 2 PPPoE 200 2 PPPoE
2006 800 5 IPoE 300 5 IPoE

2007 800 6 IPoE 300 6 IPoE

EtherType classification mode
EtherType classification mode classifies traffic by EtherType. When a frame is

received, the corresponding EtherType service is selected based on the EtherType
and p-bit in the outer tag of the frame. The frame is sent unchanged to the LT on the
corresponding PPPoE or IPoE service.
Figure 21-13 provides an example of two HSI services on the same ONT UNI in
EtherType classification mode; the S-VLANs to which the HSI services are bound
are configured in unstacked VLAN mode.
Figure 21-13 EtherType classification mode
ONT classifies upstream traffic

PPPoE traffic to GEM PORTS 101, 102
IPoE traffic to GEM PORTS 103, 104
S-VLAN = 500
RGW sends both
OLT overwrites the S-VLAN PPPoE and IPoE
tag and sends its as a single traffic on the same
Service-2 tagged frame. Ethernet Port
to ONT.
PC
IPoE
RG
PPPoE
ONT
OLT
HSI Service-1 Trusted
PORTID 101, P-bits 0-3 Mode STB
Service-1 PORTID 102, P-bits 4-7
HSI Service-2
S-VLAN = 700 PORTID 103, P-bits 0-3
PORTID 104, P-bits 4-7
20034
Flexible mode
The flexible mode provides different configuration options that allow a network
provider to control how frames are processed at the ONT. In flexible mode, the
following processing options are available:
• ability to discard or process untagged frames received upstream at the ONT
• ability to discard or process priority-tagged frames received upstream at the ONT
• ability to priority-mark untagged IP frames from a trusted CPE using either the
DSCP in the IP header or the port-based default p-bit
• ability to forward priority-tagged frames received upstream at the ONT as either
priority-tagged frames or as C-VLAN tagged frames
• ability to simultaneously pass-through singled-tagged and double-tagged frames
from the CPE to the LT
• ability to screen singled-tagged and double-tagged frames in upstream direction
using the tag protocol identifier (TPID); non-matching frames are processed as
untagged frames

• ability to tag single and double-tagged frames with their TPID in the downstream
direction
• ability to translate a subscriber VLAN on the UNI side to its equivalent subscriber
VLAN on the network side in both the upstream and downstream directions
• ability to translate a subscriber p-bit on the UNI side to the subscriber p-bit on the
network side in both the upstream and downstream directions
Different configuration options can be combined, to meet a specific configuration

requirement. The flexible mode is principally used with Ethernet services for
business and residential applications that are configured in the two-level hierarchy of
portal and flow; see Chapter 28 for more information on these services.
Compatible tagging modes

The LT and the ONT process frames independently. The operator must ensure that
the tagging configuration of the S-VLAN is compatible with both the downstream
and the upstream tagging configuration of the ONT UNI.
See the VLAN tagging training section in the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI for a list of compatible tagging
modes.
21.6 C-VLAN differentiated services on a UNI
You can configure a VLAN to support more than one service in the same ONT UNI
by using the ENT-PONVLAN command to configure the VLAN to be in p-bit
overlapping mode.
The p-bit overlapping mode allows the 7342 ISAM FTTU to support various
services on an ONT UNI that share the same stacked S-VLAN, but are differentiated
by unique C-VLANs. The VLAN must be configured as a residential bridge and use
stacked tagging in order for it to be configured for the p-bit overlapping mode.
In non-p-bit overlapping mode (the default mode), the PON VLAN has normal
stacked S-VLAN behavior.
Support for C-VLAN differentiated services on a UNI is only provided by GLT8 and
GLT4 cards.

21.7 Frame processing at the LT
The LT processes a frame in the downstream direction based on the VLAN tagging
mode of the S-VLAN, and in the upstream direction based on the VLAN tagging
mode and p-bit marking of the S-VLAN. Each VLAN tagging mode and p-bit
marking mode have their own set of tagging rules, which instruct the LT how to
process the frames before sending them to the ONT or to the NT.
• In the downstream direction, the LT can receive a single-tagged, double-tagged,
or triple-tagged frame from the NT, and can send a double-tagged,
singled-tagged, priority-tagged, or untagged frame to the ONT.
• In the upstream direction, the LT can receive a priority-tagged, single-tagged, or
double-tagged frame from the ONT, and can send a single-tagged, double-tagged,
or triple-tagged frame to the network
The following sections describe VLAN tagging at the LT:

• Downstream tagging at the LT
• Upstream tagging at the LT
Downstream tagging at the LT

In the downstream, the LT either overwrites the outer tag of the frame, strips the
frame of its outer tag, or leaves the outer tag of the frame unchanged based on the
VLAN tagging mode of the S-VLAN. Table 21-9 lists the possible combinations of
VLAN modes, tagging modes, and the corresponding downstream tagging operation
at the LT.
Table 21-9 Downstream tagging at the LT
VLAN mode VLAN tagging LT

mode
Overwrites outer Strips outer tag Leaves outer tag
tag unchanged
Residential Stacked (1) ✓

bridge
Unstacked ✓
pass- ✓
through
Cross- Stacked (1) ✓

connect Unstacked ✓
Pass- ✓
through
CVLAN- Stacked (1) ✓

learning
Note
(1) A VLAN in stacked mode can be enabled for single-tagged frames. In this special case, the LT sends
an untagged frame on the PON to the ONT.

The downstream tagging operations at the LT are described in detail in the following
sections
Downstream tagging in stacked VLAN mode
Table 21-10 describes the tagging of downstream frames at the LT in stacked VLAN
mode, and the resulting frames sent by the LT to the ONT.
Table 21-10 Downstream tagging at the LT in stacked VLAN mode
NT to LT LT LT to ONT
The NT sends a single-tagged If the S-VLAN is not enabled for —

frame to the LT. (S-VLAN single-tagged frame, the LT discards
tag) the frame.
If the S-VLAN is enabled for single- The LT sends an untagged

tagged frames, the LT strips the frame to the ONT.
frame of its outer tag.
The NT sends a The LT strips the frame of its outer The LT sends a
double-tagged frame to the tag. single-tagged frame to the
LT. (S-VLAN and C-VLAN tag) ONT. (C-VLAN tag)
The NT sends a triple-tagged The LT strips the frame of its outer The LT sends a
frame to the LT. (S-VLAN tag. double-tagged frame to the
and C-VLAN tag) ONT. (C-VLAN tag)
Downstream tagging in unstacked VLAN mode
Table 21-11 describes the tagging of downstream frames at the LT in unstacked

VLAN mode, and the resulting frames sent by the LT to the ONT.
Table 21-11 Downstream tagging at the LT in unstacked VLAN mode
The NT sends a single-tagged The LT sets the VLAN ID in the tag to The LT sends a
frame to the LT. (S-VLAN 0. priority-tagged frame to the
tag) ONT.
The NT sends a The LT discards the frame. —

double-tagged frame to the
LT. (S-VLAN and C-VLAN tag)
The NT sends a triple-tagged The LT discards the frame. —

frame to the LT. (S-VLAN
and C-VLAN tag)
Downstream tagging in VLAN pass-through mode
Table 21-12 describes the tagging of downstream frames at the LT in VLAN

pass-through mode, and the resulting frames sent by the LT to the ONT.

Table 21-12 Downstream tagging at the LT in VLAN pass-through mode
The NT sends a single-tagged The LT leaves the frame The LT sends a

frame to the LT. (S-VLAN unchanged. (1) single-tagged frame to the
tag) ONT. (S-VLAN tag)
The NT sends a The LT leaves the frame The LT sends a

double-tagged frame to the unchanged. (1) double-tagged frame to the
LT. (S-VLAN and C-VLAN tag) ONT. (S-VLAN and C-VLAN
tag)
The NT sends a triple-tagged The LT discards the frame. —

frame to the LT. (S-VLAN
and C-VLAN tag)
Note
(1) Where a VLAN is configured in pass-through mode, the ONT UNI port is configured as a tagged port
to allow the VLAN ID to pass through to the CPE.
Upstream tagging at the LT

Table 21-13 lists the possible combinations of VLAN modes, tagging modes, and
p-bit marking modes, and the corresponding upstream tagging operation at the LT.
Table 21-13 Upstream tagging at the LT
VLAN VLAN P-bit LT

forwarding tagging marking
mode mode mode (1) Overwrites Inserts Inserts Inserts Checks for
VLAN ID in S-VLAN C-VLAN translated allowance
outer tag p-bit in p-bit in p-bit in of singled-
outer tag outer tag outer tag tagged
frames
(4095) (2)
Residential Stacked copy ✓ ✓

bridge
set ✓ ✓
map ✓ ✓
Unstacked copy ✓
Pass- copy ✓
through
Cross- Stacked copy ✓ ✓

connect set ✓ ✓
map ✓ ✓
Unstacked copy ✓
Pass- copy ✓
through
(1 of 2)

VLAN VLAN P-bit LT

forwarding tagging marking
mode mode mode (1) Overwrites Inserts Inserts Inserts Checks for
VLAN ID in S-VLAN C-VLAN translated allowance
outer tag p-bit in p-bit in p-bit in of singled-
outer tag outer tag outer tag tagged
frames
(4095) (2)
CVLAN- Stacked copy ✓

learning set ✓
map ✓
(2 of 2)
Notes
(1) The p-bit marking mode applies in the upstream direction only.
(2) When singled-tagged frames are allowed in a stacked VLAN, the LT strips the C-VLAN tag before adding the S-VLAN tag if
the C-VLAN ID has the special value of 4095.
The upstream tagging operations at the LT are described in the following sections
Upstream tagging in stacked VLAN mode
As a general rule, in stacked VLAN mode, the LT adds the S-VLAN tag before
sending the frame to the network. However, if the S-VLAN is enabled for
single-tagged frames, the LT strips the C-VLAN tag before adding the S-VLAN tag
if the C-VLAN ID has a special value, and sends a single-tagged frame to the
network.
The LT sets the VLAN ID in the outer tag to the VLAN ID of the S-VLAN, and sets
the p-bit in the outer tag based on the p-bit marking mode of the S-VLAN, as
described in Table 21-4.
Table 21-14 describes the tagging of upstream frames at the LT in stacked VLAN
mode, and the resulting frames sent by the LT to the NT.
Table 21-14 Upstream tagging at the LT in stacked VLAN mode
ONT to LT LT LT to NT
The ONT sends a The LT adds the S-VLAN tag to the The LT sends a
priority-tagged frame priority-tagged frame. double-tagged frame to the
to the LT. NT.
The ONT sends a tagged If the S-VLAN is not enabled for The LT sends a
frame to the LT. single-tagged frames, the LT adds the double-tagged frame to the
(C-VLAN tag) S-VLAN tag to the tagged frame. NT.
If the S-VLAN is enabled for The LT sends either a single

single-tagged frames, and the C-VLAN ID or double S-VLAN tagged
has the value 4095, the LT strips the frame.
C-VLAN tag, and adds the S-VLAN tag. (1)
If the S-VLAN is enabled for The LT sends a

single-tagged frames, and the C-VLAN ID double-tagged frame to the
does not have the value 4095, the LT NT.
adds the S-VLAN tag.
(1 of 2)

The ONT sends a The LT adds the S-VLAN tag to the The LT sends a triple-tagged
double-tagged frame to double-tagged frame. frame to the NT.
the LT. (S-VLAN and
C-VLAN tagged frame)
(2 of 2)
Note
(1) See the 7342 ISAM FTTU Operations and Maintenance Procedures Guide using TL1 and CLI for
configuration requirements in stacked VLAN mode.
Upstream tagging at the LT in unstacked VLAN mode
Table 21-15 describes tagging of upstream frames at the LT in unstacked VLAN

mode, and the resulting frames sent by the LT to the NT.
Table 21-15 Upstream tagging at the LT in unstacked VLAN mode
The ONT sends a The LT overwrites the C-VLAN tag with The LT sends an S-VLAN
priority-tagged frame the S-VLAN tag, using the S-VLAN ID and tagged frame to the NT.
to the LT. the p-bit in the C-VLAN tag. (1)
The ONT sends a

single-tagged frame to
the LT. (C-VLAN tag)
The ONT sends a The LT discards the frame. −
double-tagged frame to
the LT. (S-VLAN and
Note
(1) For an S-VLAN in unstacked VLAN mode, the p-bit marking mode must be copy, to ensure that the
customer p-bit is preserved as inserted by the CPE.
Upstream tagging in VLAN pass-through mode
Table 21-16 describes the tagging of upstream frames at the LT in VLAN

pass-through mode, and the resulting frames sent by the LT to the NT.
Table 21-16 Upstream tagging at the LT in VLAN pass-through mode
The ONT sends a The LT overwrites the C-VLAN tag with The LT sends an S-VLAN
priority-tagged frame the S-VLAN tag, using the S-VLAN ID (1) tagged frame to the NT.
to the LT. and the p-bit in the C-VLAN tag. (2)
The ONT sends a

single-tagged frame to
the LT. (C-VLAN tag)
(1 of 2)

The ONT sends a The LT passes the frame through as is. The LT sends a
double-tagged frame to double-tagged frame to the
the LT. (S-VLAN and NT.
(2 of 2)
Notes
(1) To achieve the VLAN pass-through mode, so that the frame is sent to the network with the same
C-VLAN ID inserted by the CPE, the S-VLAN must be configured with the same C-VLAN ID.
(2) For an S-VLAN in VLAN pass-through mode, copy must be the p-bit marking mode so that the
customer p-bit, as inserted by the CPE, is preserved.
21.8 Frame processing at the ONT
An ONT UNI is configurable for tagging in one of two downstream tagging modes,
and in one of six upstream tagging modes. Each tagging mode has its own tagging
rules, which instruct the ONT how to process frames before sending them to the CPE
or to the LT.
• In the downstream direction, the ONT can receive a double-tagged,
single-tagged, priority-tagged, or untagged frame from the LT, and can send a
double-tagged, single-tagged, priority-tagged, or untagged frame to the CPE.
• In the upstream direction, the ONT can receive an untagged, priority-tagged,
single-tagged, or double-tagged frame from the CPE, and can send a
priority-tagged, single-tagged, or double-tagged frame to the LT.
The following sections describe tagging at the ONT:

• Downstream tagging modes at the ONT UNI
• Upstream tagging modes at the ONT UNI
• Downstream tagging at the ONT
• Upstream tagging at the ONT
Note — VLAN translation tagging behavior may differ depending on

the type of ONT or MDU. See the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI for more
information. Package A, C, and H (current generation) ONTs do not
support downstream p-bit translation when in VLAN translation
mode.
Downstream tagging at the ONT

Table 21-17 describes the downstream tagging operations at the ONT, based on the
downstream and upstream tagging modes of the forwarding ONT UNI port.

Table 21-17 Downstream tagging at the ONT
Upstream tagging mode of ONT UNI Downstream tagging at ONT

port
Transmit to port with a tag
Untrusted mode The ONT leaves the frame as is.

VLAN pass-through mode The ONT leaves the frame as is.
VLAN translation mode The ONT swaps the network-side customer VLAN ID
with the UNI-side customer VLAN ID.
VLAN translation mode with EtherType The ONT swaps the network-side customer VLAN ID
classification with the UNI-side customer VLAN ID.
EtherType classification The ONT leaves the frame as is.
Flexible mode If the flow is configured for VLAN or p-bit

translation:
• the ONT swaps the network-side C-VLAN ID with
the UNI-side C-VLAN ID, if applicable
• the ONT swaps the network-side customer p-bit
with the UNI-side customer p-bit, if
applicable. (1)
In the flexible mode, an ONT UNI has a configured

TPID value:
• for a single-tagged frame, the ONT inserts the
configured TPID value in the outer tag
• for a double-tagged frame, the ONT inserts the
configured TPID value in the outer tag and the
TPID value 0x8100 in the inner tag is
transparently passed through
Transmit to port without a tag (2)
All upstream tagging modes The ONT strips the downstream frame of its outer
tag.
Notes
(1) Downstream p-bit translation is not performed if more than one UNI-side p-bit is mapped to the
same network-side p-bit. The p-bit is passed through as is.
(2) When the CPE associated with an ONT UNI port can only generate, or accept untagged frames, data
frames transmitted towards the subscriber should be untagged frames.
Upstream tagging at the ONT

In the upstream direction, the ONT can receive an untagged, priority-tagged,
single-tagged, or double-tagged frame from a CPE. The ONT processes the frame in
four stages as follows, before sending it to the LT as a single-tagged or double-tagged
frame:
1 The ONT uses the QoS marker profile to process frames in the first stage. The
ONT performs an initial screening of frames using the screening criteria in the
QoS marker profile. If a frame is accepted, the ONT either tags the frame (if the
frame is untagged), overwrites the VLAN ID in the outer tag, or leaves the frame
as is.
2 The ONT matches the incoming frame to a service or flow on the ONT UNI. If
a match is not found, the frame is dropped.

3 Where VLAN and p-bit translation are required, the ONT performs the
translation in the outer tag of the frame.
4 The ONT determines the frame’s GEM port, by matching the p-bit in the outer
tag to the p-bit mapping of queues in the priority queue profile of the service or
flow. A non-matching frame is dropped; a matching frame is directed to the
GEM port.
The ONT forwards the frame to the LT on the corresponding service or flow.
Table 21-18 describes the p-bit marking rules for marking untagged frames by frame
type. These p-bit marking rules apply to all tagging modes. See the
CLI for configuration details.
Table 21-18 P-bit marking rules for untagged frames
Frame type P-bit marking rule

Untagged IP frame In untrusted mode, the ONT uses the default p-bit of the ONT UNI
port to mark an untagged IP frame. In all other tagging modes, the
ONT marks the frame with a p-bit in one of two ways:
• using the default p-bit for the ONT UNI port
• deriving the p-bit from the DSCP in the IP header using the DSCP
to p-bit mapping profile
Untagged Non-IP frame The ONT marks an untagged non-IP frame with its p-bit using the
default p-bit of the ONT UNI port.
The following sections describe the upstream tagging operations at the ONT by
upstream tagging mode.
Upstream tagging in untrusted mode
Table 21-19 describes the tagging of upstream frames at the ONT in untrusted mode,
and the resulting frames sent by the ONT to the LT.
Table 21-19 Upstream tagging at the ONT in the untrusted mode
Upstream ONT UNI CPE to ONT ONT ONT to LT

tagging mode
Untrusted mode The CPE sends an The ONT adds the C-VLAN tag using The ONT sends a
untagged frame to the the port-based default p-bit and tagged frame to
ONT. C-VLAN ID. the LT.
The CPE sends a The ONT overwrites the C-VLAN tag

priority-tagged frame to using the port-based default C-VLAN
the ONT. ID and p-bit.
The CPE sends a tagged

frame to the ONT.

Upstream tagging in VLAN pass-through mode
Table 21-20 describes the tagging of upstream frames at the ONT in the VLAN
pass-through mode, and the resulting frames sent by the ONT to the LT.
Table 21-20 Upstream tagging at the ONT in the VLAN pass-through mode

tagging mode
VLAN pass-through The CPE sends an The ONT tags the frame using the port-based The ONT sends a
mode untagged frame to the default C-VLAN ID, and sets the p-bit as tagged frame to the
ONT. described in Table 21-18. LT.
The CPE sends a The ONT leaves the frame unchanged. The ONT sends a
priority-tagged frame to priority-tagged
the ONT. frame to the LT.
The CPE sends a tagged The ONT leaves the frame unchanged. The ONT sends a
frame to the ONT. tagged frame to the
LT.
The CPE sends a The ONT discards the frame. −

double-tagged frame to
the ONT.
Upstream tagging in VLAN translation mode
Figure 21-14 shows the algorithm used by the ONT to translate a UNI-side C-VLAN
to a network-side C-VLAN in VLAN translation mode.

Figure 21-14 Translation algorithm in VLAN translation mode
VLAN-tagged frame
Untagged frame Priority-tagged frame
Add C-VLAN tag with Search for a service on the

C-VLAN ID set to ONT UNI port with matching
port-based default C-VLAN ID.
VLAN ID and p-bit set
to DSCP mapping value.
Was a Service match

matching is not found Search for a default service
C-VLAN ID on the ONT UNI port.
found?
Default service
Was a default is not found
service found?
Frame is dropped
Service match Default service

is found is found
Does the
default service have
a provisioned network-
side VLAN ID?
Network-side VLAN ID
Network-side VLAN ID is not provisioned
is provisioned for service for service
Overwrite the C-VLAN ID with Overwrite the C-VLAN ID with Retain originalRetain
C-VLANoriginal
ID
the network-side VLAN ID the network-side VLAN ID and p-bit. C-VLAN ID
and retain p-bit. and retain p-bit. and p-bit
19456
Table 21-17 describes the tagging of upstream frames at the ONT in VLAN
translation mode, and the resulting frames sent by the ONT to the LT.

Table 21-21 Upstream tagging at the ONT in VLAN translation mode

tagging mode
VLAN translation The CPE sends an The ONT tags the frame using the port-based The ONT sends a
mode untagged frame to the default C-VLAN ID, and sets the p-bit as priority-tagged
ONT. described in Table 21-18. frame (1), or tagged
The ONT then uses the algorithm in frame to the LT.
Figure 21-14 to overwrite the UNI-side C-VLAN
ID with the network-side C-VLAN ID.
The CPE sends a tagged The ONT uses the algorithm in Figure 21-14 to The ONT sends a
frame to the ONT. overwrite the UNI-side C-VLAN ID with the priority-tagged
network-side C-VLAN ID. frame (1), or tagged
frame to the LT.
The CPE sends a The ONT discards the frame. (2) −
double-tagged tagged
frame to the ONT.
Notes
(1) If the network-side VLAN ID has the value of zero, the ONT sends a priority-tagged frame, otherwise, the ONT sends a
tagged-frame.
(2) The ETSI MDUs can translate from a zero VLAN ID to a non-zero VLAN ID, but it cannot translate from a non-zero VLAN ID
to a zero VLAN ID. Therefore, for the ETSI MDU, upstream VLAN translation is possible, but downstream is not. As a result,
priority-tagged frames are not allowed from the CPE.
Upstream tagging in VLAN translation mode with EtherType classification
Figure 21-15 shows the algorithm used by the ONT to translate a UNI-side C-VLAN
to a network-side C-VLAN in VLAN translation mode with EtherType classification
mode.

Figure 21-15 Tagging of upstream traffic in VLAN translation mode with EtherType classification
Tagged frame
Untagged frame Priority-tagged frame
Add C-VLAN tag with: Search for a service on the

C-VLAN ID set to ONT UNI port matching both
port-based default C-VLAN ID and Ether Type.
V-LAN ID
p-bit set to DSCP
mapping value for an
IP packet
p-bit set to port-based
default p-bit for a Service match
non-IP packet Was a
matching is not found Search for a default service
C-VLAN ID on the ONT UNI port.
found?
Default service
Was a default is not found
service found?
Frame is dropped
Service match Default service

is found is found
Does the
default service have
a provisioned network-
side VLAN ID?
Network-side VLAN ID
Network-side VLAN ID is not provisioned
is provisioned for service for service
Overwrite theOverwrite
C-VLAN the
ID with
C-VLAN ID withOverwrite theOverwrite
C-VLAN the
ID with
C-VLAN ID
Retain
with originalRetain
C-VLANoriginal
ID
the network-side
the network
VLAN IDside VLAN ID the network-side
the network
VLAN IDside VLAN and
ID p-bit. C-VLAN ID
and retain p-bit.
and retain p-bit. and retain p-bit.
and retain p-bit. and p-bit
19457
Table 21-22 describes tagging of upstream frames at the ONT in VLAN translation
mode with EtherType classification, and the resulting frames sent by the ONT to the
LT.

Table 21-22 Upstream tagging at the ONT in VLAN translation mode with EtherType classification

tagging mode
VLAN translation The CPE sends an The ONT tags the frame using the port-based The ONT sends a
with EtherType untagged frame to the default C-VLAN ID, and sets the p-bit as priority-tagged (1)
classification mode ONT. described in Table 21-18. or tagged frame to
The ONT then uses the algorithm in the LT.
Figure 21-15 to overwrite the UNI-side C-VLAN
ID with the network-side C-VLAN ID.
The CPE sends a The ONT discards frame. −

priority-tagged frame to
the ONT.
The CPE sends a tagged The ONT uses the algorithm in Figure 21-15 to The ONT sends a
frame to the ONT. overwrite the UNI -side C-VLAN ID with the priority-tagged (1)
network-side C-VLAN ID. or tagged frame to
the LT.
Note
(1) The ONT sends a priority-tagged frame, if the network-side VLAN ID has the value of zero. Otherwise, the ONT sends a
tagged-frame.
Upstream tagging in EtherType classification mode
Table 21-23 describes tagging of upstream frames at the ONT in the EtherType
classification mode, and the resulting frames sent by the ONT to the LT.
Table 21-23 Upstream tagging at the ONT in EtherType classification mode
EtherType CPE to ONT ONT ONT to LT

classification of
frame
PPPoE The CPE sends an untagged The ONT tags the frame using the port-based The ONT sends a
frame to the ONT. default C-VLAN ID, and sets the p-bits as tagged frame on the
described in Table 21-18. PPPoE service.
priority-tagged frame to the priority-tagged
ONT. frame on the PPPoE
service.
frame to the ONT. tagged frame on the
PPPoE service.
ONT.
(1 of 2)

EtherType CPE to ONT ONT ONT to LT

classification of
frame
IPoE or anything The CPE sends an untagged The ONT tags the frame using the port-based The ONT sends a
else frame to the ONT. default C-VLAN ID, and sets the p-bit as tagged frame on the
described in Table 21-18. IPoE service.
priority-tagged frame to the priority-tagged
ONT. frame on the IPoE
service.
frame to the ONT. tagged frame on the
IPoE service.

ONT.
(2 of 2)
Upstream tagging in flexible mode
Table 21-24 describes the tagging of upstream frames at the ONT in flexible mode,
and the resulting frames sent by the ONT to the LT.

Table 21-24 Upstream tagging at the ONT in flexible mode

tagging mode
Flexible mode The CPE sends an If the ONT UNI is configured to drop untagged −
untagged frame to the frames, the ONT discards the frame.
ONT.
If the ONT UNI is configured to receive The ONT sends a
untagged frames, the ONT tags the untagged single-tagged frame
frame using the port-based default C-VLAN ID to the LT.
and sets the p-bit as described in Table 21-18.
If the flow is configured for VLAN translation,
the ONT swaps the C-VLAN ID in the outer tag
for the network-side C-VLAN ID.
If the flow is configured for p-bit translation,
the ONT swaps the p-bit in the outer tag for the
network-side customer p-bit.
The CPE sends a The ONT screens the frame for the TPID value −
priority-tagged frame to configured for the ONT UNI port. For a
the ONT. non-matching frame, the ONT processes the
frame as an untagged frame.
If the ONT UNI is configured to drop −

priority-tagged frames, the ONT discards the
frame.
If the ONT UNI is configured to pass-through The ONT sends a

priority-tagged frames, the ONT passes the priority-tagged
frame through as is. frame to the LT.
If the ONT UNI is configured to overwrite VLAN The ONT sends a

ID with the port-based C-VLAN ID, the ONT single-tagged frame
overwrites the VLAN ID. to the LT.
If the flow is configured for VLAN translation,
the ONT swaps the C-VLAN ID in the outer tag
for the network-side C-VLAN ID.
If the flow is configured for p-bit translation,
the ONT swaps the p-bit in the outer tag for the
network-side customer p-bit.
The CPE sends a The ONT screens the frame for the TPID value The ONT sends a
single-tagged frame to configured for the ONT UNI port. single-tagged frame
the ONT. • For a non-matching frame, the ONT to the LT.
processes the frame as an untagged frame.
• For a matching frame:
• If the flow is configured for VLAN
translation, the ONT swaps the C-VLAN
ID in the outer tag for the network-side
C-VLAN ID.
• If the flow is configured for p-bit
translation, the ONT swaps the p-bit in
the outer tag for the network-side
customer p-bit.
The CPE sends a The ONT screens the frame for the TPID value The ONT sends a
double-tagged frame to configured for the ONT UNI port. double-tagged
the ONT. • For a non-matching frame, the ONT frame to the LT.
processes the frame as an untagged frame.
• For a matching frame, if the flow is
configured for VLAN translation, the ONT
swaps the C-VLAN ID in the outer tag for
the network-side C-VLAN ID; the p-bit is
preserved.

21.9 Network interface CAC bandwidth check
A CAC check ensures available bandwidth on a network interface to support

requested services. Figure 21-16 illustrates the different levels in the network system
where a CAC bandwidth check is performed:
• at the SHub network port or link aggregation group (LAG) of network ports,
whenever a VLAN is added to the SHub network port or LAG
• for a S-VLAN, whenever a subscriber service, is added to an S-VLAN, or a flow
or portal is added to an S-VLAN with a bandwidth profile
• at the GPON at the LT card, whenever a subscriber service is added to the GPON,
or a flow or portal is added to the GPON with a bandwidth profile
Figure 21-16 CAC bandwidth check
Services, flows, or
Service portals configured
Traffic Flows with CIR/AIR/EIR
7342 OLT
GPON ONT
S-VLAN GPON CAC
at the
CAC at S-VLAN CAC for LT
GE NT port S-VLAN
or LAG Capacity
S-VLAN GPON
ONT
19239
For more information on bandwidth profiles, see Chapter 18 on “QoS”.
CAC at NT port or LAG

Whenever a SHub VLAN is created, the guaranteed downstream and upstream
bandwidths, as defined by the committed information rates (CIR), are specified.
When the SHub VLAN is associated with a 1-GE or 10-GE port, or a LAG on the
network SHub, a CAC check is performed on the port or LAG to determine if it has
sufficient bandwidth to support the new VLAN. Overbooking is not supported on the
SHub ports or LAGs.
Note — The default CIR for VLANs configured on the SHub is 100
kb/s.

Use the SHub Interface Port Control Status CLI command (show interface shub port)
to determine available upstream and downstream bandwidth on an SHub network
port before creating a VLAN on an network port or LAG. The SHub VLAN
Configuration CLI command (configure vlan shub) is used to configure upstream
and downstream bandwidth parameters on the SHub VLAN.
For information about CLI command syntax, refer to the 7342 ISAM FTTU CLI
Commands Guide.
CAC for S-VLAN capacity

Each S-VLAN is configured with the following bandwidth characteristics:
• downstream and upstream guaranteed bandwidths
• downstream and upstream overbooking factors to improve network efficiency
A CAC check is performed on an S-VLAN when a new service is provisioned, or
when a flow or portal is provisioned with a bandwidth profile. The CAC check
determines if the S-VLAN has available bandwidth to support the required EIR for
the service, flow, or portal. The CAC check ensures that the sum of the EIRs of all
services, flows, and portals on the S-VLAN is less than the S-VLAN guaranteed
bandwidth times the S-VLAN overbooking factor.
There are separate CAC checks for upstream and downstream directions.
PON CAC at the LT

The GPON performs limited upstream and downstream CAC checks to assure that
new service, flow, or portal provisioning does not exceed the available PON
bandwidth. The following calculations are performed when a new service is
provisioned, or when a flow or portal is provisioned with a bandwidth profile:
• The CIR identified in the bandwidth profile is added to the sum of all other CIR
of services, flows, and portals. The CIR sum is compared against the available
downstream PON bandwidth.
• The AIR identified in the bandwidth profile is added to the sum of all other AIR
of services, flows, and portals. The AIR sum is compared against the available
upstream PON bandwidth.
If the sum of all CIRs is less than the available downstream PON bandwidth, and the
sum of all AIRs is less than the available upstream PON bandwidth, then the
provisioning request is allowed.
The available downstream PON bandwidth is 2.488 Gb/s less the reserved bandwidth
for multicast less some reserved bandwidth for OMCI. The available upstream PON
bandwidth is 1.244 Gb/s less some bandwidth reserved for OMCI.

PON bandwidth
The bandwidth available on the PON can be considered when configuring the system
for maximum performance. The following information is available for a specific
PON:
• aggregate upstream provisioned CIR
• aggregate upstream provisioned AIR
• guaranteed upstream bandwidth that remains for further provisioning
• aggregate downstream provisioned CIR
• guaranteed downstream bandwidth that remains for further provisioning
• maximum downstream multicast bandwidth allowed
The operator can use this information to determine how much bandwidth is left to
allot in the upstream or downstream direction.
GPON and SHub VLAN bandwidth synchronization

The operator is responsible for ensuring that the bandwidth configured for a VLAN
on the NT is the same as the bandwidth configured for the corresponding VLAN on
the SHub.
21.10 User-to-user communication
User-to-user communication allows subscribers to communicate with one another

within the same VLAN. By default, the 7342 ISAM FTTU disables user-to-user
communication on all VLANs. In this state, all upstream traffic from a subscriber is
sent to the network service provider (NSP). However, the operator can enable
user-to-user communication on a per-VLAN basis. Up to ten VLANs can be enabled
for user-to-user communication.
Restrictions
User-to-user communication is limited to RB VLANs. User-to-user communication
does not apply to CC VLANs, which have only a single subscriber. However, for an
RB VLAN that is configured for MAC scalability, user-to-user communication is not
possible if MAC learning is disabled on the LT-side port.
Application
User-to-user communication is applicable in the case where a number of VoIP
subscribers share the same VoIP service VLAN (S-VLAN). Enabling user-to-user
communication allows a subscriber on one ONT to receive a call from a subscriber
on a second ONT in the same VLAN, as follows.
1 When a call is made, the originating ONT sends an ARP request to learn the
MAC address of the terminating ONT.

2 The LT does not respond to ARP requests received from its PON ports; it
forwards the ARP request upstream.
3 Enabling user-to-user communication causes the NT to redirect the ARP request
to the sending LT, so the LT can respond to internal ONT ARP requests on behalf
of ONTs in the same VLAN.
Note — An alternative solution is to enable local proxy ARP on an

upstream switch or router to respond to these ARP requests with its
own MAC address.
To configure VoIP for user-to-user communication:

• Enable user-to-user communication on the VoIP S-VLAN on the NT.
• Activate the proxy ARP function on the LT by enabling DHCP relay on the
PON VLAN.
21.11 VLAN bridging scalability
The 7342 ISAM FTTU supports two types of VLAN bridging: RB and CC bridging.
Table 21-25 describes the scalability of VLAN bridges. See Table 8-5 for more
information about service capacity.
Table 21-25 VLAN bridging scalability
MAC addresses per bridge 1 to 128 This number is configurable from 1 to 128.
port
Bridge ports per GLT2 384 384 = 3 per user x 128 users per GLT2. The
assumption is 2 UNIs per ONT.
Bridge ports per GLT4 768 768 = 3 per user x 256 users per GLT4. The
assumption is 2 UNIs per ONT.
Bridge ports per GLT8 4096 System wide limit is 64k
Bridge ports per residential 6176 6176 = 384 bridge ports per GLT2 x 16 GLT2 + 32
bridge reserved
Bridge ports per system 6176 6176 = 384 bridge ports per GLT2 x 16 GLT2 + 32
reserved
21.12 VPNs
The 7342 ISAM FTTU supports Layer 2 VPNs where the lease line for the SME
(small medium enterprise) domain is pure Layer 2 transparent in terms of
user-to-user traffic (for example, to allow downstream/upstream ARP broadcasts).
Support for Layer 2 VPNs by the 7342 ISAM FTTU requires disabling of MAC
learning on the S-VLAN of the L2 VPN entry configured; section 15.4 in
chapter 15 “Layer 2 forwarding” for more information about MAC learning.

The 7342 ISAM FTTU supports Layer 2 VPNs on EXNT cards; Layer 2 VPNs are
not supported on EHNT cards.
The 7342 ISAM FTTU uses a Layer 2 filtering database to redirect the frames in the
down stream direction for a pure leased line.


Services descriptions
22 — VoIP overview
23 — HSI service
24 — RF video services
25 — Triple play service delivery architecture in access network
26 — CES DS1 and E1 interfaces
27 — Support for the micro span CES
28 — Ethernet services for business and residential applications
29 — GENIP service

22.1 Overview 22-2
22.2 Voice gateway mode 22-4
22.3 H.248 softswitch mode 22-7
22.4 SIP modes 22-8
22.5 Dual SIP client mode using VEIP 22-14
22.6 VoIP service configuration 22-18
22.7 SIP data model and XML profiles 22-23
22.8 Digit map 22-63
22.9 Security 22-72
22.10 VoIP call and performance monitoring statistics 22-73

22.1 Overview
This chapter provides information about the implementation of the Voice over IP
(VoIP) service in the 7342 ISAM FTTU.
VoIP service operation modes

The 7342 ISAM FTTU provides different modes of operation for VoIP services.
These include voice gateway, H.248 softswitch, and session initiation protocol (SIP)
modes.
Voice gateway mode

When the service provider uses existing Class 5 switch for voice services, the
7342 ISAM FTTU uses the G6 voice gateway to interact with the switch and perform
loop emulation. The G6 voice gateway performs both the signaling and the bearer
path end-point functions.
H.248 softswitch mode

When the service provider uses the broadband data network for voice services, the
7342 ISAM FTTU interacts with the network through the ITU-defined H.248
protocol or the IETF-defined Megaco protocol to an H.248-based softswitch. In this
mode, the voice traffic and signaling may follow different paths through the network.
This mode is not applicable to package D ONTs.
SIP modes
When the service provider uses SIP for VoIP services, the system interoperates in
two SIP modes: SIP mode 1 or ‘thin client’ mode, and SIP mode 2 or ‘thick client’
mode. Package C and D ONTs only support SIP mode 2.
When configuring SIP using OMCIv2 via TL1, the Softswitch parameter identifies
the SIP gateway softswitch vendor. The format is four ASCII coded alphabetic
characters [A..Z] as defined in [ATIS-0322000]. A value of four null characters
indicates no particular vendor.
The setting of this Softswitch parameter signals to the ONT to use various types of
SIP. Until all softswitch vendor IDs are identified, package A, B, and H ONTs
interpret some specific settings as follows:
• THIN = legacy SIP 1 - Mode 1 SIP - thin client
• any other setting including null = legacy SIP 2 - Mode 2 SIP - thick client
In these modes of operation, the ONT performs user agent functionality. The two
modes of operation are to allow for different signaling behavior, especially for
advanced call features, to be handled correctly for the two very different signaling
characteristics.
The 7342 ISAM FTTU is designed to inhibit software download to the ONT when
an emergency calls (911) is in progress. This is in association with the Emergency
Call Active alarm. This functionality is not supported in package C and D ONTs.

TISPAN support
Building upon the work already done by 3GPP in creating the SIP-based IMS (IP
Multimedia Subsystem), TISPAN and 3GPP are now working together to define a
harmonized IMS-centric core for both wireless and wireline networks.
This harmonized ALL IP network has the potential to provide a completely new
telecom business model for both fixed and mobile network operators. Access
independent IMS will be a key enabler for fixed/mobile convergence, reducing
network installation and maintenance costs, and allowing new services to be rapidly
developed and deployed to satisfy new market demands.
The Alcatel-Lucent Feature Server 5000 is more than 80% compliant with all
TISPAN Release 1 features, with the exception of TS 183 023 (XCAP over the Ut
interface).
7342 ISAM FTTU access product line interoperates with Alcatel-Lucent TISPAN
compliant FS5000 from Release 04.04.16 and later.
Contact your Alcatel-Lucent support representative for a complete listing of all
TISPAN compliance details.
Common service operation mode features

Table 22-1 describes features that the VoIP service operation modes have in
common.
Table 22-1 Common features of VoIP service operation modes
Feature Description
802.1p The upstream VoIP traffic is marked with an 802.1p priority value according to the priority queue
profile and the following rules:
• It is recommended to use two priority queues.
• The priority queue with the highest mapped value is used for VoIP signaling, dynamic host
configuration protocol (DHCP) and file transfer protocol (FTP).
• The other priority queue is used for bearer traffic.
• For each traffic type, the traffic is tagged with the highest value mapped to its priority queue.
• In the downstream direction, other values mapped to the two priority queues are used to map
frames to the appropriate GPON encapsulated module (GEM) port ID.
911 The ONTs do not have special requirements for 911 calls.
Bandwidth Bandwidth profiles are provisioned for both upstream and downstream traffic flows. These profiles are
profile for both signaling and bearer traffic. Bandwidth and priority queue profiles are defined at the packet
optical line termination (P-OLT) unit. The same set of profiles can be used for all VoIP traffic.
DSCP The upstream signaling and bearer VoIP traffic is marked with differentiated services code point (DSCP)
values according to VoIP service and POTS port provisioning.
For non-SoC-based ONTs, signaling and bearer in the downstream direction must be marked with the
priority bits in the priority queue (PQ) profile for VoIP services. Otherwise, signaling is not directed to
the VoIP stack and the bearer is not directed to the voice path.
(1 of 2)

Feature Description
Configuration VoIP configuration information for the ONTs is provided in configuration profile files (XML files). A
profile file (XML configuration profile file contains a set of characteristic data for the analog phone and the VoIP
file) service. The data includes:
• impedance settings
• gain settings
• ringing cadences
• tone frequencies and cadences
For the SIP modes, the configuration profile data includes additional service configuration parameters.
Due to a file naming restriction in the NT file system, only 13-character file names can be
accommodated for configuration profile files, even though 14-character software version names are
supported by the ONT units.
Configuration profile files can be embedded in the ONT software load or obtained by download. The
download method is configured at the P-OLT:
• FTP server: the ONT downloads the configuration profile file from the provisioned server by FTP
using the VOIP client's IP interface
• SIPPING server: the ONT may still access an FTP server for the analog data set info associated with
POTS lines, but the primary information is downloaded from a SIPPING server
• OMCI channel: The P-OLT downloads the configuration profile file to the ONT using the OMCI
channel. If the P-OLT does not have the configuration profile file, it will use its management
interface to obtain the configuration profile file from the provisioned FTP server.
IP addressing Provisioning options are available to manually provision IP addresses through TL1, simple network
management protocol (SNMP), or learned through the DHCP or BRAS server.
MLT diagnostics The same mechanized loop test (MLT) diagnostics are available in both modes of operation.
Option 82 A provisionable string used by the DHCP relay is enabled on the service virtual local area network
identifier (1) (S-VLAN) with the configuration (CONF) option. The string allows a configurable identifier to be
associated with the VoIP service that is inserted by the DHCP relay agent at the P-OLT toward the DHCP
server.
Ping The ONTs support ping responses.
(2 of 2)
Note
(1) When another device is configured as the DHCP server and the 7342 ISAM FTTU is configured as a DHCP relay agent, the
Option 82 parameter should be enabled on both devices. This is to ensure that traffic passes correctly between the
devices.
22.2 Voice gateway mode
In the G6 voice gateway mode, the H.248/Megaco protocol is used for call control
signaling between the voice gateway and the ONT. The OLT interfaces with the
voice gateway through a layer 2 Ethernet network. Using the H.248 protocol, the
voice gateway controls voice calls, including the bearer channel to carry voice data
between the voice gateway and ONT. The signaling and bearer end-points are
identical. This mode is not supported on package C and D ONTs.
Figure 22-1 shows the network topology when the voice service is delivered in a
voice gateway mode.

Figure 22-1 Voice gateway network topology
AMS
GR303/ L2
TR008 Ethernet
cloud
Phone ONT Phone
Class 5 PSTN Voice gateway OLT
switch (G6)
Signaling and bearer channel end-points are same

18188
The G6 voice gateway mode supports two submodes as follows:

• GR-303/TR008 mode for ANSI H.248 support
• V5 mode for ETSI H.248 support
GR-303/TR008 mode
The G6 voice gateway supports both GR-303 and TR008 interfaces with the Class 5
switch. In this mode, two types of message flows typically occur between the voice
gateway and the ONT: H.248/Megaco signaling and ABCD-bit loop-start signaling.
H.248/Megaco message-based signaling is used to set up and tear down calls. It sets
up the bearer path and DS0 connection.
ABCD-bit loop-start signaling controls the analog interface and is passed in the
bearer channel using RFC 2833 protocol. The G6 voice gateway converts the 2-bit
AB signaling used by the TR008 interface to the 4-bit ABCD loop-start signaling
used by the ONT.
GR-303/TR008 call flow

The following is a high-level description of the flow for the GR-303/TR008 type call
that is initiated by the PSTN side through a Class 5 switch.
1 After the voice gateway receives a GR-303 setup request, it sends an equivalent
H.248/Megaco connect message to the ONT. This establishes the bearer path
between the Class 5 switch and the ONT. After the bearer path is established, the
voice gateway acknowledges the GR-303 setup request to the Class 5 switch.
2 The Class 5 switch sends ABCD codes to ring the phone. The codes alternate
between ring-on and ring-off. The voice gateway forwards the codes to the ONT
transparently. During ringing, the Class 5 switch sends frequency-shift-keying
(FSK) tones along the bearer path between the first and second ring to deliver the
caller identifier information.

3 When the phone goes off-hook, the ONT reports the off-hook status using ABCD
signaling. The voice gateway forwards the signaling to the Class 5 switch. The
Class 5 switch stops sending ringing ABCD codes when it receives the off-hook
signaling, then allows the voice data to flow through the bearer path.
4 When the phone goes on-hook, the ONT reports the on-hook status using the
ABCD signaling to the voice gateway. The voice gateway forwards the signaling
to the Class 5 switch.
5 When the Class 5 switch receives the on-hook signaling, it sends a GR-303
release message to the voice gateway and disconnects the voice path. The voice
gateway in turn sends the H.248/Megaco message to the ONT to disconnect the
bearer path.
V5 mode
The G6 voice gateway supports V5.2 interfaces with the Class 5 switch. In this mode,
the voice gateway translates the V5.2 PSTN signaling messages into H.248 messages
to the ONT. These messages are used for all aspects of call control, including call
setup, call teardown, and analog interface control for ringing or off-hook/on-hook
notifications. The H.248 messages are also used to set up the bearer path and voice
connection with the ONT.
V5 call flow
The following is a high-level description of the flow for a V5 type call that is initiated
from the PSTN side through a Class 5 switch.
1 After the voice gateway receives a V5 channel allocation request, it sends an
equivalent H.248/Megaco connect message to the ONT. This establishes the
bearer path between the Class 5 switch and the ONT. After the bearer path is
established, the voice gateway acknowledges the channel allocation request to
the switch.
2 The Class 5 switch sends Establish and Signal messages to ring the phone. These
messages indicate the ringing cadence number to use. The voice gateway
translates the messages to H.248 signaling and passes the cadence number on.
The ONT then rings the phone according to the profile data in the current
configuration profile for that cadence.
3 When the phone goes off-hook, the ONT reports the off-hook status using the
H.248 signaling. The voice gateway translates the H.248 signaling into a Signal
message to the Class 5 switch. The Class 5 switch connects the voice call to the
voice gateway. The ONT automatically stops the ringing and allows the voice
data to flow through the bearer path to the voice gateway.
4 When the phone goes on-hook, the ONT reports the on-hook status using the
H.248 signaling. The voice gateway translates the H.248 signaling into a Signal
message to the Class 5 switch.
5 When the Class 5 switch receives the Signal message for on-hook, it sends
Disconnect and channel de-allocation messages to the voice gateway and
disconnects the voice channel. The voice gateway in turn sends the H.248
signaling message to the ONT to tear down the bearer path.

22.3 H.248 softswitch mode
The H.248 softswitch application uses a full set of H.248/Megaco signaling

messages to support voice services. Most call features require some type of signaling
interaction with the softswitch.The softswitch supports features such as caller ID,
call waiting, and 3-way calling. See the appropriate ONT Customer Release Notes for
information about supported softswitches. This mode is not supported on package D
ONTs.
The ONT performs various functions under the direction of the softswitch.
• notify the softswitch of off-hook and on-hook events
• provide dial tone locally
• collect dialed digits and send the digits to the softswitch
• play ringback tone and busy tone
• provide caller ID FSK transmission with data provided by the Softswitch
• establish or disconnect real-time protocol (RTP) bearer path and RTP control
protocol (RTCP) to another VoIP media gateway
Figure 22-2 shows the softswitch network topology.
Figure 22-2 Softswitch network topology
Server (s) DHCP, Management channel

application, FTP etc.,
IP phone Softswitch
PSTN
gateway IP cloud
Signaling
channel
PSTN
cloud BRAS
L2 RJ11
Ethernet
cloud POTS
phone
POTS RJ45
phone OLT ONT
Class 5 PSTN IP
switch phone
18189

The ONT supports redundant softswitch servers. When operating in a redundant

configuration, the ONT contacts the secondary server if the primary server is lost.
Note — To implement redundant softswitch servers, you must use the

DHCP option 120 for a second softswitch IP address.
Softswitch call flow

The call flow associated with a conventional softswitch for traffic originating from
the ONT is generally the same as specified in the IETF/ITU-T H.248/Megaco call
flow.
One fundamental difference between the gateway mode and the softswitch mode is
that, in the softswitch mode, the Megaco signaling protocol instructs the ONT in
terms of playing tones, and on-hook and off-hook event through out-of-band
signaling messages.
22.4 SIP modes
The 7342 ISAM FTTU supports two SIP modes:

• SIP mode 1: thin client interworking with softswitches, such as Broadsoft
Broadworks (not supported on package C and D ONTs)
• SIP mode 2: thick client interworking with softswitches, such as Nortel CS2000
When configuring SIP using OMCIv2 via TL1, the Softswitch parameter identifies
the SIP gateway softswitch vendor. The format is four ASCII coded alphabetic
characters [A..Z] as defined in [ATIS-0322000]. A value of four null characters
indicates no particular vendor. The setting of this Softswitch parameter signals to the
ONT to use various types of SIP. Until all softswitch vendor IDs are identified,
package A, B, and H ONTs interpret some specific settings as follows:
• THIN = legacy SIP 1 - Mode 1 SIP - thin client
• any other setting including null = legacy SIP 2 - Mode 2 SIP - thick client
In the two SIP modes, the SIP switches provide the SIP server functions, while the
ONT provides the SIP user agent functions, including the following.
• controls the analog states of the POTS line to locally invoke call setup and call
tear-down
• generates dial tone locally
• collects dialed digits and send the dialed string to the SIP switch
• plays ringback tone and busy tone
• derives caller ID FSK from headers in signaling messages
• supports date and time for caller ID (not supported on package C and D ONTs)
• establishes or disconnects an RTP bearer path and RTCP to another VoIP media
gateway
• call statistics with call history (not supported on package C and D ONTs)

Redundancy in SIP mode 1 or SIP mode 2 is supported if a domain name is

configured for the RegistrarRoute and OutboundProxy parameters in the SIP
provisioning data and a DNS server address. or redundant DNS server address is
provided through DHCP; see section 22.7. The ONT automatically contacts the
domain name server (DNS) and obtains a list of A records or SRV records. The ONT
uses the records to contact possible SIP servers according to the methodology
outlined in RFC 3263. SIP redundancy is not supported on all Package C and D
ONTs. Contact your Alcatel-Lucent technical support representative for more
information.
SIP service features

Table 22-2 lists the service features on package A, B, and H ONTs and MDUs
supported by the two SIP modes and whether the service feature is configurable
using TL1 via OMCIv2. Not all features are supported for all SIP application servers.
Table 22-2 SIP service features
Service Description SIP SIP OMCIv2

mode 1 mode 2
Basic call Basic calling functions Y Y Some parameter such as

contact_uri must be
configured on the ONT
using XML.
Emergency number (911) Basic 911 support Y Y Fully configurable

(1)
Enhanced 911 support — Y
Denial of feature use — Y
Emergency ringback — Y
Forced hold — Y
Call forwarding status Splash ring when a call is actually — Y Reminder ring and
indications (1) forwarded Y Y cfsi_event_uri must be
Stutter dial tone while call forwarding is configured using XML.
active
Implicit call forward status indicators for
FS 5000 softswitch cannot be configured
using TL1.
Call hold (ANSI) Basic hold (flash hook supported) Y Y Fully configurable
Remote hold/network hold — Y
Call hold (ETSI) Basic hold (flash hook supported) Y Y ETSI mode cannot be
Remote hold/network hold (1) — Y configured using TL1.
Reverse polarity (ETSI) (1) — — Y ETSI mode cannot be

configured using TL1.
Tone of death (ETSI) (1) — — Y ETSI mode cannot be

HF using INVITE (1) For FS 5000 softswitch interoperability Y — thin_client_HF_method is

only supported using XML.
Call transfer Blind and consultative call transfer Y Y Fully configurable

Call park (1) Call transfer attended and unattended — Y
(1 of 3)


mode 1 mode 2
Call waiting (ANSI) Basic call waiting Y Y Fully configurable (Except

Delivery of calling number and name Y Y for deactivation of call
waiting on package C, E, F,
Cancel call waiting Y Y and G ONTs. Deactivation
Activate/deactivate/interrogate call Y Y is supported on some
waiting package D ONTs, such as
I-240G-U.)
Call waiting (ETSI) Basic call waiting Y Y ETSI mode cannot be

Delivery of calling number and name Y Y configured using TL1.
Cancel call waiting (1) Y Y
Activate/deactivate/interrogate call Y Y
waiting (1)
Fax service T.38 Y Y Fully configurable

Pass through Y Y
Caller ID Delivery of calling party number and Y Y Basic caller ID is

name Y Y configurable using TL1.
Caller ID Details such as ID format,
URI preference, and
country code stripping
must be configured using
XML
DTMF RFC2833 — Y Symmetric feature only

Inband Y — supported using XML. INFO
(1)
based only supported using
INFO based — Y XML.
Codec commit re-INVITE For softswitches that do not support Y Y peer_codec_commit only
(1) extra invite messages generated by the configured using XML.
ONT due to use of multiple codecs
Session timer — Y Y Session timer default

values are used when
Packetization interval — Y Y default_packetization_int

erval is only configurable
using XML.
Automatic callback (1) — Y Y Fully configurable
Conference calling (ANSI) Call parties are joined together at a Y — Fully configurable
softswitch server
Call parties in a 3-way conference are — Y
joined together at an ONT
6-way conference (1) — Y
Conference calling (ETSI) Call parties in a 3-way conference are Y — ETSI mode cannot be
joined together at an ONT configured using TL1.
Direct connect (Hot Line) Configurable directory number is called Y Y Fully configurable
automatically when a subscriber goes off
hook
Direct connect (Warm Configurable directory number is called Y Y Fully configurable
Line) (2) automatically when a subscriber goes off
hook and does not dial before the initial
digit timeout period.
(2 of 3)


mode 1 mode 2
Distinctive ringing Outside call alerting Y Y Fully configurable

Priority call Y Y
Screening list Y Y
Teen line Y Y
Home intercom Allows conversation between two phones — Y Only one service code is
on the same physical POTS line as though supported when
in a normal call, but without establishing configured using TL1.
a network connection
Message waiting Audible and visual MWI when a subscriber Specific feature details
indication (MWI) has voice mail message waiting, such as
including: vmwi_refresh_interval,
Y Y vmwi_abbreviated_ring,
Reminder ring
Y Y mwi_reminder_burst, and
Stutter dial tone mwi_reminder_interval
Y Y
Visual MWI must be configured using
XML.
Outbound call dialing Part of basic call Y Y Fully configurable
Bridged lines Two or more lines sharing the same — Y

directory number
Call pickup with Barge-in Allows a third party to join a two-way — Y

(1) call
Suppressed ringing (1) Supports specialized telemetry devices — Y Not configurable, must use
used in place of standard phone sets enable_supp_ring XML
parameter.
Multiple SIP accounts (1) As many as 10 registrations are allowed — Y

for each POTS line
(3 of 3)
Notes
(1) Not supported on package D ONTs
(2) Supported on I-240G-U but not on other Package D ONTs
Subscriber service codes for SIP mode 2

In SIP mode 2, the ONT supports service-feature related codes that are configurable
in the ONT (not supported for package C and D ONTs), including the following:
• *70 or 1170 to cancel call waiting for the duration of the current call
• *52 or 1152 after a flash hook to place the remote party on hold
• *54 or 1154, or *53 or 1153 to activate home intercom
• *41 or 1141 to initiate a 6-way conference call, or cause a consultation call to be
joined to an active 6-way conference
• *43 or 1143 to release a consultation call instead of joining it to a 6-way
conference
• *43# to activate call waiting service (ETSI)
• #43# to deactivate call waiting service (ETSI)
• *#43# to interrogate call waiting service activation status (ETSI)

By default, the subscriber invokes features such as 3-way calling or call waiting
using the methods described in the Bellcore GRs. However, the ONTs supporting
SIP voice service also support ETSI market-based methods of invoking calling
features when the enable_etsi SIP parameter in Table 22-14 is set to yes. Enabling
this parameter allows for different subscriber call feature controls, as shown in
Table 22-3. This is not supported on package D ONTs.
Table 22-3 ETSI call feature configuration
Call feature SIP provisioning Example

parameter
Call waiting
Release active call, reduce to 2-way call etsi_cw_release R1 (1)
Toggle calls etsi_cw_toggle R2 (1) (2)
Merge calls, begin 3-way call etsi_cw_merge R3 (1)
Release held or new call, reduce to 2-way call etsi_cw_release_held_ R0

call
Call hold and call consultation
Release active call, reduce to 2-way call etsi_ch_release R1 (1)
Toggle calls etsi_ch_toggle R2 (1)
Merge calls, begin 3-way call etsi_ch_merge R3 (1)
Release held call, reduce to 2-way call etsi_cw_release_held R0

call
3-way call
Split call, return to call hold (3-way call ends) etsi_3wc_split R2 (1)
Split call, return to call hold (3-way call ends, previous etsi_3wc_split_ R2 (1)
call hold state entered preconf
Notes
(1) R in the example column refers to register recall and the numbers are dialed digits.
(2) R2 for the etsi_cw_toggle parameter indicates that using register recall (or flash hook) then dialing
‘2’ causes the ONT to toggle between two calls during call waiting.
SIP call flow

Figure 22-3 shows the call flow for a SIP call that originates from the ONT.

Figure 22-3 Call flow of a SIP call originating from the ONT
Phone ONT Softswitch
Off hook
Send dial tone or stutter tone
First digital dialed
Stop dial tone/stutter tone
Remaining digits dialed
INVITE (collected digits)
100 TRYING
180 RINGING
Send ring back tone
PRACK
200 OK (PRACK)
200 OK (INVITE)
Stop ring back tone
ACK
Speech path established
18585
Figure 22-4 shows the call flow for a SIP call that is terminated at the ONT.

Figure 22-4 Call flow of a SIP call terminated at the ONT
Phone ONT Softswitch
INVITE
100 TRYING
Send ringing with caller ID
180 RINGING
PRACK
200 OK (PRACK)
Off hook
Stop ringing
200 OK (INVITE)
ACK
Speech path established
18586
22.5 Dual SIP client mode using VEIP
A dual SIP client is necessary in networks where provisioning of voice services on

the ONT are done by two different provides, such as in an environment where one
provider owns the physical configuration (e.g. the PON fiber to the ONT device in
the home or business) and another provider wants access to connect end users.
When this occurs on supporting ONT devices, some aspects of configuration such as
data tunnel configuration with QoS or POTS interface settings can be configured by
one provider, and some aspects can be configured by another provider, such as SIP
service parameters or DHCP server configuration for IP address allocation.
The domain managed by the provider dealing with physical aspects of ONT
configuration, such as port settings, is done by traditional network service providers,
and configuration is done in a traditional manner via OMCI.
A VEIP is a mechanism for an external network or element manager to configure and
otherwise manage an ONT. This external manager can be used to configure other
functionality of the ONT that is not done via OMCI, for example, L3 or wireless
interfaces. At this virtual termination point, the external manager has access to the
interface or to traffic on the interface. The P-OLT manages the VEIP using OMCI to
terminate VLANs as on any other UNI.
Traditional L2 functions continue to be managed by OMCI using the P-OLT or a
network management system.

The VEIP is the boundary point between the OMCI domain and the TR-069 domain.
Beyond the VEIP, voice services or other functionality is managed by the CWMP
per the TR-069 standard. The L3 functions of devices that support L3 can be
managed via home management systems (ACS or HDM) defined by TR-069 or by
web-based GUIs.
This VEIP managed entity represents the hand off point in an ONT or MDU to a
separate, non-OMCI management domain. One or more Ethernet traffic flows are
present at this boundary.
Figure 22-5 shows the relationship between the OMCI and non-OMCI domains.
Figure 22-5 VEIP and the relationship to TR-069
Access
Telco Seeker
OLT ACS
Enable data connection VoIP parameters provisioning

Physical POTS maintenance Through TR - 069
Via OMCI
VEIP
SIP UA Media
client client
IP client
ONT SIP client
22217
The ONT must support TR-069 configuration via a third-party manager.

Table 22-4 identifies the restrictions that apply.
Table 22-4 Restrictions to configure an ONT VEIP port
Task Restriction
Create an ONT VEIP port The ONT card must be created
The QoS session profile must be created.
The DSCP to p-bit mapping profile must exist, if a non-default

profile is specified.
Up to 16 VEIPs can be configured on an ONTCARD.
(1 of 2)

Task Restriction
Modify an ONT VEIP port After the ONT UNI port is created, you cannot modify the
association between an ONT UNI port and a QoS session profile. To
associate a new QoS session profile with the ONT UNI port, you
must first delete the ONT UNI port and re-create it.
The ONT UNI port must be in the out-of-service state to modify

any parameter other than customer information.
If you specify a new non-default DSCP to p-bit mapping profile,

the profile must exist.
Delete an ONT VEIP port To delete the ONT UNI port, the following is required:
• All services and flows that are configured on the port must be
deleted.
• The ONT UNI port must be in the out-of-service state.
(2 of 2)
Figure 22-6 shows VEIP configuration inputs.
Figure 22-6 VEIP configuration inputs
PPTP Ext VLAN Priority

POTS UNI Tagging Queue A1
Oper (Downstream)
UNI-G Priority GEM

VLAN Interworking
Queue A2 Tagging
(Downstream) TP
MAC Bridge Filter 802.1p
VEIP Port Config Mapper
Data Service
Priority MAC Bridge Profile
Queue A3 GEM
UNI-G Port Config Interworking
(Downstream) Data TP
MAC Bridge
Service
PPTP Priority Profile GEM
POTS UNI Queue A4 MAC Bridge Interworking
(Downstream) Port Config TP
Data 802.1p
VEIP Mapper
Service
Profile GEM
VLAN
Tagging Interworking
Filter TP
22218
Figure 22-7 shows dual SIP upstream and downstream tagging.

Figure 22-7 Dual SIP upstream and downstream tagging
Upstream
RTP & RTCP UNTAG

P-bit :5 provisioning To GEM
SIP-client-1 VID=10
P-bit :7 provisioning To GEM
SIP Signal & DHCP UNTAG
Downstream
RTP & RTCP UNTAG

SIP-client-1 VID=10 P-bit = 5 From GEM
SIP Signal & DHCP UNTAG
22219
Figure 22-8 shows the dual SIP DHCP request process flow.
Figure 22-8 Dual SIP DHCP request process
DHCP Request
DHCP Request + Option 82 string
According to VLAN ID
SIP-client-1 OLT Access seeker

22220
Figure 22-9 shows the full TR-069 configuration process flow

Figure 22-9 TR-069 configuration process flow
DHCP ACS OSS/BSS

SIP-client-1 OLT server
Add line ID in the

A DHCP request DHCP request
Line ID, IP address, provisioning code
DHCP server shall

assign below address
to SIP-Client:
B IP address
DNS address
ACS URL
Provisioning code
C Register request to ACS

Get customer
info
D ACS verify the user name and password
E TR-069 Connect establish
A SIP-Client request IP address and provision code D ACS verify the user name and password and
from DHCP server and OLT relay with line ID establish the connections
B DHCP server assign the address information to E TR-069 Conection Establish

SIP-Client according the line ID which gets from OSS
C SIP-Client ACS with HTTP user name and passwors

for request make connection
22221
22.6 VoIP service configuration
The VoIP framework consisting of signaling protocols like SIP does not specify any
standard way or mechanism of implementing a configuration interface. As
implemented in the 7342 ISAM FTTU, there are four possible sources of
configuration information for SIP. See Table 22-5 for the sources of SIP
configuration data.

Table 22-5 Sources of SIP configuration data
Source Description
OMCI OMCI communication is used to conduct service and protocol provisioning. OMCI
data is used to configure the overall VOIP service and individual POTS lines from
the OLT. A limited set of provisioning options for SIP are also provided using OMCI.
OMCI data is established using TL1 or SNMP commands at the OLT.
OMCIv1 allows configuration of proprietary options using TL1. OMCIv2 allows
configuration of standards-based VoIP service, POTS line, and SIP commands.
Those SIP commands that cannot be configured using OMCIv2 are listed in Tables
22-10 to 22-14.
OMCIv2 configuration support is available for Release 04.07.50 and later.
DHCP IP addresses that are used for the voice service can be manually selected and
entered or automatically obtained. As an option to manual IP address
provisioning, a DHCP server can be used to automatically obtain IP addresses.
Configuration Country-specific parameters are stored in a configuration profile file (XML file) to
profile file allow the VoIP services to be configured for individual countries. Configuration
profile files can be embedded in the software load or obtained by download.
When the configuration profile file is downloaded from an FTP server (or from the
P-OLT via the OMCI channel) instead of from a SIPPING server, it may contain
SIP-specific provisioning parameters.
When using an OLT system that supports OMCIv2, most SIP-specific provisioning
parameters can be configured using standards-based TL1 commands.
iConfig iConfig is an alternative to the configuration profile file method of provisioning

SIP-specific parameters at the ONT. The iConfig external server communicates SIP
provisioning data to ONTs. This process is intended to allow centralized control
and dissemination of provisioning data to multiple SIP devices, such as ONTs.
iConfig is only available using OMCIv1.
7342 ISAM FTTU VoIP service configuration is described in subsequent sections as

follows:
• process for country-specific POTS configuration files
• service and protocol configuration
• configuration profile (embedded in the software load or by download)
• iConfig (Sipping) configuration for SIP
• VoIP service provisioning parameters
Process for country-specific POTS configuration files

In order for SIP configuration to work correctly in different countries, configuration
profile file (XML files) are used. These XML files contain:
• CDE data, related to hardware settings specific to a country, such as tone values
and ringing cadences.
• SIP provisioning data, related to SIP-specific configuration parameters, allowing
for per-ONT and per-POTS line configurations.
The CDE data is gathered by Alcatel-Lucent and used to generate the XML files. The
XML files are shipped with the ONT software. The XML files are downloaded to the
ONTs, and when the ONT initializes and the VoIP client is activated, the XML
content containing SIP configurations is loaded into system. Alternately, on
OMCIv2 systems, some SIP configurations can be done using TL1.

If required, the XML files can be downloaded to ONTs from an FTP server or
SIPPING server, or the P-OLT can download the files to ONTs via the OMCI
channel.
Service and protocol configuration

Service and protocol configuration requirements are different between the voice
gateway mode and the softswitch mode.
Voice gateway mode

In the voice gateway mode, the service and protocol configuration must be manually
performed using the element management system (EMS). Voice gateway
deployments require some unique considerations during service and protocol
configuration; see Table 22-6.
Table 22-6 Voice gateway mode considerations
Type Consideration
ONT configuration The static IP addresses must be derived and configured

along with termination identifiers on the ONT during the
POTS provisioning time. No DHCP function is expected.
Voice gateway configuration The ONT IP addresses and the termination identifiers must
be configured on the voice gateway.
File download The ONT is expected to use an embedded configuration

profile for voice gateway applications. File download is not
necessary. The embedded configuration profile is stored on
the ONT flash. ONTs are shipped from the factory with the
embedded configuration profiles already installed. New
configuration profile files can be downloaded to the ONT
from an FTP server or SIPPING server, or from the P-OLT via
the OMCI channel.
ONT and voice gateway MAC The ONT and voice gateway MAC addresses are fixed at the
configuration ONT and the voice gateway. The MAC addresses are
exchanged as part of the ARP.
Softswitch modes
There are two softswitch modes: H.248/Megaco and SIP softswitch modes. In these
modes, some configuration elements associated with VoIP provisioning can be
derived automatically from the DHCP/BRAS servers on the network. Package C and
D ONTs do not support softswitch modes.
The ONT and the softswitch trigger the ARP proxy function for individual MAC
address learning.
Table 22-7 describes the use of different DHCP options in the different VoIP modes.

Table 22-7 DHCP options and VoIP modes
DHCP option Function Voice gateway H.248 Softswitch SIP mode 1 SIP mode 2
mode mode (for IP0E) (for IPoE)
1 IP subnet mask Not recommended Supported Supported Supported
3 Default IP router Not recommended Supported Supported Supported
6 DNS server address Not supported Not supported Supported Supported
50 IP address of VoIP Not recommended Supported Supported Supported

service on the ONT
61 (3) ONT client ID Not recommended Supported (1) Supported Supported
66 (4) FTP server’s IP address Not recommended Supported Supported Supported

(used if FTP download
is needed)
90 (2) (3) DHCP authentication Not recommended Supported Supported Supported
100 (5) Time Zone Offset Not recommended Supported Supported Supported
relative to UTC
120 (6) IP softswitch IP Not recommended The first IP address Supported Supported
addresses or domain is the primary
name server. The second
IP address is the
address of the
secondary server.
If a second IP
address is present,
it enables
redundancy.
Notes
(1) The clientid parameter is used as the H.248 message identifier (MID) field for H.248 signaling messages when DHCP is
disabled.
(2) DHCP Option 90 is not supported on package C and D ONTs.
(3) DHCP Option 61 and 90 are not supported on I-240W-S ONTs.
(4) DHCP Option 66 is not supported on package C (except I-010G-Q, I-010G-S, and I-240W-U), package D (except I-240W-S,
I-241W-S, and I-240W-Q 3FE 52958 AY variant), package E, package I, package J, or package K ONTs.
(5) If the ONT is configured to use DHCP and the DHCP server used by the ONT supports DHCP Option 100, the ONT will get
time zone and daylight savings settings from the DHCP server. DHCP Option 100 takes precedence over configuration by
TL1 and CLI of the time zone offset.
(6) DHCP Option 120 is supported from R04.8.48 on some devices. Contact your Alcatel-Lucent technical support
representative for more information.
Configuration profile
The 7342 ISAM FTTU uses embedded or downloaded configuration profiles for
both the voice gateway and Megaco softswitch modes. This is also supported for SIP
and includes additional SIP-specific parameters.
Configuration profile in voice gateway and softswitch modes

The ONT supports configuration profiles related to different countries. The profile
settings for analog and digital data are specific to each country. Embedded or
downloaded configuration profiles have the same content and format, and are used
for both voice gateway and H.248 Softswitch modes.

The ONT software load contains embedded configuration profiles with the specified
file names. Embedded configuration profiles are needed when a file download is not
desirable. See the appropriate 7342 ISAM FTTU ONT CRN for information about the
countries that are supported in the embedded profiles.
The ONT can download the appropriate configuration profile using an FTP server or
SIPPING server, or the P-OLT can download it to the ONT via the OMCI channel
when the ONT does not have the specified file name among its embedded
configuration profiles. The downloaded configuration profile is stored in flash
memory of the ONT and can survive ONT restarts, software downloads, and
software activation. Because the ONT does not re-download a file automatically, any
change to the contents of an existing configuration profile file on the FTP server,
SIPPING server, or P-OLT has no impact on in-service ONTs.
To activate a new configuration profile on the ONT, you must use a different file
name for the configuration profile file that is on the FTP server, SIPPING server, or
P-OLT. VoIP service on each ONT must be provisioned with the new file name. The
ONT automatically deletes a previously downloaded file with a name that is no
longer provisioned.
Configuration profile in SIP modes

In the SIP modes, additional data in the configuration profile may be used to
provision SIP services as part of the configuration profile downloaded by the ONT
from an FTP server or SIPPING server, or downloaded by the P-OLT to the ONT via
the OMCI channel. Section 22.7 summarizes this additional provisioning data. The
use of a configuration profile to provision SIP services is a provisioning option at the
ONT.
iConfig
The ONT can communicate with a specialized server intended to allow centralized
control and dissemination of provisioning data to SIP devices, such as ONTs. The
protocol used for this communication is based on draft IETF standard
draft-ietf-sipping-config-framework, and is more simply referred to as iConfig or
Sipping. The ONT maintains a status for each iConfig profile that you can retrieve
by OMCIv1 upon request. You can only configure iConfig using OMCIv1.
This is an optional feature at the ONT as an alternative to the configuration profile
method of provisioning SIP-specific parameters at the ONT. The same parameters
summarized in Tables 22-10 to 22-14 are supported with both methods.
When iConfig is enabled, the ONT contacts the specialized configuration server for
a root certificate to be used for subsequent access to provisioning data using TLS.
The configuration server notifies the ONT of provisioning data by supplying an
indirect HTTPS reference. The ONT then reads the provisioning data using HTTP
over TLS (HTTPS), and with HTTP Digest authentication.
Direct communication to the configuration server uses SIP protocol over UDP with
HTTP Digest (also known as MD5) authentication. The ONT is provisioned with the
IP addressees of the Configuration server and the HTTP Digest authentication
credentials as part of the VoIP client turn-up.

When the iConfig method is selected, there is no configuration profile selection.

Default data for U.S. applications will be used for all analog settings. However, you
can obtain the download status of profiles for VoIP and for POTS lines using TL1 or
5520 AMS to retrieve and display SIP configuration data to isolate trouble shooting
issues with more granularity. See 7342 ISAM FTTU Operations and Maintenance
guide for more information about downloading iConfig profiles.
22.7 SIP data model and XML profiles
There are different device, application, and user profiles for each line of an ONT.
There are additionally local network profiles and vendor specific profiles that apply
to the device. The ONT or MDU must process sets of data that define both the device
as a single unit, and per line. Each profile consists of profile data sets that are a
logical division of properties: local network, device, user, and service.
The distinct sets of data are contained in XML files that are downloaded to the ONT
or MDU. In order for SIP configuration to work correctly in different countries,
XML download files are used. These XML files contain:
• CDE data related to hardware settings specific to a country, such as tone values
and ringing cadences. Such CDE data should not be configured in most cases.
• SIP provisioning data, related to SIP-specific configuration parameters, allowing
for per-ONT and per-POTS line configurations. SIP provisioning data can be
configured using the XML file. When using a system that supports
standards-based OMCIv2, you can use TL1 to configure equivalent parameters in
most cases.
Figure 22-10 shows the how the data in the XML files is applied to the device.
Figure 22-10 XML data application to ONT and MDUs.
le le
r ofi rofi
ifi cP kP
ec or
p e tw
rS l N
n do ca
Ve Lo
Line X
Line 4
Media
Line 3
CDE SIP Identity SIP Service
Line 2
Analog
Line 1
ice ice i les i les files There is different Device, application,
ev ev of of ro
r d r d pr pr p and user profiles for each line. One local network
Pe Pe ice ion er profile and Vendor specific profile (CDE)
v
ca
t Us
De li is maintained for all lines
A pp
21689

A value listed as boolean accepts any of six values. These are the pairs of 0 and 1,
yes or no, and true or false. White space around these values is accepted. Any other
value used is ignored and causes the default value to be used.
Table 22-8 shows the relationships between the data sets.
Table 22-8 SIP data model profiles
Local Device Application User profile Vendor Notes

network profile (one profile (one (one per profile
profile (one per port) per port) port) (CDE) (one
per device) per device)
Data set
Media Media local — — — Vendor Applicable to exchange

network profile of media within a SIP
profile (CDE) session
SIP protocol SIP protocol — SIP protocol — Applicable to all SIP

(local (local communication
network network
profile and profile and
application application
profile) profile)
Analog port Analog local — — — Applicable to how the

network user agent manages the
profile analog port
Identity — Identity data — — Applicable to user

(subscriber) identity
Service — — — Service data Applicable to service

set options for user
(subscriber)
CDE — — — — Not configurable,

applicable to device
Vendor profile (CDE)

The majority of vendor profile data parameters are not configurable. For profile
details not listed in Table 22-9, contact your Alcatel-Lucent support representative

Table 22-9 Vendor profile (CDE) provisioning parameters
Parameter Description Mode Mode Device OMCIv2 TL1 and CLI

1 2 support? parameters
shortest_pattern Specifies the behavior for matching N Y All Yes but no N/A
_match overlapping patterns in an TL1 or CLI
H.248/Megaco digitmap. When this developed
parameter is set to true and a dialed Value is
digit results in a complete match for derived
any pattern, the digits will be reported from
immediately to the Megaco softswitch. download
When this parameter is set to false and / default
a dialed digit results in a complete line
match of one pattern, but also a subset profile
match of at least one additional
pattern, then the ONT will continue to
wait (up to the interdigit_timer) for
more digits in order to match
the longest possible pattern in the
digitmap.
The default value shall be “false”
SIP protocol (local network profile and application profile)

Table 22-10 lists the SIP protocol parameters. When OMCIv2 support is yes, then
TL1 can be used to configure equivalent parameters on systems supporting OMCIv2.
Table 22-10 SIP protocol parameters
Parameter Description Mode Mode Device OMCIv2 TL1 parameters

1 2 support?
transport_pr The name (UDP, TCP, TLS) of the Y Y Package Yes UDPPort using
otocol (1) transport protocol and the port A, B, H Default is ent-ontsip-config
TransportPr number to be used for signaling. This is only UDP
otocol an optional parameter, the default
(1)
protocol value is UDP and the default
port number is 5060. UDP is the only
allowed value for transport protocol.
(This parameter does not apply to
iConfig message transport.)
For package C and D ONTs, UDP is used
without any configuration necessary.
registrar_uri The uniform resource identifier (URI) is Y Y All Yes PROXYSERVPROFID

(1) used as the request URI for all except using
RegistrarUri( REGISTER requests. This is a string of package ent-ontsip-config
1) up to 99 characters and is a required C and D
parameter. The FTP XML name of this
parameter is shown as RegistrarURI.
Can use the form sip:domain or
sip:registrar_route
(1 of 7)


1 2 support?
RegistrarRou The address of the server or proxy to Y Y All Yes, but REGISTRARPROFID
te which REGISTER requests are sent. It is registrar and
a numeric IP address or a fully qualified address REGISTRARPROFN
registrar_ro domain name. This is a string of up to and M using
ute (1) 99 characters and is a required registrar ent-ontsip-config
parameter. The FTP XML name of this route will
parameter is shown as RegistrarRoute. have the
When the string dhcp is used, this same
keyword substitutes the IP address or address.
domain name returned from DHCP
option 120 instead of the
registrar_route parameter value. If the
DHCP server does not provide an option
120 value, a 0.0.0.0 address is
substituted and a registration failure
alarm is raised for each configured
POTS line.
Can use the form xxx.xxx.xxx.xxx:port,
where xxx.xxx.xxx.xxx is the IP address
and port is the port number from
transport_protocol
RegistrarRou Optional parameter that indicates the Y Y Some No N/A

teSec (1) (3) address of the server or proxy to which package
REGISTER requests are sent. It is a C,
numeric IP address. The default is a package
null string. D, and
Can use the form xxx.xxx.xxx.xxx:port, package
where xxx.xxx.xxx.xxx is the IP address E MDUs
and port is the port number from
transport_protocol
register_per The registration expiration time that Y Y All Yes REGEXPTIME using
iod (1) the client will propose by including it in ent-ontsip-config
an Expires header of a REGISTER
request. This is a non-negative integer
and the value is expressed in seconds.
The default value is 3600.
register_hea The number of seconds prior to Y Y All Yes, REREGHEADSTRT

d_start (1) expiration of a registration at which default using
the client sends a REGISTER request to value in ent-ontsip-config
refresh the registration. This is a TL1 is 360
non-negative integer and the value is seconds.
expressed in seconds. The default
value is 60.
register_retr The interval between successive Y Y All No, value N/A

y_interval (1) registration retries after a failed is derived
registration retry. The value is from
expressed in seconds. The range is zero download
(0) to 65535 and zero (0) disables / default
registration. The default value is 60. line
profile.
(2 of 7)


1 2 support?
OutboundPr The address of a server or proxy to Y Y All Yes, TL1 OUTPROXYSERVER

oxy which all SIP requests are to be sent, allows SIP PROFID using
outbound_pr except for those for which a server of URI for ent-ontsip-config
oxy (1) proxy is not otherwise specified. It is outbound
either a numeric IP address or a fully proxy but
qualified domain name. This is a string the ONT
of up to 99 characters and is a required expects a
parameter. The FTP XML name of this string in a
parameter is shown as OutboundProxy. non-URI
When the string dhcp is used, this format.
keyword substitutes the IP address or
domain name returned from DHCP
option 120 instead of the
registrar_route parameter value. If the
DHCP server does not provide an option
120 value, a 0.0.0.0 address is
substituted and invite failure and
subscribe failure alarms are raised for
each configured POTS line.
The outbound_proxy value is
superseded for INVITE requests if the
outbound_uri_suffix value is
configured. (2)
• outbound_uri_prefix (1) + dialed
number + @ + outbound_proxy
when the oubound_uri_suffix value
is not configured
number + outbound_uri_suffix
is configured
DHCP Option 120 is only supported on

some devices as of R04.08.48. Contact
your support representative for more
information.
OutboundPr Optional parameter that indicates the Y Y Some No N/A

oxySec (1) address of a server or proxy to which package
all SIP requests are to be sent, except C,
for those for which a server of proxy is package
not otherwise specified. It is a numeric D, and
IP address. The default is a null string. package
The OutboundProxySec value is E MDUs
configured. (2)
is not configured
is configured
DomainNam This parameter is used to compose the Y Y Package Y N/A

e Callee's host part of the SIP INVITE L ONTs
request and is also used in the “TO” only
header, for example,
callee)DN@DomainName.
(3 of 7)


1 2 support?
sip_dscp (1) The differentiated services code point Y Y Package Yes DSCP using
(DSCP) value that should populate the A, B, H ent-ontsip-config
DS field of SIP packets sent by the user only
agent. It is an integer value in the
range of zero (0) to 63. The default
value is the value configured via
SNMP/TL1.
subscribe_p The subscription expiration time that N Y Package Yes, TL1 VOICEMAILTO
eriod (1) the client will propose by including it in A, B, H and CLI using
an Expires header of a SUBSCRIBE only there is no ed-ONTVOICEPOR
request. This is a non-negative integer default TSIP
and the value is expressed in value
seconds.The default value is 86400
(one day). (This parameter does not
apply to iConfig requests.)
subscribe_h The number of seconds prior to N Y Package No, value
ead_start (1) expiration of a subscription at which A, B, H is derived
the client sends a SUBSCRIBE request only from
to refresh the subscription.This is a download
non-negative integer and the value is / default
expressed in seconds. The default line
value is 3600 (one hour). profile.
sip_timer_t1 The value of the SIP T1 timer (the Y Y Package No, value N/A
(1) round-trip time estimate). This is a A, B, H is derived
non-negative integer and the value is only from
expressed in milliseconds. The range is download
1 to 65535. The default value is 500. / default
line
profile.
sip_timer_t2 The value of the SIP T2 timer (the Y Y Package No, value N/A
(1) maximum retry interval for a A, B, H is derived
non-INVITE request). This is an integer only from
and the value is expressed in seconds. download
The range is 1 to 65535. The default is / default
4. line
profile.
sip_invite_ti The INVITE transaction timeout, Y Y Package No, value N/A

meout (1) designated as Timer B in RFC 3261. This A, B, H is derived
is an integer. The value is expressed in only from
seconds. The range is 1 to 65535. The download
default value is 32 (64*T1). / default
line
profile.
sip_noninvit The non-INVITE transaction timeout, Y Y Package No, value N/A
e_timeout (1 designated as Timer F in RFC 3261. This A, B, H is derived
) is an integer and the value is expressed only from
in seconds. The range is 1 to 65535. download
The default value is 32 (64*T1). / default
line
profile.
(4 of 7)


1 2 support?
default_pro Specifies the application server Y Y All No, value N/A

duct_id product identifier that shall be except is derived
assumed for product-specific package from
communication with the application C, D, download
server if the application server does and E / default
not provide a product identifier. The line
value of this parameter is any string profile.
that can be used as the value of a
server or user agent header. The
default is an empty string.
peer_codec Specifies the behavior of the ONT SIP Y Y All No, value N/A
_commit client software as to whether a except is derived
re-invite message is sent at the end of package from
an SDP negotiation. The value of this C, D, download
parameter is a string with values: and E / default
• (default) always to ensure the ONT line
send the re-invite message when profile.
multiple codecs are included
• none to ensure the ONT never
sends a re-invite message
• single to ensure the ONT sends the
re-invite message except when the
SDP answer contains a single codec
The default is set to none when running

in iConfig SIP mode in voice R4.3
add_route_h Specifies whether the ONT adds route Y Y All No, value N/A
eader headers to outgoing requests. The except is derived
options are: package from
• true (default) C, D, download
and E / default
• false
line
When set to true, the route header are profile.
added based on the reg_route
parameter for register requests and
the outbound_proxy parameter for all
other requests.
When set to false, no route header is
added to outgoing requests that would
initiate a new dialog.
enable_reg_ Specifies whether the ONT should send N Y All No, value N/A
subscribe the registration subscribe method except is derived
described in RFC3680. The options are: package from
• true C, D, download
and E / default
• false (default)
line
profile.
(5 of 7)


1 2 support?
follow_regis The parameter controls whether all SIP Y Y Package No, value N/A
tration signalling follows the registration (i.e. A, B, H, is derived
be sent via the IP address through I-240W- from
which the current registration was S only download
sent) or not. / default
The parameter is only supported in line
GSIP 4.5 profile.
If this parameter set to “true” or “yes”
and if registrar_route and
outbound_proxy are both non-empty
and set to the same value then, all SIP
signaling will strictly follow
registration.
If this parameter set to “false” or “no”
or if registrar_route and
outbound_proxy are configured as
different values then, all SIP signalling
may or may not follow registration.
The default value is false in ftp mode
and true in iConfig mode.
call_waiting The parameter determines how the Y Y Package No, value N/A
_ringing_ind ONT provisionally responds to a call A, B, H, is derived
ication waiting request using either the 180, I-240W- from
180_alert_info or 182 responses. S only download
For 180_alert_info, the ONT sends out / default
a 180 response with a extra header line
with Alert-Info: profile.
<urn:alert:service:call-waiting>. By
default, the ONT sends the normal 180
ringing response as the call waiting
ringing indication. However some
customers require that a specific 18x
response for the call waiting ringing
signal so that the SS/AS can
differentiate it from normal ringing
and to generate a specific
announcement to the calling party.
The possible specific 18x messages
include the following two cases:
• 1. CMCC requires that a 182
response shall be generated in this
case;
• 2. 3GPP 24.615 requires 180, but
that 180 shall have a specific
header Alert-Info:
<urn:alert:service:call-waiting>
The default is the 180 signalling

method.
SIP_poundke The parameter determines whether Y Y Some No, value N/A
y_escape the # key is translated to%23 (per package is derived
RFC2361) or is not translated per C, from
request by China operators. package download
When set to true, translate to%23. D, and / default
package line
When set to false, no translation E MDUs profile.
(report # directly).
(6 of 7)


1 2 support?
dns_redun_ The DNS server selection mode. Y Y Package Y N/A

mode • dns_redun_primary: Any new DNS L ONTs
look-up request gets always sent to only
the highest priority DNS server
irrespective of whether the
previous DNS look-up request got
replied by the highest priority DNS
server or not.
• dns-redun-at-successful: A new
DNS look-up request gets sent to
the DNS server that successfully
replied to the previous DNS look-up
request. This DNS server remains
addressed for as long as a reply
gets received from this DNS server
during the initial retransmission
interval.
dns_ini_retr The initial retransmission time interval Y Y Package Y N/A

_int after which the DNS resolver will send L ONTs
the first retransmission for the DNS only
look-up request.
Use an integer value from 200 to
1000 ms.
dns_max_re The maximum number of DNS look-up Y Y Package Y N/A

tr_nbr retransmissions to be addressed to the L ONTs
same DNS server in case of no only
response. The retransmission
algorithm is based on an initial
transmission of the query and a number
of retransmissions.
Use an integer value from 0 to 4.
dns_purge_t The DNS purge timer intends to Y Y Package Y N/A

imer overrule the TTL value in case the L ONTs
latter value would be set to an only
excessively long time.
The maximum resource record caching
time equals:
RR caching time = MIN [DNS purge
timer; MINTTL]
Whereby MINTTL = MIN {[TTL NAPTR]*;
[TTL SRV]*; [TTL A]*}
The DNS purge timer gets disabled
when set to the value “0”.
In this case the maximum resource
record caching time equals:
RR caching time = MINTTL = MIN {[TTL
NAPTR]*; [TTL SRV]*; [TTL A]*}
Use an integer value from 0 to 86400 s.
(7 of 7)
Notes
(1) This parameter can only be set on an ONT-wide basis when the parameter is configured as part of the configuration profile
(downloaded by the ONT from an FTP server or SIPPING server, or downloaded to the ONT by the P-OLT via the OMCI
channel).
(2) Does not apply to package C, D, and E ONTs and MDUs
(3) For the I-240W-S ONT, the RegistrarRout e or RegistarRouteSec must be set the same as OutboundProxy or
OutboundProxySec.

Identity data
Table 22-11 lists the identity data. When OMCIv2 support is yes, then TL1 can be
used to configure equivalent parameters on systems supporting OMCIv2.
Table 22-11 Identity provisioning parameters

1 2 support?
address_of_reco The SIP address of record (AOR) for Y Y All Yes, User part
rd the POTS line. This is a string of up to address is configured using
AddressOfRecor 99 characters and is a required constructe USERAOR using
d parameter. The FTP XML name of this d using ed-ONTVOICEPO
parameter is shown as user part RTSIP
AddressOfRecord. is and host Host part
When the string autofill is used, this part configured using
keyword substitutes a new address of parameter AORHOSTPRTPR
record, taking the form: s. OFID using
sip:CLIENTID + ent-ontsip-confi
PORT#@registrar_host, g
where
CLIENTID is the TL1 and OMCI
configured value for CLIENTID
PORT# is the numeric port value,
from 1 to n, where n is the numeric
port number for the POTS line
registrar_host is the filled value of
the registrar_uri parameter.
The CLIENTID and PORT# values are
concatenated, with no white space
or other delimiters between them.
realm A realm identifier that corresponds Y Y All Yes, Defined in

to the service provider domain in except defined in authentication
which the POTS line is registered. package authentic security method
The realm identifier is used in the C, D, ation REALM using
authentication of the user agent. and E security ed-ONTVOICEPO
This is a string of up to 99 characters method. RTSIP
and is an optional parameter. The In TL1
default is to use the realm parameter length is
from the 401/407 authentication up to 25
challenge. characters
Some devices use an SS 401 response. .
Contact your support representative
username The user name to be used for Y Y All Yes, in Defined in

authentication for all SIP requests TL1 length authentication
made on behalf of the SIP AOR. This is up to 50 security method
data element affects the behavior of characters USERNAME using
both the voice software and the ed-ONTVOICEPO
iConfig client. This is a string of up to RTSIP
99 characters. The default value is
the user portion of the AOR.
password A password that is associated with Y Y All Yes, in Defined in
the AOR in the service provider TL1 length authentication
domain that is identified by the is up to 25 security method
realm identifier and is used in the characters PASSWORD using
authentication of the user agent. ed-ONTVOICEPO
This is a string of up to 99 characters RTSIP
and is an optional parameter.
(1 of 2)


1 2 support?
contact_uri_use Mandatory parameter of the user Y Y Package No, N/A

r name portion of the contact URI that A, B, H USERAOR
ContactURIUser represents the port on behalf of only parameter
which the user agent acts. The user is used
name of the contact URI is the value
of the contact_uri_user property.
The host value portion of the contact
URI is the numeric IP address of the
user agent. The contact URI is
registered against the AOR. This is a
string of up to 99 characters and a
required parameter. The FTP XML
name of this parameter is shown as
ContactURIUser.
When the string autofill is used, this
keyword substitutes a new
contact_uri_user value, taking the
form:
CLIENTID + PORT#
where
CLIENTID is the TL1 and OMCI
configured value for CLIENTID
PORT# is the numeric port value,
from 1 to n, where n is the numeric
port number for the POTS line
The CLIENTID and PORT# values are
concatenated, with no white space
or other delimiters between them
For other devices, the contact URI is
a “sip” URI whose user name is the
value of the contact_uri_user
property and whose domain is the
FQDN of the user agent, if available,
otherwise the numeric IP address of
the user agent. The Contact URI shall
be registered against the AOR.
Some devices only use the IP address
to populate the contract header.
Contact support for more
information.
primary_identit Specifies up to 10 identity data sets Y Y All No, value N/A

y may be associated with a single voice except is derived
line. If more than one data set is package from
specified, only one should be C, D, download
specified as the primary identity. and E / default
The primary identity is the one to be line
used in outgoing calls and profile.
subscriptions from the line with
which it is associated. If more than
one identity data set has this
property set to true/1/yes or if none
does, the voice client may use any of
the configured identities. The
default is false/0/no.
(2 of 2)

Analog local network profile

Table 22-12 lists the analog local network profile parameters. When OMCIv2
support is yes, then TL1 can be used to configure equivalent parameters on systems
supporting OMCIv2.
Table 22-12 Analog local network profile provisioning parameters
Parameter Description Mode Mode Device OMCIv2 TL1

permanent_timer The duration, in seconds, of the Y Y All Yes but no N/A

PermanentTimer “permanent” timer (sometimes TL1
known as the “start dial” timer). This developed
timer starts when an off-hook Value is
condition is detected on the POTS derived
line, and if it expires before any digits from
are received from the POTS line, download
permanent treatment is applied to / default
the line. This is an optional line
parameter. This is a non-zero positive profile.
integer and the value is expressed in
seconds. The default value is 16.
interdigit_timer The duration, in seconds, of the Y Y All No, value N/A

InterDigitTimer standard interdigital timer. This is derived
timer starts after a digit is received from
from the analog line interface, and if download
it expires before another digit is / default
received, dialing is assumed to be line
completed. This is an optional profile.
parameter. This is a non-zero positive
integer and the value is expressed in
seconds. The default value is 16.
critical_timer The duration, in seconds, of the Y Y All Yes but no N/A

CriticalTimer “critical” interdigital timer. This TL1
timer starts at a point in digit developed
collection specified by the dialing Value is
pattern, and if it expires before derived
another digit is received, dialing is from
assumed to be completed. This is an download
optional parameter. This is a / default
non-zero positive integer and the line
value is expressed in seconds. The profile.
default value is 4.
timed_release The duration, in seconds, of the Y Y All Yes RLSTIMER

TimedReleaseTim Timed Release timer. To end a using
er conversation, the local or remote ed-ONTVOICE
subscriber hangs up. If the local PORTSIP
subscriber hangs up, BYE is sent to
the softswitch immediately unless
this was a termination end of the call.
If the local call was the termination
call, BYE is not sent and the idle state
is entered until the re-answer timer
expires or BYE is received. The
re-answer timer is configured using
the reanswer_timer parameter.
This is an optional parameter. This is
a non-negative integer and the value
is expressed in seconds. The default
value in the XML file is 10 seconds.
The default is 10 for TL1.
(1 of 4)


release_treatmen Specifies the treatment applied to a Y Y All Yes TBD using

t port that has originated a call but the ed-ONTVOICE
phone remains off-hook after the PORTSIP
called party has hung up and the time
specified in the timed_release
parameter expires.
The options are ‘permanent’ and
‘reoriginate’. The default is
permanent.
When you choose permanent,
following the restoration of loop
current a reorder tone is played
followed by a receiver off hook tone.
If the timer elapses on both those
tones then the line is locked out until
it goes on-hook.
When you choose reoriginate,
following the restoration of loop
current the line is treated the same
as if an on-hook to off-hook transition
was detected. The off-hook state is
transitioned to a new call origination.
enter_key The digit that is to be treated as an Y Y Package No, value N/A

EnterKey indication that dialing is complete, A, B, H is derived
when received at a point in digit only from
collection where it does not match download
the dialing pattern at that point. This / default
is typically used to signal the line
completion of dialing a speed dialing profile.
number or an international number.
This is an optional parameter. The
hash mark symbol “#” is the default
value.
Other devices always use #.
(2 of 4)


resanswer_timer Specifies the reanswer timer. N Y Package No, value N/A

The default value is a string A, B, H is derived
use_timed_release. You can also use only from
a non-negative integer to indicate the reanswer_
reanswer timer value. A value of 0 timer XML
causes the user agent to send a BYE value
immediately upon on-hook.
In the case of an integer, the timer
governs the following behavior. On an
inbound call, if the analog line goes
on-hook, the User Agent maintains
the dialog and start the
reanswer_timer. The media session
remains active with the user agent
transmitting RTCP packets as usual,
and silence if the current audio
format requires, and receiving audio.
If the analog line goes off-hook before
the timer expires, the analog line
resumes participation in the media
session of the dialog, and the timer is
canceled. If a BYE is received before
the timer expires, the user agent
idles the analog line and cancel the
timer.
If the timer expires with the line
remaining on-hook, the User Agent
idles the line and end the dialog by
sending a BYE. A value of 0 will cause
the User Agent to send BYE
immediately upon on-hook.
error_tone_timer This parameter is a string containing N Y Package No, value N/A

either a non-negative integer value or A, B, H is derived
the text use_timed_release. The only from
options are used_timed_released timed_rel
(default) and a non-zero integer. ease XML
If the parameter has an integer value value
then the value governs the time, in
seconds, that tones are generated in
response to INVITE errors before
starting permanent signal treatment.
If the parameter is set to
use_timed_release timed_release
parameter has a value of 0, the timer
is set to 10 seconds. If the
use_time_release value is used, then
BUSY is the only error condition
whose duration is governed by the
timed_release. All other errors will
result in immediate permanent signal
treatment.
(3 of 4)


auto_connect_tim This parameter is a string containing N Y Package No, value N/A

er either a non-negative integer value or A, B, H is derived
the text use_timed_release. If this only from
parameter has an integer value it will timed_rel
govern how long the device waits ease XML
before resuming a held remote call value
when an active remote call goes
on-hook. If the value
use_time_release is selected and the
timed_release parameter has a value
of 0, this timer is set to 10 seconds.
(4 of 4)
Media local network profile

Table 22-13 lists the media local network profile parameters. When OMCIv2 support
is yes, then TL1 can be used to configure equivalent parameters on systems
supporting OMCIv2.
Table 22-13 Media local network profile provisioning parameters
Parameter Description Mode Mode Device OMCIv2 TL1 parameter

1 2 support?
codec An audio format name, chosen from Y Y All Yes COCEC1ST,

among the audio MIME types CODEC2ND,
registered with the IANA (many of CODEC3RD,
which are listed in RFC 3555). More CODEC4TH using
than one codec setting may appear in ent-profile-voip
the provisioning data; the sequence of media
all such codec setting values, in
descending order of q value, is used
by the user agent to create an ordered
list of codec formats sent in an initial
offer and is used to define the order
of formats sent in an answer. The
audio/telephone-event format
specified by RFC 2833 is implicitly
included by the user agent in all
offers, and in all answers to an offer
that includes that format, and thus a
setting including that format is never
required. The following codec values
are supported:
• audio/PCMA (for G.711 A-law)
• audio/PCMU (for G.711 Mu-law)
• audio/G722 (for G.722)
Other values are silently ignored.

These values are case insensitive. The
default value is “audio/pcmu”.
(1 of 4)


1 2 support?
qos-dscp The differentiated services code point Y Y Package Yes DSCP using
(DSCP) value that should populate the A, B, H ent-profile-rtp
DS field of RTP packets sent by the only
user agent. It is an integer value in the
range of zero (0) to 63. The default
value is the value configured via
SNMP/TL1. The TL1 default is 46.
local-ports A range of port numbers specifying Y Y Package Yes LOCALPORTMIN

the minimum and maximum ports A, B, H and
numbers to be used by the user agent only LOCALPORTMAX
for RTP media. NOTE: Only one value using
is set for this parameter across all ent-profile-rtp
ports in the system. This is a string.
The range is specified as a lower
bound and an upper bound, separated
by a dash. For XML, these bounds are
decimal integer values between 0 and
65535. The default range is
5004-6003. For some devices,
increments of 4 are used, starting
with the first port for RTP and RTCP
ports. Contact your support
representative for more information.
For TL1, the range is 5000 to 65000
and the default is 50000 for the
minimum value and 60000 for the
maximum value.
enable_t38 Indicates whether T.38 support is Y Y All Yes, TL1 FAXMODE using
enabled. This is a string containing a default is ent-profile-voip
value of “yes” or “no.” The default no but media
value for XML is “yes.”. The default XML
value for TL1 is PASSTHRU. default is
yes. TL1
takes
precedenc
e
(2 of 4)


1 2 support?
enable_rfc283 Indicates whether voice activity Y Y All Yes OOBDTMF using

3 detection is enabled for voice ent-profile-voip
encoding. In order for DTMF tones to media
be encoded in RFC 2833 packets,
there must be SDP negotiation and
agreement at both ends of the bearer
channel. The ONT or MDU will offer
RFC 2833 or include it in an SDP
response only if the enable_rfc2833 is
set to yes. This is a string containing a
value of “yes” or “no.”. The default
value is “yes.”
When set to ‘far_end_symmetry”,
during SDP negotiations of the RFC
2833 payload type, the ONT offers the
configured
dynamic_codec_payload_map_entry
value for RFC 2833. However, if the
ONT receives an answer to an offer
with a different payload type, the
ONT uses that payload type for both
the sending and receiving of RFC 2833
packets.
ONTs will explicitly include the SDP
direction attribute of sendrcv when
the current call connection is in a
2-way conversation.
enable_vad Indicates whether voice activity Y Y All Yes, SILENCE1ST

detection is enabled for voice always using
encoding. This is a string containing a defined in ent-profile-voip
value of “yes” or “no.” The default first order media
value is “no.” of silence
suppressio
n used
packetization This parameter controls the Y Y All Yes, PERIOD1ST using

_interval packetization rate which each line of always ent-profile-voip
the voice client (ONT or MDU) will use defined in media
in the offer/answer SDP messages for first order
the RTP packet rate it requests to of packet
receive. The units are milliseconds period
between successive frames. The voice selection
client can offer a subset of the range used
of values of 10 to 30 (10, 20, 30 are
supported). The value actually used
will be rounded to the nearest
supported value. The default value is
10 when using a download method and
20 when using iConfig to configure
SIP.
enable_info_b This parameter specifies whether the Y N All No, value N/A
ased_dtmf voice client transmits DTMF digits in except is derived
INFO method SIP messages rather than package from
inband or via RFC 2833 signaling. C, D, download
When enabled, this parameter takes and E / default
precedence over the enable_rfc2833 line
parameter. The content type for the profile.
INFO messages is controlled by the
content_type_for_info parameter.
The default value is “no” (disabled).
(3 of 4)


1 2 support?
content_type_ This parameter specifies the content Y N All No, value N/A
for_info type to be sent in INFO messages that except is derived
carry DTMF tones and flash hook package from
events. The two supported values for C, D, download
this parameter are and E / default
“audio/telephone-event” and line
“application/broadsoft”. If an profile.
unrecognized value is specified, the
default value is used. The default
value is “application/broadsoft”.
default_packe This parameter specifies the rate at Y Y Package No, value N/A
tization_inter which the ONT generates RTP frames A, B, H is derived
val if the far end does not request a only from
specific rate during the SDP download
offer/answer phase of establishing a / default
call. The default is 10 milliseconds line
when using a download method profile.
download and 20 milliseconds when
using iConfig to configure SIP.
ptime_symme Specifies control over the N Y All No, XML N/A
tric interpretation of the except developed
packetization_interval and package for
default_packetization_interval C, D, specific
parameters. The parameter accepts and E customer
two values: no_symmetry (default) interop
and far_end_symmetry. For further
details see those parameters.
annexb_in_sd Specifies the appearance of the N Y All No, value N/A
p annexb parameter in the SDP during except is derived
negotiation of G729 as a codec as package from
follows. If enable_vad is set to C, D, download
Yes/True/1, then the string and E / default
a=fmtp:18 annexb=yes is added to the line
SDP. When set to No/False/0, then profile.
the string a=fmtp:18 annexb=no is
added to the SDP. If the SDP codec list
does not include G.729 or this
parameter is set to False/No/0, then
the annexb text is not added to the
SDP under any circumstances. The
default is No/False/0.
dtmf_volume_ Specifies the volume field sent in the N Y All No, value N/A
level RFC 2833 packets that encode DTMF except is derived
from the attached phone. When the package from
parameter is set to measured, then C, D, download
the volume of the tone received in and E / default
dBm0 from the attached phone will be line
reported in the RFC 2833 packets. profile.
When the parameter is set to an
integer between 0 and 55, then that
value will be used in the volume field
of any transmitted RTC 2833 packets
signaling DTMF. The default is
measured.
(4 of 4)
Service data set

Table 22-14 lists the service parameters per port. When OMCIv2 support is yes, then
TL1 can be used to configure equivalent parameters on systems supporting OMCIv2.

Table 22-14 Service data provisioning parameters per port

digit_map A pattern that guides digit collection Y Y All Yes but no N/A
DigitMap and allows the user agent to TL1
determine when dialing is complete. developed
One digit_map setting is supported Value is
for each POTS port. See Tables 22-15 derived
and 22-16 for a description of the from
digit map content based on ONT download
package types. This is a string of up / default
to 1093 characters and is a required line
parameter with no default value. A profile.
digit map must be customized for
each SIP implementation based on
the features of the SIP server in the
network.
White space in the digit map string is
not significant. Characters are case
insensitive.
Some devices use the MGCP format.
Contact your support representative
for a list.
outbound_uri_pref A string added as a prefix to the Y Y Package No, value N/A

ix dialed digits to form the Request URI A, B, H is derived
OutboundURIPrefix and the To URI when sending an only from
(1) INVITE request to the softswitch. download
This is a sting of up to 99 characters / default
and is an optional parameter. The line
default value is “sip.” The FTP XML profile.
name of this parameter is shown as
OutboundURIPrefix
configured. (1)
when the oubound_uri_suffix
value is not configured
value is configured
For other devices, the default is

“sip:” that cannot be changed
(1 of 23)


outbound_uri_suffi A string that is added as a suffix to Y Y Package No, value N/A

x the dialed digits to form the Request A, B, H is derived
URI and the To URI when sending an only from
INVITE request to the softswitch. The download
specified string is added as is if the / default
string contains an @ character. If an line
@ character is not present, then @ is profile.
prefixed to the specified value. This
string of up to 99 characters is an
optional parameter. The default
value is “@” + outbound_proxy. The
FTP XML name of this parameter is
shown as OutboundURISuffix.
configured. (2)
value is not configured
value is configured
For other devices, the default is an

empty string that cannot be
changed.
service_code_ccw A set of one or more service codes, N Y Package Yes CANCELWAIT

such as *70, that the user agent A, B, H using
recognizes as the Cancel Call Waiting only ent-profile-a
service code. This reflects that fact cccodes
that in typical dial plans there are
two equivalent ways to dial a given
service code. This is a string. The
value of this property may include up
to two service codes separated by
white space. The default is “*70
1170.” In XML the length can be up to
6 characters. In TL1, the length can
be up to 5 characters.
The same service code values must
be present in the digit map with an
‘S’ modifier and no ‘R’ modifier.
If a configured value also appears in
the digit map with an S modifier then
they will be processed during dialing
for the associated feature. If the
value is not in the digit map with an
S modifier, then the digits will be
treated as normally dialed digits and
not be specially processed.
Use the appropriate enable_XXX
parameter to enable the service
code.
For other devices, the value is “*70
1170 and cannot be changed.
(2 of 23)


service_code_6wc A set of one or more service codes N Y Package No, value N/A
that the user agent recognizes as a A, B, H is derived
request to initiate a six-way only from
conference. This reflects that fact download
that in typical dial plans there are / default
two equivalent ways to dial a given line
service code. This is a string. The profile.
value of this property may include
two service codes, each up to 6
characters long, separated by white
space. The default is “*41 1141”.
code.
service_code_rls A set of one or more service codes N Y Package No, value N/A
that the user agent recognizes as a A, B, H is derived
request to release a consultation call only from
that was initiated as part of six-way download
conference procedures. This reflects / default
the fact that in typical dial plans line
there are two equivalent ways to dial profile.
a given service code. This is a string.
The value of this property may
include two service codes, each up
to 6 characters long, separated by
white space. The default is “*43
1143”.
code.
(3 of 23)


service_code_hold A set of one or more service codes N Y Package Yes HOLD using
that the user agent recognizes as a A, B, H ent-profile-a
request to place the active call on only cccodes
hold. This reflects that fact that in
typical dial plans there are two
equivalent ways to dial a given
service code. This is a string. The
value of this property may include up
to two service codes separated by
white space.
The default is “*52 1152.” In XML the
length can be up to 6 characters. In
TL1, the length can be up to 5
characters
code.
For other devices, the value is “*52
1152” and cannot be changed.
intercom_code_1 A set of one or more home intercom N Y Package Yes, but INTERCOM
service codes for alerting pattern 1. A, B, H only one using
This reflects that fact that in typical only intercom ent-profile-a
dial plans there are two equivalent code is cccodes
ways to dial a given service code. supported
This is a string. The value of this
property may include up to two
service codes separated by white
space.
The default is “*53 1153.” In XML the
length can be up to 6 characters. In
TL1, the length can be up to 5
characters
For other devices the setting is “*53
intercom _code_2 A set of one or more home intercom N Y Package No, value N/A
service codes for alerting pattern 2. A, B, H is derived
This reflects that fact that in typical only from
dial plans there are two equivalent download
ways to dial a given service code. / default
This is a string. The value of this line
property may include up to two profile.
service codes, each up to 6
characters long, separated by white
space. The default is “*54 1154.”
For other devices the setting is “*53
(4 of 23)


enable_cw Indicates whether the call waiting Y Y All Yes, CALLWAIT set
service is enabled. This is a string enabled if to 3 using
containing a value of “yes” or “no.” both call ent-profile-v
The default value is “yes.” waiting oipappservic
Case 1: enable_caller_id = false, and caller e
enable_calling_name_id = false, ID are
enable_cw = true, PAI header configured
present then call waiting will be
allowed, any CID number present in
PAI header will be displayed.
Case 2: enable_caller_id = false,
enable_calling_name_id = false,
enable_cw = true, PAI header absent
then call waiting will be allowed, any
CID number/ name present in FROM
header will be suppressed.
Case 3: enable_caller_id = true,
enable_calling_name_id = true,
enable_cw = true, PAI header absent
then call waiting will be allowed, any
CID number/ name present in FROM
header will be displayed.
business_cw Indicates whether the business group Y Y All No, value N/A
variant of the call waiting service is except is derived
enabled. This is a string containing a package from
value of “yes” or “no.” The default C, D, download
value is “no.” and E / default
line
profile.
enable_3wc Indicates whether 3-way conference N Y All Yes CALLPROGTR

service is enabled. This is a string AN set to 1
containing a value of “yes” or “no.” using
The default value is “no.” ent-profile-v
oipappservic
e
enable_6wc Indicates whether 6-way conference N Y Package Yes CALLPROGTR
service is enabled. This is a string A, B, H AN set to 80
containing a value of “yes” or “no.” only using
The default value is “no.” ent-profile-v
oipappservic
e
enable_transfer Indicates whether the call transfer N Y All Yes CALLPROGTR

The default value is “no”. ent-profile-v
oipappservic
e
enable_hold Indicates whether the call hold N Y All Yes CALLPROGTR

The default value is “no”. ent-profile-v
oipappservic
e
(5 of 23)


enable_supp_ring Indicates whether the suppressed N Y Package No, value N/A

ringing service is enabled. This is a A, B, H is derived
string containing a value of “yes” or only from
“no.” The default value is “no”. download
/ default
line
profile.
enable_forced_hol Indicates whether the forced hold N Y All Yes CALLPROGTR

d behavior is enabled for an except AN set to 40
emergency call. This is a string package using
containing a value of “yes” or “no.” C, D, ent-profile-v
This is an optional parameter. The and E oipappservic
default value is “no.” e
supp_ring_offhook The time interval within which the N Y Package No, value N/A
_timer device must go offhook for a A, B, H is derived
suppressed ringing call. This is a only from
non-negative integer. The value is download
expressed in seconds. The default / default
value is 5. line
profile.
supp_ring_interrup The time interval within which the N Y Package No, value N/A
t_timer device must go onhook if a A, B, H is derived
suppressed ringing call is only from
interrupted. This is a non-negative download
integer. The value is expressed in / default
seconds. The default value is 2. line
profile.
conference_uri The URI of the conference server to N Y Package Yes CONFURIPRO

be used for the 6-way conference A, B, H FID using
service. only ent-profile-v
oipappservic
e
direct_connect_uri The URI to be inserted as the To Y Y All Yes DIRCONNURIP

address of an INVITE sent in response PROFID using
to the device going off-hook. If this ent-profile-v
property is set, an off-hook event oipappservic
triggers an immediate INVITE with e
the value of this property as the To
address. If this property is not set, an
off-hook event provides the dial tone
to the port, allowing the user to dial
a call in the usual manner.
In XML this is a string of up to 99
characters and is an optional
parameter. In TL1 this is a string of
up to 32 characters. The default
value is a null string, which indicates
no direct connect. Set the
enable_warmline parameter to “yes”
to use the direct_connect_uri
parameter.
(6 of 23)


message_event_uri The URI to which a subscription for N Y Package Yes VOICEMAIL

message-waiting events is sent. If A, B, H using
this property is not set, the user only ed-ONTVOICE
agent shall not subscribe for message PORTSIP
waiting events. This value is a URI
The default is no URI, which disables
subscribe. When the parameter is set
to URI, you can configure the
allow_unmatched_notify parameter.
When the string autofill is used, this
keyword substitutes a new
message_event_uri value based on
the filled value, after any derived
value, of the address_of_record
parameter.
For other devices, the value is an
empty string and cannot be changed.
message_waiting_ The mode for presenting a Y Y All Yes CALLPRESENT

mode message-waiting indication to the except set to 7 using
user. This is a sequence of up to package ent-profile-v
three values: “dial-tone” to enable C, D, oipappservic
stutter dial tone, “visual” to enable and E e
visual MWI, and “reminder-ring” to
enable a reminder ring. Any
combination of the three may be
specified. This is an optional
parameter. The default value is
“dial-tone.”
You can specify more than one value
at a time in the XML file. Separate
the values using spaces.
vmwi_refresh_inte The duration, in minutes, of the Y Y All No, value N/A

rval interval between successive except is derived
“refresh” transmissions of the package from
message-waiting status to the analog C, D, download
line, if “visual” is specified in and E / default
message_waiting_mode. If the value line
of this property is zero, “refresh” profile.
transmissions will not be performed.
This is an optional parameter. This is
a non-negative integer expressed in
minutes. The default value is 30.
vmwi_abbreviated Indicates whether the abbreviated Y Y Package No, value N/A
_ring ring option is enabled. This is a string A, B, H is derived
containing a value of “yes” or “no.” only from
This is an optional parameter. The download
default value is “no.” / default
For other devices the value is no and line
cannot be changed. profile.
mwi_reminder_bur The duration of the message-waiting Y Y Package No, value N/A

st reminder ring burst. This is an A, B, H is derived
optional parameter. This is an only from
integer expressed in milliseconds. download
The default value is 500. / default
line
profile.
(7 of 23)


mwi_reminder_int The duration of the interval between Y Y Package No, value N/A
erval message-waiting reminder ring A, B, H is derived
bursts. This is an optional only from
parameter. This is a non-negative download
integer expressed in minutes. The / default
default value is 15. line
profile.
bridged_line_uri The bridged line agent URI if the Y Y Package Yes BRIDGEURIPR
bridged line service is enabled. If this A, B, H OFID using
property is not set, the user agent only ent-profile-v
does not enable the POTS line to act oipappservic
as one of a set of bridged lines. e
bridged_line_dialo The bridged line dialog URI used by Y Y Package No, value N/A
g_uri the bridged line service. If this A, B, H is derived
property is not set, the user agent only from
uses the bridged_line_uri setting as download
the bridged line dialog URI. / default
line
profile.
cfwd_state Indicates whether the state of the Y Y Package Yes CALLPRESENT

network-based call forwarding A, B, H set to 8 using
service is to be rendered to the only ent-profile-v
user.This is a string containing a oipappservic
value of “yes” or “no.” The default e
value is “no.”
cfwd_reminder Indicates whether a reminder alert is Y Y Package No, value N/A

to be provided to the user when the A, B, H is derived
network-based call forwarding only from
service redirects a call. This is a download
string containing a value of “yes” or / default
“no.” The default value is “no.” line
profile.
cfwd_event_uri The URI to which a call forwarding Y Y Package No, value N/A
event subscription is sent. If this A, B, H is derived
property is not set, but either only from
cfwd_state or cfwd_reminder is set download
to “yes,” the call forwarding event / default
subscription is sent to the URI line
specified in the address_of_record profile.
property. This value is a URI.
obsolete_hold Indicates whether the user agent N Y Package No, value N/A
must use the obsolete hold A, B, H is derived
convention (a connection address of only from
0.0.0.0) when placing a media download
stream on hold. This is a string / default
containing a value of “yes” or “no.” line
The default value is “yes.” profile.
session_timer_min The minimum acceptable value for Y Y Package No, value N/A
the RFC 4028 session timer interval. A, B, D, is derived
This is a non-negative integer. The H only from
value is expressed in seconds. The download
default value is 90, which is the RFC / default
4028 absolute minimum. line
profile.
(8 of 23)


session_timer_max The RFC 4028 session timer interval Y Y Package No, value N/A
to be proposed by the user agent. A, B, D, is derived
This is a non-negative integer. The H only from
value is expressed in seconds. The download
default value is 1800, which is the / default
RFC 4028 recommended value. line
profile.
session_timer_refr Specifies the refresher to be Y Y Package No, value N/A

esher specified by the user agent when it A, B, D, is derived
has a choice. A value of “none” H only from
specifies that the user agent will not download
request session expiration. Any other / default
value specifies that the user agent line
will request session expiration. This profile.
is a string containing either “none,”
“uas,” or “uac.” The default value is
“uas.”
cid_allows_from_h A value specifying whether Y Y Package No, value N/A
dr information from the FROM header A, B, H is derived
may be used in providing caller ID to only from
the phone set. Information from download
P-Asserted-Identity header is always / default
used in preference to the FROM line
header. This value only has effect profile.
when no P-Asserted-Identity
information is available. A “yes”
means that the FROM header will be
used for the caller ID if the
P-Asserted-Identity header is not
present in the INVITE message. A
“no” means that, if the
P-Asserted-Identity header is not
present, then no caller ID is provided
to the phone set. The default value is
“no”.
enable_caller_id The same as the Y Y Package No, value N/A
cid_allows_from_hdr parameter C, D, E, is derived
F, and G from
download
/ default
line
profile.
ansi_caller_id_ext Specifies the number of caller ID Y Y Package No, value N/A

_digits digits displayed. Only displayed for A, B, H is derived
GSIP v4.6 and later software. only from
By default (false) the number of Does not download
digits displayed is 10. If set to true, apply on / default
the number digits displayed is package line
extended up to 20. C, D, profile.
This parameter takes effect only if and E
the enable_etsi parameter is ONTs or
disabled (set to false). MDUs
(9 of 23)


allow_unmatched_ This parameter governs behavior to Y Y Package No, value N/A

notify allow a NOTIFY with full dialog A, B, H is derived
headers (indicating that they are only from
part of a dialog) to be accepted by download
the ONT that does not match a / default
known SUBSCRIBE dialog. The line
contents of such an unmatched profile.
NOTIFY will be ignored. The default
is “no”, meaning that a NOTIFY with
full dialog headers must match a
known SUBSCRIBE dialog or a 481
error will result. If the parameter is
set to yes, the contents of such an
unmatched NOTIFY will be ignored.
This parameter should not be set to
“yes” if implicit NOTIFY messages
are expected from the softswitch
(for example, no SUBSCRIBE is
performed).
For other devices, the value is no and
cannot be changed.
rfc2833_symmetric This parameter governs the SDP Y Y All No, value N/A
offer/answer processing related to is derived
the payload type to use with from
RFC2833. If this parameter is set to download
“yes”, then it means that the same / default
payload types will be used for both line
send and receive RFC2833 packets. profile.
The payload type to be used will be
based on the SDP offer or answer
from the ONT. If this parameter is set
to “no” then the payload types to be
used for send and receive RFC2833
packets are set according to the
rules in RFC3264 section 5.
If this parameter is set to
“far_end_symmetry”, the same
payload type will be sent for both
send and receive RFC2833 packets.
The payload type to be used will be
based on the SDP offer or answer
received from the far end of the call.
The default is “no”
(10 of 23)


dynamic_codec_pa This is a list of ordered pairs that Y Y Package No, value N/A
yload_map_entry specify the dynamic payload A, B, H is derived
numbers to be used by the ONT for only from
specific payload types, identified by download
IANA MIME type. / default
The value specified is the dynamic line
payload number sent by the voice profile.
client as part of its offer-answer SDP
negotiation. Specifically an ordered
pair of a <mimetype> entry and a
<payload_number> entry. More than
one such map entry may be present.
Since R1.6 the software allows for
only 2: “audio/G726-32” or
“audio/telephone-event”. Any other
mimetype will be ignored along with
its payload number. Processing of
mimetypes will be case insensitive.
The <payload_number> entry is an
integer in the range of 96 to 127. It is
an error to specify two mimetypes to
map to the same payload number.
Such errors will cause the profile not
to be used.
Any other mimetype value along with
its associated payload_number will
be ignored. The payload_number
entry is an integer in the range of 96
to 127 inclusive. It is an error to
specify two mimetypes that map to
the same payload number. Such
errors will cause the profile not to be
used. The default for
“audio/G726-32” is 98. The default
for “audio/telephone-event” is 97.
obsolete_stale This value controls the behavior of Y Y Package No, value N/A
the ONT with respect to nonce A, B, H is derived
expiration and re-registration or only from
dialog refreshes. download
If this value is set to “true” then if / default
the ONT receives an authentication line
reject (401 or 407 error) that profile.
contains a new nonce value, but no
stale-flag, the ONT should behave as
if a stale=true was present and send
the refresh with the new nonce value
Note that the ONT will still properly
handle the stale-flag, if present. If
the obsolete_stale value is set to
“false”, then if the stale-flag is not
present in the 401/407 message,
RFC2716 compliant behavior will be
followed, and the registration or
dialog that was being refreshed will
be terminated. The default value is
“false” when using a download
method download and “true” when
using iConfig to configure SIP.
(11 of 23)


thin_client_HF_me If the voice client is in thin mode (SIP Y N Package No, value N/A
thod mode 1), the flash hook processing A, B, H is derived
behavior is controlled by this value. only from
If the value is set to ‘info’, the hook download
flash indication is sent using an INFO / default
message to the softswitch. If the line
value is set to ‘invite’, the ONT profile.
passes the HF event to the softswitch
using an INVITE message with the
request-URI set to the value of the
thin_client_HF_request_URI value.
thin_client_HF_re This value contains the string value Y N Package No, value N/A
quest_ to be used as the user portion of the A, B, H is derived
URI INVITE request when the ONT is in only from
thin client (SIP mode 1) and the download
thin_client_HF_method is set to / default
‘invite’. The default is line
‘LucentTISPAN-FlashRequest’. profile.
cfwd_implicit This value controls whether the voice Y Y Package No, value N/A
client will SUBSCRIBE to call A, B, H is derived
forwarding status NOTIFY messages only from
or whether the voice client will download
expect to receive NOTIFY messages / default
without a subscription. line
If the value is set to ‘no’, the voice profile.
client subscribes if either of the
cfwd_state or cfwd_reminder values
are set to ‘yes’.
If the value is set to ‘yes’, the voice
client will process NOTIFY messages
without having performed a
SUBSCRIBE.
The default value is ‘no’.
session_timer_met This value controls which SIP method Y Y Package No, value N/A
hod is used for session timer A, B, H is derived
functionality. The options are only from
‘update’ or ‘invite’. The default is download
‘invite’. / default
line
profile.
(12 of 23)


enable_warmline This value controls whether the Y Y Package Yes DIRCONNECT

warm line feature is enabled. A, B, H set to 0 or 1
If the value is set to ‘yes’, warm line and on using
is enabled. When warm line is I-240G- ent-profile-v
enabled, if the permanent_timer U oipappservic
expires before a caller who has e
picked up the phone (gone off hook)
dials any digit, the CPE device sends
an INVITE request using the value
specified in the direct_connect_uri
property as the requested URI.
The default is ‘no’, warm line is
disabled.
As of R4.4, the parameter is changed
to a string value. The options are:
• True/1/Yes
• False/0/No (default)
• Subscriber
When set to Subscriber, the

subscriber can activate or deactivate
the warmline service and configure
the default destination number for
warmline calls.
enable_etsi This parameter controls whether the N Y All No, value N/A
ONT acts in accordance with ETSI or except is derived
GR requirements for offering package from
services. A value of “yes” enables C, D, download
ETSI behavior. The default is “no”. and E / default
line
profile.
etsi_ch_release This parameter contains the value of N Y All No, value N/A
the consult call service option code except is derived
which is used to drop the active package from
session and resume held session as a C, D, download
two-way call ending the consult and E / default
state. If this parameter is not line
configured or is configured to profile.
contain the empty string, the ONT
disables the functionality.
Valid values are in the form “Rd,
where d represents '0'-'9' or '*' or '#'.
An invalid value causes the ONT to
act as if this parameter was not
configured. This parameter only has
meaning if the enable_esti
parameter is set to “yes”. The
(13 of 23)


etsi_ch_toggle This parameter contains the value of N Y All No, value N/A
used to toggle between two sessions. package from
If this property is not configured or is C, D, download
configured to contain the empty and E / default
string, the ONT disables this line
functionality. profile.
etsi_ch_merge This parameter contains the value of N Y All No, value N/A
which is used to merge two sessions package from
to a 3-way call with mixing in the C, D, download
ONT. If this property is not and E / default
configured or is configured to line
contain the empty string, the ONT profile.
disables this functionality.
etsi_3wc_split This parameter contains the service N Y All No, value N/A
code that takes a 3wc to a consult except is derived
call state in the ETSI mode. If this package from
parameter is not configured or is C, D, download
string, the ONT disables the split call line
operation for the line in question. profile.
(14 of 23)


etsi_cw_release This parameter contains the service N Y All No, value N/A
code used to release the active except is derived
session and resume the held call as a package from
two way call ending the call waiting C, D, download
state. If this parameter is not and E / default
configured or is configured to line
contain the empty string, the ONT profile.
disables the release active session
operation for the line in question.
etsi_cw_toggle This parameter contains the service N Y All No, value N/A
code to be used to toggle between except is derived
sessions during call waiting. If this package from
parameter is not configured or is C, D, download
string, the ONT disables the toggle line
session operation for the line in profile.
question.
etsi_cw_merge This parameter contains the service N Y All No, value N/A
code to be used to merge the 2-call except is derived
waiting sessions and transition into a package from
3-way call with mixing in the ONT. If C, D, download
this property is not configured or is and E / default
configured to contain the empty line
string, the ONT disables the merge profile.
sessions operation for the line in
question.
cw_alert_timer This parameter specifies the value, N Y All No, value N/A
in seconds, of the duration for which except is derived
the user is allowed to answer a call package from
waiting call. The default is 120 C, D, download
seconds. and E / default
line
profile.
(15 of 23)


enable_dead_line_ This parameter controls ONT Y Y All No, value N/A

tone behavior with respect to playing a except is derived
“dead line tone” when the user goes package from
off-hook and either: C, D, download
• the line is unregistered and E / default
line
• the PON is unavailable
profile.
• addressing could not be obtained
from the DHCP server
The default is “no”, indicating that

no tone is output in either case.
enable_reverse_po This parameter controls whether N Y All No, value N/A

larity reverse polarity is used. except is derived
This parameter can be configured package from
only when the enable_etsi C, D, download
parameter is set to yes. It must be and E / default
configured for each line. When line
enabled: profile.
For the originator of a call, polarity is
reversed when the call is answered
(200 OK received). For the
terminator of a call, polarity is
reversed prior to the start of ringing.
For either the originator or
terminator, when the call ends
because BYE received, normal
polarity is resumed. For the
originator, if the user goes on-hook,
normal polarity is resumed. For the
terminator, if the user goes on-hook,
reverse polarity continues until the
re-answer timer expires, then
normal polarity is resumed.
The default is “no”. Set to “yes” to
enable reverse polarity.
All lines of I-240W-S ONT should be
configured the same. The I-240W-S
does not support polarity reversal of
terminating calls.
enable_calling_na This parameter determines whether Y Y All Yes CALLERID set

me_id a display name is output to the phone except to 2 using
set. package ent-profile-v
When the parameter is set to ‘yes C, D, oipappservic
(default), the display name is and E e
included as part of the caller ID
output data. When the parameter is
set to ‘no’, the display name is not
included as part of the caller ID
output data.
(16 of 23)


callerid_uri_prefer This parameter specifies whether to Y Y All No, value N/A

ence set tel-uri as a higher priority than except is derived
sip-uri, when there is more than one package from
p-assert header present. C, D, download
Supported parameters are ‘sip’, and E / default
‘tel’, or ‘first’. Unsupported values line
are mapped to ‘first’. If an incoming profile.
call contains more than one p-assert
header, this parameter controls
which header is used to populate the
caller ID data output on the phone
set.
When the parameter is set to ‘sip’,
the p-assert header that is formed
with a sip-uri will be used. When the
parameter is set to ‘tel’, the p-assert
header that is formed with a tel-uri
will be used. When the parameter is
set to ‘first’ (default), it indicates
the p-assert header that occurs
earlier in the incoming INVITE will be
used for the caller ID data. The
default is ‘first’
add_media_level_ This parameter controls the N Y All No, value N/A

cline presence of the second “c-line”, or except is derived
contact address, in the SDP for package from
obsolete hold. This parameter is C, D, download
ignored when the obsolete_hold and E / default
parameter is not enabled. The line
options are “yes” (default) meaning profile.
the second c-line will be added as
part of the media description, and
“no”, meaning only a single
session-level c=line is present in the
SDP, and it is set to 0.0.0.0.
direction_in_hold_ This parameter controls the value of N Y All No, value N/A
req direction attribute inserted into the except is derived
hold SDP when standard hold package from
behavior is enabled. This parameter C, D, download
is ignored when the obsolete_hold and E / default
parameter is enabled. The options line
are “sendonly” (default) and profile.
“inactive”, which correspond to the
direction attribute that is used in
SDP for the hold request.
etsi_ch_release_h This parameter contains the service N Y All No, value N/A
eld_call code to be used to release the held except is derived
session during a consultation call. If package from
this property is not configured or is C, D, download
string, the ONT shall disable this line
functionality. Valid values shall be of profile.
the form “Rd”, where d represents
'0'-'9' or '*' or '#'. An invalid value will
cause the ONT to act as if this
parameter was not configured. This
parameter only has meaning if the
enable_esti parameter is set to
“yes”. The default is an empty
string.
(17 of 23)


etsi_activate_call_ A set of one or more service codes N Y All No, value N/A
waiting that the user agent will recognize as except is derived
a request to activate call waiting in package from
ETSI mode. The value of this C, D, download
property may include up to two and E / default
service codes of six characters each, line
separated by white space. This profile.
reflects that fact that in typical dial
plans there are two equivalent ways
to dial a given service code. The
default is “*43#”.
etsi_deactivate_ca A set of one or more service codes N Y All No, value N/A
ll_ that the user agent will recognize as except is derived
waiting a request to de-activate call waiting package from
in ETSI mode. The value of this C, D, download
property may include up to two and E / default
service codes of six characters each, line
separated by white space. This profile.
default is “#43#”.
etsi_interrogate_c A set of one or more service codes N Y All No, value N/A
all_waiting that the user agent will recognize as except is derived
a request to interrogate call waiting package from
active status in ETSI mode. The value C, D, download
of this property may include up to and E / default
two service codes of six characters line
each, separated by white space. This profile.
default is “*#43#”.
ets_ch_release_he This parameter contains the service N Y All No, value N/A
ld_call code to be used to release the held except is derived
session during a consultation call. If package from
this parameter is not configured or is C, D, download
string, the ONT disables the line
functionality. Valid values shall be of profile.
the form “Rd”, where d represents
'0'-'9' or '*' or '#'. An invalid value will
cause the ONT to act as if this
parameter was not configured. This
parameter only has meaning if the
enable_esti parameter is set to
“yes”. The default is an empty
string.
(18 of 23)


etsi_3wc_split_pre This parameter contains the service N Y All No, value N/A
conf code to be used to split a 3-way call except is derived
and return to the pre-conference package from
state. If this property is not C, D, download
configured or is configured to and E / default
contain the empty string, the ONT line
shall disable this functionality. Valid profile.
values shall be of the form “Rd”,
An invalid value will cause the ONT
to act as if this parameter was not
enable_call_hold_t This parameter controls whether or N Y All No, value N/A

one not the ONT will play the call hold except is derived
tone to the user when the associated package from
RTP session is inactive or “sendonly”. C, D, download
This parameter only applies when and E / default
the enable_esti parameter is set to line
“yes”. The default is “no” profile.
etsi_recall_dial_to This parameter contains the name of N Y All No, value N/A
ne_name the tone to be played to indicate to except is derived
the user that mid-call dialing is package from
allowed. Possible values are C, D, download
“DialTone” or “RecallDialTone”. This and E / default
parameter only applies when the line
enable_esti parameter is set to true. profile.
The default is “RecallDialTone”.
etsi_held_party_ri This parameter shall control whether N Y All No, value N/A
ngback or not ringing shall be applied when except is derived
a user goes on hook with an RTP package from
session on hold. This parameter only C, D, download
applies when the enable_esti and E / default
parameter is set to true. The default line
is “no”. profile.
etsi_ch_release_e Specifies the code used to release a N Y All No, value N/A
arliest call and return to a two-way call by except is derived
releasing the first added call. Valid package from
values are in the form Rd, where d is C, D, download
0-9, *, or #. The default is an empty and E / default
string. You can only configure the line
parameter when the enable_etsi profile.
parameter is set to true.
etsi_ch_release_la Specifies the code used to release a N Y All No,

test call and return to a two-way call by except default
releasing the last added call. Valid package value is
values are in the form Rd, where d is C, D, used in
0-9, *, or #. The default is an empty and E TL1.
string. You can only configure the
parameter when the enable_etsi
(19 of 23)


etsi_3wc_release_ Specifies the code used to reduce a Y Y All No, value N/A
earliest three-way call to a two-way call by except is derived
releasing the first added call. Valid package from
etsi_3wc_release_l Specifies the code used to reduce a Y Y All No, value N/A
atest three-way call to a two-way call by except is derived
releasing the last added call. Valid package from
enable_3wc_focus Specifies the behavior of the ONT N Y All No, value N/A
when generating contact name in an except is derived
INVITE of a second call. The options package from
are: C, D, E, download
• true (default) and / default
I-240W line
• false
ONT profile.
When set to true, the ONT appends
3WC to the contact name and adds
the isfocus header. If the three-way
call is reduced to a two-way call, a
re-invite is sent to remove the
isfocus.
When set to false, the ONT does not
append 3WC to the contact name and
does not add an isfocus header to the
invite message.
You can configure the parameter
when the enable_etsi parameter is
set to true
prefer_early_medi Specifies whether to continue to N Y All No, value N/A

a output early media to a user even except is derived
after the ONT receives a 180 ringing package from
response. C, D, download
The options are: and E / default
line
• True/1/Yes to ignore the 180 profile.
ringing response
• (default) False/0/No to suppress
the early media session and play
a local ringback tone
This parameter is available in XML

releases R4.1 and 4.3, but not R4.2.
(20 of 23)


enable_service_in Specifies whether the ONT supports N Y All No, value N/A
_remote_hold supplementary services such as except is derived
three-way calling, call hold display, package from
and call transfer when the call C, D, download
session is remotely held. and E / default
The options are True/1/Yes and line
False/0/No. If this parameter is set profile.
to True, then ONT supports the
supplementary services. The default
is False. This attribute is only
supported in XML R4.4 and later.
service_code_enab Specifies the feature access service N Y All No, value N/A
le_warm code used by subscriber to activate except is derived
warmline. The user agent must package from
support at least two service codes, as C, D, download
is typical in most dialing plans. The and E / default
default is *53*. This reflects that fact line
You can configure the parameter profile.
when the enable_warmline
parameter is set to Subscriber.
service_code_disa Specifies the feature access service N Y All No, value N/A
ble_warm code used by subscriber to except is derived
deactivate warmline. The user agent package from
must support at least two service C, D, download
codes, as is typical in most dialing and E / default
plans. The default is #53#. This line
reflects that fact You can configure profile.
the parameter when the
enable_warmline parameter is set to
Subscriber.
osi_timer Specifies the open switch interval N Y All No, value N/A
duration. The option is a number except is derived
from 0 to X, which represents package from
milliseconds. The default is 900. C, D, download
When set to 0, the ONT starts the and E / default
permanent signal treatment line
immediately after the release timer profile.
expires after a BYE is received for an
incoming/outgoing call.
When set to non-zero, then after
release timer expires, the ONT
removes the loop current for the
specified time and then starts the
permanent signaling treatment.
(21 of 23)


TimeZoneOffset The difference expressed in seconds N Y Package If TL1 is Yes

between UCT (received by the ONT C, D, E, also
via NTP or the P-OLT) and the local F, and G configured
time. If the ONT does not have the and XML
timezone offset value set via DHCP has it
option 100, this value should be configured
added to the UCT whenever the time to a
is to be displayed to the subscriber non-zero
(at the moment the only application value,
of this is caller ID display). then TL1
If this parameter is configured takes
through TL1, and XML has it precedenc
configured to a non-zero value, then e over XML
TL1 takes precedence over XML.
Updating the time zone offset via
XML requires change of the XML file.
It is not recommended for use by
customers. Contact your
Alcatel-Lucent support
representative.
Privacy Specifies whether outgoing INVITE N Y Package No, value N/A

messages contain privacy header C, D, E, derived
information. Null (default) or empty F, and G from XML
indicates no privacy header, none only
indicates Privacy:none in INVITE
requests, and id indicates Privacy:id
in INVITE requests.
Mode Specifies whether the preferred ID is N Y Package No, value N/A

carried in the outgoing INVITE C, D, E, derived
message. The options are true and F, and G from XML
false (default) only
ID Specifies the preferred ID when the N Y Package No, value N/A

Mode parameter is set to true or C, D, E, derived
contains a null string if the preferred F, and G from XML
ID is generated elsewhere. The ID is only
a string of up to 63 characters.
Support100rel Specifies whether 100rel is N Y Package No, value N/A

contained in the support header of a C, D, E, derived
SIP request message to initiate a F, and G from XML
dialog. only
When set to true, 100rel is contained
in the outgoing INVITE message.
When set to false (default) 100rel is
not in the header.
Require100rel Specifies whether 100rel is N Y Package No, value N/A

contained in the require header of a C, D, E, derived
SIP provision response message if the F, and G from XML
other device supports 100rel. only
When set to true, 100rel is contained
in the provision response message.
When set to false (default) 100rel is
ignored.
(22 of 23)


local_country_cod Specifies the display of the calling N Y Support Applicable N/A

e party number. The ONT removes the ed on all for iConfig
local country code from the received package mode. The
phone number only when the s except ONT uses
enable_etsi parameter is configured C, D, country_c
as false and the length of the and E ode
received phone number is greater property
than or equal to 10+ x, where x is the in ftp
length of country code. The default mode
is an empty string. When the default
is an empty string, then the
country_code value is used.
If the length of the remaining
number is more than 10 digits, then
the ONT displays the first 10 digits.
digit_sending_mod The digit sending mode to be Y Y Package Y N/A

e applied. Possible values are: L ONTs
• en-bloc only
• overlap-invite
• overlap-indialog
(23 of 23)
Notes
(1) The default value of the parameter outbound_uri_prefix is “sip” and not “tel”. If necessary, change the configuration of
the value to “tel”.
(2) Does not apply to package C, D, and E ONTs and MDUs
22.8 Digit map
A digit map is used to control how the ONT or MDU processes dialed digits for a
voice service.
Besides simple collection of the digits of a phone number, it allows for ONT or MDU
internal handling of special dialed sequences like 911 and service codes. The ONT
utilizes the configured digit map at call origination, or in some cases after flash-hook.
In SIP mode 1, there is no digit collection by the ONT after flash-hook. In SIP mode
2, digit collection is usually started after a mid-call flash-hook. In all other cases
digits are simply passed in-band in the voice path, either as tones or as RFC 2833
packets. The digit map also allows for these subscriber interaction functions:
• timeout of digit collection
• termination of digit collection
• output of recall dial tone or normal dial tone
When digit collection is started the ONT digit map library (DML) software is
initialized with timers and the configured digit map string. The DML builds a “tree”
with branches for each possible matching path possible in the digit map string from
left to right. As each digit is input:
1 The tree is traversed using the digits entered so far until a matching pattern is
found.

2 If the matching point also satisfies all conditions of the pattern (such as the
number of repetitions allowed), then digit collection is ended.
3 If no matching pattern is found, then digit collection is ended.
Digit map digit collection

Digit collection begins when the device goes off-hook. Digit map processing occurs
until one of the following events occurs:
• The permanent timer expires when no digit has been received.
• The interdigit timer expires after at least one digit has been received.
• no more patterns are matched, and the base of the digit map tree is reached
• a digit is entered for which there is no matching pattern
• the enter key is used, but it is processed as an enter key only if there is not a
pattern match for the defined enter key at that point in the tree
The call attempt is made (INVITE sent) with digits collected at the point the digit
collection ends.
Digit map syntax, collection elements, and samples for package C, D,

E, F, and G
The ONT digit map is a pattern that guides digit collection and allows the user agent
to determine when dialing is complete. Digit maps can be configured using XML or
using OMCIv2 via TL1. When configured using XML, The digit_map SIP parameter
is used to set this pattern.
To apply a new dial plan, configure the dial plan and apply to both POTS ports. After
locking and unlocking the ONT, the new dial plan goes into effect.
White space in the digit map string is not significant. Characters are not case
sensitive. Parenthesis can be used to create patterns with following operators and
modifiers and to group sets of patterns together. An enter key on the phone is used
during digit collection to end the collection and cause the call attempt to be made
(INVITE sent). The enter key detected by the ONT is configurable with the SIP
provisioning enter_key parameter. The default is “#”.
Vertical bar characters are used to create alternate patterns in the digit map. For
example 1 | 2| 3 means 1 or 2 or 3. Care must be taken to make alternative patterns
unambiguous when constructing a digit map.
Table 22-15 lists and describes the elements, symbols, and modifiers used in the
ONT digit map.

Table 22-15 ONT digit map elements, symbols, and modifiers for package C, D, E, F, and G ONTs
Pattern elements, Representation

symbol, or modifier
0-9, *, #, (,), [,], | Dialed digits or characters
x Any numeric string with any length, including 0

x{n} A digit in the range 0-9 followed with digits with a length of n, for example,
123x{5} equals 123xxxxx.
[] A set of digits enclosed in brackets “[ ]” represents the occurrence of any

of the enclosed digits, for example [1-5] indicates only numbers 1 to 5 are
acceptable
. A pattern element followed by a dot signifies zero of more occurrences of

the element.
() A sequence of pattern elements enclosed in parenthesis matches the
concatenation of the elements.
| A sequence of pattern elements separated by | matches the any one of the

elements in the sequence.
T The T modifier represents the application of the critical dial timer (4 s). A
pattern element followed by the T modifier matches if an only if the critical
timer expires at that point. There can be multiple critical timers in the dial
plan table, for example, (123x.T|456x.T|**xxx.T)
Note 1 — Alphabetic symbols in the ONT digit map are not case
sensitive.
Note 2 — The digit_map SIP parameter is a required parameter; it has
no default value. A digit map must be customized for each SIP
implementation based on the features of the SIP server in the network.
Dial plan configured using OMCIv2

A dial plan can consist of several dial plan tokens. Each token is a component of the
overall dial plan. Each dial plan token is limited to 28 bytes in length. The total length
of the dial plan is limited to 448 bytes. The following is an example of a digit map,
and is the default dial plan if no other plan is configured:
(***xx|*xx*x.#|*xx*x.*xx#|*xx*x.*x#|*31*xxxxxxxx|*xx#|#xx#|*#xx#|#00
1|x.T)
This dial plan consists of three dial plan tokens:

1 (***xx|*xx*x.#|*xx*x.*xx#|
2 xx*x.*x#|*31*xxxxxxxx|
3 *xx#|#xx#|*#xx#|#001|x.T)

This example:
• Allows for multiple digits to be entered following * or # for service codes
• Nested parentheses and parenthetical grouping is not allowed. A single pair of
parentheses delimits the complete digit map
• The interdigit timeout with this digit map should be configured to 4 seconds
(normally it is 16 seconds).
The following is a more complex example of a digit map:

(*67x.T|1167x.T|*82x.T|1182x.T|*70|1170|101xxxxx.T|*52|1152|*88x.T|1
188x.T|*90x.T|1190x.T|*[23]xx|11[23]xx|*[014]x|11[014]x|*5[013456789
]|115[013456789]|*6[012345689]|116[012345689]|*7[123456789]|117[1234
56789]|*8[01345679]|118[01345679]|*9[123456789]|119[123456789]|0.T|0
0|01x.T|[01][2-8]11|[01]911E|[01][2-9][023456789]xxxxxxxx|[01][2-9]1
[023456789]xxxxxxx|[2-8]11|911E|[2-9][023456789]xxxxx|[2-9]1[0234567
89]xxxx|[2-9].T|[2-9][023456789].T)
This example:
• The ^ (NOT match) operator is not supported, so ranges must be explicitly
enumerated, for example, [023456789] replaces [^1]
• The x, y (min and max variable repetition) operator is not supported so terms
instead use the open-ended x.T pattern
Dial plan configured using XML

In XML, the dial plan is named as a DigitMap, which is a string of characters with a
length limit of 1024 bytes. A dial plan can consist of several dial plan tokens. Each
token is a component of the overall dial plan. Each dial plan token is limited to 28
bytes in length. The following is an example of a digit map, and is the default dial
plan if no other plan is configured:
<DigitMap>
(***xx|911E|1911E|0911E|101xxxx911E|***xx|*xx*x.#|*xx*x.*xx#|*xx*x.*
x#|*31*xxxxxxxx|*xx#|#xx#|*#xx#|#001|x.T)</DigitMap>
This dial plan consists of three dial plan tokens:

1 (***xx|*xx*x.#|*xx*x.*xx#|
2 xx*x.*x#|*31*xxxxxxxx|
3 *xx#|#xx#|*#xx#|#001|x.T)
This example:
• Allows for multiple digits to be entered following * or # for service codes
• Nested parentheses and parenthetical grouping is not allowed. A single pair of
parentheses delimits the complete digit map
• The interdigit timeout with this digit map should be configured to 4 seconds
Matching rules
Take the default dial plan as an example:

(***xx|*xx*x.#|*xx*x.*xx#|*xx*x.*x#|*31*xxxxxxxx|*xx#|#xx#|*#xx#|#00
1|x.T)
• If one unique item is matched without ambiguous, ONT would sent the dialed
numbers immediately. e.g. dial *43#
• If the matched item contains timer T, ONT would wait for sending until the timer
expired. If a new digit is dialed before the timer expires, ONT will re-check the
dialed number with the new digit to see if the number can be sent out. e.g. dial
123456
• If the dialed numbers do not match any items, ONT would not send the numbers.
e.g. dial ***#
• If the numbers dialed hit more than one item, ONT would chose the best match
one.
e.g. (***xx|123xxx.T|1234)
• After dial 1234, ONT would send out the numbers immediately as the rule 1234
was hit instead of 123xxx.T
Dial timer configuration

You can configure dial timer behavior:
<PermanentTimer>20</PermanentTimer>
<InterDigitTimer>16</InterDigitTimer>
<CriticalTimer>4</CriticalTimer>
• PermanentTimer indicates how long the dial tone would play when the subscriber
went off-hook but didn’t dial any digits
• InterDigitTimer indicates how long the ONT would wait for the subscriber to
continue dialing when a number was dialed but did not fully match any item of
the dial plan
• CriticalTimer indicates how long the ONT waits after some numbers are dialed
that match one item of the dial plan. It is only applicable to the item with postfix T
Digit map syntax, collection elements, and samples for package A, B,

and H
The ONT digit map is a pattern that guides digit collection and allows the user agent
to determine when dialing is complete. The digit_map SIP parameter is used to set
this pattern. One digit map is supported for each POTS port.
White space in the digit map string is not significant. Characters are not case
sensitive. Parenthesis can be used to create patterns with following operators and
modifiers and to group sets of patterns together. An enter key on the phone is used
during digit collection to end the collection and cause the call attempt to be made
(INVITE sent). The enter key detected by the ONT is configurable with the SIP
provisioning enter_key parameter. The default is “#”.
Vertical bar characters are used to create alternate patterns in the digit map. For
example 1 | 2| 3 means 1 or 2 or 3. Care must be taken to make alternative patterns
unambiguous when constructing a digit map.

Digit collection can be influenced by the following SIP configuration parameters

(see section 22.7 for details on these parameters):
• permanent timer
• interdigit timer
• critical timer
• use of the Enter key
There are three types of service codes (also called feature codes) to consider in a digit
map:
• The service code is handled locally at the ONT or MDU, for example *70 in SIP
mode 2. Such service codes are not supported in SIP mode 1. These service codes
are not included in INVITE messages.
• The service code triggers a service at the softswitch, but does not have a set of
digits which must then be collected by the ONT or MDU. In this case, the
INVITE contains just the feature code, and is dependent on the softswitch.
• The service code triggers a service at the softswitch, and does have a set of digits
which must then be collected by the ONT or MDU. In this case, both the service
code and the phone number are included in the INVITE message. For example,
*67 followed by 1234567 would invoke called ID blocking on a call to phone
number 123-4567. In most cases, the digit map would include the I (insertion
character) modifier and #, so the INVITE would contain *67#1234567.
Table 22-16 lists and describes the elements, symbols, and modifiers used in the
ONT digit map.

Table 22-16 ONT digit map elements, symbols, and modifiers for package A, B, and H ONTs
Pattern elements, symbol, or Representation

modifier
0-9, A-D, *, and # Dialed digits
x A digit in the range 0-9

[] A set of digits enclosed in brackets “[]” represents the occurrence
of any of the enclosed digits. If a ^ appears immediately after the
opening bracket, it represents the occurrence of any digit other
than the enclosed digits.
. A pattern element followed by a dot signifies zero of more

occurrences of the element.
? A pattern element followed by a question mark signifies zero or one

occurrence of the element.
In the sequence ((* | 11) (88| 90)) R I#? means the user can enter:
• nothing
• *88
• *90
However, the user cannot enter:

• *88 and *90
+ A pattern element followed by a plus sign signifies one or more

occurrences of the element.
{m} A pattern element followed by {m} signifies exactly m occurrences
of the element.
{m,} A pattern element followed by {m, n} signifies at least m

occurrences.
{m, n} A pattern element followed by {m, n} signifies at least m

occurrences, but not more than n occurrences of the element.
For example, {0,2} means that the pattern proceeding it can be
used 0, 1, or 2 times.
In the sequence ((* | 11) (67 | 82)) SRI# {0,2} means the user can
enter:
• nothing
• *67 and *82
• *82 and *67
• *82
• *67
However, the user cannot enter:

• *67, *82, and *67
() A sequence of pattern elements enclosed in parenthesis matches

the concatenation of the elements.
| A sequence of pattern elements separated by | matches the any

one of the elements in the sequence.
T The T modifier represents the application of the critical timer (4 s).

A pattern element followed by the T modifier matches if an only if
the critical timer expires at that point.
P The P modifier represents the application of dial tone when a

partial match reaches that point.
(1 of 2)

Pattern elements, symbol, or Representation

modifier
I The I modifier represents the insertion of a special digit character

(such as #) into the collected digit string immediately following the
substring that matches the pattern element that is followed by the
I modifier. The inserted character is specified immediately
following the I in the pattern.
E The E modifier specifies the substring that matches the pattern

element before it as an emergency call. The pattern element
generally is a sequence of pattern elements enclosed in
parentheses.
R The R modifier specifies that a recall dial tone should be output
after a particular pattern is performed.
S The S modifier specifies the substring that matches the pattern

element before it as service code that may be of interest to the user
agent. The pattern element generally is a sequence of pattern
elements enclosed in parentheses. This use of this symbol is not
supported in SIP mode 1.
(2 of 2)
Note 1 — Alphabetic symbols in the ONT digit map are not case
sensitive.
Note 2 — The digit_map SIP parameter is a required parameter; it has
no default value. A digit map must be customized for each SIP
implementation based on the features of the SIP server in the network.
The following is an example of a digit map used with SIP mode 1:

*x{20} | #x{20} | 411 | 911 | [01235678]x{20} | [49] ([^1]x{19} |
1[^1]x{19})
This example:
• Allows for up to 20 digits to be entered following * or # for service codes
• 411 or 911 can be entered and digit map collection will stop immediately.
• Allows a dialed number (without a service code) of up to 20 digits, with
exclusions to make sure the different patterns are unique for 411 and 911.
• This example forces the subscriber to use the enter key or wait for timeout to dial
a simple service code or phone number (except for 411 or 911).
• The interdigit timeout with this Digit Map should be configured to 4 seconds
The following is an example of a digit map used with SIP mode 2:

( ( * | 11 ) ( 67 | 82 ) ) SRI# {0,2} ( ( * | 11 ) ( 70 ) ) S I# ? (
101xxxx ) ? ( ( * | 11 ) 52 ) S I# ? ( ( * | 11 ) ( 88 | 90 ) ) R I#
? ( ( ( * | 11 ) ( [23]xx | [014]x | 5[^2] | 6[^7] | 7[^0] | 8[01345679]
| 9[^0] ) ) S I# | ( 0T | 00 | 011?[2-9]x{0,14}T | [01] ( [2-8] 11 |
(911)E | [2-9] ( [^1]x{8} | 1[^1] x{7}) ) | [2-8] 11 | (911)E | [2-9]
( [^1]x{5} | 1[^1] x{4}) | [2-9] [^1]?T ) )

This example:
• The example allows these type 1 service codes: *70/1170 and *52/1152. The
cancel call waiting and call hold service code parameters in the XML download
data must also be configured with these features codes for the features to work
properly.
• Allows these type 3 service codes: *67/1167, *82/1182, *88/1188, and *90/1190.
*67/1167 and *82/1182 can be entered together in any order and can be followed
by *88/1188 or *90/1190. This ordering may be important in some cases.
• All other service codes are type 2.
• S and R modifiers are used with most codes; however, the S modifier is not
required except for the type 1 codes.
• R modifiers are not necessary on the *70/1170 and *52/1152 codes, the ONT will
output correct tones as part of Type 1 processing.
• The E modifier in the example will cause special emergency call behavior in the
ONT if 911, 0911 or 1911 is dialed.
RFC2833 DTMF digit transmission

Inband transmission of DTMF tones only occurs when digit collection is not being
performed. This inband transmission provides a way for a server to independently
collect dialed digits, allowing the ONT to pass them transparently. By comparison,
RFC2833 transmission of DTMF is an alternative method of transmitting DTMF
digits. This is not applicable to package D ONTs.
In VoIP processing, the use of RFC2833 is a negotiated item in the Session
Description Protocol (SDP). The SDP Offer/Answer negotiation is used to determine
if the two endpoints should actually use RFC2833 transmission or not.
When using the RFC2833 transmission method, digits are encoded in
RFC2833-defined packets so the server does not have to decode RTP packets in
order to process DTMF tones. When RFC2833 packets are used for DTMF
transmission, the DTMF tones are not sent in the encoded RTP data.
The 7342 ISAM FTTU provides a provisioning option to enable or disable this
feature so the ONT knows whether or not to initiate offers with RFC2833 or not. See
the SIP provisioning parameter enable_rfc2833 in Table 22-13.
Note — This feature does not change how pulse dialing is handled,
and applies to DTMF only.
INFO-based DTMF digit transmission

As an alternative to RFC2833 DTMF transmission, the ONT supports sending and
receiving DTMF digits in SIP INFO messages. The digit is represented in the body
of the INFO messages following a content type header of
application/telephone-event as follows:
Content-Type: audio/telephone-event
Content Length: 4

xxyyyyyy
Where xxyyyyyy is a 32-bit value. xx is the top-most 8 bits, and yyyyyy is the next 24
bits. xx represents one of the 16 possible DTMF event values specified in RFC2833
(0 through 15). yyyyyy is not used, it will be ignored in INFO messages received, and
set to 0 for INFO messages generated by the ONT.
As with RFC2833 DTMF transmission, a digit sent with this method will not be sent
in the encoded RTP voice data. INFO based DTMF transmission is enabled with the
enable_info_based_dtmf parameter from Table 22-13.
Note — This feature does not change how pulse dialing is handled,
and applies to DTMF only.
22.9 Security
For network and ONT security, some ONTs support the following mechanisms:
• DHCP option 90: supported in any VoIP mode of operation that uses DHCP
• HTTP Digest/MD5 authentication: supported in SIP modes in response to an
authorization challenge from the softswitch
• configuration of an FTP server username and password, when downloading
configuration profile files
• configuration of SIPPing server authentication using a modifiable user name and
password.
These security measures are not supported on package C and D ONTs.

There is no security mechanism when downloading from the OLT to an ONT via
OMCI. The existing mechanism of FTP server username and password will be
applicable in CONFMETH=OMCI when the OLT has to FTP a file, but if the file
exists in the OLT, there are no checks.
DHCP Option 90
DHCP Option 90 provides a signature in a DHCP message for the authentication and
integrity of the message. DHCP Option 90 does not provide privacy. The signature
allows a DHCP client or server to know a responding client or server is valid or a
spoof. It also prevents replay and eavesdropping attacks that can cause a denial of
service.
VoIP clients are programmed with a username secret ID and a shared secret K (Key).
To sign a DHCP message, the invariant parts of the message are used to compute a
hash value with the secret K based on RFC 2104. If the receiver of the message has
the same secret K, the receiver can re-calculate the hash value and determine whether
the sender knows the shared secret K. If the hash value calculated by receiver does
not match the hash value in the Option 90 HMAC-MD5 field, the sender does not
know the correct secret K value or the message was altered during the transmission.
Using the RDM, a receiver can determine whether this message has already been
received and is a replay attack.

HTTP digest
HTTP digest provides a method for client authentication and message integrity to the
server, and optional authentication of server and server messages. HTTP digest does
not provide privacy. HTTP digest may be used within Transport Layer Security
(TLS) to perform client authentication. Server authentication is mandatory in TLS.
Each VoIP client is provisioned with at least one set that includes a realm identifier,
username, and password (shared secret). The information is also stored on the
network servers.
22.10 VoIP call and performance monitoring statistics
VoIP call and performance monitoring statistics are gathered for the last incoming or
outgoing call on each POTS port configured for VoIP on some ONTs. Up to 32
previous call statistics are supported individually. VoIP call statistics are not
supported on package C and D ONTs.
An RTCP failure alarm is raised at the P-OLT if RTCP packets are not received
during a VoIP call.
Statistics collection using OMCIv1

Statistics collection using OMCIv1 is not available for Package C, D, E, I, or K
ONTs, with the exception of I-240G-U, I-240G-R and O-240G-P, which support
limited call history statistics. The I-240G-U, I-240G-R and O-240G-P ONTs support
only the Date, Time, Duration, Called Number and Calling Number statistics
VoIP call statistics for the last incoming or outgoing call are retained at the ONT.
You can view the statistics from a management session with the P-OLT using TL1
or the EMS interface.
Collection of call statistics occurs when a bearer channel is established. If multiple
bearer channels are established during the course of a single call, such as if call
waiting occurs, then only the data from the last disconnected bearer channel is
retained in the ONT.
Note — Call record log statistics are created only when a dialog
progresses to an RTP session. Inbound no-answer calls are not logged
because an RTP session is not configured while outbound calls are
being logged.
Table 22-17 lists the VoIP call statistics that are collected.
Table 22-17 Collected VoIP call statistics using OMCIv1
Type Description Statistic Format/unit
Date (1) The date when the call was initiated. This is determined at DATE YY-MM-DD
the start of ringing when terminating a call (incoming), or Example: 06-01-16
when going off-hook for the originating call (outgoing).
(1 of 2)

Type Description Statistic Format/unit

Time (1) The time when the call was initiated. This is determined at TIME HH-MM-SS
the start of ringing when terminating a call (incoming), or Example: 13-30-02
when going off-hook for the originating call (outgoing).
Duration The duration of the call is recorded as an integer in seconds. DURATION seconds
For a call origination, the duration starts at the initial
off-hook and stops when the call ends with on-hook. For call
termination, the duration starts when ringing is applied to
the line, continues when the line goes off-hook, and stops
when the call ends with on-hook.
Called number (2) For outgoing calls, the called number is the digits dialed by CALLEDNO a string of up to 25
the subscriber. alphanumeric
For incoming calls, the called number is the identity of the characters
subscriber line terminated at the ONT that is receiving the
call.
Calling For outgoing calls, the calling number is the identity of the CALLINGNO a string of up to 25
number (2) subscriber line terminated at the ONT that is initiating the alphanumeric
call. characters
For incoming calls, the calling number is the phone number
or identity of the external party that is calling a subscriber
line terminated at the ONT.
RTP packets The total number of RTP packets transmitted during of the TXPKTS integer
transmitted call.
RTP packets The total number of RTP packets received during the call. RXPKTS integer
received
RTP packets lost The total number of RTP packets lost during the call. PKTSLOST integer
RTP packets The total number of RTP packets discarded due to errors. PKTSDISC integer
discarded
Jitter buffer The total number of jitter buffer overruns. OVERRUNS integer
overruns
Jitter buffer The total number of jitter buffer underruns. UNDERRUNS integer
underruns
Average jitter The average jitter for received packets is recorded as an AVGJTR milliseconds
integer in milliseconds.
RTCP The far end RTCP participation with valid values of RTCP —
participation participated or not participated.
Peak jitter The peak jitter. PJTR milliseconds
Average jitter The average jitter buffer depth. AVGJTRBD milliseconds

buffer depth
RTCP-XR The far end RTCP-XR participation with valid values of RTCPXR —
participation participated or not participated.
RTCP-XR peak The peak round-trip delay for a call. (Only available if PRTDEL integer
round-trip delay far-end participated in RTCP-XR.)
RTCP-XR average The average round-trip delay for the call. (Only available if AVGRTDEL integer
round-trip delay far-end participated in RTCP-XR.)
RTCP-XR average The average mean opinion score (MOS) with valid values of 0 AVGMOS (3) integer
mean opinion to 500 in hundredths. (Only available if far-end participated
score in RTCP-XR.)
(2 of 2)
Notes
(1) The time and date data is from the local GMT time kept at the ONT.
(2) Not supported for voice gateway and H.248 softswitch modes.

(3) When interoperating in voice gateway mode with G6, the AVGMOS statistic is not supported. When using the TL1 command
REPT-OPSTAT-ONTCALLHIST, command output reports 43.
Statistics collection for package A, B, and H using OMCIv2

Call record log statistics are created only when a dialog progresses to an RTP session.
Inbound no-answer calls are not logged because an RTP session is not configured
while outbound calls are being logged.
Note — Only current performance monitoring counters are

supported. Historical 15 min counters are not supported.
Table 22-18 lists the ONT call-related performance monitoring statistics that are
collected.
Table 22-18 Package A, B, and H call-related performance monitoring statistics
Montype Description Location Format/unit

ONT POTS call
SETUPFAILS Count of call setup failures. NE Integer
SETUPTIMER High water mark that records the longest duration of a NE Time, in
single call setup detected during this interval milliseconds
TERMFAILS Count of call termination failures NE Integer
RELEASES Count of analog port releases without dialing detected NE Integer

(abandoned calls)
OFFHOOKTIMER High water mark for longest time a single off hook was NE Time, in
detected for the analog port during this interval. milliseconds
ONT POTS RTP
RTPERRORS Count of RTP packet errors NE Integer
PACKETLOSS Fraction of counters lost during interval. Not applicable NE 0 for no packet loss
for current interval. OxFFFF for 100%
packet loss
MAXJITTER High water mark for maximum jitter during this interval. NE RTP timestamp units
MAXRTCPINT High water mark for maximum time between RTCP NE Time, in
packets this interval. milliseconds
BUFUNDERFLOW Count of times the reassembly buffer underflows. NE Integer
BUFOVERFLOW Count of times the reassembly buffer overflows. NE Integer
ONT SIP
TRANSACTIONS Count of new transactions initiated. NE Integer
RXINVITEREQ Count of received invite messages including NE Integer

retransmission.
RXINVITERETRANS Count of received invite retransmission messages. NE Integer
RXNONINVITSREQ Count of received non-invite messages including NE Integer

retransmission.
(1 of 3)

RXNONINVITERETRANS Count of received non-invite retransmission messages. NE Integer
RXRESPONSES Count of total responses received. NE Integer
RXNONINVITERETRANS Count of total response retransmission messages NE Integer

received.
TXINVITESREQ Count of transmitted invite messages including NE Integer

retransmission.
TXINVITERETRANS Count of transmitted invite retransmission messages. NE Integer
TXNONINVITSREQ Count of transmitted non-invite messages including NE Integer

retransmission.
TXNONINVITERETRANS Count of transmitted non-invite retransmission messages. NE Integer
TXRESPONSES Count of total responses transmitted. NE Integer
TXNONINVITERETRANS Count of total response retransmission messages NE Integer

transmitted.
ONT SIP call
CONNECTFAILS Count of times SIP user agent failed to reach/connect to NE Integer

peer during SIP call initiation.
VALIDATEFAILS Count of times SIP user agent failed to validate its peer NE Integer
during SIP call initiation.
TIMEOUTS Count of number of times SIP user agent timed out during NE Integer
SIP call initiation.
RXFAILS Count of number of times SIP user agent received a NE Integer
failure error code during SIP call initiation.
AUTHFAILS Count of number of times SIP user agent failed to NE Integer

authenticate itself during SIP call initiation.
ONT MGC (Megaco)

RXMSGS Count of received Megaco messages on the association as NE Integer
defined by ITU-T H.341.
RXOCTETS Count of received octets on the association as defined by NE Integer

ITU-T H.341.
TXMSGS Count of transmitted Megaco messages on the association NE Integer

as defined by ITU-T H.341.
TXOCTETS Count of transmitted octets on the association as defined NE Integer
by ITU-T H.341.
PROTOCOLERR Count of total errors detected on the association as NE Integer

defined by ITU-T H.341, including:
• syntax errors in a given received message
• outgoing transactions that failed due to a protocol
problem
TXLOSSES Count of total number of transport losses detected on the NE Integer

association. These losses would be due to a loss of
communication with the remote entity caused by
hardware or software problems.
(2 of 3)

LASTEVENT Last detected event on the association, including: NE Enumeration as

• NOEVENT to indicate event has not been detected shown under
description
• LINKUP to indicate the transport link came up
• LINKDOWN to indicate the transport link went down
• PERSISTERR to indicate a persistent error was
detected on the transport link, such as socket
connection to remote node could not be set up
• LOCALSHUTDN to indicate the transport link was
brought down intentionally by the local application
• FAILOVER to indicate the transport link was brought
down because of a failover
• OTHER for all other reasons
LASTEVENTTIME Time since the last event on the association was NE Time, in seconds
detected, as defined by ITU-T H.341
LASTRESTARTTIME Time since the statistics on the association was reset, as NE Time, in seconds
defined by ITU-T H.341
ONT IP host
ICMPERR Count of ICMP errors received. NE Integer
DNSERR Count of DNS errors received. NE Integer
DHCPTIMEOUT Count of DHCP timeouts received. NE Integer
ADDRCONFLCT Count of whenever an ONT detects a conflicting IP NE Integer

address on the network. A conflicting IP address is
defined as an IP address that is the same as the one
currently assigned to the ONT
OUTOFMEM Count of out of memory conditions in the IP stack. NE Integer
INTERVALERR Count of internal error conditions. NE Integer
(3 of 3)
RTCP failure alarm

When a bearer channel is established on a VoIP POTS port on the ONT, the system
monitors RTCP activity. The alarm management software raises an RTCP failure
alarm when no RTCP packets are detected on the established bearer channel within
a configured duration of time. By default, the system waits 3 min before raising an
RTCP failure alarm.
The RTCP alarm is associated with a specific POTS port on the ONT. You can view
system-generated alarms at the P-OLT using TL1 or the EMS interface. An active
RTCP failure alarm is cleared at the P-OLT when either the VoIP call is terminated
or RTCP packets are detected on the bearer channel.


23 — HSI service
23.1 Overview 23-2
23.2 Network example 23-2
23.3 HSI service configuration elements 23-3
23.4 QoS characteristics 23-7
23.5 HSI service configuration example 23-10

23 — HSI service
23.1 Overview
This chapter provides high level information about the implementation of the
HSI service in the 7342 ISAM FTTU. Although the HSI service can carry different
types of traffic, such as IPTV traffic, this chapter focuses on the delivery of IP data
services to subscribers.
TL1 and CLI for HSI related procedures.
23.2 Network example
The HSI service enables the delivery of IP data services to business and residential
subscribers. Figure 23-1 provides an overview of the delivery of IP data services to
a subscriber across the triple play service delivery architecture (TPSDA).
Figure 23-1 Delivery of data services across the TPSDA
Services and Edge Routing Aggregation Access network Home/Business/MTU

servers
VPLS/
HSI HVPLS
Internet
ONT
Internet 7450 ESS 7342 ISAM
7750 SR FTTU
19464
Following is a description of the flow of IP data traffic across the 7342 ISAM FTTU
access network. For a description of the flow of traffic between the internet and the
7342 ISAM FTTU, see Section 25.2, “Service delivery architecture”.
Downstream flow across the 7342 ISAM FTTU access network

IP data traffic flows from the 7450 ESS to the subscriber as follows.
1 At the 7450 ESS, when the switch determines that the packet is destined for a
subscriber port, the packet is mapped to the appropriate VLAN for a particular
subscriber.
2 The 7450 ESS forwards the packet on the access GE port with the appropriate
p-bit.
3 The 7342 ISAM FTTU access node receives the packets as single- or
double-tagged frames, and manipulates the tag based on the tagging mode of the
VLAN.
4 The frames are directed to a GEM port based on the value of their p-bit and
VLAN ID, and carried downstream over the GPON as untagged, priority-tagged,
or tagged frames.

23 — HSI service
5 The ONT receives the frames on the GEM ports. If the ONT UNI port associated
with a GEM port is configured as an untagged port, the ONT strips the frames of
their tag header. For tagged ONT UNI ports, the ONT leaves the frames intact.
6 The switch at the ONT forwards the frames to the ONT UNI port as untagged or
tagged frames.
Upstream flow across the 7342 ISAM FTTU access network

IP data traffic flows from the subscriber to the 7450 ESS as follows.
1 In the upstream direction, the IP data traffic enters the 7342 ISAM FTTU access
network through an Ethernet, VDSL2, or MoCA port on the ONT as untagged,
priority-tagged, or tagged frames
2 On a packet basis, the ONT tags and marks the received frames with their p-bit
and C-VLAN ID based on the upstream tagging mode of the port.
3 The ONT directs the frame to one of eight GEM ports according to its priority
queue.
4 The frame is carried across the GPON on the GEM port contained within a
T-CONT to the LT as either a priority-tagged or tagged frame. The DBA at the
LT card grants upstream bandwidth to the frame on a T-CONT basis.
5 The LT receives priority-tagged and tagged frames on the GEM port. The LT
priority marks the frame with the p-bit received from the ONT, and tags the
frame with its S-VLAN ID in one of two ways.
• In VLAN stacked mode, the LT adds an outer S-VLAN tag, and sends the frame
upstream to the network as a double-tagged frame.
• In VLAN unstacked mode, the LT overwrites the C-VLAN ID with the
S-VLAN ID, and sends the frame upstream to the network as a single-tagged frame.
6 The switches direct the frame from the LT to the NT, and from the NT to the
SHub. The S-VLAN ID determines the outgoing ports along the way, and the
p-bit determines the queues.
7 The 7450 ESS receives the packet on the subscriber VLAN.
23.3 HSI service configuration elements
The following configuration elements are required to configure an HSI service:

• S-VLAN
• ONT
• Port-related elements
• ONT UNI port including Ethernet, VDSL2, or MoCA port
• QoS marker and session profile
• HSI service
• HSI service
• bandwidth profile
• priority queue profile

23 — HSI service
Figure 23-2 shows the configuration elements in a networking topology where two
HSI services are configured a single ONT UNI port.
Figure 23-2 HSI service configuration elements in a networking topology
A priority queue profile governs queuing and scheduling

of different traffic flows by service.
ONT
Scheduler ANI ONT-IWF

(GPON) ONT UNI port
(A) Pri=0 GEM port ID=i
Pri=1 GEM port ID=j
SP+ HSI service (1)
WRR Pri=2 GEM port ID=k
T-CONT
(A) Pri=3 GEM port ID=l
LT Ethernet/VDSL/MoCA port
Pri=4 GEM port ID=m
Pri=5 GEM port ID=n
SP+ HSI service (2)
WRR Pri=6 GEM port ID=o
T-CONT
(B) Pri=7 GEM port ID=p
Scheduler Queues
(B) Downstream
Upstream
A DSCP to p-bit mapping is used to

priority-mark untagged frames from a
trusted customer.
A QoS marker and session profile
directs marking and tagging of traffic
flows on a port.
19460
HSI elements
Table 23-1 shows where to locate a detailed description of each configuration
element.
Table 23-1 HSI service configuration elements
HSI element See

S-VLAN Chapter 21
ONT 7342 ISAM FTTU ONT Product Information Manual
ONT UNI port 7342 ISAM FTTU ONT Product Information Manual
DSCP to p-bit mapping Section 18.3
QoS marker and session profiles Section 18.3
HSI service 7342 ISAM FTTU Operations and Maintenance

Procedures Guide using TL1 and CLI
Bandwidth profile Section 18.6
Priority queue profile Section 18.5
Per-service anti-spoofing (ONT only) Section 20.11

23 — HSI service
Relationship among the HSI elements

The relationships among the HSI elements are shown and labelled in Figure 23-3 and
are described in Table 23-2.
Figure 23-3 Relationships among HSI elements
GEM
port
I H
J
A B F G
ONT ONT UNI HSI Priority queue T-CONT
port service profile
C D
E
DSCP to p-bit QoS session
mapping profile Bandwidth
profile
QoS marker
Port provisioning profile HSI service provisioning data
data
One-to-one mapping
One-to-many or many-to-one mapping
19461

23 — HSI service
Table 23-2 Relationships among HSI elements
Key Relationship description
A Based on the model of ONT, an ONT can support multiple Ethernet/VDSL2/MoCA

ports. Each port supports a single subscriber.
B An ONT UNI port can carry one or more HSI services to the subscriber. Typically this
configuration occurs when more than one service provider is supplying services to
the subscriber.
C A DSCP to p-bit mapping is used to priority mark untagged frames from a trusted
customer. If a DSCP to p-bit mapping is not configured for the port, the ONT uses
the system-wide DSCP to p-bit mapping.
D The QoS marker profile specifies the tagging mode of a port in the upstream and
downstream directions. All services provisioned on the ONT UNI port inherit the
same tagging mode. Because each port can have its own QoS marker profile,
multiple tagging modes can be supported simultaneously across different ONT UNI
ports.
E An upstream and a downstream bandwidth profile specify the bandwidth

requirements of a service. Services can share the same bandwidth profiles.
F Each HSI service is configured with one priority queue profile that directs the
queuing and scheduling of its traffic by p-bit. HSI services can share the same
priority queue profile on the same port or across ports.
G The 7342 ISAM FTTU assigns a single T-CONT to a priority queue profile to carry
service traffic across the GPON.
H For each priority queue that is specified in a priority queue profile, a GEM port is
assigned. Traffic is directed to a GEM port based on p-bit as follows:
• the p-bit to queue mapping in the priority queue profile maps the p-bit in the
frame to a queue in the profile
• the queue determines the GEM port
There are a minimum 16 and a maximum 128 GEM ports available per ONT which is
dependant on the ONU hardware platform. This in turn limits the number of priority
queues per ONT to one GEM port per queue. A queue can have multiple pbits
assigned to it in the PQ Profile where all eight pbits can be mapped to only one
queue, in which case all eight pbits equals one queue, which equals one GEM port.
When multiple priority queues are used per service, this limits the number of
services available per ONT UNI.
See 7342 ISAM FTTU ONT Product Information Manual for more information about
the number of GEM ports available per types of ONTs.
I Because a port can have up to eight priority queues, an Ethernet/VDSL2/MoCA port

can have one to eight GEM ports. Where more than one service is configured for a
port, each priority queue profile must use fewer than eight priority queues.
There are a minimum 16 and a maximum 128 GEM ports available per ONT which is
dependant on the ONU hardware platform. This in turn limits the number of priority
queues per ONT to one GEM port per queue. A queue can have multiple pbits
assigned to it in the PQ Profile where all eight pbits can be mapped to only one
When multiple priority queues are used per service, this limits the number of
services available per ONT UNI.
See 7342 ISAM FTTU ONT Product Information Manual for more information about
the number of GEM ports available per types of ONTs.
J Traffic is carried across the GPON in GEM ports that are contained in the T-CONT.
A T-CONT is limited to a maximum of eight GEM ports.

23 — HSI service
Note — See the 7342 ISAM FTTU Operations and Maintenance

Procedures Guide using TL1 and CLI for configuration details of
each element.
23.4 QoS characteristics
This section describes QoS characteristics that are specific to HSI. For a detailed
overview of QoS, see chapter 18.
Data traffic
An HSI service carries the following types of data traffic:
• IP enscapsulated data traffic
• IP enscapsulated data traffic in PPPoE
The ONT transparently passes data traffic between an ONT UNI port and a GEM
port in both the upstream and downstream directions.
Upstream direction
In the upstream direction, the following path shows how traffic from an ONT UNI
port is directed to a GEM port:
ONT UNI port → HSI service → p-bit in the frame → p-bit to queue mapping
→ priority queue → GEM port
A flow of traffic from an HSI service on an ONT UNI port is directed upstream to
one of eight GEM ports. The GEM port is selected based on the priority queue to
which the p-bit encoded in the tag header of the frame is mapped.
Downstream traffic
Downstream traffic is switched directly to the ONT UNI port that is associated with
the GEM port.
P-bit
Unlike video and voice data, HSI data is tolerant of jitter, delays, and packet loss, and
does not require preferential treatment over other traffic types. Because the p-bit
differentiates traffic into CoS, the lower p-bit values of 0 through 2 are normally
reserved for data traffic. These p-bits correspond to the following CoS:
• best effort
• advanced forwarding
Note — P-bit 7 is reserved for management traffic, such as OMCI.

For more information on the assignment of p-bits to traffic classes,
see Table 18-14, “Recommended CoS mapping”.

23 — HSI service
Traffic queuing and scheduling

Because priority queue profiles are associated on a per service basis, multiple
priority queue profiles can be supported simultaneously across an ONT UNI port in
the upstream direction.
Figure 23-4 shows how a single priority queue profile can support all traffic across
an ONT UNI port. This configuration normally occurs when a single provider
supplies all services to a subscriber across the ONT UNI port.
Figure 23-4 Upstream traffic queuing for single priority queue profile
Traffic tagging and prioritization in both the

upstream and downstream directions
ONT
ANI ONT-IWF
(GPON) ONT UNI port
Pri=0 GEM port ID=i
Pri=1 GEM port ID=j
Pri=2 GEM port ID=k
Pri=3 GEM port ID=l
LT SP+ Ethernet/VDSL/MoCA port
T-CONT WRR Pri=4 GEM port ID=m
(A) Pri=5 GEM port ID=n
Pri=6 GEM port ID=o
Pri=7 GEM port ID=p
Scheduler Queues
(A) Downstream
Upstream
19458
Figure 23-5 shows how multiple priority queue profiles can support traffic across an
ONT UNI port. This configuration occurs when more than one provider supplies
services to a subscriber across the ONT UNI port.
There are a minimum 16 and a maximum 128 GEM ports available per ONT which
is dependant on the ONU hardware platform. This in turn limits the number of
priority queues per ONT to one GEM port per queue. A queue can have multiple
pbits assigned to it in the PQ Profile where all eight pbits can be mapped to only one
when multiple priority queues are used per service, this limits the number of services
available per ONT UNI. See 7342 ISAM FTTU ONT Product Information Manual
for more information about the number of GEM ports available per types of ONTs.

23 — HSI service
Figure 23-5 Upstream traffic queuing with two priority queue profiles
Traffic tagging and prioritization in both the

upstream and downstream directions
ONT
Scheduler ANI ONT-IWF

(GPON) ONT UNI port
(A) Pri=0 GEM port ID=i
Pri=1 GEM port ID=j
SP+ HSI service (1)
WRR Pri=2 GEM port ID=k
T-CONT
(A) Pri=3 GEM port ID=l
LT Ethernet/VDSL/MoCA port
Pri=4 GEM port ID=m
Pri=5 GEM port ID=n
SP+ HSI service (2)
WRR Pri=6 GEM port ID=o
T-CONT
(B) Pri=7 GEM port ID=p
Scheduler Queues
(B) Downstream
Upstream
19459
Tagging
Each VLAN at the NT is configurable for tagging, and each ONT UNI port on the
ONT is configurable for upstream and downstream tagging.
• The P-OLT follows the tagging mode of the VLAN.
• The ONT follows the tagging mode of the ONT UNI port, as specified in the QoS
marker profile.
The operator is responsible for ensuring that the VLAN and ONT UNI port tagging
options are compatible.
Table 23-3 lists the tagging modes and where a detailed description of each tagging
mode can be found. The ONT applies the same tagging mode to all services across
an ONT UNI port in both the downstream and upstream directions.
Table 23-3 Tagging modes
Tagging mode Options See
VLAN tagging modes Stacked VLANs Section 21.5
Unstacked VLANs
Unstacked VLANs in VLAN pass-through

mode
ONT UNI port downstream Transmit tagged traffic Section 21.5

tagging modes
Transmit untagged traffic
(1 of 2)

23 — HSI service
Tagging mode Options See
ONT UNI port upstream Untrusted mode Section 21.5

tagging modes
VLAN pass through mode
VLAN translation mode

VLAN/Ethertype translation mode
Ethertype classification mode
(2 of 2)
23.5 HSI service configuration example
See the training section of the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI for a configuration example.

24.1 Overview 24-2

24.1 Overview
The 7342 ISAM FTTU can provide RF video service through the video overlay
function.
The function operates downstream in the 1550 nm optical band. Signals sent over the
overlay network are presented to the subscriber as RF signals from a video F-type
connector in the ONT.
Note — For information on IP multicasting and IGMP, see
chapter 14.
The RF video service in the downstream 1550 nm optical band supports most
available cable television (CATV) services, including standard analog broadcast
channels, as well as standard and high definition digital broadcast channels. On
MoCA-supporting ONTs operating in the downstream 1490 nm optical band.
additional services can be delivered, including video-on-demand (VOD) and
data-based services, such as interactive video (games). In the upstream direction, the
1310 nm return channel is carried over an HSI service. For access to these services,
a set-top box may be required between the video output of the ONT equipment and
the customer’s television set.
The MoCA data channel transmits in the 800 MHz to 1500 MHz frequency range,
while the RF video channel transmits in the 54 MHz to 850 MHz or 47 to 862 MHz
frequency range, depending on ONT. The video channel is 6 MHz wide.
Within the ONT functional blocks, the RF subsystem is an RF amplifier that
produces the required RF output for the subscriber video equipment. The RF
subsystem monitors the levels of optical and RF signals in support of the
performance management functions. The RF video service is optional and
independent of the SoC functions.
The 7342 ISAM FTTU supports an RF video service timer associated with each
video port. If communication between the OLT and the ONT is lost (not ranged), the
timer starts and video service continues to operate until the timer expires. If
communication between the OLT and the ONT is re-established before the timer
expires, the RF video service continues to operate and the timer is stopped. If the
timer expires, the RF video port is disabled until the ONT successfully re-ranges with
the OLT.
The timer will disable the RF video port when the ONT is operating on battery or
local AC power, unless the power override is set to use the settings specified by the
power shed profile. In this case, the video service will be disabled if any of the timers
(service or video timer) specified for the power shed profile expires first.
The timer value can be configured on the 7342 ISAM FTTU using TL1 or AMS.
Note 1 — For ONT RF video interface specifications, see the
7342 ISAM FTTU ONT Product Information Manual.
Note 2 — For RF video service and timer configuration procedures,
see the 7342 ISAM FTTU Operations and Maintenance Procedures

Breakdown of the RF 1550 nm and 1490 nm overlay

Figure 24-1 shows the RF 1550 nm and 1490 nm frequency spectrum overlay.
Figure 24-1 1550 nm and 1490 nm RF overlay on the 7342 ISAM FTTU
<optional>
Switched Digital Broadcast
200/n1000 100/n1000
channels channels
Analog Digital
Broadcast (HD) 1550 nm
Broadcast
(SD)
50 MHz 350 MHz 860 MHz
New services
SD VoD
HD VoD
Non-Video 1490 nm
19443
When MoCA is used as the Ethernet over coaxial technology, how the spectrum is
used becomes an issue. For example, both RF and MoCA could use the 800 MHz to
860 MHz frequency range, but typically MoCA channels start above 860 MHz.
Table 24-1 shows the breakdown of the data channels.
Table 24-1 RF and MoCA channel breakdown
Feature RF MoCA
Data channel width 6 MHz 25 MHz

Downstream frequency range 54 to 860 MHz 800 to 1500 MHz
Data throughput n/a above 100 Mb/s
Figure 24-2 shows the network topology.

Figure 24-2 RF video service in 7342 ISAM FTTU
Video head end Core transport Central office Fiber (PON) ONT Home network
Distribution
Broadcast
video
Analog
channels
Digital
channels
1550 nm A
(downstream RF video)
Video RF mux Video optical

transmitter EDFA Coax
1310 nm
(upstream)
Private B
network
Power Major Alarm
Processor Minor Alarm
Coax
WDM
IP 7342 OLT
VoD VoD Network C
server Ethernet
Ethernet Coax
1490 nm
(downstream data)
Router
A Analog broadcast No STB needed
B Digital broadcast STB needed
C Broadcast and VoD STB needed
19442

25 — Triple play service delivery
architecture in access network
25.1 Overview 25-2
25.2 Service delivery architecture 25-3
25.3 7342 ISAM FTTU functionality 25-10
25.4 Equipment 25-11
25.5 System management 25-13
25.6 QoS 25-17
25.7 Filter policies 25-18
25.8 VLANs 25-20
25.9 Layer 3 routing 25-22
25.10 Layer 2 forwarding 25-23
25.11 IGMP and IP multicast 25-25
25.12 Subscriber connections 25-28
25.13 ONT services 25-30
25.14 Configuration examples 25-32

25.1 Overview
This chapter provides:

• an overview of the 7342 ISAM FTTU
• an overview about how to configure the 7342 ISAM FTTU to support the
delivery of services to subscribers
• a road map to the guides that contain the concepts, configuration guidelines, and
procedures of a specific functional area or topic
Configuration tools
A CLI interface is generally used to configure the SHub module on the NT card (see
Figure 25-6); a TL1 interface is used for all other configuration.
Terminology
The following terms and definitions apply in this chapter.
Cross-connect mode
Cross-connect (CC) is a VLAN mode where there is a one-to-one mapping between
the VLAN from the network side and the subscriber side. A CC VLAN can only be
associated with one subscriber port on the ONT side of GPON.
Packet forwarding is based on VLAN. MAC learning is usually disabled.

C-VLAN learning mode is a VLAN mode where packet forwarding is based on
C-VLAN on the LT. C-VLAN learning is only supported on the LT, and is
configured either in RB or CC mode on the NT; see Cross-connect mode
and Residential-bridge mode respectively in this chapter.
Flow
A flow is the equivalent of a service on the ONT UNI; each flow is bound to one
portal and one S-VLAN. When bundling is used for an S-VLAN, multiple flows can
be bundled in a single portal.
Flow mirroring mode

Flow mirroring is a VLAN mode where a VLAN carries a duplicate copy of the
packets from one or more subscriber bridge ports to a network port with a packet
sniffer device that is used to view the packets for debugging or law enforcement
purposes.

Portal
A portal represents a T-CONT on a PON. Multiple S-VLANs can be aggregated in
a single portal, or an S-VLAN can have a dedicated portal. The portal aggregates the
traffic from one or more flows on the same ONT, and can specify bandwidth
requirements on an aggregate basis.
Reserved mode
Reserved mode is a VLAN mode for VLANs created for internal or external
communications. Reserved VLANs include:
• VLAN for trace and debug
• VLAN for Broadcom stacking
• VLAN for SHub to LT or NT communication (4094)
• VLAN for network management
Residential-bridge mode
Residential-bridge (RB) is a VLAN mode where multiple subscribers can be
associated with a single S-VLAN, or multiple services can be associated with a
single S-VLAN. For example, subscribers with the same network service provider
can share the same S-VLAN, or all data services can use the same S-VLAN.
In RB mode, packet forwarding is differentiated between subscriber edge and
network sides. Packet forwarding to the subscriber edge is based on destination
MAC address.
25.2 Service delivery architecture
The 7342 ISAM FTTU supports the delivery of data using high-speed Internet
(HSI), voice, and video services to residential and business subscribers over a single
broadband network. Each service is a discrete product, as shown in Figure 25-1. The
video component includes linear programming (broadcast television), and optionally
a non-linear Video on Demand (VoD) component.
Figure 25-1 7342 ISAM FTTU service delivery
Data
(high-speed Internet)
Voice Video
Residential gateway
19383

The delivery of services on the 7342 ISAM FTTU is based on three major
components, as shown in Figure 25-2:
• IP/MPLS network
• IP edge aggregation and routing
• 7342 ISAM FTTU access network
This section describes these three components.
Figure 25-2 7342 ISAM FTTU service delivery architecture
IP network IP edge aggregation 7342 ISAM FTTU

and routing access network
BSR - broadband service router

BSA - broadband service aggregator 5520 AMS
5620 SAM 5750 SSC
7342
BSA ISAM
FTTU
NGN VLAN (8) access
7450 ESS
7342
ISAM
Secure VPLS BSA FTTU
Video infrastructure access
BSR
DHCP
server 7450 ESS
IP/MPLS 7342
ISAM
7750 SR BSA FTTU
access
7450 ESS
Internet
19392
IP/MPLS network
The IP/MPLS network is the core network and includes core routers that are
interconnected using access links, such as fiber. A router consists of line cards,
switching fabric, and a control processor card, as shown in Figure 25-3.

Figure 25-3 Architectural elements of a router
Router
Forwarding
Interfaces
line card
Forwarding Control plane

line card Control processor card
Forwarding
Switching fabric
line card
19418
Relationship between elements

The switching fabric performs packet switching between line cards.
• Incoming packets from external interfaces are received and forwarded to the
switching fabric by the line cards.
• The switching fabric switches the packets to other line cards for forwarding to
outgoing interfaces.
The control plane, which resides on the control processor card, calculates forwarding
paths between routers and exchanges routing information.
IP edge aggregation and routing

The IP edge aggregation and routing component is based on two major network
elements, which are optimized for their respective roles:
• the BSA, an aggregation device that performs the subscriber-specific functions
• the BSR, a multi-edge service router that provides the routing intelligence
The 7450 Ethernet Service Switch (ESS) provides the BSA functionality; the
7750 Service Router (SR) provide the BSR functionality.

Ethernet access ports on the BSA connect the BSA and the 7342 ISAM FTTU access
network.
The 5750 Subscriber Services Controller (SSC) and 5620 Service Aware Manager
(SAM) manage the BSA and BSR as a single virtual node. A secure VPLS
infrastructure interconnects the BSA and BSR.
The BSR routes traffic to and from multiple service providers to the IP/MPLS
network, as shown in Figure 25-4.

Figure 25-4 IP/MPLS network
IP/MPLS network
Service Core router Service
provider BSR BSR provider
Service Service
provider provider
Service Service
provider provider
Service Access Service

provider link provider
19419
Architectural elements
Table 25-1 describes the architectural elements of the IP edge aggregation and
routing component.
Table 25-1 IP edge aggregation and routing architectural elements
Component Description
BSA The BSA Is a high-capacity Ethernet-centric aggregation device

that:
• aggregates traffic from a 7342 ISAM FTTU that is connected to
subscriber residential gateways
• performs per-subscriber queueing, scheduling, accounting, and
filtering
• supports hundreds of GE ports, tens of thousands of filter
policies, and tens of thousands of queues
BSR The BSR Is a multiservice edge router that is connected to the

IP/MPLS network. The BSR:
• terminates the layer 2 access and routes over IP/MPLS with
support for all IP and MPLS routing protocols
• supports per-service and per-content type differentiation of
QoS levels
• supports the distribution of multicast traffic
• supports hundreds of ports
(1 of 2)

5750 SSC The 5750 SSC is a management system that provides a customer
self-service web portal to manage services for a subscriber.The
5750 SSC:
• supports centralized management of customer and service
profiles and policies
• works with the 5620 SAM to enable per-user QoS and bandwidth
changes in the network
5620 SAM The 5620 SAM is a management system that provides a unified
interface for activating services and policies across the distributed
elements of the TPSDA, including VPLS, QoS, multicasting, security,
filtering, and accounting.
The 5620 SAM supports the function to:
• install, create, configure, and manage end-user services
• configure and manage policies related to QoS, routing
protocols, schedules, ACLs, services, files, accounting, and
statistics
• set polling, deployment, and alarm policies
secure VPLS infrastructure VPLS Is a provider service that:

• emulates the functionality of a Local Area network
• interconnects 7342 ISAM FTTUs that are located in different
geographic areas as though they are in the same local area
network
• provides multipoint connectivity over an IP network
VPLS instances can be automatically established using

hub-and-spoke and ring topologies. The instance starts in the BSA
and terminates at the BSR, which is connected to the IP-routed
network.
(2 of 2)
7342 ISAM FTTU access network

The 7342 ISAM FTTU access network extends optical access across the last mile of
the communications network to the subscriber using fiber optic cabling to provide
services to residential or business subscribers. The 7342 ISAM FTTU access
network consists of the following elements:
• P-OLT
• GPON
• ONT

Figure 25-5 shows a composite view of the 7342 ISAM FTTU access network.

Figure 25-5 7342 ISAM FTTU access network
P-OLT GPON ONT
Optical link length 1
5520 AMS
Splitters
1490 nm 2.4 Gb/s
1310 nm 1.2 Gb/s

BSA
7342 P-OLT
1 The maximum optical link length depends on the specific equipment and deployment conditions.
19417
The 7342 ISAM FTTU access node is connected to Ethernet access ports on the
BSA. Typically, a single VLAN per subscriber is configured between the access
node and the BSA. This configuration enables the BSA to apply consistent
per-subscriber policies, such as QoS, filtering, and accounting.
The 5520 AMS provides both element management and network management
functions for the 7342 ISAM FTTU access network.
All services and traffic are transported between the P-OLT and an ONT over a
GPON network. The primary transport mechanism over the GPON is Ethernet over
GEM, with differentiated levels of service to ensure equitable and efficient
utilization of the shared bandwidth on the GPON.
• The P-OLT resides at the office of the service provider and performs a
network-to-GPON interface.
• The ONT resides at the customer premises or curb and performs a
subscriber-to-GPON interface function.
Architectural elements
Table 25-2 describes the individual architectural elements of the 7342 ISAM FTTU
access network component.

Table 25-2 7342 ISAM FTTU access network architectural elements
P-OLT The P-OLT equipment performs a network-to-GPON interface. The

equipment comprises three main elements:
• NT card: The Ethernet high capacity network termination (NT)
card connects the P-OLT to the BSA.
• ACU card: The alarm control unit (ACU) card provides a
centralized collection point for alarms and common alarm
displays for the central office.
• LT card: The GPON line termination (LT) is an asymmetrical
GPON line interface providing 2.4 Gb/s downstream through a
1490 nm optical wavelength and 1.2 Gb/s upstream through a
1310 nm optical wavelength. The LT card provides the
interfaces between the OLT and the ONTs through the optical
data network (ODN), where the PON interface is terminated
and the optical signal is converted to an electrical signal and
vice versa.
GPON The GPON brings optic fiber cabling and signals to the subscriber.
The optical transmission has no power requirements or active
electronic parts after the signal goes through the network.
The GPON employs a point-to-multipoint topology. A single strand
of fiber extends from the P-OLT at the central office to a passive
optical splitter. The splitter can handle up to 64 subscribers on a
PON, and a PON reach can be up to 60 km with the distance
between closest and furthest ONTs not exceeding 20 to 40 km
depending on the optics class used.
The optical link budget is defined by both loss and bandwidth
characteristics. The loss characteristic is determined by the
difference between the optical transmitter and optical receiver for
each direction. Typically this is 28 dB. The bandwidth characteristic
is reflected by the maximum link distance parameter of each OLT
and ONT transmitter specification, and is limited by the smaller of
the upstream and downstream values.
ONT The ONT is an edge device that terminates the GPON and provides
service interfaces to the subscriber. The ONT receives all
transmissions from the P-OLT, determines which data packets are
for the subscriber, and discards all other packets.
The ONTs are available in various models. They can be used
interchangeably on the GPON network so that service providers can
mix ONT models to meet the unique needs of their client base.
5520 AMS The 5520 AMS is an EMS that provides an alternative to the TL1 and
CLI. The 5520 AMS allow for full remote support of network
elements, including:
• provisioning
• software downloads
• database backup and restore
• fault management
• disaster recovery
• performance monitoring

25.3 7342 ISAM FTTU functionality
Table 25-3 represents the functionality of the 7342 ISAM FTTU. The functionality
has been divided into functional areas, with each functional area comprising one or
more configuration tasks. Table 25-3 lists the functional areas, the tasks, the chapter
in the 7342 ISAM FTTU Product Information Manual where concepts are described,
and the volume in the 7342 ISAM FTTU Operations and Maintenance Procedures
Guide using TL1 and CLI where configuration guidelines and procedures can be
found. A brief description of each functional area is provided in the sections that
follow.
Table 25-3 Functional areas of the 7342 ISAM FTTU
Functional area Task Chapter in 7342 ISAM FTTU Volume in 7342 ISAM FTTU
Product Information Manual Operations and
Maintenance Procedures
Guide using TL1 and CLI
Equipment Configuring P-OLT equipment Chapter 6 P-OLT equipment

Chapter 8 configuration
Chapter
Configuring ONT equipment See 7342 ISAM FTTU ONT ONT equipment configuration
Product Information Manual
Configuring interfaces − Interfaces
QoS Policing traffic Chapter 18 QoS configuration
Creating QoS profiles
Performing CAC check —

System Configuring system — System management
management
Configuring network −
management
Configuring STP —
Configuring security Chapter 20 Security configuration
Configuring system logging and Chapter 9 System logging, event, and

event management Chapter 20 alarm management
Performing OSWP download — System maintenance
Filter policies Configuring MAC filters — Filters configuration
Configuring ICMP filters
Configuring TCP filters

Configuring UDP filters
Configuring IP protocol filters
VLANs Configuring SHub VLANs Chapter 21 VLAN management and

configuration
Configuring PON VLANs
(1 of 2)

Functional area Task Chapter in 7342 ISAM FTTU Volume in 7342 ISAM FTTU
Product Information Manual Operations and
Maintenance Procedures
Guide using TL1 and CLI
Layer 2 forwarding Setting aging timer Chapter 15 Layer 2 forwarding and layer 3
routing configuration
Disabling MAC learning
Maintaining the VLAN FDB on

the NT
Maintaining the VLAN FDB on

the LT
Layer 3 routing Configuring VRFs — Layer 2 forwarding and layer 3

routing configuration
Configuring RIP —
IGMP and IP Configuring IGMP proxy Chapter 14 IGMP and multicast service
multicast configuration
Configuring IGMP snoop
Configuring multicast VLANs

Configuring for preconfigured
multicast
Configuring multicast packages
Configuring an IGMP signaling

channel
Reserving multicast bandwidth Chapter 18 QoS configuration

on the PON
Subscriber Configuring DHCP Chapter 10 Layer 2 forwarding and layer 3
connections routing configuration
Configuring PPPoE
Configuring Proxy ARP Chapter 17
ONT services Configuring ONT services Chapter 26 CES PW and CES over IP PW
Chapter 27 service configuration
Chapter 28 (Ethernet) HSI and Ethernet service

configuration
Chapter 23 (HSI)
Chapter 24 RF video service configuration
Chapter 22 Voice service configuration
— VDSL2 service configuration

Configuring ONT UNI ports — ONT UNI port configuration
(2 of 2)
25.4 Equipment
The equipment must be configured at the P-OLT level and at the ONT level.
Figure 25-6 shows a high-level view of the flow of data between the P-OLT and
ONT equipment.

Figure 25-6 7342 ISAM FTTU equipment
ONT
NT LT
ONT
ONT
ONT
SHub PON ONT
ONT
21354
Configuring P-OLT equipment

The equipment at the P-OLT includes NT cards, ACU cards, LT cards, and the PON
facility.
NT cards
The NT cards include the following:
• EHNT-A for the N shelf
• EHNT-B for the M shelf, which is the ETSI equivalent of the L shelf
• EXNT-A for the M shelf
Each NT card has a SHub module and uses 2 Broadcom modules.
LT cards
The LT cards include the following.
• GLT2-A, B, C – 2 PON port variations, which is usable with all NT types and
shelves
• GLT4-A – 4 port LT card, which is common in APAC
• GLT8-A - 8 port LT card, which is supported on EXNT-A cards only
Configuring ONT equipment

The equipment at the ONT level includes the ONT and ONT cards. The
7342 ISAM FTTU supports a large number of ONT variants for providing data,
voice and video services, and various interfaces to access the ONT including:
• SSH CLI interface
• HTTP interface
Creating a power shedding profile

An optional power shedding profile can be configured for an ONT to establish the
length of time that a class of service is to remain operational when the power source
for the ONT transitions to battery power during an outage.

Setting ONT NTP parameters

If NTP is used to calibrate the time on the ONT, the operator must specify parameter
settings that enable access to an NTP server.
Setting threshold levels for 1490 nm downstream signal

The 7342 ISAM FTTU uses a 1490 nm downstream signal for data, IPTV, VoIP, and
packetized CES DS1/E1 downstream traffic between the P-OLT and the ONT, as
shown in Figure 25-5. The operator can set high and low optical power level
thresholds for the downstream signal. An alarm is raised in the system if either the
high or the low optical power level threshold is crossed.
Entering and clearing SLID at the ONT

The operator can use either the serial number of the ONT or a SLID to uniquely
identify a new ONT on the PON. The P-OLT uses the serial number or the SLID to
match a newly PON-connected ONT to its provisioning data. The serial number is
hard coded into the ONT. However, a SLID uniquely identifies a subscriber site and
is hardware-independent. Therefore, the SLID must be entered in the ONT by an
operator, and cleared when the ONT is reused.
Configuring interfaces
Interfaces include ports on the NT card and LAGs. Ports include front-panel ports
(network-side ports) and LT-side ports. A LAG is a combination of physical links
into a single logical link. Only front-panel ports can participate in a LAG. The
number of front panel ports limits the number of LAGs in a system.
25.5 System management
System management includes one or more of the following tasks:

• Configuring system
• Configuring network management
• Configuring security
• Performing OSWP download
• Configuring STP
Configuring system
As part of system turn-up, the following parameters are configured at the system
level:
• system identifier for the 7342 ISAM FTTU, location, and contact name
• network VLAN EtherType
• date and time
• clock synchronization
• default time-to-live
• NT redundancy for non-simplex operation
• IP address of default router

• system MAC address

• management interface
• management VLAN
• SNMP communication
• VLAN system parameters including MAC aging timer, ARP refresh timer,
reserved VLANs, default tagging mode of SHub VLANs
• IGMP system parameters including IGMP proxy and all system-level parameters
for IGMP traffic
• P-OLT equipment including ACU card, LT cards, and PONs
Configuring network management

The 7342 ISAM FTTU provides the following choices for network management:
• in-band management
• out-of-band management
• SNMP with the AMS management system
Out-of-band management
Out-of-band management utilizes the ACU port. The ACU port is 100Mbps capable,
but the software is limited to a much smaller bandwidth. The ACU port is an
untagged port, which requires no VLAN configuration. The ACU port is
unprotected; it is subject to extreme network condition such as ARP storm.
Out-of-band network is assumed to be a secure network. Therefore, protection
should be provided at network level.
In-band management
In-band management uses the NT port, which is protected. The default management
VLAN is 4093, which can be changed to another VLAN.
SNMP management
SNMP management can be configured in CLI to allow communication between
GPON and AMS. The 7342 ISAM FTTU supports SNMP v1/2 or SNMP v3.
SNMP v1/2 requires the communication of community and SHub community
strings. SNMP v3 requires the configuration of user, group, privacy and
authentication information.
Configuring security
The following entities are configured as part of security:
• unsecured access channel to the P-OLT, or secured access channel to the P-OLT
using SSH
• secured CLI access to ONT using SSH
• CLI login banner
• Internet key exchange
• Internet protocol security (IPsec) service

• operator accounts and passwords

• RADIUS servers
• 802.1x authentication for an ONT port
Configuring STP
The spanning tree protocol (STP) is a link management protocol that provides
multiple data paths from one network segment to another, and protects the network
against loops. All bridges running STP collect information about other bridges in the
network through an exchange of data messages called BPDUs. The BPDU packets
hold information about ports, addresses, priorities, and costs. This exchange of
information requires the following:
• a bridge is elected as root bridge for the spanning-tree network topology
• every bridged LAN segment has a designated bridge
• redundant bridge ports are placed in a backup state to remove loops in the bridged
network
STP has many variants. The 7342 ISAM FTTU supports rapid spanning tree
protocol (RSTP). RSTP is configured on the NT using CLI commands. Elements of
the configuration include the following:
• RSTP parameters at the system level, such as hello time, forward delay, bridge
priority
• RSTP parameters at the port or LAG level, such as whether the port is an edge
port and the STP bridge priority of the port
Configuring system logging and event management

This section describes system logging and event management on the
7342 ISAM FTTU.
Configuring system logging

The 7342 ISAM FTTU supports up to 64 system logs, also known as syslog. The
system log contains actions performed on the NE, behavior of the NE that may
provide troubleshooting information, even after a reset, and security-related
information for administrators.
Based on information contained in the syslog, the administrator can:
• trace and audit the behavior of the NE
• review operator actions
• change the security settings
Figure 25-7 shows the syslog system.

Figure 25-7 Syslog system
Syslog record
storage
SHub logs Configuration

Authentication query results
CLI configurations
Syslog Local file system
system
TL1 configurations
View management Send syslogs to

from stations remote servers
18901
All syslog messages include a timestamp, based on the NE system clock, to identify
the time the logged action or event occurred. System log messages also provide a
description of the action that is being logged, and identifies the remote host terminal
of the user performing the logged action.
Configuring event management

The system reports alarm conditions (alarms) and non-alarm conditions (events) to
the management interface, for all system entities. The notification code associated
with a condition determines whether the condition is reported as an alarm or event,
and specifies the severity level for the alarms as minor, major, or critical.
• You can set and view the notification codes for the conditions associated with
each of the system entities.
• You can enable or inhibit autonomous messages based on the alarm or event
notification code.
You can also set and view reporting thresholds for common equipment (COM)
non-facility alarms and events, ONT alarms and events (other than ONT card alarms)
and PON alarms and events. The reporting threshold specifies that only alarms and
events of the configured severity level, or higher, will be reported. For example, if
you configure the reporting threshold for a specific ONT to major (MJ), all major and
critical alarms for the ONT will be reported; minor alarms and non-alarm events are
not reported. The alarm threshold you set overrides the common default threshold for
the equipment type.
Performing OSWP download

The overall software package (OSWP) consists of the 7342 ISAM FTTU core, NT,
SHub, and LT software files. The NT card has the capacity to store two software
packages from different releases in its software banks, OSWP-1 and OSWP-2.

When the OSWP is downloaded to the 7342 ISAM FTTU, the Type-A software files
are automatically downloaded to the LT cards installed in the system. The download
is accomplished in the background and is non-service affecting. The files are marked
as passive software files in the LT and do not become active until the LT card is reset.
25.6 QoS
QoS is a method to provide different levels of service for different types of network
traffic. The 7342 ISAM FTTU supports a QoS model that ensures:
• bandwidth is available to support requested services
• per-subscriber bandwidth controls on services meet service level agreements for
a subscriber
• there is minimum delay, jitter, and packet loss for critically sensitive traffic, such
as voice and video
The QoS model on the 7342 ISAM FTTU is implemented through traffic policing,
QoS profiles, and CAC checks.
Policing traffic
The operator can implement traffic policing on network interfaces to monitor egress
traffic for rate on a per-port basis, and to monitor ingress traffic for rate and
maximum burst size on a per traffic flow basis. A traffic flow can be defined as a
port, a VLAN, a combination of VLAN and p-bit, or a combination of VLAN and
DSCP.
Creating QoS profiles

A QoS profile is a template with settings that are applicable to individual entities
within a network. The operator can create different types of QoS profiles and apply
them to network entities to mark, tag, classify, queue, and rate limit traffic, and to
specify service bandwidth requirements. The profile can be used by more than one
network entity at the same time. Table 25-4 identifies the QoS profiles, their
function, and the network entities to which they can be applied.
Table 25-4 QoS profiles
Function QoS profile Applied to
Classify traffic P-bit to CoS mapping NT card (1)
Mark and tag traffic C-VLAN to S-VLAN p-bit PON VLAN

translation profile
QoS marker and session profile ONT UNI port
DSCP to p-bit translation profile ONT UNI port
UNI-side to network-side p-bit Flow

translation profile
(1 of 2)

Function QoS profile Applied to
Support class-based queuing Traffic scheduler (NT) Ports on NT card(2)

and scheduling
P-bit to queue mapping (LT) Ports on LT card (3)
Traffic scheduler (LT) Ports on LT card
Priority queue profile ONT service or flow
Rate limit traffic Policer (meter and traffic flow) Network ports on NT card
Per-ONT downstream rate ONT

limiting scheduler
Per-service downstream rate ONT service or flow

limiting scheduler
Specify service bandwidth Bandwidth profile ONT service, flow, or portal

requirements
(2 of 2)
Notes
(1) The p-bit to CoS mapping is applied to upstream traffic only on the NT card.
(2) NT ports include network-side and LT-side ports.
(3) The system automatically applies the p-bit to queue mapping profile to all queues on the LT card.
Performing CAC check

CAC checks are performed to ensure that sufficient bandwidth is available on a
network interface, a PON, and on a service VLAN (S-VLAN) to maintain new QoS
requirements without affecting the QoS of existing ONT services. The system
automatically initiates the CAC check on the network port or LAG after an S-VLAN
is added to the network interface, or on the PON and S-VLAN after the operator
creates a service, portal, or flow. The system rejects the request if the network
interface, PON, or the S-VLAN has insufficient bandwidth.
25.7 Filter policies
Filter policies, also referred to as Access Control Lists (ACLs), are templates
consisting of filters that can be applied to physical ports on the NT card. Filters can
be VLAN-specific, or applicable to all VLANS on a port.
Filter policies include MAC filters, ICMP filters, TCP filters, UDP filters, and IP
protocol filters.
Configuring MAC filters

The MAC filter controls incoming VLAN traffic on a network or LT port. The MAC
filter specifies the criteria by which a packet is allowed or dropped, and the action of
allow or drop for a matching packet. Filtering criteria include:
• source MAC address
• destination MAC address
• source and destination MAC address
• EtherType
• VLAN (optional)

Configuring ICMP filters

The ICMP filter controls incoming or outgoing ICMP traffic on a network or LT port.
The ICMP filter specifies the criteria by which an ICMP packet is allowed or
dropped, and the default action of allow or drop for a matching packet. Filtering
criteria include one or more of the following:
• source and/or destination IP address (mandatory)
• message type (optional)
• message code (optional)
• traffic direction
• VLAN (optional)
Configuring TCP filters

The TCP filter controls incoming or outgoing TCP traffic on a network or LT port.
The TCP filter specifies the criteria by which a TCP packet is allowed or dropped on
a port. Filtering criteria include one or more of the following:
• range of destination TCP ports (optional)
• range of source TCP ports (optional)
• VLAN (optional)
Configuring UDP filters

The UDP filter controls incoming or outgoing UDP traffic on a network or LT port.
The UDP filter specifies the criteria by which a UDP packet is allowed or dropped
on a port. Filtering criteria include one or more of the following:
• range of destination UDP ports (optional)
• range of source UDP ports (optional)
• VLAN (optional)
Configuring IP protocol filters

The IP protocol filter controls incoming or outgoing IP protocol (other than UDP,
TCP, and ICMP) traffic on a network or LT port. The IP filter specifies the criteria
by which an IP protocol packet is allowed or dropped on a port. Filtering criteria
include one or more of the following:
• IP protocol (optional)
• VLAN (optional)

25.8 VLANs
A virtual LAN, commonly known as a VLAN, is a group of physically dispersed

hosts or end stations with a common set of requirements that communicate as if they
were attached to the same broadcast domain. VLANs are used to limit the boundaries
of a broadcast. The VLAN groups nodes (or devices) in a single broadcast domain.
Only nodes within the same broadcast domain can receive broadcast frames that
originate from any node within the same domain.
VLANs are created on the 7342 ISAM FTTU for various purposes, such as:
• to establish an IP connection to the switch from a workstation connected to a port
in the VLAN (management VLAN)
• to carry IP multicast streams from IPTV service providers from the IP/MPLS
network to the PON (multicast VLAN)
• to carry services from network service providers to subscribers (S-VLANs)
VLANs are configured between the BSA and the 7342 ISAM FTTU access node,
using the 5620 SAM. VLANs are created on the NT card using the CLI, and on the
LT card using the TL1.
For multicast and service VLANs, a VLAN is created on the NT card and the
equivalent VLAN is created on the LT card. The VLAN IDs must match to create a
secure path for data and video traffic from the Ethernet network to the PON.
Configuring SHub VLANs

VLANs on the NT can be configured in one of four operational modes:
• Residential-bridge mode
• Cross-connect mode
• Reserved mode
The operator has the capability to associate the VLAN with the following ports to
provide layer 2 bridging with the external world:
• network ports
• LT ports
• LAG ports (built on top of network ports)
Network ports and LAG ports instantiate the network side, while LT ports instantiate
the subscriber side.
Configuring PON VLANs

VLANs are managed on the LT as PON VLANs. A PON VLAN can be configured
to operate in one of four modes:
• Residential-bridge mode, for layer 2 forwarding based on destination MAC
address
• C-VLAN learning mode, for layer 2 forwarding based on C-VLAN

• Cross-connect mode, where the VLAN is associated with a single subscriber

bridge port
The PON VLAN must share the same identifier as the corresponding VLAN on the
NT.
For RB VLANs, the operator can enable DHCP relay or PPPoE relay with Option 82
on the PON VLAN. If DHCP is enabled, the Proxy ARP function is activated on the
PON VLAN to respond to ARP requests from an edge router for a host on a CPE.
VLAN tag handling

To understand how the VLAN capability works on the 7342 ISAM FTTU, the
system can be broken down into its individual modules including the NT/SHub, the
LT, and the ONT, and understand how each module handles the VLAN tagging
respectively.
The following sections provides a brief overview of VLAN tag handling on each
module. See the 7342 ISAM FTTU Product Information Manual for complete
information on VLAN tag handling.
NT/SHub
The main function of the NT/SHub is to route the packet to the proper destination
based on VLAN. It typically does not handle VLAN tagging, such as altering VLAN
tag information.
A VLAN association must be created in the upstream direction to allow uplink
forwarding to the NT network port, and in the downstream direction to allow packet
forwarding to the proper LT card.
LT
The LT provides the following tagging modes on a per PON VLAN basis:
• stacked VLAN mode
The stacked mode is the most commonly used VLAN mode. As a general rule, in
the stacked VLAN mode, the LT adds the outer S-VLAN before sending the
packet to the network (NT/SHub), and strips the outer S-VLAN tag before
sending the packet to the subscriber (ONT).
• unstacked VLAN mode
In the downstream direction, the LT sets the VLAN ID in the outer tag to zero,
and sends a priority-tagged frame to the ONT; in the upstream direction, the LT
overwrites the C-VLAN tag with the S-VLAN tag.
The LT passes the outer tag as is.
Regardless of the tagging mode, the LT does not change the p-bit in the downstream
direction.

ONT
In the downstream direction, the ONT supports transmitting to port with or without
a tag. In the upstream direction, the ONT supports multiple VLAN tagging options,
including untrusted, VLAN pass-through, VLAN translation, VLAN translation with
EtherType classification, EtherType classification, and flexible mode.The most
commonly used tagging modes are untrusted, VLAN pass-through, and flexible
mode.
The downstream and upstream tagging options are defined in the QoS
marker/session profile.
In untrusted mode, the ONT will add the C-VLAN tag using the port-based default
values when an untagged IP frame is received; when a tagged frame is received, the
ONT will overwrite the C-VLAN tag using the port-based default values.
In pass-through mode, as a general rule, the ONT leaves the frame as is. However,
the ONT drops a double-tagged frame. When an untagged frame is received, the
ONT adds the C-VLAN tag using the port-based values.
In VLAN translation mode, the ONT swaps the UNI-side C-VLAN with the
NETWORK-side CLVAN, for a single tagged frame. However, the ONT drops the
frame if it is a priority-tagged or double-tagged frame. Along with VLAN
translation, the ONT can also perform p-bit translation in the upstream and
downstream based on the optional p-bit translation profile.
Flexible mode offers complex handling of the tag, and supports double-tagged
frames. See 7342 ISAM FTTU Product Information Manual for more information.
25.9 Layer 3 routing
The 7342 ISAM FTTU supports virtual routing and forwarding on the SHub (VRF)
and RIP as the routing protocol.
VRF is a logical and virtual routing function included in an IP network router that
allows multiple instances of a routing table to exist in a router and to work
simultaneously. Each instance of a routing table is identified by a VRF number.
A routing table keeps track of routes to specified destinations, and a routing metric.
The routing table is used to determine the best path along which a data packet will
be forwarded toward its final destination.
ARP cache (also called IP-to-net media) is a table in memory of address mappings
that translate host server IP addresses to their corresponding Ethernet addresses. The
ARP cache translates a destination IP address to a destination MAC address.
The system uses ARP cache for destination IP addresses that are directly connected.
For a destination IP address that is not directly connected, a route is stored in the
routing table. The routing table points to the next hop, which represents a directly
connected IP address.

Each packet contains its origin and destination. When a packet is received, the router
determines the VRF based on the interface it arrived on and examines the packet.
• If the destination IP address specified in the packet is directly connected, the ARP
cache provides the corresponding MAC address.
• If the destination IP address specified in the packet is not directly connected, the
router finds the best routing table entry match for its destination. The routing table
entry match provides the next hop. The next hop represents a directly connected
IP address, and the ARP cache provides the corresponding MAC address.
The destination MAC address in the packet is set to the MAC address from the ARP
cache, and the router forwards the packet based on its destination MAC address. At
each subsequent hop, the process is repeated until the packet reaches its final
destination.
Configuring VRFs
The 7342 ISAM FTTU supports up to 127 VRF instances on the SHub. The VRF
comprises both static and dynamic entries:
• The operator can manually update a VRF with a static route including IP route
destination, next hop, VLAN ID associated with the VRF to the next hop, and
routing metric.
• The system can dynamically update the VRF with newly learned routes received
from RIP.
The VRF can be associated with one or more SHub VLANs.
Configuring RIP
The 7342 ISAM FTTU supports the routing information protocol (RIP). RIP is an
interior gateway protocol (IGP) that uses a distance-vector algorithm to determine
the best route to a destination with the hop count as the deciding factor.
25.10 Layer 2 forwarding
Forwarding is the process whereby frames in a VLAN are relayed from one port to
another. The 7342 ISAM FTTU uses both the NT and the LT cards to provide the
layer 2 forwarding function. The NT and LT cards provide two independent layer 2
systems. They both learn and age independently on MAC addresses. Where
C-VLAN forwarding is used, the LT card also learns and ages on C-VLAN.
Table 25-5 compares layer 2 forwarding on the NT and LT cards.
Table 25-5 Layer 2 forwarding differences between NT and LT
Item NT card LT card
Aging timer The operator sets the aging timer for learned entries at the system level.
The system applies the aging timer to all learned entries.
(1 of 2)

Item NT card LT card
MAC address learning The operator can explicitly disable The forwarding mode of the PON
MAC learning for a range of SHub VLAN determines if MAC learning is
VLANs. enabled or disabled. The LT card
learns MAC addresses for RB PON
VLANs.
C-VLAN learning N/A The LT card learns C-VLANs for PON

VLANS in C-VLAN learning mode.
(2 of 2)
Setting aging timer

The aging time specifies how long a learned entry in the VLAN FDB is retained after
no packets are sourced from the address. On the NT and the LT, the aging timer is
set at the system level, and applies to all learned MAC addresses.
Disabling MAC learning

On the NT, the operator can disable MAC learning for a range of SHub VLANs.
Disabling MAC learning is specifically applicable to CC VLANs where the VLAN
is associated with only one network port and one LT port.
On the LT card, the operational mode of the PON VLAN determines whether MAC
learning or C-VLAN learning is disabled, as shown in Table 25-6.
Table 25-6 MAC learning and C-VLAN learning on the LT
Operational mode of PON VLAN MAC learning C-VLAN learning

disabled disabled
Residential bridge mode ✓
C-VLAN learning mode ✓
Cross-connect mode ✓ ✓
Flow mirroring mode ✓ ✓
Maintaining the VLAN FDB on the NT

On the NT card, the layer 2 bridge uses a VLAN FDB to derive the list of ports to
forward a packet. When a downstream packet arrives at the bridge, the bridge
performs a lookup in the VLAN FDB. If a matching entry is not found, the bridge
discards the packet.
The VLAN FDB on the NT card comprises both static and dynamic entries.
• The operator can add a static unicast MAC entry for a specified VLAN and port.
• Dynamic entries are learned entries. The NT learns and ages MAC addresses.
When an upstream packet arrives at the bridge, the bridge examines the packet for
the source MAC address If the source MAC address is not found in the VLAN
FDB, the layer 2 bridge adds an entry, and deletes the entry when it ages out.

Maintaining the VLAN FDB on the LT

On the LT card, the 7342 ISAM FTTU uses the VLAN FDB to derive the list of
subscriber bridge ports to forward a packet. When a downstream packet arrives at the
bridge, the 7342 ISAM FTTU performs a lookup in the VLAN FDB. If a matching
entry is not found, the 7342 ISAM FTTU discards the packet.
The VLAN FDB on the LT card comprises both static and dynamic entries.
• The operator can add a static MAC or C-VLAN entry.
• Dynamic entries are learned entries. The LT learns and ages on MAC addresses
or C-VLANs depending on the operational mode of the PON VLAN; see
Table 25-6.
• In MAC learning mode, when an upstream packet arrives at the bridge, the bridge
examines the packet for the source MAC address. If the source MAC address is not
found in the VLAN FDB, the bridge adds an entry, and deletes the entry when it ages
out.
• In C-VLAN learning mode, when an upstream packet arrives at the bridge, the
bridge examines the packet for the C-VLAN. If the C-VLAN is not found in the
VLAN FDB, the bridge adds an entry, and deletes the entry when it ages out.
• The operator can also delete dynamic entries, specifically to expedite the move of
an ONT to a new location.
25.11 IGMP and IP multicast
The 7342 ISAM FTTU delivers video streams on demand to IPTV video subscribers
using the IP multicast technology.
Multicast streams are sourced at the NT from a network-side port and are forwarded
to a single “multicast” GEM port on each PON to subscribers. The
7342 ISAM FTTU only forwards multicast streams from multicast sources that are
configured as static, and those requested by a subscriber. The broadcast nature of the
PON allows multicast streams to be distributed to multiple subscribers.
The 7342 ISAM FTTU maintains a multicast forwarding information base (FIB) on
the NT, LT, and ONT. The multicast FIB holds the port membership for all active
multicast source entries.
Figure 25-8 shows the implementation of IGMP across the service delivery
architecture.

Figure 25-8 Implementation of IGMP across the service delivery architecture
BSR BSA P-OLT NT P-OLT LT ONT
IGMP IGMP IGMP IGMP

proxy proxy proxy snoop
IGMP joins, leaves,

and reports
IGMP GMQs
and GSQs
Network Subscriber
equipment equipment
Multicast forwarding
upstream
downstream
19433
Configuring IGMP proxy

IGMP proxy facilities are configured on the NT and the LT; see Figure 25-8. These
facilities manage the multicast FIB. The IGMP proxy facilities support RFC 2236
(version 2) and RFC 3376 (version 3) “Internet Group Management Protocol”
(IGMP). To manage the multicast FIB, the IGMP proxy facilities process incoming
IGMP messages and queries, and send out IGMP messages, queries, and reports.
Configuring IGMP snoop

An IGMP snoop function is implemented on the ONT; see Figure 25-8. The IGMP
snoop function silently examines all IGMP messages:
• to track the IP multicast streams that a host is receiving
• to regulate and monitor the number of active streams on the ONT UNI port
During OLT provisioning of IGMP proxy or an IGMP signaling channel, the ONT
IGMP snoop facility receives the following settings:
• from IGMP proxy where the setting applies to all streams on the ONT:
• maximum stream age, which is computed as follows:
age = (((robustness variable) × (Query interval)) + (one Query Response Interval))
The age of a stream is reset upon snooping a related IGMP Report. A stream is
removed from a subscriber port if a Report is not received within the provisioned
age limit.
• from IGMP signaling channel where the settings apply to a specific ONT UNI:
• maximum number of multicast streams allowed to be received
• maximum number of hosts that are allowed to receive the same multicast stream
• maximum IGMP message rate
• IGMP version (v2 or v3)
• LT to ONT signaling enabled/disabled


The operator must configure one or more VLANs on the 7342 ISAM FTTU to
forward the multicast traffic from the multicast edge router to the subscriber. Each
VLAN can serve one, or multiple service providers. The VLANs are created as SHub
VLANs on the NT, and as PON VLANs on the LT.
To support ONTs that cannot perform one-to-one VLAN translation in the
downstream, the system supports multicast VLAN translation on the NT.
Configuring for preconfigured multicast

A multicast source is typically configured when offered as a multicast channel to
subscribers. A preconfigured multicast source is uniquely identified by an IP address
in the multicast source table. The multicast stream is carried to the subscriber in a
multicast VLAN that is dedicated to the NSP.
The operator can configure a multicast source as either dynamic or static.
• A dynamic multicast source is only activated through IGMP signaling.
Dynamic multicast sources are entered at the LT only.
• A static multicast source is added to the multicast FIB, and forwarded to the PON
at system startup.
Static multicast sources are entered at the NT on a per-VLAN basis, and
associated with one or more LT-side ports for forwarding. The equivalent static
multicast source must be entered at the LT, and associated with one or more
PONs.
Configuring for nonconfigured multicast

Nonconfigured multicast does not have preconfigured multicast channels in the
multicast source table. The multicast stream is carried in the NSP VLAN configured
for the IGMP signaling channel that is supporting the subscriber. If the IGMP
signaling channel does not have a configured NSP VLAN, the multicast stream is
carried in the network-side VLAN configured for the HSI service or flow that is
supporting the IGMP signaling channel.
Configuring multicast packages

The operator can deliver different levels of service to subscribers by grouping
multicast streams into one or more packages, which are offered as a group of viewing
or listening channels. The subscriber can choose to subscribe to a package for a
pre-view session or for a full-view session.
Categorizing multicast sources into packages

The operator can categorize a multicast source into one or more multicast packages
when the operator creates or modifies the multicast source.

Configuring an IGMP signaling channel

An IGMP signaling channel is established between the LT and a subscriber, and is
configured on the ONT UNI port. The IGMP signaling channel has the same
identifier as the HSI or flow that it serves. The channel specifies the IGMP and
multicast characteristics of the service, such as the IGMP version used, the maximum
number of multicast streams that the host supports, the maximum bandwidth that can
be used for all multicast groups for the ONT UNI, and the full-view and pre-view
subscription packages of the subscriber.
Granting viewing rights

The operator can grant full-view or pre-view rights to packages to a subscriber when
the operator creates or modifies the IGMP signaling channel.
Reserving multicast bandwidth on the PON

Each PON interface that has multicast subscribers must be configured with available
bandwidth for the multicast service.
Multicast streams are not replicated on the PON. The multicast streams are
forwarded downstream and carried across the PON using a a single GEM port ID.
The bandwidth required for multicast streams is reserved at the PON level to ensure
that multicast traffic is accounted for in the CAC check.
The system tracks the amount of bandwidth consumed on a PON. When a subscriber
requests an IP multicast stream that is not already on the PON, the system adds the
bit rate to the current rate in use. If the total exceeds the allowable bandwidth amount,
the request is denied.
25.12 Subscriber connections
The 7342 ISAM FTTU uses the LT card to provide the DHCP relay agent function,
the PPPoE relay agent function, and the proxy ARP function. The operator can
enable these functions on a per-VLAN basis for RB VLANs.
The operator can use DHCP and PPPoE relay for different ONT services on the same
ONT UNI. With FGU4.8.04 and later, the ONT services can be on the same
S-VLAN, but with pre FGU4.8.04 software the operator cannot enable DHCP and
PPPoE on the same S-VLAN.
Configuring DHCP
DHCP is a network protocol that allows a host to obtain its IP address and other
configuration information from a server when the host powers up. The
7342 ISAM FTTU uses the DHCP relay agent function on the LT card to provide the
DHCP functionality. The LT card supports only the layer 2 relay agent function.

The DHCP relay agent function is required when the LAN does not have BOOTP or
a DHCP server. In a LAN, a host on the LAN broadcasts a DHCP request message
on the network. Every DHCP server that receives the message replies with a DHCP
offer message, which allows the client to choose a server based on the host client
configuration. A server on the LAN can be configured to relay the requests to the
DHCP server that may be located elsewhere on the network. The DHCP relay agent
function also passes the responses from the server to the client that initiated the
request.
The layer 2 DHCP relay agent function on the LT card:
• optionally appends the circuit ID and remote ID of hosts to DHCP request
messages from hosts (see Configuring Option 82 in this chapter)
• snoops DHCP acknowledgements from DHCP servers to learn IP addresses
assigned to hosts for secure ARP purposes
DHCP relay parameters
On the LT, DHCP is configured on a per-VLAN basis for PON VLANs in

residential-bridge mode, and includes these parameters:
• DHCP, to enable the relay agent on the PON VLAN
• Option 82 parameters, including circuit ID and remote ID
The parameters used to configure DCHP on the NT include:
• relaying, which enables or disables the DHCP relay agent
• VRF and VLAN association
• VRF relay agent parameters including
• seconds threshold, which specifies the maximum time that a DHCP server is given
to answer a DHCP request
• hops threshold, which specifies the maximum number of hops that a request can go
through before reaching a DHCP server
• IP address of VLAN
• DHCP server and IP address, which specifies the DHCP server and IP address to
which the relay agent forwards packets
• route
Configuring Option 82
Option 82 allows the DHCP relay agent function on the LT to append the physical
location of a host to a DHCP request message that is being forwarded to a DHCP
server. If Option 82 is enabled, the DHCP server returns the Option 82 parameter in
the response, so that the DHCP relay agent relays the response only on the
originating circuit.

Configuring PPPoE
PPPoE is a Point-to-Point Protocol over Ethernet (PPPoE) that service providers can
use to provide high-speed Internet (HSI) services. When a service provider chooses
to use PPPoE, the PPPoE relay agent provides information to the broadband remote
access server (BRAS) or to an ISP service about which subscriber is setting up a
PPPoE session.
The 7342 ISAM FTTU uses the LT card to provide the layer 2 PPPoE relay agent
function. The operator can enable or disable the PPPoE relay agent function on the
PON VLAN level for RB VLANs in stacked or unstacked tagging mode, and
optionally configure PPPoE for Option 82; see Configuring Option 82 in this
chapter.
Configuring Proxy ARP

Proxy ARP allows a device, such as a router, to answer ARP requests that are
intended for another device. This allows a device to reach a remote subnet without
configuring routes to the subnet or a default gateway device.
Proxy ARP is a technique by which a device on a specific network answers the ARP
queries for a network address that is not on that network. The ARP proxy is aware of
the location of the destination, and offers its own MAC address in reply. Serving as
an ARP proxy for another host effectively directs LAN traffic to the proxy. The
redirected traffic is then typically routed by the proxy to the intended destination via
another interface or via a tunnel.
Configuring proxy ARP on the LT

The 7342 ISAM FTTU supports a proxy ARP function on the LT on a per-VLAN
basis to handle ARP requests from an edge router for the MAC address of a host on
the CPE. To enable the proxy ARP function, the operator must enable DHCP on the
PON VLAN.
The proxy ARP function uses an ARP table on the LT to respond to ARP requests.
The ARP table contains dynamic and static entries.
• Where a host uses DHCP to obtain its IP address, the LT snoops the DHCP ack
response from a DHCP server to learn the IP address and MAC address of the
host, and adds a dynamic entry in the lease table and in the ARP table.
• Where the IP address is statically allocated to a host on a CPE, such as to a set-top
device for VoD, the operator can create a static entry in the ARP table on the LT.
25.13 ONT services
The 7342 ISAM FTTU supports Ethernet services for business and residential
applications, and traditional services such as HSI. The services originate from the
network side, and are carried across the 7342 ISAM FTTU access network to
subscribers, as shown in Figure 25-9.

Figure 25-9 Service delivery across the 7342 ISAM FTTU access network
Slot Port
(physical) (physical) UNI Service
ONT Port ID
ONTENET HSI
VLAN Bridge PON ONTENET

port HSI
Slot (physical)
NT card LT card
ONTPOTS Voice
VLAN
bridge
Slot (physical)
ONTVIDUNI
Slot (physical)
18912
Configuring ONT services

The 7342 ISAM FTTU supports the following ONT services:
• CES PW and CES over IP PW
• Ethernet for business or residential applications
• HSI
• IPTV and video
• RF video
• VDSL2
• VoIP
High-speed Internet and video can either have their own HSI, or share the same HSI.
If the HSI is shared, an IGMP signaling channel is required for video.
Configuring ONT UNI ports

Based on the model of the ONT, an ONT can support multiple ONT UNI ports. An
ONT UNI port supports a single subscriber. An ONT UNI port can carry multiple
services to a subscriber. Typically, this configuration occurs when more than one
service provider supplies services to the subscriber.
Table 25-7 identifies the ONT UNI port that is specific to an ONT service.

Table 25-7 ONT UNI ports
ONT service ONT UNI port
CES PW and CES over IP PW DS1 or E1
Ethernet for business or residential applications Ethernet

(1) MoCA
HSI
ONT HPNA
IPTV and video
VDLS2 VDLS2
VOIP POTS
Note
(1) High-speed Internet and video can either have their own HSI, or share the same HSI. If the HSI is
shared, an IGMP signaling channel is required for video.
25.14 Configuration examples
This section provides configuration examples of the following:

• System configuration
• P-OLT equipment configuration
• IGMP and multicast configuration
• ONT equipment configuration
• VLAN configuration
• DHCP configuration
• HSI service with IGMP signaling channel configuration
• VoIP service configuration
The examples represent an end-to-end configuration of the 7342 ISAM FTTU that
provides data, IPTV, and voice services to a subscriber, as shown in Figure 25-11.
Figure 25-10 Subscriber service provisioning example
NT LT ONT RG
VLAN Ethernet
(subscriber)
10/100/1000 Base T 10/100
VLAN IPTV 1 Base T
(multicast) Computer
VLAN IPTV 2
(multicast)
Voice Phone
Phone
Set-top box
19434

Following are the general characteristics of the configuration. Specifics are given
within the configuration examples.
• The 7342 ISAM FTTU system is configured for simplex NT operation.
• The end-to-end configuration uses a VLAN per subscriber model where all
services are carried to the subscriber on ONT 2 under PON 1 on LT card 2 in
VLAN 10 in residential bridge mode from network port 1.
• VLAN 10 is enabled for DHCP.
• Multicast streams from one NSP will be carried from a multicast edge router to
the PON in VLAN 40 in unstacked tagging mode from network port 2.
• Multicast streams from a second NSP will be carried from a multicast edge router
to the PON in VLAN 41 in unstacked tagging mode from network port 2.
• IGMP proxy on the LT will operate in full proxy mode, and IGMP signaling will
be enabled between the NT and the network multicast router on the multicast
VLANs.
• Voice service is in H.248/Megaco softswitch mode.
The examples include the configuration entities in Figure 25-11. A shaded box
indicates an entity that will be configured in the examples.
Figure 25-11 Configuration entities in configuration examples
QoS session profile Bandwidth profile

QoS marker profile Prority queue profile
ONT 1
ONTCARD ENET HSI IGMP

ENET channel
LT 1
PON 1 ONT 2
ONTCARD POTS VoIP
VOICE
Network
port 1 NT A LT 2
PON 4 ONT 64 Bandwidth profile

Prority queue profile
LT 14
or
LT 18
21368
The following workflow represents the logical order to use the sample procedures in
this section to provide services to a subscriber.
1 Configure system; see System configuration in this chapter.
2 Configure P-OLT equipment; see P-OLT equipment configuration in this
chapter.
3 Configure IGMP and IP multicast; see IGMP and multicast configuration in this
chapter.
4 Configure ONT equipment; see ONT equipment configuration in this chapter.
5 Configure S-VLAN; see VLAN configuration in this chapter.

6 Configure S-VLAN for DHCP; see DHCP configuration in this chapter.

7 Configure HSI service and IGMP signaling channel; see HSI service with IGMP
signaling channel configuration in this chapter.
8 Configure VoIP service; see VoIP service configuration in this chapter.
System configuration
The following sections provide examples to turn up the system, to configure network
management for in-band and out-of-band management, and to establish SNMP
communication.
Configuring system
The following shows an example to turn up the 7342 ISAM FTTU with these
characteristics:
• manual setting of date and time of system
• synchronization to local clock
• in-band management of system (no EMS) using management VLAN 4003
Example
1 Set the system identifier, and configure the network VLAN EtherType:
configure system id FTTU1 name Alcatel-Lucent location 600 March Rd
contact-person John x1112
configure system ether-type 8100
Note — If you reset the NT card or the 7342 ISAM FTTU, the date
and time are also reset.
2 Set the date and time manually (not using SNTP):

SET-DAT:FTTU1::::03-31-07,13-34-00;
3 Set up synchronization to local clock:

ED-SYNCN::CLKSRCNT::::SRCSELSCH=LOC;
4 Verify that the correct software versions are loaded on the NT unit:
RTRV-MEM::OSWP-1::;
5 Set the IP address of the default IP router to none, as EMS will not be used to
manage system, and the bridge MAC address:
SET-NE-ALL:FTTU1:COM::::DEFROUTER=NONE,
LANXMAC=00-0e-86-10-a8-34;
6 Reset the system without self-test to allow the bridge MAC address to be used
for layer 2 operations, such as RSTP.
INIT-SYS:FTTU1:SYSTEM:::2;

7 Configure the management interface for in-band management:

DLT-IPPORT::NTENET;
ENT-IPPORT:FTTU1:NTENET::MANUAL:IPADDR=192.16.0.1,
NETMASK=255.255.255.0;
8 Set the system-level VLAN parameters at the NT including global tagging mode
of SHub VLANs and aging timer for learned MAC addresses:
configure vlan shub dual-tag-mode
configure bridge-shub ageing-time 7200
9 Set the system-level VLAN parameters at the LT:

SET-PONVLANSYS:FTTU1:COM::::AGEING=10,ARPTBLREFRESH=120,TNDVLAN=3
999,BRCMVLAN=3998,OWLAN=0;
10 Configure the system management VLAN 4003, attach it to network port 1,

specify the management VLAN on the SHub side, and activate the management
VLAN:
configure vlan shub id 4003 mode residential-bridge name management
up-info-rate 10000 down-info-rate 10000 flooding disable no
user-user-comm priority-bits 5
configure interface shub port 1 port-type network mode automatic

upstream-bw-th 90 downstream-bw-th 90 admin-status up
configure vlan shub id 4003 egress-port network:1
configure vlan shub id 4003 untag-port 1
configure bridge-shub port 1 pvid 4003
configure system en-snmp-auth-trap ether-shape-rate 128

mgnt-vlan-id 4003
configure interface shub vlan-id 4003 mtu 1500 admin-status up
admin software-mngt shub database save
11 Specify VLAN 4003 as the management VLAN on the NT side using TL1:
SET-PONVLANSYS:FTTU1:COM::::MGMTVLAN=4003;
12 Ping the IP address for the 7342 ISAM FTTU:

ping 192.16.0.1 no timeout tries 10 mtu-size 500
13 Back up the NT and SHub databases, and verify the database upload status:
UL-DB:::::tftp_server_ip,7342/backups/dm.tar,AOSWPACTUAL
REPT-OPSTAT-DBUL;
14 Configure system-level IGMP parameters; see Configuring IGMP proxy in this

chapter.
15 STOP. This procedure is complete.

Configuring out-of-band management

The following shows an example to configure network management for out-of-band
management.
Example
1 Delete the default IP address that the GPON system has configured. The default
IP address must be deleted before a new IP address can be entered.
Note — With older GPON releases, if the default router is defined,
the system prevents the IP address from being deleted. Therefore, the
default router must be set to NONE before a deletion can be
performed. Set the IP address of the default router to NONE using the
TL1 command SET-NE-ALL.
DLT-IPPORT::ACUENET;
2 Configure out-of-band IP address using the value ACUENET as the aid.

SET-NE-ALL::DEFROUTER=192.16.0.254;
ENT-IPPORT:FTTU1:ACUENET:::MANUAL:IPADDR=192.16.0.1,NETMASK=255.2
55.255.0;
Configuring SNMPv2
The following shows an example to configure SNMPv2 to be managed by
5520 AMS from any IP address.
Example
1 Configure SNMPv2. The SNMPv2 requires the configuration of community and
shub community strings:
configure system security snmp community ASAM host-address
0.0.0.0/0
configure system security snmp shub community 1 name LANX ip-addr

0.0.0.0 privilege read-write
configure system security snmp community LANC host-address

0.0.0.0/0 context shub privilege read-write
Configuring SNMPv3
The following shows an example to configure SNMPv3.

Example
1 Configure SNMPv3. SNMPv3 requires the configuration of user, group, privacy
and authentication information:
configure system security snmp user gponuser authentication
sha1:plain:gponuser privacy des:plain:gponuser
configure system security snmp group gponuser security-level

privacy-and-auth context all map-user-group gponuser group-name
gponuser
P-OLT equipment configuration

This section provides an example to configure P-OLT equipment, including:
• ACU card, LT cards, and PONs
• interfaces
Configuring ACU card, LT cards, and PONs

The following provides an example of the configuration of the ACU card, LT cards,
and PONs using the parameter values described in Table 25-8.
Table 25-8 P-OLT equipment parameter values
Equipment Parameter values
ACU card on rack 1, shelf 1 • aid ACU-1-1

• equipment type of AACU-C
• power up
• in service
LT cards in slot 1 and slot 2 on rack • aid LT-1-1-1 and LT-1-1-2 respectively
1, shelf 1 • equipment type of GLT4-A
• power up
• in service
PONS 1 to 4 on LT cards 1 and 2 • aids PON-1-1-1-1 through PON-1-1-1-4, and PON-1-1-2-1

through PON-1-1-2-4 respectively
• FEC disabled
• in service
Example
1 Configure the ACU card.
ENT-EQPT::ACU-1-1:::AACU-C:LSMPWR=UP:IS

2 Plan the LT cards 1, 2, and 10:

ENT-EQPT::LT-1-1-1:::GLT4-A:LSMPWR=UP:IS
3 Install the LT cards.

4 Set the administrative state of the four PONs to active on LT 1 and LT 2 and eight
PONs on LT10:
ED-PON::PON-1-1-1-1&&4::::FECDN=DISABLED:IS
Note — When the LT card is created, all PONs are auto-created in an

administrative down state. The PONs must be activated.
Configuring interfaces
The following provides an example to configure network ports 1 and 2.
Example
1 Configure network ports 1 and 2 in an administrative state of up:
configure interface shub port 1 port-type network admin-status up
IGMP and multicast configuration

This section provides an example to configure IGMP and IP multicast. The following
configurations apply:
• IGMP proxy facilities on the NT and LT
• multicast VLANs
• multicast sources
• multicast bandwidth
Configuring IGMP proxy

The following provides an example of the configuration of the IGMP proxy facilities
on the NT and the LT.

Example for IGMP proxy on NT

1 Start up IGMP proxy facility on the NT:
configure igmp shub igs-system proxy-state start
2 Specify the VLAN IP interface address as the system-level source IP address to

be used in IGMP messages that are generated and sent out to the LT or to the
network:
configure igmp shub igs-system self-ip-addr-mode from-ip
Note — Steps 3 to 7 are optional. The IGMP proxy on the NT can run
with default values.
3 Specify the level of trace statements that are allowed:

configure igmp shub igs-system trace-selection 129
4 Specify the time interval after which the router port (network side) and host port
(LT side) entries are purged:
configure igmp shub igs-system router-purge-intv 125
configure igmp shub igs-system host-purge-intv 600
5 Specify the maximum number of multicast groups entries that the SHub can learn
for CAC:
configure igmp shub igs-system max-mcast-learn 1024
6 Disable global leave message:

configure igmp shub igs-system no glb-leave
7 Specify, at the system level, the time in seconds in which the LT must respond
to an IGMP query from the SHub:
configure igmp shub igs-system reduced-resp-int 125
8 Enable IGMP proxy on the NT:

configure igmp shub igs-system proxy-mode enable
9 Save configuration:

Example for IGMP proxy on LT

1 Start up IGMP proxy facility on the LT:
SET-PONIGMPSYS::COM::::QUERYINT=125,QMAXRESTIME=100,ROBUSTNESS=2,
GSQSPACING=10,NOANSQUERY=2,LMMAXRESTIME=2,CHECKSUM=FALSE,UNSOLICI
TRPT=0,CAPMAXNUMGRP=1024,MAXNUMUNCONFIG=0,CAPCFGSRCRSVTM=125,CAPU
NCFGSRCRSVTM=0,SRCIPADDR=0.0.0.0,MODE=STDPROXY,USERCVLANDEF=0,USE
RPRIDEF=0,DATACVLANDEF=4095,DATAPRIDEF=4095,NETWCVLANDEF=0,USERVE
RSIONDEF=V2,NETWVERSIONDEF=V2,NUMV3RECSDEF=128,ONTSIG=DISABLED;

This section provides an example to configure two multicast VLANs:
• Multicast VLAN 40 will carry the following multicast streams from one NSP
from network port 2 to PON 1 on LT 2.
• IP multicast group 239.192.0.1
• Multicast VLAN 41 will carry the following multicast streams from a second
NSP from network port 2 to PON 1 on LT 2.
Example
1 Ensure that network port 2 is configured; see Configuring interfaces in this
chapter.
2 Configure VLAN 40 and 41 in RB mode on the SHub, and associate the VLANs
with network port 2 and with LT 2:
configure vlan shub id 40 mode residential-bridge
configure vlan shub id 40 egress-port lt:1/1/2
3 Configure the network ports as router ports, and verify their status:
configure igmp shub vlan-router-port 40 network-port 2
configure igmp shub vlan-router-port 41 network-port 2
show igmp shub vlan-router-port 41 network-port 2
show igmp shub vlan-router-port 41 network-port 2

4 Enable IGMP signaling between the NT and the network edge router for VLANs
40 and 41:
configure igmp shub vlan-filter 40 snoop-filter disable
configure igmp shub vlan-filter 41 snoop-filter disable
configure igmp shub vlan-filter 40 network-signaling enable
configure igmp shub vlan-filter 41 network-signaling enable
5 Configure an IP interface for the multicast VLANs, and specify that the system
uses the IP interface of the VLAN as the source IP address for IGMP messages
that are sent out to the network or to the LT on the VLAN:
configure interface shub vlan-id 40 admin-status down
configure interface shub ip 40 ip-addr 172.22.40.11/24
configure interface shub ip 41 ip-addr 72.22.41.11/24
configure interface shub vlan-id 40 admin-status auto-up
configure interface shub vlan-id 40 admin-status auto-up
configure igmp shub vlan-filter self-ip-addr-mode inherit-ip-intf
Note — The IP interface address is designated as the source IP

address for IGMP messages that are generated by the IGMP proxy
facility; see step 2.
6 Configure the time for the LT to respond to a last leave query from the IGMP
proxy on the NT:
configure igmp shub response-timer 104 leave-rsp-timer 3
7 Specify IGMP version 2 for the VLANs:

configure igmp shub vlan-filter 40 vlan-version igmpv2
configure igmp shub vlan-filter 41 vlan-version igmpv2
Note — Steps 8 to 11 are optional, if default values are sufficient.

8 Enable the generation of IGMP queries for the VLANs and configure the related
parameters:
configure igmp shub vlan-filter 40 querier enabled
configure igmp shub vlan-filter 40 query-int 40
configure igmp shub vlan-filter 40 no retry-count
configure igmp shub vlan-filter 41 querier enabled
configure igmp shub vlan-filter 41 query-int 40
configure igmp shub vlan-filter 41 no retry-count
9 Configure unsolicited membership report parameters, which is sent when a host

joins a multicast group:
configure igmp shub vlan-filter 40 robustness 1
configure igmp shub vlan-filter 40 unsolicit-rpt-int 10
configure igmp shub vlan-filter 41 robustness 1
configure igmp shub vlan-filter 41 unsolicit-rpt-int 10
10 Specify the p-bit for the IGMP proxy facility to use to tag IGMP joins, leaves,
and messages, which it generates and sends out to the network, with their
S-VLAN tag (outer tag). The IGMP proxy facility uses the SHub VLAN ID.
configure vlan shub id 40 priority-bits 6
configure vlan shub id 41 priority-bits 6
11 Specify the VLAN ID and p-bit for the IGMP proxy facility to use to tag IGMP
joins, leaves, and messages, which it generates and sends out to the network, with
their C-VLAN tag (inner tag). For an unstacked VLAN, specify none:
configure vlan shub id 40 c-vlan no c-vlan no c-vlan-priority
configure vlan shub id 41 c-vlan no c-vlan no c-vlan-priority
12 Save the configuration in the SHub database:

13 Create the PON VLAN for VLANs 40 and 41:

ENT-PONVLAN::PONVLAN-40::::MODE=RBRIDGE,SPBITMODE=COPY,SPBITUS=0,
FWDMCBYCVLAN=DISABLED,DHCPRELAY=DISABLED,TAGMODE=UNSTACKED,USGBW=
28000000,DSGBW=28000000,USOBF=75,DSOBF=75;
FWDMCBYCVLAN=DISABLED,TAGMODE=UNSTACKED,DHCPRELAY=DISABLED,USGBW=
28000000,DSGBW=28000000,USOBF=75,DSOBF=75;

Configuring multicast sources

The following provides an example to configure dynamic multicast sources on the
LT using the parameter values described in Table 25-9:
Table 25-9 Multicast source parameter values
Multicast source Parameter values
IP multicast group 239.192.0.1 from NSP 1 • peak rate of 2500 kb/s

• sustained rate of 2500 kb/s
• multicast VLAN ID 40
IP multicast group 239.192.0.2 from NSP 1 • peak rate of 4000 kb/s

IP multicast group 239.192.1.1 from NSP 2: • peak rate of 2500 kb/s

IP multicast group 239.192.1.2 from NSP 2: • peak rate of 4000 kb/s
Example
1 Configure multicast packages:
ED-PONIGMPPKG::1::::PACKAGENAME=Low_def_Pkg;
ED-PONIGMPPKG::2::::PACKAGENAME=High_def_Pkg;
2 Configure the multicast sources on the LT:

ENT-PONMCSRC::PONMCSRC-239.192.0.1::::SRCNAME=,SVCNAME=,PEAKRATE=
2500,SUSTAINRATE=2500,VLANID=40,MCTYPE=DYNAMIC,MEMBERSHIPDEC=1,ME
MBERSHIPDUR=,PREVDUR=,MAXPREV=,BLKOUT=;

Reserving multicast bandwidth on the PON

The following provides an example of reserving bandwidth for multicast on PON 1
on LT 2 using the following parameter values:
• aid PON-1-1-2-1
• maximum bandwidth of 300000 kb/s
Example
1 Set the bandwidth for multicast on PON 1 on LT 2:
SET-PONMCBW::PON-1-1-2-1:::300000;
2 STOP. This procedure is complete
ONT equipment configuration

This section provides an example of the configuration of the following ONT
equipment, as shown in Figure 25-11, using the parameter values described in
Table 25-10:
• ONT 2 under PON 1 on LT 2
• ONT card 1 (Ethernet)
• ONT card 2 (VoIP)
Table 25-10 ONT equipment parameter values
Multicast source Parameter values

ONT 2 under PON 1 on LT 2 • aid ID ONT-1-1-2-1-2
• no battery backup
• accumulation interval of 8000 frames
• ONT description 1 and 2 of null
• provisioned version number of *
• serial number of ALCL12345678
• SLID of wildcard (not used)
• planned software version of 3FE50782BFNA08
• FEC disabled
• rogue ONT defence behavior of automatic
• port-to-port communication disabled
• per-service downstream rate limiting disabled
• collection of optical measurements disabled
• in service
ONT card 1 • aid of ONTCARD-1-1-2-1-2-1

• card type of 10/100 Base-T
• in service
ONT card 2 • aid of ONTCARD-1-1-2-1-2-2

• card type of POTS
• in service

Example
1 Ensure that LT card 2 and PON 1 are configured; see P-OLT equipment
configuration in this chapter.
2 Create ONT 2 under PON 1 on LT 2:
ENT-ONT::ONT-1-1-2-1-2::::BTRYBKUP=NO,BERINT=8000,
DESC1=NULL,DESC2=NULL,PROVVERSION=*,SERNUM=ALCL12345678,SUBSLOCID
=WILDCARD,SWVERPLND=3FE50782BFNA08,FECUP=DISABLE,ONTENABLE=AUTO,P
2PENABLE=DISABLE,RATELIMITOPT=DISABLE,OPTICSHIST=DISABLE,DLSW=DIS
ABLED:IS
3 Set the card type of the first ONT card, and activate it:
ENT-ONTCARD::ONTCARD-1-1-2-1-2-1:::10_100BASET::IS
Note — Installed ONT cards are learned by the ONT, but they are not
auto-created. You must specify the type of ONT card, and activate the
ONT card. The number and type of ONT cards vary per ONT type.
An alarm is raised if the card type does not match what the ONT is
reporting.
4 Set the card type of the second ONT card, and activate it:
ENT-ONTCARD::ONTCARD-1-1-2-1-2-2:::POTS::IS
VLAN configuration
This section provides an example of the configuration of an S-VLAN on the SHub
and on the LT. The S-VLAN will be used to carry the subscriber services from the
network to the PON.
Configuring SHub VLAN

The SHub VLAN has these parameter values:
• VLAN ID 10
• residential-bridge mode
• DHCP enabled
• connected to network interface port 1 and LT cards 1 and 2, as shown in
Figure 25-12
Figure 25-12 SHub VLAN
NT to LT card 1
Network SHub
port 1 VLAN 10
NT to LT card 2
21369

Example
1 Configure network port 1 in an administrative state of up:
2 Configure the SHub VLAN 10 in RB mode:

3 Associate the SHub VLAN 10 with network port 1:

4 Associate the SHub VLAN 10 with LT 1 and LT 2:

5 Configure VLAN 10 for DHCP on the SHub; see Configuring DHCP on the
SHub in this chapter.
Configuring PON VLAN

The equivalent VLAN on the LT has these parameter values:
• VLAN ID 10
• residential-bridge mode
• p-bit copy mode of copy
• stacked tagging mode
• DHCP enabled with circuit ID set to physical address of the circuit on which host
is connected
• upstream and downstream committed information rate of 28 000 000 kb/s
• forwarding of untagged BPDUs disabled
Example
1 Configure the equivalent VLAN 10 on the LT:
ALLOWUNTAGDS=ENABLED,CPBITDS=0,FWDMCBYCVLAN=DISABLED,NAME=,DHCPRE
LAY=ENABLED,TAGMODE=STACKED,PPPOERELAY=DISABLED,OPTION82CID=PHYAD
DR,OPTION82RID=NONE,USGBW=28000000,DSGBW=28000000,USOBF=75,DSOBF=
75,L2CNTRLFR=DISABLED;
2 Configure the PON VLAN for DHCP; see Configuring DHCP on the LT in this
chapter.

DHCP configuration
The following provides an example to configure S-VLAN 10 for DHCP. The
example assumes that S-VLAN 10 is created on the SHub and the LT;
see Configuring SHub VLAN and Configuring PON VLAN respectively in this
chapter.
Configuring DHCP on the SHub

The example has these parameter values:
• VRF 2 with name DHCP_VRF2, which is associated with VLAN 10
• DHCP server with IP address 143.209.14.50 and name DHCP_SERVER for
VRF 2
• VLAN 10 with IP address of 172.22.178.123 and prefix length 24
Example
1 Configure VRF 2 on the SHub:
configure ip shub vrf 2 name DHCP_VRF2
modeandcommstatus slow-path-mode zero-ttl drop
2 Associate VLAN 10 with VRF 2, and configure an IP interface for VLAN 10:
configure interface shub ip 10 vrf-id 2
configure interface shub ip 10 ip-addr 172.22.178.123 prefix-length

24
configure interface shub vlan-id 10 admin-status up
3 Enable the DHCP relay agent on the SHub.

configure dhcp-relay shub relaying relaying
4 Specify the DHCP server for VRF 2:

configure dhcp-relay shub server ip-address 143.209.14.50
server-name DHCP_SERVER
5 Configure and enable the DHCP relay agent to VRF 2:

configure dhcp-relay shub agent 2 agent-ip-addr 172.22.178.123
configure dhcp-relay shub agent 2 relaying relaying
configure ip shub vrf 2 route-dest 0.0.0.0/0 next-hop

172.22.178.254 vlan-id 10 metric 1
6 Save the configuration in the SHub database:


Configuring DHCP on the LT

The example enables DHCP on PON VLAN 10 with circuit ID set to physical
address of the circuit on which the host is connected.
Example:
1 Configure the PON VLAN for DHCP:
ED-PONVLAN::PONVLAN-10::::DHCPRELAY=ENABLED,
OPTION82CID=PHYADDR,OPTION82RID=NONE
HSI service with IGMP signaling channel configuration

This section provides an example of the configuration of an HSI service with an
IGMP signaling channel, using the parameter values described in Table 25-11. The
service will be carried from the network to the PON in S-VLAN 10. The example
includes the configuration of the following entities as shown in Figure 25-11:
• QoS and marker session profiles
• Ethernet ONT UNI port
• Bandwidth profile
• HSI service
• IGMP signaling channel
Table 25-11 HSI service and IGMP signaling channel parameter values
Configuration entity Parameter values
HSI service • aid of HSI-1-1-2-1-2-1-1-1

• bandwidth profile ID 5
• priority queue profile ID 5
• AES encryption disabled
• service label subscriber_1_HSI
• S-VLAN ID 10
• in service
IGMP signaling channel • aid HSI-1-1-2-1-2-1-1-

• maximum bandwidth consumption of 24000 kb/s
• number of multicast streams allowed on the port of 10
• rate of 16 IGMP messages per second
• maximum number of hosts per stream of 4
• IGMP version 2
• system default C-VLAN and p-bit for IGMP queries and
multicast traffic
• ONT signaling disabled

Example
1 Ensure that the following configurations are complete:
• LT 2 and PON 1 on LT 2; see P-OLT equipment configuration in this chapter
• configuration of S-VLAN 10; see VLAN configuration in this chapter
• configuration of ONT 2 under PON 1 on LT 2, and ONT card 1; see ONT equipment
configuration in this chapter
• configuration of IGMP and IP multicast; see IGMP and multicast configuration in
this chapter
2 Create a QoS marker profile, which will be indexed by a QoS session profile. The
primary purpose of the QoS marker profile is to define the upstream and
downstream VLAN handling from ONT side:
Note — Because the subscriber is treated as an untrusted source:
• upstream frames on the ONT UNI will be tagged with the default
p-bit and C-VLAN of the ONT UNI
• downstream frames in the stacked S-VLAN will be stripped of
their outer tag
ENT-QOS-MARKPROF::5:::TEST_MARK:PROFTYPE=UNTRUSTED,DOT1P=0,UNTAGD
S=XMITNOTAG,UNTAGUS=USEDSCPBITS,PRITAGUS=USEDEFCVLAN,TPID=8100
3 Create a QoS session profile that indexes the QoS marker profile in step 2. This
QoS session profile will be used by the Ethernet ONT UNI port.
ENT-QOS-SESSPROF::5:::TEST_SESS:UPMARKPROFID=5,UPMARKPROFNM
4 Configure the first Ethernet port on ONT card 1:

ENT-ONTENET::ONTENET-1-1-2-1-2-1-1::::CUSTINFO=TESTUSER,
AUTODETECT=10_100BASETAUTO,CVLANDEF=5,SESSPROFID=5,SESSPROFNM=,MA
XMACNUM=8,PWROVERRIDE=FALSE,DSCPMAPPROFID=,DSCPMAPPROFNM=,ARPSEND
ERIP=ALLZEROS:IS
5 Create a bandwidth profile with 0 committed rate, and up to 100Mbps maximum

rate, and with a delay tolerance of 32. This profile is typical for so called best
effort service.
ENT-PROFILE-BW::5:::TEST_BW:CIR=0,AIR=0,EIR=100000,DT=32
6 Create a priority queue profile, that opens only one queue (first queue), and maps
all 8 p-bits into this queue. The profile places all upstream traffic, regardless of
the p-bit setting, in the first queue for processing.
ENT-PROFILE-PQ::5:::AllPbitsToQ0:PQ1WEIGHT=0,PQ2WEIGHT=256,PQ3WEI
GHT=256,PQ4WEIGHT=256,PQ5WEIGHT=256,PQ6WEIGHT=256,PQ7WEIGHT=256,P
Q8WEIGHT=256,DOT1P0PQ=1,DOT1P1PQ=1,DOT1P2PQ=1,DOT1P3PQ=1,DOT1P4PQ
=1,DOT1P5PQ=1,DOT1P6PQ=1,DOT1P7PQ=1,VERSION=1;

7 Create the HSI service on the first Ethernet port on ONT 2 under PON 1 on LT 2
using the parameter values in Table 25-11:
Note — An HSI service is needed to pass unicast IGMP signaling
messages (IGMP join and leave messages) from the subscriber to the
network, and IGMP signaling messages (IGMP membership query
messages) from the network to the subscriber.
ENT-SERVICE-HSI::HSI-1-1-2-1-2-1-1-1::::BWPROFUPID=5,BWPROFUPNM=,
BWPROFDNID=5,BWPROFDNNM=,PQPROFID=5,PQPROFNM=,AESENABLE=DISABLE,L
ABEL=,SVLAN=10,CUSTOMERID=,ETHERTYPE=UNUSED,UNISIDEVLAN=0,NETWORK
SIDEVLAN=0,IPANTISPOOF=ENABLED,IPANTISPOOFMAX=1,SCHEDSERVPROFDNID
=,SCHEDSERVPROFDNNM=:IS
8 Create the IGMP signaling channel using the parameter values in Table 25-11:
ENT-PONIGMPCHN::HSI-1-1-2-1-2-1-1-1:::MAXTOTMCBITRATE=24000,MAXNU
MGROUP=10,MAXMSGRATE=16,MAXNUMHOST=4,USERVERSION=2,USERCVLAN=4095
,USERPRI=4095,DATACVLAN=4095,DATAPRI=4095,PERMDEC=permdec,PREVPER
MDEC=,ONTSIG=disabled;
VoIP service configuration

This section provides an example of the configuration of a VoIP service using the
parameter values described in Table 25-12. The service will be carried from the
network to the PON in S-VLAN 10. The example includes the configuration of the
following entities as shown in Figure 25-11:
• bandwidth profile
• VoIP service
• POTS port (line)
Table 25-12 VoIP service parameter values
Priority queue profile Priority queue profile for VoIP service where voice signaling
traffic has p-bit 5 and voice bearer traffic has p-bit 6 with the
following characteristics:
• profile ID 4
• weight 1 for queue 1
• weight 2 for queue 2
• weight 256 (unused) for all others
• p-bit 0 to 5 is assigned to 2
• p-bits 6 and 7 assigned to queue 1
(1 of 2)

Voice service on ONT 2 under • aid VOIP-1-1-2-1-2-1

PON 1 of LT 2 on rack 1, shelf 1 • upstream and downstream bandwidth profile ID 36
• priority queue profile id 1
• AES encryption enabled
• service label of subscriber_1_VoIP
• S-VLAN ID 10
• IP address of 10.10.15.54
• network mask IP address of 255.255.255.0
• IP address of default router of 10.10.15.250
• IP address of the media gateway controller of 10.10.15.250
• IP address of FTP server of 0.0.0.0
• DHCP disabled
• UDP port of the media gateway controller 2944
• DSCP value for outgoing signaling and management packets
of 48
• VoIP mode of ANSI (GR-303 and GR-8) voice emulation
through H.248 with a gateway (ANSIH248)
• configuration file of ansi.xml
• planned configuration file of test
• client ID of ABCD.*
• customer ID ALU
• circuit ID of null
• in service
POTS port 1 on ONT card in slot • aid ID ONTPOTS-1-1-2-1-2-2-1

2 on ONT 2 under PON 1 of LT 2 • customer information of provisioning sample
in rack 1, shelf 1
• VoIP service ID of 1
• termination ID of line1
• DSCP value for outgoing bearer traffic of 46
• POTS power of 0
• call history enabled
• no power shedding override
• SIP message timeout count threshold of 0
• bearer packet loss threshold of 100
• excessive jitter threshold of 100
• gain value of 0 for received signal
• gain value of 0 for transmit signal
• in service
(2 of 2)
Example
1 Ensure that the following configurations are complete:
• LT 2 and PON 1 on LT 2; see P-OLT equipment configuration in this chapter
• configuration of S-VLAN 10; see VLAN configuration in this chapter
• configuration of ONT 2 under PON 1 on LT 2, and ONT card 2; see ONT equipment
configuration in this chapter
2 Create a bandwidth profile with fixed bandwidth of 600 Kbps, and a delay
tolerance of 8:
ENT-PROFILE-BW::36:::600kbps:CIR=600,AIR=600,EIR=600,DT=8;

3 Create a priority queue profile, that opens only two queues (first queue and
second) for bearer and signaling traffic, and maps first 6 p-bits into queue two
and last two p-bits into queue one:
ENT-PROFILE-PQ::4:::VOIP:PQ1WEIGHT=1,PQ2WEIGHT=2,PQ3WEIGHT=256,PQ
4WEIGHT=256,PQ5WEIGHT=256,PQ6WEIGHT=256,PQ7WEIGHT=256,PQ8WEIGHT=2
56,DOT1P0PQ=2,DOT1P1PQ=2,DOT1P2PQ=2,DOT1P3PQ=2,DOT1P4PQ=2,DOT1P5P
Q=2,DOT1P6PQ=1,DOT1P7PQ=1,VERSION=1;
4 Create the voice service:

ENT-SERVICE-VOIP::VOIP-1-1-2-1-2-1::::BWPROFUPID=36,BWPROFUPNM=,B
WPROFNID=36,BWPROFDNNM=,PQPROFID=4,PQPROFNM=,AESENABLE=ENABLE,LAB
EL=subscriber_1_VoIP,SVLAN=10,IPADDRLOC=10.10.15.54,NETMASKLOC=25
5.255.255.0,DEFROUTER=10.10.15.250,IPADDMGC=10.10.15.250,IPADDRMG
CSEC=0.0.0.0,IPADDRFTP=0.0.0.0,DHCP=DISABLE,PORTMGC=2944,VOIPDSCP
=48,VOIPMODE=ANSIH248,CONFIGFILE=ansi.xml,CLIENTID=ABCD.*,CUSTOME
RID=ALU,SERCRETID=1,SECRETK=1,SRCVLANID=0:IS;
5 Create the POTS line:

ENT-ONTPOTS::ONTPOTS-1-1-2-1-2-2-1::::CUSTINFO=ALU_in_Kanata,VOIP
SERV=1,TERMID=line1,POTSPWR=0,CALLHIST=enabled,PWROVERRIDE=FALSE,
SIPMSGTOTH=,BRRPKTLOSSTH=100,XJTTRTH=100,RXGAIN=0,TXGAIN=0:IS;

26.1 Overview 26-2
26.2 Network example for layer 2 CES over Ethernet on a business

ONT 26-2
26.3 Network example for layer 3 CES over IP pseudo-wire

SAToP 26-5
26.4 Structured and unstructured DS1 and E1 services handling for

Layer 2 CES over Ethernet 26-6
26.5 Jitter buffering, congestion handling, and alarms 26-8
26.6 CES clocking and synchronization 26-8
26.7 Configuring DS1 and E1 port parameters 26-9
26.8 Configuring CES PW services 26-11

26.1 Overview
This chapter provides information about how the 7342 ISAM FTTU performs circuit
emulation services (CES) encapsulation on DS1 and E1 TDM traffic for transport:
• as Ethernet layer 2 over the GPON using the Metro Ethernet Forum standard
MEF-8 payload structure and pseudo-wire (PW) technology. This is also known
as CESoETH
• as IP/MPLS layer 3 over the GPON using Structured Agnostic TDM over Packet
(SAToP) and pseudo-wire (PW) technology.
You can provision CES and the DS1 or E1 ports using a TL1 or an EMS management
session with the P-OLT. See the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI or the appropriate network management
operations and maintenance guide for configuration procedures.
Figure 26-1 shows the differences in how layer 2 and layer 3 CES services are
configured.
Figure 26-1 Layer 2 and layer 3 CES service configuration
Layer 2 CES PW Layer 3 CES SATOP
IWF IWF
TDM <-> MEF8 TDM <-> SAToP
ENT-SERVICE- ENT-SERVICE-
ENT-ONTCESUNI DS1/E1 CESoETH CESPW DS1/E1 SAToP CESOIPPW
RTP ENT-ONTCESUNI RTP
VLAN UDP
MAC IP ENT-ONTIPHOST
Ethertype VLAN ENT-SERVICE-
0x88d8 MAC CESOIPUNI
21983
26.2 Network example for layer 2 CES over Ethernet on a

business ONT
For layer 2 CESoETH, the business ONT supports two DS1 and E1 service
connections at the subscriber premises. The following TDM link types are supported:
• structured (fractional) DS1 or E1
• unstructured DS1 or E1
At the subscriber premises, the business ONT terminates DS1 or E1 links from the
subscriber. The TDM traffic is adapted and packetized using MEF-8 pseudo-wire
technology before being transported across the GPON. MEF-8 is the payload option
that is used. The MEF-8 packets are multiplexed with the Ethernet layer 2 data traffic
at the business ONT GPON port.
When the MEF-8 packets are received at the 7342 ISAM FTTU P-OLT that is
installed at the CO, the P-OLT forwards the packets to the destination PSTN,
typically via a G6 voice gateway that is connected to the IP network.

Figure 26-2 shows the network topology of DS1 or E1 CES encapsulated traffic from
the PSTN traversing the GPON via a voice gateway and 7342 ISAM FTTU P-OLT
on the CO side, and the business ONT at the customer premise. The
7342 ISAM FTTU and business ONT model can also support CES DS1 and E1
traffic from a 7250 Service Access Switch.
Figure 26-2 CES DS1 or E1 traffic between the ONT and PSTN over the GPON via the P-OLT
EMS
L2
DS1 or E1 GE Ethernet GE GPON
cloud DS1 or E1
Business
Class 5 PSTN Voice gateway P-OLT ONT
switch (G6)
DHCP server
18953
In the downstream direction, DS1 or E1 traffic from the PSTN is sent to the G6 voice
gateway, which performs Ethernet layer 2 encapsulation using the MEF-8 payload
format and sends the traffic out on to the Ethernet network to the 7342 ISAM FTTU
P-OLT. The LT card installed in the 7342 ISAM FTTU P-OLT forwards the packets
to the business ONT over the GPON. At the subscriber premises, the business ONT
de-encapsulates the packets and forwards the DS1 or E1 payload to the DS1 or E1
port, which is terminating the DS1 or E1 lines at the subscriber premises.
Service options
Table 26-1 describes the options supported for voice, data, and video services.
Table 26-1 Voice, data, and video service options
Service Options
Voice H.248/Megaco and session initiation protocol (SIP) between the ONT and
voice gateway or softswitch
Real-time transport protocol (RTP), user datagram protocol (UDP), Internet

protocol (IP), Ethernet, and expedited forwarding
Unbundling support using a G6 gateway
Data Point-to-point (PPP) and dynamic host configuration protocol (DHCP)
802.1X, remote authentication dial-in user service (RADIUS) for DHCP

Residential bridge and virtual local area network (VLAN) cross-connect modes
DHCP relay (Option 82), proxy address resolution protocol (ARP)
(1 of 2)

Service Options
Video Internet protocol over Ethernet (IPoE) and PPP over Ethernet (PPPoE)
Internet group management protocol (IGMP) v2 and v3, proxy and snoop
IPoE, class of service (CoS), assured forwarding

Expedited leave, fault isolation, performance management, cross-VLAN
multicast, Connection admittance control (CAC) on PON, and customer
channel limits
(2 of 2)
Table 26-2 describes the CES DS1/E1 features supported on the business ONT. The
business ONT supports the voice, data, and video service options described in
Table 26-1.
Table 26-2 Business ONT features
Item Specification
GPON interfaces Two IEEE 802.3 compliant, RJ-45 10/100/1000BASE-T Gigabit

Ethernet ports, half or full duplex, supporting multi-mode and
single-mode fiber.
For configurable modes, see 7342 ISAM FTTU P-OLT and ONT
Operations and Maintenance Procedures.
DS1/E1 WAN interfaces Two RJ-48C ports configured for 100 Ω DS1, 120 Ω balanced E1,
or 75 Ω unbalanced E1.
DS1/E1 CES over PSN IETF PWE3 pseudo-wire

MEF-8
DS1 standards AT&T TR-6421; ITU-T Rec. G.703, G.704

Structured, unstructured, and fractional DS1 support
E1 standards ITU-T Rec. G.703, G.704, G.706, G.732, G.823

Structured, unstructured, and fractional E1 support
Synchronization CES DS1/E1 Upstream: A 16.384 MHz local oscillator or a derived clock from
the GPON that is provided by the P-OLT (1).
Downstream: A 16.384 MHz adaptive clock received from the
PWE3 packet stream, and a differential clock recovered from the
PWE3 packet stream.
Gigabit A Gigabit Ethernet transmit reference clock of 125 MHz as per

Ethernet IEEE 802.3.
Management Local DB-9 serial craft port

Remote in-band management using TL1 or an EMS management
session with the P-OLT
SNMP MIB 1 and MIB 2 support
Quality QoS aware layer 2 switch per VLAN
Loopbacks and diagnostic tests Local, remote and packet loopbacks

Trace route and PING support
Note
(1) The downstream derived clock provided by the P-OLT is tied to the BITS clock and is traceable to
a network timing reference. The derived clock is used for differential clock recovery and for timing
the upstream PWE3 packet streams in the absence of a valid TDM recovery clock.

26.3 Network example for layer 3 CES over IP pseudo-wire

SAToP
SAToP is an encapsulation layer that carries TDM circuits over a packet switched
network. For layer 3 SAToP, the following TDM link types are supported:
• structured (fractional) DS1 or E1
• unstructured DS1 or E1
Figure 26-2 shows the network topology of DS1 or E1 CES encapsulated traffic from
the PSTN traversing the GPON via a voice gateway and 7342 ISAM FTTU P-OLT
on the CO side, and the far end device at the customer premises.
Figure 26-3 CES over IP DS1 or E1 traffic
EMS
L3 IP
DS1 or E1 GE cloud GE GPON
DS1 or E1
Supporting
Voice gateway P-OLT SAToP
DHCP server
21984
In the upstream direction, the flow is DS1 CES TDM DS1 or E1 traffic that is
encapsulated using RTP on the OLT. From the OLT, the TDM packets also get a
TCP/UDP header with a DSCP value. This then is encapsulated in IP and processed
by the VLAN, The traffic then flows through the MAC bridge and out the ANI side.
Service options
Table 26-1 describes the options supported for voice, data, and video services.
Table 26-3 Voice, data, and video service options
Service Options
Voice H.248/Megaco and session initiation protocol (SIP) between the ONT and
voice gateway or softswitch
Real-time transport protocol (RTP), user datagram protocol (UDP), Internet

protocol (IP), and expedited forwarding
(1 of 2)

Service Options
Data Dynamic host configuration protocol (DHCP)
802.1X, remote authentication dial-in user service (RADIUS) for DHCP
Residential bridge and virtual local area network (VLAN) cross-connect modes
DHCP relay (Option 82), proxy address resolution protocol (ARP)
Video IP
Internet group management protocol (IGMP) v2 and v3, proxy and snoop
IPoE, class of service (CoS), assured forwarding
Expedited leave, fault isolation, performance management, cross-VLAN

multicast, Connection admittance control (CAC) on PON, and customer
channel limits
(2 of 2)
26.4 Structured and unstructured DS1 and E1 services handling

for Layer 2 CES over Ethernet
Structured DS1 or E1 services emulate fractional services where the 1.544 Mb/s
DS1, or 2.048 Mb/s E1, bandwidth is subdivided in to DS0 64 kb/s channels.
Framing is used to group together multiple DS0s when the service is structured or
fractional. Unstructured services treat the full bandwidth of a DS1 or E1 link as
though it were one large channel, ignoring any framing.
CES encapsulation is a method of carrying TDM traffic in an Ethernet frame so that
there is minimal loss of quality. The 7342 ISAM FTTU can per form CES on the
TDM traffic received at the ONT DS1 or E1 port using the MEF-8 payload structure
for transport as Ethernet layer 2 packets over pseudo-wires (PW) or as IP layer 3
packets over IP.
The TDM payload, whether it is structured or unstructured, is treated as a bit stream.
The MEF-8 packets are multiplexed along with other Ethernet layer 2 data packets
at the ONT before being transported across the GPON.
Structured DS1/E1
Structured emulation takes the DS0 timeslots that are in a TDM frame and places
them in sequence into the MEF-8 payload structure of the packet. The existing
framing structure, such as the F bit for DS1, is removed.
Figure 26-4 shows how the CES interworking function (IWF) of the business ONT
converts structured TDM frames into MEF-8 packets.

Figure 26-4 Structured TDM frames encapsulated into CES MEF-8 packets
Packet 1 Packet 2 Packet L

DS0 Timeslot 1 DS0 Timeslot 1 DS0 Timeslot 1
DS0 Timeslot 2 DS0 Timeslot 2 DS0 Timeslot 2 Frame 1
Frame 1 Frame 2 Frame M in Packet L
DS0 Timeslot 1 DS0 Timeslot 1 DS0 Timeslot 1 DS0 Timeslot N DS0 Timeslot N DS0 Timeslot N
DS0 Timeslot 2 DS0 Timeslot 2 DS0 Timeslot 2 DS0 Timeslot 1 DS0 Timeslot 1 DS0 Timeslot 1
DS0 Timeslot 3 DS0 Timeslot 3 DS0 Timeslot 3 IWF Frame 2
DS0 Timeslot N DS0 Timeslot N DS0 Timeslot N in Packet L
DS0 Timeslot N DS0 Timeslot N DS0 Timeslot N
DS0 Timeslot 1 DS0 Timeslot 1 DS0 Timeslot 1
Incoming TDM Frames Frame M
in Packet L
DS0 Timeslot N DS0 Timeslot N DS0 Timeslot N
Outgoing Packets
18954
Unstructured DS1/E1
Unstructured emulation, which is also called structure-agnostic transport, disregards
any TDM framing structure and treats the TDM data as a stream of consecutive
octets. The number of octets that comprise each MEF-8 payload is independent of
the number of timeslots in each TDM frame. As such, any alignment of these octets
with the underlying timeslots is coincidental and is not guaranteed. The payload size
is typically chosen to make a packet formation time of approximately 1 msec. For a
DS1 circuit, this payload size is 192 octets, where an octet is an eight bit byte. For
E1, the payload size is 256 octets.
Figure 26-5 shows how the CES interworking function (IWF) converts unstructured
TDM octets in to CES MEF-8 packets.
Figure 26-5 Unstructured TDM traffic encapsulated into CES MEF-8 packets
Packet 1 Packet 2 Packet L

Octet 1 Octet 1 Octet 1
Octet 1 Octet 2 Octet N IWF Octet 2 Octet 2 Octet 2
Octet N Octet N Octet N
Incoming TDM Octets Outgoing Packets

18955
Payload size
In unstructured mode, the payload size is fixed at eight DS0 frames per MEF-8
packet. For DS1, the payload length is fixed at 192 bytes per frame. For E1, the
payload length is fixed at 256 bytes per frame. In structured mode, the payload length
is determined from the encapsulation delay setting, see section 26.8.
Note — The payload length for each DS0 frame in a MEF-8 packet is
0.125 ms.

26.5 Jitter buffering, congestion handling, and alarms
Jitter occurs when packets arriving from the network experience delays caused by
network congestion, packet routing, or timing drifts. A jitter buffer is used to manage
jitter. You configure the jitter buffer using a TL1 management session with the
P-OLT.
The jitter buffer is configured in the CES maintenance profile and is set in frame
units, where one frame unit equals 0.125 ms. Calculate the maximum jitter buffer
size to use as follows:
1.5 × payload length (in frames) × 0.125 ms = maximum jitter buffer (ms)
The minimum value for the jitter buffer is 1 ms. The maximum value is 200 ms. See
and CLI for configuration command descriptions.
Stray packets are discarded by the CE bound IWF. Malformed packets are detected
by a mismatch between the expected packet size, taking the value of the l bit in to
account, and the actual packet size inferred from the PSN and multiplexing layers.
The 7342 ISAM FTTU monitors the TDM streams for alarm conditions. An alarm is
raised in the system when an alarm condition persists for 2.5 seconds. The alarm is
cleared after the alarm condition is no longer detected for a period of 10 s. The
following CES pseudo-wire (PW) alarms can be raised:
• PWE Link Loss
• PWE LOSSREORDER
• PWE Malformed packets
• PWE Late Frames
• PWE Jitter Buffer Over-run
• PWE Jitter Buffer Under-run
The following CES port alarms are raised in the system:

• CES Loss Of Signal (LOS)
• CES AIS Received
• CES Loss Of Frame (LOF)
• CES RAI Received
26.6 CES clocking and synchronization
The same clocking reference at both ends of the DS1 or E1 link is required to meet
the wander requirements of TDM traffic.
The business ONT can use one of two clocking sources for CES: a derived GPON
clock at 16.384 MHz or a local oscillator. When the system clock for CES is derived
from the GPON, the upstream P-OLT locks to the BIT clock and supplies the ONT
with an Ethernet clock that is traceable to a network timing reference. The supplied
Ethernet clock is used for differential clock recovery and for timing the upstream
packet streams in the absence of a valid TDM recovery clock. The local oscillator is
only used if adaptive mode is selected.

The downstream TDM streams may be timed from one of two clocking sources: a
16.384 MHz adaptive clock received from the packet stream or a differential clock
recovered from the packet stream via the GPON. When the clock is received from
the GPON, you must configure the GPON to send RTP packets.
In adaptive timing, a local, free-running 25 MHz clock is used. The generated bit rate
is determined by the long-term average data rate. The DS1/E1 equipment that is
attached must be loop timed. In differential timing, a 16.384 MHz reference clock is
synchronized to the PON. Both ends of the DS1/E1 must use the same reference
clock frequency and be synchronized to a common source. RTP is used to transport
the transmit bit rate information. The DS1 or E1 equipment that is attached to the
terminating devices must be loop timed. In loop timing, the receive clock rate is used
for the transmit clock rate. The DS1/E1 equipment that is attached must be source
timed, not loop timed.
Timestamps within the packets are used for carrying timing information across the
network. Timestamp values are generated in differential format when the interface is
operating in differential timing reference mode. Otherwise, the timestamp values
represent absolute time.
You can add an RTP header to each packet for timing purposes and determine
whether or not to include the 4 byte control word immediately preceding the RTP
header. Configure RTP header parameters using a TL1 or an EMS management
session with the P-OLT. See the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI for configuration command descriptions.
26.7 Configuring DS1 and E1 port parameters
You can configure the following DS1 and E1 port parameters:

• framing mode
• framing type
• line encoding
• line length (DS1)
• line impedance (E1)
Configure the DS1 or E1 port at the business ONT or applicable end user device to
be compatible with the connected TDM link.
Note — You must configure both ports on the business ONT or
end-user device for the same type of service, either DS1 or E1. Do not
combine different TDM services.
Structured and unstructured framing mode

For each DS1 or E1 port, you can configure the framing mode as either structured or
as unstructured. Structured framing mode uses framing, whereas the unstructured
mode is without any framing. The default framing mode is unstructured. Make sure
that the type of framing used matches the framing mode you have configured for the
port.

Framing type
Framing is used to synchronize and extract individual channels from a structured
DS1 or E1 link. The framing you configure for the DS1 or E1 port at the business
ONT must be consistent with the framing mode that you configured for the port.
If the framing mode for the port is configured as unstructured, then you must
configure the framing type as unframed. When unframed is selected, all incoming
TDM data is treated like a bit stream.
Table 26-4 lists the framing types the business ONT supports. The available framing
types are only applicable if the business ONT DS1 or E1 port is configured as
structured.
Table 26-4 DS1 and E1 framing
Link type Framing
DS1 superframes
extended superframes
unframed (default)
E1 PCM 30
PCM 31
unframed (default)
For DS1 links, superframes consist of 12 DS0 64 kb/s timeslots that are combined in
to one superframe. An extended superframe consists of 24 DS0 64 kb/s timeslots
combined in to one extended superframe.
For E1 links using PCM 30 transmission, multiFrame alignment signal (MFAS) and
frame alignment signal (FAS) framing are used. Timeslots 1 through 15 correspond
to channels 1 through 15, and timeslots 17 through 31 correspond to channels 16
through 30. Timeslot 0 of every even frame is reserved for FAS and timeslot 16 is
reserved for MFAS and channel associated signaling (CAS).
For E1 links using PCM 31 transmission, only FAS framing is used. Timeslots 1
through 31 correspond to channels 1 through 31. Timeslot 0 of every even frame is
reserved for FAS.
Line encoding
Table 26-5 lists the line encoding types supported for DS1 and E1 links.
Table 26-5 DS1 and E1 line encoding
Link type Encoding
DS1 B8ZS
AMI (default)
E1 HDB3
AMI (default)

Binary 8 zero code suppression (B8ZS) prevents too many consecutive zeros from
being transmitted over the DS1 link. If an 8 bit sequence of zeros is detected, they
are replaced with a pre-determined sequence before being transmitted. When that
sequence is detected at the receiving end, it is replaced with 8 bits of all zeros.
Alternate mark inversion (AMI) line encoding is used to accommodate the ones
density requirements of DS1 and E1 lines. One bit out of eight is reserved as a control
bit. As such, AMI operates at 56 Kb/s rather than the full 64 kb/s for each DS0.
High-density bipolar-3 zeros (HDB3) is based on AMI and is similar to B8ZS. When
a sequence of four zeros in a row is detected, a substituted value is inserted that is
determined by the number of occurrences since the previous sequence was detected.
Line length and line impedance

The business ONT supports DS1, DSX-1, and E1 connections. Table 26-6 lists the
line lengths that are supported for DS1 and DSX-1 connections.
Table 26-6 Line lengths supported for DS1 and DSX-1
Link type Line length
DS1 7.5 dB
15 dB
22.5 dB
DSX-1 0-133 ft (default)

133-266 ft
266-399 ft
399-533 ft
533-655 ft
For E1 links, you can set the impedance for either 75 Ω or 120 Ω.
Note — An RJ-48C connector at the business ONT is used for DS1

and E1 connections. You may require a cable adapter to connect your
TDM line to the business ONT. Adapters are not supplied.
26.8 Configuring CES PW services
For each DS1 or E1 port you configure, you must create a CES pseudo-wire (PW)
service. See the 7342 ISAM FTTU Operations and Maintenance Procedures Guide
using TL1 and CLI for configuration command descriptions.


27.1 Overview 27-2

27.1 Overview
This chapter provides information about how the 7342 ISAM FTTU interacts with
the micro span component of Litespan circuit emulation service solution.
micro span is a product used to provide wideband services over an Ethernet link.
These service are carried across the Ethernet network. The network aggregates the
traffic, both Ethernet and PON. There are two elements in the solution:
• The MS-C configured in a Litespan slot in the central office
• the MS-R remote terminal, connected to an ONT at the subscriber site
To confine the traffic between the central office and the remote terminal, a VLAN is
used. The transport network between the MS-C and the MS-R uses Ethernet
switching based on the VLAN ID and the MAC addresses of the devices. See the
7342 ISAM FTTU ONT Product Information Manual CES interfaces chapter for
more information.
Figure 27-1 shows a micro span solution using a 7342 ISAM FTTU to transport CES
traffic across an Ethernet network.
Figure 27-1 Network example of micro span collocated with 7342 ISAM FTTU
Central Office
Litespan-2000/2012
Switched TDM
Special Services
GR-57, GR-303
Class 5
D4, DS1
DACS MS-C
DS1,
DC3, Ethernet
OC-x
ONT
PON Data Video
Ethernet POTS/VoIP
7450 ESS 7342 ISAM

FTTU Ethernet
ALARM, DDS
MS-R COIN, ISDN
DS1
Central Office B NMS Management for

Litespan and
7342 ISAM FTTU and ONTs
18933

In order to ensure the CES traffic is transmitted to and from the MS-C and MS-R, a
CES VLAN must be created that confines the traffic as it traverses the network. A
management VLAN is also used for communication between the MS-C and the
5520 AMS. Figure 27-2 shows a sample VLAN configuration.
Figure 27-2 CES VLAN example using micro span, 7342 ISAM FTTU, and ONTs
Litespan-2000/2012
MS-C VLAN 20
VLAN 10
W L
MS-C T T ONT
7450 ESS 7342 ISAM FTTU
Pre-provisioned with port-based

VLAN residential bridge for MS-R
each MC-C VLAN ID
MS-Rs added
to VLAN 10
18935
High-level workflow
The following is a high-level description of the workflow required to create a CES
network configuration that includes the 7342 ISAM FTTU and ONTs.
1 Provision and configure the MS-C and MS-R according to the appropriate
Litespan user documentation.
2 Connect an Ethernet cable from the ONT to the MS-R. The traffic is then
segregated. See the appropriate Litespan user documentation.
3 When using ONTs without Ethernet physical PLL, the network timing settings
on both ends of the CES should be set to adaptive.
4 Ensure the P-OLT and the ONT is configured to carry pbits for priority traffic
tagging. See the 7342 ISAM FTTU Operations and Maintenance Procedures
Guide using TL1 and CLI or the 7342 ISAM FTTU Operations and Maintenance
Using the 5520 AMS.
5 Configure the ONT to support transparent bridging. See the 7342 ISAM FTTU
Operations and Maintenance Procedures Guide using TL1 and CLI or the
7342 ISAM FTTU Operations and Maintenance Using the 5520 AMS.
6 Configure a CES VLAN across the Ethernet network for the micro span traffic;
for example, on the 7342 ISAM FTTU and the 7450 ESS. See the appropriate
equipment user documentation for VLAN configuration information.
7 When the CES VLAN is configured, the MS-C and MS-R create a CES
automatically.


28 — Ethernet services for business and
residential applications
28.1 Overview 28-2
28.2 Metro Ethernet services infrastructure 28-4
28.3 Ethernet virtual connection 28-6
28.4 EVC models 28-11
28.5 Constraints 28-17

28.1 Overview
This chapter provides high-level information about the implementation of Ethernet

services for business and residential applications in the 7342 ISAM FTTU.
Table 28-1 describes the functionality that is supported by the Ethernet services, and
optionally by traditional services such as standard HSI, VoIP, CES, and VDLS2. See
Table 28-1 Functionality supported by Ethernet services
Functionality Description Ethernet Traditional

services services
Single-tagged frames in a stacked VLAN This functionality applies to internal EVCs ✓

with all-to-one bundling; see Internal EVC
Transparent pass-through of untagged models for more information.
frames from the CPE
To implement, the ONT UNI must be
configured with the default value VLAN ID of
4095, and the S-VLAN configured in stacked
mode with single-tagged frames enabled.
Transparent pass-through of double-tagged This functionality supports wholesaling ✓

frames across the 7342 ISAM FTTU access services on the PON, and mixed business
network services such as point-to-point and xDSL.
This functionality applies to external EVCs;
see External EVC models for more
information.
VLAN pass-through mode at the LT and
flexible mode at the ONT allow both
single-tagged and double-tagged frames to
pass through simultaneously from the
network to the CPE and from the CPE to the
network. See Chapter 21 on VLANs and VPNs
GEM port per service The External EVC with T-CONT per CoS model ✓
supports multiple services for a single
subscriber, with a dedicated GEM port for
each service. In this model, traffic is directed
to a GEM port based on VLAN ID and p-bit.
Setting of p-bit in the outer S-VLAN tag to This functionality supports bundling of a ✓ ✓
a defined value while retaining the number of C-VLANS in a single S-VLAN for a
subscriber p-bit service provider.
You can specify the p-bit marking mode for a
Mapping of business traffic at the LT to the ✓ ✓
stacked S-VLAN on the PON; see Chapter
CoS in the aggregation network, while
Chapter 21 on VLANs and VPNs for more
retaining the subscriber p-bit
information.
Translation of the customer p-bit on the You can apply a Uni-side to network-side ✓
UNI side to its equivalent customer p-bit on p-bit translation profile to a flow; see
the network side at the ONT Chapter 18 on QoS and Chapter 21 on VLANs
and VPNs for more information.
Translation of the customer VLAN on the You can map the UNI-side C-VLAN to the ✓ ✓
UNI-side to its equivalent customer VLAN network-side C-VLAN for a flow or service;
on the network side at the ONT see Chapter 21 on VLANs and VPNs for more
information.
(1 of 2)

Functionality Description Ethernet Traditional

services services
Multiple cross-connect VLANs on the same This functionality applies to external EVCs; ✓
ONT UNI see External EVC models for more
information.
T-CONT sharing across multiple ONT UNIs This functionality obtains maximum ✓
on the same ONT for a single service subscriber scalability on the PON, and limits
MAC learning at the LT.
The T-CONT per service model allows
multiple subscribers of the same service to
share the same T-CONT; see Chapter 18
on QoS for more information. You can disable
MAC learning at the LT for S-VLANs that are
used in this scenario.
T-CONT sharing across multiple services on The T-CONT per EVC model allows multiple ✓
the same ONT UNI services for a single subscriber to share the
same T-CONT; see Chapter 18 on QoS for
more information.
T-CONT sharing across multiple services This functionality identifies different CoSs ✓
across multiple ONT UNIs on the same ONT between the P-OLT and the ONT in
cross-connect mode.
The T-CONT per CoS model allows multiple
services for different subscribers to share the
same T-CONT; see Chapter 18 on QoS for
more information.
Upstream segregation of single and A flow may be defined by any combination of ✓

double-tagged frames to GEM ports based VLAN ID, p-bits, and number of tags.
on the VLAN ID and p-bit in their outer tag The T-CONT per EVC model supports the
segregation of traffic into GEM ports by VLAN
ID, p-bit, and number of tags; see Chapter 18
on QoS for more information.
GEM port sharing across an UNI Multiple services on the same ONT UNI can ✓
share the same GEM port.
VLAN translation on incoming frame from The customer VLAN on the UNI-side can be ✓ ✓
CPE swapped for the customer VLAN on the
network-side, to support multiple EVCs on
the same ONT UNI; see Chapter 21 on VLANs
and VPNs for more information.
Bundling Bundling allows two or more C-VLANs on the ✓

same ONT UNI to be associated with a single
EVC (or S-VLAN).
Service-multiplexing can also be used with
bundling, and allows an ONT UNI to support
multiple EVCs (or S-VLANs).
See Internal EVC models for more
information.
All-to-one bundling All-to-one bundling occurs when every ✓

C-VLAN on the ONT UNI maps to a single EVC
(or S-VLAN).
See Internal EVC models for more
information.
(2 of 2)
These features are subject to constraints. For information about system and hardware
related constraints, see Section 28.5.
TL1 and CLI for business service related procedures.

28.2 Metro Ethernet services infrastructure
Figure 28-1 shows the model for Metro Ethernet services.
Figure 28-1 Metro Ethernet services model
CPE CPE
UNI Metro UNI
ethernet
network (MEN)
UNI
CPE
20028
A MEN is a computer network that is based on the Ethernet standard and covers a
metropolitan area. MEN is commonly used as a metropolitan access network to
connect subscribers and businesses to a WAN, such as the Internet. Large businesses
can also use Metro Ethernet to connect branch offices to their intranet.
The MEN contains one or more 7342 ISAM FTTUs that connect to a bridging device
such as 7450 Ethernet Service Switch, as shown in Figure 28-2.

Figure 28-2 Example of MEN
7750 SR 7750 SR
7450 ESS 7450 ESS

MEN
7342 GPON 7342 GPON
CPE CPE
UNI UNI
ONT ONT
20029
The CPE and MEN exchange Ethernet frames across the UNI. A UNI is a standard
Ethernet interface that is the demarcation point between the CPE and the
7342 ISAM FTTU access network. In the 7342 ISAM FTTU, a UNI is equivalent to
an ONT UNI port.
An Ethernet frame is a frame transmitted across the UNI to the network service
provider, or an Ethernet frame transmitted across the UNI to the subscriber. The
Ethernet frame consists of the first bit of the destination MAC address through the
last bit of the frame check sequence. Ethernet frames can be divided into two groups:
• data Ethernet frames
• L2 control protocol frames
A data Ethernet frame is one of the following:
• unicast Ethernet frame, which has a unicast destination MAC address
• multicast Ethernet frame, which has a multicast destination MAC address
• broadcast Ethernet frame, which has a broadcast destination MAC address

28.3 Ethernet virtual connection
The connectivity between the UNIs is specified by the Ethernet virtual connection
(EVC). An EVC is a logical association of two or more UNIs, and performs two
functions:
• connects two or more subscriber sites to enable the transfer of Ethernet service
frames between them, such as Internet data, business critical data, video, VoIP,
video conferences
• prevents the transfer of data between subscriber sites that are not part of the same
EVC. This capability enables an EVC to provide data security and privacy similar
to frame relay or ATM permanent virtual circuit (PCV).
Two rules govern the delivery of Ethernet frames over an EVC:

• the service frame should never be delivered back to the originating UNI
• the service frame must be delivered with the Ethernet MAC address and frame
content unchanged
Based on these characteristics, an EVC can be used to construct a L2 private line or

virtual private network (VPN).
EVC types
In Metro Ethernet services, there are three types of EVCs:
• point-to-point
• multipoint-to-multipoint
• rooted-multipoint
The EVC types are described in the following sections.
Point-to-point EVC
In a point-to-point EVC, exactly two UNIs must be associated with one another as
shown in Figure 28-2 and in Figure 28-3. A service frame from one UNI in the EVC
must only be delivered to the second UNI in the EVC. This type of EVC operates
similarly to a virtual circuit. It is an essential component of a service type known as
E-line.

Figure 28-3 Point-to-point EVC
CPE
UNI
20077
Multipoint-to-multipoint EVC
In a multipoint-to-multipoint EVC, two or more UNIs must be associated with one

another, as shown in Figure 28-4. Typically, a broadcast or multicast service frame
from one UNI in the EVC would be replicated in the MEN, and a single copy would
be delivered to each of the other UNIs in the EVC. This EVC creates a service that
behaves like a switched Ethernet environment. It is an essential component of a
service type known as E-LAN.
Figure 28-4 Multipoint-to-multipoint EVC
CPE
UNI
20078
Rooted-multipoint EVC
In a rooted-multipoint EVC, UNIs are designated as either a root or a leaf UNI.

Transmissions from a root UNI may be delivered to one or more of the other root and
leaf UNIs, and transmissions from a leaf UNI are delivered to only one or more of
the root UNIs. No communication can occur between leaf UNIs. Figure 28-5 shows
a rooted-multipoint EVC. This EVC can be used in environments that need a
hub-and-spoke communication arrangement without needing to configure multiple
point-to-point EVCs. It is an essential component of a service type known as E-tree.

Figure 28-5 Rooted-multipoint EVC
Root
UNI
Leaf UNI
Rooted-Multipoint EVC
20084
Implementation of EVC on the 7342 ISAM FTTU

Individual links of the EVC are implemented on one or more 7342 ISAM FTTUs as
separate S-VLANs. The upstream function to which the 7342 ISAM FTTUs are
connected, such as the 7450 ESS, bridges the links together using, for example,
VPLS. The upstream configuration determines the EVC type.
In the 7342 ISAM FTTU, a link of the EVC is generally configured in stacked
VLAN mode. However, the outer tag is added either internally or externally
depending on whether the EVC is an internal or external EVC:
• An EVC is an internal EVC when the EVC UNI originates on the
7342 ISAM FTTU, and is equivalent to an ONT UNI. In such cases, the S-VLAN
originates inside the 7342 ISAM FTTU, and the 7342 ISAM FTTU adds the
outer tag at the LT.
• An EVC is an external EVC when the EVC UNI is not equivalent to an ONT UNI
port, and the S-VLAN originates outside the 7342 ISAM FTTU at the CPE. For
an external EVC, the outer tag is added externally to the 7342 ISAM FTTU so
that the 7342 ISAM FTTU receives and transmits double-tagged frames.
In an EVC. the Ethernet services are configured in a two-level hierarchy: the portal
is the higher-level and the flow is the lower level. The two-level hierarchy supports
T-CONT sharing across multiple services and subscribers, which allows subscriber
scalability on the PON.
An EVC can be a single service that is carried to one or more subscribers, such as in
the case of multicast and broadcast, or an EVC can carry multiple services to a single
subscriber. The EVC is configured as an S-VLAN on the PON.
A portal is the equivalent of a T-CONT on a PON. Multiple EVCs can be aggregated
in a single portal, or an EVC can have a dedicated portal. The portal aggregates the
traffic from one or more flows on the same ONT, and specifies bandwidth
requirements on an aggregate basis.
The flow is the equivalent of a service or C-VLAN on the ONT UNI; each flow is
bound to one portal and one EVC. When bundling is used for an EVC, multiple
C-VLANs can be bundled in a single portal.
Figure 28-6 shows the relationships among the Ethernet service elements.

Figure 28-6 Ethernet service element relationships
PON
ONT
ONT CARD
ONT UNI
PORTAL FLOW
FLOW
PORTAL FLOW
FLOW
20030
Configuration elements
The following configuration elements are needed to configure a link of an EVC and
its Ethernet services on the 7342 ISAM FTTU:
• EVC
• S-VLAN
• optional C-VLAN to S-VLAN p-bit translation profile
• portal
• optional bandwidth profile
• optional per-service downstream rate-limiting scheduler
• flow
• optional bandwidth profile
• optional UNI-side to network-side p-bit translation profile
• ONT UNI, such as an Ethernet, VDSL2, or MoCA port
• QoS marker and session profile
Figure 28-7 shows the configuration of EVC and Ethernet services configuration.

Figure 28-7 EVC and Ethernet services configuration
EVC Portal Flow ONT UNI

S-VLAN (Bandwidth profile) (Bandwidth profile) QoS marker and
(C-VLAN to S-VLAN p-bit (Per-service downstream Priority queue profile session profile
translation profile rate-limiting scheduler) Uni-side to network-side DSCP to p-bit
p-bit translation profile mapping profile
GEM GEM
S-VLAN T-CONT Mapper Tagging
GEM GEM
Tagging Scheduler UNI
GEM GEM
S-VLAN DSRL Mapper Tagging
GEM GEM
20054
Table 28-2 describes each configuration element and the chapter in the
7342 ISAM FTTU Product Information Manual where the configuration element is
described in more detail.

Table 28-2 EVC and Ethernet service configuration elements
Configuration element Description See
EVC S-VLAN The S-VLAN is a VLAN on the PON. Chapter 21 VLANs and
VPNs
C-VLAN to S-VLAN p-bit The S-VLAN has a C-VLAN to S-VLAN p-bit Chapter 18 QoS
translation translation profile if the LT must translate
customer p-bits to NSP p-bits before
sending frames to the network.
Portal Bandwidth profile The bandwidth profile specifies the

bandwidth requirements for the services in
a portal. The bandwidth is profiled either
for a portal or for the individual flows in a
portal, but not for both.
Per-service downstream If the ONT is configured for downstream

rate-limiting scheduler rate-limiting on a per-service basis, a
per-service downstream rate-limiting
scheduler may be specified for the portal;
see Downstream hierarchical scheduler and
rate limiting.
Flow Bandwidth profile The bandwidth profile specifies the

bandwidth requirements of the flow. The
bandwidth is profiled either for the portal
or for the individual flows in a portal, but
not for both.
UNI-side to network-side p-bit A flow can specify a UNI-side to

translation profile network-side p-bit translation profile to
translate the customer p-bit on the UNI side
to its equivalent customer p-bit on the
network side.
Priority queue profile The priority queue profile defines the

mapping of p-bits to queues, and the weight
of each queue in the upstream. Each
priority queue is a GEM port.
ONT UNI port DSCP to p-bit mapping The ONT uses a DSCP to p-bit mapping to
priority-mark untagged IP traffic received
at an ONT UNI port from a trusted source.
QoS marker and session profiles The QoS session and marker profiles define
the tagging of traffic at the ONT UNI port.
28.4 EVC models
The 7342 ISAM FTTU supports four ways to configure a link of an internal EVC,
and two ways to configure a link of an external EVC. The configuration models are
described in the following sections.
TL1 and CLI for more configuration information.

Internal EVC models

An internal EVC has four configuration models:
• bundling and one CoS
• bundling and multiple CoSs
• all-to-one bundling and one CoS
• all-to-one bundling and multiple CoSs
The following definitions apply:

• Bundling allows two or more C-VLANs on the same ONT UNI to be associated
with a single EVC (or S-VLAN). With bundling, the provider and subscriber
must agree on the C-VLAN IDs used at the ONT UNI and the mapping between
each C-VLAN ID and a specific S-VLAN.
Service multiplexing can also be used with bundling, and allows an ONT UNI to
support multiple EVCs (or S-VLANs). Service multiplexing can only be used
with bundling.
• All-to-one bundling occurs when every C-VLAN on the ONT UNI maps to a
single EVC (or S-VLAN).
• A single CoS provides one portal per EVC (or S-VLAN). All traffic in the same
EVC is directed to the same portal.
• Multiple CoSs provide two or more portals per EVC (or S-VLAN). Traffic in the
same EVC is directed to one of the portals based on p-bits.
Internal EVC configuration considerations

The four internal EVC configuration models are described in the next sections, and
are based on the following considerations:
• An internal EVC with bundling and service multiplexing supports multiple EVCs
per UNI. An internal EVC with all-to one bundling supports a single EVC per
UNI.
• For internal EVCs, the LT must add the outer tag in the upstream direction, and
remove the outer tag in the downstream direction. The tagging behavior at the LT
corresponds to the VLAN tagging mode of stacked; see Chapter “VLANs and
VPNs” for more information about VLAN tagging modes.
• All-to-one bundling requires special consideration. At the subscriber side, the
all-to-one bundling models receive from and send to the CPE a mixture of
untagged, single-tagged, and double-tagged frames. At the network side, the
all-to-one bundling models receive from and send to the network a mixture of
single-tagged, double-tagged, and triple-tagged frames. As a result, the following
configurations are also required to support all-to-one bundling:
• Because of hardware limitations in handling triple-tagged frames, the all-to-one
bundling models must be configured in cross-connect VLAN mode; see
Chapter “VLANs and VPNs” for more information about cross-connect VLANs.
• To allow a single-tagged frame in a stacked VLAN, special configuration is required
to instruct the LT to allow an untagged frame across the PON in the downstream
direction, and to remove the outer C-VLAN tag before adding the S-VLAN tag in
the upstream direction, so that a singled-tagged frame is sent to the network;
see Configuration constraints for more information.

Internal EVC with bundling and single CoS
This configuration model, as shown in Figure 28-8, enables more than one C-VLAN
to be bundled in a single EVC under one CoS. All service flows in the EVC are
directed to the same portal.
Figure 28-8 Internal EVC with bundling and single CoS
Portal Flow
GEM GEM
S-VLAN Tagging T-CONT Mapper Tagging
GEM GEM
Scheduler UNI
GEM
DSPL Mapper Tagging
GEM
20032
The EVC is configured as a stacked S-VLAN in C-VLAN learning mode, and is

enabled for forwarding of broadcast and multicast frames. The EVC has a single
portal. For each C-VLAN that is bundled in the EVC, a flow is configured on the
ONT UNI port with a priority queue profile, and is attached to the portal.
Table 28-3 shows the basic steps that are required to configure an internal EVC with
bundling and single CoS. See the 7342 ISAM FTTU Operations and Maintenance
Procedures Guide using TL1 and CLI for more configuration information.
Table 28-3 Configuration for internal EVCs with bundling and single CoS
Network element Configuration requirements
EVC Create a PON S-VLAN with

• VLAN mode of C-VLAN learning
• tagging mode of stacked VLAN mode
• forwarding of broadcast and multicast frames
Portal Create one portal.
Flow For each C-VLAN to be bundled in the S-VLAN:

• Create a priority queue profile.
• Create a flow specifying a priority queue profile, and
associate the flow to a portal.
Internal EVC with bundling and multiple CoSs
This configuration model allows more than one C-VLAN to be bundled in a single
EVC under two or more CoSs. In this model, an EVC has a portal per CoS, and flows
are directed to a portal by p-bit.

The EVC is configured as a stacked S-VLAN in C-VLAN learning mode, and is

enabled for forwarding of broadcast and multicast frames. For each CoS, a portal is
created.
For each C-VLAN that is bundled in the EVC, a flow for each portal is created on
the UNI port with non-overlapping p-bits in the priority queue profile, and is
associated to the portal.
bundling and multiple CoSs. See the 7342 ISAM FTTU Operations and
Maintenance Procedures Guide using TL1 and CLI for more configuration
information.
Table 28-4 Configuration for internal EVCs with bundling and multiple CoSs
EVC Create a PON S-VLAN with:

• VLAN mode of C-VLAN learning
• forwarding of broadcast and multicast frames
Portal For each CoS:
Flow • Create a portal.

• Create a priority queue profile with p-bits unique to the
CoS.
• For each C-VLAN to be bundled in the S-VLAN:
• Create a flow specifying the priority queue profile, and
associate the flow to the portal.
Internal EVC with all-to-one bundling and single CoS
This configuration model, as shown in Figure 28-9, allows all C-VLANs on the same
ONT UNI to be bundled in a single EVC under one CoS.
Figure 28-9 Internal EVC with all-to-one bundling and single CoS
Portal
Flow
T-CONT
GEM GEM
S-VLAN Tagging Scheduler Mapper Tagging UNI
GEM GEM
DSPL
20031
The EVC is configured as a stacked S-VLAN in cross-connect mode. The EVC has
a single portal. A single flow, which specifies a default behavior for all C-VLANs,
is created on the ONT UNI, and is attached to the portal.

all-to-one bundling and single CoS. See the 7342 ISAM FTTU Operations and
information.
Table 28-5 Configuration for internal EVCs with all-to-one bundling and single CoS

• VLAN mode of cross-connect mode
Portal Create one portal.
Single flow Create a single flow, and associate the single flow to the
portal.
Internal EVC with all-to-one bundling and multiple CoSs
This configuration model enables all C-VLANs to be bundled in a single EVC under
two or more CoSs.
The EVC is configured as a stacked S-VLAN in cross-connect mode. The EVC has
one portal for each CoS.
For each portal, a flow is created on the UNI port with a priority queue profile with
non-overlapping p-bits, and is attached to the portal. Each flow defines a default
behavior for all C-VLANs.
all-to-one bundling and multiple CoSs. See the 7342 ISAM FTTU Operations and
information.
Table 28-6 Configuration for internal EVCs with all-to-one bundling and multiple CoSs

• VLAN mode of cross-connect

Flow • Create a portal.
• Create a priority queue profile with p-bits unique to the
CoS.
associate the flow to a portal.

External EVC models

An external EVC provides two configuration models:
• T-CONT per EVC
• T-CONT per CoS
An external EVC can simultaneously receive single and double-tagged frames from
CPE. The ONT is typically configured to process both, and to drop untagged and
priority-tagged frames.
External EVC with T-CONT per EVC
This configuration model provides a separate T-CONT for each EVC.

An EVC is configured as a cross-connect S-VLAN in VLAN pass-through mode. An
EVC has a single portal. A single flow is created on the ONT UNI with a priority
queue profile, and is attached to the portal.
Table 28-7 shows the basic steps that are required to configure an external EVC with
one T-CONT per EVC. See the 7342 ISAM FTTU Operations and Maintenance
Table 28-7 Configuration for external EVCs with one T-CONT per EVC

• VLAN tagging mode of VLAN pass-through mode
Portal Create a single portal, and associate the portal to S-VLAN.
Flow Create a priority queue profile for the flow.

Create a single flow specifying the priority queue profile, and
associate the single flow to the portal.
External EVC with T-CONT per CoS
This configuration model allows multiple EVCs to share the same portal by CoS.
Flows in the EVCs are grouped together in the same portal by p-bit.
Each EVC is configured as a cross-connect S-VLAN in VLAN pass-through mode.
For each CoS, there is a single portal that the EVCs share. For each EVC within a
CoS, a single flow is created on the ONT UNI with a priority queue profile, and is
attached to the portal.
Table 28-8 shows the basic steps that are required to configure an external EVC with
one T-CONT per CoS. See the 7342 ISAM FTTU Operations and Maintenance

Table 28-8 Configuration for external EVCs with one T-CONT per COS
EVC For each EVC that will share the T-CONT, create a PON S-VLAN
with:
• tagging mode of VLAN pass-through mode
Flow
• Create a single portal.
• Create a priority queue profile with p-bits unique to this
CoS.
• For each EVC within this CoS:
attach the flow to the portal.
28.5 Constraints
The following sections describe the system, hardware, and configuration constraints
for EVCs and Ethernet services.
System constraints
The following system constraints apply:
• An external EVC cannot have an IGMP signaling channel. An IGMP signaling
channel can only be associated with a flow that does not use double-tagged
frames at the UNI.
• An external EVC cannot use an ONT UNI that is configured for anti-spoofing.
ONT-based anti-spoofing can only be implemented on a port that does not use
double-tagged frames.
• An internal and external EVC can only be implemented on an ONT UNI that is
configured in the flexible mode.
• The flexible mode does not support per-service anti-spoofing.
• The flexible mode does not support Ethertype classification.
• LT-based IP anti-spoofing is not supported for GLT8-A LT card
Hardware constraints
GLT cards support Ethernet services for business and residential applications as
follows:
• The GLT8 and GLT4 supports all functionality for Ethernet services for business
and residential applications.
• The GLT2 does not support EVC models that require the C-VLAN learning
mode. These are EVC models that use bundling and service multiplexing (see
Section 28.4).

• The GLT2-A does not support internal EVCs (see Section 28.4), including the
following functionality:
• all-to-one tagging
• single-tagged frames in a stacked VLAN
• p-bit marking of upstream frames with a p-bit value specified for the S-VLAN
• p-bit translation of C-VLAN p-bit to S-VLAN p-bit
• The GLT2-A supports only the following functionality:
• double-tagged frame support from customers
• cross-connect without VLAN translation
• mapping of customer p-bits to provider p-bits
• control to pass or drop untagged non-BPDU frames
• control to pass or drop customer BPDUs
Table 28-9 lists the maximum number of portals that can be configured for GLT
cards and the overall maximum for the 7342 FTTU system.
Table 28-9 Maximum number of portals per GLT card and system
Description GLT2 GLT4 GLT8
Maximum 880 (440 * 2) 1760 (440 * 4) 3520 (440 * 8) (1)
portals per
GLT card
Maximum 31680 (1760 * 18): EHNT

portals per 63360 (3520 * 18): EXNT
system
Note
(1) The GLT8-A LT card is only supported by the EXNT-A NT card
Table 28-10 lists the ONT types that support Ethernet services implementations.
Table 28-10 Ethernet services support for ONT types
ONT type Ethernet services support Standard services support
GSFU (SOCv2.x) ✓ ✓
GSFU (SOCv1.x): − ✓
Package A (I-24x, I-040, B-0404-A) (1) ✓ ✓
Package B (I-x4xG-B) (1) ✓ ✓
MDU (O-00240V-A, O-0881V-A) ✓ ✓

MDU (O-2412x)
MDU (O-2412x) − ✓
M300 MDU − ✓

Note
(1) The Current Generation ONTs (I-24x, I-040, B-0404-A) must be enabled for port-to-port communication to support the
flexible mode; in this communication mode, a business service can only be configured on port 1, and the service is
replicated on the other enabled ONT UNI ports.
The Next Generation ONTs (I-x4xG-B) do not have to be in port-to-port communication to support the flexible mode, and
support business services separately on each of their 4 ONT UNI ports.
The Current Generation ONTs (I-24x, I-040, B-0404-A) do not support the
following:
• VLAN translation and VLAN pass-through on traffic that uses the same p-bit
across the same UNI
• downstream p-bit translation when the service is configured for VLAN
pass-through
The ONT UNI supports a VLAN tagging operation data table that is populated by an
EVC flow configuration command, based on the number of UNI-side p-bits
(multiplied by two if both single- and double-tagged frames are enabled for the flow
operation). An ONT UNI supports 16 entries and an MDU supports 32 entries.
Configuration constraints
Table 28-11 describes how to configure the 7342 ISAM FTTU to meet the specific
requirements of a particular EVC model.
Table 28-11 EVC configuration constraints
EVC configuration model Requirement Configuration

Internal EVC with bundling, Simultaneous pass-through of The PON S-VLAN must be configured with:
and one or more EVCs per singled-tagged, and optionally untagged • VLAN mode of C-VLAN learning
UNI (service-multiplexing) and priority-tagged frames from the CPE
in upstream direction • tagging mode of stacked VLAN mode
Simultaneous pass-through of untagged
• forwarding of broadcast and multicast
frames
and single-tagged frames in downstream
direction A service flow is configured for each C-VLAN
that is bundled in the EVC.
The QoS marker profile must be configured in
flexible mode and to:
• transmit untagged frames using default
p-bit for the port; the ONT will by default
tag the frame with the default C-VLAN ID
for the port
• overwrite priority-tagged frames with the
default C-VLAN ID for the port
The downstream tagging mode in the QoS

marker profile can be transmit to port with or
without a tag.
The default p-bit in the QoS marker profile
can be any value.
(1 of 2)

EVC configuration model Requirement Configuration
Internal EVC with all-to-one Simultaneous pass-through of untagged, The PON S-VLAN must be configured with:
bundling, and a single EVC priority-tagged, singled-tagged, and • VLAN mode of cross-connect mode
per UNI double-tagged frames in upstream
direction • tagging mode of stacked VLAN mode
Simultaneous pass-through of untagged,
• enabling of single-tagged frames in a
stacked VLAN
priority-tagged, singled-tagged, and
double-tagged frames in downstream The ONT UNI port must be configured with
direction the default C-VLAN ID of 4095.
The QoS marker profile for the ONT UNI must
be configured with flexible mode as the
upstream tagging mode, and transmit to port
with a tag as the downstream tagging mode,
and to:
• transmit untagged frames using default
p-bit for the port
• allow priority-tagged frames to pass
through
The default p-bit in the QoS marker profile

can be any value.
External EVC Simultaneous pass-through of The PON S-VLAN must be configured with:
singled-tagged and double-tagged frames • VLAN mode of cross-connect
from CPE in upstream direction
• tagging mode of VLAN pass-through mode
Simultaneous pass-through of
singled-tagged and double-tagged frames The QoS marker profile for the ONT UNI must
to CPE be configured with flexible mode as the
upstream tagging mode, and transmit to port
with a tag as the downstream tagging mode,
and to drop untagged and priority-tagged
frames.
(2 of 2)

29.1 Overview 29-2
29.2 GENIP service configuration elements 29-2

29.1 Overview
GENIP service is a special ONT service that lets you provision management channel
related parameters so that an ONT can be managed directly via an EMS. The ONT
must be an ONT general IP UNI, such as the 7353 ISAM FTTB ONU.
GENIP service allows you to create an SNMP service on the ONT using TL1, and it
allows configuration and retrieval of the IP host, IP service and SNMP parameters
using TL1 and SNMP through an SNMP management channel that you set up at the
P-OLT for the ONT.
Note — When GENIP service is provisioned for an ONT, no other

IP-based services, such VOIP service or CES over IP UNI service,
can be associated with the IP host on the ONT.
29.2 GENIP service configuration elements
The configuration of GENIP service includes configuration of the following

configuration elements:
• S-VLAN associated with the GENIP service
• QoS profiles for the associated GENIP service (upstream bandwidth profile,
downstream bandwidth profile, and priority queue profile)
• IP host bridge port:
• MAC address to be associated with the IP host bridge port
• IP address associated with the bridge port in the proxy ARP table on the LT
• GENIP service
• IP host on the ONT
• SNMP management channel for the ONT
Table 29-1 describes the configuration elements in more detail.
Table 29-1 GENIP service configuration elements
Configuration element Description
S-VLAN The SHub VLAN and the PON VLAN specify the service VLAN (S-VLAN)
in which the associated GENIP service is received and carried from
the NT to the LT, and from the LT to the PON respectively. An
S-VLAN is created on the NT as a SHub VLAN and the LT as a PON
VLAN with the same VLAN ID.
The SRC Vlan id (the VLAN ID that is to be used for tagging upstream
traffic of this general IP service) configured for the GENIP service
should be the same as the S-VLAN.
Upstream bandwidth profile This profile specifies the upstream bandwidth characteristics of a
service.
Downstream bandwidth This profile specifies the downstream bandwidth characteristics of

profile a service.
(1 of 2)

Configuration element Description
Priority queue profile The priority queue profile specifies the queues that are reserved for
a service in the upstream direction, and the size, weight, and the
p-bits of each reserved queue. The ONT directs a frame to a queue
based on the p-bit in the outer tag of the frame.
IP host bridge port This parameter associates the MAC address of the ONT with a bridge
port and is entered as a static entry in the VLAN forwarding
database.
This parameter associates the IP address with the bridge port in the
proxy ARP table on the LT
GENIP service Each GENIP service is configured for a single ONT that is an ONT
general IP UNI controlled by the 7342 ISAM FTTU.
ONT IP host An ONT IP host needs to be configured on top of the GENIP service
in order for the ONT to support an SNMP management channel.
SNMP management channel SNMP management channel that is set up at the P-OLT for the ONT.
(2 of 2)


Unit data sheets
30 — Index of unit data sheets
31 — AACU-C unit data sheet
32 — AFAN-H unit data sheet
33 — AFAN-S unit data sheet
34 — ALTS-N unit data sheet
35 — ATRU-M unit data sheet
36 — ATRU-N unit data sheet
37 — ATRU-U unit data sheet
38 — BITS-B unit data sheet
39 — Blank LT filler plate unit data sheet
40 — Blank NT filler plate unit data sheet
41 — EHNT and pluggable optical modules unit data sheet
42 — EXNT-A and pluggable optical modules unit data sheet
43 — FILT-A and FILT-B unit data sheet
44 — GLT2 unit data sheet

46 — GLT8 and pluggable optical modules unit data sheet
47 — LT card unit data sheet
48 — NT card unit data sheet
49 — OLT rack unit data sheet
50 — OLTS-M unit data sheet
51 — SANC-D unit data sheet
52 — Racks for video coupler unit data sheet
53 — Tyco video coupler subrack unit data sheet
54 — Tyco VCS8-A unit data sheet
55 — Tyco VCW4-A unit data sheet
56 — VCSL-A LGX unit data sheet
57 — LGX VCW2 unit data sheet

30.1 Overview 30-2
30.2 Unit data sheet overview 30-2
30.3 Index list of unit data sheets for 7342 ISAM FTTU 30-2

30.1 Overview
Table 30-1 lists the sections in this chapter that provide overview information about
unit data sheets for the 7342 ISAM FTTU.
Table 30-1 Overview of unit data sheets for the 7342 ISAM FTTU
Description Section
Unit data sheet overview 30.2
Index list of the unit data sheets for the 7342 ISAM FTTU 30.3
30.2 Unit data sheet overview
Unit data sheets provide detailed information about the major hardware units of the
7342 ISAM FTTU. The unit data sheets supplement the information provided
elsewhere in the documentation.
Unit data sheets typically provide the following types of information:
• identification
• features and application notes
• general description
• physical description, including an illustration and dimensions
• alarm LEDs
• interfaces and connections
• power supply
Many of the units used in the 7342 ISAM FTTU are used in more than one
Alcatel-Lucent product. The unit data sheets in this document describe the units as
they are used in the 7342 ISAM FTTU. For information about the units as they are
used in other products, see the unit data sheets that have been provided as part of the
documentation for the product.
30.3 Index list of unit data sheets for 7342 ISAM FTTU
Table 30-2 lists the unit data sheets according to part description.
Note — The shelf is referred to within these manuals by the term

Optical Line Terminal Shelf (OLTS), but ALTS-N or OLTS-M is the
name used for ordering.

Table 30-2 Alphabetical list of unit data sheets by description
Description Mnemonic Part number Chapter
Alarm control unit AACU-C 3EC 16687 AC 31
Battery filter adapter card FILT-A 3EM 17820 AA 43
Battery filter adapter card FILT-B 3FE 51428 AA 43

3FE 51428 AB
BITS access for optical NT BITS-B 3FE 51426 AA 38
Fan unit with filter AFAN-H 3EC 37533 AB 32
Fan unit with filter AFAN-S 3FE 51461 AA 33
GPON line termination with 2 PONs card 1 GLT2-A 3FE 50385 AA 44
GPON line termination with 2 PONs card 2 GLT2-B 3FE 51039 AA 44
GPON line termination with 4 PONs card 1 GLT4-A 3FE 51034 AA, AC, AG variants 45
GPON line termination with 4 PONs card 2 GLT4-D 3FE 53232 AA 45
GPON LT with 8 PONs card 1 GLT8-A 3FE 68218 AA 46
Ethernet high-capacity network termination EHNT-A 3FE 50479 AA 41

card 3FE 50479 AB
Ethernet high-capacity network termination EHNT-B 3FE 51196 AA 41

card
Ethernet XAUI based network termination EXNT-A 3FE 51230 AA 42

card
OLT shelf, version N ALTS-N 3EC 17542 AB 34
OLT shelf, version M OLTS-M 3FE 51410 AA 50
OLT rack — 3AP 60332 EB 49

3AP 60432 EB
3AP 60332 CB
3AP 60432 CB
3FE 51459 AA
3FE 51459 AB
Rack for video coupler, Tyco and LGX — 1AD 04674 0001 52
Synchronous ATM network combiner, SANC-D 3EC 17919 AA 51

version D, BITS and LAN access for optical
NT
Top rack unit, version M ATRU-M 3EC 17422 AA 35
Top rack unit, version N ATRU-N 3EC 17422 CD 36
Top rack unit, version U ATRU-U 3FE 51460 AA 37
Video coupler subrack, Tyco VCS 1AD 04675 0001 53
Video coupler WDM tray for 4 PONs, Tyco VCW4-A 3EM 15711 AA (tray pair) 55
3EM 15711 AB (left tray)
3EM 15711 AC (right tray)
Video coupler WDM with splitters tray for 8 VCS8-A 3EM 15711 AD (tray pair) 54
PONs, Tyco 3EM 15711 AE (left tray)
3EM 15711 AF (right tray)
(1 of 2)

Description Mnemonic Part number Chapter
Video coupler shelf, LGX compatible VCSL-A 3EM 11047 AA 56
Video coupler LGX WDM cassette, 2 PONs VCW2-C 3EM 11046 AC 57
(2 of 2)

31.1 Identification 31-2
31.2 Features and application notes 31-2
31.4 Alarm control function 31-4
31.5 Alarm LEDs 31-5
31.6 Interfaces and connections 31-6
31.7 Physical description 31-8

31.1 Identification
Table 31-1 provides identification information about the AACU-C.
Table 31-1 Identification of ACCU-C
Part number Mnemonic Description CLEI CPR ECI/Bar

code
3EC 16687 AB AACU-C Alarm control unit, VAUCABNKAA W73150 134652

version C
3EC 16687 AC AACU-C Alarm control unit, BVC1AAYFAA O7OLTJ 154790

version C
31.2 Features and application notes
The AACU-C card provides:

• alarm control functions for the P-OLT shelf that support CO alarm system,
telemetry alarm system, and rack alarms
• alarm cut-off (ACO) and LED lamp test button
• alarm LEDs
• audible alarm signals to the TRU (HTRU-F or AMP)
• connection to the TRU (HTRU-F or AMP)
• local craft interface
• one Ethernet port on the AACU
• one Ethernet port on the P-OLT backplane
• response to remote inventory request by the NT card
The AACU-C is a card that is installed in each P-OLT shelf. The AACU-C card
provides alarm control functions for the P-OLT shelf. The AACU-C card:
• collects up to two rack fan alarms, one TRU fuse alarm, and five miscellaneous
external alarms
• reports conditions of locally detected alarms
• reports of NT alarm conditions as set by the NT card, including NT loss of signal,
NT failure, and LT failure
• handles input and output alarm information
• generates alarm status indicators via relay contacts or Opto switches
• generates audible and visual telemetry signals

If any of the P-OLT components experience a fault, the AACU-C generates visual
and audible alarm signals and forwards the signals to the TRU. When the alarms are
generated, the LEDs on the AACU front panel displays the alarms according to the
level of severity, including critical, major, and minor. The AACU also generates
audible alarm signals to telemetry devices.
In addition to the audible alarm indicators and alarm LEDs, the AACU front panel
contains an ACO (audible cut-off) button, a local craft port, and an Ethernet port. The
ACO button can be used to extinguish the audible alarm. If the ACO button is
pressed for longer than 3 s., a lamp test starts. The local craft port is for OAM access.
The Ethernet port is for remote out-of-band OAM access or can also be used as an
Ethernet craft port.
The AACU-C connects to the TRU through a cable that connects the J64 connector
at the backplane of the P-OLT shelf and the J3 connector on the TRU.
The AACU-C responds to request from the NT card about its identification and
operating status for remote inventory. The information provided for remote
inventory includes product identification, manufacturer identification, and inventory
information.
Figure 31-1 shows the front and side views of the AACU.

Figure 31-1 AACU front and side views
31.4 Alarm control function
The AACU generates alarm signals related to the operation of the P-OLT shelf for:
• the CO alarm system
• the telemetry alarm system
• rack-level alarms
CO alarm system
The AACU supports a local CO alarm interface that provide visual and audible
minor, major, and critical alarms to the CO alarm system.

The AACU supports six discrete isolated alarm outputs: two for critical, two for
major, and two for minor alarms.
The critical alarm outputs are normally closed (power off) contact mechanical relays
that are held open during normal operation. If there is a loss of power, the relay is
released to notify the CO.
The AACU accepts an external ACO input that resets the audible alarm contact sets
to the non-alarmed state. The visual alarms remain on until the alarms are cleared.
Telemetry alarm system

The AACU provides a discrete telemetry alarm interface that provides visual and
audible minor, major, and critical alarms to the telemetry alarm system. The
telemetry alarm system consists of two contact sets for minor and major alarms and
one contact set for critical alarms.
The critical alarm outputs are normally closed (power off) contact mechanical relays
that are held open during normal operation. If there is a loss of power, the relay is
released to notify the CO.
The AACU accepts an external ACO input that resets the audible alarm contact sets
to the non-alarmed state. The visual alarms remain on until the alarms are cleared.
After activation, the telemetry alarms remain activated for a minimum of 20 s. to
ensure that the telemetry scanner has the time to detect the alarm.
Rack-level alarms
The AACU-C generates the following rack-level alarm inputs:
• 2 alarm inputs for the state of each fan unit
• a fuse alarm input for the fuse alarm from the TRU
• up to 5 miscellaneous alarm input
When any of the alarms described above occur, the AACU updates its alarm status
table. The ACCU-C reports the alarm status when polled by the NT.
31.5 Alarm LEDs
By default, the AACU-C generates a critical alarm output to the CO and telemetry
alarm systems when a poll by the NT fails for 12 s., which leads to an NT Poll Failure
event.
The AACU-C front panel has five LEDs. The CRI, MAJ, and MIN LEDs indicate
alarms associated with the P-OLT shelf. The ALM LED indicates the local alarms
associated with the AACU-C card. The ACO LED activates whenever the ACO
switch is pressed. The ACO switch serves two functions: one is to extinguish the
audible alarms and the other is to test the LED lamps. When the switch is pressed for
more than 3 s., the AACU-C lamps are lit until the ACO switch is released.
Table 31-2 describes the alarm LEDs.

Table 31-2 Alarm LEDs
LEDs Description Color display
CRI Critical Red
MAJ Major Red
MIN Minor Yellow
ALM Alarm local Red
ACO ACO active Green
31.6 Interfaces and connections
The AACU provides the following interfaces:

• TRU (HTRU-F or AMP)
• alarm input and output
• AACU OAM
• Ethernet OS port
• NT cards
Interface to the TRU

The connection to the TRU transmits alarm signals from the AACU to the TRU. The
connection is accomplished through the telephony connector that is located on the
backplane of the P-OLT shelf. This connector (J64) is linked via the alarm cable to
the alarms connector (J3) on the back of the TRU. Both connectors use the 50-pin
connector. For more information about the pin assignment of the connectors, see
7342 ISAM FTTU Hardware Installation and Maintenance Practices.
Interface for alarm input/output

The AACU has a top connector that connects the AACU with the P-OLT backplane.
The top connector provides an interface for the alarm input and output.
Interface for AACU OAM

The AACU provides one local craft interface on the front panel for OAM access. In
addition, the AACU provides one Ethernet port located on the front panel, and an
Ethernet port connected to the AACU on the P-OLT backplane.
Local craft port

The local craft interface uses a DB-9 connector that provides female pins with a male
shell. It is configured as DCE to communicate with a local DTE craft terminal.
Table 31-3 describes the pin assignments for the DB-9 connector.

Table 31-3 DB-9 connector pin assignment
Pin Signal Direction Description
1 DCD Out Data carrier detect
2 RXD Out Received data
3 TXD In Transmit data
4 DTR In Data terminal ready
5 EG — Signal ground (EG)
6 DSR Out Data set ready

7 RTS In Request to send
8 CTS Out Clear to send
9 RI In Ring indicator (used in DTE

configurations only)
Cable connectors
Use a cable to connect the DB-9 craft port on the AACU-C to the craft terminal. For
the craft port, the cable end must be a male 9-pin connector. For the craft terminal,
the cable end can be either a 9-pin or 25-pin connector. For more information about
the pin assignment for the craft cable connectors, see 7342 ISAM FTTU Hardware
Installation and Maintenance Practices.
Interface for Ethernet OS port

The AACU provides a 10/100 BaseT Ethernet interface that connects to the CO
LAN. The interface uses the RJ-45 Ethernet port on the front panel of the AACU.
The Ethernet interface is paralleled via a backplane connection to a second RJ-45
jack mounted on the backplane to support rear access cabling.
Caution — The two Ethernet ports must not be used simultaneously.
If you plug Ethernet cables into both front and back RJ45 connectors,
neither interface will work because of interference between the
signals causing continuous errors.
Interface to the NT cards

The AACU has an interface to the NT card for alarm collection and control functions.
Table 31-4 describes the NT interface signal and the associated direction.
Table 31-4 NT interface
Signal Direction Description
ACU_TXD In Serial receive line from the NT
ACU_RXD Out Serial transmit line to the NT
ACU_IRQ Out AACU interrupt request to the NT

31.7 Physical description
Table 31-5 describes the physical specification of the AACU card.
Table 31-5 AACU physical specifications
Description Specification
Height 16.53 in. (41.99 cm)
Width 0.77 in. (1.96 cm)
Depth 8.66 in. (22 cm)
Weight 1.5 lb. (0.68 kg)

32.4 Front panel 32-3
32.5 Back panel 32-3
32.6 Fan and cable assembly 32-4
32.7 Filter assembly 32-4
32.8 Electrical specifications 32-4

32.1 Identification
Table 32-1 provides identification information about AFAN-H.
Table 32-1 Identification of AFAN-H
Part number Mnemonic Description CLEI CPR ECI/Bar code
3EC 37533 AA 3EC AFAN-H Fan unit with filter. Two — — —

37533 AB variants: AA does not have a
filter bracket, while AB does.
The AFAN-H fan unit provides:

• forced air cooling through eight wide-range fans integrated with the ALTS-N
shelf
• nominal voltages of 48 V dc to 60 V dc
• alarm interface board that provides alarm indication to the ATRU and the office
alarm system
• alarm (for a failing fan, for example) that closes the relay contacts
• replaceable and hot-insertable fans
• locking mechanism that prevents the unit from being disconnected from the frame
when fully extended
• power and alarm connections to the backplane using two DB-15 connectors
• dust filter
• L-10 lifetime at ambient temperatures of 104°F (40°C): 75000 h
• L-10 lifetime at ambient temperatures of 158°F (70°C): 70000 h
• noise level: 57 dBA
• temperature range: 14°F to 158°F (–10°C to +70°C)
• flammability according to UL94V-0
The AFAN-H provides forced air cooling to an ALTS-N shelf as well as alarm
generation in case of fan failure. It is protected through circuit breakers in the TRU
or CO power distribution frame. Air is drawn through the AFAN from bottom to top.
Figure 32-1 shows the front, top, and side views of the AFAN-H fan unit.

Figure 32-1 Front, top, and side views of the AFAN-H fan unit
Airflow
Alarm LED
18402
32.4 Front panel
The front panel has a single alarm LED, which lights in case of fan failure; see
Figure 32-2.
Figure 32-2 AFAN-H front panel
18343
32.5 Back panel
The back panel contains the connectors that plug into the shelf back panel; see
Figure 32-3.
Figure 32-3 AFAN-H back panel
BK BD
CATHODE (-) ANODE (*)
LED 1
FAN 1 FAN 3 FAN 5 FAN 7
FAN 1 FAN 4 FAN 6 FAN 8
18344

32.6 Fan and cable assembly
The cable assembly transfers the alarm signal to the ATRU or any other alarm
collection device and the power connection; see Figure 32-4.
Figure 32-4 Fan and cable assembly
Fan
Pin 1
18178
32.7 Filter assembly
This AFAN-H version is provided with a dust filter. The dust filter has the following
characteristics:
• made from nonwoven synthetic material with a minimum dust arrestance of 80%
• initial pressure <35 Pa
• EN779 Classification E3
• dimensions: 0.30 in. x 18.35 in. x 9.49 in. (7.6mm x 466 mm x 241 mm)
• filter life depends on the physical surroundings, typical 3 to 6 months (inspection
every 2 months)
• complies with UL Class2/UL94 HF-1
• slides into a dedicated slot on the shelf
32.8 Electrical specifications
The fan unit has the following electrical specifications:

• maximum free airflow: 330 ft3/h (9.3 m3/h) (–36 V dc) to 405 ft3/h (11.5 m3/h)
(–72 V dc)
• air velocity: 1.5 m/s
• voltage: –36 V dc to –72 V dc
Table 32-2 describes the physical specifications of the AFAN-H fan unit.

Table 32-2 AFAN-H physical specifications
Description Specifications
3EC 37533 AA
Height 23.62 in. (60 cm)
Width 13.39 in. (34 cm)
Depth 5.71 in. (14.50 cm)
Weight 11.02 lb (5 kg)


33.5 Filter assembly 33-3
33.6 Electrical specifications 33-3

33.1 Identification
Table 33-1 provides identification information about AFAN-S.
Table 33-1 Identification of AFAN-S
3FE 51461 AA AFAN-S Fan unit with filter. BVPQAEFKAA 070MEX 155523
3FE 51462 AA — Rack mount chassis for fan unit — — —
3FE 51527 AA — Replacement air filter — — —
The AFAN-S fan unit provides:

• forced air cooling through six wide-range fans mounted below the OLTS-M shelf
• redundant power feeds, nominal voltage range of -48 V dc to -60 V dc
• LED on the unit front panel to indicate status
• fan presence detected by the ACU card, alarm generated if fan is not installed
• variable speed fan to match airflow to thermal requirements
• fan filter replacement without service interruption
The AFAN-S provides forced air cooling to an OLTS-M shelf as well as alarm
generation in case of fan failure. It is protected through circuit breakers in the TRU.
Power must be supplied to the A and B power source at startup (boot time) or the
system will not initialize. This is because a FANALM alarm for fan 1 will be raised
if the fan unit is missing A- or B-side power. An alarm for this reason puts the system
in thermal shutdown mode. This is to ensure proper powering of the equipment to
protect the system from a potential thermal event. Air is drawn through the AFAN
from bottom to top.
The AFAN-S utilizes thermal sensors and a single control board to regulate the
variable speed fans. The fan unit consumes less power and is quieter by running at
low speed in normal CO operating conditions. If the fan exhaust temperature rises,
the controller board will increase the fan speed. If a fan fails, the remaining fans will
increase their speed to compensate for the loss and a fan failure alarm will be raised.
The fan unit is removable for servicing, allowing easy access to the six internal fans.
The fan chassis mounts directly below the OLTS-M shelf and the AFAN-S unit and
filter assembly slide into the chassis.
Figure 33-1 shows the front of the AFAN-S fan unit with the air filter installed.

Figure 33-1 Front view of the AFAN-S fan unit
AFAN-S
FAN UNIT STATUS
BLINKING
GREEN - INTIALIZING
SOLID
GREEN - ACTIVE
CAUTION
RED - FAN FAILURE
AMBER - OVER-TEMPERATURE
MOVING PARTS INSIDE OF FAN
19372
33.4 Front panel
The front panel has a single, three element, status LED. Table 33-2 defines the status
LED states.
Table 33-2 Status LED indications
LED color LED state Fan status

Green Blinking Initializing
On Active
Yellow On Over temperature

Red On Fan failure
33.5 Filter assembly
This AFAN-S version is provided with a dust filter. The dust filter has the following
characteristics:
• made from nonwoven synthetic material with a minimum dust arrestance of 80%
• filter life depends on the physical surroundings, typical 3 to 6 months (inspection
every month)
• slides into a dedicated slot on the shelf
• replacement without affecting service
33.6 Electrical specifications
The fan unit has the following electrical specifications:

• voltage: –36 V dc to –75 V dc
• dual input power feed (–48 V dc A and B power feeds)
Table 33-3 describes the physical specifications of the AFAN-S fan unit.

Table 33-3 AFAN-S physical specifications
Description Specifications
Height 3.38 in. (85.85 mm)
Width 17.23 in. (437.64 mm)
Depth 10.88 in. (276.35 mm)
Weight 11.0 lbs. (5.0 kg)

34.4 Backplane connectors and cables 34-4
34.5 Physical location identification 34-6
34.6 Power distribution 34-6
34.7 Thermal limitation 34-7

34.1 Identification
Table 34-1 provides identification information about ALTS-N.
Table 34-1 Identification of ALTS-N

code
3EC 17542 AB ALTS-N Line termination — — —

shelf, version N
The ALTS-N shelf provides:

• a shelf frame in which the P-OLT components install that is rack mountable in a
UT-9 rack for deployment in a CO or CEV
• slots for 2 NT cards (NTA and NTB) and 1 ACU card
• slots for up to 16 LT cards; for example, up to 16 GLT2 cards terminating a
maximum of 2048 subscribers per P-OLT shelf
• connection for a FILT card with three battery filter caps that mount in the shelf
power input area for CE Mark, EN55022, and EN300386 EMC compliance
• connection for a SANC-D backplane adapter
• terminals for connecting a –48 V dc or –60 V dc power supply
• support for the installation of a fiber routing tray
The ALTS-N optical line termination (OLT) shelf is the rack mountable frame in
which the cards and other units that comprise the P-OLT are installed. The shelf
mounts in the OLT rack for CO or CEV installations. The OLT rack is a UT-9 rack,
600 mm wide and 2200 mm high, with 25 mm spaced holes for mounting equipment.
See the OLT rack unit data sheet for more information.
Note — Due to thermal limitations, you can install a maximum of two

P-OLT shelves plus one TRU unit in a rack, even though three shelves
plus the TRU unit can physically fit in to the same rack.
The ALTS-N shelf has three main areas:

• card cage
• cable routing and shelf connector area
• fan tray

The ALTS-N shelf supports the following NT and LT cards:

• EHNT-A
• GLT2-A
• GLT2-B
Figure 34-1 shows an ALTS-N shelf populated with P-OLT components.
Figure 34-1 ALTS-N shelf with P-OLT cards and components
Energy Hazard

ALM ACT ALM PWR ACT
MIN
ALM
ACO
623.75 mm
ETHERNET
CRAFT
247.2 mm 497.4 mm
284.5 mm 515 mm
529.4 mm
18835
The card cage is the large central area of the shelf that accommodates plug-in cards
that are 16.53 in. (42 cm) in height and 8.66 in. (22 cm) in depth. From left to right,
there is 1 ACU slot, 2 NT slots (NTA and NTB), and 16 LT slots. Blank filler plates
must be installed in any empty slots in the card cage area.
The topmost area of the shelf is the cable routing and shelf connector area, which
provides the following:
• attachments for the fiber mounting kit
• line interface connectors, such as the I/O unit for the GLT2 card that provides an
Ethernet connection between the GLT2 and Ethernet equipment outside the
P-OLT
• slot for the optional SANC-D unit

• shelf power connections from the TRU

• fan unit power connections from the TRU
• TRU and remote craft interface connectors
• IQ-bus extension and XDSL line connectors
Note — The IQ-bus extension and XDSL line connectors are not used
for the 7342 ISAM FTTU application.
The fan tray area contains the fan unit.

For a detailed description of the fan unit and the plug-in cards, refer to the
corresponding unit data sheets.
34.4 Backplane connectors and cables
The backplane interconnects the cards, the fan unit, the eHCL bus interface, external
interfaces, and other rack equipment. Input power terminals are located on the
externally accessible section of the backplane, which is the topmost section; see
Figure 34-1 and Figure 34-2. The physical location identification jumpers are also
located on the backplane.
Power is distributed to the fan unit and to the active units in the shelf over the
backplane. Cards installed in the card cage are supplied with redundant (A, B) power
feeds from the TRU over the shelf backplane. Shelf and fan unit power circuit
breakers are located on the TRU.
Figure 34-2 shows the backplane of the ALTS-N. The connectors that appear in the
topmost section are externally accessible from the front of the shelf. This is also
where fiber cable management is performed.

Figure 34-2 ALTS-N backplane

M5 nuts for Fast-on terminals
powering Subrack for powering Fan unit
(from TRU) (from TRU)
Fast-ons for
Two-Wire
configuration
(LT area)
Fast-ons for
Two-Wire configuration
(Fan area) FGE026
Table 34-2 provides information about the backplane connectors and related cables.
Table 34-2 Backplane connectors and related cables
Connector Function Type Related cables
PWR I/O Shelf power (BATA, BATB, BATRET) Cable Lug M5 6 mm2 (3x)
FAN PWR I/O Fan power (BATA, BATB, BATRET) Female Faston 6.3 0.75 mm2 (3x)
(1 of 2)

FAN 1, FAN 2 Fan interface DSUB 15 pins None
LT01 to LT16 NTA, Connectors for plug-in units in line Metral None
NTB, ACU termination area CON-PB*MAL*XX (1)
LINE 01 to 16 Line interface connectors CHAMP 50 pins UTP CAT5-type or better
ACU-TRU Top Rack interface DSUB 50 pins 3EC 16844 xx AA
CRTF Remote Craft Interface DSUB 9 pins 3EC 16028 xx AA
PLID PLID jumper setting Jumper connectors 1AB 00270 00 12

(jumper)
BATRET, FG Two-wire power configuration Fastons (Faston bridge)
(2 of 2)
Note
(1) Press-fit connectors with five row pinning and with 2 mm pitch.
34.5 Physical location identification
The ALTS-N shelf provides the physical location identification (PLID) setting. This
requires 21 PLID bits for ultra-density equipment.
Nine bits (SLOT_ID, BP_TYP) are fixed in the backplane layout, the other twelve
(SR_ID, R_ID, R_TYP, ACU_EN) can be altered at the installation with PLID
jumpers.
As described in Table 34-2, the jumpers are placed on the backplane in two columns
between the ACU and the NTA slots.
34.6 Power distribution
The shelf and the fan unit receive redundant power from the TRU. The TRU provides
redundant power, A and B, to the shelf and frame ground for the rack. In the
three-wire configuration, there are three power cables (BATA, BATB, and
BATRET) and a separate frame ground wire. In the two-wire configuration, frame
ground is provided via the BATRET cable. Figure 34-2 shows the Faston bridges
used to connect the three-wire and the two-wire power configurations.
The power signals BATA, BATB and BATRET is distributed via the backplane and
feed the plug-in units and fan units installed.
In the shelf power input area, a small board (FILT-A) is bolted onto the power
connectors of the ALTS-N shelf. The FILT-A (3EM 17820 AA) filters the dc mains
on the shelf to achieve CE Mark, EN55022, and EN300386 EMC compliance.
Three battery filter caps are provided on the board, one each for BAT_A-FG,
BAT_B-FG, and BAT_RET-FG.
Table 34-3 lists the power and grounding signals used.

Table 34-3 Power and grounding signals
Signal name Description
BATA Battery supply voltage branch A
BATB Battery supply voltage branch B
BATRET Common return voltage
EG Electrical ground
FG Shelf frame ground
34.7 Thermal limitation
Due to the high data rates and large number of subscribers, failure of the P-OLT
equipment can cause massive service outages and revenue loss for service providers.
Some P-OLT cards are not expected to operate more than a few minutes without
forced air cooling.
To prevent failure, the P-OLT uses a redundant fan design. With this design, the
failure of one fan does not cause a cooling system degradation that is severe enough
for the NT and LT units to fail. However, there are constraints that must be observed
for the design to work as specified.
Observe the following when working with the P-OLT equipment:
• Keep the front cover on during normal operation to maintain proper thermal
operation.
• Use only the AFAN-H as the P-OLT cooling system. The AFAN-H is
fault-tolerant and highly reliable.
• Do not stack P-OLT shelves directly over each other, unless the air space between
the shelves are 300 mm and more.
• Do Not place the shelf above a heat source without redirecting the hot air away
from the inlet of the shelf. For example, you can use an air baffle to redirect hot
air.
• Never allow an in-service P-OLT be left without forced-air cooling for more than
5 minutes.
• Replace the failed fan within the MTTR period. A single-fan failure in the P-OLT
cooling system does not cause the NT or LT cards to fail during the MTTR period.
MTTR is a maximum of 4 hours for remote locations, including CEVs.
Figure 34-3 shows the ALTS-N shelf with a front cover and a fan unit inserted at the
bottom.

Figure 34-3 ALTS-N shelf
FGE032
Front cover
The front cover provides EMC enclosure of the line termination area.
The front cover is supported by hanging it on the hooks on top of the shelf and closed
by locking the clips at the bottom.
Rear cover
The rear cover provides electrical insulation between the backplane of the shelf and
the rack or cabinet. To assure EMC enclosure, it is mounted to the backplane with
screws and to the shelf frame with spring contacts.
Fiber management kit

The fiber management kit is used to route fiber cables that are coming from the LT
cards installed in the ALTS-N shelf, and consists of a fiber routing tray and mounting
brackets. The fiber routing tray mounts inside the cable routing and shelf connector
area, which is located directly above the card cage. Fiber cables are routed out the
cable exit areas located on the left and right sides of the shelf.
Specifications
Table 34-4 describes the physical specifications of the ALTS-N.

Table 34-4 Physical specifications of the ALTS-N
Height 24.56 in. (62.4 cm)
Width 20.27 in. (51.5 cm)
Depth 11.22 in. (28.5 cm)
Weight 62.61 lb (28.4 kg)


35.5 PBA-ATRU-G board 35-4

35.1 Identification
Table 35-1 provides identification information about ATRU-M.
Table 35-1 Identification of ATRU-M
Part number Mnemonic Name CLEI CPR ECI/bar

code
3EC 17422 AA ATRU-M Top rack unit, version M, for P-OLT rack — — —
configurations
The ATRU-M unit provides:

• rack powering to a maximum of two P-OLT shelves
• termination of the office power and service battery cabling
• termination of redundant office power cabling
• termination point for connection to the CO alarm system and telemetry alarm
system
• circuit breaker options for the AA variant:
• 6 x 30 A circuit breakers: 3 x A/3 x B (labeled 01, 02, and 03), for board protection
• 6 x 4 A circuit breakers: 3 x A/3 x B (labeled FAN1, FAN2, and FAN3), for fan
protection
• three fuses, 5 A each, one for the service battery, 2 for the power cabling to the
top rack unit (TRU) control board
• summary alarm display of minor, major, and critical alarms
• circuit breaker alarm
• power available indicators (A and B)
• earth bonding point
The ATRU includes the front panel and the connector blocks. For a description of
the connector blocks and their cabling, refer to the 7342 ISAM FTTU Hardware
Installation and Maintenance Practices.
The top rack unit contains a small board, the ATRU-G, located on the left. For a brief
description of this board, see the corresponding section.

35.4 Front panel
Figure 35-1 shows the following parts from left to right:

• indicator LEDs and Test button
• circuit breaker block for branch A
• circuit breaker block for branch B
• warning labels
Figure 35-1 ATRU-M AA variant front panel
Indicator LEDs and test button

The test button is used to activate a lamp test. The lamp test tests the LEDs on the
PBAs and the rack lamps. Above the test button, a number of LED indicators are
located. Table 35-2 provides information about the LEDs.
Table 35-2 Front panel LED indicators
LED Name Description
CRI Critical Indicates a critical error

MAJ Major Indicates a major error
MIN Minor Indicates a minor error
FUS Fuse Indicates the condition of the fuse
VOLTAGE Voltage Indicates a voltage error
PWR-ATRU Power Power Indicator
PWRA1 Power 1, branch A Power indicator 1 of the A branch of the power

distribution

distribution
distribution
PWRB1 Power 1, branch B Power indicator 1 of the B branch of the power

distribution

distribution
(1 of 2)


distribution
(2 of 2)
Circuit breakers
Circuit breakers are used for power feed branch A and B. The ATRU-M uses the AA
variant of the branch A circuit breaker.
The AA variant provides six circuit breakers each for the branch A and B. When
looking at the front panel, the circuit breakers for the branch A are located at the left
and those for the branch B are located at the right. Of the six circuit breakers for each
branch, the first three, labeled 01, 02, and 03, are the circuit breakers for the line of
the power distribution. These are 30 A circuit breakers and used for board protection.
The other three, labeled FAN1, FAN2, and FAN3, are 4 A circuit breakers, used for
fan protection.
Earth bonding point

This is the bonding point to which the protective earth is connected.
35.5 PBA-ATRU-G board
The PBA-ATRU-G board is located to the left, inside the ATRU-M. This board
performs a number of controls and functions of the ATRU-M. It contains a number
of connectors for different signals and a number of jumpers (straps) to set board
parameters.
Figure 35-2 shows the location of the connectors and jumpers on the PBA-ATRU-G
board.

Figure 35-2 PBA-ATRU-G connector and jumper locations
The pin layout of the 37-pin SUB-D CO interface connector is described in

Table 35-3. This interfaces to the central office local and telemetry alarm systems.
Table 35-3 CO connector pin layout
Pin Signal name I/O Description
1 ACO_TEL_RET In BATRET on ACU

2 ACO_AUD_RET In BATRET on ACU
3 Not used — —
4 Not used — —
5 MISC1RET In BATRET on ACU
8 VOLTAGE_ALM Out Voltage alarm (low/high)
9 FUSEFAIL Out Fuse failure alarm
10 AUD_MIN- Out Audible minor alarm
11 AUDMAJ- Out Audible major alarm

12 AUD_CRI- Out Audible critical alarm
13 VIS_MIN- Out Visual minor alarm
14 VIS_MAJ- Out Visual major alarm

15 VIS_CRI- Out Visual critical alarm
16 TEL_MIN- Out Telemetry minor alarm
17 TEL_MAJ- Out Telemetry major alarm
(1 of 2)

18 TEL_CRI- Out Telemetry critical alarm
19 SYS_ID- Out System identity
20 ACO_TEL In (From CO) Alarm cutoff telemetry

21 ACO_AUD In Alarm cutoff audible
22 Not used — —
23 MISC1 In Spare alarm 1
26 VOLTAGE_ALM_RET Out (To CO) BATR on ATRU
27 FUSEFAIL_RET Out BATR on ATRU
28 AUD_MIN+ Out BATRET ON CO
29 AUDMAJ+ Out BATRET ON CO

30 AUD_CRI+ Out BATRET ON CO
31 VIS_MIN+ Out BATRET on ATRU
32 VIS_MAJ+ Out BATRET on ATRU
33 VIS_CRI+ Out BATRET on ATRU
34 TEL_MIN+ Out BATRET on CO
35 TEL_MAJ+ Out BATRET on CO
36 TEL_CRI+ Out BATRET on CO
37 SYS_ID+ Out BATRET on CO
(2 of 2)
Table 35-4 describes the ATRU-M physical specifications.
Table 35-4 ATRU-M physical specifications
Height 3.37 in. (86 mm)
Width 20.08 in. (51 cm)



36.1 Identification
Table 36-1 provides identification information about ATRU-N.
Table 36-1 Identification of ATRU-N
Part number Mnemonic Name CLEI CPR ECI/Bar

code
3EC 17422 CD ATRU-N Top rack unit, Version N — — —
The ATRU-N unit provides:

• rack configurations with one or two ALTS-N shelves
• fixed power distribution to ALTS-N shelves
• connection of the central office (CO) power branches (feeders A1, A2, A3, B1,
B2, and B3)
• distribution for branches A (feeders A1, A2) and B (feeders B1, B2) to two
ALTS-N shelves (redundant shelf powering)
• distribution for branch A (feeder A3) to the first fan unit and branch B (feeder B3)
to the second fan unit
• BATRET connection towards the CO power distribution frame (PDF) and to the
shelves and associated fan units
Note — The ATRU-N contains no switches or circuit breakers for
equipment protection. The customer has to provide the protection
devices at the power source or at the PDF.
• wires required for shelf and fan unit powering

• fused powering connections for the PBA-ATRU-G unit (six 5 A fuses)
• alarm control unit (ACU) interconnection between the shelves
• connection to the CO alarm system and telemetry alarm system
• alarm collecting, input voltage supervision, alarm routing and displaying alarm
conditions on the front panel (PBA-ATRU-G unit)
• jumper setting for alarm selection
• earth bonding point on the front panel
• installation into a standard ETSI rack at an 87.5 mm pitch
The ATRU-N is used for a rack configuration with up to two ALTS-N shelves, so
two power feeders are sufficient. However, a third power feeder is used for powering
a single fan unit. The first fan unit is powered by the third feeder from branch A and
the second fan unit is powered by the third feeder from branch B. Redundant
powering of the fan units is not offered; see Figure 36-1.

The ATRU-N provides the following functions:

• connection of the external input power feeders (maximum three branch A and
three branch B feeders) and distribution of these to the two shelves and to the fan
unit in each shelf
Note — Because the shelves and fan units in the rack are not
protected by switches nor circuit breakers, the customer has to
provide for the protection devices at the power source or power
distribution frame.
• ACU (alarm control unit) interconnections between the shelves
• voltage alarm at input voltages outside the tolerated limits
• alarm selection
The ATRU-N contains the PBA-ATRU-G unit that performs the following
functions:
• alarm collection
• input voltage supervision
• alarm routing
• displays of the alarm conditions
It contains the cables for the power connections to the shelves and the fan units.
The TRU fits into a 87.5 mm pitch and according to the standard ETSI rack
dimensions.

Figure 36-1 Diagram of ATRU-N for fixed shelf powering (up to two ALTS-N shelves)
to Power Distribution Frame
configuration)
(for Two Wire
BAT A1
BAT A2
BAT A3
BAT B1
BAT B2
BAT B3
BAT B1
BAT B2
BAT B3
BATRET
PBA ATRU G
F A1 5A
I PWR A1
F A1 5A
I PWR A2
F A1 5A
I PWR A3
BATRET
F B1 5A
I PWR B1
F B1 5A
I PWR B2
F B1 5A
I PWR B3
BATRET
A TRU N
SR1
SR 2
Fan1
SR1
SR 2
Fan2
BAT A BAT B BAT RET
to shelf and fan units
The ATRU-N has three main parts: the front panel, the power-input terminal blocks,
and the PBA-ATRU-G board; see Figure 36-2.

Figure 36-2 Parts of the ATRU-N
Front panel
The front panel contains the following items from left to right:
• LEDs for status indication and test button
• Earth bonding point
• Label with current rating
• Warning label “Energy Hazard”
Figure 36-3 shows the front panel.
Figure 36-3 ATRU-N front panel
Front panel LEDs

Figure 36-4 shows the twelve front panel LEDs. Table 36-2 describes the LEDs.

Figure 36-4 ATRU-N front panel LEDs
CRI
MAJ
MIN
FUS
VOLTAGE
PWR•ATRU
PWRA1 PWRB1
PWRA2 PWRB2
PWRA3 PWRB3
TEST
FGE106
Table 36-2 Front panel LEDs
LED Color Name Description
CRI Red Critical Indicates a critical error

MAJ Red Major Indicates a major error
MIN Yellow Minor Indicates a minor error
FUS Red Fuse Indicates the condition of the fuse
VOLTAGE Red Voltage Indicates a voltage error
PWR_ATRU White Power Power Indicator
PWRA1 Green Power 1, branch A Power indicator 1 of power branch A
PWRB1 Green Power 1, branch B Power indicator 1 of power branch B
Test button
The test button is used to activate a lamp-test. This test allows to check the operation
of the front panel LEDs (on the PBA-ATRU-G) and the rack lamps above the TRU.
Earth bonding point

The earth bonding point is connected to the protective earth. It provides a connection
point for an ESD wrist strap required when handling ESD susceptible cards.

Power input terminal blocks

The ATRU-N provides terminal and fuse blocks premounted on a symmetrical
DIN-rail. The two fabrication variants, shown in Figure 36-5, are available from
different sources. Although they have different terminal block types, they have the
same performance characteristics.
Figure 36-5 Power-input terminal blocks (two fabrication variants)
Fabrication variant 1 (1)
(2)
(3)
interconnected
BATRET terminals
Fabrication variant 2
(1)
(2) (3)
interconnected
BATRET terminals
Notes (1) Frame Ground is connected to this BATRET terminal to obtain the Two Wire power configuration
(2) These fuses and terminals are reserved for powering the PBA ATRU G unit.
(3) This terminal is reserved for BATRET connection of the PBA ATRU G unit.

Power and grounding provisions

The power input connections are the powering feeds coming from the CO PDF and
terminated on the terminal blocks inside the TRU (Figure 36-5).
Power input connections must be made by service personnel only. Table 36-3 gives
an overview of the possible connections.
Table 36-3 Power input connection and grounding provisions
Power connection type Provisions Labeling Wire section
Battery input feed A1 max. 16 mm2 P-A1 16 mm2
Battery input feed A2 max. 16 mm2 P-A2 16 mm2
Battery input feed B1 max. 16 mm2 P-B1 16 mm2
Battery input feed B2 max. 16 mm2 P-B2 16 mm2

Battery input feed A3 max. 2.5 mm2 P-A3 2.5 mm2
Battery input feed B3 max. 2.5 mm2 P-B3 2.5 mm2
Battery return inputs max. max. 16 mm2 BRET 16 mm2
Optional two-wire system connection max. 16 mm2 BRET 16 mm2

point (1)
Note
(1) Allows connecting the rack frame ground to BATRET to obtain a two-wire power supply instead of
the standard delivered three-wire power architecture. This connection is to be made on site.
Each variant contains six terminal blocks for BATRET connection; these are
interconnected.
Only two blocks of 16 mm2 are required for the battery return connections to the
power plant (BATRET A, BATRET B). The third block of 16 mm2 is reserved for
the optional frame ground to BATRET connection to obtain a two-wire
configuration.
Miniature fuses for PBA-TRU-G

The input terminal block contains six identical miniature fuses to protect the
PBA-ATRU-G board. Because this board is powered from all the branches (A1, A2,
A3, B1, B2, and B3) there is protection on each branch:
F-A1, F-A2, F-A3, F-B1, F-B2, and F-B3 are rated 250 V/5 A/medium blow.
External circuit breaker rating and cable sections

A P-OLT system equipped with the ATRU-N for fixed shelf powering is
permanently connected equipment. This type of TRU does not provide switches or
circuit breakers for powering on or off the system. The power switching function has
to be done externally by circuit breakers at the PDF.
Figure 36-6 shows how the P-OLT rack with an ATRU for fixed power distribution
has to be connected to the PDF.

Figure 36-6 Power connection of P-OLT rack to PDF
Power input terminals

ATRU N
Circuit Breakers B1 A1
PDF B
Shelf 1
Battery B Fan unit 1 A3
Circuit Breakers
B2 A2
PDF A
Shelf 2
Battery A Fan unit 2 B3
Power Distribution Frame
Note — The power distribution to the shelves provides for

redundancy, meaning that if one of the two breakers supplying a
specific shelf is turned off (for example, A1 is turned off, but B1 is
left on), the remaining single feed can support the full current
requirements of that shelf. Under normal conditions (A and B on), the
power/current is shared between the A and B feeds.
The power distribution to the fan units does not provide for
redundancy. Each fan unit is supplied by only one feed (feed A3 for
the first fan unit and feed B3 for the second).
The circuit breakers at the power distribution frame must have the following current
rating to protect the power cables feeding a P-OLT rack equipped with two ALTS-N
shelves; see Table 36-4.

Table 36-4 PDF circuit breaker rating and power cable sections
Branch Powering Max. CB Power cable

rating at PDF section
Branch A1 Shelf 1 32 A 16 mm2
Branch A2 Shelf 2 32 A 16 mm2
Branch A3 Fan unit 1 10 A 2.5 mm2
Branch B1 Shelf 1 32 A 16 mm2
Branch B2 Shelf 2 32 A 16 mm2
Branch B3 Fan unit 2 10 A 2.5 mm2
Warning — If an inappropriate circuit breaker or cable section is

applied, a dangerous situation may occur.
Using circuit breakers with a rating too high or using power cables
with a section too small can cause death or serious physical harm to
persons, or damage to equipment.
Incorrect connection can cause serious physical harm to persons or
damage to equipment (for example, when powering the fan units with
power cables that are protected with 32 A breakers instead of 10 A
breakers).
Remove and replace circuit breakers with appropriately rated circuit
breakers.
Check for correct power cable connections between the power
distribution frame and the P-OLT before powering the equipment.
PBA-ATRU-G board
The ATRU-N contains the PBA-ATRU-G board. This board provides an interface
for alarm collection, alarm routing, and display of the alarm conditions in the rack.
As shown in Figure 36-2, the ATRU-G board is mounted inside the left-hand side the
TRU.
Figure 36-7 describes the board layout and shows the following items:
• LEDS (Figure 36-4 shows the LEDs on the front panel)
• one test button (Figure 36-4 shows the test button on the front panel)
• three ACU/FAN alarm interface connectors
• one central office interface connector
• twenty jumpers.

Figure 36-7 Layout of the ATRU-G board (jumpers factory set)
ACU3 ACU2 ACU1
2 4 6 4 6
1 20
1 34 1 34 1 34
1 1 3 1 3 18 18 18
3 2 1
X1
LEDS
13 5
2 4 6
(LR)
(CA) 1 2 3 33 33 33
17 50 17 50 17 50
19
37
(CB) 1 2 3 X20
(CO)
Test button FGE108
Rack lamp connector

ACU/FAN Alarm
Interface Connectors
ATRU G Jumpers
3 21
Pin number Central Office
X1
Interface Connector
Jumper X19
number X20
Jumper
CO interface connector
Table 36-5 describes the pin connector layout for a D-SUB 37-pin connector used
with the CO interface connector on the ATRU G. Figure 36-8 shows the D-SUB
37-pin connector layout.

Figure 36-8 D-SUB 37-pin connector
1
20
37
19
FGE109
Table 36-5 Pin layout of CO interface connector
Pin Signal name Type Description
1 ACO_TEL_RET In BATRET on ACU
2 ACO_AUD_RET In BATRET on ACU
3, 4, 22 Not used — —
5 MISC1_RET In BATRET on ACU
8 VOLTAGE_ALM Out Voltage_alarm (low/high)
9 FUSEFAIL Out Fuse failure alarm
10 AUD_MIN- Out Audible minor alarm
11 AUD_MAJ- Out Audible major alarm
(1 of 2)

12 AUD_CRI- Out Audible critical alarm
13 VIS_MIN- Out Visual minor alarm
14 VIS_MAJ- Out Visual major alarm

15 VIS_CRI- Out Visual critical alarm
16 TEL_MIN- Out Telemetry minor alarm
17 TEL_MAJ- Out Telemetry major alarm
18 TEL_CRI- Out Telemetry critical alarm
19 SYS_ID- Out System identity
20 ACO_AUD In Alarm cutoff audible
21 ACO_TEL In Alarm cutoff telemetry

26 VOLTAGE_ALM_RET Out BATR on ATRU-G
27 FUSEFAIL_RET Out BATRET on ATRU-G
28 AUD_MIN+ Out BATRET on CO
29 AUD_MAJ+ Out BATRET on CO
30 AUD_CRI+ Out BATRET on CO
31 VIS_MIN+ Out BATRET on ATRU-G
33 VIS_CRI+ Out BATRET on ATRU-G
34 TEL_MIN+ Out BATRET on CO
35 VIS_MAJ+ Out BATRET on ATRU-G

35 TEL_MAJ+ Out BATRET on CO
36 TEL_CRI+ Out BATRET on CO
37 SYS_ID+ Out BATRET on CO
(2 of 2)
ACU/FAN alarm interface connectors

Table 36-6 describes the pin connector layout for a D-SUB 50-pin connector used
with the ACU and FAN interface connectors on the ATRU-G. Figure 36-9 shows the
D-SUB 50-pin connector layout.

Figure 36-9 D-SUB 50-pin connector
1 34
18
17 50
FGE110
Table 36-6 Pin layout of ACU/FAN alarm connectors
1 ACO-TEL-A Out Telemetry alarm cutoff (A-wire)
2 ACO-AU-A Out Audible alarm cutoff (A-wire)
3 FAN-ALM0-A Out Fan unit 0 alarm (A-wire)
4 FAN-ALM1-A Out Fan unit 1 alarm (A-wire)
5 DOOR-ALM-A Out Door alarm (A-wire)
6 FUSE-ALM-A Out Fuse alarm (A-wire)
7 SP-ALM0-A Out Spare alarm 0 (A-wire)
(1 of 3)

12 AU-MIN-A In Minor audible alarm (A-wire)
13 AU-MAJ-A In Major audible alarm (A-wire)

14 AU-CRIT-A In Critical audible alarm (A-wire)
15 VIS-MIN-A In Minor visible alarm (A-wire)
16 VIS-MAJ-A In Major visible alarm (A-wire)
17 VIS-CRIT-A In Critical visible alarm (A-wire)
18 TEL-MIN-A In Minor tel. alarm (A-wire)
18 TEL-MIN-B In Minor tel. alarm (B-wire)
20 TEL-MAJ-A In Major tel. alarm (A-wire)
21 TEL-MAJ-B In Major tel. alarm (B-wire)
22 TEL-CRIT-A In Critical tel. alarm (A-wire)

23 TEL-CRIT-B In Critical tel. alarm (B-wire)
24 SID-A In System ID (A-wire)
25 SID-B In System ID (B-wire)
26 FAN-ALM2-A In Fan unit 2 alarm (A-wire)
27 FAN-ALM2-B In Fan unit 2 alarm (B-wire)
28 FAN-ALM3-A In Fan unit 3 alarm (A-wire)
29 FAN-ALM3-B In Fan unit 3 alarm (B-wire)
30 TRU-SP0 In Spare alarm 0

34 ACO-TEL-B Out Telemetry. alarm cutoff (B-wire)
35 ACO-AU-B Out Audible alarm cutoff (B-wire)

36 FAN-ALM0-B Out Fan unit 0 alarm (B-wire)
37 FAN-ALM1-B Out Fan unit 1 alarm (B-wire)
38 DOOR-ALM-B Out Door alarm (B-wire)
39 FUSE-ALM-B Out Fuse alarm (B-wire)
40 SP-ALM0-B Out Spare alarm 0 (B-wire)
45 AU-MIN-B In Minor audible alarm (B-wire)
46 AU-MAJ-B In Major audible alarm (B-wire)
47 AU-CRIT-B In Critical audible alarm (B-wire)
(2 of 3)

48 VIS-MIN-B In Minor visible alarm (B-wire)
49 VIS-MAJ-B In Major visible alarm (B-wire)
50 VIS-CRIT-B In Critical visible alarm (B-wire)
(3 of 3)
Jumpers
The PBA-ATRU-G is equipped with 20 jumpers. Jumpers X1 to X19 allow different
parameter settings and jumper X20 is a spare.
At delivery, the jumpers are factory set. Each jumper is in the left-hand position and
connects pin 2 and 3. Table 36-7 gives the function of the jumpers when factory set.
Jumper setting is performed on site and as required by the application; see
Table 36-8.
Table 36-7 Factory jumper settings
Jumper Function (application-dependent)
X5 Fuse fail indication at CO
X3+X6 Power OFF command to ACU (1)
X11 Power OFF setting for 48 V power system
X4 LVA_HVA signal to ACU
X7+X8+X9+X10 LVA_HVA setting for 48 V rack supply voltage selection system
X14 Rack lamp ON when one power branch is present
X15+X16 ALARM FAN3 assigned to ACU alarm input of FAN2 (2)
X12+X13 ATRU-G fed by power branches A and B

X2+X18+X17+x19 Door alarm contacts connected to ACU alarm inputs SP_ALM2
Notes
(1) X3 and X6 are removed for 3 P-OLT racks (future).
(2) X15 and X16 are removed for 2 and (future) 3 P-OLT racks.
Table 36-8 Application-dependent jumper setting
X17+X19 MISC3 of CO connected to SP_ALM2 of ACU
X4 MISC4 of ACU connected toSP_ALM3 of ACU

X1+X6+X5+X3 MISC5 of ACU connected to SP_ALM4 of ACU (1)
X7+X8+X9+X10 LVA_HVA setting for 60 V rack supply voltage selection system
X11 Power OFF setting for 60 V power system
(1 of 2)

X12+X13 ATRU-G is fed by the service battery
X14 POWER ON rack lamp is illuminated when both the power input branches
are present
X15+X16 ALARM FAN3 assigned to ACU alarm input of FAN1 (2)
X2+X18 Door alarm contacts connected to ACU alarm inputs DOOR_ALM
(2 of 2)
Notes
(1) X3 and X6 are removed for 3 P-OLT racks (future).
(2) X15 and X16 are removed for 2 and (future) 3 P-OLT racks.
Dimensions
The ATRU-N unit complies with the ETSI rack dimensions.
Table 36-9 gives the dimensions of the ATRU-N.
Table 36-9 ATRU-N dimensions
Dimension Comment Value

Height — 85.7mm
Width Excluding mounting support 500 mm
Including mounting support 530 mm

For mounting 515 mm
Depth Excluding hinged front 258.5 mm
Including hinged front 262 mm

Pitch of mounting holes — 12.5 or 25 mm
Weight — 3.5 kg
Safety requirements
When equipped in a OLT rack, the ATRU-N meets the requirements of:
• EN 60950/EC 60950, third edition 1999-04—Safety of information technology
equipment.
• AS3260
The following characteristics are valid:
• permanently connected equipment
• installation in restricted access location
• Class I equipment (for protection against electric shock)

• TNV dc supply voltage (Telecommunication Network Voltage)

• The dc-return conductor is insulated (three-wire power configuration) with
arrangements to connect the dc-return conductor to the frame (two-wire power
configuration).
Specifications
Table 36-10 describes the physical specifications of the ATRU-N.
Table 36-10 Physical specifications of the ATRU-N
Height 3.37 in. (85.7 mm)
Width 15.75 in. (40 cm)
Depth 11.81 in. (30 cm)


37.5 PBA-ATRU-G board 37-4

37.1 Identification
Table 37-1 provides identification information about ATRU-U.
Table 37-1 Identification of ATRU-U
Part number Mnemonic Name CLEI CPR ECI/bar code
3FE 51460 AA ATRU-U Top rack unit, version U, for OLTS-M BVM5Y00CRA 211350 454739
P-OLT rack configurations
The ATRU-U units provide:

• termination of redundant office power
• termination of the service battery cabling
• circuit breakers for rack equipment for the ATRU-U:
• 4 x 35 A circuit breakers: 2 x A/2 x B (labeled 01,and 02), for P-OLT shelf
protection
• 4 x 6 A circuit breakers: 2 x A/2 x B (labeled FAN1 and FAN2), for fan protection
• rack power wiring to a maximum of two P-OLT shelves
• rack power wiring to a maximum of two fan shelves
• termination point for connection to the CO alarm system and telemetry alarm
system
• three internal fuses, 5 A each, one for the service battery, 2 for the power cabling
to the top rack unit (TRU) control board (PBA-ATRU-G)
• summary alarm display of minor, major, and critical alarms
• circuit breaker alarm indicator
• power available indicators (A and B)
The ATRU includes the front panel, redundant power connector blocks and rack
equipment power harness. For a description of the connector blocks and their
cabling, refer to the 7342 ISAM FTTU Hardware Installation and Maintenance
Practices.
The top rack unit contains a small board, the ATRU-G, located on the left. For a brief
description of this board, see the corresponding section.

37.4 Front panel
Figure 37-1 shows the following parts from left to right:

• indicator LEDs and Test button
• circuit breaker block for branch A
• circuit breaker block for branch B
• warning labels
Figure 37-1 ATRU-U front panel
CAUT ION
TWO Bra
nch Pow
Switch off er Supply
the fuses
F........and
F...
rack or PD .....in
B.....
to clear
the equipm
ent
ENERGY
HAZARD
19335
Indicator LEDs and test button

The test button is used to activate a lamp test. The lamp test tests the LEDs on the
TRU and the rack lamps. Above the test button, a number of LED indicators are
located. Table 37-2 provides information about the LEDs.
Table 37-2 Front panel LED indicators
CRI (red) Critical Indicates a critical error
MAJ (red) Major Indicates a major error
MIN (yellow) Minor Indicates a minor error

FUS (red) Fuse fail Indicates the tripped or off condition of a circuit breaker
VOLTAGE (red) Voltage Indicates a branch voltage error high or low
PWR-ATRU ATRU Power Power present Indicator

(green)
PWRA1 (green) Power 1, branch A Power indicator 1 of the A branch of the power
distribution
PWRA2 (green) Power 2, branch A Power indicator 2 of the A branch of the power
distribution
UNUSED — —
(1 of 2)

PWRB1 (green) Power 1, branch B Power indicator 1 of the B branch of the power
distribution
PWRB2 (green) Power 2, branch B Power indicator 2 of the B branch of the power
distribution
UNUSED — —
(2 of 2)
Circuit breakers
Circuit breakers are used for power feed branch A and B for two OLTS-M shelves
and two AFAN-S fan units.
There are four circuit breakers each for the branch A and B. When looking at the
front panel, the circuit breakers for the branch A are located at the left and those for
the branch B are located at the right. Of the four circuit breakers for each branch, the
first two, labeled 01,and 02, are the circuit breakers for the shelf power distribution.
These are 35 A circuit breakers (ATRU-U) and used for board protection. The other
two, labeled FAN1,and FAN2, are 6 A circuit breakers, used for the fan unit
protection.
Earth bonding point

This is the bonding point to which the ESD wrist strap is connected.
37.5 PBA-ATRU-G board
The PBA-ATRU-G board is located to the left, inside the ATRU-U. This board
performs a number of controls and functions of the TRU. It contains a number of
connectors for different signals and a number of jumpers (straps) to set board
parameters.
Figure 37-2 shows the location of the connectors and jumpers on the PBA-ATRU-G
board.

Figure 37-2 PBA-ATRU-G connector and jumper locations
X201 (PA) X202 (PB) ACU1

4 5 6 4 5 6 ACU2
X312 (DA) 1 2 3 1 2 3 X301 (CO) ACU3
2
1 k319
X311 (LR)
1 3 5
2 4 6
X2401 (CA) X2402 (CB) k366 k382 X304 X303 X302

1 2 3 1 2 3
3 2 1
X1
X19
18839
The three ACU connectors interface through the P-OLT back panel to the ACU card.
Connector ACU1 is for P-OLT shelf 1, connector ACU2 is for P-OLT shelf 2 and
connector ACU3 is not used.
The pin layout of the 6-pin RJ45 rack lamp connector is described in Table 37-3.
Table 37-3 Lamp rack connector (X311)
1 CRI_RK_LMP Out Critical alarm rack lamp (Red lamp,

left side, +)
2 MAJ_RK_LMP Out Major alarm rack lamp (Red lamp,

right side, +)
3 MIN_RK_LMP Out Minor alarm rack lamp (Yellow lamp,+)
4 BATD Out –48 V (all lamps, –)
5 LMP_ON Out Power ON (Green lamp, +)
6 — — —
The pin layout of the 2-pin door alarm connector is described in Table 37-4. This
interfaces to the equipment cabinet door sensor.

Table 37-4 Door alarm connector (X312)
1 DOOR ALM A In Door alarm A-wire (BATRET of ACU)
2 DOOR ALM B In Door alarm B-wire (OPTO ACU)
Note — Jumper X20 is a spare jumper.
Table 37-5 describes the ATRU-U physical specifications.
Table 37-5 ATRU-U physical specifications
Height 3.37 in. (8.57 cm)
Width 17.23 in. (47.76 cm)
Depth 10.18 in. (25.85 cm)


38.4 Location 38-3

38.1 Identification
Table 38-1 provides identification information about the BITS-B.
Table 38-1 Identification of BITS-B
3FE 51426 AA BITS-B BITS and LAN interface board BVL3AC2BAA 099999 155524
The BITS-B unit provides:

• signal attenuation of the BITS clock signal to the NT
• signal attenuation of the reflection back to the BITS clock generator
• electromagnetic interference attenuation
• ethernet LAN connector
The BITS-B card is mounted on the OLTS-M backplane at J67 and provides an
RJ-45 connector to connect the primary (PRI) BITS and secondary (SEC) BITS
timing references to the NT cards. A second RJ-45 connector on the cards provides
a 10/100 Mbps Ethernet interface.
The BITS-B card provides protection and attenuation for the BITS signals and also
provides termination for unused Ethernet signals.
The BITS-B is a passive unit. No power interface is required.
Figure 38-1 shows the BITS-B card. See 7342 ISAM FTTU Hardware Installation
and Maintenance Practices for the pinouts for the BITS interface.
Figure 38-1 BITS-B card
LAN
BITS
19338

38.4 Location
The BITS-B unit is mounted on the backplane of the OLTS-M shelf in the power and
connector section at the top of the shelf.



39.1 Identification
Table 39-1 provides identification information about the blank LT filler plates.
Table 39-1 Identification of the blank LT filler plate
3FE 24573 AA — LT filler plate — — —
3FE 51178 AA — 4 Port LT filler plate BVPQAEEKAA — 154157
The blank LT filler plate:

• provides an ESD/EMI seal for unused LT slots in shelves supporting two-port
LTs
• provides a thermal seal for unused LT slots in shelves supporting two-port LTs
• contains mechanical parts only
The four-port LT filler plate:
• provides an ESD/EMI seal for unused LT slots in shelves supporting four-port
LTs
• provides a thermal seal for unused LT slots in shelves supporting four-port LTs
• provides non-functional fiber connectors to park fiber optic cable
Warning — The blank LT filler plate or LT cards must be placed in

unused LT slots to maintain proper operation.
To meet EMC and thermal requirements, blank LT filler plates or LT cards must be
inserted in any unused LT slots.
Note — The ANSI OLTS-K shelf does not need the front and rear
covers installed to meet EMC and thermal requirements as in previous
versions.
Table 39-2 describes the dimensions of the blank LT filler plate.

Table 39-2 Dimensions of the LT filler plate
Description Measurement
Height 16.53 in. (41.9862 cm)
Width 0.98 in. (2.49 cm)
Depth 7.36 in. (18.69 cm)



40.1 Identification
Table 40-1 provides identification information about the blank NT filler plate.
Table 40-1 Identification of the blank NT filler plate
Part Number Mnemonic Description CLEI CPR ECI / Bar code
3FE 24574 AA — Blank NT filler plate — — —
The blank NT filler plate:

• provides an ESD/EMI seal for unused NT slots in shelves
• provides a thermal seal for unused NT slots in shelves
• contains mechanical parts only
Warning — The blank NT filler plate or NT cards must be placed in

unused NT slots to maintain proper operation.
To meet EMC and thermal requirements, blank NT filler plates or NT cards must be
inserted in any unused NT slots in any shelf.
Note — The ANSI OLTS-K shelf does not need the front and rear
covers installed to meet EMC and thermal requirements as in previous
versions.
Table 40-2 describes the dimensions of the blank NT filler plate.
Table 40-2 Dimensions of the NT filler plate
Height 16.53 in. (41.9862 cm)
Width 0.98 in. (2.95 cm)
Depth 7.36 in. (18.69 cm)

41 — EHNT and pluggable optical modules
unit data sheet
41.4 Network interface modules 41-8
41.5 Interfaces and connectors 41-8
41.6 Status LEDs 41-8
41.7 Power 41-10

41.1 Identification
Table 41-1 provides identification information about EHNT-A and the associated
pluggable optical modules while Table 41-2 provides specific information for 1AB
3566300XX modules.
Table 41-1 Identification of EHNT-A and the associated optical modules
Part number Mnemonic Description CLEI CPR ECI/Bar Application

code
3FE 50479 AA EHNT-A Ethernet high capacity BVNIPR0EAB 070BHM 147927 —

network termination
3FE 50479 AB card, version A BVNIPU0EAA 070BHM 149239 —
3FE 51196 AA EHNT-B Ethernet high capacity BVL3ABHBAA 070JMJ 151820 —

network termination
card, version B
(for OLTS-M shelf)
3FE 51026 AA — 10/100/1000 Mb/s SFP, BVL3AA5BAA U73174 146295 —

electrical, 100 m (328
ft), not temperature
hardened (Commercial
range -5°C to +50°C
(23°F to 122°F)) (1) (2) (3)
3FE 25771 Dx — 1-GE-SFP, CWDM, SMF, — — — —

(Refer to Duplex LC connector, 62
Table 41-3) km, not temperature
range 0°C to +45°C
(32°F to 113°F)) (1)
3FE 25772 AA — 1-GE SFP (upstream), VAUIAGUAAA U72812 137841 —

1310 nm tx, 1490 nm rx,
SMF, 10 km,
temperature hardened
(Industrial range -40°C
to +65°C (-40°F to
149°F)) (1)
3FE 25772 AB — 1-GE SFP (downstream), VAUIAGVAAA U72813 137842 —

1490 nm tx, 1310 nm rx,
SMF, 10 km,
to +65°C (-40°F to
149°F)) (1)
(1 of 4)


code
3FE 25773 AA — 1-GE SFP, 850 nm, MMF, VAUIAE1AAA U72499 135570 SX
550 m(4), temperature
hardened (Industrial
(-40°F to 185°F)) (1) (3)
• compliant with
802.3z 1000BASE-SX
PMD
• 275 m with 62.5 uM
MMF (200 MHz * km
@ 850nm fiber)
• 550 m with 50 uM
MMF (500 MHz * km
@ 850nm fiber)
3FE 25773 CA — 1-GE SFP, 850 nm, MMF, BVLIJ0TFAA U72534 136282 SX
550 m (4), not
(Commercial range -5°C
to +50°C (23°F to
122°F)) (1) (3)
• compliant with
802.3z 1000BASE-SX
PMD
• 275 m with 62.5 uM
MMF (200 MHz * km
@ 850nm fiber)
• 550 m with 50 uM
MMF (500 MHz * km
@ 850nm fiber)
3FE 25774 AA — 1-GE SFP, 1310 nm, VAUIAEYAAA U72496 135567 LX10
SMF, 10 km,
to +65°C (-40°F to
149°F)) (1) (3)
3FE 25775 AA — 1-GE SFP, 1310 nm, VAUIAE0AAA U72498 135569 EX

SMF, 40 km,
to +65°C (-40°F to
149°F)) (1) (3)
3FE 25776 AA — 1-GE SFP, 1550 nm, VAUIAF2AAA U72742 136958 ZXU
SMF, 80 km,
to +65°C (-40°F to
149°F)) (1) (3)
3FE 25776 BA — 1-GE SFP, 1550 nm, VAUIAEZAAA U72497 135568 ZXU
SMF, 80 km, not
to +50°C (23°F to
122°F)) (1) (3)
(2 of 4)


code
3FE 28785 AA — 1-GE BX40-U SFP VAUIALWAAA U73573 154268 —

(upstream), 1310 nm tx,
1550 nm rx, SMF, 40 km,
to +85°C (-40°F to
185°F)) (1)
3FE 28785 AB — 1-GE BX40-D SFP VAUIALXAAA U73573 154347 —

(downstream), 1510 nm
tx, 1301 rx, SMF, 40 km,
to +85°C (-40°F to
185°F)) (1)
3FE 50712 AA — 10-GE XFP, 850 nm, BVLIJ0UFAA U72906 139338 SR

MMF, 300 m (5), not
to +50°C (23°F to
122°F)) (1) (3)
3FE 50712 BA — 10-GE XFP, 1310 nm, BVL3AALBAA U73047 142249 LR

SMF, 10 km, not
to +50°C (23°F to
122°F)) (1)
3FE 50712 BB — 10-GE XFP, 1310 nm, VAUIAMHAAA U73591 154615 LR

SMF, 10 km,
to +65°C (-40°F to
149°F)) (1) (3)
3FE 50712 CA — 10-GE XFP, 1550 nm, BVL3AAMBAA U73048 142250 ER

SMF, 40 km, not
to +50°C (23°F to
122°F)) (1) (3)
3FE 50712 CB — 10-GE XFP, 1550 nm, BLV3AA9BAA U73263 148225 ER

SMF, 40 km,
to +65°C (-40°F to
149°F)) (1) (3)
3FE 50712 DA — 10-GE XFP, 1550 nm, — — — —

SMF, 80 km, not
to +50°C (23°F to
122°F)) (1) (3)
3EM 19465 AA — 10-GE XFP, electrical, — — — —

0.3 m, temperature
hardened (for EHNT-A
only) (Industrial range
-40°C to +65°C (-40°F to
149°F)) (1)
(3 of 4)


code
1AB 35663 00XX — 10-GE XFP, 100GHz (Refer to (Refer to (Refer to —

(Refer to DWDM, SMF, 80 km, not Table 41-2) Table 41-2) Table 41-2)
Table 41-2) temperature hardened
to +50°C (23°F to
122°F)) (1) (3)
(4 of 4)
Notes
(1) Do not use unauthorized SFPs or XFPs. Using unauthorized SFPs and XFPs adversely affects the P-OLT, may cause an
unexpected NT reset, and requires operator intervention to fix.
(2) Use shielded CAT5e-grade or better Ethernet cables with electrical SFPs or XFPs.
(3) The EXNT-A AA variant does not support these SFPs or XFPs.
(4) The reach assumes 50 µm MMF.
(5) The reach assumes 50 µm MMF, 2000 MHz/km.
Table 41-2 Specific information for 1AB 35663 00XX modules
Part number Channel Wavelength CLEI CPR ECI/Bar code
1AB356630001 60 1529.55 WOTRAP5GAA U73480 152783

1AB356630002 59 1530.33 WOTRAP6GAA U73480 152827
1AB356630003 58 1531.12 WOTRAP7GAA U73480 152828
1AB356630004 57 1531.90 WOTRAP8GAA U73480 152829
1AB356630005 56 1532.68 WOTRAP9GAA U73480 152830
1AB356630006 55 1533.47 WOTRARAGAA U73480 152831
1AB356630007 54 1534.25 WOTRARBGAA U73480 152832
1AB356630008 53 1535.04 WOTRARCGAA U73480 152833
1AB356630009 52 1535.82 WOTRARDGAA U73480 152834
1AB356630010 51 1536.61 WOTRAREGAA U73480 152835
1AB356630011 50 1537.40 WOTRARFGAA U73480 152836
1AB356630012 49 1538.19 WOTRARGGAA U73480 152837
1AB356630013 48 1538.98 WOTRARHGAA U73480 152838
1AB356630014 47 1539.76 WOTRARJGAA U73480 152839
1AB356630015 46 1540.56 WOTRARKGAA U73480 152840
1AB356630016 45 1541.35 WOTRARLGAA U73480 152841
1AB356630017 44 1542.14 WOTRARMGAA U73480 152842
1AB356630018 43 1542.94 WOTRARNGAA U73480 152843
1AB356630019 42 1543.73 WOTRARPGAA U73480 152844

1AB356630020 41 1544.53 WOTRARRGAA U73480 152845
1AB356630021 40 1545.32 WOTRARSGAA U73480 152846
1AB356630022 39 1546.12 WOTRARTGAA U73480 152847
(1 of 2)

Part number Channel Wavelength CLEI CPR ECI/Bar code
1AB356630023 38 1546.92 WOTRARUGAA U73480 152848
1AB356630024 37 1547.72 WOTRARVGAA U73480 152849
1AB356630025 36 1548.51 WOTRARWGAA U73480 152850

1AB356630026 35 1549.32 WOTRARXGAA U73480 152851
1AB356630027 34 1550.12 WOTRARYGAA U73480 152852
1AB356630028 33 1550.92 WOTRARZGAA U73480 152853
1AB356630029 32 1551.72 WOTRAR0GAA U73480 152854
1AB356630030 31 1552.52 WOTRAR1GAA U73480 152855
1AB356630031 30 1553.33 WOTRAR2GAA U73480 152856
1AB356630032 29 1554.13 WOTRAR3GAA U73480 152857
1AB356630033 28 1554.94 WOTRAR4GAA U73480 152858
1AB356630034 27 1555.75 WOTRAR5GAA U73480 152859

1AB356630035 26 1556.55 WOTRAR6GAA U73480 152860
1AB356630036 25 1557.36 WOTRAR7GAA U73480 152861
1AB356630037 24 1558.17 WOTRAR8GAA U73480 152862
1AB356630038 23 1558.98 WOTRAR9GAA U73480 152863
1AB356630039 22 1559.79 WOTRASAGAA U73480 152864
1AB356630040 21 1560.61 WOTRASBGAA U73480 152865
1AB356630041 20 1561.42 WOTRASCGAA U73480 152866
(2 of 2)
Table 41-3 Specific information for 3FE 25771 XX CWDM modules
Part number Wavelength
3FE 25771 DA 1471 nm
3FE 25771 DB 1491 nm
3FE 25771 DC 1511 nm
3FE 25771 DD 1531 nm
3FE 25771 DE 1551 nm
3FE 25771 DF 1571 nm
3FE 25771 DG 1591 nm
3FE 25771 DH 1611 nm
The EHNT card mounts in the network termination slots (NT-A and NT-B) of the
optical line termination (OLT) shelf.

The EHNT card supports:

• up to 16384 media access control (MAC) address entries with hardware assisted
aging
• up to 8000 IP address entries; hashing may limit the number of IP address entries
to 5000
• up to 12257 routes
• IEEE 802.3x flow control at full duplex
• network timing requirements for BITS I/F logic
The EHNT card provides:

• gigabit Ethernet (GE) optical connectivity to a high-bandwidth Internet protocol
(IP) services network
• pluggable SFP and XFP modules for GE optical connectivity
• management and control interfaces for the 7342 ISAM FTTU
• a 48 Gb/s switch matrix that supports two GE interfaces per line termination (LT)
card (36 in total)
• four fixed 1-GE 1000Base-X using SFP network ports
• one 10-GE network XFP port
• one HiGig (10-GE) NT-to-NT XFP port for EHNT-A
• diagnostic light emitting diodes (LEDs) per port
Note — The EHNT card is not pre-equipped with optical ports. The
base unit has an operating temperature of −40°F to 149°F (−40°C to
65°C). Different versions of optical pluggable modules are available
for each port, some of which provide extended temperature operation.
The EHNT card is an NT subsystem that provides GE optical connectivity to a

high-bandwidth IP services network.
The EHNT-A card has four 1-GE SFP ports for connectivity to a high-bandwidth IP
services network and two 10-GE XFP ports. One 10-GE XFP port connects to the IP
services network and the remaining 10-GE port connects to the other NT card in a
redundant system. Any one or a combination of the network connections can be used,
depending on expected capacity.
The EHNT-B card has four 1-GE SFP ports for connectivity to a high-bandwidth IP
services network and one 10-GE XFP port for connection to the IP services network.
Any one or a combination of the network connections can be used, depending on
expected capacity. Connectivity to the other NT card in a redundant system is
accomplished through the backplane of the OLTS-M shelf.
In addition to providing network termination, the EHNT card performs Ethernet
switching and provides the control and management functions of the
7342 ISAM FTTU. The EHNT card manages the P-OLT, the shelf, and the
switching data path.

The EHNT card manages high-bandwidth IP services for subscribers by providing a

48 Gb/s Ethernet switching matrix. In the downstream direction, high-bandwidth IP
services enter the network termination side of the 7342 ISAM FTTU over optical
connectivity at the EHNT card. The EHNT card switches the IP traffic. The
appropriate packets for each connected subscriber are then forwarded over the
backplane to an LT unit. In the upstream direction, the EHNT card receives Ethernet
packets from the LT units over the backplane. The EHNT card switches the packets
to the high-bandwidth IP services network.
The EHNT card supports inband management traffic received through its
connectors. Local management through a craft terminal is supported by the EHNT
card through craft connections on the alarm control unit (ACU).
The EHNT card can be managed by either a NMS or a local command line interface
(CLI and TL1) on the AACU.
The AB variant of the EHNT-A card replaced the previously available AA variant.
The AB variant is a direct replacement of the AA variant but does not contain the
wire straps. The AA variant is no longer an orderable item.
The EHNT-A and EHNT-B are not interchangeable. The EHNT-A is the NT card for
the OLTS-K shelf configuration and the EHNT-B is the NT card for the OLTS-M
configuration.
41.4 Network interface modules
See Section 48.4 of the NT card unit data sheet for information on network interface
modules.
41.5 Interfaces and connectors
The EHNT supports the LC/UPC connector for connection to the external optical
network.
The EHNT supports the following connectors for the required optical modules that
are Alcatel-Lucent-approved:
• four 1000Base-X SFP connectors for gigabit Ethernet optical connectivity
• one 10-GE network XFP connector
• one HiGig (10-GE) NT-to-NT XFP connector (EHNT-A only)
These connectors are located on the faceplate of the EHNT card. For detailed
backplane pin information, see the 7342 ISAM FTTU Hardware Installation and
41.6 Status LEDs
The front panel contains light emitting diodes (LEDs) for port status, diagnostics of
power, the SFP ports, and the XFP ports. Figure 41-1 shows the front view of the
EHNT-A and Figure 41-2 shows the front view of the EHNT-B.

Figure 41-1 Front view of EHNT-A
ALM PWR ACT
UNIT
LNK TX RX EHNT
ALM PWR ACT
UNIT
1 1
LNK TX RX
1 Gb E
2
3
1 Gb E
4
10 GbE
1
2
1 GbE-1
3
4
10 GbE 1 1 GbE-2
1 GbE-3
1 GbE-4
10 GbE-1
10 GbE-2
(XO)
18153
Figure 41-2 Front view of EHNT-B

UNIT
ALM PWR ACT
LNK TX RX EHNT-B
GE-1 ALM PWR ACT

UNIT
LNK TX RX
GE-1
GE-2
NETWORK
GE-3
GE-2 GE-4
NETWORK
10G
O&M
Tx
GE-3
Rx
GE-1
GE-4
10G
GE-2
GE-3
O&M
GE-4
10G
19043

The port LEDs show the status of the 1-GE and 10-GE ports. The O&M port LEDs
on the EHNT-B card, indicate the out-of-band management traffic activity on the
ACU card (indicated by RX LED). Differing ports are labeled to the left of the LEDs,
but the LEDs show the same information for each. Table 41-4 provides information
about port LEDs.
Table 41-4 EHNT port LEDs
LED Color Display Status
LNK Green OFF No link detected at this port
ON Link detected at this port

TX Green OFF No data activity detected on this TX port
ON Data activity detected on this TX port
RX Green OFF No data activity detected on this RX port
ON Data activity detected on this RX port
Table 41-5 provides information about diagnostic LEDs on the EHNT card.
Table 41-5 EHNT diagnostic LEDs
ALM Red ON Card failure
PWR Green OFF Power off
ON Power on
1 s ON, 1 s OFF Alive (boot SW)
Flashing at received packet Loading software

rate
3.5 s ON, 0.5 s OFF Software is running
ACT Green OFF Standby
ON Active
One pulse (1) Synchronizing
Note
(1) One pulse is equal to 125 ms ON, 125 ms OFF, and exhibits a repetition rate of 2/s.
41.7 Power
The EHNT card is fed by two power branches (BATA and BATB) with a nominal
voltage of −48 V or –60 V and an operating range of −36 V dc to −72 V dc through
its backplane connector.
A fuse is provided to avoid damage to the PBA in case of short circuits. The fuse
rating is 4 A, slow blow.

A hot insertion circuit limits the in-rush current. An electromagnetic compatibility

(EMC) filter is provided to limit the noise coupled onto the battery (BAT) wires.
Table 41-6 lists the physical specifications of the EHNT card.
Table 41-6 EHNT physical specifications
Description Specification (Vertical orientation)
Width 1.2 in. (3 cm)


42 — EXNT-A and pluggable optical
modules unit data sheet
42.7 Power 42-9

42.1 Identification
Table 42-1 provides identification information about EXNT-A and the associated
pluggable optical modules.
Table 42-1 Identification of EXNT-A and the associated optical modules

code
3FE 51230 AA EXNT-A Ethernet XAUI based BVL3ADHBAA 070MXD 156646 —

(extreme-capacity)
network termination
card, version A
(for OLTS-M shelf only)
3FE 51230 AC EXNT-A Ethernet XAUI based BVL3ADXBAB 070PCT 175829 —
(extreme-capacity)
network termination
card, version A,
3FE 51026 AA — 10/100/1000 Mb/s SFP, BVL3AA5BAA U73174 146295 —

electrical, 100 m (328
ft), not temperature
range -5°C to +50°C (23°F
to 122°F)) (1) (2) (3)
3FE 25771 Dx — 1-GE-SFP, CWDM, SMF, — — — —

(Refer to Duplex LC connector, 62
Table 42-2) km, not temperature
range 0°C to +45°C (32°F
to 113°F)) (1)
3FE 25772 AA — 1-GE SFP(upstream),1310 VAUIAGUAAA U72812 137841 —

nm tx, 1490 nm rx, SMF,
10 km, temperature
(-40°F to 149°F)) (1)
3FE 25772 AB — 1-GE SFP (downstream), VAUIAGVAAA U72813 137842 —

1490 nm tx, 1310 nm rx,
SMF, 10 km, temperature
(-40°F to 149°F)) (1)
(1 of 4)


code
3FE 25773 AA — 1-GE SFP, 850 nm, MMF, VAUIAE1AAA U72499 135570 SX
550 m (4), temperature
(-40°F to 185°F)) (1) (3)
• compliant with
802.3z 1000BASE-SX
PMD
• 275 m with 62.5 uM
MMF (200 MHz * km @
850nm fiber)
• 550 m with 50 uM
MMF (500 MHz * km @
850nm fiber)
3FE 25773 CA — 1-GE SFP, 850 nm, MMF, BVLIJ0TFAA U72534 136282 SX
550 m (4), not
to +50°C (23°F to 122°F))
(1) (3)
• compliant with
802.3z 1000BASE-SX
PMD
• 275 m with 62.5 uM
MMF (200 MHz * km @
850nm fiber)
• 550 m with 50 uM
MMF (500 MHz * km @
850nm fiber)
3FE 25774 AA — 1-GE SFP, 1310 nm, SMF, VAUIAEYAAA U72496 135567 LX10
10 km, temperature
(-40°F to 149°F)) (1) (3)
3FE 25775 AA — 1-GE SFP, 1310 nm, SMF, VAUIAE0AAA U72498 135569 EX
40 km, temperature
(-40°F to 149°F)) (1) (3)
3FE 25776 AA — 1-GE SFP, 1550 nm, SMF, VAUIAF2AAA U72742 136958 ZXU
80 km, temperature
(-40°F to 149°F)) (1) (3)
3FE 25776 BA — 1-GE SFP, 1550 nm, SMF, VAUIAEZAAA U72497 135568 ZXU
80 km, not temperature
to 122°F)) (1) (3)
3FE 28785 AA — 1-GE BX40-U SFP VAUIALWAAA U73573 154268 —

(upstream), 1310 nm tx,
1550 nm rx, SMF, 40 km,
(Industrial range -40°C to
+85°C (-40°F to 185°F)) (1)
(2 of 4)


code
3FE 28785 AB — 1-GE BX40-D SFP VAUIALXAAA U73573 154347 —

(downstream), 1510 nm
tx, 1310 rx, SMF, 40 km,
(Industrial range -40°C to
+85°C (-40°F to 185°F)) (1)
3FE 50712 AA — 10-GE XFP, 850 nm, MMF, BVLIJ0UFAA U72906 139338 SR
300 m (5), not
to +50°C (23°F to 122°F))
(1) (3)
3FE 50712 BA — 10-GE XFP, 1310 nm, BVL3AALBAA U73047 142249 LR

SMF, 10 km, not
to +50°C (23°F to 122°F))
(1)
3FE 50712 BB — 10-GE XFP, 1310 nm, VAUIAMHAAA U73591 154615 LR

(-40°F to 149°F)) (1) (3)
3FE 50712 CA — 10-GE XFP, 1550 nm, BVL3AAMBAA U73048 142250 ER

SMF, 40 km, not
to +50°C (23°F to 122°F))
(1) (3)
3FE 50712 CB — 10-GE XFP, 1550 nm, BLV3AA9BAA U73263 148225 ER

(-40°F to 149°F)) (1) (3)
3FE 50712 DA — 10-GE XFP, 1550 nm, — — — —

SMF, 80 km, not
to +50°C (23°F to 122°F))
(1) (3)
3EM 19465 AA — 10-GE XFP, electrical, 0.3 — — — —

m, temperature
hardened (for EHNT-A
only) (Industrial range
-40°C to +65°C (-40°F to
149°F)) (1)
1AB 35663 — 10-GE XFP, 100GHz (Refer to (Refer to (Refer to —

00XX (Refer to DWDM, SMF, 49.71 mi (80 Table 41-2) Table 41-2) Table 41-2)
Table 41-2) km), not temperature
to 122°F)) (1) (3)
3FE 53441 AC — B+ I-temp SFP for BVL3AHWBA U72BER 175542 —

termination of one PON A
with the GLT8-A (1)
(3 of 4)


code
3FE 53441 AA — B+ C-temp SFP for VAI2AHXNAA U72CGT 182431 —

termination of one PON
with the GLT8-A (1)
3FE 53441 BA — C+ C-temp SFP for BVL3AHXBAA U72BES 175543 —

with the GLT8-A (1)
3FE 53441 BC — C+ I-temp SFP for BVL3AHYBAA O70YWH 175545 —
with the GLT8-A (1)
(4 of 4)
Notes
(1) Do not use unauthorized SFPs or XFPs. Using unauthorized SFPs and XFPs adversely affects the P-OLT, may cause an
unexpected NT reset, and requires operator intervention to fix.
(2) Use shielded CAT5e-grade or better Ethernet cables with electrical SFPs or XFPs.
(3) The EXNT-A AA variant does not support these SFPs or XFPs.
(4) The reach assumes 50 µm MMF.
(5) The reach assumes 50 µm MMF, 2000 MHz/km.
Table 42-2 Specific information for 3FE 25771 XX CWDM modules
Part number Wavelength
3FE 25771 DA 1471 nm

3FE 25771 DB 1491 nm
3FE 25771 DC 1511 nm
3FE 25771 DD 1531 nm
3FE 25771 DE 1551 nm
3FE 25771 DF 1571 nm
3FE 25771 DG 1591 nm
3FE 25771 DH 1611 nm
The EXNT-A card mounts in the network termination slots (NT-A and NT-B) of the
optical line termination (OLTS-M) shelf.
The EXNT-A card supports:
• up to 16384 media access control (MAC) address entries with hardware assisted
aging
• up to 2000 IP address entries on the EXNT-A card
• up to 993 routes on the EXNT-A card
• IEEE 802.3x flow control at full duplex
• network timing requirements for BITS I/F logic
• IEEE 1588v2 Precision Timing Protocol (PTP)

The card provides:

• gigabit Ethernet (GE) optical connectivity to a high-bandwidth Internet protocol
(IP) services network
• pluggable SFP and XFP modules for GE optical connectivity
• management and control interfaces for the 7342 ISAM FTTU
• 200 Gb switch matrix
• XAUI and eHCL interfaces per line termination (LT) card
• 10 GE XAUI link to each GLT4 card and each GLT8 card
• 2.5 GE eHCL link to each GLT2-C card
• four 10 GE XAUI links with the peer NT card (only two links are used)
• one XAUI link to the ACU card
• two 1-GE SFP network ports
• two 10-GE XFP network ports
• network synchronization of the NT system clock
• BITS/SETS
• 1588v2 PTP
• diagnostic light emitting diodes (LEDs) per port
Note — The EXNT-A card is not pre-equipped with optical ports.

The base unit has an operating temperature of −40°F to 149°F (−40°C
to 65°C). Different versions of optical pluggable modules are
available for each port, some of which provide extended temperature
operation.
The EXNT-A card is an NT subsystem that provides GE optical connectivity to a

high-bandwidth IP services network.
The EXNT-A card has two 1-GE SFP ports and two 10-GE XFP ports for
connectivity to a high-bandwidth IP services network. Any one or a combination of
the network connections can be used, depending on expected capacity. Connectivity
to the other NT card in a redundant system is accomplished through a XAUI interface
in the backplane of the shelf.
In addition to providing network termination, the EXNT-A card performs Ethernet
switching and provides the control and management functions of the
7342 ISAM FTTU. The EXNT-A card manages the P-OLT, the shelf, and the
switching data path.
The EXNT-A card manages high-bandwidth IP services for subscribers by providing
a 200 Gb/s Ethernet switching matrix. In the downstream direction, high-bandwidth
IP services enter the network termination side of the 7342 ISAM FTTU over optical
connectivity at the EXNT-A card. The EXNT-A card switches the IP traffic. The
appropriate packets for each connected subscriber are then forwarded over the
backplane to an LT unit. In the upstream direction, the EXNT-A card receives
Ethernet packets from the LT units over the backplane. The EXNT-A card switches
the packets to the high-bandwidth IP services network.

The EXNT-A card supports inband management traffic received through its
connectors. Local management through a craft terminal is supported by the EXNT-A
card through craft connections on the alarm control unit (ACU).
The EXNT-A card can be managed by the 5520 AMS network element management
interface or the local command line interface (CLI and TL1) on the ACU.
See Section 48.4 of the NT card unit data sheet for information on network interface
modules.
The EXNT-A supports the LC/UPC connector for connection to the external optical
network.
The EXNT-A supports the following connectors for the required optical modules
that are Alcatel-Lucent-approved:
• two 1000Base-X SFP connectors for gigabit Ethernet optical connectivity
• two 10-GE network XFP connector
These connectors are located on the faceplate of the EXNT-A card. For detailed
backplane pin information, see the 7342 ISAM FTTU Hardware Installation and
42.6 Status LEDs
The front panel contains light emitting diodes (LEDs) for the individual 1 GE and 10
GE port status, ACU LAN port status, card alarm indication, and NT operational
state. Figure 42-1 shows the front view of the EXNT-A.

Figure 42-1 Front view of EXNT-A
UNIT
ALM PWR ACT
LNK TX RX EXNT-A
GE-1 ALM PWR ACT
UNIT
LNK TX RX
GE-1
NETWORK
NETWORK
GE-2
10G1
GE-2 10G2
O&M
Tx
10G1
Rx
GE-1
10G2
O&M GE-2
10G-1
GE-4
10G-2
19445
Table 42-3 defines the UNIT LEDs on the EXNT-A card.
Table 42-3 EXNT-A UNIT LEDs
ALM Red ON Card failure

PWR Green OFF Power off (no power on board)
ON Power on
1 s ON, 1 s OFF Alive (boot SW)
Flashing at received packet Loading software

rate
3.5 s ON, 0.5 s OFF Software is running
ACT Green OFF Standby NT
ON Active NT
One pulse (1) Synchronizing
Note
(1) One pulse is equal to 125 ms ON, 125 ms OFF, and exhibits a repetition rate of 2/s.

The NETWORK LEDs indicate the status and traffic flow of the 1-GE (GE-1 and
GE-2) and the 10-GE (10G1 and 10G2) ports. The O&M LEDs indicate the
out-of-band management traffic activity at the LAN connector on the ACU card.
Differing ports are labeled to the left of the LED group, but the LEDs show the same
information for each. Table 42-4 provides information about the NETWORK and
O&M LEDs.
Table 42-4 NETWORK and O&M LEDs
LNK Green OFF No link detected at this port
ON Link detected at this port
TX Green OFF No data activity detected on this TX port
ON Data activity detected on this TX port
RX Green OFF No data activity detected on this RX port
ON Data activity detected on this RX port
42.7 Power
The EXNT-A card is fed by two power branches (BATA and BATB) with a nominal
voltage of −48 V or –60 V and an operating range of −40.5 V dc to −72 V dc through
its backplane connector.
A hot insertion circuit limits the in-rush current. An electromagnetic compatibility
(EMC) filter is provided to limit the noise coupled onto the battery (BAT) wires.
Table 42-5 lists the physical specifications of the EXNT-A card.
Table 42-5 EXNT-A physical specifications
Description Specification (Vertical orientation)
Width 1.2 in. (3 cm)




43.1 Identification
Table 43-1 provides identification information about FILT-A and FILT-B.
Table 43-1 Identification of FILT-A and FILT-B

code
3EM 17820 AA FILT-A Battery filter adapter — — —

card
3FE 51428 AA FILT-B Battery filter adapter — — —

card
3FE 51428 AB FILT-B Battery filter adapter — — —

card
The FILT-A and FILT-B provide:

• filtering for the dc mains, bolted onto the power connectors of the ALTS-N and
OLTS-M shelf in the shelf power input area
• three battery filter caps, one each for BAT_A-FG, BAT_B-FG, and
BAT_RET-FG or BAT_RET-EG
• CE Mark, EN55022, and EN300386 EMC compliance
In the shelf power input area, the FILT-A or FILT-B are installed on the Battery A,
Battery B, and Battery Return power connectors of the ALTS-N or OLTS-M shelf.
The FILT-A or FILT-B filters the dc mains on the shelf. Figure 43-1 shows the
FILT-A on the backplane of the shelf. The FILT-B is not shown, since the FILT-B
is always part of the backplane assembly of the OLTS-M shelf.

Figure 43-1 FILT-A on the ALTS-N backplane
Short male/female
standoff External tooth
External tooth lockwasher
lockwasher
Long male/female M5 locknuts
standoff
FILT PBA
Hex nut Split
lockwasher
M3 flat
washer Hex nut
Split
M3X10 MM lockwasher
captive screw
Power
connection
Split
lockwasher
Hex nut
Protective cover
18177
Shelf power distribution

The shelf and the integrated fan are powered from the TRU using two redundant
branches A and B in a 2-wire or 3-wire configuration.
Power and grounding signals

Table 43-2 describes information about signal identification.
Table 43-2 Signal identification
A 2-wire configuration has the same three power cables, but no separate grounding.
Grounding is provided through the BATRET cable, when the two Faston bridges are
equipped on the backplane, one in the LT area and one in the fan area.
A 3-wire configuration has three power cables (BATA, BATB, and BATRET) and a
separate grounding (frame ground) provided by the mechanical connection with the
rack.

The power signals BATA, BATB, and BATRET are distributed through the
backplane and feed the cards and the fan unit.
Three battery filter caps are provided on the FILT-A and FILT-B, one each for
BAT_A-FG, BAT_B-FG, and BAT_RET-FG or BAT_RET-EG.
The FILT-A or FILT-B kit contains male/female standoffs, lock washers, nuts, and
other hardware needed to install the FILT-A or FILT-B on the backplane power
connectors. See the 7342 ISAM FTTU Hardware Installation and Maintenance
Practices for installation instructions.
Figure 43-2 shows the caution label on the backplane of the shelf.
Figure 43-2 Caution label on the shelf backplane
Ene
rgy
Haz
ard
18176
Tables 43-3 and 43-4describes the physical specifications of the FILT-A or FILT-B
card.
Table 43-3 FILT-A physical specifications
Height 1 in. (2.5 cm)
Width 4.8 in. (12.2 cm)
Depth 1.4 in. (3.5 cm)
Table 43-4 FILT-B physical specifications
Height 1.49 in. (3.78 cm)
Width 5.91 in. (15.01 cm)
Depth 1.4 in. (3.5 cm)

44.4 Optical budgets 44-4
44.7 Power 44-7

44.1 Identification
Table 44-1 provides identification information about the GLT2.
Table 44-1 Identification of GLT2
Part Number Mnemonic Description CLEI CPR ECI/Bar

code
3FE 50385 AA GLT2-A GPON line termination with 2 PONS BVNIRS0EAB 070BMU 145814
asymmetric, eHCL, temperature hardened,
version A
3FE 51039 AA GLT2-B GPON line termination with 2 PONS BVNIRT0EAA 070EGZ 146791
asymmetric, eHCL, temperature hardened,
version B
3FE 51305 AA GLT2-C GPON line termination with 2 PONS BVNISV0EAA 070KAM 152707
asymmetric, eHCL/XAUI, temperature
hardened, version C
Features and application notes specific to the GLT2 card include:

• two PON interfaces that supports a maximum of 128 indoor or outdoor ONTs per
GLT2 card
• two eHCL interfaces between the NT cards and each LT card with a throughput
capacity of 4 Gb/s (GLT2-A and GLT2-B)
• LT communication interface to NT is determined by NT type (GLT2-C):
• EXNT-A — one XAUI lane (2.5 Gb/s) to NTA and NTB with a 5 Gb/s throughput
capacity
• EHNT-B — one eHCL lane (2 Gb/s) to NTA and NTB with a 4 Gb/s throughput
capacity
For features and application notes common to all LT cards, see Section 47.2 of
the LT card unit data sheet.
The GLT2 is a line termination (LT) card that provides connectivity between the
network termination (NT) cards and the optical network terminals (ONTs). The LT
card is plugged in the P-OLT shelf, together with the two NT cards and an alarm
control unit (ACU). The LT cards and the NT cards perform the optical line
termination (OLT) function as specified in ITU G.984.1. The OLT is connected
through a single fiber to the ONTs.

The NT cards are central shelf controllers that provide two Ethernet switches. Each
NT is connected to an LT card by a communication link. Each LT card has redundant
communication links to the active and standby NT cards. GLT2-A and GLT2-B
cards support 2 Gb/s eHCL links. The GLT2-C can operate in one of two
communication modes, either 2 Gb/s eHCL or 2.5 Gb/s XAUI. The communication
mode is determined by the active NT card type. With EHNT cards the eHCL link
mode is used and with EXNT cards the XAUI link mode is used.
The eHCL/XAUI interface provides a point-to-point transmission to and from the
NT cards for network access, implementing an Ethernet packet-based interface. The
communication links support load sharing over the two redundant links. The eHCL
links support a throughput capacity of 4 Gb/s RX and TX and the XAUI links support
a throughput of 5 Gb/s RX and TX to the NTs to handle subscriber traffic.
The GLT2 card contains a media access controller (MAC) that provide the interfaces
towards the PON. The MAC transport channel is asymmetric with a 2.488 Gb/s line
rate downstream and a 1.244 Gb/s line rate upstream on the PON interface.
The GLT2 card contains a 12 Gb/s packet switch that supports Ethernet adaptation
for VLAN functions such as priority mapping, bridging and crossconnect,
processing, and destination port selection. The switch supports the processing of
voice, data, and IPTV video services.
There are three versions of the GLT2 cards: version A, version B and version C.
Table 44-2 describes the differences.
Table 44-2 GLT2-A, GLT2-B and GLT2-C differences
GLT2 GLT2-A GLT2-B GLT2-C

features
FEC Downstream FEC Downstream and upstream Downstream and upstream

support. Upstream FEC support FEC support
FEC is not
supported.
Multicast Multicast Multicast capability which Multicast capability which

traffic rate capability which allows the GLT2-B to allows the GLT2-C to
limits the GLT2-A duplicate multicast streams duplicate multicast streams
to 2 Gb/s traffic between both GPON between both GPON
per GPON interfaces. This allows the interfaces. This allows the
interface. GLT2-B to surpass 4 Gb/s GLT2-C to surpass 4 Gb/s
towards both GPON towards both GPON
interfaces and achieve interfaces and achieve
maximum downstream line maximum downstream line
rates (2.4 Gb/s). rates (2.4 Gb/s)
Downstream — Supported Supported

rate limiting
per ONT
Flow — Supported Supported

mirroring
CVLAN — Supported Supported

bridging
mode
PON Up Up Down
interface
connector
orientation
(1 of 2)

GLT2 GLT2-A GLT2-B GLT2-C

features
LT to NT link eHCL eHCL eHCL and XAUI

interface
(2 of 2)
44.4 Optical budgets
See Section 47.4 of LT card unit data sheet for information on optical budgets.
44.5 Status LEDs
The GLT2 front panel contains five LEDs indicating power and alarm status.
Table 44-3 describes the LEDs.
Table 44-3 GLT2 LEDs
LED Description Color Display Status
PWR This LED indicates that Green ON Power on

normal power is being
provided to the card. OFF Power off
Blinking Initialization
ALM This LED indicates that Red ON Alarm is present on board

the card has a local
hardware failure present. OFF No alarm is present on
board
SF1 This LED indicates that Yellow ON Alarm is present on PON
SF2 the PON facility is in facility. Indicates loss of
Signal Fail mode. signal on PON.
OFF No alarm present on PON

facility.
The GLT2 front panel has two SC/UPC connectors for interfaces to the PON. The
connecting fiber cable can be 1.6-mm, 2.0-mm or 3.0-mm single mode fiber cable.
Figure 44-1 shows the front view of the GLT2-A card.

Figure 44-1 Front view of the GLT2-A card
18146
Figure 44-2 shows the side view of the GLT2-A card and the card ejection handles.

Figure 44-2 Side view of the GLT2-A card
18147
The front panel contains status LEDs described in Section 44.5.

For additional information on interfaces and connections common to all LT cards,

see Section 47.6 of LT card unit data sheet.
44.7 Power
See Section 47.7 of LT card unit data sheet for information on power.
Table 44-4 describes the physical specifications of the GLT2 card.
Table 44-4 GLT2 physical specifications

Width 0.98 in. (2.5 cm)
Weight ± 2.0 lb (0.91 kg)
Temperature range –40°F to 149°F (–40°C to 65°C)


45.7 Power 45-5

45.1 Identification
Table 45-1 provides identification information about the GLT4.
Table 45-1 Identification of GLT4

code
3FE 51034 AA GLT4-A GPON line termination with 4 PONs BVL3ACMBAA 070KCN 152823
hardened, fiber routing down
3FE 51034 AC GLT4-A GPON line termination with 4 PONs BVL3AD7BAA 070KCN 162833
hardened, fiber routing down, RSSI
optics
3FE 51034 AG GLT4-A GPON line termination with 4 PONs BVL3AGSBAA 070XBW 172867
optics
3FE 53232 AA GLT4-D GPON line termination with 4 PONs BVL3AHHBAA 070YGT 174717
asymmetric, eHCL/XAUI, fiber routing
down, C+ optics with RSSI capabilities
(not temperature hardened)
3FE 53232 AB GLT4-D GPON line termination with 4 PONs — — —
asymmetric, eHCL/XAUI, fiber routing
down, C+ optics with RSSI capabilities
(not temperature hardened)
The GLT4 card provides:

• four PON interfaces that supports a maximum of 256 indoor or outdoor ONTs per
GLT4 card
• RSSI capable optics on the AC and AG variants of the GLT4-A card and the
GLT4-D card
• extended capabilities with Class C+ optics on the GLT4-D card
• LT communication interface to NT is determined by NT type:
• EHNT-B — one eHCL lane (2 Gb/s) to NTA and NTB with a 4 Gb/s throughput
capacity
• EXNT-A — four XAUI lanes (10 Gb/s) to NTA and NTB with a 20 Gb/s throughput
capacity

The GLT4 is a line termination (LT) card that provides connectivity between the
network termination (NT) cards and the optical network terminals (ONTs). The LT
card is plugged in the P-OLT shelf, together with the two NT cards and an alarm
control unit (ACU). The LT cards and the NT cards perform the optical line
termination (OLT) function as specified in ITU G.984.1. The OLT is connected
through a single fiber to the ONTs and will support a maximum of 64 ONTs per
PON.
NT is connected to an LT card by a communication link. Each LT card has redundant
communication links to the active and standby NT cards. The LT card can operate in
one of two modes of communication, either the 2 Gb/s (eHCL) or the 10Gb/s (XAUI)
mode. The communication mode is determined by the active NT card type. When the
EHNT-B card type is detected, the 2 Gb/s operating mode is configured. When the
EXNT-A card type is detected, the 10 Gb/s operating mode is configured.
The communication interface provides a point-to-point transmission to and from the
communication links support load sharing over the two redundant links. The eHCL
links support a throughput capacity of 4 Gb/s RX and TX and the XAUI links support
a throughput capacity of 20 Gb/s RX and TX to the NTs to handle subscriber traffic.
The GLT4 card contains a media access controller (MAC) that provide the interfaces
rate downstream and a 1.244 Gb/s line rate upstream on the PON interface.
The GLT4 card contains a 12 Gb/s packet switch that supports Ethernet adaptation
for VLAN functions such as priority mapping, bridging and crossconnect,
processing, and destination port selection. The switch supports the processing of
voice, data, and IPTV video services.
The RSSI capable optics on the GLT4-A, (AC and AG variants), and GLT4-D
provides the ability to view a summary of the operational status of PON port optics.
Using a TL1 command, the user can view a report of the receive and transmit optical
power levels, laser bias voltage and current, and the temperature of the optics
module.
The class C+ optics on the GLT4-D card provides an extended reach of 60 km and
an enhanced receive sensitivity.
45.5 Status LEDs
The GLT4 front panel contains six LEDs indicating power and alarm status.
Table 45-2 describes the LEDs.

PWR This LED indicates that Green ON Power on

normal power is being
provided to the card. OFF Power off
Blinking Initialization
ALM This LED indicates that Red ON Alarm is present on board

the card has a local
hardware failure present. OFF No alarm is present on
board
SF1 This LED indicates that Yellow ON Alarm is present on PON

SF2 the PON facility is in facility. Indicates loss of
Signal Fail mode. signal on PON.
SF3
SF4 OFF No alarm present on PON
facility.
The GLT4 front panel has four SC/UPC connectors for interfaces to the PON. The
connecting fiber cable can be 1.6-mm, 2.0-mm or 3.0-mm single mode fiber cable.
Figure 45-1 shows the front view of the card.
Figure 45-1 Front view of the GLT4 card
GLT4-A
PWR
ALM
1
PON SF
2
3
4
DANGER
INVISIBLE LASER
RADIATION WHEN
DISCONNECTED
AVOIDE DIRECT
EXPOSURE TO BEAM
PON1
PON2
PON3
PON4
19073

Figure 45-2 shows the side view of the card and the card ejection handles.
Figure 45-2 Side view of the GLT4 card
13760 13754 19074

45.7 Power

Width 0.98 in. (2.5 cm)
Temperature range GLT4-D AA variant 0°F to 122 °F (0°C to 50°C)

GLT4-D AB variant 0°F to 149 °F (0°C to 65°C)

46 — GLT8 and pluggable optical modules
unit data sheet
46.7 Power 46-7
46.9 Constraints 46-8

46.1 Identification
Table 46-1 provides identification information about the GLT8 and the associated
pluggable optical modules.
Table 46-1 Identification of GLT8 and the associated optical modules

code
3FE 68218 AA GLT8-A GPON line termination for 8 PONs BVL3AX4BAA 072HSM 188121
asymmetric, XAUI, temperature
capability
Requires an orderable SFP for each PON
3HG 01122 AA GLT8-A GPON line termination for 8 PONs — — —

capability
Supplied with B+ I-temp SFPs for
termination with 4 PONs; requires an
orderable SFP for each additional PON
3HG 01122 AB GLT8-A GPON line termination for 8 PONs — — —

capability
Supplied with B+ C-temp SFPs for
3HG 01122 AC GLT8-A GPON line termination for 8 PONs — — —

capability
Supplied with C+ C-temp SFPs for
3HG 01122 AD GLT8-A GPON line termination for 8 PONs — — —

capability
Supplied with C+ I-temp SFPs for
(1 of 2)


code
3HG 01122 AE GLT8-A GPON line termination for 8 PONs — — —

capability
Supplied with B+ I-temp SFPs for
3FE 53441 AC — B+ I-temp SFP for termination of one BVL3AHWBAA U72BER 175542
PON with the GLT8-A (1)
3FE 53441 AA — B+ C-temp SFP for termination of one VAI2AHXNAA U72CGT 182431
3FE 53441 BA — C+ C-temp SFP for termination of one BVL3AHXBAA U72BES 175543
3FE 53441 BC — C+ I-temp SFP for termination of one BVL3AHYBAA O70YWH 175545
(2 of 2)
Note
(1) Do not use unauthorized SFPs. Using unauthorized SFPs adversely affects the P-OLT, may cause an unexpected GLT8 reset,
and requires operator intervention to fix.
The GLT8 card provides:

• eight PON interfaces that supports a maximum of 512 indoor or outdoor ONTs
per GLT8 card
• PON interfaces that use pluggable SFPs to allow greater flexibility; the SFPs
must be Alcatel-Lucent-approved SFPs
• a replacement for the GLT4 card, with the capability to support eight PONs
instead of four PONs
• the ability to co-exist with GLT4 cards
• RSSI capability and IPv6 ready
• LT communication interface to EXNT-A NT cards through two XAUI lanes (10
Gb/s) to NTA and NTB with a 20 Gb/s throughput capacity; the GLT8 card does
not communicate with the EHNT NT cards
• support for Time of Day (ToD) for use in mobile back-haul applications
The GLT8 card does not support the following:

• LT-based IP anti-spoofing
• alarms for invalid or uninstalled SFP optical modules

The GLT8 is a line termination (LT) card that provides connectivity between
EXNT-A NT cards and the optical network terminals (ONTs). LT cards are installed
in the P-OLT shelf, together with two NT cards and an alarm control unit (ACU). The
LT cards and the NT cards perform the optical line termination (OLT) function as
specified in ITU G.984.1. The LT is connected through a single fiber to the ONTs
and will support a maximum of 64 ONTs per PON.
NT is connected to an LT card by an internal communication link. The GLT8 card
has two 10Gb/s (XAUI) communication links, one to the active EXNT-A NT card
and one to the standby EXNT-A NT card.
The communication interface provides a point-to-point transmission to and from the
communication links support load sharing over the two redundant links. The GLT8
communication links support a throughput capacity of 20 Gb/s RX and TX to the
EXNT-A NT cards to handle subscriber traffic.
The LT cards contain a media access controller (MAC) that provide the interfaces
rate downstream and a 1.244 Gb/s line rate upstream on each PON interface.
The LT cards contain a 30 Gb/s IWF switch that supports Ethernet adaptation for
VLAN functions such as priority mapping, bridging and crossconnect, processing,
and destination port selection. The switch supports the processing of voice, data, and
IPTV video services.
The RSSI capability of the GLT8 provides the ability to view a summary of the
operational status of the SFPs used at the PON ports. Using a TL1 command, the user
can view a report of the receive and transmit optical power levels, laser bias voltage
and current, and the temperature of each SFP.
46.5 Status LEDs
The GLT8 front panel has LEDs indicating card power and alarm status, and the
activity of the SFPs and terminated PONs. Table 46-2 describes the LEDs.
PWR This LED indicates the — OFF Power off

status of power being
provided to the card. Green ON Power on
Blinking Initialization/download
(1 of 2)

ALM This LED indicates alarm — OFF No alarms are present on

status of the card. the card
Red ON One or more alarms are

present on the card
SFP1 These LEDs indicate the — OFF The PON is not active and
SFP2 activity status of the SFPs it is safe to remove the SFP
and the terminated PONs. or disconnect the fiber
SFP3 from the SFP.
SFP4
Green ON The PON is provisioned and
SFP5 active without errors.
SFP6
Yellow ON The PON is provisioned but
SFP7
none of the provisioned
SFP8 ONTs are ranged.
Red ON The transmitter has failed

or there is no
communication to the SFP.
(2 of 2)
The GLT8 front panel has eight SFP ports for fiber connections to PONs. The SFP
ports are angled towards the bottom of the card faceplate to allow fibers coming from
the bottom part of the shelf to be connected to the SFPs. The GLT8 can be ordered
with four SFPs pre-installed or SFPs can be ordered and installed as needed. The
SFPs must be Alcatel-Lucent-approved SFPs; see Table 46-1 for more information.
The connecting fiber cable can be 1.6-mm, 2.0-mm or 3.0-mm single mode fiber
cable.
Figure 46-1 shows the front view of the card.

Figure 46-1 Front view of the GLT8 card
23727
Figure 46-2 shows the side view of the card and the card ejection handles.

Figure 46-2 Side view of the GLT8 card
23728

46.7 Power
(1 of 2)

Width 0.98 in. (2.5 cm)

Temperature range GLT8-A –40°F to 149°F (–40°C to 65°C)
(2 of 2)
46.9 Constraints
The primary port must be set to the odd port of the adjacent pair to allow for correct
GLT8-A support for PON protection.

47.4 Optical budgets for GLTx cards 47-3
47.7 Power 47-5

47.1 Identification
Table 47-1 identifies the sections that provide identification information specific to
each LT card type.
Table 47-1 LT card identification information
LT card See
Identification of GLT2 Section 44.1
Identification of GLT4 Section 45.1
Identification of GLT8 and the associated optical modules Section 46.1
The LT card provides:

• SC/UPC PON interface connectors (GLT2 and GLT4) or SFPs (GLT8)
• a line rate of 2.488 Gb/s downstream and 1.244 Gb/s upstream
• a 12 Gb/s packet switch (GLT2)
• 15 Gb/s IWF (GLT4)
• 30 Gb/s IWF (GLT8)
• Ethernet adaptation that supports VLAN functions
• reference clocks that generate PON clocks
• an on-board controller (OBC) for control and status
• the ability to be hot inserted or extracted
• an operating temperature range as follows:
• GLT2, GLT4-A, and GLT8-A: –40°F to 149°F (–40°C to 65°C)
• GLT4-D AA: 0°F to 122 °F (0°C to 50°C)
• GLT4-D AB: 0°F to 149 °F (0°C to 65°C)
• reach capacity of 18.6 miles (30 km) with the GLT2-x and GLT4-A
• reach capacity of 37.3 miles (60 km) with the GLT4-D (Class C+ optics)
• reach capacity of 18.6 miles (30 km) with the GLT8-A (Class B+ optics)
• reach capacity of 37.3 miles (60 km) with the GLT8-A (Class C+ optics)
For features and application notes specific to each LT card type, use Table 47-2 to
locate information.
Table 47-2 LT card features and application notes
LT card See
GLT2 Section 44.2
GLT4 Section 45.2
GLT8 Section 46.2

Table 47-3 identifies the sections that describe each LT card type.
Table 47-3 LT card general description
LT card See
GLT2 Section 44.3
GLT4 Section 45.3
GLT8 Section 46.3
47.4 Optical budgets for GLTx cards
Table 47-4 provides the optical budgets of GLT2, GLT4, and GLT8 cards.
Warning — Operating equipment outside of its tested and

documented performance characteristics and causing an optical
overload may cause damage to equipment components, such as APD
receivers, affect service delivery, and void any component or system
warranties.
Table 47-4 Optical budgets of the GLTx cards
Description Minimum Typical Maximum

Transmitting budgets
TX nominal bit rate — 2488.32 Mbit/s —

2.488 Gb/s
TX central wavelength single fibre 1480 nm — 1500 nm

Line code = Scrambled NRZ — — —
Mask of TX eye diagram — Per G.984.2 —
Minimum ORL of ODN at Olu and Old — more than 32 —
B+ optics, TX output power (1) 1.5 dBm — 5.0 dBm
C+ optics, TX output power(2) 3.0 dBm — 7.0 dBm
TX extinction ratio (Class B+ and C+ optics) 8.2 dB — 13.0 dB

(1)
TX spectral width for B+ optics 0.1 nm — 0.9 nm
TX spectral width for C+ optics 0.1 nm — 0.6 nm
TX side mode suppression 30 dB — —
Receiving budgets
RX nominal bit rate — 1244.16 Mbit/s —

1.244 Gb/s
(1 of 2)

RX wavelength single and dual fibre 1260 nm 1310 nm 1360 nm
Line code = Scrambled NRZ — — —
Maximum reflectance of equipment, — less than -20 dB —

measured at receiver wavelength
Minimum ORL of ODN at Oru and Ord — more than 32 —
RX BER — 1E10-10 —
RX optical sensitivity (Class B+ optics) (3) –28.0 dB — —
RX optical overload (Class B+ optics) (3) –8.0 dBm — —
RX optical sensitivity (Class C+ optics) (2) (3) -32.0 dBm — —
RX optical overload (Class C+ optics) (2) (3) -12.0 dBm — —
Link distance (Class B+ optics) — — 21.74799 miles

(35 km) (4)
Link distance (Class C+ optics) — — 37.3 miles

(60 km) (4)
(2 of 2)
Notes
(1) GPON Class B+ optical link budgets are specified as a usable 28dB of optical budget. The typical
value of +1.5dBm minimum transmit level is specified along with a minimum extinction ratio (ER)
of 8.2dB in order to obtain this 28dB budget. Additionally a GLT may exhibit a minimum ER of 7.5dB
(in CO environment) or 6.0dB (in outdoor environment) which is compensated with a higher
minimum value of +2.0 dBm optical TX power in order to continue to guarantee an operating link
budget of 28dB.
(2) For Class C+ application, the use of FEC is mandatory for performance levels.
(3) When the optical level is outside its operating range, a levello or levelhi alarm is raised, depending
on the configuration. The low and high optical power thresholds differ depending on the ONT
variant. See the ONT unit data sheets in the 7342 ISAM FTTU ONT Product Information Manual for
more information.
(4) The optical link budget is defined by both loss and bandwidth characteristics. The loss
characteristic is determined by the difference between the optical transmitter and optical
receiver for each direction. The bandwidth characteristic is reflected by the maximum link
distance parameter of each OLT and ONT transmitter specification, and is limited by the smaller
of the upstream and downstream values.
47.5 Status LEDs
The front panel of an LT card contains status LEDs. Table 47-5 identifies the
sections that describe the LEDs specific to each LT card type.
Table 47-5 LT card LEDs
LT card See
GLT2 LEDs Section 44.5

Table 47-6 identifies the sections that describe the interfaces and connections
specific to each LT card type. The information that follows Table 47-6 is common to
all LT cards.
Table 47-6 LT card interfaces and connections
LT card See
GLT2 Section 44.6
GLT4 Section 45.6

GLT8 Section 46.6
The front panel contains card ejection handles that can remove the LT card from the
OLT shelf. The LT cards provide hot insertion and removal capability. The LT cards
can be plugged in and removed from a live shelf without affecting the operation of
any other cards.
The LT card connections with external CO equipment are provided on the P-OLT
backplane. The connections include:
• point-to-point eHCL and XAUI interfaces, depending on the LT card
• special lines:
• LT identification address lines
• LT control/status lines
• P-OLT related interfaces
The backplane connectors are female compliant press-fit connectors with 5-row
pinning and 2-mm pitch.
47.7 Power
The LT card is powered through the backplane of the P-OLT shelf at –48 V dc or
–60 V dc.
Table 47-7 identifies the sections that describe the physical specifications of each LT
card type.
Table 47-7 LT card physical specifications
LT card Specification
GLT2 physical specifications Section 44.8
(1 of 2)

LT card Specification
(2 of 2)

48.7 Power 48-17
48.9 Supported diagnostic parameters per SFP or XFP 48-18

48.1 Identification
Table 48-1 identifies the sections that provide identification information specific to
each NT card type.
Table 48-1 NT card identification information
NT card See
Identification of EHNT Section 41.1
Identification of EXNT-A Section 42.1
Table 48-2 identifies the sections that provide feature and application information
specific to each NT card type.
Table 48-2 NT card features and application notes
NT card See
EHNT Section 48.2
EXNT-A Section 42.2
Table 48-3 identifies the sections that describe each NT card type.
Table 48-3 NT card general description
NT card See
EHNT Section 41.3

EXNT-A Section 42.3
Figure 48-1 shows the physical differences between an optical and electrical SFP.

Figure 48-1 Optical and electrical SFP module components
Optical SFP Electrical SFP
Release clasp Case temperature

probe point
Receiver (Rx)
Transmitter (Tx)
18389
Figure 48-2 shows an electrical SFP installed in an NT card port.
Figure 48-2 Electrical SFP in an NT card
EHNT-B
Electrical ALM PWR ACT
UNIT
LNK TX RX
SFP GE-1
GE-2
NETWORK
GE-3
GE-4
10G
O&M
Tx
Rx
GE-1
GE-2
GE-3
GE-4
10G
19251
Optical module power and modulation frequencies

Table 48-4 describes the power propagation and modulation frequencies of the
optical modules.

Table 48-4 Power propagation and modulation frequencies of optical modules
Description Part number Power Maximum Optical budgets

propagation at modulation
optical port frequency
1-GE SFP (upstream),1310 nm tx, 1490 3FE 25772 AA 0.5mW 1250 MHz See Table 48-5
nm rx, SMF, 10 km
1-GE SFP (downstream), 1490 nm tx, 3FE 25772 AB 0.5mW 1250 MHz See Table 48-6
1310 nm rx, SMF, 10 km
1-GE SFP, 850 nm, MMF, 550 m, 3FE 25773 AA 0.4 mW 1250 MHz See Table 48-7
1-GE SFP, 850 nm, MMF, 550 m, not 3FE 25773 CA 0.4 mW 1250 MHz See Table 48-8
1-GE SFP, 1310 nm, SMF, 10 km 3FE 25774 AA 0.5 mW 1250 MHz See Table 48-9
1-GE SFP, 1310 nm, SMF, 40 km 3FE 25775 AA 1.0 mW 1250 MHz See Table 48-10
1-GE SFP, 1550 nm, SMF, 80 km, 3FE 25776 AA 3.2 mW 1250 MHz See Table 48-11
1-GE SFP, 1550 nm, SMF, 80 km, not 3FE 25776 BA 3.2 mW 1250 MHz See Table 48-12
1-GE BX40-U SFP (upstream), 1310 nm 3FE 28785 AA 1.0mW 1250 MHz See Table 48-13
tx, 1550 nm rx, SMF, 40 km
1-GE BX40-D SFP (downstream), 1510 3FE 28785 AB 1.0mW 1250 MHz See Table 48-14
nm tx, 1310 rx, SMF, 40 km
1-GE SFP (upstream),1310 nm tx, 1490 3FE 65571 AA 1.0mW 1250 MHz See Table 48-15
nm rx, SMF, 40 km
1-GE SFP (downstream), 1490 nm tx, 3FE 65571 AB 1.0mW 1250 MHz See Table 48-16
1310 nm rx, SMF, 40 km
1-GE SFP, CWDM, SMF, 80 km 3FE 25771 Dx 3.2mW 1250 MHz See Table 48-17
10-GE XFP, 850 nm, MMF, 300 m 3FE 50712 AA 0.8 mW 10.31 GHz See Table 48-18
10-GE XFP, 1310 nm, SMF, 10 km, not 3FE 50712 BA 1.1 mW 10.31 GHz See Table 48-19
10-GE XFP, 1310 nm, SMF, 10 km, 3FE 50712 BB 1.1 mW 10.31 GHz See Table 48-19
10-GE XFP, 1550 nm, SMF, 40 km, not 3FE 50712 CA 2.5 mW 10.31 GHz See Table 48-20
10-GE XFP, 1550 nm, SMF, 40 km, 3FE 50712 CB 2.5 mW 10.31 GHz See Table 48-20
10-GE XFP, 1550 nm, SMF, 80 km 3FE 50712 DA 3.2mW 10.31 GHz See Table 48-21
10-GE XFP, 100GHz DWDM, SMF, 80 km 1AB 35663 00xx 3.2mW 10.31 GHz See Table 48-22
Optical budgets
Table 48-5 describes the optical budgets for the 1-GE SFP (upstream),1310 nm tx,
1490 nm rx, SMF, 10 km (3FE 25772 AA).

Table 48-5 Optical budgets for the 1-GE SFP (upstream),1310 nm tx, 1490 nm rx, SMF,
10 km (3FE 25772 AA)
Tx nominal bit rate — 1250 Mb/s —

Tx central wavelength 1260 nm 1310 nm 1360 nm
Mask of Tx eye diagram — 803.3ah —
Tx mean launched optical power -9.0 dBm — -3.0 dBm
Tx extinction ratio 6 dB — —
Tx spectral width (-20 dB) — — 3.5 nm
Tx SMSR 30 dB — —
Receiving budgets
Rx nominal bit rate — 1250 Mb/s —
Rx wavelength 1480 nm 1490 nm 1500 nm

Rx BER — Less than 1E-12 —
Rx optical sensitivity -19.5 dBm — —
Rx optical overload — — -3 dBm
Link distance (G.652MF) — 6.21 mi —

(10 km)
Table 48-6 describes the optical budgets for the 1-GE SFP (downstream),1310 nm
tx, 1490 nm rx, SMF, 10 km (3FE 25772 AB).
Table 48-6 Optical budgets for the 1-GE SFP (downstream),1310 nm tx, 1490 nm rx,
SMF, 10 km (3FE 25772 AB)
Tx mean launched optical power -9.0 dBm — -3.0 dBm
Tx spectral width (-20 dB) — — 1 nm
Receiving budgets
(1 of 2)

Rx optical sensitivity -19.5 dBm — —
Rx optical overload — — -3 dBm
Link distance (G.652 SMF) — 6.21 mi —

(10 km)
(2 of 2)
Table 48-7 describes the optical budgets for the 1-GE SFP, 850 nm, MMF, 550 m,
temperature hardened (3FE 25773 AA).
Table 48-7 Optical budgets for the 1-GE SFP, 850 nm, MMF, 550 m, temperature
hardened (3FE 25773 AA)

Tx central wavelength 820 nm — 860 nm
Mask of Tx eye diagram — 802.3 —
Tx mean launched optical power –9.5 dBm — –4.0 dBm
Tx spectral width (rms) — — 0.85 nm
Receiving budgets
Rx wavelength 820 nm — 860 nm
Rx optical sensitivity –17 dBm — —
Rx optical overload 0 dBm — —

Link distance (50 um MMF) — 0.31 mi (550 m) —
Table 48-8 describes the optical budgets for the 1-GE 850 nm SFP with a reach of
1804 ft (550 m), not temperature hardened (3FE 25773 CA).
Warning — Operating equipment outside of its tested and

documented performance characteristics and causing an optical
overload may cause damage to equipment components, such as APD
receivers, affect service delivery, and void any component or system
warranties.
The 1-GE 850 nm SPF with MMF:

• compliant with 802.3z 1000BASE-SX PMD
• 275 m with 62.5 uM MMF (200 MHz * km @ 850nm fiber)
• 550 m with 50 uM MMF (500 MHz * km @ 850nm fiber)

Table 48-8 Optical budgets for the 1-GE 850 nm 550 m SFP (3FE 25773 CA)
Tx spectral width (rms) — — 0.85 nm
Receiving budgets
Rx optical overload 0 dBm — —

Link distance (50 um MMF) — 0.31 mi (550 m) —
6.21 mi (10 km) (3FE 25774 AA).
Table 48-9 Optical budgets for the 1-GE 1310 nm 10 km SFP (3FE 25774 AA)
Tx spectral width (SMSR) — — 30 dB
Receiving budgets
Rx optical overload –3.0 dBm — —
Link distance (50 um MMF) — 6.21 mi (10 km) —

24.86 mi (40 km) (3FE 25775 AA).
TX nominal bit rate — 1250 Mb/s —

TX central wavelength 1280 nm — 1335 nm
Mask of TX eye diagram — 802.3 —
TX mean launched optical power –4.5 dBm — 0 dBm
TX extinction ratio 9 dB — —
TX spectral width (SMSR) — — 30.0 dB
Receiving budgets
RX nominal bit rate — 1250 Mb/s —
RX wavelength 1280 nm — 1335 nm
RX BER — Less than 1E-12 —
RX optical sensitivity –22 dBm — —

RX optical overload –3.0 dBm — —

(40 km)
49.71 mi (80 km), temperature hardened (3FE 25776 AA).
TX mean launched optical power 0 dBm — +5 dBm
Receiving budgets
(1 of 2)


(80 km)
(2 of 2)
Table 48-12 describes the optical budgets for the 1-GE 1550 nm SFP and a reach of
49.71 mi (80 km), not temperature hardened (3FE 25776 BA).
Table 48-12 Optical budgets for the 1-GE 1550 nm 80 km SFP (3FE 25776 BA)

TX mean launched optical power 0 dBm — +5 dBm
Receiving budgets

RX optical overload 0 dBm — —

(80 km)
Table 48-13 describes the optical budgets for the 1-GE BX40-U SFP with a reach of
24.86 mi (40 km), temperature hardened (3FE 28785 AA).
Table 48-13 Optical budgets for the 1-GE 1310 nm Tx/1550 nm Rx, 40 km SFP (3FE
28785 AA)
TX central wavelength — 1310 nm —

(1 of 2)

Receiving budgets

RX optical sensitivity –24 dBm — -3 dBm

(40 km)
(2 of 2)
Table 48-14 describes the optical budgets for the 1-GE BX40-D SFP with a reach of
24.86 mi (40 km), temperature hardened (3FE 28785 AB).
Table 48-14 Optical budgets for the 1-GE 1550 nm Tx/1310 nm Rx 40 km SFP (3FE 28785
AB)
TX central wavelength — 1550 nm —
Receiving budgets
RX optical sensitivity –24 dBm — -3 dBm

(40 km)
Table 48-15 describes the optical budgets for the 1-GE SFP (upstream),1310 nm tx,
1490 nm rx, SMF, 40 km (3FE 65571 AA).

Table 48-15 Optical budgets for the 1-GE SFP (upstream),1310 nm tx, 1490 nm rx, SMF,
40 km (3FE 65571 AA)

Tx mean launched optical power –3.0 dBm — +2 dBm
Tx spectral width (–20 db) — — 1 nm
Receiving budgets

Rx optical overload — — –3 dBm

(40 km)
Table 48-16 describes the optical budgets for the 1-GE SFP (downstream),1310 nm
tx, 1490 nm rx, SMF, 40 km (3FE 65571 AB).
Table 48-16 Optical budgets for the 1-GE SFP (downstream),1310 nm tx, 1490 nm rx,
SMF, 40 km (3FE 65571 AB)
Tx mean launched optical power –3.0 dBm — +2 dBm
Tx spectral width (–20 db) — — 1 nm
Receiving budgets
(1 of 2)


(40 km)
(2 of 2)
Table 48-17 describes the optical budgets for the 1-GE SFP, CWDM, SMF, 80 km
(3FE 25771 Dx).
Table 48-17 Optical budgets for the 1-GE SFP, CWDM, SMF, 80 km (3FE 25771 Dx)
Tx central wavelength
3FE 25771 DA 1464.5 nm 1471 nm 1477.5 nm
3FE 25771 DB 1484.5 nm 1491 nm 1497.5 nm
3FE 25771 DC 1504.5 nm 1511 nm 1517.5 nm
3FE 25771 DD 1524.5 nm 1531 nm 1537.5 nm
3FE 25771 DE 1544.5 nm 1551 nm 1557.5 nm

3FE 25771 DF 1564.5 nm 1571 nm 1577.5 nm
3FE 25771 DG 1584.5 nm 1591 nm 1597.5 nm
3FE 25771 DH 1604.5 nm 1611 nm 1617.5 nm

Tx mean launched optical power 0 dBm — +5 dBm
Tx extinction ratio 9 dBm — —
Tx spectral width (-20 db) — — 1 nm
Tx SMSR 30 dBm — —
Receiving budgets
Link distance (G.652 SMF) 49.71 mi

(80 km)
Table 48-18 describes the optical budgets for the 10-GE 850 nm XFP with a reach of
984 ft (300 m) (3FE 50712 AA).

Table 48-18 Optical budgets for the 10-GE 850 nm 300 m XFP (3FE 50712 AA)
TX nominal bit rate — 10 Gb/s —
TX mean launched optical power –4.0 dBm — –1.1 dBm
TX spectral width (rms) — — 0.45 nm
Receiving budgets
RX nominal bit rate — 10 Gb/s —
RX optical sensitivity –9.9 dBm — —

Link distance (50 um 2 GHz) — 984 ft (300 m) —
Table 48-19 describes the optical budgets for the 10-GE 1310 nm XFP with a reach
of 6.21 mi (10 km), not temperature hardened (3FE 50712 BA) and temperature
hardened (3FE 50712 BB).
Table 48-19 Optical budgets for the 10-GE 1310 nm 10 km XFP (3FE 50712 BA and 3FE
50712 BB)
TX extinction ratio 3.5 dB — —
TX spectral width (SMSR) — — 30 dB
Receiving budgets
Link distance (50 um 2 GHz) — 6.21mi (10 km) —

of 24.86 mi (40 km), not temperature hardened (3FE 50712 CA) and temperature
hardened (3FE 50712 CB).
Table 48-20 Optical budgets for the 10-GE 1550 nm 40 km XFP (3FE 50712 CA and 3FE
50712 CB)

Receiving budgets

Link distance (50 um 2 GHz) — 24.86 mi —

(40 km)
of 49.71 mi (80 km) (3FE 50712 DA).
Table 48-21 Optical budgets for the 10-GE 1550 nm 80 km XFP (3FE 50712 DA)
TX central wavelength 1530 nm 1550 nm 1565 nm
TX mean launched optical power 0 dBm — + 4.0 dBm
Receiving budgets
(1 of 2)


(80 km)
(2 of 2)
Table 48-22 describes the optical budgets for the 10-GE XFP, 100GHz DWDM,
SMF, 80 km (1AB 35663 00xx).
Table 48-22 Optical budgets for the 10-GE XFP, 100GHz DWDM, SMF, 80 km (1AB 35663
00xx)

TX central wavelength — See Table 48-23 —
TX mean launched optical power 0 dBm — + 4.0 dBm
Receiving budgets

(80 km)
Table 48-23 provides wavelength information for the 10-GE XFP, 100GHz DWDM,
SMF, 80 km (1AB 35663 00xx).
Table 48-23 Wavelength information for the 10-GE XFP, 100GHz DWDM, SMF, 80 km
(1AB 35663 00xx)
Part number Channel Wavelength
1AB356630001 60 1529.55
1AB356630002 59 1530.33
1AB356630003 58 1531.12
1AB356630004 57 1531.90
1AB356630005 56 1532.68
(1 of 2)

Part number Channel Wavelength
1AB356630006 55 1533.47
1AB356630007 54 1534.25
1AB356630008 53 1535.04
1AB356630009 52 1535.82
1AB356630010 51 1536.61
1AB356630011 50 1537.40
1AB356630012 49 1538.19
1AB356630013 48 1538.98
1AB356630014 47 1539.76
1AB356630015 46 1540.56
1AB356630016 45 1541.35
1AB356630017 44 1542.14
1AB356630018 43 1542.94
1AB356630019 42 1543.73
1AB356630020 41 1544.53
1AB356630021 40 1545.32
1AB356630022 39 1546.12
1AB356630023 38 1546.92
1AB356630024 37 1547.72
1AB356630025 36 1548.51
1AB356630026 35 1549.32
1AB356630027 34 1550.12
1AB356630028 33 1550.92
1AB356630029 32 1551.72
1AB356630030 31 1552.52
1AB356630031 30 1553.33
1AB356630032 29 1554.13
1AB356630033 28 1554.94
1AB356630034 27 1555.75
1AB356630035 26 1556.55
1AB356630036 25 1557.36
1AB356630037 24 1558.17
1AB356630038 23 1558.98
1AB356630039 22 1559.79
1AB356630040 21 1560.61
1AB356630041 20 1561.42
(2 of 2)

Table 48-24 identifies the sections that describe the interfaces and connections
specific to each NT card type.
Table 48-24 NT card interfaces and connections
NT card See
EHNT Section 41.5
EXNT-A Section 42.5
48.6 Status LEDs
The front panel of an NT card contains LEDs indicating power and alarm status.
Table 48-25 identifies the sections that describe the LEDs specific to each NT card
type.
Table 48-25 NT card LEDs
NT card See
EHNT Section 41.6
EXNT-A Section 42.6
48.7 Power
Table 48-26 identifies the sections that describe the power information specific to
each NT card type.
Table 48-26 NT card power information
NT card See
EHNT Section 41.7
EXNT-A Section 42.7
Table 48-27 identifies the sections that describe the physical specifications of each
NT card type.

Table 48-27 EHNT physical specifications
NT card See
EHNT Section 41.8
EXNT-A Section 42.8
48.9 Supported diagnostic parameters per SFP or XFP
Table 48-28 lists the supported diagnostics per SFP or XFP.
Table 48-28 Supported diagnostics per SPF and XFP
Description Part number Supported diagnostics
Transceiver supply voltage

Transceiver temperature
Transceiver bias current
Transmit power
Transmit frame
Receive power
Loss of signal
1-GE SFP (upstream),1310 nm tx, 1490 nm rx, 3FE 25772 AA ✓ ✓ ✓ ✓ ✓ ✓ ✓

SMF, 10 km
1-GE SFP (downstream), 1490 nm tx, 1310 nm 3FE 25772 AB ✓ (2) (2) ✓ ✓ ✓ ✓
rx, SMF, 10 km
1-GE SFP, 850 nm, MMF, 550 m, temperature 3FE 25773 AA ✓ (2) (2) ✓ ✓ ✓ ✓
hardened
1-GE SFP, 850 nm, MMF, 550 m, not 3FE 25773 CA ✓ (2) (2) ✓ ✓ ✓ ✓
1-GE SFP, 1310 nm, SMF, 10 km 3FE 25774 AA ✓ (2) (2) ✓ ✓ ✓ ✓
1-GE SFP, 1310 nm, SMF, 40 km 3FE 25775 AA ✓ (2) (2) ✓ ✓ ✓ ✓
1-GE SFP, 1550 nm, SMF, 80 km, temperature 3FE 25776 AA ✓ (2) (2) ✓ ✓ ✓ ✓
hardened
1-GE SFP, 1550 nm, SMF, 80 km, not 3FE 25776 BA ✓ (2) (2) ✓ ✓ ✓ ✓
1-GE BX40-U SFP (upstream), 1310 nm tx, 1550 3FE 28785 AA ✓ (2) (2) ✓ ✓ ✓ ✓
nm rx, SMF, 40 km
1-GE BX40-D SFP (downstream), 1510 nm tx, 3FE 28785 AB ✓ (2) (2) ✓ ✓ ✓ ✓
1301 rx, SMF, 40 km
1-GE SFP (upstream),1310 nm tx, 1490 nm rx, 3FE 65571 AA ✓ (2) (2) ✓ ✓ ✓ ✓
SMF, 40 km
1-GE SFP (downstream), 1490 nm tx, 1310 nm 3FE 65571 AB ✓ (2) (2) ✓ ✓ ✓ ✓
rx, SMF, 40 km
(1 of 2)

Description Part number Supported diagnostics
Transceiver supply voltage

Transceiver temperature
Transceiver bias current
Transmit power
Transmit frame
Receive power
Loss of signal
1-GE SFP, CWDM, SMF, 62 or 80 km 3FE 25771 Dx (1) ✓ ✓ ✓ ✓ ✓ ✓ ✓
10-GE XFP, 850 nm, MMF, 300 m 3FE 50712 AA ✓ ✓ ✓ ✓ ✓ ✓ ✓
10-GE XFP, 1310 nm, SMF, 10 km, not 3FE 50712 BA ✓ ✓ ✓ ✓ ✓ ✓ ✓

10-GE XFP, 1310 nm, SMF, 10 km, temperature 3FE 50712 BB ✓ ✓ ✓ ✓ ✓ ✓ ✓

hardened
10-GE XFP, 1550 nm, SMF, 40 km, not 3FE 50712 CA ✓ ✓ ✓ ✓ ✓ ✓ ✓
10-GE XFP, 1550 nm, SMF, 40 km, temperature 3FE 50712 CB ✓ (2) (2) ✓ ✓ ✓ ✓
hardened
10-GE XFP, 1550 nm, SMF, 80 km 3FE 50712 DA ✓ (2) (2) ✓ ✓ ✓ ✓
10-GE XFP, 100GHz DWDM, SMF, 80 km 1AB 35663 ✓ ✓ ✓ ✓ ✓ ✓ ✓

00xx(3)
(2 of 2)
Notes
(1) Where x = A, B, C, D, E, F, G, or H.
(2) Contact your Alcatel-Lucent support representative for more information
(3) Where yy = any two-digit number from 01 to 41.



49.1 Identification
Table 49-1 provides identification information about the OLT rack assembly.
Table 49-1 Identification of the OLT rack assembly
Part number Mnemonic Description CLEI CPR ECI/bar code
3AP 60332 CB — prewired OLT rack assembly with one — — —

ALTS-N shelf, one ATRU-N TRU, and
one AFAN-H fan unit with fan filter
3AP 60432 CB — prewired OLT rack assembly with two — — —

ALTS-N shelves, one ATRU-N TRU, and
two AFAN-H fan units with fan filters
3AP 60332 EB — prewired OLT rack assembly with one — — —

ALTS-N shelf, one ATRU-M TRU, and
one AFAN-H fan unit with fan filter
3AP 60432 EB — prewired OLT rack assembly with two — — —

ALTS-N shelves, one ATRU-M TRU, and
two AFAN-H fan units with fan filters
3FE 51459 AA — 2200 mm rack with one OLTS-M shelf — — —

The pre-assembled rack is equipped
with one OLTS-M shelf (with door), the
TRU, the AFAN, and cable harnesses.
3FE 51459 AB — 2200 mm rack with two OLTS-M shelves — — —
The pre-assembled rack is equipped
with two OLTS-M shelves (with doors),
the TRU, the AFAN, and cable
harnesses.
The OLT rack assembly:

• is preinstalled with either one or two P-OLT ALTS-N or OLTS-M shelves that
have an AFAN-H or AFAN-S fan unit installed with filters
• is preinstalled with either an ATRU-M, ATRU-N or ATRU-U top rack unit
(TRU) providing redundant power distribution for up to two shelves, power
circuit breakers, fan failure fuses, and telco alarm distribution
• support for –48 V dc or –60 V dc
• supports alarm connection to the shelves

The OLT rack is:

• UT-9 rack, 600 mm wide and 2200 mm high, that has 25 mm drill holes for
mounting equipment to install a maximum of two ALTS-N or OLTS-M shelves.
Each rack accommodates one TRU.
• 19-in. rack, used in the Asia-Pacific (APAC) market, 482.6 mm wide and 1800
mm high to install a maximum of two OLT-M shelves, that has 36U vertical
equipment aperture per IEC 60297-1 or 1550 mm vertical equipment aperture per
IEC 917-2. Each rack accommodates one TRU.
Note 1 — One P-OLT system consists of a single ALTS-N or

OLTS-M shelf that is populated with the plug-in units and
components that comprise a P-OLT. See the ALTS-N or OLTS-M
unit data sheet for more information.
Note 2 — The TRU distributes redundant power for the shelves, as
well as provides circuit breakers, fan fuse, and telco alarm
connections. See the unit data sheets for the ATRU-N, ATRU-M or
ATRU-U for more information.
Table 49-2 describes the various OLT rack configurations.
Table 49-2 OLT rack assembly components list
OLT rack assembly Components list

part number
Quantity Description Part number
3AP 60332 EB 1 UT-9 rack, 600 mm wide and 2200 3FE 20145 AA
mm high, with 25 mm drill holes for
mounting equipment
1 ALTS-N shelf 3EC 17542 AB
1 ATRU-M TRU 3EC 17422 AA
1 AFAN-H fan unit with fan filter 3EC 37533 AB
3AP 60432 EB 1 UT-9 rack, 600 mm wide and 2200 3FE 20145 AA
mounting equipment
2 ALTS-N shelves 3EC 17542 AB
1 ATRU-M TRU 3EC 17422 AA

3AP 60332 CB 1 UT-9 rack, 600 mm wide and 2200 3FE 20145 AA
mounting equipment
1 ALTS-N shelf 3EC 17542 AB
1 ATRU-N TRU 3EC 17422 CD
(1 of 2)

OLT rack assembly Components list

part number
Quantity Description Part number
3AP 60432 CB 1 UT-9 rack, 600 mm wide and 2200 3FE 20145 AA
mounting equipment
2 ALTS-N shelves 3EC 17542 AB
1 ATRU-N TRU 3EC 17422 CD
3FE 51459 AA 1 ETSI Universal rack, 600 mm wide 3FE 28688 AA

and 2200 mm high, with 25 mm drill
holes for mounting equipment
1 One OLTS-M shelf with front door 3FE 51410 AA

1 ATRU-U TRU 3FE 51460 AA
1 AFAN-S fan unit with fan filter 3FE 51619 AA
3FE 51459 AB 1 ETSI Universal rack, 600 mm wide 3FE 28688 AA

and 2200 mm high, with 25 mm drill
holes for mounting equipment
2 Two OLTS-M shelves with front doors 3FE 51410 AA
1 ATRU-U TRU 3FE 51460 AA
2 AFAN-S fan unit with fan filter 3FE 51619 AA
(2 of 2)
Table 49-3 describes the physical specifications of the ETSI racks.
Table 49-3 Physical specifications of ETSI racks
3AP 60332 CB, 3FE 51459 AA
Width 29.13 in. (74 cm)
Depth 22.05 in. (56 cm)
3AP 60432 CB, 3FE 51459 AB
Width 29.13 in. (74 cm)
Depth 22.05 in. (56 cm)
3AP 60332 EB
(1 of 2)

Width 26.77 in. (68 cm)
Depth 16.93 in. (43 cm)

3AP 60432 EB
Width 29.13 in. (74 cm)
Depth 22.05 in. (56 cm)
Weight 379.42 lb (172.1kg)
(2 of 2)


50.4 Backplane connectors and cables 50-5
50.5 Physical location identification 50-6
50.6 Power distribution 50-6
50.7 Thermal limitation 50-7

50.1 Identification
Table 50-1 provides identification information about OLTS-M.
Table 50-1 Identification of OLTS-M
3FE 51410 AA OLTS-M 19 inch line termination shelf, BVM5X00CRA 211349 454738
version M
3FE 51488 AA — 19 in. mounting ear - left — — —
3FE 51489 AA — 19 in. mounting ear - right — — —
3FE 51490 AA — ETSI mounting ear - left — — —
3FE 51491 AA — ETSI mounting ear - right — — —
The OLTS-M shelf provides:

• front access shelf in which the P-OLT components install
• mounting locations for NT, LT and AACU cards:
• 2 NT cards
• 1 AACU card
• 14 LT cards
• terminals for connecting –48 V dc or –60 V dc Battery A and Battery B power
feeds
• FILT card installed with battery filter caps that mount on the shelf power input
terminals for CE Mark, EN55022, and EN300386 EMC compliance
• SMAC card to provide MAC ID addresses for the NE
• BITS-B card that provides:
• BITS clock termination
• LAN interface
• 10 Gbps XAUI links between NTs and LTs, as well as between NTs and the ACU
for future use
• HighGig backplane interconnection between NT cards
• integrated fiber management tray at the bottom of the shelf
• shelf is rack mountable in either a 19 in. rack or a UT-9 rack for deployment in a
CO or CEV

The OLTS-M optical line termination (OLT) shelf is the 19 in. rack mountable frame
in which the cards and other units that comprise the P-OLT are installed. The shelf
mounts in the OLT rack for CO or CEV installations. Depending on the mounting
ears that are ordered, the OLT rack can be either a 19 in. wide, 300 mm or UT-9 rack,
600 mm wide for mounting equipment. See the OLT rack unit data sheet for more
information.
Note — Due to thermal limitations, you can install a maximum of two

P-OLT shelves plus one TRU unit in a UT-9 rack, even though three
shelves plus the TRU unit can physically fit in to the same rack.
The OLTS-M shelf has three main areas:

• power and shelf connector area (upper area)
• card cage (center area)
• cable routing tray (lower area)
The OLTS-M shelf supports the following NT and LT cards:
• EHNT-B
• EXNT-A
• GLT4-A
• GLT4-D
• GLT8-A
Figure 50-1 shows an OLTS-M shelf, with 19 in. mounting ears, populated with
P-OLT components.

Figure 50-1 OLTS-M shelf with P-OLT cards and 19in. mounting ears
19.0158
18.3110
11.1181 17.2334
BATRET BAT A BAT B
UNIT
UNIT
1 1 1 1 1 1 1 1 1 MIN 1 1 1 1 1
LNK TX RX LNK TX RX
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
PON SF
2 2 2 2 2 2 2 2 2 GE-1 ALM GE-1 2 2 2 2 2
3 3 3 3 3 3 3 3 3 GE-2 ACO GE-2 3 3 3 3 3
NETWORK
NETWORK
4 4 4 4 4 4 4 4 4 GE-3 GE-3 4 4 4 4 4
GE-4 GE-4
10G 10G
O&M O&M
Tx Tx
Rx Rx
GE-1 GE-1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
PON1
24.4646
ETHERNET
GE-2 GE-2
GE-3 GE-3
CRAFT
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
PON2
GE-4 GE-4
10G 10G
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON3
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
PON4
19321
The card cage is the large central area of the shelf that accommodates plug-in cards
that are 16.53 in. (42 cm) in height and 8.66 in. (22 cm) in depth. From left to right,
there are 9 LT card slots (LT 1 through LT 9), 1 NT slot (NTA), 1 ACU slot, 1 NT
slot (NTB), and 5 LT slots (LT 10 through LT 14). To maintain air flow and EMI
integrity, blank filler panels must be installed in any empty slot in the card cage area.
The topmost area of the shelf is the power and shelf connector area, which provides
the following:
• shelf power connections from the TRU
• BITS interface and remote Ethernet connectors
• craft 2 interface connector
• shelf alarm connection to TRU
• fan alarm connector
• SMAC card

50.4 Backplane connectors and cables
The backplane interconnects the cards, the eHCL bus interface, the XAUI bus
interfaces, external interfaces, and other rack equipment. Input power terminals are
located on the externally accessible section of the backplane, which is the topmost
section; see Figure 50-1.
The shelf identification jumpers are located on the backplane in the area of the NTA
connectors. The jumpers can only be accessed when there are no cards installed in
the shelf.
Power is distributed to the installed units in the shelf over the backplane. Cards
installed in the card cage are supplied with redundant (A and B) power feeds from
the TRU over the shelf backplane. Shelf power circuit breakers are located on the
TRU at the top of the rack.
Figure 50-2 shows the backplane of the OLTS-M. The connectors that appear in the
topmost section are externally accessible from the front of the shelf.
Figure 50-2 OLTS-M backplane
Shelf Power BITS LAN Craft 2 Alarm

Terminals Interface
Fan
Alarm
BATRET BAT A BAT B
SMAC
Shelf ID
19339
Table 50-2 provides information about the backplane connectors and related cables.

Table 50-2 Backplane connectors and related cables
FILT-B terminals Shelf power (BATA, BATB, BATRET) Cable Lug M5 6 mm2 (3x)
LAN (on BITS-B 10/100 Mbps Ethernet port RJ45

card)
BITS (on BITS-B BITS primary and BITS secondary signal input RJ45
card)
ALARMS (J64) Alarm interface cable to TRU DSUB 50 pins 3FE 51529 AA
3FE 51529 AB
CRAFT 2 Remote Craft Interface DSUB 9 pins 3EC 16028 xx AA

INTERFACE (J23)
FAN_ALM (J25) Fan shelf alarm interface 2x5 ribbon connector Part of power harness
SMAC (J22) SMAC card connector — —
Shelf ID (J63) Physical location identification jumper Jumper connectors —

settings
50.5 Physical location identification
The OLTS-M shelf provides the physical location identification (PLID) setting. This
requires 21 PLID bits for ultra-density equipment.
The jumpers are placed on the backplane in two columns between the LT-9 and the
NTA slots.
50.6 Power distribution
The shelf receives redundant power from the TRU. The TRU provides redundant
power, A and B, to the shelf and frame ground for the rack. In the three-wire
configuration, there are three power cables (BATA, BATB, and BATRET) and a
separate frame ground wire. In the two-wire configuration, frame ground is provided
via the BATRET cable.
The power signals BATA, BATB and BATRET is distributed via the backplane and
feed the plug-in units. Power must be supplied to the A and B power source at startup
(boot time) or the system will not initialize. This is because a FANALM alarm for
fan 1 will be raised if the fan unit is missing A- or B-side power. An alarm for this
reason puts the system in thermal shutdown mode. This is to ensure proper powering
of the equipment to protect the system from a potential thermal event.
In the shelf power input area, a small board (FILT-B) is bolted onto the power
connectors of the OLTS-M shelf. The FILT-B filters the dc mains on the shelf to
achieve CE Mark, EN55022, and EN300386 EMC compliance.
Three battery filter caps are provided on the board, one each for BAT_A-FG,
BAT_B-FG, and BAT_RET-FG.
Table 50-3 lists the power and grounding signals used.

Table 50-3 Power and grounding signals
50.7 Thermal limitation
Due to the high data rates and large number of subscribers, failures of the P-OLT
equipment can cause massive service outages and revenue loss for service providers.
Some P-OLT cards are not expected to operate more than a few minutes without
forced air cooling.
In the current system, there exist multiple thermal sensors on the NT and LT cards.
This allows for 2 thermal defense methods on the P-OLT.
• Individual thermal readings on the LT and NT cards. This allows for shutdown of
individual cards, but not for shutdown of a group of LT cards or all LT cards on
the shelf.
• FGU 4.6 and later introduced a more comprehensive, system wide thermal
defense that correlated information from alarms and the fans to ensure
system-wide protection.
To prevent failures, the P-OLT uses a redundant fan design. With this design, the
failure of one fan does not cause a cooling system degradation that is severe enough
for the NT and LT units to fail. However, there are constraints that must be observed
for the design to work as specified.
Observe the following when working with the P-OLT equipment:
• Install filler panels in any unused slot position to maintain proper thermal
operation.
• Use only the AFAN-S as the OLTS-M shelf cooling system. The AFAN-S is
fault-tolerant and highly reliable.
• Power must be supplied to the A and B power source at startup (boot time) or the
system will not initialize. This is because a FANALM alarm for fan 1 will be
raised if the fan unit is missing A- or B-side power. An alarm for this reason puts
the system in thermal shutdown mode. This is to ensure proper powering of the
equipment to protect the system from a potential thermal event.
• Do not stack P-OLT shelves directly over each other, a 50 mm air gap between
the lower P-OLT shelf and the fan unit for the upper P-OLT should exist.
• Do Not place the shelf above a heat source without redirecting the hot air away
from the inlet of the shelf. For example, you can use an air baffle to redirect hot
air.

• Never allow an in-service P-OLT be left without forced-air cooling for more than
5 minutes.
• Replace the failed fan within the MTTR period. A single-fan failure in the P-OLT
cooling system does not cause the NT or LT cards to fail during the MTTR period.
MTTR is a maximum of 4 hours for remote locations, including CEVs.
P-OLT thermal defense for individual card protection

There are threshold values defined for such sensors where the hardware and software
react to the sensor readings once a threshold is exceeded.
LT cards
The LT cards have thermal sensors mounted in close proximity to the boards FPGAs
(two on the GLT2 and four on the GLT4 cards). Each sensor takes two separate
readings:
• Internal reading - the ambient temperature for the area around the sensor.
• External reading - the core (junction) temperature of the FPGA device.
The GLT8-A card has a five separate thermal sensors. Two separate thermal
switches independent of the thermal sensors provided on the GLT8-A card will
power off the card in case an over-temperature condition threshold exists.
The LT card software reads the sensors periodically (once per second) and will
maintain a history of the last ten readings. If the average of the readings exceed a
pre-defined threshold, the software reacts to it.
The LT thresholds for internal readings are:
• Major Thermal Alarm Raise Threshold - LT notifies NT of monitored
temperature threshold reached or exceeded and NT raises system alarm
(HITEMP). The temperature exceeded threshold for this alarm is 70°C (158°F).
• Major Thermal Alarm Clear Threshold - LT notifies NT of monitored
temperature falling below threshold for clearing of system alarm (HITEMP). The
temperature clear threshold for this alarm is 67°C (152.6°F).
• Critical Thermal Alarm Raise Threshold - LT notifies the NT that the card is
dangerously hot. The NT raises a system alarm (SHUTDOWN) (85° C/185° F)
and turns off the power to the reporting LT card. The operator is expected to
resolve the cause of the high temperature and re-activate the LT using TL1
commands. Take immediate action when this alarm is raised.
• Critical Thermal Alarm Clear Threshold - LT notifies NT of monitored
temperature falling below threshold for clearing of system alarm (HITEMP). The
temperature clear threshold for this alarm is 102°C (215.6°F).

The LT thresholds for junction readings are:

• Major Thermal Alarm Raise Threshold - LT notifies NT of monitored
temperature threshold reached or exceeded and NT raises system alarm
(HITEMP). The temperature exceeded threshold for this alarm is 105°C (221°F).
• Major Thermal Alarm Clear Threshold - LT notifies NT of monitored
temperature falling below threshold for clearing of system alarm (HITEMP).
• Critical Thermal Alarm Raise Threshold - LT notifies the NT that the card is
dangerously hot. The NT raises a system alarm (SHUTDOWN) (110° C/230° F)
and turns off the power to the reporting LT card. The operator is expected to
resolve the cause of the high temperature and re-activate the LT using TL1
commands.
NT card
Each NT card has two thermal sensors that are read by the on-board computers. The
sensors are located at the hottest locations on the board and monitor the ambient
temperature of the card. The software reads the sensors and raises major and critical
alarms when the pre-defined thresholds are exceeded. The NT thresholds are:
• Major Thermal Alarm Raise Threshold - monitored temperature threshold
reached or exceeded (70° C/158° F), NT raises system alarm (HITEMP).
• Major Thermal Alarm Clear Threshold - monitored temperature falls below
threshold (68° C/154° F) for clearing of system alarm (HITEMP).
• Critical Thermal Alarm Raise Threshold - monitored temperature threshold
reached or exceeded (85° C/185° F), raises critical system alarm (SHUTDOWN).
• Critical Thermal Alarm Clear Threshold - monitored temperature falls below
threshold (82° C/179.6° F) for clearing of critical system alarm (SHUTDOWN).
Unlike the LT, the software cannot power down the NT in the case of a critical
thermal event. There is a thermal switch located next to the boards power supply that
will power down the NT board if a very high temperature is reached (95° C/203° F).
If the ambient temperature falls below 85° C (185° F), the board will be powered up
again. If the problem is with the active card, then switch the NT card to standby and
then shut down the active card. If the problem is with the standby NT card, then only
the standby NT card should be shut down.
Fan unit (AFAN-S)

The fan unit is essential to the proper operation of the 7342 ISAM FTTU. If a fan
fails, the fan unit controller will increase the speed of the operating fan and raise a
system alarm (FANALM). Other reasons for a FANALM include:
• power feed missing (A or B)
• on-board fan unit controller fails (causes system to increase the speed of the fans
to maximum)

• on-board fan unit power converters fail

• bad power to the controller
If the fan unit is removed from the system, a system alarm is raised (FANMISSING).
The 7342 ISAM FTTU should not be operated without the fan unit for more than a
few minutes. A single fan failure will not immediately cause the cards or system to
shut down during that time. But it is a necessary practice to replace a failed fan. The
system cannot run with one less fan than planned. A critical thermal temperature
alarm will be raised due to insufficient cooling.
P-OLT thermal defense in FGU 4.6 and later systems

New command(s) allow the user to gather individual ambient and junction
temperature readings of every board in the system. The REPT-OPSTAT-EQPT
command is added to the TL1 management system for thermal sensor retrievals from
the NTs, AACU and LTs. The show equipment shelf command is added to the CLI
management system for thermal sensor retrievals from the NTs, AACU and LTs. See
and CLI guide for more information about performing the commands.
LT cards and NT cards

Similar to the current implementation, in FGU 4.6 and later, the LT and NT software
reads the multiple thermal sensors in a periodic way. The readings are categorized
into 2 types:
• Local ambient temperature readings: These readings are showing the ambient
thermal readings around a specific sensor # of such readings/sensors will be
equivalent to the number of sensors on the board (for example, if the board has 4
sensors, the expected number of such readings are 4). These values are physically
read from the sensors and are representing the sensor temperature. These readings
measure the temperature (PCB) around the sensor.
• FPGA/ASIC/CPLD junction temperature readings: The critical board
components (for example, FPGA) are also read periodically. The total number of
readings may be less than the total number of sensors on board, however all the
FPGAs on board are recommended to be covered with such readings. For current
GLT4-x, and GLT8-A, or NT cards, these readings are read from the same
sensors.
There are 2 critical conditions defined:

• Critical Condition 1 (CC1): This is a trigger where the system shows a thermal
breakdown and is independent of thermal mode. It is dangerous to continue
operation if such a trigger happens. The trigger is a certain number of LTs stating
SHUTDOWN alarms within a certain timeframe.
• Critical Condition 2: This is a trigger which states that the system will get hot
quickly. And this condition is detected only by early detection algorithm. System
reacts to this trigger.

For a system that has 9 or more active LTs, the following conditions are considered
as Critical Condition 1:
• The system gets THERMALSHUTDOWN alarms from 4 or more LTs within 4
minutes.
• At any time if at least 80% of the LTs in the system report either HITEMP alarm
or THERMALSHUTDOWN alarm
For a system that has less than 9 active LTs, the following conditions are considered
as Critical Condition 1:
• The system gets THERMALSHUTDOWN alarms from 3 or more LTs within 4
minutes.
• At any time if at least 90% of the LTs in the system report either HITEMP or
THERMALSHUTDOWN alarms.
The detection of no air flow is the basis for critical fan problems. Once the system
detects air-flow problems in the LTs, it starts to count the number of such warnings
and makes a decision depending on the received number of warnings and the total
number of active LTs in the system. The critical condition 2 is a clear indicator for
the shelf early detection algorithm to take an action. The system takes action to
critical condition 2 only while detecting FAN1 or unreliable ACU issues. If the
problem is with the active NT card, then switch the NT card to standby and then shut
down the active card. If the problem is with the standby NT card, then only the
standby NT card should be shut down.
For a system that has 9 or more active LT cards, one of the following conditions are
considered as Critical Condition 2:
• The system gets/calculates suspected air flow problem warnings from at least
70% of the LTs within any minute interval
• For 4 or more LTs, the system calculates a suspected air flow problem for 3
consecutive minutes. 3 consecutive minute-long suspected air flow issues from an
LT are called “3 consecutive warnings”.
• For 3 consecutive minutes, if the system calculates 9 or more 3 consecutive
warnings for the LTs
For a system that has less than 9 active LT cards, one of the following conditions are
considered as Critical Condition 2:
• The system gets/calculates suspected air flow problem warnings from at least
80% of the LTs within any minute interval
• For 3 or more LTs, the system calculates a suspected air flow problem for 3
consecutive minutes. 3 consecutive minute-long suspected air flow issues from an
LT are called “3 consecutive warnings”.
• For 3 consecutive minutes, if the system calculates 6 or more 3 consecutive
warnings for the LTs

Fan unit
The fan unit is essential to the proper operation of the 7342 ISAM FTTU. There are
six fans in the fan unit and they are configured as three redundant pairs. If a fan fails,
the fan unit controller will increase the speed of the operating fan and raise a system
alarm (FANALM). Other reasons for a FANALM include:
• power feed missing (A or B)
• on-board fan unit controller fails (causes system to increase the speed of the fans
to maximum)
• on-board fan unit power converters fail
• bad power to the controller
If the fan unit is removed from the system, a system alarm is raised (FANMISSING).
The 7342 ISAM FTTU should not be operated without the fan unit for more than a
few minutes. A single fan failure will not immediately cause the cards or system to
shut down during that time. But it is a necessary practice to replace a failed fan. The
system cannot run with one less fan than planned. A critical thermal temperature
alarm will be raised due to insufficient cooling.
To avoid damage to hardware due to thermal events, early detection of thermal
problems was added to FGU 4.6 and later releases. The early detection mechanism
senses a problem with the fans that are critical for the operation of the shelf, thus the
system reacts to the condition. The key controller in a system is the NT card, and
keeping it alive during a thermal event is the main intent of early detection logic. If
the NT is kept alive, it can maintain the control of the LTs, however to be alive, the
NT is required to detect a thermal problem at its early phases and react to it before it
gets out of control.
For this purpose, the NT board is sent all the thermal sensor data from all LTs. If a
Fan1 condition (or missing/malfunctioning ACU) is detected, the NT software
determines if a thermally critical condition present and puts the shelf into an
“absolute low-power” mode, in which all LTs are turned off and the NTs are put in
low-power mode. This is based both on the presence of Fan1/ACU problem and the
number of LTs reporting thermal issues. This way, the NTs survive a fatal fan failure
with protecting the equipment, however all the services are taken down. In the case
of a Fan2 condition, the NT goes into ‘ignorant’ mode, where the NT expects the fan
unit to be put back in a short time, for example, when fan filters are being replaced.
The following sections describe the OLTS-M shelf.
Front cover
The front cover is supported by hanging it on the notched cutouts on the side rails of
the shelf and secured by tightening the two captive screws at the bottom.

Fiber management shelf

The fiber management shelf located at the bottom of the OLTS-M shelf is used to
route fiber cables that are coming from the LT and NT cards. It consists of a fiber
tray and fiber routing clips. Fiber cables are routed out the cable exit areas located on
the left and right sides of the shelf. To assist in routing the cables, the front lip of the
tray can be removed by loosening the two captive screws on the bottom edge.
Specifications
Table 50-4 describes the physical specifications of the OLTS-M.
Table 50-4 Physical specifications of the OLTS-M
Height 24.46 in. (62.13 cm)

Width 17.23 in. (43.76 cm)
Depth 11.12 in. (28.24 cm)
Maximum heat dissipation 1450 W at -5°C, +50°C



51.1 Identification
Table 51-1 provides identification information about the SANC-D.
Table 51-1 Identification of the SANC-D

code
3EC 17919 AA SANC-D Synchronous ATM network combiner, — — —

version D, BITS and LAN access for optical
NT
The SANC-D provides:

• BITS and LAN interface connection in an ALTS-N shelf
• synchronization signal connection to the optical NT units
• front panel BITS and LAN connection using two RJ-45 connectors
• backplane connection to the optical NT units
The SANC-D provides BITS and LAN physical interface access to the optical NT
units installed in the shelf. The SANC-D is located in the connector area of the
ALTS-N shelf.
The SANC-D provides the following functions:
• BITS/SETS interface physical access
• LAN physical access
• RIMW interface
A SANC-D can be used in an ALTS-N shelf deployed with either one or two SDH
optical NT units.
The SANC-D backplane connectors are female pressfit connectors with 5-row
pinning and 2 mm pitch.
The SANC-D is provided with a LAN interface to allow outband management.
The external interfaces are:

• BITS/SETS interface physical access
• LAN physical access

• remote inventory interface

• presence interface
The front panel is equipped with the following parts:
• one RJ-45 8-pin female connector for BITS/SETS interface
• one RJ-45 8-pin female connector for LAN interface
• two contacts for ESD prevention
• two tabs for insertion and extraction


52 — Racks for video coupler unit data
sheet

52.1 Identification
Table 52-1 provides identification information about the Tyco and LGX racks for the
video coupler.
Table 52-1 Identification of the rack for the video coupler

code
1AD 04674 0001 — Tyco 2200 mm — — —

video coupler
fiber rack
1AD 01412 0044 — LGX rack for — — —

video coupler
The Tyco rack for the video coupler:

• houses a maximum of 15 Tyco video coupler subracks (VCSs), including one for
sparing
• includes fiber-handling raceways
• is generally located in a CO or CEV
The LGX rack for the video coupler:
• houses a maximum of nine video coupler shelves (VCSL-As)
• supports two full packet optical line termination (P-OLT) systems (one and a half
VCSL shelves are required for each P-OLT)
• is generally located in the central office (CO) or controlled environment vault
(CEV)
The following provides a general description of the video coupler racks.
Tyco
The 2200 mm video coupler fiber rack is used to hold the VCSs separately from the
packet optical line termination (P-OLT) rack.
The VCSs are storage shelves for video coupler trays. The trays contain wavelength
division multiplexers (WDMs).
The WDMs provide video signal overlay onto the passive optical network (PON) and
distribute the video signal from the video optical line termination (V-OLT) to the
optical network terminal (ONT).

When fully equipped, a video coupler fiber rack provides video overlay capacity for
a maximum of five P-OLT racks, or 10 P-OLT shelves.
Figure 52-1 shows the video coupler fiber rack.

Figure 52-1 Video coupler fiber rack

LGX
The rack for the video coupler is a standard 23 in (54.82 cm). closed unequal-flange
equipment rack. A fiber slack storage tray (FSST) is optional for each three VCSL-A
shelves.
The rack holds the video coupler shelves that provide wavelength division
multiplexers (WDMs) for merging the optical traffic from the P-OLT and the video
optical line termination (V-OLT).
For each full P-OLT, 1-1/2 VCSL shelves are required. A single video coupler rack
can support a maximum of six P-OLTs.
Figure 52-2 shows the rack for video coupler and the recommended video coupler
layout.

Figure 52-2 Rack for video coupler and recommended layout
VCW2 1 VCW2 12
VCSL 1
VCSL 2
P-OLT 1 VCSL 3 P-OLT 4
FSST
VCSL 4
VCSL 5
P-OLT 2 VCSL 6 P-OLT 5
FSST
VCSL 7
VCSL 8
P-OLT 3 P-OLT 6
VCSL 9
FSST
no310
Table 52-2 provides information about the physical dimensions of the Tyco video
coupler fiber rack.

Table 52-2 Physical dimensions of the Tyco video coupler fiber rack
Height 86.61 in. (2200 mm)
Width 47.24 in. (1200 mm)
Depth 11.81 in. (300 mm)
Table 52-3 provides information about the dimensions of the LGX 58.42 cm (23-in.)
rack, including the front and back aisles.
Table 52-3 54.82 cm (23 in) rack dimensions
Description Pitch Depth Floor area

Wiring aisle (rear) 26 in. (66 cm) 11.2 in. (28.4 cm) 2.17 ft2 (0.202 m2)
Equipment 26 in. (66 cm) 12.8 in. (32.5 cm) 2.17 ft2 (0.202 m2)
Maintenance aisle (front) 26 in. (66 cm) 15 in. (38.1 cm) 2.71 ft2 (0.252 m2)
Total 26 in. (66 cm) 39 in. (99 cm) 7.05 ft2 (0.655 m2)


53 — Tyco video coupler subrack unit data
sheet

53.1 Identification
Table 53-1 provides identification information about the Tyco subrack for video
coupler.
Table 53-1 Identification of the subrack for video coupler

code
1AD 04675 0001 — Subrack for video — — —

coupler provided
by Tyco
The Tyco subrack for video coupler:

• holds a maximum of three pairs of Tyco video coupler WDM (VCW4-A) trays
that include three left trays and three right trays
• is housed in the 2200-mm Tyco video coupler fiber rack
• provides fiber routing management for the VCW4-A trays to the sides of the
subrack
• allows independent removal and addition of video coupler trays for maintenance
or replacement
• allows independent connection or disconnection of fiber jumpers for maintenance
and replacement
• is generally located in a CO, CEV, or remote terminal
The Tyco video coupler subrack (VCS) supports a maximum of three pairs of video
coupler WDM (VCW4-A) trays. The VCS modularity allows system expansion on
an as-needed basis. It also provides fiber routing management into and out of the
shelf while maintaining fiber bend radius control.
Figure 53-1 shows the front view of the VCS.
Figure 53-1 Video coupler subrack, front view

The WDM is used to overlay video signals through the PON to individual ONTs. A
VCS supports a maximum of 24 PONs.
For more information about the Tyco video coupler subrack, see related Tyco
customer documents.
Figure 53-2 shows an open VCS with five WDM trays.
Figure 53-2 Open VCS with 5 trays


54.4 Optical safety 54-3
54.5 Environment requirements 54-3
54.6 Connections 54-4

54.1 Identification
Table 54-1 provides identification information about Tyco VCS8-A.
Table 54-1 Identification of VCS8-A

code
3EM 15711 AD VCS8-A Tyco video — — —

coupler WDM
trays with
splitters, 16
PONs, version A
3EM 15711 AE — Left tray with 8 — — —

WDMs with LC
connectors on
the splitters
3EM 15711 AF — Right tray with 8 — — —

WDMs with LC
connectors on
the splitters
The Tyco VCS8-A tray provides:

• overlay video signal inserted into downstream traffic to the optical network
terminals (ONTs)
• modular trays designed for scalability that matches the passive optical networks
(PONs) on the line termination (LT) cards
• installation based on LT cards with one tray supporting four LT cards
• eight wavelength division multiplexers (WDMs) per tray that can serve eight
PONs
• 18 port connections per tray with front access, including PON and video optical
line termination (V-OLT) ports equipped with SC/APC connectors, and packet
optical line termination (P-OLT) ports equipped with SC/UPC connectors
• easy snap-in installation of a maximum of two pairs of VCS8 trays into the video
coupler subrack (VCS)
• easy connection or disconnection of jumpers without tools
The VCS8-A is located in the central office (CO), controlled environment vault
(CEV), or remote terminal. It is compliant with GR-1209 and GR-1221
requirements. The connectors are compliant with GR-326 requirements.

The VCS8-A tray is used for applications that support all digital radio frequency
(RF) lineup. The VCS8 provides overlay of video signals from the V-OLT onto the
PON.
The VCS8 tray supports the integration of the splitters into the VCS8 tray. The
integration eliminates the need for a splitter rack and simplifies fiber management.
The VCS8 allows a one-to-one relationship between the P-OLT subracks and VCSs.
The VCS8 is scalable to accommodate the increase of LT cards in the P-OLT. The
VCS8 tray contains two trays, a left and a right tray, that are connected together.
Each VCS contains two pairs of VCS8 trays that can provide video overlay to a
maximum of 16 LT cards.
There are 18 LC type connectors in each tray, grouped into three sets:
• eight LC/UPC connectors for signals to and from the P-OLTs
• two LC/APC connectors for signals to the V-OLT
• eight LC/APC connectors for signals to and from the ONTs, including the overlay
video signal
Each V-OLT port is attached to an optical amplifier. The V-OLT input passes
through a 1:4 planar splitter that splits the V-OLT input into four outputs to feed four
WDM video couplers. Each video coupler connects to the P-OLT, V-OLT, and the
PON that connects to the ONTs.
The function of the VCS8-A is to merge the optical traffic from P-OLT and V-OLT
ports into a multiwavelength signal. The merge is accomplished through a coarse
WDM. The VCS8-A injects the 1550 nm video traffic from the V-OLT onto the 1490
nm traffic from the P-OLT. The resulting multiwavelength traffic is then passed
through the PON to the ONT at the subscriber site. The 1310 nm upstream traffic
from the ONT is routed through the VCS8-A to the P-OLT port.
54.4 Optical safety
Observe the following warnings when working with the optical components in the
VCS8-A.
Warning 1 — Possibility of personal injury. Laser radiation when
open. Avoid eye or skin exposure to direct or scattered radiations.
Warning 2 — Possibility of personal injury. Fiber cables transmit
invisible laser light. To avoid eye damage or blindness, never look
directly into fibers, connectors, or adapters.
54.5 Environment requirements
The VCS8-A contains optical components that must be placed in a controlled

environment. The conditions in the environment must not exceed the extreme ratings
provided in Table 54-2.

Table 54-2 Extreme rating for optical components
Parameter Minimum Maximum
Storage and shipping temperature –40°F (–40°C) 185°F (85°C)
Operating temperature –40°F (–40°C) 185°F (85°C)
Optical input power capability — +24 dBm
Operating and storage humidity range (1) 5% RH 85% RH
Note
(1) The actual operating environment may reach a maximum of 90% for short-term operation.
Short-term operation is defined as a maximum of 72 h and for a total of no more than 15 days per
year.
54.6 Connections
There are 18 LC type connectors in a VCS8 tray, grouped into three sets. Each group
of three connectors handles two inputs, one from the P-OLT and one from the
V-OLT, and one output to the ONT through the PON. The functions of the
connectors are described as follows:
• P-OLT connector: receives input from the P-OLT
• V-OLT connector: receives input from the V-OLT
• PON connector: provides output to an ONT through the PON
Figure 54-1 shows the VCS8 tray.
Figure 54-1 VCS8 tray


55.1 Identification
Table 55-1 provides identification information about Tyco VCW4-A.
Table 55-1 Identification of VCW4-A

code
3EM 15711 AA VCW4-A Tyco video — — —

coupler WDM tray
for 8 PONs,
version A
3EM 15711 AB — Left tray: Tyco — — —

video coupler
WDM tray for 4
PONs (4 SC
without splitters)
3EM 15711 AC — Right tray: Tyco — — —

video coupler
WDM tray for 4
PONs (4 SC
without splitters)
The Tyco VCW4-A tray provides:

• overlay video signal inserted into downstream traffic to the optical network
terminal (ONT)
• modular trays designed for scalability that matches the passive optical networks
(PONs) on the line termination (LT) cards
• installation based on LT cards with one tray supporting two LT cards
• four wavelength division multiplexers (WDMs) per tray that can serve four PONs
• 12 port connections per tray with front access, including PON and video optical
line termination (V-OLT) ports equipped with SC/APC connectors, and packet
optical line termination (P-OLT) ports equipped with SC/UPC connectors
The VCW4-A is located in the central office (CO), controlled environment vault
(CEV), or remote terminal. It is compliant with GR-1209 and GR-1221
requirements. The connectors are compliant with GR-326 requirements.
The VCW4-A tray is installed in a Tyco video coupler subrack. Left and right trays
are paired for space efficiency. Each tray contains four WDMs that can connect a
maximum of four PONs.

The function of the VCW4-A is to merge the optical traffic from P-OLT and V-OLT
WDM. The VCW4-A injects the 1550 nm video traffic from the V-OLT onto the
1490 nm traffic from the P-OLT. The resulting multiwavelength traffic is then
passed through the PON to the ONT at the subscriber site. The 1310 nm upstream
traffic from the ONT is routed through the VCW4-A to the P-OLT port.
55.4 Optical safety
VCW2-C.
The VCW4-A contains optical components that must be placed in a controlled


Note
year.
55.6 Connections
There are 12 SC type connectors in a VCW4 tray, grouped into four sets of three.
Each group of three connectors handles two inputs, one from the P-OLT and one
from the V-OLT, and one output to the ONT through the PON.

The functions of the connectors are described as follows:

Figure 55-1shows the VCW4 tray.
Figure 55-1 VCW4 tray and connectors

56.4 Alarms 56-3

56.1 Identification
Table 56-1 provides identification information about the LGX VCSL-A.
Table 56-1 Identification of VCSL-A

code
3EM 11047 AA — Video coupler — — —

shelf LGX
The VCSL-A shelf:

• holds a maximum of 12 video coupler WDM casettes (VCW2-C)
• mounts in either a 19-in. or 23-in. LGX-compatible rack with a removable front
door
• provides fiber routing management
• enables independent removal and addition of video coupler cassettes for
maintenance
• provides blank plates for unoccupied cassette slots
• is generally located in CO or CEV
Figure 56-1 shows the VCSL-A shelf.

Figure 56-1 VCSL-A shelf
No270
The VCSL-A shelf houses and protects the video coupler WDM cassettes. The
VCSL modularity allows system expansion on an as-needed basis. It also provides
fiber routing management into and out of the shelf while maintaining fiber bend
radius control.
The VCSL-A supports a maximum of 12 WDM cassettes per shelf. Each WDM
cassette (VCW2-C) supports two PONs. The WDM is used to distribute video
signals through the PON to individual ONTs.
56.4 Alarms
This is a passive shelf. There are no alarms present.
56.5 Connections
Figure 56-1 shows the output connectors.
Table 56-2 lists the physical specifications of the VCSL-A shelf.
Table 56-2 Physical specifications
Height 7 in. (17.78 cm)
Width 17 in. (43.18 cm)
(1 of 2)

Depth 11 in. (27.94 cm)
Weight 8 lb (3.36 kg)
(2 of 2)

57.4 Optical budget 57-3

57.1 Identification
Table 57-1 provides identification information about LGX VCW2-C.
Table 57-1 Identification of VCW2-C

code
3EM 11046 AC VCW2-C Video coupler BVPMBEABAA W73067 134412

WDM cassette, 2
PON, version C
The LGX VCW2-C cassette provides:

• overlay video signal inserted into downstream traffic to the ONT
• modular cassettes designed for scalability that matches the PONs on the LT cards
• 2 wavelength division multiplexers (WDMs) that support a maximum of two
PONs
• 6 port connections with front access, including PON and V-OLT ports equipped
with SC/APC and P-OLT ports equipped with SC/UPC connectors
• adapters for PON connections equipped with shutters for safety
• industry standard vertical LGX cassette
• easy installation into the VCSL-A or any LGX-compatible shelves
The VCW2-C is located in a CO, CEV, or remote terminal. It is compliant with

GR-1209 and GR-1221 requirements. The connectors are compliant with GR-326
requirements.
A VCW2-C is installed in the VCSL-A shelf. Each VCW2-C contains two WDM
units. Each WDM unit is connected to a PON in the P-OLT system.
The function of the VCW2-C is to merge the optical traffic from P-OLT and V-OLT
WDM. The VCW2-C injects the 1550 nm video traffic from the V-OLT onto the
1490 nm traffic from the P-OLT. The resulting multiwavelength traffic is then
passed through the PON to the ONT at the subscriber site. The 1310 nm upstream
traffic from the ONT is routed through the VCW2-C to the P-OLT port.
Figure 57-1 shows an illustration of the VCW2-C.

Figure 57-1 VCW2-C
57.4 Optical budget
The video coupler optical budget information is divided into two sections: one for
VCW2 connectors and the other for the WDM.
Table 57-2 provides the optical budget of VCW2 connectors.
Table 57-2 Optical budget of VCW2 connectors
Parameter Condition Minimum Maximum
Insertion loss Mated pair — 0.3 dB
Return loss UPC 50 dB —
Return loss APC 60 dB —
Return loss UPC 50 dB —
Table 57-3 provides the optical budget of WDM.
Table 57-3 Optical budget of WDM
Parameter Minimum Maximum Notes

Video band 1539 nm 1565 nm —
Data bands 1260 nm 1360 nm —
1480 nm 1500 nm —
Data isolation 20 dB — Worst point over data
bands
(1 of 2)

Parameter Minimum Maximum Notes
Video isolation 20 dB — Worst point over

video bands
Insertion loss — 0.8 dB Port-to-port

(connectorized
pigtail)
Polarization mode — 0.1 ps All ports, over data

dispersion (PMD) and video bands
Polarization dependent — 0.1 dB All ports, over data

loss (PDL) and video bands
Chromatic dispersion –1 ps/nm +1 ps/nm All ports, over data

(CD) and video bands
Directivity 55 dB — All ports, over data

and video bands
Return loss 55 dB — All ports, over data
and video bands
(2 of 2)
57.5 Optical safety
VCW2-C.
The VCW2-C contains optical components that must be placed in a controlled


Note
year.
57.7 Connections
There are six SC type connectors at the front of the VCW2-C. There are two sets of
three connectors. The functions of the connectors are described as follows:
Figure 57-2 shows the input and output connectors.
Figure 57-2 VCW2-C input and output connectors
SC/APC
PON
SC/UPC
P-OLT
SC/APC
V-OLT
SC/APC
PON
SC/UPC
P-OLT
SC/APC
V-OLT
VCW2-x
FGU051
Table 57-5 lists the physical specifications of the VCW2.
Table 57-5 VCW2 physical specifications
Height 5.10 in. (12.95 cm)
Width 1.15 in. (2.92 cm)
Depth 6.36 in. (16.15 cm)
(1 of 2)

(2 of 2)

Glossary
10/100Base-T 10- to 100-Mb/s LAN

An IEEE standard for 10/100 Mb/s twisted-pair Ethernet wiring.
1000Base-LX An IEEE 802.3 LAN transmission standard for 1000 Mb/s gigabit Ethernet
(GE) using Long Wavelength (LX) laser transmitters over fiber-optic cable.
1000Base-SX An IEEE 802.3 LAN transmission standard for 1000 Mb/s gigabit Ethernet
(GE) using Short Wavelength (SX) laser transmitters over fiber-optic cable.
10Base-T An IEEE 802.3 LAN transmission standard for Ethernet. 10Base-T carries
data at 10 Mb/s to a maximum distance of 328 ft (100 m) over unshielded
twisted-pair cabling.
5520 AMS 5520 Access Management System
The Alcatel-Lucent UNIX-based, client-server architecture controller for
various NE systems.
5523 AWS The Alcatel-Lucent 5523 Access Workstation
The Alcatel-Lucent client-server architecture controller for
7342 ISAM FTTU systems.
5526 AMS The Alcatel-Lucent 5526 Access Management System
The Alcatel-Lucent UNIX-based, client-server architecture controller for
7342 ISAM FTTU systems.
5528 WAM 5528 Web-based Access Manager
The Alcatel-Lucent 5528 Web-based Access Manager is a web server-based
network manager software. The 5528 WAM allows registered users to
connect to the NE through the Internet or craft port, providing a uniform and
simplified method of monitoring, provisioning, and configuring NEs.
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 GL-1

Glossary
AAA server Authentication, Authorization, Accounting server

AACU-C Alarm Control Unit, Version C
A card that performs alarm control functions and provides connectivity for
a craft terminal and Ethernet 10Base-T connectivity for maintenance access.
AAI Access-to-Access Interface
The interface that the line termination (LT) card uses to subtend to the
passive optical network (PON).
ACK Acknowledgement
ACL Access Control List
ACO Alarm Cut Off
ACO is a push button that allows the audible alarms to be extinguished
without affecting the visual alarms. The audible alarms can be toggled as
enabled or disabled.
ACU Alarm Control Unit
A component located on the optical line termination (OLT) shelf that
collects rack alarms, controls top rack unit alarm displays, and provides an
alarm interface to the central office alarm system
AFAN Fan
A fan unit installed at the bottom of each optical line termination (OLT)
shelf.
AFAN-H Fan, version H
A fan unit installed at the bottom of each optical line termination (ALTS-N)
shelf. AFAN-H is only used in the ETSI market.
AFAN-P Fan, version P
A fan unit installed at the bottom of each optical line termination (OLTS-K)
shelf. AFAN-P is only used in the ANSI market.
AFAN-R Fan, version R
A fan unit installed at the bottom of each optical line termination (OLTS-L)
shelf. AFAN-R is only used in the ANSI market.
AFAN-S Fan, version S
A fan unit installed at the bottom of each optical line termination (OLTS-M)
shelf. AFAN-S is only used in the ETSI market.
AFE Analog Front End
AGC Automatic Gain Control
An electronic device that controls the gain of a signal to ensure some level
of performance over changing conditions.
GL-2 October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Glossary
AID Access Identifier

AIS Alarm Indication Signal
ALM Alarm
ALTS-N ADSL Line Termination Shelf, version N
The ASAM shelf that provides mounting locations and slide-in rails for unit
insertion into backplane-mounted connectors. The ALTS-N is only used in
the ETSI market.
ANSI American National Standards Institute
A nonprofit, nongovernmental body supported by over 1000 trade
organizations, professional societies, and companies; ANSI was established
for the creation of voluntary industry standards.
APAC Asia Pacific
APC American Power Conversion
APS Automatic Protection Switching
The capability of a transmission system to detect a failure on a working
facility and switch to a protection facility to recover the traffic, thus
increasing overall system availability
ARP Address Resolution Protocol
A protocol within TCP/IP that maps IP addresses to Ethernet
MAC addresses. TCP/IP requires ARP for use with Ethernet
ASCII American Standard Code for Information Interchange
Coding method used to convert letters, numbers, punctuation, and control
codes into digital form
ATM Asynchronous Transfer Mode
A switching and multiplexing technique in which information is organized
into fixed length cells, with each cell consisting of an identification header
field and an information field. ATM is asynchronous because the use of the
cells depends on the required or instantaneous bit rate.
AU Automatically Out-of-Service
An alarm signal that indicates that the unit failed and is automatically taken
out-of-service
AUMA Automatically and Manually Out-of-Service
An alarm signal that indicates that the unit failed and the user has manually
(administratively) taken it out of service.
AWG American Wire Gauge
AWG is a standard measuring gauge for non-ferrous conductors.

Glossary
BAC Buffer Acceptance Control

BATA Battery A
BATB Battery B
BATRET Battery Return
BER Bit Error Rate
Measure of transmission quality expressed as the percentage of received bits
in error compared to the total number of bits received.
BITS Building Integrated Timing Supply
BITS-A BITS backplane adapter, version A
BITS-A is only used in the ANSI market.
BITS-B BITS backplane adapter, version B
BITS-B is only used in the ETSI market.
BMLD Burst Mode Laser Driver
BOOTP Bootstrap Protocol
Application layer configuration protocol that allows a host to configure itself
dynamically at boot time. This protocol provides 3 services:
• IP address assignment
• Detection of the IP address for a serving machine
• The name of a file to be loaded and executed by the client machine
BRAS Broadband Remote Access Server
BW Bandwidth
C-VLAN Customer VLAN
CAC Connection Admission Control
CAC is an algorithm that evaluates whether a new service can be added to a
VLAN on a PON, and whether a new VLAN can be added to a gigabit
Ethernet port or LAG on the NT.
CB Circuit Breaker
CBN Common Bonding Network
CC Cross Connect
CDE Component Development Environment
Development discipline based on the reuse of components to ease rapid
time-to-market.
CDR Clock Data Recovery

Glossary
CDRH Center for Devices and Radiological Health (U.S.)

CEMT Cable Entry Management Tray
CES Circuit Emulation Service
CEV Controlled Environment Vault
CFR Code of Federal Regulation (U.S.)
CID Channel Identifier or Consecutive Identical Digit
CLEC Competitive Local Exchange Carrier
CLEI Common Language Equipment Identifier
CLI Command Line Interface
A workstation access method interface that uses CLI commands to
communicate to any network element in the 7342 ISAM FTTU network.
CO Central Office
Telephone switching center that connects subscribers within a telephone
network.
CODEC Coder Decoder
CoS Class of Service
a method of managing traffic in a network by grouping similar types of
traffic together and treating each type as a class with its own level of service
priority.
CPE Customer Premises Equipment
Customer-owned telecommunications equipment at customer premises used
to terminate or process information from the public network
CPLD Complex Programmable Logic Device
CPU Central Processing Unit
The part of a computer that performs the logic computational and
decision-making functions
CRoHS China Restriction of Hazardous Substances
The CRoHS regulations provide information about the installation and
operation of ONT systems with regards to the use of hazardous substances
in products and subassemblies.
CSA Carrier Serving Area
A type of trunk-loop architecture that typically includes a T1 carrier, a
cluster of subscribers, and a serving area

Glossary
CSMA/CD Carrier Sense Multiple Access with Collision Detection

A data communications mode in a shared medium in which access
contention problems are solved by denying access to one of the contenders
CTAG Correlation Tag
DBA Dynamic Bandwidth Allocation
The capacity of subdividing large high-capacity network transmission
resources among multiple applications almost instantaneously and providing
each application only the share of bandwidth each application requires
dBm Decibel referenced to one millivolt across 75 ohms
DCE Data Circuit Terminating Equipment
DHCP Dynamic Host Configuration Protocol
DHCP is a client/server service that is an extension of the BOOTP protocol.
DHCP simplifies the configuration of a client workstation since no IP
addresses, subnet masks, default gateways, domain names, or DNSs must be
programmed. With DHCP, this information is dynamically leased from the
DHCP server for a predefined amount of time. Because the information is
stored on a server, it centralizes IP address management, reduces the number
of IP addresses to be used, and simplifies maintenance. RFC 2131 defines
DHCP.
DLF Destination Lookup Failure
DLP Detailed Level Procedure
DPE Drum Plate Enlarger
DS1 Digital Service Level-1
A digital circuit with a total bandwidth or transmission speed of 1.5444
million bits per second. The trunk level-1 standard of 1.5444 is in support of
24-voice conversations each encoded at 64 Kb per second.
DSCP Differentiated Services Code Point
A six-bit value encoded in the type of service field of an IP packet header. It
identifies the CoS that the packet should receive.
DSL Digital Subscriber Line
A DSL is a single twisted-pair that supports full-duplex transmission at a bit
rate of 160 kb/s (144 kb/s for 2B+D data, 12 kb/s for framing and error
correction, and 4 kb/s for the embedded operations channel).
DSP Digital Signaling Processing
DSRL Downstream rate limiting can be configured on the 7342 ISAM FTTU on a
per-ONT basis or on a per-service basis
DTE Data Terminal Equipment
A definition of hardware specifications provided for data communications.

Glossary
E-MAN Ethernet Metropolitan Area Network

EAP Extensible Authentication Protocol
EC Echo Cancellation
A technique to stop a received signal from being transmitted back to its
origin by constructing a signal closely approximating the echo component
and subtracting this from the locally transmitted signal
ECT Enhanced Craft Terminal
EDFA Erdium-Doped Fiber Amplifier
A form of fiber optical amplification in which the transmittal light signal
passes through a section of erbium-doped fiber and is amplified by means of
a laser pump diode. EDFA is used in transmitter booster amplifiers, in-line
repeating amplifiers, and receiver preamplifiers.
EE Equipment Engineering
EFM Ethernet in First Mile
EFT Electrical Fast Transient
eHCL Ethernet-based High Capacity Link
EHNT Ethernet-based High-capacity Network Termination
EIA Electronic Industries Association
Group that specifies electrical transmission standards. The EIA and TIA
have developed numerous well-known communications standards,
including EIA/TIA-232 and EIA/TIA-449.
EM Element Manager
EMC ElectroMagnetic Compatibility
EMC designates the ability of commodities to function normally in the
electromagnetic environment (this ability is termed Electromagnetic
Susceptibility [EMS]), and the ability not to generate unbearable
electromagnetic interference to other devices and equipment in the same
environment (this ability is termed Electromagnetic Interference [EMI].
These two abilities are collectively named EMC.
EMI Electromagnetic Interference
EMS Element Management System
EPC Ethernet Power Connection
EPS Equipment Protection Switching
The capability of physical equipment to detect a failure on a working facility
and switch to a protection facility to recover the traffic, thus increasing
overall system availability.
ES Error Second

Glossary
ESD Electrostatic discharge

ETSI European Telecommunications Standards Institute
The European counterpart to ANSI. Established to produce
telecommunication standards integration in the European community for
users, manufacturers, suppliers, and Post Telephone and Telegraph
administration.
EVC Ethernet Virtual Connection
Logical association of UNIs that connects subscriber sites to enable transfer
of Ethernet service frames (such as Internet data, business critical data,
video, and video conferences) between them, and prevents transfer of data
between subscriber sites that are not part of the EVC
EXNT Ethernet XAUI based (extreme-capacity) Network Termination
FAP Fuse Alarm Panel
FCC Federal Communications Commission (U.S.)
FCS Frame Check Sequence
FDA Food and Drug Agency (U.S.)
FDB Forwarding Database
FEC Forward Error Correction
FEC is an error control mechanism where the sender adds redundant
information to the original data. This is called the error correction code. This
allows the receiver to detect and correct errors without the need to request
that the original sender provide additional data to fix the error. This can
prevent the re-transmission of data, which can have high bandwidth costs,
and can avoid the creation and management of another, back-channel
connection. The 7342 ISAM FTTU uses 239/255 Reed-Solomon block
coding. The encoder intersperses parity bits into the data sequence using the
specified algorithm. The receiving end decodes using an inverse of the
algorithm. This is done in both the upstream and downstream direction.
FGND Frame Ground
FGU Feature Group Fiber to the User
FPGA Field Programmable Gate Array
An integrated chip with functions that can be programmed by software
FSST Fiber Slack Storage Tray
A tray used in the Video Coupler shelf for excess PON fiber storage
FTP File Transfer Protocol
A protocol by which clients can transfer files to a server. Commonly used to
transfer files to a web server for websites or to download files from the web
to install.

Glossary
FTTU Fiber To The User

A high-speed fiber-optic cable technology for delivery of broadband
services to home or office over and Ethernet passive optical network (PON).
GBE Gigabit Ethernet
GE Gigabit Ethernet
Ethernet interface that runs at 1000 Mb/s
GEM GPON encapsulated module
GLOB GPON Line-termination Optical Block
GLT2 GPON Line Termination with 2 PONs
GMII Gigabit Ethernet Media Independent Interface
GMQ General Membership Query
GND Ground
GNDF Ground Frame
GPON Gigabit Passive Optical Network
GSQ Group Specific Query
GTRU GPON top rack unit
GUI Graphical User Interface
A user screen that includes menus, tables, or icons to query or change data;
usually distinguished from the command line interface.
HD High Density
HS Hazardous Substance
HSI High Speed Internet
HST Hazardous Substance Table
The HST lists the hazardous substances present in products and
subassemblies, as required by CRoHS legislation.
HTRU High-density Top Rack Unit
An FTTU component that provides redundant power distribution, as well as
fuse and alarm functions, for an equipment rack housing OLTS units.
IBN Isolated Bonding Network
ICMP Internet Control Message Protocol

Glossary
IDC Insulation Displacement Connector

IEEE Institute of Electrical and Electronics Engineers
The IEEE is a worldwide engineering publishing and standards-making
body. It is the organization responsible for defining many of the standards
used in the computer, electrical, and electronics industries.
IGMP Internet Group Management Protocol
A protocol used between hosts and multicast routers on a single physical
network to establish hosts’ membership in particular multicast groups.
Version 2 of IGMP is described in RFC 2236.
IGS IGMP system on the SHub
IKE Internet Key Exchange
A CLI configuration command used to configure the IKE service based on
the information contained in the command parameters.
ILEC Incumbent Local Exchange Carrier
IOCM Input-Output Channel Manager
IP Internet Protocol
Connectionless packet-switching protocol that works together with TCP.
IPoE Internet Protocol over Ethernet
IPTV IP Television
The delivery of video services over an end-to-end IP infrastructure. IPTV
can include various classes of video services, such as video on demand,
broadcast TV, video conferencing, and mobile video.
IS In Service
ISAM Intelligent Services Access Manager
The Intelligent Service Access Manager is a DSL access multiplexer that
operates in a packet aggregation network. The ISAM enables deployment of
triple-play services, such as video on demand, high-definition TV and
broadcast TV services for all subscribers simultaneously.
ISDN Integrated Services Digital Network
An internationally accepted standard for voice, data, and signaling. There
are two basic types of ISDN service: Basic Rate Interface (BRI) and Primary
Rate Interface (PRI).
ISP Internet Service Provider
A regional network-providing Internet service

Glossary
ITU International Telecommunication Union

Standards organization that develops international telecommunications
recommendations.
IXL Index List
LACP Link Aggregation Control Protocol
An IEEE specification (802.3ad) that allows you to bundle several physical
ports together to form a single logical channel.
LAG Link Aggregation
A combination of physical network links into a single logical link used to
increase bandwidth and provide redundancy.
LAN Local Area Network
Type of network that sends and receives communications over a small area,
such as within an office or group of buildings.
LED Light Emitting Diode
A semiconductor diode that emits light when a current is passed through it.
LGX LightGuide Cross-connect
LIM Line Interface Module
LLC Logical Link Control
The common data link protocol in Layer 2 of the OSI model that multiplexes
one or more data links to and from separate service access points.
LLID Loopback Location IDentifier
During a fault investigation by a network operator, the point to which
loopback cells return from a central location in the network.
LOP Loss of Pointer
LOS Loss of Signal
A condition at the receiver or a maintenance signal transmitted in the
physical overhead, indicating that the receiving equipment has lost the
received signal.
LP MDU Low Profile Multi-Dwelling Unit
LSM Line/Server Module
LT Line Termination
MAC Media Access Control
The IEEE sublayer in a local area network that controls access to the shared
medium by local area network attached devices.

Glossary
MAU Media Attachment Unit

Ethernet connector.
MBS Maximum Burst Size
MCR Minimum Cell Rate
An available bit-rate service traffic descriptor in cells/sec. The rate at which
the source is always allowed to send.
MD MD is expanded in two ways:
• Mixed Density
• Monitor Diode
MD5 Message Digit algorithm 5
MDF Main Distribution Frame
MDI Medium Dependent Interface
MDI is a type of Ethernet port for use with twisted-pair cabling.
MDIX Medium Dependent Interface Crossover
The MDIX version of MDI enables the connection of like devices using
straight-through twisted-pair for MDI port to MDIX port connections and
crossover twisted-pair for MDI-to-MDI or MDIX-to-MDIX connections.
MDU Multi Dwelling Unit
MEN Metro Ethernet network
MIB Management Information Base
A database of network performance information that is stored on a network
agent for access by a network management station.
MII Media Independent Interface
MLT Mechanized Loop Test
MMF Multimode Fiber
An optical fiber with a core diameter from 50 to 100 microns. Most
commonly used in short distance LANs. The larger core diameter allows
broader light sources such as LEDs. Modal dispersion is a problem over
longer distances.
MoCA Multimedia over Coax Alliance
MOS Mean Opinion Scores
MPI Message Passing Interface
MPOE Minimum Point of Entry

Glossary
MTTR Mean Time To Repair

NAT Network Address Translation
NB Narrow Band
ND Neighbor Discovery
NE Network Element
Hardware or combined hardware-software that is designed to perform within
a telecommunications system.
NEBS Network Equipment Building Standards
Performance, quality, environmental, and safety standards set by Bellcore
for telecommunications equipment.
NEC U.S. National Electrical Code
Nm One billionth (10-9) of a meter
NNI Network-to-Node Interface
NR Normal
NSP Network Service Provider
NT Network Termination
A card that provides a link to an Ethernet-based network. The
7342 ISAM FTTU uses the EHNT-A, EHNT-B or EXNT-A.
NTA, or NT-A Network Termination-A
NTB Network Timing BUS
NTB, or NT-B Network Termination-B
NTP Non-Trouble Procedure
or
Network Time Protocol
NTR Network Timing Reference
OAM Operations, Administration, and Maintenance
Broad categories of functions found in a communications network and/or the
business processes found in network service provider companies.
OATD Optical Access Termination Daughterboard
OBC On-Board Controller
ODN Optical Distribution Network

Glossary
OFDF Optical Fiber Distribution Frame

The interface between optical fiber and the optical transmission equipment.
OLT Optical Line Termination
OLTS Optical Line Termination Shelf
The FTTU shelf (also called FTTU Line Termination Shelf) that provides
mounting locations and slide-in rails for unit insertion into
backplane-mounted connectors.
OLTS-K Optical Line Termination Shelf, version K
backplane-mounted connectors. The OLTS-K is only used in the ANSI
market.
OLTS-L Optical Line Termination Shelf, version L
backplane-mounted connectors. The OLTS-L is only used in the ANSI
market.
OLTS-M Optical Line Termination Shelf, version M
backplane-mounted connectors. The OLTS-M is only used in the ETSI
market.
OMCI ONT Management Control Interface
ONT Optical Network Terminal
Equipment that provides voice, data, and video services and terminates the
7342 ISAM FTTU network at a subscriber location. ONTs provide services
to a single family home, a business location, or a multidwelling residence,
such as an apartment complex or condominium. Services can include POTS,
high-speed Ethernet, IPTV, and RF video.
ONU Optical Network Unit
Equipment that provides voice, data, and video services and terminates the
7342 ISAM FTTU network at a subscriber location. ONTs provide services
to a single family home, a business location, or a multidwelling residence,
such as an apartment complex or condominium. Services can include POTS,
high-speed Ethernet, IPTV, and RF video.
OOS Out Of Service
The status of a primary rate link when it is out of service.
OOS-MA Out of Service—Maintenance

Glossary
OS Operations System
Standalone software system that supports network-related operations
functions.
OSI Open Systems Interconnection
The only internationally accepted framework of standards for
communication between different systems made by various vendors.
OSMINE Operation Systems Modification for the Integration of Network Elements
OSP Outside Plant
OSPF Open Shortest Path First
Dynamic routing protocol that responds quickly to network topology
changes. As a successor to RIP, it uses an algorithm that builds and
calculates the shortest path to all known destinations.
OSS Operations Support System
OSWP Overall Software Package
P-OLT Packet Optical Line Termination
The fully assembled shelf in the 7342 ISAM FTTU system. The P-OLT
consists of two NT cards (for redundancy), one AACU card, and 18 LT
cards.
PADI PPPoE Active Discovery Initiation
PBA Printed Board Assembly
PBIT Priority bit
PC Personal Computer
PCI Peripheral Component Interconnect
PCM Pulse Code Modulation
A form or modulation used to sample a voice signal and convert the sample
into a digital code. A digital modulation method that converts a pulse
amplitude modulated signal into a digital signal.
PCR Peak Cell Rate
The Peak Cell Rate in cells/sec; the cell rate that the source may never
exceed.
PDF Power Distribution Frame
PDV Packet Delay Variation
PE Protective Earth
PHY Physical (Medium independent)

Glossary
PID Protocol Identifier

A part of the SNAP header that identifies the protocol to be encapsulated.
PLID Physical Location Identification
PLL Phase Locked Loop
A circuit used to re-generate the far-end clock from the incoming
high-capacity multiplexing stream.
PLOAM Physical Layer Operation Administration and Maintenance
PM Performance Monitoring
A type of transport measurement that provides the continuous collection of
performance data.
PoE Power over Ethernet
A technology that enables the transmission of electrical power, along with
data, to remote devices over unshielded twisted-pair wiring in an Ethernet
network.
POLT Packet Optical Line Termination
The fully assembled shelf in the 7342 ISAM FTTU system. The POLT (or
P-OLT) consists of two NT cards (for redundancy), one AACU card, and 18
LT cards for the OLTS-L and OLTS-K, 16 LT cards for the ALTS-N, and
14 LT cards for the OLTS-M.
PON Passive Optical Network
A fiber-based network that uses passive splitters to deliver signals to
multiple users.
POTS Plain Old Telephone Service
Term used to describe narrowband, voice-only telephone service.
PPP Point-to-Point Protocol
A protocol that allows a computer to use TCP/IP with a standard telephone
line and a high-speed modem to establish a link between two terminal
installations
PPPoE Point-to-Point Protocol over Ethernet
A specification for connecting multiple computer users on an Ethernet local
area network to a remote site through common customer premises
equipment. PPPoE allows users to share a common xDSL, cable modem, or
wireless connection to the Internet. PPPoE combines the PPP protocol,
commonly used in dialup connections, with the Ethernet protocol, which
supports multiple users in a local area network. The PPP protocol
information is encapsulated within an Ethernet frame.
PPTP Point-to-Point Tunneling Protocol
PQ Priority Queue

Glossary
PRI Primary Rate Interface

One type of interface for the ISDN product. The equivalent of a T-1 circuit.
The PRI delivered to the customer premises provides a 23B+D channel
running at 1.544 Mbit/s.
PSD Packet Switched Data
PST Primary State; PON Section Trace
PSTN Public Switched Telephone Network
Telephone network based on normal telephone signaling and ordinary
switched long distance telephone circuits.
PVC Permanent Virtual Circuit
A connection set up by service order instead of on-demand signaling.
PW pseudo-wire
QoS Quality of Service
Measure of the quality of a data communications link provided to a
subscriber.
RADIUS Remote Authentication Dial in User Service
A standardized method of information exchange between a device that
provides network access to users (RADIUS client) and a device that contains
authentication and profile information for the users (RADIUS server).
RAL Restricted Access Location
RAM Remote Access Multiplexer
RB Residential Bridge
RDI Remote Defect Indication
RDM Relay Detection Mechanism
RED Random Early Detection
REN Ring Equivalency Number
RF Radio Frequency
RG Routing Gateway
RGW Residential Gateway
RH Relative Humidity

Glossary
RIP Routing Information Protocol

An interior gateway protocol defined by the IETF (RIPv1 - RFC 1058 and
RIPv2 - 2453) that specifies how routers exchange routing table information.
RIP is a routing protocol based on the distance vector algorithm. With RIP,
routers periodically exchange entire tables.
RJ-45 The RJ-45 is a single-line jack for digital transmission over ordinary phone
wire, either untwisted or twisted. It is the interface for Ethernet standards
10Base-T and 100Base-T.
RMON Remote Monitoring
RSSI Receive Signal Strength Indication
RSTP Rapid Spanning Tree Protocol
RSTP is specified in IEEE802.1w. It replaces the spanning tree protocol
specified by IEEE 802.1d. RSTP is targeted at switched networks with
point-to-point interconnections, and allows for much quicker
reconfiguration time (approximately 1 s) by allowing a rapid change in port
roles.
RT Real Time
RTCP Real-Time Control Protocol
RTL Routine Task List
RTP Real-time Transport Protocol
RTU Remote Test Unit
RU Rack Unit
A rack unit is a unit of vertical space in a standard 19-inch equipment rack.
One RU is 1.75 in.
Rx Receive (Rx) is the downstream direction on the ONT side. Receive (Rx) is
the upstream direction on the LT side.
S-VLAN Service VLAN
SC Subscriber Connector or Standard Connector or Siemon Connector
SCR Sustainable Cell Rate
SDH Synchronous Digital Hierarchy
SEC Secondary
SELV Safety Extra Low Voltage
A circuit which has no direct connection to a primary power source, but
derives its power from either a transformer, converter or equivalent isolation
device, or from a battery. It is designed and protected so that under normal
and single fault conditions, its voltages do not exceed a safe value.
SES Severely Errored Second

Glossary
SFF Small Form Factor

A physically compact connector design that has been developed for use in
fiber optic systems. These connectors are about half the size of conventional
connectors.
SFP Small Form-factor Pluggable
SFP is a specification for a new generation of optical modular transceivers.
The devices are designed for use with small form factor connectors, and
offer high speed and physical compactness. They are hot-swappable.
SFTP SSH File Transfer Protocol
SFU Single family unit
SHub Service Hub
SID System Identifier
A string up to 20 characters in length specifies a unique name for each NE
in a system.
SIP Session Initiation Protocol
SIP is an application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants. These
sessions include Internet telephone calls, multimedia distribution and
multimedia conferences.
SLC Subscriber Line Cardholder
SLIC Subscriber’s Line Interface Circuit
A component in the optical network terminal (ONT) that confers operating
states and other functionality.
SLID Subscriber Location Identification
A 10-character string set in the network element manager on a GSFU to
allow Enhanced Automated Service Turn-Up.
SMF Single Mode Fiber
Optical fiber with a core diameter of less than 10 microns that is used for
high-bandwidth transmission over long distances.
SMII Serial Media Independent Interface
SNMP Simple Network Management Protocol
Protocol used by network management to retrieve information about
connection status, configuration, and performance.
SNR Signal-to-Noise Ratio
The ratio of the value of the signal to that of the noise; often expressed in
decibels (dB).

Glossary
SNTP Simple Network Time Protocol

A method of synchronizing network nodes. An SNTP server can be used by
multiple nodes to synchronize themselves.
SoC System-on-a-Chip
SOHO Small Office Home Office
SP Strict Priority
SPI Serial Peripheral Interface
SSH Secure Shell
STB Set-Top Box
The electronic box connected to a television set. This STB receives the
incoming CATV signal and is connected to the television’s coaxial cable.
STP Spanning Tree Protocol
STP is a technique based on an IEEE 802.1d standard that detects and
eliminates forwarding loops in a bridged network. When multiple paths
exist, STP selects the most efficient path for the bridge to use. If that path
fails, STP automatically reconfigures the network to activate another path.
This protocol is used mostly by local bridges.
SWRD Single Wire Return Device
A unit that provides the ONTs with an Ethernet connection for upstream
connectivity. The SWRD unit functions as a data conversion device with two
10/100 Ethernet ports and 2 RF ports.
T-CONT Transmission Container, Traffic Container
TAP Test Access Port
or
Trouble Analysis Procedure
TB Terminal Block
TC Transmission Convergence
A sub-layer of the ATM physical layer that transforms the flow of cells into
a steady flow of bits for transmission over the physical medium.
TCA Threshold Crossing Alarm
An alarm is generated when user-defined thresholds for any one of the
profile statistics contained in a TCA profile have been exceeded. Several
statistics counters can be monitored using a single TCA profile.
TCP Transmission Control Protocol
Protocol for establishing a duplex connection between end systems for the
reliable delivery of data.

Glossary
TCP/IP Transmission Control Protocol/Internet Protocol

A networking protocol that provides communication across interconnected
networks, between computers with different hardware architectures and
various operating companies
TDM Time Division Multiplex
A transmission technique used to transmit several signals across a single
channel or bus by interleaving the signals in successive time slots. A specific
time slot or interval is assigned to each signal source
TFTP Trivial File Transfer Protocol
TIA Telecommunications Industries Association
The group responsible for setting telecommunications standards in the
United States.
TID Target Identifier
The parameter in a TL1 command that identifies the NE which is the target
for the execution of the command.
TL1 Transaction Language 1
Human-machine language standard for controlling network elements.
TLS Transport Layer Security
TNG Training Document
TNV Telecom Network Voltage
TOS Type of Service
TPID Tag Protocol Identifier
TRU Top Rack Unit
TWP Twisted Pair
Tx Transmit
Tx is in the upstream direction on the optical network terminal (ONT) side
and in the downstream direction on the line termination (LT) side.
UAI User-to-Access Interface
The link between the subscriber and the FTTU.
UART Universal Synchronous Receiver Transmitter

Glossary
UAS UAS is expanded in two ways:

• Unavailable seconds
A calculation derived by counting the number of seconds that the
interface is unavailable.
• Universal Access Server
UDP User Datagram Protocol
UDS Unit data sheet
UID User Identifier
UL Underwriters Laboratories, Inc.
UNI User-to-Network Interface
UPC Usage Parameter Control
UPS Uninterruptible Power Supply
An FTTU component that provides emergency backup power for lifeline
POTS at a subscriber’s location.
upstream Transmission from the customer location to the network. On the network
termination (NT) side, transmit (Tx) indicates the upstream direction of the
transmission to the network. On the line termination (LT) side, receive (Rx)
indicates the upstream direction of the transmission to the OLT.
UTC Coordinated Universal Time
A time scale that couples Greenwich Mean Time, which is based solely on
the Earth's inconsistent rotation rate, with highly accurate atomic time.
V ac Volts alternating current
V dc Volts direct current
V-OLT Video Optical Line Termination
VCL Virtual Channel Link
VCSL Video Coupler Shelf, LGX compatible
VCW2 Video Coupler WDM Cassette, 2 PON
A unit that is installed into the Video Coupler Shelf-LGX (VCSL) of an
FTTU system. Each VCW2 contains two WDM units, which allows each
line termination (LT) card installed in the packet optical line termination
(P-OLT) to connect to a single VCW2.

Glossary
VDSL Very-high-bit-rate Digital Subscriber Line

A technology that enables very high speed asymmetric data transmission
rates over a single twisted-pair copper telephone wire, but at shorter ranges
than other xDSL types. VDSL consists of two versions: VDSL1, which is the
original VDSL, and VDSL2. The 7342 ISAM FTTU supports VDSL2.
VDSL1 is converted to VDSL2 on migration to release FGU 04.05.05 and
higher.
VLAN Virtual Local Area Network
A VLAN divides a physical LAN into multiple virtual LANs whose
members are not necessarily based on location. VLAN specifications are
contained in IEEE 802.1Q.
VOD Video On Demand
A service that allows many users to request the same videos at the same time.
Requires a high-end video server with hundreds of gigabytes of storage.
VoIP Voice over IP
VoIP carries voice transmissions in packets and uses Internet Protocols (IP)
instead of using legacy public switched telephone network (PSTN)
circuit-switched technologies and protocols. VoIP avoids the tolls charged
for POTS.
VP/VC Virtual Path/Virtual Channel
VRF Virtual Routing and Forwarding
A logical or virtual routing function with associated routing table that can be
instantiated in a router capable of supporting IP VPN services.
W Watt
WAN Wide Area Network
A type of network that sends and receives communications over a national
area.
WDM Wavelength Division Multiplexing
A means of increasing the data-carrying capacity of an optical fiber by
simultaneously operating at more than one wavelength.
WRR Weighted Round Robin
XAUI 10 GE Attachment Unit Interface
A standard for connecting 10 Gigabit Ethernet ports to each other and to
other electronic devices on a printed circuit board.
xDSL x Digital Subscriber Line
A general term that is used to refer to more than one type of unspecified DSL
(for example, ADSL, ADSL2, READSL, SHDSL, VDSL2).
XFP 10-gigabit Ethernet (GE) small form-factor pluggable

Glossary
YP Yellow Pages

Index
Numbers AACU-C, 31-1

alarm control functions, 31-4
1490 nm, 24-2 alarm input/output, 31-6
15 min counters, 19-3 CO alarm system, 31-4
15-min counters, 19-3 features and descriptions, 31-2
1550 nm, 24-2 functions, 31-2
7342 ISAM FTTU HTRU, 31-2
access network, 25-7 identification, 31-2
functional blocks, 5-2 interface to HTRU, 31-6
functionality, 25-10 interfaces and connections, 31-6
GPON features, 1-4 OAM interface, 31-6
OAM tests, 13-6 rack-level alarms, 31-4
service delivery, 25-3 telemetry alarm system, 31-4
service features, 1-5 account login management, 20-17
triple play, 25-1 AFAN-H, 32-1
unit data sheet, 30-2 back panel, 32-3
7342 ISAM FTTU EVC implementation, 28-8 cable assembly, 32-4
7342 ISAM FTTU VLAN usage, 21-3 electrical specifications, 32-4
802.1ag, 13-6 features and descriptions, 32-2
filter assembly, 32-4
A front panel, 32-3
functions, 32-2
AACU, 31-1
identification, 32-2
alarm LEDs, 31-5
physical specifications, 32-4
dimensions, 31-8
AFAN-S, 33-1
physical description, 31-8
electrical specifications, 33-3
weight, 31-8
features and descriptions, 33-2
AACU-A, 6-9
filter assembly, 33-3
front panel, 33-3
Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 IN-1

Index
AFAN-S (continued) — burst size
functions, 33-2 ATRU-N, 36-1

identification, 33-2 features and application notes, 36-2
physical specifications, 33-3 functional description, 36-2
alarms identification, 36-2
CES, 26-8 physical description, 36-4
fault isolation, 9-1 ATRU-U, 37-1
IGMP and IP multicast, 14-27 identification, 37-2
monitoring, 7-7
RTCP failure, 22-77 B
troubleshooting, 9-1
VoIP, 22-73, 22-77 B8ZS, 26-10
allocating backplane peformance monitoring, 19-7
bandwidth, 18-24 bandwidth
ALTS-N, 6-4, 34-1, 50-1 allocating, 18-24
backplane connectors and cables, 34-4, CAC check, 21-39
50-5 CAC check for S-VLAN, 21-40
features and application notes, 34-2, 50-2 DBA, 18-24
general description, 34-2, 50-3 profile, 18-23
identification, 34-2, 50-2 reserved, 18-24
MAC address label, 6-4 SHub VLAN capacity check, 21-39
physical description, 34-7, 50-12 BITS, 26-8, 26-11
physical location identification, 34-6, 50-6 BITS-B, 38-1
power distribution, 34-6, 50-6 features, 38-2
AMI, 26-10 general description, 38-2
anti-spoofing, 20-19 identification, 38-2
ARP, 17-4 location, 38-3
gratuitous ARP anti-spoofing, 20-19 Blank LT filter plate, 39-1
P-OLT, 20-22 features and application notes, 39-2
source address anti-spoofing, 20-20 general description, 39-2
application notes, 4-1 identification, 39-2
FGU 04.04.xx, 4-2 physical description, 39-2
FGU 4.2, 4-4 Blank NT filler plate, 40-1
FGU 4.3.0, 4-3 features and application notes, 40-2
FGU 4.3.5, 4-3 general description, 40-2
ARP spoofing, 17-4 identification, 40-2
ASM multicast, 14-17 physical description, 40-2
ATRU-M, 35-1 bridge ports
features and application notes, 35-2, 37-2 associating with flow mirroring VLANs,
front panel, 35-3, 37-3 21-9
general description, 35-2, 37-2 bridging
identification, 35-2 VLAN scalability, 21-42
indicator LEDs and test button, 35-3, 37-3 broadcast domains
PBA-ATRU-G board, 35-4, 37-4 creating for VLANs, 21-3
physical description, 35-6, 37-6 burst size, 18-8
IN-2 October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Index
business ONT — configuring
business ONT payload size, 26-11

CES, 26-2 QoS, 26-8
connection capacity, 6-12 RTP header, 26-8, 26-11
DS1/E1 ports, 26-2 SAToP overview, 26-5
business services; See Ethernet services services handling, 26-6
signaling mode, 26-11
C timeslot mapping, 26-11
timing, 26-8, 26-11
C-VLAN differentiated services on a UNI, Tx ECID, 26-11
21-23 CLI access protocols, 7-5
C-VLAN ID clocking
limiting the number learned, 15-8 adaptive clock, 26-8, 26-11
C-VLAN learning mode, 15-14 BITS, 26-8, 26-11
configuration, 15-20 differential clock, 26-8, 26-11
C-VLAN learning VLANs, 21-4, 21-7 local oscillator, 26-8, 26-11
features, 21-7 configuration elements
CAC GENIP service, 29-2
bandwidth check, 21-39 configuring
bandwidth check for S-VLAN, 21-40 7342 ISAM FTTU access network, 25-7
LAG bandwidth check, 21-39 DHCP, 25-28
LT, 21-40 equipment, 25-11
NT bandwidth check, 21-39 filter policy, 25-18
PON, 21-40 forwarding, 25-23
SHub VLAN bandwidth capacity check, IGMP, 14-35, 25-25
21-39 IP edge aggregation and routing, 25-5
Capacity IP filter policy, 25-19
technical specifications, 8-4 IP multicast, 25-25
CAS, 26-11 IP routing, 25-22
CES, 1-8 IP/MPLS network, 25-4
AES encryption, 26-11 layer 2 forwarding, 25-24
alarms, 26-8 MAC filter policy, 25-18, 25-19, 25-19,
clocking, 26-8, 26-11 25-19
configuration, 26-11 ONT UNI port, 25-31
congestion handling, 26-8 PON VLAN, 25-20
DS1/E1 port parameters, 26-9 PPPoE, 25-30
expected ECID, 26-11 Proxy ARP, 25-30
frames per packet, 26-11 QoS, 18-28, 25-17
interworking function, 26-6, 26-7 routing protocols, 25-23
IWF, 26-6, 26-7 STP, 25-15
jitter buffer, 26-8 subscriber connections, 25-28
MAC address, 26-11 subscriber services, 25-30, 25-31
MEF-8 packets, 26-2, 26-6, 26-7 v-VPLS, 25-20
micro span, 27-2 VLAN, 25-20
overview, 26-2 VLANs, 21-3
payload length, 26-7 VRF, 25-22

Index
congestion management elements — dynamic multicast stream
congestion management elements, 18-9 downstream rate limiting, 18-13, 18-31

downstream rate limiting, 18-13 per ONT, 18-15
p-bit to queue mapping, 18-10 per service, 18-15
ports, 18-10 traffic scheduler, 18-15
priority queue profile, 18-17 downstream tagging
scheduler and queues, 18-10 at LT, 21-24
switch, 18-9 at ONT, 21-29
T-CONT and GEM ports, 18-18 modes, 21-18
traffic scheduler, 18-11 options, 21-2
constraints pass-through VLANs, 21-25
Ethernet services configuration, 28-17 stacked VLANs, 21-25
Ethernet services hardware, 28-17 transmit to port with tag, 21-18
Ethernet services system, 28-17 transmit to port without tag, 21-19
continuity check, 13-6 unstacked VLANs, 21-25
control data records, 14-34 DS1
counters AMI, 26-10
15-min counters, 19-2, 19-3 B8ZS, 26-10
filters, 19-3 CES encapsulation, 26-6
IGMP and IP multicast, 14-27 encoding, 26-10
restrictions, 19-6 extended superframes, 26-10
rolling counters, 19-2, 19-6 framing, 26-10
TCA thresholds, 19-3 jitter buffer, 26-8
cross-connect mode, 15-12 line length, 26-11
configuration, 15-21 modes, 26-9
cross-connect VLANs, 21-5 payload length, 26-7
features, 21-5 port configuration, 26-9
structured mode, 26-9
D superframes, 26-10
synchronization, 26-8, 26-11
data and IPTV service, 1-5 unstructured mode, 26-9
DBA, 18-24 DS1/E1
denial of service, 20-23 CES, 26-6
DHCP jitter buffer, 26-8
configuring for end-to-end, 25-28 payload length, 26-7
Option 82, 10-3 DS1/E1 CES, 1-8
DHCP Option 90, 22-72 DSCP, 18-5
DHCP relay agent, 10-1, 11-1, 12-1 p-bit mapping, 18-5, 18-36
configuration, 10-4 DSX-1
function, 10-2, 10-6, 12-2 line length, 26-11
parameters, 10-5, 25-29 dual SIP client mode, 22-14
virtual router configuration, 10-5 dynamic multicast stream, 14-19, 14-20
differentiated services on a UNI, 21-23
downstream forwarding
VLAN translation with EtherType
classification, 21-21

Index
E — Ethernet virtual connections
E equipment layout, 6-1

ONT equipment, 6-12
E1 P-OLT equipment, 6-2
AMI, 26-10 V-OLT equipment, 6-9
CES encapsulation, 26-6 Ethernet frames
encoding, 26-10 broadcast, 28-4
framing, 26-10 downstream tagging at ONT, 21-29
HDB3, 26-10 downstream tagging stacked VLANs,
impedance, 26-11 21-25
jitter buffer, 26-8 L2 control protocol, 28-4
modes, 26-9 MEN to CPE, 28-4
payload length, 26-7 multicast, 28-4
PCM 30, 26-10 p-bit marking untagged frames, 21-31
PCM 31, 26-10 pass-through tagging mode, 21-17
port configuration, 26-9 processing at the LT, 21-24
structured mode, 26-9 processing at the ONT, 21-29
synchronization, 26-8, 26-11 stacked tagging mode, 21-16
unstructured mode, 26-9 tagging downstream at LT, 21-24
egress rate, 18-9 tagging options, 21-2
eHCL, 44-2, 45-3, 46-4, 47-3 transmission over EVCs, 28-6
redundancy, 44-2, 45-3, 46-4, 47-3 unicast, 28-4
EHNT unstacked tagging mode, 21-17
alarm LEDs, 41-8 upstream tagging at LT, 21-26
features and application notes, 41-6, 48-2 upstream tagging at ONT, 21-30
general description, 41-7, 48-2 VLAN tagging, 21-15
identification, 41-2, 48-2 VLAN tagging modes, 21-16
interfaces and connectors, 41-8, 48-17 Ethernet services, 28-2
optical budgets, 48-4 configuration constraints, 28-19
optical module power and modulation configuration elements, 28-9
frequency, 48-3 configuration models, 28-11
physical description, 41-11, 48-17 element relationships, 28-8
power supply, 41-10, 48-17 EVC flows, 28-11
supported optical modules, 48-2 EVC models, 28-8
EHNT-A, 41-1, 48-1 EVC portals, 28-11
EMS external EVC models, 28-16
5520 AMS, 1-10 hardware constraints, 28-17
GENIP service, 1-10, 7-6 internal EVC models, 28-12
encoding, 26-10 maximum configurable EVC portals, 28-18
Environmental conditions supported functionality, 28-2
technical specifications, 8-14 supported ONTs, 28-18
equipment system constraints, 28-17
configuring for end-to-end, 25-11 Ethernet switch, 18-9
Ethernet virtual connections, 28-6
configuration constraints, 28-19
configuration elements, 28-9

Index
Ethernet virtual connections (continued) — FGU 4.3.0 release
element relationships, 28-8 EVC portals

Ethernet frame transmission, 28-6 configuration, 28-11
EVC flows, 28-11 maximum configurable, 28-18
EVC portals, 28-11 EVC types
external models, 28-16 multipoint-to-multipoint, 28-7
hardware constraints, 28-17 point-to-point, 28-6
implementation on 7342 ISAM FTTU, rooted-multipoint, 28-7
28-8 EVC; See EVC types, EVC flows, EVC portals,
internal models, 28-12 EVC configuration, EVC models
models, 28-8 EXNT
multipoint-to-multipoint, 28-7 alarm LEDs, 42-7
point-to-point, 28-6 features and application notes, 42-5
rooted multipoint, 28-7 general description, 42-6
supported ONTs, 28-18 identification, 42-2
system constraints, 28-17 interfaces and connectors, 42-7
types, 28-6 physical description, 42-9
EtherType classification, 21-22 power supply, 42-9
upstream tagging, 21-36 ExNT
EVC configuration backplane performance monitoring, 19-7
configuration constraints, 28-19 performance monitoring, 19-7
external, 28-16 EXNT-A, 42-1
hardware constraints, 28-17 extended superframes, 26-10
internal, 28-12 external EVC models, 28-8
ONT support, 28-18 configuration, 28-16
system constraints, 28-17 T-CONT per CoS, 28-16
EVC constraints T-CONT per EVC, 28-16
configuration, 28-19 types, 28-16
hardware, 28-17
maximum EVC portals, 28-18 F
system, 28-17
EVC elements fan unit, 32-2, 33-2
bandwidth, 28-11 fault isolation
EVC flows, 28-11 alarms, 9-1
EVC portals, 28-11 loopbacks, 13-5
p-bit translation profiles, 28-11 Feature description, 2-1
per service DSRL, 28-11 Feature details, 3-1
priority queue profiles, 28-11 FEC
QoS marker and session profiles, 28-11 upstream support, 5-7
S-VLAN, 28-11 FGU 04.04.xx release
EVC flows application notes, 4-2
configuration, 28-11 FGU 4.2 release
EVC models, 28-11 application notes, 4-4
external, 28-16 FGU 4.3.0 release
internal, 28-12 application notes, 4-3

Index
FGU 4.3.5 release — GTRU-B
FGU 4.3.5 release identification, 44-2, 47-2

application notes, 4-3 interfaces and connections, 44-4, 47-5
FILT-A, 6-9 OBC, 44-2, 47-3
filter policy performance monitoring, 19-7
configuring for end-to-end, 25-18 physical description, 44-7, 47-5
CPU filter, 25-18 power, 44-7, 47-5
IP filter, 25-18 version A and B difference, 47-3
MAC filter, 25-18 GLT2-A, 6-8
flexible mode GLT4, 45-1
configuration options, 21-22 alarm LEDs, 45-3
upstream tagging, 21-37 backplane performance monitoring, 19-7
flow mirroring VLANs, 21-9 dimensions, 45-5
associating with bridge ports, 21-9 features and application notes, 45-2
features, 21-10 front panel, 45-4
forwarding identification, 45-2
configuring for end-to-end, 25-23 interfaces and connections, 45-4
layer 2, 25-24 OBC, 45-3
fractional TDM, 26-6 performance monitoring, 19-7
Functional description physical description, 45-5
5520 AMS, 7-6 power, 45-5
EMS functions, 7-5 GLT8, 46-1
functional description, 5-1 alarm LEDs, 46-4
7342 ISAM FTTU functional blocks, 5-2 dimensions, 46-7
P-OLT functional blocks, 5-2 features and application notes, 46-3
V-OLT functional blocks, 5-9 front panel, 46-5
functionality identification, 46-2
7342 ISAM FTTU, 25-10 interfaces and connections, 46-5
OBC, 46-4
G physical description, 46-7
power, 46-7
GEM GPON
performance monitoring, 19-7 optical line rate, 1-2, 8-13, 13-2
GEM port, 18-18 performance monitoring, 19-7
GEM traffic descriptor, 18-21 GPON 15 min counters
network CTP, 18-21 P-OLT, 19-3
GEM traffic descriptor, 18-21 gratuitous ARP requests
GENIP service, 1-8 anti-spoofing, 20-19
configuration elements, 29-2 GTRU-B, 37-1
overview, 29-2 front panel, 37-3
GLT2, 44-1, 47-1 identification, 37-2
alarm LEDs, 44-4, 47-4
backplane performance monitoring, 19-7
dimensions, 44-7, 47-5
features and application notes, 44-2, 47-2
front panel, 44-4, 47-5

Index
H — IP multicast stream
H infrastructure
IP multicast and IGMP, 14-4
hardware constraints QoS, 18-2
Ethernet services, 28-17 ingress rate, 18-8
maximum configurable EVC portals, 28-18 internal EVC models, 28-8
hardware support all-to-one bundling and multiple CoSs,
GLT cards for Ethernet services, 28-18 28-15
ONTs for Ethernet services, 28-18 all-to-one bundling and single CoS, 28-14
HDB3, 26-10 bundling and CoS definitions, 28-12
header and tag manipulation, 21-15 bundling and multiple CoSs, 28-13
HSI bundling and single CoS, 28-13
performance monitoring, 19-7 configuration, 28-12
HTTP digest, 22-73 types, 28-12
IP edge aggregation and routing, 25-5
I IP filter policy
configuring for end-to-end, 25-19
IGMP
IP multicast
alarms, 14-27
alarms, 14-27
configuration, 14-35
ASM, 14-17
provisioning IGMP system, 14-35
provisioning video subscriber, 14-35
control data records, 14-34
requirements, 14-35
counters, 14-27
IGMP signaling, 14-5
counters, 14-27
nonconfigured, 14-19
fast leave, 14-27
packages, 14-31
join and leave messages, 14-20
access control, 14-32
LT-to-ONT signaling, 14-20
creating, 14-32
disabled, 14-21
generating CDR, 14-34
enabled, 14-21
pre-view, 14-34
performance monitoring, 19-7
preconfigured, 14-19
processing limits, 14-25
service networks, 14-10
proxy, 14-6, 14-9
IP subscriber, 14-10
signaling, 14-5
PPPoE subscriber, 14-14
snoop, 14-9, 14-9
SSM, 14-17
source specific multicast, 14-17
streams
SSM, 14-17
dynamic, 14-19, 14-20
standard leave, 14-27
flow, 14-4
IGMP fast leave leave, 14-27
static, 14-19, 14-20
IGMP messages, 14-20
video management, 14-31
IGMP proxy, 14-6
IP multicast and IGMP, 14-2
IGMP signaling, 14-5
infrastructure, 14-4
join and leave messages, 14-20
IP multicast stream
IGMP snoop, 14-9
dynamic, 14-19, 14-20
IGMP standard leave, 14-27
flow, 14-4
indoor ONT
static, 14-19, 14-20
connection capacity, 6-12

Index
IP routing — MEF-8
IP routing line length, 26-11

configuring for end-to-end, 25-22 link trace, 13-6
IP/MPLS network, 25-4 Litespan
IWF, 26-6, 26-7 micro span, 27-2
loopbacks, 13-5, 13-6
J LT
CAC, 21-40
jitter buffer, 26-8 downstream tagging, 21-24
jitter buffer statistics, 22-73 downstream tagging for pass-through
join and leave messages, 14-20 VLANs, 21-25
join messages downstream tagging for unstacked
processing at LT card, 14-23 VLANs, 21-25
downstream tagging stacked VLANs,
L
21-25
LAG Ethernet frames processing, 21-24
CAC bandwidth check, 21-39 forwarding architecture, 15-2
layer 2 forwarding, 15-2 upstream tagging, 21-26
architecture, 15-2 upstream tagging for stacked VLANs,
LT, 15-2 21-27
NT, 15-4 upstream tagging for unstacked VLANs,
ONT, 15-5 21-28
C-VLAN learning mode configuration, upstream tagging pass-through VLANs,
15-20 21-28
configuring for end-to-end, 25-24 LT card
cross-connect mode configuration, 15-21 processing join messages, 14-23
MAC filters, 15-22 LT-to-ONT signaling, 14-20
modes on LT, 15-9 disabled, 14-21
C-VLAN learning, 15-14 enabled, 14-21
cross-connect (transparent), 15-12
residential bridge, 15-10 M
pause frames, 15-22 MAC, 44-2, 45-3, 46-4, 47-3
residential bridge mode configuration, MAC address, 26-11
15-18, 15-19 limiting the number learned, 15-8
downstream frame forwarding, 15-19 MAC filter policy
upstream frame forwarding, 15-18 configuring for end-to-end, 25-18, 25-19,
rules on NT, 15-6 25-19, 25-19
classifying interfaces, 15-6 MAC filters, 15-22
learning MAC addresses, 15-7 MEF-8, 1-8
switching flood traffic, 15-7 expected ECID, 26-11
subscriber scalability, 15-23 overview, 26-2
transparent protocol forwarding, 15-22 packets, 26-6
Layer 2 VPNs, 21-42 payload size, 26-11
limiting timestamps, 26-8, 26-11
learned C-VLAN IDs, 15-8 Tx ECID, 26-11
learned MAC addresses, 15-8

Index
MEN services — outdoor ONT
MEN services; See Metro Ethernet services craft terminal, 7-4

Metro Ethernet services management interfaces, 7-2
7342 FTTU implementation, 28-4 manual tasks, 7-6
Ethernet frames transmission, 28-4 ONT FLASH repair information, 7-7
EVC types supported, 28-6 OSMINE certification, 7-7
infrastructure, 28-4 TL1 access protocol option, 7-5
micro span, 27-2 OAM tests, 13-6
network example, 27-2 OLT rack, 49-1
Microspan features and application notes, 49-2
workflow, 27-3 general description, 49-3
mirror packet VLAN tagging, 21-10 identification, 49-2
MoCA OLTS-M, 6-6
RF video interaction, 24-2 MAC address label, 6-6
modes ONT
layer 2 forwarding on LT, 15-9 downstream tagging modes, 21-29
VLANs, 21-4 Ethernet services support, 28-18
Modular ONT forwarding architecture, 15-5
TCA, 13-3 RF video network example, 24-3
VDSL performance monitoring, 13-3 ONT equipment, 6-12
VoIP statistics, 22-73 loopbacks, 13-5
modular ONT performance monitoring, 19-6
connection capacity, 6-12 ONT safety
modulation frequency, 48-3 electrostatic discharge, xviii
monitoring thresholds and levels, 19-7 ONT UNI
multicast packages, 14-31, 14-32 downstream tagging modes, 21-18
multipoint-to-multipoint EVC, 28-7 Ethernet services configuration, 28-11
upstream tagging modes, 21-19
N ONT UNI port
nonconfigured multicast, 14-19 ONTs
NT Ethernet frames processing, 21-29
CAC bandwidth check for SHub VLAN, upstream tagging modes, 21-30
21-39 optical budgets, 48-4
forwarding architecture, 15-4 optical module power, 48-3
layer 2 forwarding rules, 15-6 optical module power and modulation
NT redundancy frequency, 48-3
data synchronization, 16-6 Optical modules
multiple bridge port configuration, 16-3 technical specifications, 8-13
multiple upstream switches, 16-3 Option 82, 10-3
single bridge port configuration, 16-2 OSMINE certification, 7-7
Outdoor ONT
O
VoIP statistics, 22-73
OAM, 7-1 outdoor ONT
5523 AWS, 7-5 connection capacity, 6-12
CLI access protocol option, 7-5

Index
Overview — Power specifications
Overview P-OLT equipment layout, 6-2

5520 AMS, 1-10 P-OLT functional blocks
7342 ISAM FTTU, 1-2 line termination, 5-7
network ONT interfaces, 1-10 network termination, 5-4
network P-OLT interfaces, 1-9 P-OLT rack, 49-2
network V-OLT interfaces, 1-9 pass-through tagging, 21-17, 21-17
overview pass-through tagging upstream, 21-19, 21-32
element management system, 1-10 pass-through VLANs
GENIP service, 29-2 downstream tagging, 21-25
IP multicast and IGMP, 14-2 upstream tagging, 21-28
network interfaces, 1-9 pause frames, 15-22
PCM 30, 26-10
P PCM 31, 26-10
per-service
P-bit, 18-4 , 20-22
C-VLAN to S-VLAN p-bit translation performance monitoring, 7-7
profile, 18-6 counters, 13-3, 19-2
CoS mapping, 18-5 ExNT, 19-7
DSCP mapping, 18-5 GEM ports, 19-7
queue mapping, 18-10 GLT2, 19-7
UNI-side to network-side p-bit translation GLT4, 19-7
profile, 18-6 GPON, 19-7
p-bit marking GPON optical line levels, 13-2
compatible configurations, 21-18 HSI, 19-7
copy mode, 21-18 IGMP, 19-7
LT, 21-17 ONT, 19-6
map mode, 21-18 P-OLT, 19-6, 19-7
S-VLAN, 21-17 RMON Ethernet statistics, 19-15
set mode, 21-18 TCA, 13-3
untagged frames, 21-31 VDSL, 13-3
p-bit overlapping mode, 21-23 VLAN, 19-7
P-OLT PING, 7-7, 13-3
AACU-A, 6-9 Pluggable units, 6-7
Backplane, 6-7 point-to-point EVC, 28-6
cards, 6-7 PON
FILT-A, 6-9 CAC, 21-40
GLT2-A, 6-8 subscriber scalability maximum, 15-25
loopbacks, 13-5 PON fiber protection, 5-8
performance monitoring, 19-6, 19-7 PON interfaces, 44-2, 45-3, 46-4, 47-3
Rack (ETSI), 6-2 PON VLAN
SANC-D, 6-9 configuring for end-to-end, 25-20
technical specification, 8-2 ports, 18-10
VoIP statistics, 22-73 Power specifications, 8-15
P-OLT equipment input voltage, 8-15
ALTS-N shelf, 6-4, 6-6 power consumption, 8-15

Index
PPPoE — RF overlay breakdown
PPPoE priority queue profile, 18-17

configuring for end-to-end, 25-30 queues, 18-10
PPPoE relay agent, 10-1, 11-1, 12-1 reserved bandwidth, 18-24
configuration, 11-2 scheduler, 18-10
function, 11-2 T-CONT, 18-18
pre-view subscription, 14-34 traffic classification, 18-4
preconfigured multicast, 14-19 traffic policing, 18-8
priority queue profile, 18-17 traffic scheduler, 18-11
processing limits traffic shaping, 18-22
IGMP messages, 14-25 upstream queuing and scheduling, 18-32
profile VLAN configurations, 18-28
bandwidth, 18-23 queues, 18-10
priority queue, 18-17 p-bit mapping, 18-10
QoS marker, 18-7 queuing and scheduling
Protection downstream, 18-29
PON fiber, 5-8 downstream at the LT, 18-30
Proxy ARP, 17-2 downstream at the network, 18-30
configuring for end-to-end, 25-30 downstream at the NT, 18-30
functions, 17-2 downstream at the ONT, 18-31
proxy ARP upstream, 18-32
persistence, 17-3 upstream at the LT, 18-34
process flow, 17-2 upstream at the NT, 18-35
static IP, 17-3 upstream at the ONT, 18-33
pseudo-wire, 26-6
R
Q
Rack, 6-2
QoS, 26-8 Backplane, 6-7
bandwidth profile, 18-23 Raman reduction, 5-7
configuring, 18-28 Redundancy
configuring for end-to-end, 25-17 multi uplink protection, 16-5
configuring VLAN, 18-28 NT and LT, 16-5
congestion management, 18-9 uplink protection, 16-4
DBA, 18-24 relay agent, 10-1, 11-1, 12-1
downstream queueing and scheduling, DHCP, 10-2, 10-6, 12-2
18-29 DHCP configuration, 10-4
downstream rate limiting, 18-13, 18-31 PPPoE, 11-2
DSCP to p-bit mapping, 18-36 PPPoE configuration, 11-2
Ethernet switch, 18-9 remote loopbacks, 13-5
GEM port, 18-18 residential bridge mode, 15-10
GEM traffic descriptor, 18-21 configuration, 15-18
infrastructure, 18-2 residential bridge VLANs, 21-4
marker profile, 18-7 features, 21-4
p-bit to queue mapping, 18-10 RF line rate, 1-2, 8-13
ports, 18-10 RF overlay breakdown, 24-3

Index
RF video — statistics
RF video protocols, 20-12

about, 24-2 reauthentication, 20-14
network example, 24-3 restart scenario, 20-13
RF video service, 1-6 statistics and operating data, 20-13
RMON Ethernet statistics, 19-15 user-session disconnection, 20-13
rolling counters, 19-6 access control lists, 20-3
rooted-multipoint EVC, 28-7 anti-spoofing, 20-19
routing protocols denial of service, 20-23
configuring for end-to-end, 25-23 DHCP Option 90, 22-72
RTCP HTTP digest, 22-73
alarm, 22-77 RADIUS, 20-4
statistics, 22-73 secured MAC learning, 20-3
RTP, 26-8, 26-11 SNMP, 20-6
rules for layer 2 forwarding SSH, 20-7
on NT, 15-6 system log, 20-15
user accounts, 20-17
S service capacity specifications, 8-4
service features, 1-5
S-VLAN, 26-11 service networks
CAC bandwidth check, 21-40 IP multicast, 14-10
p-bit marking compatible configurations, services
21-18 RF video, 24-2
p-bit marking modes, 21-18 SHub VLAN
Safety guidelines CAC bandwidth capacity check, 21-39
safety standard compliance signaling, 26-11
resistibility compliance, xiv SIP
SANC-D, 6-9, 51-1 dual client mode, 22-14
features and application notes, 51-2 softswitch
general description, 51-2 5020, 22-7
identification, 51-2 source address anti-spoofing, 20-20
physical description, 51-2 P-OLT, 20-22
SAToP per-service, 20-22
CES over IP, 26-5 source VLAN, 26-11
DS1/E1 ports, 26-5 SSM multicast, 14-17
overview, 26-5 stacked tagging, 21-16
scalability stacked VLANs
VLAN bridging, 21-42 downstream tagging, 21-25
scalability of subscribers per PON, 15-25 upstream tagging, 21-27
scheduler, 18-10 static multicast stream, 14-19, 14-20
secured MAC learning, 20-3 statistics
security AVGJTRBUFF, 22-73
802.1X authentication, 20-11 CALLEDNO, 22-73
8021.x authentication CALLINGNO, 22-73
assumptions, 20-11 DURATION, 22-73
port-based authentication, 20-12 OVERRUNS, 22-73

Index
statistics (continued) — Technical specifications
performance monitoring counters, 13-3, downstream stacked VLANs, 21-25

19-2 Ethernet frames, 21-15
PKTSDISC, 22-73 options, 21-2
RTCP, 22-73 p-bit marking untagged frames, 21-31
RXPKTS, 22-73 pass-through mode, 21-17
status reports, 13-3, 19-2, 19-6 stacked mode, 21-16
TIME, 22-73 unstacked mode, 21-17
TXPKTS, 22-73 upstream at LT, 21-26
UNDERRUNS, 22-73 upstream at ONT, 21-30
VoIP, 13-3, 22-73, 22-73 upstream for stacked VLANs, 21-27
status reports, 19-6 upstream for unstacked VLANs, 21-28
STP upstream in untrusted mode, 21-31
configuring for end-to-end, 25-15 upstream pass-through VLANs, 21-28
structured TDM, 26-6 VLAN mirror packets, 21-10
subscriber connections tagging mode, 21-22
configuring for end-to-end, 25-28 EtherType classification, 21-22
subscriber scalability tagging modes
bridging table limitations, 15-25 compatible, 21-23
implementation considerations, 15-23 downstream, 21-18
limitations and restrictions, 15-26 Ethernet frames, 21-16
maximum subscribers per PON, 15-25 transmit to port with a tag, 21-18
subscriber services transmit to port without a tag, 21-19
configuring for end-to-end, 25-30, 25-31 upstream, 21-19
superframes, 26-10 upstream EtherType classification, 21-36
syslog, 20-15 upstream flexible mode, 21-37
system constraints upstream flexible tagging, 21-22
Ethernet services, 28-17 upstream in VLAN translation, 21-32
maximum configurable EVC portals, 28-18 upstream pass-through mode, 21-19, 21-32
system log, 20-15 upstream untrusted, 21-19
upstream VLAN translation tagging, 21-19
T upstream VLAN translation with
EtherType classification, 21-21, 21-34
T-CONT, 18-18 TCA, 13-3
per CoS model, 18-18 TDM
per EVC model, 18-18 line length, 26-11
per service model, 18-19 synchronization, 26-8, 26-11
per subscriber/per service model, 18-19 Technical specifications
T1/E1 capacity specifications, 8-4
loopbacks, 13-5 distance and performance, 8-12
tagging environmental conditions, 8-14
downstream at LT, 21-24 ONT connection capacity, 6-12
downstream at ONT, 21-29 optical modules, 8-13, 48-2
downstream for pass-through VLANs, P-OLT, 8-2
21-25 P-OLT connection capacity, 8-13
downstream for unstacked VLANs, 21-25 PON bandwidth, 8-12

Index
Technical specifications (continued) — upstream tagging
power consumption, 8-15 BITS-B, 38-1

service capacity specifications, 8-4 blank LT filter plate, 39-1
video coupler, 8-3 blank NT filler plate, 40-1
video coupler optical budget, 8-14, 57-3 GTRU-B, 37-1
timeslots, 26-6, 26-11 SANC-D, 51-1
timing, 26-8, 26-11 VCW2, 57-1
TISPAN VCW4, 54-1, 55-1
VoIP support, 22-3 connections, 54-4, 55-3
TL1 access protocols, 7-5 environmental requirements, 54-3,
traffic classification, 18-4 55-3
traffic meter, 18-8, 18-8 features and application notes, 54-2,
traffic policing 55-2
egress rate, 18-9 general description, 54-3, 55-2
traffic flow types, 18-8 identification, 54-2, 55-2
traffic policing elements, 18-8 optical safety, 54-3, 55-3
burst size, 18-8 video coupler shelf, 53-1, 56-1
ingress rate, 18-8 unit data sheet
meter, 18-8 EHNT-A, 41-1, 48-1
traffic scheduler, 18-11 EXNT-A, 42-1
downstream rate limiting, 18-15 OLT rack, 49-1
LT, 18-12 overview, 30-2
NT, 18-11 unstacked tagging, 21-17
priority queue profile, 18-17 unstacked VLANs
traffic shaping elements, 18-22 downstream tagging, 21-25
bandwidth profile, 18-23 upstream tagging, 21-28
DBA, 18-24 unstructured TDM, 26-6
reserved bandwidth, 18-24 untagged frames p-bit marking, 21-31
translation profile untrusted tagging, 21-19
C-VLAN p-bit to S-VLAN p-bit, 18-6 untrusted tagging mode, 21-31
UNI-side p-bit to network-side p-bit, 18-6 upstream forwarding
transmit to port with tag, 21-18 VLAN translation with EtherType
transmit to port without a tag, 21-19 classification, 21-21
triple play, 25-1 upstream tagging
troubleshooting at ONT, 21-30
alarms, 9-1 EtherType classification, 21-22, 21-36
flexible mode, 21-22, 21-37
U LT, 21-26
modes, 21-19
UNI options, 21-2
differentiated services, 21-23 pass-through mode, 21-19, 21-32
Unit data sheet pass-through VLANs, 21-28
ALTS-N, 34-1, 50-1 stacked VLANs, 21-27
ATRU-M, 35-1 unstacked VLANs, 21-28
ATRU-N, 36-1 untrusted, 21-19
ATRU-U, 37-1

Index
upstream tagging (continued) — VLANs
VLAN translation mode, 21-19, 21-32 Video coupler shelf, 53-1, 56-1
VLAN translation with EtherType alarms, 56-3
classification, 21-21, 21-34 connections, 56-3
user accounts, 20-17 features and application notes, 53-2, 56-2
user-to-user communication, 21-41 general description, 53-2, 56-2
identification, 53-2, 56-2
V physical description, 56-3
video coupler subrack, 6-10
V-OLT equipment layout, 6-9 video coupler WDM tray, 6-10
V-OLT functional blocks video management, 14-31
RF video service management, 5-10 VLAN
RF video services, 5-9 configuring for end-to-end, 25-20
RF video signal distribution, 5-9 configuring for QoS, 18-28
upstream signal and data channels, 5-10 configuring on the LT, 25-20
v-VPLS configuring on the NT, 25-20
configuring for end-to-end, 25-20 performance monitoring, 19-7
VCSL, 53-1, 56-1 VLAN for service model, 21-12
VCW2, 57-1 VLAN for subscriber model, 21-11
connections, 57-5 VLAN forwarding
environmental requirements, 57-4 C-VLAN learning mode, 15-14
features and application notes, 57-2 cross-connect (transparent) mode, 15-12
general description, 57-2 residential bridge mode, 15-10
identification, 57-2 VLAN translation tagging mode, 21-19
optical safety, 57-4 VLAN translation upstream tagging, 21-32
physical description, 57-5 VLAN translation with EtherType
VCW4, 54-1, 55-1 classification, 21-21, 21-34
connections, 54-2, 54-4, 55-2, 55-3 downstream forwarding, 21-21
environmental requirements, 54-3, 55-3 upstream forwarding, 21-21
features and application notes, 54-2, 55-2 VLANs
general description, 54-3, 55-2 7342 ISAM FTTU usage, 21-3
optical safety, 54-3, 55-3 associating flow mirroring VLANs with
VDSL bridge ports, 21-9
performance monitoring, 13-3 bridging scalability, 21-42
VEIP, 22-14 broadcast domains, 21-3
video C-VLAN differentiated services on a UNI,
Raman reduction, 5-7 21-23
Video coupler C-VLAN learning mode, 21-4, 21-7
optical budget, 8-14, 57-3 CAC check, 21-39
technical specifications, 8-3 CAC S-VLAN bandwidth check, 21-40
video coupler equipment layout, 6-10 compatible tagging modes, 21-23
Video coupler rack, 52-1 configuration method, 21-3
features and application notes, 52-2 cross-connect mode, 21-5
general description, 52-2 definition, 21-3
identification, 52-2 differentiated services, 21-23
physical description, 52-6 downstream tagging at LT, 21-24

Index
VLANs (continued) — VRF
downstream tagging at ONTs, 21-29 upstream tagging in untrusted mode, 21-31

downstream tagging for pass-through upstream tagging in VLAN translation
VLANs, 21-25 mode, 21-32
downstream tagging for unstacked upstream tagging options, 21-2
VLANs, 21-25 upstream tagging pass-through mode,
downstream tagging modes, 21-18 21-32
downstream tagging options, 21-2 upstream tagging pass-through VLANs,
downstream tagging stacked VLANs, 21-28
21-25 upstream untrusted tagging, 21-19
Ethernet frame tagging modes, 21-16 upstream VLAN translation tagging mode,
Ethernet frames processing at the LT, 21-19
21-24 upstream VLAN translation with
Ethernet frames processing at the ONT, EtherType classification, 21-21, 21-34
21-29 user-to-user communication, 21-41
EtherType classification tagging, 21-22 voice gateway
flow mirroring features, 21-10 G6, 22-4
flow mirroring mode, 21-9 voice service, 1-5
frame header manipulation, 21-15 VoIP
frame tagging, 21-15 5020 Softswitch mode, 22-2, 23-2
mirror packet tagging, 21-10 alarms, 22-73, 22-77
models, 21-10 common features, 22-3
modes, 21-4 configuration, 22-18
p-bit overlapping mode, 21-23 dual SIP client mode, 22-14
pass-through tagging mode, 21-17 H.248-based softswitch, 22-7
purpose, 21-3 modes of operation, 22-2, 23-2
residential bridge mode, 21-4, 21-4 service and protocol configuration, 22-20
SHub VLAN CAC bandwidth check, SIP softswitch mode, 22-2, 23-2
21-39 SIP softswitch modes, 22-8
stacked tagging mode, 21-16 statistics, 7-7, 22-73, 22-73
stacking, 21-24 TISPAN support, 22-3
transmit to port without a tag, 21-18, 21-19 voice gateway, 22-4
unstacked tagging mode, 21-17 voice gateway mode, 22-2, 23-2
untagged frames p-bit marking, 21-31 VPNs
upstream EtherType classification, 21-36 Layer 2, 21-42
upstream flexible tagging mode, 21-22, VRF
21-37 configuring for end-to-end, 25-22
upstream pass-through tagging mode,
21-19
upstream tagging, 21-19
upstream tagging at LT, 21-26
upstream tagging at ONTs, 21-30
upstream tagging for stacked VLANs,
21-27
upstream tagging for unstacked VLANs,
21-28

Index

Customer documentation and product support
Customer documentation
http://www.alcatel-lucent.com/myaccess
Product manuals and documentation updates are available at
alcatel-lucent.com. If you are a new user and require access to this
service, please contact your Alcatel-Lucent sales representative.
Technical Support
http://support.alcatel-lucent.com
Documentation feedback
[email protected]
© 2013 Alcatel-Lucent. All rights reserved.

7342 Isam Fttu Olt Etsi r4.9.00 Product Information 3fe 55457 Aaaa Tczza

Uploaded by

Copyright:

Available Formats

7342 Isam Fttu Olt Etsi r4.9.00 Product Information 3fe 55457 Aaaa Tczza

Uploaded by

Document Information

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

7342 Isam Fttu Olt Etsi r4.9.00 Product Information 3fe 55457 Aaaa Tczza

Uploaded by

Copyright:

Available Formats

ETSI PRODUCT INFORMATION MANUAL

3FE 55457 AAAA TCZZA Edition 01

Copyright 2013 Alcatel-Lucent.

When printed by Alcatel-Lucent, this document is printed on recycled paper.

Assistance and ordering phone numbers

Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 iii

Alcatel-Lucent quality processes

Procedure 1 To download an CD-ROM ISO image or ZIP file package

3 Click on Downloads: Electronic Delivery.

4 Choose Documentation from the drop-down menu and click Next.

6 Follow the onscreen directions to download the file.

iv October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Procedure 2 To access individual documents

1 Navigate to http://www.alcatel-lucent.com/myaccess and enter your user name

4 Click on the PDF to open or save the file.

Warning — Warning indicates that the described activity or situation

Caution — Caution indicates that the described activity or situation

Note — A note provides information that is, or may be, of special

Procedures with options or substeps

Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 v

Procedure 3 Example of options in a procedure

a This is one option.

b This is another option.

2 You must perform this step.

Procedure 4 Example of required substeps in a procedure

i This is the first substep.

ii This is the second substep.

iii This is the third substep.

2 You must perform this step.

Multiple PDF document search

Procedure 5 To search multiple PDF files for a common term

3 Enter the search criteria.

vi October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

4 Click on the All PDF Documents In radio button.

5 Select the folder in which to search using the drop-down menu.

6 Click on the Search button.

Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 vii

viii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Safety instruction boxes

Danger — Possibility of personal injury.

Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 ix

The following is an example of the Warning box.

Warning 2 — Possibility of data loss.

Caution 2 — Service interruption.

Safety related labels

ESD warning label

x October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Figure 1 ESD warning label

Hazardous voltage warning label

Figure 2 Hazardous voltage warning label

Laser warning labels

Figure 3 Laser product label

Figure 4 shows a laser classification label. Laser classification labels may be

Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00 October 2013 xi

Figure 4 Laser classification label

CLASS 1 LASER PRODUCT '

xii October 2013 Alcatel-Lucent 7342 ISAM FTTU P-OLT R4.9.00

Figure 5 Laser warning labels

INVISIBLE LASER RADIATION

Laser Warning Label Laser Warning Label