Nga Appendix02 Final - BT

IN CONFIDENCE
FTTP Technical Requirements Reference:GPON/0005/JB
Openreach Invitation To Tender

FTTP Solution
Schedule of Technical
Requirements
Reference: FTTP/GPON/0002/2007/JB
Authorised by:
Simon Fisher, Openreach
Date
Openreach Strategic FTTP ITT: Technical Requirements
Copyright
British Telecommunications plc, 2008. All rights reserved.
BT maintains that all reasonable care and skill has been used in the compilation of this
publication. However, BT shall not be under any liability for loss or damage (including
consequential loss) whatsoever or howsoever arising as a result of the use of this publication by
the reader, his servants, agents or any third party.
All third-party trademarks are hereby acknowledged.
Document History
Revision Author Date Notes
Issue 1 Joe Brannan 15/01/08 Formal issue following review.
Page 5 of 87
IN CONFIDENCE
Distribution
Distribution will be controlled by:
BT Design
Name: Joe Brannan

Role: Author
Address: pp HWP303
PO Box 234
Edinburgh
Midlothian
EH12 9UR
E-mail: joseph.brannan@bt.com
Telephone: 07795980748
Enquires about the technical content should be directed to Joe Brannan.

Master document will be held with the author at the above address.
Page 6 of 87
IN CONFIDENCE
Contents
1 Introduction.......................................................................................................................... 7
1.1 Scope.......................................................................................................................... 8
1.2 Standards Compliance................................................................................................ 9
1.3 Alignment with UK Telecommunications Strategic Review (TSR)...............................9
2 Initial FTTP System Requirements....................................................................................10
2.1 FTTP Architecture using standard GPON.................................................................10
2.2 GPON Bit Rates & Optical Budgets...........................................................................12
2.3 Generic Ethernet Access Products............................................................................15
2.3.1 GEA Voice Enablement Product (GEA-VEP).....................................................16
2.3.2 GEA Data Product (GEA-DP)............................................................................17
2.3.3 TDM Products................................................................................................... 17
2.4 Ethernet and VLAN Architecture...............................................................................18
2.4.1 VLAN architecture............................................................................................. 18
2.4.2 Traffic Management........................................................................................... 19
2.5 Generic Ethernet Requirements................................................................................20
2.5.1 Frame Sizes...................................................................................................... 20
2.5.2 Transparency..................................................................................................... 20
2.5.3 Ethernet OAM.................................................................................................... 21
2.5.4 QoS................................................................................................................... 21
2.6 FTTP System Scalability........................................................................................... 23
2.7 GPON QoS Requirements........................................................................................ 23
2.8 CP Handover Points and Interfaces..........................................................................26
2.9 CP Service Level Agreement.....................................................................................26
2.10 Future GPON Equipment Upgrades..........................................................................26
2.10.1 Software Upgrades............................................................................................ 26
2.10.2 Hardware Upgrades.......................................................................................... 26
2.11 Resilience and Reliability.......................................................................................... 27
2.12 GPON OLT Requirements......................................................................................... 27
2.12.1 General Requirements......................................................................................27
2.12.2 TDM Interfaces.................................................................................................. 27
2.12.3 Ethernet Interfaces............................................................................................ 28
2.12.4 Card and Port Resilience...................................................................................28
2.12.5 VLAN Manipulation............................................................................................ 29
2.12.6 QoS................................................................................................................... 30
2.12.7 Synchronisation................................................................................................. 30
2.12.8 Transfer/forwarding........................................................................................... 31
2.13 GPON ONT Requirements........................................................................................ 31
2.13.1 VLAN Manipulation............................................................................................ 31
2.13.2 QoS and CoS.................................................................................................... 32
2.13.3 ONT Types........................................................................................................ 32
2.13.4 Indoor ONT Requirements................................................................................33
2.13.5 Network Interfaces............................................................................................ 33
2.13.6 ONT Physical Design Considerations................................................................34
2.13.7 Power Supply.................................................................................................... 34
2.13.8 Power Saving & Shedding Modes.....................................................................35
2.13.9 Reset Button...................................................................................................... 35
2.13.10 Battery............................................................................................................... 35
2.13.11 Cooling.............................................................................................................. 36
2.13.12 Materials............................................................................................................ 36
2.13.13 Electrical Connector Location............................................................................36
2.13.14 Physical Requirements......................................................................................37
2.13.15 Mounting............................................................................................................ 37
2.13.16 Status Indicators................................................................................................ 37
2.13.17 Environmental Requirements............................................................................37
2.13.18 Enclosure & Aesthetics......................................................................................37
Page 7 of 87
IN CONFIDENCE
2.13.19 System Requirements.......................................................................................38

2.13.20 Test and Diagnostic Requirements....................................................................38
2.13.21 CPE Port Test Requirements.............................................................................39
2.13.22 Security Requirements......................................................................................39
2.13.23 Reliability........................................................................................................... 40
2.13.24 Laser safety....................................................................................................... 40
2.13.25 Electrical Safety................................................................................................. 40
2.14 Indoor Business ONT................................................................................................ 40
2.15 Outdoor/Semi-Ruggedised ONT Requirements Specification...................................40
2.16 GPON Management.................................................................................................. 41
2.16.1 General EMS & OSS requirements...................................................................41
2.16.2 PLOAM Channel............................................................................................... 42
2.16.3 GPON OMCI..................................................................................................... 42
2.17 Test & Diagnostic Requirements...............................................................................42
2.17.1 Element Manager.............................................................................................. 42
2.17.2 Events and Errors.............................................................................................. 43
2.17.3 Optical Supervisory facilities..............................................................................48
2.17.4 ONT Commissioning......................................................................................... 49
2.17.5 OLT Commissioning.......................................................................................... 49
2.17.6 Network Demarcation........................................................................................ 50
2.17.7 END to END Performance Monitoring...............................................................50
2.17.8 Loopback facilities............................................................................................. 50
2.17.9 Bandwidth Provisioning and Monitoring.............................................................50
2.17.10 Ethernet Statistics............................................................................................. 50
2.18 GPON Security.......................................................................................................... 50
2.18.1 BTSECS............................................................................................................ 51
2.18.2 GPON Physical Network Security.....................................................................51
2.18.3 GPON Advanced Encryption Standard..............................................................52
2.18.4 Customer and ONT Identification/Authentication...............................................52
2.18.5 Separation of Signalling, Management and Media Traffic.................................52
2.18.6 Management Security........................................................................................ 53
2.18.7 Layer 2 Security................................................................................................ 54
2.19 Health & Safety......................................................................................................... 55
2.19.1 RoHS (Restriction of Hazardous Substances)...................................................55
2.19.2 WEEE (Waste from Electrical and Electronic Equipment).................................55
2.19.3 Laser Safety...................................................................................................... 56
2.19.4 Electrical Safety................................................................................................. 56
3 FTTP Strategic Target Physical layer Architecture.............................................................57
3.1.1 GPON Optical Reach Extension........................................................................57
3.1.2 GPON Dual Parenting Requirements................................................................60
3.1.3 Next Generation PON (NGPON) Systems........................................................64
3.1.4 Future Products................................................................................................. 65
4 FTTC High Level Requirements........................................................................................ 71
5 Appendices........................................................................................................................ 73
5.1 Appendix 1 - Standards Documents..........................................................................73
5.1.1 BT GS (Generic Standards)..............................................................................73
5.1.2 Ethernet Specifications......................................................................................73
5.1.3 Environmental Specifications............................................................................73
5.1.4 ITU-T BPON Specifications...............................................................................74
5.1.5 ITU-T GPON Specifications...............................................................................74
5.1.6 Electrical Specifications.....................................................................................74
5.1.7 Fire Protection Specification..............................................................................74
5.1.8 Optical Connectors, Lasers & Fibre Specifications............................................75
5.1.9 Additional Reference Documents......................................................................75
5.2 Appendix 2 Definitions............................................................................................ 75
5.3 Appendix 3 Abbreviations.......................................................................................76
5.4 Appendix 4 FTTC Requirements............................................................................77
6 Acknowledgements............................................................................................................ 84
Page 8 of 87
IN CONFIDENCE
List of Figures
Figure 1: Upstream and Downstream definition......................................................................10
Figure 2 - FTTP Standard GPON Architecture.......................................................................11
Figure 3 - GPON future proofing for migration to NGPON......................................................12
Figure 4 Generic Ethernet Access Products........................................................................15
Figure 5: Definition of OLT domains........................................................................................ 18
Figure 6: VLAN architecture.................................................................................................... 19
Figure 7: Traffic management points using integrated Ethernet switch...................................19
Figure 8: Traffic management points using an external Ethernet switch (ES).........................20
Figure 9: Proposed block diagram of ONT input/outputs (for illustrative purposes only).........33
Figure 10: EU port numbering on ONT...................................................................................34
Figure 11: Extended Reach GPON 60km, 128 way split, dual parented..............................57
Figure 12: Reference configuration of mid-span GPON extender...........................................58
Figure 13: Illustration of Dual-Parenting restoration implemented via EMS system................60
Figure 14: Illustration of fast, automatic Dual-Parented GPON protection implemented through
OLT-OLT communications channel.................................................................................63
Figure 15 - Multicast in GPON................................................................................................ 66
Figure 16: FTTC Cut-over scenario........................................................................................71
Figure 17: FTTC Overlay scenario.......................................................................................... 71
Figure 18: FTTC Overlay low take up (<10%).........................................................................72
List of Tables
Table 1 G.984.2 Optical power levels for 2.5 Gbit/s D/S and 1.24 Gbit/s U/S.........................14
Table 2 G.984.2 Loss budgets for the GPON system.............................................................14
Table 3: Transparency exceptions........................................................................................... 20
Table 4: G984.3 Section 11.1.1 - Events Detected at the OLT...............................................43
Table 5: G984.3 Section 11.1.2 - Events Detected at the ONU/ONT.....................................46
Table 6: G.984.3 Section 11.2.1 - Errors Detected at the OLT..............................................48
Table 7: BTs required parameters identified by the FSAN Optical Supervisory Task Group. 49
Page 9 of 87
IN CONFIDENCE
1 Introduction
Openreach intends to pilot Generic Ethernet Access (GEA) products delivered over a Fibre to
the Premises (FTTP) infrastructure starting June 2008. Following successful completion of this
pilot, Openreach intends to strategically launch these GEA products in June 2009 to be
available across the UK for New Site developments of sufficient viability, and other sites where
FTTP proves economical compared to traditional copper based solutions. The GEA products will
enable Communication Providers (CPs) to provide voice, video and data services to residential
and small to medium business customers. Openreach is also considering Fibre to the Cabinet
solutions (FTTC) to deliver a similar set of products.
The FTTP technical requirements are based on Openreach FTTP Product Requirements and
feedback Openreachs Industry Consultation process. It should be noted that these
requirements are subject to change, dependent upon the outcome of ongoing discussions
between Openreach and OFCOM.
The Openreach strategic target FTTP architecture is based on a 60km reach and 128-way split
GPON, dual-parented to two geographically separated OLTs. Since these capabilities are
dependent on developing and future standards, Openreach is currently assuming that initial
deployments for the strategic launch in June 2009 will be based on standard GPON products.
However, Openreach wishes to deploy these enhanced capabilities at the earliest opportunity
and views their technical and commercial viability as a key requirement.
Vendors are invited to propose a solution that satisfies all requirements specified in this
document. Three key aspects are addressed:
1. Detailed technical requirements for vendor products based on current GPON standards.
Openreach has a strong preference for a solution requiring only an OLT at the head-end and not
an additional Ethernet switch. However it is recognised that a significant number of both
1GE and 10GE interfaces are required for CP handoff. If these interfaces and the associated
switching requirements cannot be provided by the OLT itself, then a solution containing an
external switch may be considered. This could be done in two ways.
The GPON vendor could supply the OLT only, which will be interfaced to a L2 switch from one of
BTs strategic 21C L2 switch vendors. Such a solution would ultimately be expected to have an
integrated management system so that the OLT and switch appeared as a single managed
entity. In this case Openreach would procure the L2 switch but would expect, as a minimum, full
co-operation from the GPON vendor on full integration. The GPON vendor may also wish to
consider complete ownership of this integration, including the associated costs. Hence, for a
proposal of this type, vendors must provide costs for the OLT and the level of integration
support offered.
The final and least preferred option, would be for the GPON vendor to provide an external L2
switch of their own choosing which is NOT from one of BTs strategic L2 switch vendors. Such a
solution would be expected to have an integrated management system so that the OLT and
switch appeared as a single managed entity. In this case vendors must provide the cost of both
the OLT and external L2 switch. All integration costs must be included.
Vendors must clearly indicate in their response to Section 2 FTTP System Requirements, which
of the above options is being proposed.
2. Technical requirements based on developing and future standards with particular regard to
extended reach, increased split and dual parenting.
Page 10 of 87
IN CONFIDENCE
3. High level requirements for a FTTC solution, which must be supported by the same element
management platform as the FTTP product. In addition to the formal requirements specified
in section 4, further requirements are specified in Appendix 4. These are provided to set the
context of Openreachs investigations into FTTC and responses are requested to aid
Openreachs evaluation of the capabilities and opportunities for FTTC deployment.
The proposal must include a statement of compliance for each requirement on the following
basis:
Full Compliance (FC) fully supported by the product and its management platform as
of 18th January 2008.
Partial Compliance (PC) supported by a committed roadmap. Date of (commercial)
availability must be given, otherwise the response will be judged as non-compliant.
Non Compliance (NC) not part of committed roadmap
Information Only (IO) future feature under consideration.
For responses that fall under the IO category, vendors must provide the requested information
for those requirements, otherwise the response will be judged as invalid. IO should not be given
as a response for requirements specified under section 1 above.
Requirements are denoted by the form: (Rx).
Vendors must also provide a compliance summary table that lists each [Rx] response under the
classification FC, PC, NC or IO as illustrated in the table below. However, responses to the
separate EMS requirements specification included within section 2.16 must NOT be included in
this summary table.
Full Compliance Partial Compliance Non Compliance Information Only
Ra, Rb, Rc, Rd Re, Rf, Rg Rh, Ri Rj
Total FC=4 Total PC=3 Total NC=2 Total IO=1
A separate compliance summary table must be provided for responses to the additional FTTC
requirements specified in appendix 4. Requirements in this appendix are designated by the
form [AR1], [AR2] etc, to distinguish them from the requirements in the main part of the
document. Responses for appendix 4 requirements must NOT be included in the summary
compliance table for the requirements specified in the main part of the document.
Subject to satisfactory responses, Openreach may choose to invite a vendor or vendor(s) to

conduct a lab-based trial to verify the proposed solution.
1.1 Scope
This specification describes the main technical requirements for an FTTP solution as well as the
high level requirements for an FTTC solution. It includes:
FTTP Architecture
Standard GPON system requirements
Ethernet and VLAN requirements
Extended reach, dual parenting, 128 way split and 10 Gbit/s
OLT requirements
ONT requirements
GPON Test & diagnostics
Page 11 of 87
IN CONFIDENCE
Management and OSS

Security
FTTC requirements
Unless otherwise stated, all functionality and features described in this document are
mandatory.
1.2 Standards Compliance
[R1] Compliance with all standards listed in Appendix 1 Standards Documents, is

mandatory. All components that constitute the GPON system must comply with the
G.984.x series, including all amendments and the recently approved G.984.5
Enhancement band for GPON
1.3 Alignment with UK Telecommunications Strategic Review (TSR)
The solution must be compliant with UK regulator Ofcom's "Final Statements on the Strategic
Review of Telecommunications, and Undertakings... published 22nd September 2005 which is
available from the following link: http://www.ofcom.org.uk/consult/condocs/statement_tsr/
In practical terms this means that Openreach will develop and offer FTTP connectivity products
to Communication Providers and other BT operating units on an "Equivalence of Inputs"
basis, defined in the statements as:
"Equivalence of Inputs" or "EOI" means that BT provides, in respect of a particular product or

service, the same product or service to all Communications Providers (including BT) on the
same timescales, terms and conditions (including price and service levels) by means of the
same systems and processes, and includes the provision to all Communications Providers
(including BT) of the same Commercial Information about such products, services, systems and
processes. In particular, it includes the use by BT of such systems and processes in the same
way as other Communications Providers and with the same degree of reliability and
performance as experienced by other Communications Providers.
Page 12 of 87
IN CONFIDENCE
2 Initial FTTP System Requirements

The Openreach strategic target FTTP architecture is based on a 60km reach and a 128-way
split GPON, dual-parented to two geographically separated OLTs. Since these capabilities are
dependent on developing and future standards, Openreach is currently assuming that initial
deployments for the strategic launch in June 2009 will be based on standard GPON products.
Similarly, the Ethernet and VLAN architecture used to deliver the GEA product set is assumed to
use the capabilities provided by standard GPON products.
As stated in the Introduction, Openreach has a strong preference for a solution requiring only an
OLT at the head-end and not an additional Ethernet switch. However, vendors have the option
to propose a solution requiring integration with a BT 21CN L2 switch or non BT 21CN L2 switch.
Where an external switch is proposed as part of the solution, vendors must clearly state for all
requirements, what functionality is assumed to be provided by a BT 21CN switch or will be
provided by a non BT 21CN switch. This is particularly important to meet the scalability
requirements where it is possible that each OLT-switch link would need to transport more than
4k VLANs. Full details of any proposed solution must be provided.
For the purposes of this document, Figure 1 clarifies what is meant by upstream and
downstream directions on the GPON system.
Figure 1: Upstream and Downstream definition
2.1 FTTP Architecture using the current standard GPON
The initial FTTP architecture based on a standard GPON system operating with a single 1:32
splitter is shown in Figure 2.
Page 13 of 87
IN CONFIDENCE
CP 1 In Span
Hand-Over
CP Hand-Over External Network End User
Outside Node
BT building ONT 1
- Port 1
C Optical interfaces
P In Building
CP 2 H Hand-Over
In same O Port 4
-
BT building Fr
Cable Link
a GPON
m OLT
Line 32 way split
Ce Cable Link
CP 3 P Card ONT 32
Remote H ONBS Cable Link Port 1
O
different Fr GPON
BT building a OLT
Line 32 way split
Out of Building Port 4
m Hand-Over
Card
eC
CP 4 P 28dB
Remote H ONBS Cable Link
O
non Fr
BT building a T R S
m
e
Existing Openreach GEA Products
Products GEA Data Product
GEA Voice Enablement Product
Hand-Over Point GEA CP GigE Port Product
Figure 2 - FTTP Standard GPON Architecture
Each end user will be provided with an ONT containing 4 Ethernet ports and have the ability to
select up to 2 Communications Providers (CPs) for their voice and data services.
End user traffic will be aggregated at the OLT and handed off to CPs via 1 GE or 10 GE optical
interfaces. However, TDM interfaces may also be required for particular CP applications.
Existing backhaul products will be used to provide links to the CP hand-over point.
[R2] The GPON ONT must support 4 Ethernet ports each capable of operating at 10 Mbit/s,
100 Mbit/s and 1 G Bit/s
[R3] A Business ONT with 4 Ethernet ports as described in R2 plus 4 E1 ports is required.
[R4] The GPON OLT must support STM-1 and STM-4 TDM interfaces for hand-over to CPs
(point R).
[R5] The proposed solution must support a minimum of 50 optical interfaces for hand-off to
CPs (point R). Both 1GE and 10 GE interfaces are required with an indicative ratio of
5x1GE to 1x10GE.
[R6] Vendors to state whether the proposed solution is based on an OLT only, OLT and BT
21CN L2 switch or OLT and non BT 21CN L2 switch.
[R7] Where vendors propose an OLT only solution the maximum number of ports available
for CP hand-over must be stated. The possible numerical combinations of these
interface types must also be stated.
[R8] Where vendors propose a solution based on OLT and BT 21CN L2 switch, the
maximum number of OLT ports available for connection to the L2 switch must be stated.
The possible numerical combinations of the OLT interface types must also be stated.
Page 14 of 87
IN CONFIDENCE
[R9] Where vendors propose a solution based on OLT and BT 21CN L2 switch, the level of
support offered to achieve a fully integrated management solution so that the OLT and
switch appeared as a single managed entity, must be stated.
[R10] Where vendors propose a solution based on OLT and non BT 21CN L2 switch, an
overview of the proposed solution must be given including details of the external L2
switch. The maximum number of ports available for CP hand-over must be stated as
well as the maximum number of OLT ports. The possible numerical combinations of
interface types for both OLT and L2 switch must also be stated.
[R11] Where vendors propose a solution based on OLT and non BT 21CN L2 switch,
confirmation that a fully integrated management is provided so that the OLT and switch
appeared as a single managed entity, must be stated.
[R12] Vendors to state the maximum number of GPON cards per OLT unit and how this
affects the number of backhaul ports available.
[R13] Vendors to state the maximum number of GPON per card.
[R14] Vendors to state the size and non-blocking switch capabilities of the internal OLT
Ethernet switch. If an additional Ethernet switch is proposed then vendors must also
state figures for this.
2.2 GPON Bit Rates & Optical Budgets
[R15] The GPON system must operate at 2.488 Gbit/s downstream and 1.244 Gbit/s
upstream as defined in G.984.2.
There must be no changes to the optical infrastructure once deployed. Hence, it is mandatory
that GPON deployments are future proofed from day one. This will be achieved by installing a
wavelength blocking filter (WBF) integrated into the ONT and a discrete WDM coupler (WDM1)
at the OLT as described on G.984.5. As shown in Figure 3, this will enable the upgrade and co-
existence of GPON and Next Generation PON (NGPON) on the same optical distribution
network (ODN).
Hand-Over Node End User

32 way split
Premises
WDM
OLT ONT
CP1
HO
CPn
OLT
End User
Premises
ONT
Standard GPON
Next generation PON Wavelength Blocking Filters
Figure 3 - GPON future proofing for migration to NGPON
Page 15 of 87
IN CONFIDENCE
[R16] All ONTs must contain a wavelength blocking filter such that the ONT has an S/X
tolerance mask as defined in G.984.5.
To assist in specification of WDM1 and future NG-PON upstream, vendors shall specify S/X
tolerance mask for their GPON OLT (in similar form as defined for ONT in G.984.5)
[R17] ITU-T G.984.2 and G.984.5 specify a number of variants for ONU 1.244 Gbit/s
transmitter. The Vendor must fill in the table below to indicate which options are offered
and the relative ONU price of each option. Note that in the pricing sections of the ITT,
vendors must give prices for all ONT options offered.
ONU laser type ONU transmitter wavelength Relative ONU price

range
MLM (distances <10 km) 1260-1360 nm
SLM 1290-1330 nm 1.0
SLM 1300-1320 nm
Vendor to indicate any other
options consistent with
standard offered as an extra
row in table
SLM single longitudinal mode laser

MLM -multi longitudinal mode laser
[R18] With the ONT wavelength blocking filter included, the OLT and ONT must still comply
with the 28 dB (class B+) optical performance specified in G.984.2 Amendment 1, Table
III.1/G984.2 and Table III.2/G.984.2. Vendors to confirm that the performance is
guaranteed over the operating life of the system (20 years).
Referring to Figure 2/G.984.1, BT will connect OLT/ONT to the ODN via an optical connector.
Figure 2/G.984.1 shows that the optical power levels at the OLT/ONU can be measured
- either at point S just after the optical connector
- or at point R just before the optical connector
G.984.2 Amendment 1 gives the optical power levels for OLT and ONT and resulting (28 dB)
loss budget. Openreach needs to understand whether or not the loss of optical connectors
needs to be included in specified (28 dB) loss budget.
[R19] Vendors must state for their system at which of the below points the optical power levels
given in Table III/1/G.984.2 are measured:
(a) at the point S just after the optical connector (in which case BT do not need to allow for
connector losses within specified (28 dB) loss budget).
(b) at the point R just before the optical connector (in which case BT do need to allow for
connector losses within specified (28 dB) loss budget).
The optical power and loss budgets specified in G.984.2 Amendment 1 are given below in
Tables 1 and 2. As shown in Table 1, there is a 3.5 dB range in the OLT mean launch power.
Openreach wishes to maximise the reach available from standard GPON products and would
like to understand if a vendor can provide increased transmitter launch powers and/or improved
receiver sensitivities (within GPON standard limits) to increase the GPON loss budget beyond
28 dB.
Page 16 of 87
IN CONFIDENCE
Items Unit Single fibre

OLT: OLT
Mean launched power MIN dBm +1.5
Mean launched power MAX dBm 5
Minimum sensitivity dBm 28
Minimum overload dBm 8
Downstream optical penalty dB 0.5
ONU: ONU
Mean launched power MIN dBm +0.5
Mean launched power MAX dBm 5
Minimum sensitivity dBm 27
Minimum overload dBm 8
Upstream optical penalty dB 0.5
Table 1 G.984.2 Optical power levels for 2.5 Gbit/s D/S and 1.24 Gbit/s U/S
Items Unit Single fibre

Minimum optical loss at 1490 nm dB 13
Minimum optical loss at 1310 nm dB 13
Maximum optical loss at 1490 nm dB 28
Maximum optical loss at 1310 nm dB 28
Table 2 G.984.2 Loss budgets for the GPON system
[R20] Vendors to state details of improved transmitter launch powers and/or receiver
sensitivities to increase the GPON loss budget beyond 28 dB (class B+). Vendors to
confirm that the improved performance is guaranteed over the operating life of the
system (20 years).
Furthermore, ITU-T SG15 Q2 are currently studying Class C+ GPON systems in which the
OLT is given enhanced optical capability. When used in combination with a standard (G984.2
Am 1) ONT an optical loss budget > 30 dB can be achieved while retaining purely passive fibre
ODN (G.984.2/Figure 2).
[R21] Vendors must provide details of their roadmap (with release timescales and
development challenges) for support of a Class C+ OLT, including:
- supported loss budget range
- any reach limitations other than loss (e.g. dispersion)
- specification of the class C+ OLT
- mean transmitter launch power range (min and max)
- minimum receiver sensitivity and how it is achieved
- minimum receiver overload power
- upstream operating wavelength range
Page 17 of 87
IN CONFIDENCE
[R22] Support for 60 km logical reach as specified in G.984.1 is required. Vendors to describe
the reach capabilities of their current system in terms of fibre distance supported. This is
not the power budget limit, but the limit of the ranging process and any dispersion limits
of your transmitters on G.652 fibre. Include release plans and details on what
technological developments are necessary to achieve each new capability.
[R23] Support for 128 addressable ONTs as specified in G.984.1 is required. Vendors are to
state the limit on the number of addressable ONTs per PON in their current system.
Outline release plans and details on what developments are necessary to reach 128
ONTs.
[R24] Support for 20 km differential reach is required over all maximum ONU length ranges up
to 60 km.
2.3 Generic Ethernet Access Products
Openreach intends to launch a range of GEA products:
GEA - DP : Generic Ethernet Access Data Product. This product has a number of
variants
GEA - VEP : Generic Ethernet Access Voice Enablement Product
End User
Openreach External Network
Handover
Point
CP1 GEA ATA

ONT 1
ATA
Shared Bandwidth
PON Termination Router
CP1 Router
GPON
CP2 Line CP2 GEA
Card 4 Ethernet Ports
ONT 32
32 way split
CPN GEA-VEP

GEA-DP
28dB
R S
Openreach product from R to S
Figure 4 Generic Ethernet Access Products
Each product provides an uncontended channel between the CP interface and the End User.
As illustrated in Figure 4, CPs can provide voice and data services to end users via the 4
Ethernet ports on the ONT. End user traffic for each CP is aggregated at the OLT and passed to
the CP via the 1 GE or 10 GE hand-over port(s) in conjunction with existing hand-over products.
Page 18 of 87
IN CONFIDENCE
Each End User will be able to take up to 2 voice services, both from same CP or one from each
CP.
Each End User will be able to take up to 2 data services, both from same CP or one from each
CP.
The GEA Data and GEA Voice Enablement Products will be realised by a number of managed
Virtual LANs (VLANs) from a CP to an End User. The VLANs provide uncontended bandwidth
channels between the end user and the CP handover point.
2.3.1 GEA Voice Enablement Product (GEA-VEP)
The GEA-VEP will provide a single bi-directional data channel from the CP interface to an End
User by means of a VLAN.
The GEA-VEP product provides appropriate QoS for real-time voice services to enable a CP to
construct a voice service. The GEA-VEP itself does not include any voice functionality. This is
the responsibility of the CP who will provide functionality suited to the CPs own Call Server.
Where connectivity to an analogue phone is required, the CPs Analogue Telephone Adapter
(ATA) will provide this.
[R25] The GEA-VEP provides a bi-directional symmetrical assured bandwidth channel of 135
kbit/s with a 7k byte burst capability for voice signalling purposes. The 7k byte
signalling burst must be provided with sufficient bandwidth to ensure the delay and jitter
requirements of the UK VoIP Interconnect Specification can be met. It has been
assumed that a 2 msec packet delay variation is available to the GPON from a total
allocation of 7 msec. Openreach is continuing to develop the voice solution but at
present is assuming a 20Mbit/s burst capability is required. Vendors are requested to
confirm their products can achieve the 2 msec packet delay variation across the PON
and state the burst bandwidth required to achieve this.
[R26] The GPON system must be able to police and shape the 7kbyte burst to prevent CPs
attempting to use the 20 Mbit/s burst capability on a more sustained basis. Vendors
must state how this is achieved for both upstream and downstream traffic.
[R27] Upstream assured and burst bandwidth for GEA-VEP to be implemented using T-Cont
type 3 or type 5.
[R28] Vendors to recommend whether type 3 or type 5 should be used and state their
reasons.
[R29] Downstream assured bandwidth for GEA-VEP to be identified using IEEE 802.1p
priority bits and/or VLAN ID.
[R30] Vendors to state how downstream GEA-VEP bandwidth is configured.
[R31] The GEA-VEP must be capable of supporting Voice band data services such as
modems and fax machines.
[R32] Vendors to suggest other voice design options e.g. separation of signalling and media
streams into different VLANs and to propose an alternative GPON voice solution that
meets the above (bandwidth and jitter) requirements.
2.3.2 GEA Data Product (GEA-DP)
Page 19 of 87
IN CONFIDENCE
The GEA-DP will provide a single bi-directional asymmetric data channel from the CP interface
to an End User by means of a VLAN.
A number of product variants will be offered to CPs:
GEA-DP Option 1: Assured bandwidth 0.5Mbit/s downstream, 0.5Mbit/s upstream bandwidth

over a single VLAN, with the ability to support a 2.5Mbit/s downstream burst.
GEA-DP Option 2: Assured bandwidth 10Mbit/s downstream, 2 Mbit/s upstream bandwidth over
a single VLAN, with no burst.
GEA-DP Option 3: Assured bandwidth 10Mbit/s downstream, 2Mbit/s upstream bandwidth over
a single VLAN, with the ability to support 30 Mbit/s downstream burst.
GEA-DP Option 4: Assured bandwidth 10Mbit/s downstream, 2Mbit/s upstream bandwidth over
a single VLAN, with the ability to support 100Mbit/s downstream burst.
[R33] Vendors to state that their system can be configured to support arbitrary combinations
of the above data products per ONT and per GPON.
[R34] Assured bandwidth must be implemented for GEA-DP using T-Cont type 2.
[R35] Downstream assured bandwidth for GEA-DP to be identified using IEEE 802.1p priority
bits and/or VLAN ID .
[R36] Vendors to state how downstream GEA-DP bandwidth can be configured at the OLT.
Openreach are currently assuming that initial GPON deployments commencing June 2009 will
use standard GPON with 32 customers sharing the available bandwidth. At the earliest
opportunity Openreach will move to a 128 way split PON. Openreach is therefore considering
how the customer experience can be managed by controlling bandwidth allocation on 32 way
PONs to ensure a consistent level of performance is provided to all customers, irrespective of
the split.
[R37] Vendors are requested to propose solutions to enable a consistent customer experience
to be provided for all products.
[R38] Vendors must be able to provide per VLAN statistics on the bandwidth provided to end
users for all products.
2.3.3 TDM Products
Openreach may require TDM capabilities for particular CP applications. These products may be
based on a native or emulated TDM solution.
[R39] The GPON solution must support a native TDM service providing an unstructured 2
Mbit/s service delivered via four E1 ports on an ONT and an STM1 or STM-4 interface
on the OLT. A full description of this capability must be given.
[R40] Depending on technical performance and cost benefit, Openreach may deploy an
emulated TDM service. Vendors to indicate cost benefit and state that an emulated
TDM service providing an unstructured 2 Mbit/s service delivered via four E1 ports on
and ONT and a 1 GE or 10 GE interface on the OLT is supported. A full description of
the solution and its technical performance must be given, including the type of
emulation used.
Page 20 of 87
IN CONFIDENCE
2.4 Ethernet and VLAN Architecture
The OLT is for the purpose of this ITT considered to consist of two separate domains; the
GPON domain and the Ethernet switching domain. This is illustrated in Figure 5:
Figure 5: Definition of OLT domains
The preferred solution sees the two domains embedded in a single OLT network element,
although solutions employing a separate Ethernet switch will also be considered, as explained
in Section 1. The response must clearly state whether a separate Ethernet switch is required in
order to satisfy any of the requirements in this ITT. Additionally, the response to each individual
requirement in the following sub-sections must state whether it is based on the OLT or an
external Ethernet switch.
2.4.1 VLAN architecture
BT has identified the architecture shown in Figure 6 as potentially providing a suitable solution.
The same architecture may be implemented with or without an external Ethernet switch.
In order to allow BT to finalise its architecture, vendors must answer the specific questions in
the following sections. However, vendors are also invited to propose an alternative solution
which provides at least equivalent functionality and scalability; in particular the switch function
must scale to support at least 4k VLANs per external physical interface.
Page 21 of 87
IN CONFIDENCE
Figure 6: VLAN architecture

In the architecture shown in Figure 6, two BT specified VLAN headers are added to the traffic;
one by the ONT and one by the OLT. This is in addition to any VLAN headers being transmitted
end-to-end across the GPON system by the EU/CP. On the handover to the CP at the OLT a
single BT VLAN header (per product instance) will be used (with the potential to expand to
double tags if required for scalability in future). No BT VLAN headers will be handed over to the
EU by the ONT.
In the following sub-sections the terms ONT VLAN tag and OLT VLAN tag are used for the
VLAN tags added at the ONT and the OLT respectively.
2.4.2 Traffic Management
The following figures illustrate possible traffic management points. Figure 7 shows
traffic management with the preferred solution using an integrated Ethernet switch:
Figure 7: Traffic management points using integrated Ethernet switch
Page 22 of 87
IN CONFIDENCE
Figure 8 shows traffic management in the non-preferred solution with an external Ethernet
switch (ES):
Figure 8: Traffic management points using an external Ethernet switch (ES)
2.5 Generic Ethernet Requirements
The following sub-sections detail the generic Ethernet requirements which are applicable to the
GPON system as a whole, including both ONT and OLT.
2.5.1 Frame Sizes
[R41] The minimum permissible Ethernet frame size must be 64 bytes as specified in IEEE
802.3
[R42] The maximum frame size on all FE interfaces must be 2,000 bytes as specified in IEEE
802.3as.
[R43] The maximum frame size on all GE and 10GE interfaces must be at least 9,000 bytes.
Vendor must provide details.
2.5.2 Transparency
[R44] The system must transparently forward all Ethernet frames conforming to IEEE 802.3
apart from the exceptions listed in Table 3.
[R45] The protocols listed in Table 3 must be discarded on ingress unless the GPON system
is required to act upon the frame (such as LACP for LAG).
[R46] Vendors must state whether the degree of transparency is configurable in any way.
Type Description
Invalid Ethernet Frames For instance, those with FCS errors or those that are too large or
too small
802.3x PAUSE Local link flow control protocol
Slow Protocols Set of protocols that includes LACP and 802.3ah OAM
802.1X Authentication Authentication protocol
Table 3: Transparency exceptions
Page 23 of 87
IN CONFIDENCE
[R47] Physical layer protocols such as auto-negotiation signalling must not be passed across
the GPON system.
2.5.3 Ethernet OAM
The system must comply fully with the following Ethernet OAM standards. Please include any
constraints or limitations as well as roadmap dates for any aspect of the standards that are
currently not supported.
[R48] Ethernet in the First Mile OAM as specified in IEEE 802.3ah.
[R49] Connectivity Fault Management: as specified in IEEE 802.1ag.
[R50] OAM functions and mechanisms for Ethernet based networks as specified in ITUT
Y.1731.
[R51] The vendor must indicate how Service Layer OAM (802.1ag and Y.1731) may be used
to monitor and diagnose customer connectivity end-to-end across the GPON system
from the customer interface on the ONT to the CP handover port.
[R52] The vendor must demonstrate how Service Layer OAM (802.1ag and Y.1731) may be
used by the CP to monitor their connections end-to-end across the GPON system.
2.5.4 QoS
[R53] The GPON system must be able to support a mixture of uncontended fixed and assured
bandwidth services and bursty services:
- Uncontended fixed and assured bandwidth products do not allow for any bursting
above the committed rate, i.e. CIR = PIR.
- Bursty services may allow users to burst above the committed rate when surplus
bandwidth is available on the GPON system.
[R54] The GPON system must be able to mark/re-mark any traffic above the committed rate
but lower or equal to the peak rate as discard eligible, and discard any traffic above the
peak rate, e.g. a dual rate Three Colour Marker (drTCM)
[R55] The vendor must explain, (including a diagram), how the QoS architecture works to
ensure that only bursty traffic above the committed rate is discarded during congestion.
[R56] The vendor must explain how the 802.1p bits are used to ensure that lower priority
traffic is discarded before higher priority traffic during congestion.
[R57] The GPON system must be able to allow bursty services to utilise any available
bandwidth above the committed rate for as long as it is available. The vendor must
explain how this is achieved.
[R58] The GPON system must be able to limit the period over which users are allowed to
burst above the committed rate, i.e. restrict the average non-guaranteed burst
bandwidth per End User, without reducing their peak burst rate. The vendor must
explain how this is achieved.
[R59] The vendor must state whether it is possible to provide a consistent service over time
for bursty services by limiting the total amount of burst traffic on the PON so that the
Page 24 of 87
IN CONFIDENCE
customer experience remains consistent as more users are added and the PON gets
more congested. The vendor must explain how this is achieved.
[R60] Vendor must detail, i(ncluding a diagram), the end-to-end upstream and downstream
queuing architecture across the GPON system, including:
- Number of queues
- Queuing algorithm (Strict Priority, WRR etc)
- Queue depth
- Any bottlenecks
- Policing/shaping algorithms
- Shaping approach (evenly spaced bits or bursts)
- Burst Size minimum/maximum limitations and granularity
Page 25 of 87
IN CONFIDENCE
2.6 FTTP System Scalability
[R61] The proposed vendor solution must be scalable from hundreds of end users to tens of
thousands of end users for each FTTP site.
These sites will be UK wide. To understand the scalability of a vendors solution the following
forecast figures are to be used as representative volumes for FTTP sites.
Time Period Number CP Interface Ports Number of End Users

of CPs
June 2009 July 2010 10 nx1GE and nx10GE 500
Aug 2010 July 2011 50 nx1GE and nx10 GE 5000
Aug 2011 July 2012 70 nx1GE and nx10GE 10,000
Aug 2012 July 2013 100 nx10 GE 10,000+
As stated in [R4], the proposed solution must support a minimum of 50 optical interfaces for
hand-off to CPs (point R). Both 1GE and 10 GE interfaces are required with an indicative
ratio of 5x1GE to 1x10GE.
Openreachs preference is that the above can be delivered by a single OLT chassis.
[R62] Vendors are requested to clearly describe how their proposed solution can scale to
meet the above.
- The number of OLT units, cards and ports should be identified for each time
period.
- The use of an additional Ethernet switch, if required, should be clearly defined
including the size of switch matrix and the total number of switch ports
- Descriptions of how VLAN tagging, switching and shaping are performed for such
volumes must also be included.
[R63] The vendor must detail how VLAN isolation is achieved; i.e. the ability to re-use VLAN
values on different physical ports
2.7 GPON QoS Requirements
The GPON system must have the necessary QoS mechanisms to ensure the delay, jitter and
packet loss requirements of the Generic Ethernet Access products can be met. These are
currently under review by Openreach and so the following requirements may be subject to
change.
[R64] To meet the QoS limits, the GPON system must have the appropriate packet
prioritisation, scheduling, connection admission control (CAC) and bandwidth
management for both the downstream and upstream traffic streams. Hence, the OLT
and ONT must support upstream and downstream queuing and connection control.
[R65] The GPON must have a maximum mean signal transfer delay of 1.5 msec as
specified in G.984.1.
[R66] The GPON must comply with the jitter transfer jitter tolerance and jitter generation
limits specified in G.984.2.
[R67] For upstream traffic, the GPON must support all five T-Cont types as specified in
G.984.
[R68] The system must support at least 4 instances of each T-CONT type per ONU.
Page 26 of 87
IN CONFIDENCE
[R69] The vendor must state any limitations with regard to the total number of T-CONTs,
and mix of T-CONT types that can be supported per ONT, and per GPON.
[R70] The GPON system must support status reporting, and non-status reporting dynamic
bandwidth assignment.
[R71] The Vendor must state the DBRu modes supported.
[R72] The Vendor must describe the options available for implementing downstream QoS.
[R73] The vendor must provide measured values for downstream worst case delay, jitter
and packet loss ratios for the different QoS levels for the below traffic scenarios. This
applies between CP hand-over point and ONT UNI (References R and S in Figure 3).
Contributions from all elements must be stated.
[R74] The vendor must state the options available for implementing upstream QoS, both at
the T-CONT level, and within a T-CONT.
[R75] The vendor must provide measured values for upstream worst case delay, jitter and
packet loss ratios for the different QoS levels. This applies between ONT UNI and
CP hand-over point (References S and R in Figure 2). These values must be
supplied for all 5 T-Cont types. Contributions from all elements must be stated.
All tests to be carried out with 32 ONTs connected to the PON, the 31 ONTs will be
running two data products and two voice products that are defined below.
Voice Product
135Kbps upstream @ 120byte Ethernet frame size using T-CONT type 3
135Kbps downstream @ 120byte Ethernet frame size
Data Product
2Mbps upstream @ 256byte Ethernet frame size using T-CONT type 2
10Mbps downstream @ 256byte Ethernet frame size
The following tests (1 to 100) to be performed one at time on a Port in the remaining
ONT,The remaining ONT which will be also running a single voice product (as defined
above) on one port and a single data product (as defined above) on an other port
Please show maximum, minimum and average latency and jitter for a 5 minutes
period for each test scenario. Please also included a histogram for the latency.
Test 1 to 5
135Kbps upstream @ 64byte Ethernet frame size using T-CONT type 1,2,3,4 & 5
Test 6 to 10
Test 11 to 15
Test 16 to 20
135Kbps upstream @ random Ethernet frame size using T-CONT type 1,2,3,4 & 5
Page 27 of 87
IN CONFIDENCE
135Kbps downstream @ random Ethernet frame size
Test 21 to 25
0.5Mbps upstream @ 64byte Ethernet frame size using T-CONT type 1,2,3,4 & 5
2.5Mbps downstream @ 64byte Ethernet frame size
Test 26 to 30
Test 31 to 35
Test 36 to 40
0.5Mbps upstream @ random byte Ethernet frame size using T-CONT type 1,2,3,4 &
5
2.5Mbps downstream @ random byte Ethernet frame size
Test 41 to 45
2Mbps upstream @ 64byte Ethernet frame size using T-CONT type 1,2,3,4 & 5
Test 46 to 50
Test 51 to 55
Test 56 to 60
2Mbps upstream @ random Ethernet frame size using T-CONT type 1,2,3,4 & 5
10Mbps downstream @ random Ethernet frame size
Test 61 to 65
Test 66 to 70
Test 71 to 75
Test 76 to 80
Test 81 to 85
Test 86 to 90
Page 28 of 87
IN CONFIDENCE
Test 91 to 95
Test 96 to 100
2.8 CP Handover Points and Interfaces
Customer traffic will be aggregated and handed over to CPs at the exchange containing the
OLT. Existing modes of traffic handover/backhaul will be used; in-building, in-span or CP site.
The following interface types are required:
[R76] The 1 GE interfaces must conform to IEEE 802.3z.
[R77] The 10 GE interfaces must conform to IEEE 802.3ae.
[R78] All interface cards must be able to operate in Protection or Link Aggregation mode
[R79] Each optical interface, 1 GE and 10 GE, must support autosensing
2.9 CP Service Level Agreement
It is envisaged that CPs will be offered a Service Level Agreement (SLA).
The service availability will be dependent on the outcome of an Openreach study on GPON
and FTTP product reliability.
[R80] Vendors are requested to present reliability studies, including equipment FIT rates
and propose service level availability figures that can be achieved for the two
products, GEA - VEP and GEA Data. The following MTTR figures must be used;
OLT=4hours, ONT=8hours, Business ONT=4hours, ODN fault =24hours.
2.10 Future GPON Equipment Upgrades
As with the optical infrastructure, there must be no changes to the GPON equipment that
result in a degradation of customer service, except where noted below.
2.10.1 Software Upgrades
[R81] All software upgrades to the OLT, ONT and GPON element manager must be non-
service affecting.
2.10.2 Hardware Upgrades
[R82] All hardware upgrades to the OLT, ONT and GPON element manager must be non-
service affectiong with the following exceptions:
ONT upgrade is acceptable if migrating from GPON to Next Generation PON e.g. 10 Gbit/s
Page 29 of 87
IN CONFIDENCE
ONT back-up battery maintenance and replacement .
2.11 Resilience and Reliability
Resilience requirements are specified in the OLT and ONT sections of this document.
In addition to this Openreach requires responses to the following document for reliability
modelling purposes.
GPON ITT Reliability.zip

[R83] Vendors must provide a compliance response against each of the requirements
stated in the above reliability document.
2.12 GPON OLT Requirements
[R84] STM-4 interfaces are required for TDM hand-off to CPs (point R).
[R85] The STM-4 capability must be provided using a plug-in module or card.
[R86] The Vendor must state the maximum number of STM-1 interfaces per module/card.
[R87] The Vendor must state the maximum number of STM-4 interfaces per module/card.
[R88] For the above STM-1 and STM-4 interfaces, vendors must state whether 1:1 card
and /or port protection is supported.
2.12.1 General Requirements
[R89] The GPON OLT card must provide full access to the 2.5 Gbit/s downstream and 1.24
Gbit/s upstream bandwidth per PON. This applies regardless of the number of PON
ports on a single OLT card.
[R90] The OLT must be able to support multiple ONT types (single-user/multi-user,
residential/business, MDU) on the same PON.
[R91] The OLT must support up to 128 ONTs per PON port. Other than physical reach,
vendors must state any limitations relative to operation with fewer ONTs.
[R92] The OLT must support a maximum logical reach of 60 km in conformance with ITU-T
G.984.1.
[R93] The OLT must support class B+ optics as specified in section 2.3 GPON Bit Rates
and Optical Budgets
[R94] Insertion or extraction of an OLT card in an OLT unit must not affect the correct
operation of other cards in the same shelf.
2.12.2 TDM Interfaces
[R95] The OLT must support STM-1 electrical interfaces in conformance with ITU-T G.703,
optical S-1.1, I-1, L-1.1 and/or L-1.3 (in conformance with ITU-T G.664, G.707,
G.825, G.957).
Page 30 of 87
IN CONFIDENCE
[R96] The OLT must support at least one STM-4 electrical interface in conformance with
ITU-T G.703, optical S-4.1 I-4, L-4.1, L-4.3, V-4.1, V-4.3 and/or U-4.3 (in conformance
with ITU-T G.664, G.707, G.825, G.957).
[R97] All OLT TDM interfaces must be on plug-in modules.
[R98] Insertion or extraction of an SDH card in a shelf must not affect the correct operation
of other cards in the same shelf.
[R99] Native TDM must be supported using TDMoGEM. Upstream TDM traffic,must be
transmitted in GEM frames and mapped into a Virtual Container (VC). Downstream
TDM traffic must be encapsulated in downstream GEM frames.
2.12.3 Ethernet Interfaces
[R100] 1 GE interfaces must conform to IEEE 802.3z
[R101] 10 GE interfaces must conform to IEEE 802.3ae
[R102] The OLT must support the following Gigabit Ethernet interface types:
1000Base-SX
1000Base-LX
1000Base-ZX
[R103] The OLT must support the following 10 Gigabit Ethernet interface types:
10GBase-LR
10GBase-LW
[R104] The Vendor must provide details of the physical characteristics (optical power
budgets, reach etc) of all the interfaces given in response to [R102] and [R103]
[R105] The Vendor must state whether the OLT supports SFPs for the CP handover ports
and whether the SFPs are hot-swappable
[R106] The Vendor must state whether the OLT supports Singe Fibre Working for the CP
handover ports
2.12.4 Card and Port Resilience
[R107] The OLT must support LACP-based LAG as specified in IEEE 802.3 Clause 43
across all Ethernet ports
[R108] Vendors must state whether the LAG works in a load-sharing or 1:1 protection mode
[R109] Load-sharing LAG must support::

- Per VLAN rate limiting across all links in the LAG
- In-service addition and removal of links
[R110] 1:1 protection mode LAG must support::

- Non-revertive switchover1
- Ethernet ports on separate line cards included in the same LAG
1
Restoration of a failed link in the LAG must not result in an activity switch back to the original
link
Page 31 of 87
IN CONFIDENCE
- Per port protection2
[R111] Redundant power supply cards with automatic hitless switching to the standby card is
mandatory.
[R112] For systems supporting PON interface protection, the optical G-PON termination
must be fully redundant in conformance with the type B protection scheme of ITU-T
G.983.5.
[R113] The OLT must support hardware redundancy and automatic hitless switching for the 1
GE and 10 GE interfaces.
2.12.5 VLAN Manipulation

[R114] The OLT must not use MAC bridging (MAC address flooding and learning) to forward
traffic between the CP handover ports and GPON ports. It must therefore be possible
to disable any MAC bridging functionality.
[R115] The OLT must be able to add an outer VLAN tag to upstream frames based on the
value of the incoming ONT VLAN and GEM port ID combination.
[R116] The OLT must be able to add an outer VLAN tag to downstream frames based on the
CP handover port and the value of the incoming VLAN ID from the CP.
[R117] The OLT must be able to add an OLT VLAN tag to downstream frames based purely
on the CP handover port, i.e. on a per port basis.
[R118] The OLT must be able to forward frames based purely on the outer (OLT) VLAN tag
[R119] The OLT must be able to forward frames based on both outer (OLT) VLAN tag and
inner (ONT) VLAN tag.
[R120] The GPON system must be able to transport all EU/CP VLAN tags transparently end-
to-end across the GPON system. Hence, the OLT must be able to transport any
EU/CP VLANs in addition to the ONT and OLT VLAN tags added by BT within the
GPON system, which could result in triple- or quadruple-tagged frames
[R121] The OLT must be able to remove the outer (OLT) VLAN tag from all downstream
frames
[R122] The OLT must be able to remove the outer (OLT) VLAN tag from all upstream frames
to support single tagged handover to the CP
[R123] The OLT must be able to swap the value of the remaining ONT VLAN tag in the
upstream direction once the outer OLT VLAN tag has been removed on egress to the
CP, and vice versa for the downstream direction
[R124] The OLT must be able to support a double-tagged handover to the CP, i.e. forwarding
both OLT and ONT VLAN tags (in addition to any CP/EU VLAN tags) to the CP
[R125] The OLT must support IEEE 802.1ad
[R126] Some pre-802.1ad implementations of stacked VLANs use Ethertype 0x81-00 for
both the inner and outer VLAN tags. Vendors must state whether the proposed
solution accepts Ethertype 0x81-00 for the outer (S) VLAN tag
2
Failure of a single port on a line card must not cause an activity switch for the entire line
card
Page 32 of 87
IN CONFIDENCE
[R127] After the outer OLT VLAN tag has been removed on egress to the CP, the OLT must
be able to set the Ethertype value of the remaining ONT VLAN to either 0x81-00 or
0x88-A8. This is to be configurable on a per CP handover port basis
[R128] It must be possible to set the IEEE 802.1p value within the OLT VLAN to any value in
the range 0 7 in both the upstream and downstream direction
[R129] After the OLT VLAN tag has been removed on egress to the CP, the OLT must be
able to set the 802.1p value of the remaining ONT VLAN tag to any value in the range
07
[R130] The OLT must be able to translate the 802.1p value in the outer VLAN tag received
from the CP to a BT specified value in the downstream direction, and vice versa in the
upstream direction
[R131] The full VLAN range must be available at the OLT (0 4095) for both the outer VLAN
and inner VLAN tags. Please state any reserved VLANs that are not available for
customer traffic
2.12.6 QoS
[R132] The OLT must support per VLAN policing on ingress to all Ethernet interfaces on a
single VLAN and/or a group of VLANs. Please state what policing algorithm is used
on ingress (e.g. leaky bucket, token bucket etc) to support the full range of GEA
products detailed previously in this document. Include the maximum and minimum
values for each applicable attribute as well as the level of granularity.
[R133] The OLT must support per port policing on ingress to all Ethernet interfaces.
[R134] Vendors must state whether the OLT supports egress shaping on all Ethernet
interfaces and what algorithm is used. Include the maximum and minimum values for
each applicable attribute as well as the level of granularity.
[R135] Vendors must state whether the Ethernet policing/shaping algorithm includes the
Inter-frame Gap (IFG) and/or the frame pre-amble.
[R136] Once each VLAN has been allocated its CIR, the ingress policing and/or egress
shaping must allocate any remaining bandwidth proportionally based on each
individual VLANs CIR
[R137] The OLT must be able to schedule frames based on the IEEE 802.1p value on
ingress and egress
[R138] The OLT must be able to queue frames based on VLAN ID
2.12.7 Synchronisation
[R139] The OLT must be able to recover the timing signal from an external synchronisation
interface (BITS interface) of 2048 kHz in conformance with ITU-T G.703 and G.823.
[R140] The OLT must be able to recover the timing signal from an Ethernet-based SNI in
accordance with G.8261.
[R141] The OLT must be able to use a free running clock with 20 ppm accuracy when all
other available input clocks are lost.
Page 33 of 87
IN CONFIDENCE
[R142] The OLT must be able to switch the reference clock source from one source to
another one. The choice of the active source is ruled by a configurable priority level
scheme. This switching must be hitless for the traffic.
[R143] Revertive mode with waiting time to restore and forced switching on a valid
synchronisation source is a required option. The switching must be hitless for the
traffic.
2.12.8 Transfer/forwarding
[R144] The OLT must be able to achieve scheduling and prioritisation of services using
mechanisms based on traffic and QoS parameters per S-VLAN.
[R145] The OLT must be able to allow over-provisioning of best efforts burst bandwidth but
not fixed or assured bandwidth.
[R146] The OLT must be able to manage network congestion using mechanisms to ensure a
fair allocation of network resources for products with same CoS. Vendors to state
how this is achieved.
2.12.8.1 OLT Ethernet and QoS Requirements
[R147] The GPON OLT must fully support the Ethernet requirements in section 3.5.
[R148] The GPON OLT must fully support the QoS requirements in section 3.5.
2.13 GPON ONT Requirements
All requirements in this section apply to all ONT types unless specifically stated otherwise.
Vendors must state any ONT types that do not comply.
[R149] ONTs must contain an integrated Wavelength Blocking Filter that meets the
requirements of G.984.5.
2.13.1 VLAN Manipulation
[R150] The ONT must not use MAC bridging (MAC address flooding and learning) to forward
traffic between the EU ports and the GEM ports. It must be possible to disable any
MAC bridging functionality in the ONT.
[R151] The ONT must be able to add a VLAN tag (ONT VLAN tag) to all upstream traffic on
a per EU port basis. The ONT VLAN tag must be added to each frame regardless of
whether the frame already contains a customer tag or not. Similarly the ONT VLAN
tag must be removed in the downstream direction before handover to the EU.
[R152] The ONT must be able to add an ONT VLAN tag to all upstream traffic based on the
customer VLAN ID. Similarly the ONT VLAN tag must be removed in the downstream
direction before handover to the EU
[R153] The ONT must be able to swap the EU VLAN ID to a BT specified value in the
upstream direction, and vice versa in the downstream direction.
[R154] The same ONT VLAN tag value must be supported on multiple ONTs simultaneously
on the same PON, differentiated by the use of GEM port IDs.
[R155] [It must be possible to set the IEEE 802.1p value within the ONT added VLAN tag to
any value in the range 0 7
Page 34 of 87
IN CONFIDENCE
[R156] The ONT must be able to translate the 802.1p value in the EU VLAN tag to a BT
specified value in the upstream direction, and vice versa in the downstream direction.
[R157] The Ethertype of the ONT VLAN tag must be 0x81-00. This Ethertype may be
changed to 0x88-A8 on egress to the CP.
[R158] The full VLAN range must be available at the ONT (0 4095). Please state any
reserved VLANs that are not available for customer traffic.
2.13.2 QoS and CoS
[R159] The ONT must support per VLAN ingress policing on a single VLAN and/or a group of
VLANs. Please state what policing algorithms are available on ingress (e.g. leaky
bucket). Include the maximum and minimum rates for each applicable attribute the as
well as level of granularity.
[R160] The ONT must support per (physical) port ingress policing.
[R161] For double-tagged frames containing an ONT VLAN tag and an EU VLAN tag, the
ONT must support ingress policing based on the outer (ONT) VLAN tag
[R162] For double-tagged frames containing an ONT VLAN tag and an EU VLAN tag, the
ONT must support ingress policing based on the inner (EU) VLAN tag
[R163] The Vendor must state whether the Ethernet policing algorithm includes the Inter-
frame Gap (IFG) and/or the frame pre-amble
[R164] The ONT must be able to schedule frames based on the IEEE 802.1p value of the
ONT VLAN tag on ingress and egress at every Ethernet interface
[R165] The ONT must be able to queue frames based on VLAN ID
[R166] For a specified CIR the system should be able to confirm a specific 802.1p marking
as set by the EU or CP up to the CIR value. It must also discard or remark to a
specified 802.1p marking any traffic in excess of the CIR value or not marked as per
the required value. For a specified PIR the system should be able to confirm a
specific 802.1p marking as set by the customer or CP up to the PIR value and discard
any traffic in excess of the PIR value or remark to a specified 802.1p marking any
traffic not marked as per the required 802.1p value
2.13.3 ONT Types
The current Openreach requirements are based around one ONT per single dwelling unit,
including individual apartments in multi-dwelling units (MDUs).
Requirements for a specific MDU ONT will be investigated at a later date.
For initial GPON deployments in June 2009, it is anticipated that indoor ONTs will be used.
However, Openreach expects there to be a future requirement for external and semi-
ruggedised ONTs and hence the requirements currently identified for these are also listed in
this section.
2.13.4 Indoor ONT Requirements
Page 35 of 87
IN CONFIDENCE
Figure 9 illustrates the proposed ONT input and output requirements and should be
considered in conjunction with the relevant sections below for clarification of functionality.
[R167] The ONT must be designed so that upon complete loss of power the configuration is
not lost. When power is restored the ONT must return to normal operation with no
local or remote intervention required.
Reset Power LINK

Button LED LED
Link Status/Activity SC -UPC uniter /patchcord

status RJ45 LEDs and cable clamping
1 2 3 4
Double RJ45
Customer
Replaceable Insulated Low
Battery Voltage
Power Supply
240V Switched
Ring Main socket
Figure 9: Proposed block diagram of ONT input/outputs (for illustrative purposes only)
2.13.5 Network Interfaces
The following section details the ONTs electrical and optical network interfaces.
2.13.5.1 Ethernet Interfaces
[R168] FE interfaces must conform to IEEE 802.3u
[R169] GE interfaces must conform to IEEE 802.3z
[R170] The UNI ports must support 10/100/1000Base-Tx. The default setting must be 100
Mbps but be re-configurable for 10Mbps or 1Gbps operation via the element manager
[R171] Vendors to state the maximum useful throughput (in Mbit/s) of UNI ports, assuming
only one ONT on the PON. If this will increase in future releases provide roadmap for
this feature
[R172] Each UNI port must be configurable as a data or voice port
[R173] It must be possible to disable auto-negotiation on all ONT Ethernet interfaces and
manually configure the port speed and duplex settings
[R174] Copper Ethernet ports must use RJ-45 connectors

Page 36 of 87
IN CONFIDENCE
[R175] Each Ethernet port must have two associated LEDs; one for Link Status and one for
Activity Status.
[R176] Each port must be individually numbered 1 to 4, from left to right when viewing the
ports as illustrated in Figure 10
Figure 10: EU port numbering on ONT
[R177] The port numbering scheme in the EMS must correspond to that on the physical ONT
2.13.5.2 Fibre Network
[R178] The ONT must interface into a single-mode fibre of type G.652 via an SC-UPC
connector compliant with the specifications given in section 5.1.8.
[R179] The open port on the SC-UPC connector/uniter must be fitted with a dust cover.
2.13.6 ONT Physical Design Considerations
The ONT will be classed as an indoor device, and will therefore require a casing providing
protection to the relevant indoor environment. The following sections detail the ONT physical
design considerations.
2.13.7 Power Supply
[R180] The power supply to the ONT must be a single, low voltage power interface including
the optional capability for battery backup. It should be of the Fat plug type. The
power supply must be of minimal size and weight. Details must be stated.
[R181] The PSU must be suitable for use with the standard domestic UK supplied 240V (ac)
and conform to the relevant standards given in section 5.1.
Key operating features are as follows;
[R182] The ONT power connection must be provided in such a way that incorrect insertion is
not possible.
[R183] Easy customer change out of the Openreach supplied replacement power supply.
[R184] Provide status signalling to the ONT (see section 4.4.3).
[R185] Must display marking in accordance with Directive 89/336/EEC.
[R186] Short circuit protection must be included on the power and battery unit.
Page 37 of 87
IN CONFIDENCE
[R187] Low power and power saving modes are required in line with EU directives on power
shedding and FSAN / ITU-T SG15/Q2 work on power saving.
[R188] The maximum length of the ONT to power supply cable must be 2.0m.
[R189] Must conform with the material requirements given in section 2.13.12
2.13.8 Power Saving & Shedding Modes
Openreach, in conjunction with the GPON standards groups, is investigating the use of power
saving modes in the ONT. They key challenge is to reduce power consumption whilst
ensuring there is no detrimental effect on service performance
[R190] The ONT output power consumption must be <10W, with a target of <5W.
[R191] Vendors are requested to advise Openreach of results of any investigations in this
area.
2.13.9 Reset Button
[R192] Openreach requires the ONT to self-reset in the event of a system lockup. To ensure
an engineer visit is not required, a Power Reset switch must be available. In the event
of a lockup from which the system cannot recover, this is deemed more efficient than
physically removing the power supply wiring or battery from an ONT.
[R193] The system Reset button must be made available with the following outline design;
When the button is pressed the ONT must reset to a known default state.
The button must be recessed to avoid accidental resetting.
The button must be accessible through a 2mm hole.
Alternative reset button proposals will be considered.
2.13.10 Battery Subsystem
[R194] Each ONT type must be provided with battery back-up as an optional capability.
[R195] The battery must be readily sourceable (e.g. UK high street or mail order) and be
easily replaceable by the customer
The battery must meet the following minimum requirements;
[R196] Rechargeable, with a minimum life expectancy of 5 years.
[R197] Capable of sustaining the operation of the ONT for a minimum of 4-hours under
normal operating conditions.
[R198] Able to signal the following conditions to the ONT.
Signal Signal Parameter

Condition
On Battery When the mains power has failed and the battery is powering the ONT.
Battery Missing Battery was provisioned but is missing.
Battery Failure Battery is provisioned and present but cannot recharge.
Page 38 of 87
IN CONFIDENCE
Battery Low Battery is provisioned and present but its voltage is too low.
[R199] Provide a user visible indication via an ONT LED of the following conditions.
LED Indicator LED Label Parameter to be Alerted

Colour
Green Operating on mains power.
POWER
Red Operating on battery power.
[R200] Conform to Annex A of ETSI EN 302-099.
2.13.11 Cooling
[R201] The ONT must meet the ETSI EN 300-119-5 (Part 5 Thermal management)
specification, where the following design aspects are covered.;
[R202] No active cooling devices.
[R203] Maximum external case temperature must not exceed 60 oC.
2.13.12 Materials
The ONT manufacturing materials must conform to the following requirements (see Health &
Safety, section 2.19 for additional information).
[R204] Flammability requirements for all polymer materials must meet IEC 60950 - as
outlined in the Openreach GS fire risk standard (See section 5.1.7).
[R205] Metallic parts must be resistant to corrosive influences they may encounter during the
service lifetime of the product.
[R206] Dissimilar metals must not be used in contact with each other unless they are suitably
finished to prevent electrolytic corrosion.
[R207] UV light and fungi on exposed polymeric materials must not affect the product
performance.
[R208] Must be resistant to solvents and degreasing agents used in the preparation of fibre
splicing and cleaning and general household cleaning products.
2.13.13 Electrical Connector Location
With reference to Figure 9, a proposed layout is illustrated for the arrangement of electrical
connectors. Key points are;
[R209] Ethernet ports must be accessible to the customer.
[R210] Power connection must be accessible to the customer.
[R211] Rubber grommets must be provided to secure cables if they pass through the ONT
case.
Page 39 of 87
IN CONFIDENCE
2.13.14 Physical Requirements
[R212] The ONT must be no larger than 200mm long x 150mm wide x 30mm deep,
excluding any optional mountings. It must allow easy access to electrical ports and
visual checking of status LEDs and reset button. BTs preference is for the ONT to
be as small as possible.
2.13.15 Mounting
[R213] The ONT must be capable of being wall mounted in the horizontal or vertical plane.
2.13.16 Status Indicators
[R214] The ONT must provide an LED status indicator that complies with the following
requirements.
ONT Status PON LED LED Label

OK Green
Attempting to sync with OLT Flashing Green LINK
No optical power present Red
2.13.17 Environmental Requirements
Guidance on protection in indoor environments can be found in the Openreach Generic

Specifications and as defined in the BS IP specifications for enclosures. The ONT, power
supply and battery must meet the following standards:
[R215] ETSI EN 300-019-1-3 [Class 3.2]: Classification of environmental conditions;

stationary use at weather-protected locations.
[R216] ETSI EN 300-019-1-2 [Class 2.3]: Public Transportation
[R217] EN 60950-1 Information technology equipment-safety.
[R218] BS EN 60529 Degrees of protection provided by enclosures to IP code 55.
2.13.18 Enclosure & Aesthetics
The following section details the end product form.
2.13.18.1 Finish
[R219] The ONT must not present any sharp edges or protrusions that could be deemed a
safety hazard.
Openreach are currently developing a requirements specification for the ONT finish, colour /
texture, materials and branding. These requirements will be sent to vendors as and when
necessary.
Page 40 of 87
IN CONFIDENCE
2.13.18.2 Packaging and Labelling
[R220] Each consignment of ONTs must be packed and marked in accordance with the
detailed requirements specified in the web link:
http://selling2bt.extra.bt.com/WorkingWithBT/DeliverytoBT/default.htm
2.13.19 System Requirements
2.13.19.1 Protocols
[R221] The ONT must communicate with the OLT via OMCI as defined in G.984.4.
2.13.19.2 ONT Ethernet and QoS Requirements
[R222] The GPON ONT must fully support the requirements in section 2.5 Generic Ethernet
Requirements.
[R223] The GPON ONT must fully support the requirements in section 2.6 GPON QoS
Requirements.
[R224] For upstream traffic, the ONT must support T-Cont types 1,2,3,4 and 5 as specified in
G.984.3.
[R225] The ONT must support the simultaneous operation of at least 4 T-CONTs of either the
same or different types.
[R226] The ONT must support both Single and Multiple T-CONTs as per G.984
[R227] The ONT must support a single T-Cont, of any type, for each Ethernet port.
[R228] The ONT must support multiple T-Conts, of any type, for each ONT port.
[R229] The ONT must support both status-reporting dynamic bandwidth assignment and non
status-reporting bandwidth assignment.
[R230] Vendors must state the maximum number of T-Conts supported by the ONT
[R231] Vendors must state the maximum number of T-Conts supported by each Ethernet
port.
2.13.19.3 Synchronisation
[R232] The ONT must be synchronised to the OLT, which derives its clock from the
Openreach exchange clock.
[R233] An internal free running clock with an accuracy of 20 ppm must be available if the
OLT clock is lost.
Vendors are requested to provide details of the holdover mode supported.
2.13.20 Test and Diagnostic Requirements
[R234] No craft terminals or diagnostic ports must be available on the ONT and there must
be no ability to configure the ONT via the UNI ports.
Page 41 of 87
IN CONFIDENCE
[R235] There must be history and logging of system events and [R71] provision for an Auto
reset after a system lockup via a watchdog timer.
The GPON system in addition to the OMCI fault management (section 2.6) must be capable
of remotely monitoring the following transceiver parameters for fault diagnosis purposes.
[R236] ONT Receiver Signal Detect
[R237] ONT Receiver Optical Power Level
[R238] Transmitter Optical Power Level
[R239] Transmitter Laser Bias Current
[R240] The dynamic range and accuracy of each parameter must be in line with guidelines to
be issued by the FSAN optical layer supervision sub-committee.
2.13.20.1 Power Supply Alarms
[R241] The ONT must provide a last gasp alarm facility in the event of a complete power
failure.
[R242] If a battery is installed then an alarm must indicate when power has failed and that
the backup battery is in use. A last-gasp alarm must be provided if the battery
subsequently becomes excessively discharged.
[R243] It must be possible for the end user to change the battery without requiring any
specialist tools.
2.13.21 CPE Port Test Requirements
Where a fault has occurred it can be difficult to determine its location. To facilitate fault
location, the capability to carry out loopback checks at key points within the PON system is
required.
[R244] The ability to loopback data from the ONT and have it analysed by the OLT is a
requirement, as defined in G.983.2 (ONT management and control interface
specification for B-PON). The loopback facility and the ONT verification of a valid
data signal must allow confirmation that data was being transmitted successfully
across the PON.
2.13.22 Security Requirements
[R245] The GPON system must be compliant with the Advanced Encryption Standard as
defined in G.984.3.
[R246] The OMCI channel must be secured as detailed in Section 7.4 of G.984.
The ONT must also comply with Security requirements in section 7.
2.13.23 Reliability
Page 42 of 87
IN CONFIDENCE
[R247] There must be no rogue ONT transmissions, i.e. the ONT should only transmit during
its correctly allocated timeslot.
[R248] The ONT must a have a watchdog facility and self-reset in the event of the ONT
malfunctioning.
[R249] Vendors must provide FIT rates for the ONT
[R250] Target minimum guaranteed lifetime is shown below during which an acceptable
failure rate (to be determined by BT following BTs GPON reliability analysis using
vendor responses) is expected:
- Battery 5 years.
- Power supply 15 years.
- ONT 20years.
2.13.24 Laser safety
[R251] Optical performance must comply with

Class / Hazard level 1 as defined in IEC 60825 part 2, edition 3 (See section 5.1.8).
2.13.25 Electrical Safety
[R252] Compliance with BS EN 61140.
2.14 Indoor Business ONT
[R253] Vendors are requested to state full compliance with the above Indoor ONT
Requirements in section 5.1.
In addition, vendors are requested to state compliance with the following:
[R254] Support for four E1 interfaces (in addition to the four 10/100/1000Base-T interfaces)
in conformance with ITU-T G.703, G.704, G.823 (jitter and wander levels), ETSI EN
300 912 and 3GPP TS 125 402 specifications (clauses dealing with frequency
stability and accuracy).
[R255] Configuring each E1 interface as "TDM unstructured" (in conformance with ITU-T
G.703) or "TDM structured" (in conformance with ITU-T G.703 and G.704).
Openreach is considering the use of TDM emulation over Ethernet and TDMoGEM.
[R256] If emulation over Ethernet is supported, please state if the IETF or MEF mechanism
is used for TDM flow transport.
[R257] Support the use of TDMoGEM features in conformance with ITU-T G.984.3 Appendix
I.2 in order to transport TDM data in an unstructured way.
2.15 Outdoor/Semi-Ruggedised ONT Requirements Specification
[R258] Vendors are requested to state full compliance with the GPON Indoor ONT
Requirements in section 5.1.
In addition, vendors are requested to state compliance with the following:
Page 43 of 87
IN CONFIDENCE
[R259] The external and semi-ruggedised ONT must be mounted within an enclosure
suitable for external applications in a non-weather protected environment.
[R260] An external door must allow customer access to view LED(s) status indicators and
operation of reset button, as required.
[R261] An internal door must be accessible by a Openreach engineer only and allow access
to the optical and electrical inputs and outputs.
[R262] The maximum external case temperature must not exceed 60 oC.
[R263] The ONT must be capable of working with an internal maximum air temperature of
+70C which includes the effects of solar radiation
[R264] The ONT power supply and battery must be located in a weather protected location
inside the external case and must meet the following;
[R265] [ETSI EN 300-019-1-3 [Class 3.2]: Classification of environmental conditions;

stationary use at weather-protected locations.
The ONT located in a non-weather or semi-weather protected location must meet the
following standards;
[R267] ETSI EN 300-019-1-4 [Class 4.1 with upper max air temperature of +70C]:
Classification of environmental conditions; stationary use at non-weather-protected
locations.
[R269] A two stage door design may be used. The external door will allow the end user
access to view LED(s) status indicators and operation of reset button, as required.
Easy access shall be provided. The internal door will be accessible by a BT engineer
only and allow access to optical and electrical inputs and outputs. Access will be via
Torx security screws or simila
[R270] For the internal door, provision must be made for a Openreach security tag (tamper
proof seals) to show unauthorised entry where appropriate.
2.16 GPON Management
The GPON will be implemented as a stand-alone system from the management perspective.
2.16.1 General EMS & OSS requirements
The GPON element management system (EMS) has responsibility for the following functions
pertaining to the OLT and ONT:
User administration
Network Configuration Management
Service Provisioning
Performance Management
Alarm & Event Management
Embedded Software Management
Security
Page 44 of 87
IN CONFIDENCE
[R271] The element manager must use SNMP to communicate with the OLT, which has
responsibility for controlling all ONTs via the GPON ONT Management and Control
Interface (OMCI) and Physical Layer Operations, Administration and Maintenance
(PLOAM) channel.
[R272] Vendors must state which versions of SNMP are supported
[R273] The EMS must be implemented on a fully redundant hot-standby platform.
[R274] Integration into Openreachs Data Communication Network (DCN) must be via an in-
band management channel on an OLT GE interface or via a separate management
port on the OLT.
Vendors are requested to state if both options are available and provide details of the
bandwidth requirements and management port interface.
The Openreach EMS and OSS requirements for GPON are contained in the following zip file.
EMS GEA ITT SOR.zip
[R275] Vendors must provide a compliance response against each of the requirements
stated in the above document.
The GPON system uses two mechanisms to manage and control the ONT: PLOAM and
OMCI
2.16.2 PLOAM Channel
Physical Layer OAM (PLOAM) provides PON management functionality, such as ranging,
activation of the ONU, establishment of OMCC, and alarm transfer.
[R276] The GPON system must be fully compliant with the PLOAM functionality specified in
G.984.3
2.16.3 GPON OMCI
[R277] The GPON system must be fully compliant with the OMCI functionality specified in
G.984.4.
2.17 Test & Diagnostic Requirements
Openreachs test and diagnostics strategy is based on pro-active maintenance via an

intelligent element manager that can predict potential failures and accurately diagnose fault
conditions. This section identifies detailed test and diagnostics requirements of the GPON
Network Elements in support of in-life commissioning, performance monitoring and fault
diagnostics.
2.17.1 Element Manager
The requirements of the element manager are found in the separate Element Manager (EMS)
Statement of Requirements (SOR).
Page 45 of 87
IN CONFIDENCE
2.17.1.1 Grouping of associated alarms

[R278] The element manager must group all alarms to present only the higher order alarms
to enable targeted diagnostics to be undertaken. The operator needs to be able to
view the lower order alarms upon request.
2.17.2 Events and Errors
[R279] The system is required to monitor and alarm the events and errors shown in Tables 1
to 3. This is complemented with a set of alarms and events in the Element Manager
SOR particularly in the following set of EMS requirements:
Requirement 1, Section 10: Performance Monitoring, Domain Specific Requirements,

and,
Ethernet OAM features in the 802.XX test features described in Requirements 1 and
2, Section 9, Service testing/Domain Specific Requirements.
Table 4: G984.3 Section 11.1.1 - Events Detected at the OLT
Type Description
Detection conditions Actions Cancellation Actions
conditions
LOSi Loss of No valid optical signal Generate When the OLT

signal for from ONU when it was Loss_of_phy_laye receives a valid
ONUi expected during M r_I notification. optical signal
consecutive frames. from ONUi
(M is configurable.
Recommended value
is 4)
LOS Loss of The OLT did not When the OLT

Signal receive any expected receives at
transmissions in the least one
upstream (complete upstream
PON failure) for transmission.
N consecutive frames.
(N is configurable.
Recommended value
is 4)
LOFi Loss of When 4 consecutive Send 3 times When frame

Frame of invalid delimiters from Deactivate_ONU- delineation for
ONUi ONUi are received ID messages. ONUi is
achieved in the
Generate operating state.
Loss_of_phy_laye
r_I notification.
Page 46 of 87
IN CONFIDENCE
Type Description
conditions
DOWi Drift of An ONU transmission Send modified When the OLT

Window of is received at an EqD to the ONUi receives the
ONUi unexpected place ONUi
within the U/S virtual Transmission in
frame. DOWi means the correct
the phase has shifted position
but is correctable via
modified EqD
Sfi Signal Fail When the upstream Send 3 times When the
of ONUi BER of ONUi Deactivate_ONU- upstream BER
becomes 10y, this ID messages. of ONUi
state is entered. Y is becomes
configurable in the Generate < 10y+1, this
range of 3 to 8 Loss_of_phy_laye state is
r_I notification. cleared.
Sdi Signal When the upstream When the

Degraded BER of ONUi upstream BER
of ONUi becomes 10x, this of ONUi
state is entered. X is becomes
configurable in the < 10X+1, this
range of 4 to 9. But state is
must be higher than Y cleared.
(SF Threshold)
LCDG Loss of GEM Channel could Send 3 times When GEM

i GEM not be delineated Deactivate_ONU- channel
channel during 3 consecutive ID messages delineation for
delineation frames ONUi is
Generate achieved
Loss_of_phy_laye
r_I notification
RDIi Remote When the RDI field of When the RDI

Defect ONUi is asserted. The field of ONUi is
Indication OLT transmission is de-asserted
of ONUi received with defects
at the ONUi
TF Transmitte The OLT transmitter is

r Failure declared in failure
when there is no
nominal backfacet
photocurrent or when
the drive currents go
beyond the maximum
specification.
SUFi Start-up The ranging of ONUi Send 3 times The ONU is

Failure of has failed n times Deactivate_ONU- ranged
ONUi (n = 2) while the OLT ID messages. successfully.
has received optical
bursts from this ONU
Page 47 of 87
IN CONFIDENCE
Type Description
conditions
Dfi Deactivate The ONU does not Cancelled by

Failure of react correctly after the operator.
ONUi three
Deactivate_ONU-ID
messages.
LOAi Loss of The OLT does not Send 3 times When the OLT
Acknowled receive an Deactivate_ONU- receives an
ge with acknowledgement ID messages. acknowledgem
ONUi from ONUi after a set ent from the
of downstream Generate ONU.
messages that imply Loss_of_phy_laye
an upstream r_I notification.
acknowledge.
Dgi Receive When the OLT Ignore received When the OLT
Dying- receives DG message alarms from this receives a
Gasp of from ONUi, DGi is ONU. PLOAM
ONUi asserted. message
Generate during ranging
Loss_of_phy_laye process
r_I notification.
LOAM Loss of When 3 consecutive Send 3 times When the OLT -

i PLOAM PLOAM messages of Deactivate_ONU- receives a
for ONUi ONUi are missing ID messages. PLOAM
after the OLT issues message
Send PLOAMu Generate corresponding
request for that ONU Loss_of_phy_laye to its PLOAM
r_I notification. flag in the
Operating
state.
MEMi Message_ When the OLT When the
Error receives an unknown operator is
Message message from ONUi informed.
from ONUi
MISi Link The OLT detects that The OLT

Mismatch the received PSTi and detects that
of ONUi the transmitted PST received PSTi
are different. and the
transmitted
PST are the
same.
PEEi Physical When the OLT Generate When the OLT

Equipment receives a PEE Loss_of_physical_ does not
Error of Message from the layer_I notification receive a PEE
ONUi ONU message from
the ONUi in 3 s
Page 48 of 87
IN CONFIDENCE
Table 5: G984.3 Section 11.1.2 - Events Detected at the ONU/ONT
Type Description
Detection Actions Cancellation Actions
conditions conditions
LOS Loss of No valid optical signal Switch off laser. Valid optical Move to
Signal is received for N Generate signal. Standby-
consecutive frames or Loss_of_phy_layer State
no electrical notification.
transitions are
received during Move to Initial-
M consecutive State
frames. N & M are
configurable.
Recommended value
is 3
LOF Loss of When 5 consecutive Switch off laser. When 2 Move to

Frame invalid PSYNC from consecutive Standby-
OLT are received. Generate frames have State
Loss_of_phy_layer correct PSYNC
notification.
Move to Initial-
State
SF Signal When the Set inactive

Failed downstream BER when the
becomes 10y, this downstream
state is entered. Y is BER is <
configurable in the 10(y+1)
range of 3 to 8
SD Signal When the Set inactive

Degraded downstream BER when the
becomes 10x, this downstream
state is entered. X is BER is
configurable in the < 10(x+1)
range of 4 to 9, but
must be higher than Y.
LCDG Loss of GEM Channel could Switch off laser. When GEM
GEM not be delineated delineation is
channel during 3 consecutive Generate achieved
delineatio frames. Loss_of_phy_layer
n notification.
TF Transmitt The ONU transmitter

er Failure is declared in failure
when there is no
nominal backfacet
photocurrent or when
the drive currents go
beyond the maximum
specification.
Page 49 of 87
IN CONFIDENCE
Type Description
SUF Start-up The ranging of this When ranging
Failure ONU has failed (see is successful.
ranging protocol for
exact condition).
MEM Message When the ONU

Error receives an unknown
Message message.
DACT Deactivat When the ONU Switch off the laser Reception of Enable
e ONU-ID receives and go to Standby- Upstream_ laser.
Deactivate_ONU-ID State. overhead
Message. It instructs message.
the ONU to deactivate Generate
itself. Loss_of_phy_layer
notification.
DIS Disabled When the ONU Switch off laser. When the ONU Go to Initial
ONU receives a Go to Emergency- receives a State
Disable_serial_ Stop State Disable_Serial
number message with _Number
its own serial number Generate message with
and the enable Loss_of_phy_layer Enable
flag = 0xFF. It stays in notification flag = 0x0F or
this state even after when it
power off. receives a
Disable_
Serial_Number
message with
its own serial
number and
the enable
flag = 0x00.
MIS Link The ONU detects that The ONU
Mismatch the received PST and detects that
ing transmitted PST are the received
different. PST and
transmitted
PST are the
same.
PEE Physical When the ONU Generate When the

Equipmen receives a PEE Loss_of_physical_ ONU does not
t Error Message layer notification receive a PEE
message in 3 s
Page 50 of 87
IN CONFIDENCE
Type Description
RDI Remote When the OLT Set RDI status bit When the OLT Clear RDI
Defect transmission is in PLOu. transmission status bit in
Indication received with defects defect is PLOu
in ONU at the ONU. The resolved
defects include
general failures of the
downstream data
path, including
excessive bit errors
(after FEC), or
corrupted overheads.
Single bit errors are
not considered
defects.
Table 6: G.984.3 Section 11.2.1 - Errors Detected at the OLT
Type Description
Detection conditions Actions
ERRi BIP Error The received BIP-8 is compared The number of differing bits is
of ONUi with the calculated BIP-8 on the accumulated in ERR. SDi and SFi are
received stream. In case of a declared upon BER crossing a
difference, ERRi counter is defined threshold
incremented
REIi Remote Once the ONU detects BIP REIi counter is incremented
Error errors, it sends upstream the accordingly
Indication number of errors inside the REI
of ONUi PLOAM message. When the
received REIi message is
different than zero, REIi counter
is incremented
2.17.3 Optical Supervisory facilities

[R280] Table 7 outlines the optical supervisory requirements, all of which are mandatory.
These have been drawn up and discussed in FSAN within the Optical Supervisory
Task Group in the Optical Access Networks (OAN) Working Group.
Page 51 of 87
IN CONFIDENCE
Measurement Requirement
OLT transmit power (downstream) Mandatory
ONT receive power (downstream) Mandatory
ONT transmit power (upstream) Mandatory
OLT received power per ONT Mandatory

(upstream)
ONT laser bias current Mandatory
OLT laser bias current Mandatory
ONT Transceiver temperature Mandatory
OLT transceiver temperature Mandatory
Drift of ONU transmission window Mandatory
Length from ranging Mandatory
BIP error counts (downstream) Mandatory
BIP error counts (upstream) Mandatory
Discarded Ethernet frames count Mandatory

(downstream) due to CRC errors
and buffer overflow
Discarded Ethernet frames count Mandatory

(upstream) due to CRC errors and
buffer overflow
OLT laser degradation and end of Mandatory

life alarm
Dying gasp alarms (particularly Mandatory

electrical power shutdown, or end of
battery life, [R175]).
Threshold crossing alarms based Mandatory

on above measurements.
Activity on UNI - Voice Mandatory
Activity on UNI Ethernet Mandatory
Table 7: BTs required parameters identified by the FSAN Optical Supervisory Task Group
2.17.4 ONT Commissioning

[R281] On completion of the installation of an ONT, the installer needs to know if the ONT is
functioning correctly. In the first instance use will be made of the power and ONT
status LEDs defined in Sections 4.2.9 and 4.2.15.
2.17.5 OLT Commissioning
[R282] On completion of the installation of an OLT (and any associated separate L2 switch),
the installer will need to know that the OLT is functioning correctly through the use of
vendor supplied commissioning specification and verification documentation. The
EMS will be in place but the PON will not be connected and no CP backhaul will be
Page 52 of 87
IN CONFIDENCE
available. The vendor will need to supply suitable test equipment and facilities to
support the full commissioning of the OLT.
2.17.6 Network Demarcation
The User Network Interface (UNI) ports will form the demarcation point between the customer
and the network.
The requirement to monitor performance at the demarcation points is defined in the Element
Manager SOR. The GPON system is required to support this functionality.
2.17.7 End to End Performance Monitoring
The requirement to monitor performance at the demarcation points is defined in the Element
Manager SOR. The GPON system is required to support this functionality.
2.17.8 Loopback facilities
The requirement for loopback facilities within the GPON equipment to monitor performance at
the demarcation points is defined in the Element Manager SOR, Section 9, Service Testing.
The GPON system is required to support this functionality.
2.17.9 Bandwidth Provisioning and Monitoring
The requirement to monitor bandwidth is defined in the Element Manager SOR. The GPON
system is required to support this functionality.
2.17.10 Ethernet Statistics

Please refer to the embedded Openreach EMS and OSS requirements document for a
complete list of required Ethernet statistics.
2.18 GPON Security
Network operators must be able to assure subscriber privacy and must therefore be provided
with mechanisms to segregate one customers data and management channels from
anothers, and to ensure that customers can be properly identified and authorised for service .
Furthermore, any customer must be prevented from adversely affecting the service provided
to any other customer.
The main risks to Openreachs customers are:
Eavesdropping
Theft of service
Unauthorised modification of data
Network operators must be able to assure the integrity and the availability of the PON, in
terms of fitness for service, and must therefore be able to protect the physical estate,
including fibre, ducts, optical equipment such as splitters/ amplifiers/ regenerators and end
systems from denial-of-service attack. They must also be able to protect PON infrastructure
against any electronic attack.
The main risks to Openreach are:
- physical destruction of fibre, ducts, optical equipment or end systems, e.g. by fire
- destruction of/ damage to OLT by high powered optical source
- electronic attack on OLT or on a management system
- fraudulent use of service
Page 53 of 87
IN CONFIDENCE
While considering the security of GPON networks it is important to keep a perspective relative
to the security of existing networks. The aim of this section is to define Openreachs security
requirements such that the security risks associated with deploying a GPON platform are
either eliminated or reduced to an acceptable level, at acceptable cost. The GPON standards
already include measures to address some of the potential security risks outlined above.
All Openreach systems, Network Elements and supplier Element Managers will be assessed
in line with BTSECS security policies, security standards, Information Assurance and
operational requirements to understand the risks, probabilities and impacts.
[R283] Vendors are requested to state equipment that already has BT security approval.
2.18.1 BTSECS
The BT Security Evaluation and Certification Scheme (BTSECS) is a MANDATORY process

for all BT and Openreach products, services, networks and systems (collectively referred to
as "targets"). The scheme ensures that BT implements appropriate and cost-effective security
by neither spending too much on unnecessary controls or by leaving vital business targets
exposed. For more information on the BTSECS Process see
http://security.intra.bt.com/kzscripts/default.asp?cid=4
[R284] Vendors are requested to provide details of successful BTSECS applications.
2.18.2 GPON Physical Network Security
2.18.2.1 Access to OLT
[R285] A GPON OLT will be housed at a large exchange site, such as a metro node. Hence
an OLT must be provided with the same level of physical security as the Openreach
equipment located in that exchange. Please describe the physical protections
available, and what protections if any exist against attempts to direct a high powered
light source down an attached fibre, from an external location. Please also describe
how optical line cards will fail over, and how any pre-existing load balancing
mechanism will behave, under such an attack.
2.18.2.2 Access to ONT
It is likely that Openreach will deploy several types of ONT.
Outdoor ONT
[R286] An external ONT is fixed to the outside wall of the customers premises. The case
must have a security key to deter unauthorised access though this will only be similar
to the keys used for utility boxes. Please describe mechanisms for protecting the fibre
and connectors against physical access by the customer, either deliberate or
accidental.
Indoor ONT
[R287] This ONT could be wall-mounted or possibly free-standing in the customer premises.
Access to the optical connection should be restricted by the use of tamper resistant
fixings, which will probably take the form of Torx-headed bolts or something similar.
Please describe mechanisms for protecting the fibre and connectors against physical
access by the customer, either deliberate or accidental.
Page 54 of 87
IN CONFIDENCE
Multi-Dwelling Unit (MDU) ONT

An MDU ONT serves several premises in a multi-dwelling unit. This may be located in a
communications room or communications box that will have limited physical security. The
general requirements for an MDU ONT have yet to be specified.
[R288] For an MDU ONT, state details of double door mechanism provided and describe
security features.
2.18.2.3 Craft Terminal
[R289] The provision of a Craft terminal port on the ONT is viewed as providing an
unacceptable level of security risk and hence is forbidden.
Configuration of an ONT must only take place via the OLT, over the PON
2.18.3 GPON Advanced Encryption Standard
[R290] All security requirements defined in GPON standards must be supported, notably the
Advanced Encryption Standard, and key management for AES, as defined in
G.984.3.
2.18.4 End User and ONT Identification/Authentication
GPON standards provide two mechanisms for registering each ONT serial number at the OLT
[R291] Vendor to state support for Method A manual entry to OLT/EMS
[R292] Vendor to state support for Method B auto-discovery by OLT
[R293] GPON standards provide an option to use a password for authenticating the
customer and services provided by each ONT. Vendor to supply details of whether
this is supported and how it could be used to enhance security.
Openreach is currently testing both methods and assessing suitable processes for their use.
[R294] Vendors must state a recommended solution for end user identification and
authentication.
[R295] Vendors should describe what prevents a customer from attaching alternative NTE,
how this would be recorded at the OLT or EMS, and what alarms would be generated.
2.18.5 Separation of Signalling, Management and Media Traffic
One of the major underlying security requirements for Openreachs Converged platforms is
the separation of signalling, management and media traffic. Mechanisms need to be in place
to separate management, signalling, & media traffic within the OLT and ONT.
[R296] Management traffic to and from the OLT must be carried in a dedicated VLAN,
separate from customer data.
[R297] Management VLANs must be completely unaffected by any other traffic on the PON.
Page 55 of 87
IN CONFIDENCE
[R298] The GPON OLT must provide a secure in-band management channel to the EMS via
the OLT SNI interface. Vendors must indicate the bandwidth requirements of the
management channel.
[R299] The GPON OLT must provide a secure separate out-of-band management port to
enable an external management channel to be established via Openreachs DCN.
Vendors are requested to provide details of the management port.
2.18.6 Management Security
Protecting management channels against attackers, recording and generating alarms for
security events, and providing mechanisms for secure transfer of software updates and
configurations is paramount.
Vendors must comply with the OAM security requirements specified in the document in
section 5.1 General EMS & OSS Requirements
[R300] Vendors must support a resilient management VLAN, compliant with the 21C tagging
framework, to the OLT headend component, for remote management of the OLT and
subtended ONT.
[R301] Vendors must provide support for 'last gasp communication between the OLT and
ONT.
[R302] Vendors must describe what out-of-band OLT management options are available
(including Ethernet and serial/console ports)
[R303] Vendors must describe what support exists for secure tunnelling protocols, such as
SSH, IPsec or SSL, on the OLT remote management interface
[R304] State any proprietary protocols used for the management of OLT/ ONT equipment (on
any interface)
[R305] How can traffic on the management ports be rate limited?
[R306] Is it possible to disable specific unused protocols/services, on management

interfaces?
[R307] Is management supported through a firewall? Please provide a list of required ports
and protocols
[R308] For each OLT management interface, what authentication is available? (in-band and
out-of-band, local password on console port etc.)
[R309] For each OLT management interface protocol, what integrity protection is available?
(In-band and out-of-band, for example, keyed hashing of packets.)
[R310] Openreach requires support for either RADIUS and/or TACACS+ authentication (User
Accounts), for both local and remote secure access to the OLT, and remote access to
the ONT, in compliance with standards such as RFC 2865, 2866 and Openreach
DMAS 21 requirements (can be supplied on request)
[R311] Role-based access must be supported on all OLT and ONT management interfaces.
The vendor must support the concept of privilege levels on user accounts, and must
supply details.
Page 56 of 87
IN CONFIDENCE
[R312] Vendors must support at least basic ACLs, covering source address, on both VLAN
and Ethernet/ IP management interfaces on OLT. Are extended ACLs, covering for
example destination address, port and protocol numbers, supported?
[R313] The OLT and ONT must support an audit trail for User Logins, Authentication failures
& Command history (Privileged User)
[R314] The OLT and ONT must support logging of standard management events: Alarms,
Traps & Environmental conditions (details of what constitutes an event, including
security events, to be supplied).
[R315] The OLT must support spooling of log files directly to a remote syslog server, rather
than relaying via the Element Manager. As a minimum, syslog over UDP must be
supported,
[R316] OLT and ONT must support in-service upgrades for firmware, software & security
patches.
Are these controlled by Privileged User? What roll-back features are supported?
What is recorded as part of the audit trail? What is the mechanism for delivering
configs to remote ONT, for example during bootstrapping?
What protocol is used to deliver upgrades?
What minimum bandwidth is required?
[R317] What protection is provided for stored configurations?
[R318] Vendors should describe the protections against direct communication between
ONTs, attached to the same OLT, for example L2 bridge blocking.
2.18.7 Layer 2 Security
Ethernet VLANs are used to provide separation and security for customer traffic and
determine the routing between the ONT and the CP interface.
The VLAN architecture will be point to point. A point to point VLAN has only two member ports
on any one network element. This restricts the forwarding of traffic to be point to point across
a network. Flooding on a point to point network is the same as normal forwarding and so it is
not necessary to learn the location of MAC addresses. This saves network resources
(memory and processing) form maintaining this information and removes exposure to DOS or
spoofing attacks. All services will use point to point VLANs. The VLAN architecture will
therefore create a point to point model, delivering customer connections from an access port
to a VLAN on a CP handover point.
In this architecture, traffic forwarding within the network is based upon VLANs (and not MAC
learning as per traditional Ethernet) and so requires OSS configuration of VLAN forwarding
tables. To achieve the required scalability it must be possible to reuse VLAN IDs across
multiple ports and therefore port isolation is required on the OLT and Layer 2 switch. To
achieve this some requirements are needed at the OLT:
[R319] Port blocking : this feature prevents certain ports from sending packets to other ports
even if they are on the same VLAN. This logic is implemented on the ingress side.
When a packet is received on a port, the OLT performs the normal packet forwarding
function. When a packet is forwarded to another port, it checks the port blocking
status and drops the packet if port blocking is enabled on the egress port.
[R320] MAC blocking : this feature can be used to block a packet with certain Source MAC
addresses from being sent out to specific ports.
Page 57 of 87
IN CONFIDENCE
[R321] Unknown multicast packet blocking : each ingress port can prevent unsolicited
unwanted or unknown multicast packets to certain ports. End users shall be
prevented from sending multicast traffic with the exception of IGMP messages. Even
the IGMP control messages have to be allowed explicitly per VLAN.
[R322] Multicast Storm Control : the number of multicast packets per second must be able to
be limited.
[R323] Broadcast Storm Control : the number of broadcast packets per second must be able
to be limited.
[R324] Limiting broadcast traffic towards subscriber ports. Traffic with an unknown
destination MAC address is not broadcasted towards subscriber ports. Furthermore,
broadcast traffic (e.g., ARP) towards subscriber ports has to be allowed explicitly per
VLAN.
[R325] Limiting broadcast traffic from subscriber ports. Subscribers are only allowed to
broadcast ARP, DHCP and PPPoE requests. Moreover, in many cases, these
requests are either answered by the OLT directly or unicast towards the legitimate
servers.
[R326] Unicast Flooding : the number of unicast packets per second must be able to be
limited.
With regard to the ONT,
[R327] MAC learning must be used to stop traffic that is not destined for transport across the
GPON.
[R328] Vendors are requested to confirm the maximum number of possible entries in the
ONT MAC address table
[R329] Port Isolation: each Ethernet interface must be isolated from the others, so it wont be
possible to transmit traffic from one to other without sending the packets to the CPs.
[R330] Vendors must state the default configuration of a client port, in terms of port
forwarding and VLAN assignment.
2.19 Health & Safety
References for all aspects of health and safety can be found in the BT GS.
[R331] Vendors to confirm compliance with the following specifications:
2.19.1 RoHS (Restriction of Hazardous Substances)
[R332] Known as Directive 2002/95/EC)., originated in the European Union and restricts the
use of six hazardous materials found in electrical and electronic products. All
applicable products in the EU market after July 1, 2006 must pass RoHS compliance.
2.19.2 WEEE (Waste from Electrical and Electronic Equipment)
[R333] Known as Directive 2002/96/EC, mandates the treatment, recovery and recycling of
electric and electronic equipment.
Page 58 of 87
IN CONFIDENCE
2.19.3 Laser Safety
[R334] Hazard Level 1 in accordance with IEC 60825-2 (See 5.1.8).
2.19.4 Electrical Safety
[R335] Compliance with BS EN 61140.
Page 59 of 87
IN CONFIDENCE
3 FTTP Strategic Target Physical layer Architecture

The Openreach strategic target architecture is shown in Figure 11. Extender boxes will be
used to increase the reach to 60km. The 128 split will be achieved by combining 4-way and
32-way splitters as illustrated. Dual parenting will be implemented by two diverse fibre
connections from the 4-way splitter to OLTs located in two geographically separate exchange
buildings. Dual parenting is required to meet service availability targets with increased reach.
WDM couplers at either side of the extender box are required for future NGPON repeaters.
Hand-Over Node #1 End User

1 by 32 Premises
2xWDM
2 by 4 way split
CP1 Extender way split ONT
HO ES OLT Box
CPn
Options for 50ms and

10 second and 30 second End User
switchover. Premises
End User
Hand-Over Node #2 PremisesONT
End User
2xWDM Premises
ONT
CP1 Extender
HO ES OLT Box
CPn ONT
60 km
Figure 11: Extended Reach GPON 60km, 128 way split, dual parented.
The 2 by 4 way splitter and the Extender Box will be located separately.
The WDM coupler associated with the Extender Box will also be located separately.
3.1.1 GPON Optical Reach Extension
A key element of the evolution of the Openreach FTTP deployment is the ability to
significantly extend the power budget of current GPON systems beyond Class B+. This offers
the ability to extend the optical reach to the logical limit of the protocol (60km) and to increase
the split of the PON to use the full address space of 128 ONTs.
Openreach is interested in the capabilities that vendors have today, the maturity of their
thinking and their roadmaps for additional features to enable GPON reach extension.
Mid-span GPON extender
ITU-T SG15 Q2 are currently studying a mid-span GPON extender as shown in figure below.
The following abbreviations are used:
IFD Interface Fiber Distribution

IFT Interface Fiber Trunk
ODN Optical Distribution Network
OTL Optical Trunk Line
Page 60 of 87
IN CONFIDENCE
ONU
UNI Mid-Span
R/S ODN OTL OLT
Extender
IFD IFT S/R SNI
ONU
R/S
UNI
Figure 12: Reference configuration of mid-span GPON extender
[R336] Vendors to describe the status of their development of mid-span GPON extenders,
including any research in this area to date. Provide a roadmap for the support of mid-
span GPON extender boxes and include release plans and details on what
technological developments are necessary to achieve each new capability.
[R337] Vendors are to state whether a mid-span GPON extender has to be paired for use
with GPON ports in a single OLT chassis/shelf/NE or if it will be possible to connect to
ports from another OLT shelf
[R338] The total system fibre length must be configurable on a per OLT GPON port basis up
to 60 km.
There are two possible ways of implementing a mid-span extender:: Layer 0 optical amplifiers
or Layer 1 optoelectronic repeaters. Hybrid approaches are possible in which one
implementation is used for one direction of the GPON and the other implementation for the
other direction.
[R339] The vendor must describe how they will implement a mid-span extender: optical
amplifiers, optoelectronic repeater or a hybrid approach. For the hybrid approach
vendors should indicate which approach is used in which direction.
[R340] With reference to Figure 12 above, vendors are asked to comment on the loss budget
ranges for both the OTL and ODN. The Openreach requirement is the following:
minimum IFD length / 0

km
maximum IFD length / 20
km
minimum IFT length / 0.1
km
maximum IFT length / 60
km
minimum IFD loss / dB 13
maximum IFD loss / dB 32
minimum IFT loss / dB 0.1
maximum IFT loss / dB 32
[R341] Vendors to state their compliance to the above and any dependence on the lengths or
losses in the IFD and IFT
Page 61 of 87
IN CONFIDENCE
Note: The IFD maximum loss and IFT maximum loss are for each individual section and
would not occur simultaneously on the same PON. Similarly, the maximum length of the IFD
and IFT will not occur simultaneously on the same PON.
[R342] Vendors to state whether the use of their GPON extender box will require any
changes to the GPON overhead length i.e. guard band, preamble and delimiter.
Vendors to comment on any impact on efficiency (compared to their conventional
GPON) due to this.
[R343] Vendors to describe their approach to managing the mid-span GPON extender box,
including:
- In-band vs. out-of-band
- Use of OMCI
- Integration with EMS system
- List of managed entities, configurable parameters, alarms and supervision
capabilities
Openreach is interested in deploying mid-span GPON extender boxes in the following

locations:
- Exchange building (central office)

- Underground e.g. manhole or footway box.
- External (street) cabinet
[R344] Describe which of the above deployment locations for mid-span GPON extenders you
intend to support.
In each case, detail:
- Release plans and what technological developments are necessary to achieve each
new capability
- How many GPON extender functions per network element
- Minimum serviceable/replaceable entity
- Physical size of network element
- Power consumption of network element
- Powering options for network element
- Environmental specifications such as operating temperature range, humidity, water
immersion depth etc.
Where a vendor includes an optical amplifier in the upstream implementation of the extender
function:
[R345] Confirm that your current GPON OLT is capable of handling the amplified
spontaneous emission from the optical amplifier. Describe any tests or studies you
have performed to prove this. If your current OLT is not compatible, provide your
roadmap to support this feature and include release plans and details on what
technological developments are necessary.
[R346] State any restrictions on the upstream wavelength range that are imposed by the
optical amplifier based GPON extender box.
Where a vendor includes an optoelectronic repeater implementation of the extender function:
[R347] Provide the jitter transfer characteristics in the upstream and downstream for the end-
to-end GPON link and state how this compares to those without the extender box.
Page 62 of 87
IN CONFIDENCE
[R348] Vendors to outline plans for increasing reach of current GPON system beyond 60 km.
Include any release plans and details on what technological developments are
necessary to achieve this.
3.1.2 GPON Dual Parenting Requirements
Openreach requires high service availability which means that fibre link resilience and
immunity from catastrophic node failures must be provided for FTTP deployments. GPON
standards do not include suitable mechanisms to recover from node failures as this requires
ONTs to be able to communicate back to geographically diverse network nodes. Openreach
proposes to use a Dual-Parenting restoration configuration as illustrated in the figure below.
Figure 13: Illustration of Dual-Parenting restoration implemented via EMS system
This scheme is not defined in current G.984 standards but, nevertheless, can still be
implemented using standards compliant GPON equipment.
Openreach foresees a phased approach to the deployment of Dual-Parenting. In the first

phase, restoration can be implemented on a slow timescale (minutes) using EMS control and
in the second phase automatic, fast (50 ms target) protection defined through standards will
be used.
It is recognised that vendors will not yet have a suitable solution for Dual-Parenting and
GPON. Openreach will want to work with vendors to develop Dual-Parenting solutions.
Openreach expects that vendors will contribute towards the standardisation of an appropriate
solution for fast restoration. The questions below are designed to determine the state of a
vendors thinking in the area of dual parenting and any development plans, as well as
determining how well their current product offering matches the specific requirements we
foresee.
GPON Protection Scheme Implementation Plans
[R349] Provide a description of the current protection mechanisms available for your GPON
system. Furthermore, describe your current roadmap for implementing GPON
standardised protection schemes as described in G.984.x and any development
plans for Dual-Parenting.
EMS driven Dual-Parenting Protection Scheme
Page 63 of 87
IN CONFIDENCE
[R350] As a short term measure, to enable the use of Dual-Parenting protection with
equipment compliant to current GPON standards, Openreach proposes to use a
semi-automatic protection switching mechanism via the vendor EMS system. Briefly,
the approach will use alarms e.g. loss of signal (LoS) on the working OLT GPON port
to detect the failure of a link. Based on this, the EMS will disable this OLT port and
enable a complementary port in the protection OLT. The ONTs will re-range and
establish connections with the protection OLT using a predefined service profile.
Indicate your ability and willingness to support such an approach. If you consider that
you have a better (simpler or faster) approach, then describe your proposed scheme
and indicate the development status of this feature.
In order for the Openreach proposed scheme to work, the following features are required.
[R351] ONTs must be able to be simultaneously registered on two geographically separated

OLTs.
[R352] OLT GPON ports must be able to assert a LoS alarm to indicate that no light is
reaching the OLT from any ONTs on that particular GPON port. Switching will be
based on all ONTs being unreachable and not on any individual ONT communications
failure.
[R353] The OLT that has disabled GPON ports on standby for protection, must still be able to
have ONTs registered on them. Similarly the OLT with working GPON ports must be
able to have these ports deactivated in the event of a failure whilst ONTs are still
registered on them.
[R354] ONTs should have the ability to maintain the service configuration profile assigned to
them in the event of a failover to the protection OLT. Describe the features in your
ONTs that will enable this to happen. In the event of a LoS condition, do your ONTs
lose or delete their service configuration profile? If so, how long will it take to restore
the ONT service configuration profile and indicate under what conditions (timescales)
and whether this could be easily modified?
[R355] Dual-Parenting protection features must work in the presence of a GPON extender
box as the two are planned to be used together.
[R356] In the event of a failover it must be possible to configure the system to manually
revert back from protection OLT to working OLT or to allow this to be automatic.
Manual reversion allows for the switch to be undertaken at a time that minimises
impact on end users and CPs and is a managed process that fits in with repair
schedules and SLAs. Similarly, it should be possible to force a manual switchover in
order to perform some planned maintenance of the system or infrastructure. When
automatic reversion is allowed, appropriate mechanisms must be used to prevent
route flapping that may cause network instability.
[R357] In a Dual-Parented restoration scheme, the OLTs need to have the capability to
continuously check that the non-working path is viable i.e. in the event of a switchover
the system will function correctly. Describe any features of your system that will
facilitate this or any schemes you foresee that could be implemented in a future
release.
[R358] It is undesirable for customers that are not affected by a fault to lose service e.g. if a
GPON OLT port fails, then customers on separate ports on the same card should not
be switched. Ideally, customers on separate ports on the same card should not be
affected if it is the optical OLT transceiver that fails and this needs to be replaced.
[R359] The following contributions are considered to be important in determining the

switching time for Dual-Parenting
Page 64 of 87
IN CONFIDENCE
[R360] For a link failure or port failure on a single OLT GPON port,
- How long does it take the OLT to detect and assert LoS?
- How long does it take for the EMS to be updated with LoS alarm?
- How long does it take to process this alarm and issue request to disable working
GPON port and for this to be acknowledged?
- How long does it take to process acknowledgement and issue the request to enable
the protection OLT GPON port?
- How long will it take for 32, 64 and 128 ONTs to be fully ranged and for Ethernet
services (VLAN connections between UNI to SNI and SNI to UNI) to re-establish?
Note: single vs double tagging may be different
[R361] For simultaneous link/port failures on a multi-port GPON card or card failure,
- How long does it take the OLT to detect and assert 4 x LoS (or card failure)?
- How long does it take for the EMS to be updated with these alarms?
- How long does it take to process alarms and issue request to disable working
GPON ports and for this to be acknowledged?
- How long does it take to process acknowledgement and issue requests to enable
protection OLT GPON ports?
- How long will it take for 32, 64 and 128 ONTs per GPON port to be fully ranged and
for Ethernet services (VLAN connections between UNI-SNI and SNI-UNI) to re-
establish across all 4 PONs?
[R362] Describe any measurements or studies you have performed to determine the total
switching time and breakdown of contributions in a Dual-Parented GPON
deployment.
[R363] Comment on any other important parameters that might impact on the switchover
time in a Dual-Parented protection scheme. For example, would there be any
dependence from the Layer 2 switch or VLAN architecture (e.g., MAC learning or
VLAN based switching, single tagged or double tagged VLANs) or number of uplink
(SNI) ports?
[R364] Openreach may wish to use alarms other than LoS to determine when to switch to a
secondary OLT. Describe any alarms you support on your GPON system that will help
in detecting a failing link.
[R365] Furthermore, outline any other alarms that you think would be useful and confirm your
implementation plans (i.e. in development for release x.y, on a roadmap or no current
plans)
[R366] For the above alarms, please describe any configurable parameters that could be
useful for the Dual-Parenting application e.g. thresholds, measurement windows etc.
[R367] Indicate any alarm filtering or correlation that is performed to ensure an alarm storm
is not generated in, for example, the event of a card failure.
[R368] It is required that the working GPON OLT port does not switch in the event that LoS is
asserted due to a failure in the local power supply to ONTs (e.g. mains power
blackout). Therefore a dying gasp message should be issued by ONTs that can then
be correlated with the LoS alarm to determine if it is appropriate to switch.
[R369] In the event of a catastrophic node failure that renders an OLT unreachable by EMS,
describe how your system will (or is planned) to react to facilitate Dual-Parenting.
Furthermore, describe how partial failures at the node could be handled e.g. if the
EMS and backhaul connections are down, but the OLT PON ports are still functioning.
Page 65 of 87
IN CONFIDENCE
[R370] In the event of a power outage and recovery at the working OLT site describe the
state the OLT GPON ports will be in after power up. How will this impact on Dual-
Parenting protection via EMS? Describe any plans to work around any problems you
foresee.
[R371] As an additional service, Openreach may offer a CP the ability to route around a
switch fault in their backhaul network. This may be done directly by directing Ethernet
uplinks from the working OLT (i.e. active PONs) to the secondary OLT and onwards to
the CP. Describe capabilities in your system that facilitate this. Furthermore, describe
alternative methods for offering this restoration service to CPs.
Fast, Automatic Dual-Parented GPON Protection Scheme
Openreach requires a fast GPON protection scheme to be defined in the G.984 standards
and for this to be implemented by any selected vendor. It is anticipated that this will require a
communications channel to be established between the working and the protection OLTs to
exchange link status and configuration information. The target switch over time in the event of
a link failure would be 50 ms.
Figure 14: Illustration of fast, automatic Dual-Parented GPON protection implemented

through OLT-OLT communications channel.
[R372] Describe any work you have done to date in developing such a protection scheme. It
is accepted that such a scheme will be proprietary at this stage.
[R373] Indicate the expected switchover time for such a scheme and the main contributors to
the switchover time.
[R374] Describe any development plans for a fast switchover scheme and indicate any
efforts to contribute towards standardisation of such a scheme.
[R375] Describe any changes that would have to be made to the functional behaviour of your
current GPON product to facilitate fast link restoration.
[R376] To achieve the 50 ms switchover target, is there any special requirement for the Layer
2 switch in GPON (e.g., L2 switch must be connection-oriented)? Indicate any issues
with your current Layer 2 switch to achieve this switchover time in your GPON.
[R377] Openreach is proposing an Open Access approach that offers Ethernet access
services to multiple CPs to connect to subscribers. In such an environment there
needs to be a mechanism for signalling to CPs which OLT GPON is currently
operational. It is thought that Ethernet OAM could be used to facilitate this process.
Page 66 of 87
IN CONFIDENCE
Describe any plans you have to implement these features on your system and
describe how this could be used to alert CPs of a failure and that a link is operational.
[R378] If Ethernet OAM is not to be implemented, or is not considered to be a good approach

or is not considered sufficient on its own, then describe alternative schemes and
indicate their implementation status, including reference to standardisation work
where appropriate.
[R379] Openreach wishes to understand the technical and commercial viability of a solution
that allows the two OLTs to be operational at once on the same PON and serving
subscribers over a single fibre with a single ONT. This could allow fast protection via
standard layer 2 and layer 3 protocols. Please comment on any such scheme that
you are considering.
[R380] In the event that Openreach deploys equipment from multiple vendors, Dual-
Parenting resilience schemes must interoperate between vendors i.e. the working
OLT could be from vendor A and the protection OLT could be from vendor B. Indicate
your willingness to facilitate such interoperability for both the short term EMS solution
and the fast OLT-OLT communications approach. Indicate any barriers to such
interoperability.
[R381] The above requirement also places a requirement on ONTs to interoperate with both
types of OLT. Describe any interoperability tests that have been performed already
and indicate any features of your products that will facilitate this interoperability.
3.1.3 Next Generation PON (NGPON) Systems
Looking beyond the requirement to extend the reach of GPON to 60 km, Openreach expect
PON technology to continue to evolve in various ways. The purpose of this section is to
understand vendors future roadmaps and how they align with current Openreach thinking on
next generation PON evolution.
Stacked GPON
Openreach would like to be able to upgrade the bandwidth of individual customers on a live
GPON, with no impact on other customers traffic. A way to achieve this is to define additional
wavelength options for GPON and then to build on the concept defined in G.984.5 to stack
multiple GPONs on a single ODN.
[R382] Vendors should describe their ideas and plans to implement stacking of GPONs,
including suggested wavelength plans.
GPON reach extension to 100 km
In the draft standard G.984.re, the ITU-T are studying extending GPON physical reach to 60
km (the current logical reach limit of the TC layer). In order to maximise GPON coverage,
Openreach are interested in subsequently further extending the physical and logical reach of
GPON to 100 km (while retaining 128-way split, 2.4 Gbit/s downstream and 1.2 Gbit/s
upstream bitrates).
A promising option to achieve 100 km reach is to develop a GPON wavelength option in

which both upstream and downstream wavelengths are in the regions above 1530 nm, where
the fibre loss is low and erbium fibre amplifiers are widely available.
[R383] Vendors should describe their roadmap for their TC layer to support logical reaches of
at least 100 km
Page 67 of 87
IN CONFIDENCE
[R384] Vendors should describe their roadmap for their GPON physical layer to support
optical reaches of at least 100 km (via mid-span repeaters or amplifiers if required)
including suggested wavelength plans.
10 Gbit/s PONs
[R385] Vendors should describe their roadmap for a 10 Gbit/s downstream PON with an
upstream rate of at least 2.4 Gbit/s. Describe (including reference material as
appendices where available) research progress to date in this area. Include
descriptions of the architecture, reach/split information, resilience options and
wavelength plans.
[R386] Vendors should describe their roadmap for 10 Gbit/s symmetrical PONs.
Alternative PON technology
While most deployments to date have focussed on TDMA PONs, research into other PON
technologies has been reported. Examples include WDM PONs and CDMA PONs .
Openreach has as yet no firm view on the best technology implementation of such disruptive
PONs, and would in any case look for standardisation prior to deployment. Regardless of
technology implementation, Openreach views the role of these disruptive PONs as delivering
bandwidths well in excess of the capabilities of TDMA PONs: a sustained bandwidth per
customer of ~1 Gbit/s is a target.
[R387] Vendors to describe their research to date into disruptive PONs (including
reference material as appendices where available) and how to upgrade a customer
on a live GPON (with minimal loss of traffic for other customers on the same ODN)
3.1.4 Future Products
Future products are anticipated and may include:
- higher bandwidths
- symmetric bandwidths
- upstream burst capability
- guaranteed delay and jitter limits
[R388] Based on the above, vendors are requested to propose enhancements to the current
products that can be supported by the proposed solution for the above.
[R389] Upstream assured and burst bandwidth for GEA-DP to be implemented using T-Cont
type 3 or type 5.
[R390] Vendors to recommend the used of type 3 or type 5 for GEA-DP and state their
reasons.
[R391] Vendors to state how and where the GEA-DP burst traffic can be policed, shaped and
scheduled both upstream and downstream.
Page 68 of 87
IN CONFIDENCE
3.1.4.1 Multicast
Figure 15 - Multicast in GPON
Openreach may support multicast capabilities in the FTTP GPON system allowing CPs to
offer broadcast services such as SDTV and/or HDTV. The implementation of these multicast
capabilities must be fully compatible with the Openreach design to implement all the other
services. To enable Openreach to develop its design, vendors must answer the following
specific questions, but are also invited to propose an alternative solution. Any alternative
solution must provide at least equivalent functionality and scalability.
[R392] Multicast traffic from one specific CP, e.g. CP A in Figure 15, must be kept isolated
from any other CPs multicast traffic (CP B in Figure 15) and sent to the correct
customers on the correct UNI at the ONT. Those customers who correctly obtain
multicast services from CP A and who havent contracted any multicast service from
CP B must not be able to obtain traffic sent by CP B.
[R393] One single CP could have more than one customer profile, offering different multicast
services for every profile. Openreach is studying different proposals to allow this (i.e.
having the profiles set up by the CP at the CPE, setting different possible multicast
group tables at the ONT, multiple multicast VLAN per CP). Vendors are requested to
explain the options and capabilities of their GPON solutions.
[R394] The OLT must support multiple multicast VLANs. The OLT must allow Openreach to
configure which VLAN(s) is (are) multicast VLAN(s).
[R395] The OLT must be able to receive the multicast streams from one or several multicast
VLANs using a N:1 forwarding model.
[R396] The multicast stream distribution (coming from one or several multicast VLANs) on
the G-PON (from the OLT to the ONTs/ONUs) will be carried out using a single GEM
port (for each IF_PON port) dedicated to multicast streams and which is not AES
encrypted. Consequently, the GEM port dedicated to multicast streams has a
meaning only in the downstream direction. Therefore, IGMP signalling will not be
transported on the multicast GEM port used for the multicast stream distribution.
[R397] For each multicast VLAN, the OLT must allow Openreach to configure the guaranteed
and maximum downstream bandwidth parameters at the GEM port (dedicated to
multicast streams distribution) level.
[R398] For each IF_PON, the OLT must allow Openreach to configure the GEM port
dedicated to transport multicast streams.
Page 69 of 87
IN CONFIDENCE
[R399] The OLT must be able to automatically configure the GEM port dedicated to multicast
streams between OLT and ONTs/ONUs.
[R400] Vendors are requested to comment on the DSL ForumTR-101 proposal for the OLT to
support IGMP v2 and v3 snooping with proxy reporting. There is the option of
supporting this requirement for each multicast VLAN or for all multicast VLANs.
Vendors are also requested to state their understanding of the FSAN and ITU position
regarding this capability.
[R401] For each multicast VLAN, the OLT must provide statistics on all active groups on a
per multicast VLAN and per GEM port basis.
[R402] The OLT must allow Openreach to configure which user GEM ports are members of a
multicast VLAN.
[R403] The OLT must allow Openreach to configure the IP multicast groups or ranges of
multicast groups per multicast VLAN based on Source address matching or Group
address matching.
[R404] For each multicast VLAN, the OLT must be able to configure the maximum number of
simultaneous multicast channels allowed per user.
[R405] The OLT must be able to configure the maximum number of simultaneous multicast
channels allowed per multicast VLAN.
[R406] The ONT must support one or several multicast VLANs using a N:1 forwarding model
for each of them.
IGMP hosts will be connected to the Ethernet UNIs that are members of the multipoint
VLAN(s) that will carry (receive) the multicast frames.
[R407] IGMP hosts must transmitin the same VLAN from which the multicast packet will be
received.
[R408] Each Ethernet UNI must be able to be a member of one CP multicast VLAN if there is
just one VLAN per CP or multiple VLANs if there are more than one VLAN per CP.
[R409] The ONT must be able to learn the Port-ID dedicated to transport multicast streams
that has been configured (automatically or manually) at the OLT.
[R410] Vendors are requested to comment on the DSL Forum TR-101 proposal that for all
multicast VLANs, the ONT will support a single IGMP v2 and v3 transparent snooping
instance. There must be the option of supporting this requirement for each multicast
VLAN or for all multicast VLANs. Vendors are also requested to state their
understanding of the FSAN and ITU position regarding this capability.
[R411] For each multicast Ethernet UNI, the ONT must support IGMP FAST LEAVE i.e. the
ONT stops sending multicast streams at the first IGMP LEAVE message (if there is no
other device connected to this stream on the same port).
3.1.4.2 Contended Products
Openreach are considering the impact of multiple high bandwidth products delivered to 128
customers on a single PON. It may be appropriate for Openreach to offer contended
products in the future. Openreach wish to fully understand GPON system capabilities
available, with and without Connection Admission Control (CAC).
Page 70 of 87
IN CONFIDENCE
For best efforts burst bandwidth, peak burst rates can be specified. Openreach could offer the
following additional statistical bandwidth guarantee:
burst bandwidth greater than X Mbit/s for Y% of time during a busy period
[R412] Please explain whether and how your QoS/scheduling/DBA mechanisms could
implement this additional statistical bandwidth guarantee, both upstream and
downstream.
How would you clamp or restrict the average best efforts burst bandwidth per End User,
without reducing their peak burst rate and without reducing the values of X and Y in the above
statistical bandwidth guarantee? Do you propose any other statistical performance measures
of End-User experience instead of the average best efforts burst bandwidth per End User, to
enforce by clamping? Can you propose any other mechanisms for enforcing a constant End
User experience as take-up and usage rates increase?
In the future it may be desirable to share available assured bandwidth between End Users
subject to CAC, so that an End User can use larger assured bandwidths, i.e. more than their
fair share (GPON BW/PON users) bandwidth (e.g. >20 Mbit/s), for some periods of time.
This would allow them to watch more streamed VoD channels occasionally than their fair
share would allow, and more than a constant assured bandwidth value would allow. Of
course, any bandwidth requests exceeding the minimum assured bandwidth might suffer from
blocking, due to the shared nature of the guaranteed burst bandwidths and concentration.
Under these circumstances Openreach could offer the following statistical guarantee relating
to bandwidth requests:
- Blocking probability
[R413] Vendors must explain whether and how the QoS/scheduling/DBA/CAC mechanisms
could ensure that a defined blocking probability is never exceeded. Please identify
any other statistical bandwidth parameters that it would be possible to guarantee to
the End User, and how.
Furthermore, it might be desirable to enforce a particular blocking probability value at all

times, regardless of the usage levels or PON load, i.e. even at low loads, so that an End
Users experience does not degrade with time as usage rates increase.
[R414] If Openreach were to want to enforce such pre-emptive blocking, how would it be
implemented and managed? Would it be possible to treat pre-emptive blocking of
bandwidth requests for long holding times (i.e. streamed VoD) differently to pre-
emptive blocking of bandwidth requests for short holding times (e.g. fast file
transfers), including no pre-emption for short holding times?
CAC (Connection/Session/File/Bandwidth Admission Control)
In order to provide guaranteed burst bandwidth, i.e. increased assured bandwidths, on

demand, e.g. for the duration of admitted VoD sessions, that exceed a minimum assured
bandwidth and exceed an End Users fair share bandwidth, the following CAC capabilities
are needed.
[R415] Vendors must indicate the ability to support each of the following CAC capabilities:
PON Bandwidth Manager for supporting CAC decisions for inter-CP bandwidth
sharing only, i.e. between all End Users across the entire PON, for increased
Page 71 of 87
IN CONFIDENCE
assured bandwidths, with control plane signalling interface to/from application

servers (VoD, VoIP etc.), CPs and End Users as appropriate
e.g. supported by ETSI TISPAN, ADQ, NGN, RACF/IMS, H323
signalling protocol
What CAC/session signalling protocol do you recommend Openreach should use?
CAC Parameters (minimum):
session ID, session duration, increased assured bandwidth, QoS or CoS
parameter requirements
file ID, file size, increased assured bandwidth, QoS or CoS parameter
requirements
CAC response time (e.g. 0.5 second) How fast a CAC response time would
be possible?
Are there any other parameters you would propose?
CAC policies:
bandwidth sharing policy: inter-CP (all participating End Users across entire
PON)
bandwidth fairness policy:
guarantee blocking probability regardless of offered traffic
any other statistical bandwidth guarantees
control plane interface from PON Bandwidth Manager into Ethernet & PON QoS
mechanisms (including DBA scheduler), in both OLT and ONT
ability to change increased assured bandwidth values, and hence fixed and assured
bandwidth values of T-CONT Types 1, 2 and 3, on demand, subject to CAC decisions
(individual sessions and files)
[R416] What is described in [R415] is a totally new requirement for T-CONTs. Vendors must
state whether the GPON system is able to control fixed and assured bandwidths on
demand from a control plane in this way:
Would it be sufficient for CAC decisions to control (vary) only the Ethernet bandwidth
policers, and keep the Assured Bandwidth of the T-CONT (Type 2 or 3) constant at
the provisioned Peak Guaranteed Bandwidth? How would this work for T-CONT Type
3, whose Non-Assured Bandwidth may need to be allowed to burst to a very high
provisioned peak rate, for long periods of time if surplus bandwidth is available, while
its Assured Bandwidth (provisioned Peak Guaranteed Bandwidth) is supposed to be
limited by L2 policing to smaller bandwidths?
[R417] Vendor must describe how the all of the above CAC capabilities are supported for:
intra-CP bandwidth sharing policy (between a CPs own End Users only)
partial inter-CP bandwidth sharing policy (across a sub-set of CPs)
[R418] Please explain whether the control plane interface from a PON Bandwidth Manager
into Ethernet & PON QoS mechanisms, at both OLT and ONT, should go directly
(e.g. to DBA scheduler and L2 policers), or via the Network Management System
(e.g. Element Manager). Please state the precise routes via Network Management
and directly for L2 policing at the ONT, i.e. how signalling messages are transported
down the PON). Also give the response times achievable for each approach.
3.1.4.3 Point-to-point (P2P) connections
Openreach may in future want to use Ethernet ports on the OLT to provide 1Gbps and
10Gbps P2P links for CPs. This may be done by switching traffic between ports on the same
Page 72 of 87
IN CONFIDENCE
line card, between ports on different line cards or aggregating multiple 1GE ports into a 10G
hub port.
[R419] Vendors must detail how 1 GE and 10GE P2P links may be switched through the
OLT. Please detail any capacity limitations (such as backplane throughput, number of
ports per card, maximum frame processing capacity etc)
Page 73 of 87
IN CONFIDENCE
4 FTTC High Level Requirements

Openreach is considering Fibre To The Cabinet (FTTC) solutions to deliver a Generic
Ethernet Access product set similar to FTTP. Three potential deployment scenarios are
shown in Figures 16 to 18 below.
Cutover provides all connections from a PCP with a DSL port and voice over copper to the
exchange is disabled.
Overlay provides those customers that request GEA products a connection to a DSL port and
voice continues to be supported over copper from the exchange for all customers. The
termination of fibre backhaul from the cabinet is envisaged at Openreach Handover Points co-
located with FTTP Handover Points and therefore a maximum distance of 80km is envisaged
to provide geographic coverage. The termination of the backhaul at the exchange will be
made on Ethernet Switches so that the interface to CPs is at L2 in a similar way to FTTP
GEA. For cutover dual parenting is provided to ensure resilience of voice (VEP), whilst in the
overlay single parenting is required to support the data product.
Figure 16: FTTC Cut-over scenario.
Figure 17: FTTC Overlay scenario
Page 74 of 87
IN CONFIDENCE
Hand-Over Node
Ethernet WDM
Sw OLT Remote Cab PCP
CP1 Extender box End User
HO / 4 way split
CPn OLT ONT
ONT Premise
D-Side Copper VDSL2
Port 1
DSLAM
2 way split modem
NTE5 SSFP
PSU Port 4
ONT
1 km
Figure 18: FTTC Overlay low take up (<10%)
[R420] Any vendor proposing an FTTP solution must also be capable of delivering a FTTCab
solution that enables the deployment of active electronics in the external network to
operate VDSL2 and ADSL2+ transmission over the D-Side network for the three
scenarios above.
[R421] Vendors must give a full description of the proposed solution for each of the above
scenarios, including the options for the line capacity and physical housing for the
remote electronics.
[R422] Vendors must give a committed product roadmap for each scenario.
[R423] Vendors must state availability of equipment for a trial of each scenario.
[R424] All solutions must be supported on the same Element Management system as FTTP.
[R425] All solutions must support optical 1GE and 10GE interfaces for CP handover.
Vendors to state the reach capabilities of the optical interfaces. Further requirements
are specified in Section 5.4 (Appendix 4 FTTC Requirements)
[R426] Vendors must provide compliance statements for the requirements in Appendix 4
FTTC Requirements, including a summary compliance table as described in section
1.
Page 75 of 87
IN CONFIDENCE
5 Appendices
5.1 Appendix 1 - Standards Documents
The following specifications and other references contain provisions, which, through reference
in this text, constitute provisions of this specification. At the time of issue, the editions
indicated were valid. All specifications and other references are subject to revision; users of
this specification are therefore encouraged to investigate the possibility of applying the most
recent edition of the specifications and other references listed below, unless otherwise stated.
Alternative specifications where appropriate are given in italics. Specifications given in bold
italics are property of BT.
5.1.1 BT GS (Generic Standards)
The GS are available via BT Procurement and Supply Chain. The website
http://www.selling2bt.bt.com/ provides links for suppliers on BTs core requirements and
provides additional information from the procurement team.
5.1.2 Ethernet Specifications
ISO/IEC 11801 2nd Information technology Generic cabling for customer premises
Edition 2002
BS EN Information technology Generic cabling systems Part 1: General
50173-1:2002 requirements and office areas.
IEEE Std 802.3u- IEEE Standards for Local and Metropolitan Area Networks:
1995 Supplement to Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications Media
Access Control (MAC) Parameters, Physical Layer, Medium Attachment
Units, and Repeater for 100 Mb/s Operation, Type 100BASE-T (Clauses
2130).
IEEE Std IEEE Standards for Local and metropolitan area networksVirtual
802.1Q, 2003 Bridged Local Area Networks.
Edition
IEEE Std IEEE Standard for Local and metropolitan area networks Media Access
802.1D- 2004 Control (MAC) Bridges.
IEEE Std 802.3af DTE Power via MDI Isolation
-2003
IEEE Std 802.3ah Ethernet in the First Mile
IEEE Std 802.1ag Connectivity Fault Management
ITU-T Y.1731 OAM functions and mechanisms for Ethernet based networks
IEEE Std 802.3u Fast Ethernet
IEEE Std 802.3z Gigabit Ethernet
IEEE Std 802.1ad Standardised method for stacking VLAN tags (QinQ)
IEEE Std 802.3 Carrier sense multiple access with collision detection (CSMA/CD)
access method and physical layer specifications
RFC 3376 IGMP v3 (Release 2.0)
RFC 792 INTERNET CONTROL MESSAGE PROTOCOL
IEC 60603-7-4 Connectors for electronic equipment Part 7-4: Detail specification for
8-way, unshielded, free and fixed connectors, for data transmissions
with frequencies up to 250 MHz
5.1.3 Environmental Specifications
ETSI EN 300- Environmental Engineering (EE); European telecommunication standard

119-5 for equipment practice; Part 5: Thermal management.
ETSI EN 300 Environmental Engineering (EE); Environmental conditions and
Page 76 of 87
IN CONFIDENCE
019-1-3 environmental tests for telecommunications equipment; Part 1-3:

Classification of environmental conditions; Stationary use at weather
protected locations.
BS EN 60950- Information technology equipment-safety Part 1: General requirements
1:2002
BS EN 60529 Degrees of protection provided by enclosures (IP code)
5.1.4 ITU-T BPON Specifications
G.983.2 ONT management and control interface specification for B-PON

5.1.5 ITU-T GPON Specifications
G.984.1 Gigabit-capable Passive Optical Networks (GPON): General

characteristics
G.984.2 Gigabit-capable Passive Optical Networks (GPON): Physical Media
Dependent (PMD) layer specification
G.984.2 Amendment 1: Appendix III Industry best practice for 2.488 Gbit/s
downstream, 1.244 Gbit/s upstream G-PON
G.984.3 Gigabit-capable Passive Optical Networks (G-PON): Transmission
convergence layer specification
G.984.3 Amendment 1
G.984.3 Amendment 2
G.984.3 Implementers Guide for ITU-T Rec. G.984.3
G.984.4 Gigabit-capable Passive Optical Networks (G-PON): ONT management
and control interface specification
G.984.4 Amendment 1
G.984.4 Amendment 2
(Prepublished)
G.984.5 Enhancement band for GPON
5.1.6 Electrical Specifications

1:2002
BS EN 55022 Information technology equipment Radio disturbance characteristics
Limits and methods of measurement
BS EN Electromagnetic compatibility (EMC) Part 3-2: Limits Limits for
61000-3-2 harmonic current emissions (equipment input current up to and including
16 A per phase)
ETSI EN 302 Environmental Engineering (EE); Powering of equipment in access
099 V1.1.1 network
BS EN 55024 Information technology equipment Immunity characteristics
Limits and methods of measurement
ETSI EN 300 Electromagnetic compatibility and Radio spectrum Matters (ERM);
386 V1.3.3 Telecommunication network equipment; ElectroMagnetic Compatibility
(EMC) requirements
BS EN Electromagnetic compatibility (EMC) Part 4-7: Testing and
61000-4-7 measurement techniques General guide on harmonics and
interharmonics measurements and instrumentation, for power supply
systems and equipment connected thereto
IEC 60320-1 Appliance couplers for household and similar general purposes.
Part 1: General requirements
BS EN Protection against electric shock Common aspects for installation and
61140:2002 equipment.
BS1363-3: 1995 13 A plugs, socket-outlets and adaptors. Specification for adaptors
5.1.7 Fire Protection Specification
Page 77 of 87
IN CONFIDENCE

1:2002
5.1.8 Optical Connectors, Lasers & Fibre Specifications
ITU-T G.652 Characteristics of a Single-Mode Optical Fibre and Cable

BT CW1505 Step Index Singlemode Optical fibres
Issue 12
CW 1802 TERMINATIONS OPTICAL 8001C/..m AND SC/..m
IEC 60874-14-9 Connectors for optical fibres and cables Part 14-9: Fibre optic connector
type SC-APC tuned 8 terminated on single mode fibre type B1 Detail
specification.
IEC 60825-2 Safety of laser products Part 2: Safety of optical fibre communication
systems (OFCS)
RC 9310 BRITISH TELECOMMUNICATIONS PLC SPECIFICATION RC 9310 FOR
CONNECTOR OPTICAL FIBRE SC
BS IEC Connectors for optical fibres and cables Part 14-3: Detail specification
60874.14.3 for fibre optic adaptor (simplex) type SC for single-mode fibre
RC 9341 SPECIFICATION RC 9341 FOR PROTECTOR SPLICE 5
EPT/COF/D861 Cleaning Of Optical Fibre Connectors
5.1.9 Additional Reference Documents
DIRECTIVE 2002/95/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27

January 2003 on the restriction of the use of certain hazardous substances in electrical and
electronic equipment
DIRECTIVE 2002/96/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27

January 2003 on waste electrical and electronic equipment (WEEE)
Directive 89/336/EEC COUNCIL DIRECTIVE of 3 May 1989 on the approximation of the laws
of the Member States relating to electromagnetic compatibility
5.2 Appendix 2 Definitions
Bend Tough, but flexible tubing, which cannot be bent greater that a 30mm radius
Limiting Tube to comply with fibre bend radii for G.652 fibre. Contact the author for more
information.
Commission Green = Voice and / or data mapping parameters configured and set.
Status LED Red = No voice or data parameters set.
CPE Customer Premises Equipment. This encompasses the wide range of

customer equipment ranging from basic telephones to complex data and
voice networking equipment.
Downstream The Downstream traffic flow is from the OLT to ONT. This is at 1490nm.
Helpdesk An Openreach centre for technical support providing information and

assistance to customers of the GPON system.
ODN Optical Distribution Network. This ranges from the optical connector within
the exchange at the OLT to the optical connector at the ONT.It utilises
passive optical components.
Page 78 of 87
IN CONFIDENCE
OLT Optical Line Termination. This is provides the access network-side interface
and is connected to one or more ODNs. The core-side interface provides
connectivity to the core telecommunications network.
ONT Optical Network Termination. This concludes a device, which has both ODN
termination and CPE termination ports.
PON LED Green = ONT synchronised with OLT.

Green/Red Flashing = Optical power detected but no grant from OLT,
therefore the ONT is unable to communicate with the OLT.
Red: = No optical power detected.
Power LED Green = Power on.

Off = No power.
RJ45 Registered Jack 45 Electrical Connector used as for Ethernet 10-BASE-T

and for ISDN2 line jack-plug.
Upstream The Upstream traffic flow is from the ONT to OLT. This is at 1310nm.
5.3 Appendix 3 Abbreviations
A.C.: Alternating Current MDI-X: Media Dependant Interface

Crossover
ALLOC-ID: Allocation Identifier
MDU: Multi Dwelling Unit
BER: Bit Error Rate
MSAN: Multi-Service Access Node
BLT: Bend Limiting Tube
NGA: Next Generation Access
BPON: Broadband Passive Optical Network
NMS: Network Management System
BS IP: British Standards International
Protection OAM: Operations Administration and
Maintenance
BT GS: British Telecommunications Generic
Standards ODN: Optical Distribution Network
CBR: Constant Bit Rate OLT: Optical Line Termination
CoS: Class of service OMCI: ONT Management and Control

Interface
CPE: Customer Premises Equipment
OMCC: ONT Management and Control
CSP: Customer Splice Point Channel
CTP: Connection Termination Point ONT: Optical Network Termination
D.C.: Direct Current OTIAN: Optical Telecommunications

Infrastructure for the BT Access Network
DSP: Digital Signal Processor
PLOAM: Physical Layer Operations
ETSI: European Telecommunications Administration and Maintenance
Standards Institute
PM: Protocol Monitoring
FMSAN: Fibre Multi-Service Access Node
Page 79 of 87
IN CONFIDENCE
PON: Passive Optical Network

FTTP: Fibre to the Premises
ppm: parts per million
FSAN: Full Service Access Network
PSU: Power Supply Unit
GAL: GEM Adaptation Layer
QoS: Quality of Service
GEM: GPON Encapsulation Method
RoHS: Restriction of Hazardous Substances
GFP: Generic Framing Protocol
RTOS: Real Time Operating System
GMII: Gigabit Media Independent Interface
SIP: Session Initiation protocol
GPON: Gigabit-capable Passive Optical
Network SLAC: Subscriber Line Access Controller
GS: Generic Standard SLIC: Subscriber Line Interface Controller
ICMP: Internet Control Message Protocol SoC: System on Chip
IP: Internet Protocol T-CONT: Transmission Container
ITU-T: International Telecommunications TDM: Time Division Multiplexing

Union Technology
UNI: User Network Interface
LED: Light Emitting Diode
VLAN: Virtual Local Area Network
MAC: Media Access Controller
WEEE: Waste from Electrical and Electronic
MDI: Media Dependant Interface Equipment
5.4 Appendix 4 FTTC Requirements
The following details are provided to set the context of Openreachs investigations into FTTC.
Suppliers are requested to provide detailed responses to the following requirements to aid
Openreachs evaluation of the capabilities and opportunities for FTTC deployment.
The information provided will be used to support the formal requirements in section 4 of the
main document.
A separate compliance summary table must be provided for responses to this appendix.
Requirements in this appendix have been denoted by [AR1], [AR2] etc, to distinguish them
from the requirements in the main part of the document.
FC,PC,NC or IO responses for these appendix requirements must not be included in the
summary compliance table for the main part of the document.
Technical Solution
Openreach is evaluating the deployment of an FTTC architecture to deliver Generic Ethernet
Access products similar to those being delivered over FTTP.
FTTC architectures are being considered for both existing network overlay and cut-over
deployment.
The products supported will be based on the GEA product set with L2 CP interfaces in the
exchange and L2 interfaces on the end user NTE. A minimum of 1 VLAN per NTE Ethernet
port must be supported. The GEA VEP product is provided for the cutover scenario only, as
existing PSTN over copper to the local exchange is maintained for the overlay scenario.
Page 80 of 87
IN CONFIDENCE
Where FTTC is deployed as a cut-over, all End Users served from a particular PCP Cabinet
will be migrated to a GEA only product set.
The Network Termination equipment is expected to replicate the GPON ONT but with the
Fibre interface replaced by a VDSL2 / ADSL2plus interface which is interoperable with
VDSL2 / ADSL2plus equipment under Access Network Frequency Plan (ANFP) conditions
(Parts B and C).
AR[1] The solution must support suitable line interfaces in a suitable Street Cabinet.
AR[2] PSTN Line Circuits must not be deployed in the cabinet. Traditional PSTN will not be
part of the cabinet solution.
AR[3] In cutover deployment, the solution will not support traditional PSTN service delivery
over the copper pairs.
AR[4] Where the solution is an Overlay, the PSTN will be delivered from Exchange over the
existing copper pair and integrated with the DSL signal via the POTS splitter in the
Cabinet based DSL line Circuits.
To minimise the impact of home wiring on the performance of VDSL2 technology, the current
view within Openreach is that, within the Customers Premises, Service Specific NTE front
plate based filters will be used rather than micro-filters.
AR[5] The Street Cabinet will require end user Line Test Support capability, either via use of
SELT/DELT or TAM/ Test head. Vendors to state their solution.
AR[6] In a network overlay scenario the Street Cabinet will not be equipped with Battery
Backup but space for batteries should be included in the design. In a network cut-over
scenario the street cabinet will require a 5 hour Battery Backup capability.
AR[7] N+1 redundancy on the Mains to DC converters must be provided.
AR[8] The system will be managed by the GPON Element Manager.
AR[9] For an overlay deployment, the Element Manager system will need to recognise FTTC
installations and be capable of setting the Line Circuit profiles to specific CAL Values to
meet the ANFP (all Lines on a particular street cabinet will be set to the same CAL
Value).
General DSL Line Interface Requirements

AR[10] The Line Card must offer VDSL2 and ADSL2plus in ANFP Street Cabinet Mode
ideally from the same line card, or a separate line card in the same Cabinet.
AR[11] The line card must be able to auto negotiate with the active NT modem in the End
User premises on which standard to train-up to.
AR[12] The line card should be able to be set a limit on technology i.e. not allow VDSL or
ADSL1, but allow ADSL2plus (G.992.5) or VDSL2 (G.993.2) in ANFP Part B mode.
AR[13] Upstream Power Back-off (UPBO) must be implemented for VDSL2
AR[14] The line card must support a full POTS splitter so that baseband telephony can be
filtered. ETSI Splitter Option B is preferred.
The splitter does not need to be integrated with the Line Card but must be included within the
solution.
Page 81 of 87
IN CONFIDENCE
AR[15] The Line Card must be protected from Over voltage and LEMP conditions on the E-
Side or D-Side cables.
AR[16] Power consumption will be a key issue. Please state the Power consumption and
dissipation per DSL port for the different operational states. Please describe any power
reduction features available now or planned for the future. Please state compliance to
the EU CoC V2 (July 2007)
AR[17] In Cutover Mode the line circuits must supply wetting current typically 3mA
AR[18] In Overlay Mode the Line Card must not prevent the operation of the PSTN Service
under fault and power fail conditions
AR[19] The Line circuit must be capable of being protected from Over voltage and LEMP
conditions on the E-Side (in overlay mode) and D-Side cables.
AR[20] The Line circuit must be protected from Over voltage and LEMP conditions on the D-
Side cables.
AR[21] The DSL system must support tone set A43C as defined in ITU-T Recommendation
G.994.1 Amendment 1.
AR[22] The solution must support gathering of transmission statistics, such as errored
seconds, retrains etc. and reporting via the EMS
AR[23] The solution must support recalculation of the quiet line noise and line insertion loss
metrics at every retrain and collection of this data by a central management system.
VDSL2 Line Interface

AR[24] The VDSL2 line card must be capable of supporting VDSL2 in ANFP Street Cabinet
Mode (Part B) over all CAL values defined in the ANFP Part B. This implies support for
VDSL2 band plan 997, profile 8c as defined in Table 6-1 of ITU-T Recommendation
G.993.2. This requires the use of PSD shaping as defined in ITU-T Recommendation
G.997.1.
AR[25] For VDSL2 the noise model to be used for distributed noise testing is to simulate the
effects of an ensemble of interferers operating in the same binder group. This
ensemble comprised 12 exchange based ADSL2plus, 6 ISDN BRA, 1 HDSL 2-pair and
1 HDSL 3-pair interferers plus 12 cabinet based VDSL2 interferers (i.e. VDSL2
Stockholm Lite). The cabinet based VDSL2 interferers should be shaped for each
specific CAL value as per the ANFPi3. As this distributed interferer will vary with length,
different noise models should be used for each cable length. Noise should be injected
at both the cabinet end and at the customer end of the link. The system should
additionally be tested without noise.
AR[26] For VDSL2 operation the system must be capable of performing multiple RF notching
over those radio amateur bands which fall within the frequency range from 1.8 7.05
MHz if required.
AR[27] For VDSL2 operation, the system must be capable of implementing UPBO in band
US1. It must be possible for the operator to control the Electrical Length parameter kl0
per port. The system mustl also be capable of autonomous estimation of the Electrical
Length kl0.
AR[28] It must be possible to program the VDSL2 line card to operate with either fixed rate
profiles, such as 10Mbit/s downstream, 2 Mbit/s upstream for GEA, or with rate
adaptive profiles.
Page 82 of 87
IN CONFIDENCE
AR[29] The DSL line cards must support gathering of transmission statistics, such as errored
seconds, retrains etc.
AR[30] The line cards must support recalculation of the quiet line noise and line insertion loss
metrics at every retrain and collection of this data by a central management system.
ADSL2plus Line Card

AR[31] The line card must be capable of supporting ADSL2plus in ANFP Street Cabinet
Mode (Part B) over all CAL values defined in the ANFP Part B. This requires the use of
PSD shaping as defined in ITU-T Recommendation G.997.1.
A specific opportunity for FTTC solutions is to address parts of the network that cannot get
broadband either due to the copper network topology resulting in very long cable lengths or
the use of multiplexers in the access network that are incompatible with DSL delivered
broadband. In the majority of cases the reason the multiplexers were deployed was to
overcome reach limitations of the copper network for the PSTN. Hence, for this application,
the majority of the Cabinets will be placed at PCPs with very long E-sides / very high CAL
values. Openreach requires the best possible rate reach performance consistent with
compliance with the ANFP.
AR[32] For ADSL2plus the noise model to be used for distributed noise testing is to simulate
the effects of an ensemble of interferers operating in the same binder group. This
ensemble comprised 10 exchange based ADSL2plus, 6 ISDN BRA, 1 HDSL 2-pair and
1 HDSL 3-pair interferers plus 10 cabinet based ADSL2plus interferers (i.e. ADSL2plus
Stockholm Lite). The cabinet based ADSL2plus interferers should be shaped for each
specific CAL value as per the ANFPi3. As this distributed interferer will vary with length,
different noise models should be used for each cable length. Noise should be injected
at both the cabinet end and at the customer end of the link. The tests are to be
performed for 2Mbit/s and 500kbit/s service profiles and for a 6dB target margin fully
rate adaptive service profile, with interleaving enabled using INPmin=2 and dMax=8
D/S and INPmin=0.5 and dMax=8 U/S, using simulated lengths of 0.5mm gauge cable.
The system should also be tested in the absence of simulated crosstalk.
AR[33] The line circuits should be able to be set a limit on technology i.e. not allow ADSL1,
but allow ADSL2plus in ANFP Part B compliant mode.
AR[34] For ADSL2plus operation the system must be capable of performing RF notching
over the frequency range from 1.8 - 2.204 MHz if required.
AR[35] The ADSL2plus system must also be capable of implementing the full range of
optional framing parameters defined in ITU-T G.992.5 and all subsequent corrigenda
and amendments.
Street Cabinet
The solution must meet legal requirements, be safe and be fit to operate for 25 years.
The requirements below identify Openreachs current view of the requirements for Street
Cabinets to house active electronics. Openreach has been working with its cabinet Vendors
on a Modular Street Cabinet Design for Street Electronics. Whilst this work is incomplete,
these requirements reflect the latest thinking.
This Section outlines the requirements for an electronics enclosure. These would be located
outside and above ground. Solutions for deploying small line capacity (<36 lines) remote
active units in underground chambers (footway boxes) are also being considered.
AR[36] The cabinet should be as small as is practicably possible.
AR[37] The maximum footprint size will be 1.5 m2 as given in The Town and Country
Planning Act (Part 24 General Permitted Development Order) (GMDO).
Page 83 of 87
IN CONFIDENCE
AR[38] Excluding the root (plinth), the maximum height of the cabinet must be 1.6m. This
height is seen to be the maximum acceptable. No access aids must be required to
allow full working access to all operational areas of the cabinet.
AR[39] The maximum depth of the cabinet must be 450 mm. This depth is considered
acceptable to the vast majority footpaths.
AR[40] There must be no access to the cabinet from the rear
AR[41] Electrical installation must be in accordance with the street furniture requirements of
BS 7671:2001 (IEE Wiring Regulations Sixteenth Edition).
AR[42] Any materials can be used for the cabinet (shell, base and internal components) that
can be shown to meet the environmental and operational requirements. The material
must not be flammable.
AR[43] Stainless steel is likely to be suitable. Aluminium alloy is unlikely to provide sufficient
protection against physical damage or arson attacks. The gauge of the material used
must be suitable to meet the environmental and operational requirements.
AR[44] The colour must be green, No. 223 of BS 381.
AR[45] If a coating is used on the shell it must be capable of a 25-year service life in both
inland and coastal polluted environments. It must also be resistant to graffiti.
AR[46] The housing must meet all security requirements detailed in the current issue of LN
413.
AR[47] The cabinet will be expected to have a life expectancy of at least 25 years, with
minimal maintenance.
AR[48] The electronics must consist of field replaceable units to enable rapid restoration of
service following an electronics fault.
AR[49] Cabinet design must allow all ducts to be sealed.
AR[50] Incoming mains cable must enter the cabinet though a separate duct.
AR[51] The Cabinet will need to provide, close to the incoming duct for the main cable, a
plywood backboard within the cabinet to accommodate the LEC equipment. There
must be sufficient space for a LEC breaker/fuse.
AR[52] The mains supply will need to be of type TNS or TNCS (PME) to allow a safe
operation without the use of a residual circuit breaker.
AR[53] Mains power outlets must not be provided.
AR[54] Please detail the power requirements for your FTTC solution for a fully loaded and
partially loaded scenarios. Please include:-
a. Any power associated with environmental management,
b. Difference between Active Lines and non active
c. Details of any power conservation features for a deployment
AR[55] The system must have an option for a five hours battery backup in order to support
service provision during power outages. The design mustl, as an option, allow some
cabinets to be installed without battery backup.
Page 84 of 87
IN CONFIDENCE
External Cabinet Environmental

AR[56] For above ground cabinets the equipment is required to continue to operate normally
under any demonstrably feasible combination of conditions contained within ETSI
specification ETS 300 019 Part1 Category 4.1 with the following exceptions and
limitations:
High air temperature reduced from +40C to +35C
To allow for solar gain a high air test temperature of +50C should be assumed.
Low air temperature increased from -33C to -20C
To allow for heat irradiance into the night sky a low air test temperature of -32C
should be assumed.
It is understood that active cooling of the cabinet will be required. This must require
minimal maintenance.
Ability to operate during and after earthquake conditions is not applicable.
External Cabinet Security

AR[57] The housing must allow all power equipment to be suitably secured to avoid
unauthorised access.
AR[58] During its lifetime the cabinet is likely to experience deliberate attacks by vandals and
accidental blows from vehicles. Repairs to the cabinet must be expedited by the
provision of replaceable doors, a replaceable roof and a shell that can be replaced
without disturbing the base or the internal equipment.
AR[59] Every cabinet panel must be removable and replaceable when the cabinet is in
service.
AR[60] The cabinet must be able to resist impacts and compressive forces as specified in
LN413. Following these tests the cabinet must remain both:
i) Watertight to BS EN 60529 Classification IP55 and,
ii) airtight, giving a pressure excess of at least 14mm head of water for a 4
litre/minute air supply.
AR[61] All doors must incorporate BT high security locks.
AR[62] Openreach will agree an acceptable lock arrangement.
AR[63] Openreach requires the vendor to integrate the electronics necessary to facilitate the
access control mechanisms
AR[64] Vendor to provide the cabinet with sensors attached to it in order to provide power,
environmental and security alarms.
AR[65] Openreach require the Vendor to co-operate in how and where the Access Control
and environmental alarms would connect through to BT systems and communicate with
them, in order to provide security and power alarm management from the Street
Cabinets.
EMC
AR[66] The Cabinet solution, including all equipment supplied by the vendor, must be CE
Marked. As the Cabinets maybe positioned close to residential homes ETSI 300 386
Class B is required.
Acoustic Noise.
AR[67] Openreach is considering setting a target for the max acoustic emission limit for its
active street cabinets to 40 dBa during the day and 35 dBa at night with the aim to
realise this target as soon as is reasonably practicable.
Page 85 of 87
IN CONFIDENCE
Test & Diagnostics

AR[68] The system must provide suitable additional Environmental alarms to enable
Openreach to maintain the Street Located equipment. As a minimum the system must
include :-
i. Door Open Alarm on every door that can be opened.
ii. Over Temperature Alarm Value to be agreed with Openreach
iii. Incoming mains power fail alarm
AR[69] The following data items, as specified within the ADSL standards, is to be collected by
and available from the Element Manager:-
i. Aggregated in-section loss by recording Tx and Rx powers at each
end
ii. S/N Margin (U/S & D/S)
iii. Bit allocation table (U/S & D/S)
iv. Bit rate (U/S & D/S)
v. Profile in use
vi. CRC errors (U/S & D/S)
vii. Initialisations
viii. ES & SES (U/S & D/S)
ix. Max achievable speed (U/S & D/S)
x. Fine gain adjust keeps S/N ratio constant (U/S & D/S)
xi. Modem up time
AR[70] The following data items, as specified within the VDSL2 and ADSL2plus standards,
is to be collected by and available from the Element Manager:-
i. Quiet noise (with respect to frequency)
ii. Insertion loss (with respect to frequency) i.e Hlin and Hlog
AR[71] The following data items, as specified within the VDSL2 standard, is to be collected
by and available from the Element Manager:-
i. Estimated Electrical Length kl0 for UPBO control US and DS
Backhaul Requirements
AR[72] The FTTC system will need to support point to point backhaul connectivity for single
GE, up to 3 GE and a 10GE interface.
AR[73] The FTTC system must be capable of supporting resilient backhaul (dual parenting).
AR[74] The FTTC system may need to support a GPON FTTP backhaul connectivity via an
ONU.
References
1. Specification of the Access Network Frequency Plan applicable to transmission
systems connected to the BT Access Network, NICC Document ND1602:2005/08.
2. ITU-T Recommendation G.992.5 (01/2005) Asymmetric Digital Subscriber Line
(ADSL) Transceivers - Extended Bandwidth ADSL2 (ADSL2+)
3.] ITU-T Recommendation G.993.2 (02/2006) Very High Speed Digital Subscriber Line
Transceivers 2
4. ITU-T Recommendation G.994.1 Handshake Procedures for Digital Subscriber Line
(DSL) Transceivers
Page 86 of 87
IN CONFIDENCE
6 Acknowledgements
The author wishes to acknowledge input from the following colleagues.
Name BT Line of Business

Eduardo Urzaiz BT Design
Ken Cobb BT Design
Mike Halls BT Design
Colin Hauge BT Design
Simon Fisher Openreach
Martin Whiting Openreach
Ramesh Haval BT Design
Geoff Hodson BT Design
Russell Davey BT Design
Derek Nesset BT Design
Dave Thorne BT Group CTO
Martin Moore BT Design
Nick Medlen Openreach
Steve Moore BT Design
Alan Hill BT Design
Dave Collier Openreach
Andy Skinner BT Design
< End of Document >
Page 87 of 87
IN CONFIDENCE

Nga Appendix02 Final - BT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nga Appendix02 Final - BT

Uploaded by

Copyright:

Available Formats

IN CONFIDENCE

FTTP Technical Requirements Reference:GPON/0005/JB

Openreach Invitation To Tender

British Telecommunications plc, 2008. All rights reserved.

All third-party trademarks are hereby acknowledged.

Revision Author Date Notes

Issue 1 Joe Brannan 15/01/08 Formal issue following review.

Distribution will be controlled by:

Name: Joe Brannan

Enquires about the technical content should be directed to Joe Brannan.

2.13.19 System Requirements.......................................................................................38

Requirements are denoted by the form: (Rx).

Full Compliance Partial Compliance Non Compliance Information Only

Ra, Rb, Rc, Rd Re, Rf, Rg Rh, Ri Rj

Total FC=4 Total PC=3 Total NC=2 Total IO=1

Subject to satisfactory responses, Openreach may choose to invite a vendor or vendor(s) to

Management and OSS

1.2 Standards Compliance

[R1] Compliance with all standards listed in Appendix 1 Standards Documents, is

1.3 Alignment with UK Telecommunications Strategic Review (TSR)

"Equivalence of Inputs" or "EOI" means that BT provides, in respect of a particular product or

2 Initial FTTP System Requirements

Figure 1: Upstream and Downstream definition

2.1 FTTP Architecture using the current standard GPON

Figure 2 - FTTP Standard GPON Architecture

[R13] Vendors to state the maximum number of GPON per card.

2.2 GPON Bit Rates & Optical Budgets

Hand-Over Node End User

Figure 3 - GPON future proofing for migration to NGPON

ONU laser type ONU transmitter wavelength Relative ONU price

SLM single longitudinal mode laser

Items Unit Single fibre

Items Unit Single fibre

2.3 Generic Ethernet Access Products

Openreach intends to launch a range of GEA products:

CP1 GEA ATA

Openreach product from R to S

Figure 4 Generic Ethernet Access Products

2.3.1 GEA Voice Enablement Product (GEA-VEP)

[R30] Vendors to state how downstream GEA-VEP bandwidth is configured.

A number of product variants will be offered to CPs:

GEA-DP Option 1: Assured bandwidth 0.5Mbit/s downstream, 0.5Mbit/s upstream bandwidth

2.4 Ethernet and VLAN Architecture

Figure 5: Definition of OLT domains

2.4.1 VLAN architecture

Figure 6: VLAN architecture

Figure 7: Traffic management points using integrated Ethernet switch

Figure 8: Traffic management points using an external Ethernet switch (ES)

2.5 Generic Ethernet Requirements

2.5.3 Ethernet OAM

[R48] Ethernet in the First Mile OAM as specified in IEEE 802.3ah.

[R49] Connectivity Fault Management: as specified in IEEE 802.1ag.

2.6 FTTP System Scalability

Time Period Number CP Interface Ports Number of End Users

2.7 GPON QoS Requirements

[R71] The Vendor must state the DBRu modes supported.

135Kbps downstream @ random Ethernet frame size

100Mbps downstream @ 256byte Ethernet frame size

2.8 CP Handover Points and Interfaces

The following interface types are required:

[R76] The 1 GE interfaces must conform to IEEE 802.3z.

[R77] The 10 GE interfaces must conform to IEEE 802.3ae.

[R79] Each optical interface, 1 GE and 10 GE, must support autosensing