Specifications For Gpon Active Equipment 13-Sdms-11

Saudi Electricity Company ‫الشركة السعودية للكهرباء‬
13-SDMS-11, REV.00
SEC DISTRIBUTION MATERIALS SPECIFICATION
DATE: 06-08-2017G
13-SDMS-11
REV. 00
SPECIFICATIONS
FOR
GPON ACTIVE EQUIPMENT
This specification is property of SEC and subject to change or modification without any notice.
Page 1 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
CONTENTS
1 INTRODUCTION............................................................................................................................. 3
2 APPLICABLE CODES AND STANDARDS ................................................................................. 3
3 ABBREVIATIONS ........................................................................................................................... 5
4 GENERAL REQUIREMENTS ....................................................................................................... 9
5 PRODUCT OFFERINGS AND ROADMAP ............................................................................... 11
6 REFERENCE ARCHITECTURE ................................................................................................ 11
7 OPTICAL LINE TERMINAL (OLT) EQUIPMENT ................................................................. 11
8 OPTICAL NETWORK TERMINAL (ONT) EQUIPMENT ..................................................... 20
9 EMS/NMS ........................................................................................................................................ 25
10 OPERATING CONDITIONS........................................................................................................ 28
11 NETWORK REFERENCE............................................................................................................ 29
12 INSTALLATION ............................................................................................................................ 29
13 TESTING AND INSPECTION ..................................................................................................... 29
Page 2 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
1 Introduction
1.1 Objectives
The aim of this document is to give the specifications for the active GPON equipment (OLTs and
ONTs) for the deployment of an FTTx network in Kingdom of Saudi Arabia.
1.2 Scope
This document specifies the minimum requirements for the supply, installation, configuration, testing,
commissioning and support of active GPON equipment, to offer a set of world class broadband products
and services covering:
 Connectivity to SEC smart meters via GPON
 OLTs located in all the substations
 Associated transport to SMOC & MDMS through Distribution metro network and NG network
 Connectivity to SEC substations via GPON
 Support for Substation Automation System (SAS), Distribution Automation System (DAS) and
Smart Grid
 ONTs located in Fiber Distribution Networks at MV/LV transformer locations
 Dual homing via diverse routes required to meet resilience requirements
 GPON type C protection scheme
 Adequate for low latency communication requirements
 Associated transport to control centers through Distribution metro network and NG network
 Connectivity to the customers of up to 2 Retail Service Providers (RSPs)
 Any active equipment needed for 3rd party services will be added by the telco / RSP
2 Applicable codes and standards

This Distribution material standard specification shall be read in conjunction with the latest revision of
Distribution General Specification titled “01-SDMS-01, Rev 01” which shall be considered as an
integral part of this standard. This material standard specification shall also be read in conjunction with
purchase order or contract schedules for the project, as applicable.
The latest revision/amendments of the following codes and standards shall be applicable for the
equipment/material covered in this Distribution material standard specification. In case of conflict, the
vendor/manufacturer may propose equipment/material conforming to one group of industry codes and
standards quoted hereunder without jeopardizing the requirements of this standard specification.
 ITU-T G.652 Characteristics of a single-mode optical fiber cable.

 ITU-T G.703 Physical/electrical characteristics of digital Interface
Page 3 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
 ITU-T G.704 Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736
Kbit/s hierarchical levels.
 ITU-T G.823 The control of jitter and wander within digital networks which are based
on the 2048 Kbit/s hierarchy.
 ITU-T G.983.4 A broadband optical access system with increased Product capability
using dynamic bandwidth assignment.
 ITU-T G.984 ITU-T Recommendation G.984 is a family of recommendations that
defines gigabit passive optical networks (GPON) for telecommunications
access networks
 ITU-T G.984.1 GPON General Characteristics.
 ITU-T G.984.2 GPON Physical Media Dependent (PMD) layer specification.
 ITU-T G.984.3 GPON Transmission convergence layer specification.
 ITU-T G.984.4 GPON ONT management and control interface specification.
 ITU-T G.984.1 Gigabit-capable Passive Optical Networks (GPON): General
characteristics, 2008, with amendment 1 (2009) and 2 (2012)
 ITU-T G.984.2 GPON: Physical Media Dependent (PMD) layer specification, 2003, with
amendment 1 (2006) and 2 (2008).
 ITU-T G.984.3 G-PON: Transmission convergence layer specification, 2008, with
amendments 1 (2009), 2 (2009), 3 (2012) and erratum 1 (2010).
 ITU-T G.984.4 G-PON: ONT management and control interface (OMCI) specification,
2008, with amendments 1 (2009), 2 (2009), 3 (2010), erratum 1 (2009),
corrigendum 1 (2010), and an implementer's guide (2009).
 IEEE 802.1ad Provider Bridges.
 IEEE 802.1ag Ethernet OAM.
 IEEE 802.1D Spanning Tree Protocol.
 IEEE 802.1p VLAN prioritization.
 IEEE 802.1Q VLAN tagging.
 IEEE 802.1w Rapid Spanning Tree Protocol of at least 8 ports, based on port-based,
address-based, and round robin.
 IEEE 802.3 10 Mbps Ethernet.
 IEEE 802.3u 100 Mbps Fast Ethernet.
 IEEE 802.3ad Ethernet Link Aggregation.
 IEEE 802.3ae 10 Gigabit Ethernet.
 IEEE 802.3z Gigabit Ethernet.
 IEEE 802.3x Flow Control.
 IETF RFC 2131 DHCP.
 IETF RFC 2132 DHCP Options and BOOTP Tenderer Extensions.
Page 4 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
 IETF RFC 2236 Internet Group Management Protocol, Version 2.

 IETF RFC 2933 Internet Group Management Protocol Management Information Base.
 IETF RFC 3046 DHCP Relay Agent Info Option (Option 82).
 IETF RFC 3376 Internet Group Management Protocol, Version 3.
 IETF RFC 2698 Two Rate Three Colour Marker. Conflicts and deviations
3 Abbreviations
AAA Authentication Authorization Accounting

ALG Application Layer Gateway
ANSI American National Standards Institute. www.ansi.org
BRAS Broadband Remote Access Server aggregates the output from OLTE, Provide
High Speed Internet
CAR Committed Access Rate
CES Circuit Emulation Service
CIR Committed Information Rate
Concurrent rate Ratio of the number of online subscribers to the number of subscribers that have
subscribed to a service
Contention ratio Ratio of the actual maximum traffic volume to the theoretical maximum traffic
volume
CPE Customer Premises Equipment
CSR Customer service request
DDNS Dynamic DNS (DDNS or DynDNS) is a method of automatically updating a
name server in the Domain Name System (DNS), often in real time, with the
active DNS configuration of its configured hostnames, addresses or other
information. The term is used to describe two different concepts.
DNS Domain Name Servers (DNS) maintain a directory of domain names and
translate them to Internet Protocol (IP) addresses.
DPI Deep Packet Inspection
ETSI European Telecommunications Standards Institute (ETSI). www.etsi.org
Page 5 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
FE Fast Ethernet
Firewall Defend servers against common attacks
FO Fibre Optic
FTTB Fiber To The Building
FTTH Fiber To The Home
FTTN Fiber To The Node
GPON Gigabit-capable Passive Optical Networks
GUI Graphical User Interface
HSIA High Speed Internet Access
IAP Interception Access Point, point in the network where the interception takes
place
IGMP The Internet Group Management Protocol (IGMP) is a communications protocol
used by hosts and adjacent routers on IPv4 networks to establish multicast group
memberships. IGMP is an integral part of IP multicast
IP Internet Protocol
IP-RR BGP IPv4/v6 routing control plane router, for route information reflection.
IPS Intrusion protection system.
IRI Interception Related Information, the metadata related to a communication
service, e.g., call detail records, call set-up time, caller-id, e-mail address
KPI Key Performance Indicator
LI Lawful Interception
LIMS Lawful Interception Management System
MDF Main Distribution Frame
MDU Multi Dwelling Unit
MIB Management Information Base
MML Man Machine Language
Page 6 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
MPLS Multi Protocol Label Switching

MTBF Mean Time Between Failures
MTU Multi Tenant Unit
NAT Network Address Translation
NDA Non Disclosure Agreement
NE Network Element
NMS Network Management System
NTP Network Time Protocol
O&M Operation and Maintenance
OLT Optical Line Terminal
OMCI Open Manage Client Instrumentation to allow system administrators to remotely
manage assets, monitor system health, and inventory deployed systems
ONT Optical Network Terminal (ITU-T)
ONU Optical Network Unit (IEEE)
OPEX Operative Expenditure
OSS Operation and Support System
OTN Optical Transport Network
PAT Provisional Acceptance Test
PBH Peak Busy Hour
PE Provider Edge
PE-AGG PE Router Aggregation all traffic from UPE, OLT devices.
Penetration rate Ratio of the number of subscribers that have subscribed to a service to the total
number of subscribers
PIR Peak Information Rate
POTS Plain Old Telephone Service
Page 7 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
PPP Point-to-Point Protocol

PPPoE PPP over Ethernet
PSTN Public Switched Telephone Network
QoS Quality of Service
RFP Request For Proposal
RGW Residential Gateway
SBU Single Business Unit
SFU Single Family Unit
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SNR Signal to Noise Ratio
SNTP Short for Simple Network Time Protocol, a simplified version of NTP. SNTP
can be used when the ultimate performance of the full NTP implementation
described in RFC 1305 is not needed or justified.
TCP Transmission Control Protocol
Triple play Bundle of services: HSIA + VoIP + IPTV
UMTS Universal Mobile Telecommunications System (UMTS) is one of the third-
generation (3G) mobile phone technologies
UPE User Provider Edge
VAD Voice activated detection- In Voice over IP (VOiP), voice activation detection
(VAD) is a software application that allows a data network carrying voice traffic
over the Internet to detect the absence of audio and conserve bandwidth by
preventing the transmission of "silent packets" over the network.
VLAN A virtual local area network (virtual LAN) is the logical grouping of network
nodes.
VoIP Voice over IP
VPN-RR BGP VPNv4/v6 routing control plane router, for route information reflection.
Page 8 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
WebCache Cache the HTTP content.

EMS Element Management System
NMS Network Management System
4 General Requirements
4.1 The Project shall deliver a fully functional active GPON network (active equipment only) as a
turnkey solution based on Reference Architecture and BoQ.
4.2 The supplier shall study all SEC requirements and based on all facts propose a turnkey, cost
effective solution, based on current international standards, including all necessary equipment
(such as servers, power supply components, ancillaries, etc.)
4.3 Supplier shall be responsible to conduct a site survey to collect all relevant information that can
have impact on project in terms of feasibility, BoQ items, cost, time plan and all aspects of
realisation. Based on the site survey, the supplier shall propose all additional necessary
equipment if any.
4.4 As per SEC requirements the supplier shall design the solution in such a way that it can provide
efficient delivery of full range of services. This network shall be flexible and adjustable to future
services, by proper dimensioning in design, hardware and software, to cope with services
demands.
4.5 The Supplier shall produce a Solution Description (SD) document which will in detail explain
functionality and design of each service, configuration of protocol and explanation of chosen
options, benefits and drawback of solution as well as all possible limitations of that solution. SD
shall extensively address resiliency and security threats, scenarios and protection solution. SEC
will control and approve LLD through Technical Clarification list.
4.6 The supplier’s solution shall support all required internal and external SEC product requirements
specified in the Product Offerings and Roadmap section of this specification
4.7 The supplier shall obtain all necessary certification from the KSA Telecoms Regulator for all
equipment proposed in the solution prior to contract signing.
4.8 The supplier shall perform, or where performed by SEC, assist SEC in performing, and
document user acceptance testing services for Applications developed implemented or modified
by the supplier
4.9 The proposed solution will be according to the industry standards and based on supplier
experience to provide the most effective and flexible network functioning. In exceptional cases,
and with SEC’s written agreement, proprietary standards may be used to achieve better
capabilities.
Page 9 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
4.10 The solution must be cost effective. It shall provide all necessary support for the services in
chosen the design, and shall exclude unnecessary options that could increase the cost.
4.11 The solution must provide as best as possible performance of each proposed service.
4.12 All Hardware and software proposed to be deployed in SEC Network shall have at least 5 years
roadmap guaranteed support. All relevant emerging technologies shall be clearly reflected in the
roadmap.
4.13 The solution description document shall explain in detail the functionality and design of each
service, the configuration of each protocol and full explanations of chosen options, the benefits
and drawback of solution as well as all possible limitation of that solution
4.14 Services availability of 99.999% shall be assured by providing first class equipment with
industry leading values for MTBF for the implemented HW and SW, and by providing
redundancy features for hardware and proper configurations.
4.15 MTBF values shall be provided for all equipment
4.16 The solution shall offer enhanced security features and proper configuration of those options in
the way that provide self-defending ability across whole network as well as per node basis.
4.17 Configurations of all network elements shall to be done in a way to provide a full set of features
for all services mentioned in this RFP.
4.18 The proposed solution needs to incorporate effective and comprehensive tools for O&M through
the deployment of appropriate EMS and NMS equipment to support Event and Fault
Management, Inventory Management, Configuration Management, Performance Management,
Security and System Administration Management.
4.19 Supplier shall completely integrate Fault Management and other tools as required into existing
SEC OSS platforms. The supplier shall offer the list of all possible alarms with alarm correlation
indicated recommended action. SEC shall choose what needs to be forwarded to OSS.
4.20 The Supplier shall provide complete list of counters and recommendation for KPIs. SEC will
choose what will be implemented.
4.21 The Supplier shall provide tools for collecting all relevant statistics from nodes that can be used
for analysis and accounting.
4.22 The suppliers shall explain all the capacity and capability of the system offered and the relation
to the unit price of each component of the system. This shall include hardware, software (port
license, software license, etc), services and support, with the BoQ clearly linked to the pricebook.
4.23 The suppliers shall explain the right of SEC in using the license offered and the limitation in
using the license. The suppliers shall also explain the capability and limitation of the existing
NMS & License in performing all NMS function.
Page 10 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
4.24 The Supplier shall propose usage based software licences wherever feasible (such as Pay As You
Use, Pay As You Grow)
4.25 The suppliers shall indicate the conformance of the equipment to relevant international standards.
4.26 The suppliers shall guarantee the interoperability with other vendor equipment (including SDH,
DWDM, Ethernet, IP equipment), any limitation/restriction with other suppliers shall be clearly
defined in the technical document.
4.27 All hardware shall have 2 years free warranty
4.28 The supplier shall conduct a Proof of Concept (PoC) to demonstrate the solution to the
requirements specified in this document
4.29 SEC shall not be responsible or liable for any costs incurred by the supplier in the PoC.
5 Product Offerings and Roadmap

The bidder’s solution must be able to fulfil all SEC requirements with regard to the services at launch as
well as future services, as described in <Add reference to product document in the future>.
5.1 Internal products and services

5.1.1 The network should support smart meter communication.
5.1.2 The network should support SAS, SCADA, DAS, and Smart grid/Smart city switching
communication.
5.2 RSP products

5.2.1 The solution shall support standard products as may be required by SEC RSPs, including:
 Broadband internet of various speeds (10, 20, 50, 100 & 1000 Mb), contention ratios and
product level guarantees
 Video on demand
 IPTV via multicast
 Voice over IP via residential gateway
 Business grade internet
 Wholesale residential and business broadband
 WiFi at Home (stand alone or integrated)
6 Reference Architecture
6.1 The solution proposed by the Supplier shall conform with the requirements of SEC.
7 Optical Line Terminal (OLT) Equipment
Page 11 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.1 The OLT shall serve as the network termination point for the optical access network and also
provides Product node interface which serves to backhaul user traffic to SEC’s network.
7.2 The OLT shall support a flexible set of Products from the same chassis.
7.3 The OLT shall support B+ and C+ Optics at the same GPON port just by changing SFP
7.4 The OLT shall have the capability to support all standard GPON protection types.
7.5 The supplier shall implement Type C protection for all GPON networks.
7.6 The GPON system shall support line rate performance for each type of interface under different
packet sizes of 64, 256, 512 and 1500 bytes respectively.
7.7 The OLT system shall support the following MAC address learning capacity:
 Minimum 32K MAC addresses per OLT system
 Minimum 4K MAC addresses per GPON port
 Minimum 1K MAC address per GEM port
 Minimum 1K MAC addresses per ONT
7.8 The MAC address learning performance of the GPON system shall be:
 Learning of 32K MAC addresses per OLT system within 1 minute
 Learning of 4K MAC addresses on a GPON port within 10 second
 Learning of 1K MAC addresses on one ONT within 2 seconds
 Learning of 1K MAC address on one GEM port ID within 2 seconds
7.9 CLI shall be available to display the MAC address learned:
 for each GEM port ID in the OLT GPON port
 for each UNI port in the ONT
7.10 MAC aging timer shall be supported and configurable with default value 300 seconds.
7.11 The OLT system shall support L2 DHCP Relay Agent functionality with Option 82 data
insertion.
7.12 The following Option 82 information shall be supported:
 OLT system name
 Slot/Module number
 GPON port number
 ONT number
 GEM port ID
7.13 The OLT system shall support DHCP Snooping
7.14 Each GPON port shall support minimum three types of traffic classes for each ONT:
 Delay Sensitive for voice and video conference
Page 12 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
 Guarantee for video streaming and business data

 Best Effort for Internet
7.15 The Dynamic Bandwidth Allocation (DBA) shall support configurable polling rate for each
traffic classes.
7.16 For Delay Sensitive traffic class shall support DBA polling interval down to 1ms with stable and
satisfactory performance.
7.17 For Guarantee traffic class shall support DBA polling interval down to 2ms with stable and
7.18 For Best Effort traffic class shall support DBA polling interval down to 4ms with stable and
7.19 The Delay Sensitive traffic class shall have priority higher than all other traffic classes.
7.20 When a GPON port is fully registered with 64 Delay Sensitive class GEM port IDs, 64
Guarantee class GEM port IDs and 64 Best Effort class GEM port IDs, the Delay Sensitive
traffic class in each ONT shall have latency of less than 2ms and latency variation of less than
2ms under congested condition caused by lower priority traffic classes.
7.21 The Guarantee traffic class shall be WRR type of traffic scheduling with priority higher than
Best Effort traffic class.
Guarantee class GEM port IDs and 64 Best Effort class GEM port IDs, the Guarantee traffic
class in each ONT shall have latency of less than 5ms under congested condition caused by lower
priority traffic classes.
7.23 The Best Effort traffic class shall be WRR type of traffic scheduling. It shall be the lowest
priority traffic class and be able to use all the available bandwidth or timeslot left from other
traffic classes and be fairly shared among all ONTs.
Guarantee class GEM port IDs and 64 Best Effort class GEM port IDs, under non-congested
condition, the Best Effort traffic class in each ONT shall have latency of less than 5ms under
non-congested condition.
7.25 The weight of each WRR traffic class (or transmission token in leaky bucket model) shall be
calculated based on the total Ethernet bytes transmitted over a certain period of time instead of
total no. of packets, this is to avoid unfair use of bandwidth due to packet sizes variation.
7.26 Each GPON port shall support minimum three egress traffic queues per ONT for the three traffic
classes, viz. Delay Sensitive, Guarantee and Best Effort.
Page 13 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.27 Each GPON port shall support minimum 8 egress traffic queues.
7.28 The OLT system shall support upstream bandwidth control through Dynamic Bandwidth
Allocation (DBA) mechanism:
 Bandwidth is allocated to different traffic priorities among ONTs
 Committed bandwidth is guaranteed for each ONT
 Available best effort bandwidth can be fully utilized and is fairly is allocated among ONTs
7.29 For downstream traffic, the OLT system shall support traffic classification from uplink ports
based on 802.1p values of SVLAN.
7.30 For upstream traffic, the OLT system shall support traffic classification based on GEM port ID.
7.31 The OLT system shall support marking of SVLAN 802.1p value
 By copying the CVLAN 802.1p value to SVLAN 802.1p value.
 By setting SVLAN 802.1p to particular value per GEM port ID.
7.32 The OLT shall support access list type of classification criteria, for example, VLAN ID, 802.1p,
MAC address, IP address, IPP, DSCP, etc.
7.33 The OLT shall provide ETSI 2.048KHz BITS timing support.
7.34 The OLT shall provide timing to all ONTs and all CPEs connected to ONTs.
7.35 The Supplier shall provide details of clock accuracy of the OLT control module.
7.36 The OLT shall provide control module and uplink redundancy.
7.37 The Supplier shall provide uplink failover time.
7.38 The OLT shall support GE and 10GE network connections.
7.39 802.3ad LAG and LACP shall be supported on the network connections.
7.40 OLT shall support the following Link Aggregation Group (LAG) hashing options: a)
Source/destination MAC address; b) VLAN tag; c) Source/destination IP address. This shall be
an SEC configurable option.
7.41 OLT shall support the ability to balance load amongst the links in a Link Aggregation Group.
7.42 OLT shall support as few as two and as many as eight links in a LAG group.
7.43 OLT shall support Link Aggregation via GigE/10GigE links across interface module slots (inter-
card basis) for module/slot redundancy, with LACP signalling
7.44 The OLT equipment and cabinet solution shall be compliant to the relevant ETSI standards.
7.45 The supplier shall provide MTBF and MTTR figures for all GPON components.
7.46 The supplier shall provide details of port capacity for PON line cards.
Page 14 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.47 The supplier shall provide details of OLT capacity when fully populated.
7.48 The supplier shall provide a detailed, itemised power budget for typical and maximum power
consumption per port, per card, per chassis and per rack. Clearly state the power drawn for each
of the individual items. State the typical and maximum power drawn for the fully loaded chassis
and rack scenarios from the previous item.
7.49 The supplier shall provide details of heat dissipation for a fully loaded chassis and rack,
including the temperature operating range.
7.50 The supplier shall provide details of the reliability of the software that will be used for each
module of the OLT including Line cards and control modules.
7.51 The supplier shall provide evidence of NEBS Level 3 Compliance (GR-1089 and GR-63).
7.52 The design of the OLT shall allow for fibre connectors and fibre routing and shall not result in
fibre bends or stress on the fibre connectors when the OLT shelf doors are opened or closed, or
the OLT plug-ins are inserted or removed.
7.53 All NE (including all equipment units and assemblies) shall be marked with model and / or part
numbers, month and year of manufacture, and serial numbers.
7.54 The OLT shall allow the disconnection of any CPE or optical facility to the ODN without an
adverse impact on the network still being served.
7.55 The OLT shall have a fault tolerant back plane such that the failure of a single line card does not
have an adverse effect on the entire shelf.
7.56 Any switch to a protected interface shall not require the repositioning of any Product.
7.57 The OLT shall provide, as a minimum, hardware redundancy for power feeds, power supplies,
on-line backup memory, network interface modules, and controller, central-processor, switch-
matrix modules, and other modules that perform similar functions in future releases.
7.58 The OLT shall support both automatic and manual switching operations between redundant
units, and hitless (or almost hitless) switching shall be performed in both. The manual would
include normal and forced (e.g., under certain alarm and/or error conditions) switching.
7.59 Installation/removal of any protected module or of any interface module into the OLT shall not
impact the functionality of any other OLT modules or of the OLT itself (i.e., be “hot swappable”)
7.60 OLTs shall have the capability of being upgraded remotely (via the management system) with
software revisions
7.61 Software downloads to the OLTs shall be non-Product affecting
7.62 The OLT shall support Gigabit Ethernet interfaces compliant with IEEE 802.3z.
Page 15 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.63 Medium-reach GigE optical interfaces shall be available, and these shall be implemented as
standard IEEE 802.3 1000B-LX10 as specified in IEEE 802.3ah.
7.64 Long-reach GigE optical interfaces shall be available, and these shall be implemented as standard
IEEE 802.3 1000B-ZX as specified in IEEE 802.3ah.
7.65 Single-mode Optical GigE interfaces shall be available for the northbound uplink from/to the
OLT. Optical interface line cards must support Gigabit Interface Converter (GBIC) or Small
Form-Factor Pluggables (SFP, also called “mini-GBIC”).
7.66 OLT shall support RSTP (rapid spanning tree protocol).
7.67 OLT shall support Dual Stack IPV4/IPV6 to trsnsition from IPV4 to IPV6
7.68 GigE interfaces shall be able to sustain 1000 Mbps in each direction, upstream and downstream,
regardless of packet size, with no packet loss.
7.69 The OLT shall provide a minimum of four (4) Gigabit Ethernet (GigE) interfaces for northbound
uplinks to support all traffic to the core network. Hardware redundancy for these 4 GigE
interfaces must be provided.
7.70 The OLT shall support VLAN tagging, per IEEE 802.1Q.
7.71 The OLT must support VLANs on the Ethernet uplink, with 4096 distinct VLANs.
7.72 The OLT shall support VLAN Stacking.
7.73 The OLT shall support IEEE 802.1Q User priority bits (formerly 802.1P bits)
7.74 The Ethernet uplink shall be capable of transmitting frames of up to 2000 bytes. Specify the
maximum Ethernet MTU and confirm that frame transmission with multiple VLAN headers can
occur
7.75 The supplier shall provide full details of management options, including in-band, out-of-band or
other, showing both management of the OLT, and also the systems available for ‘end-to-end’
provisioning.
7.76 The supplier shall identify and describe any management software that is required to manage
third party OLT components or any of the associated APoP equipment.
7.77 The supplier shall provide details of OLT upgrade procedures. Specify the time required and
capability to upgrade Control Module and Line Card software/firmware without loss of end user
Product.
7.78 The supplier shall provide details about how Product Level Agreement metrics can be obtained
from the OLT, including QoS statistics, packet loss, latency, up/down counters and line errors.
Page 16 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.79 The supplier shall provide details about how the OLT can be managed according to the ISO
FCAPS model for network management.
7.80 The supplier shall provide details of SNMP functionality, including the SNMP versions
supported, standard and extended MIB capabilities and SNMP traps.
7.81 The OLT shall support RS-232 interface for craft terminal access.
7.82 The OLT shall support in-band and out-of-band management.
7.83 OLT shall have RSSI capable optics that enable optical Line monitoring.
7.84 OLTs shall support EMS-directed provisioning requests.
7.85 Detection of a Product-affecting failure condition in an OLT shall cause the associated network
resource to be placed in an unavailable state for provisioning purposes.
7.86 OLTs shall support a complete discovery mechanism, reporting all inventory configuration
information to the EMS.
7.87 OLTs shall support on-request auditing of software version and hardware diagnostic testing (e.g.,
power-on self-test), and report results to the EMS.
7.88 The OLT shall allow for pre-provisioning of Products.
7.89 If the OLT supports pre-provisioning of line-cards, the OLT shall send an error message to the
EMS if a card type other than the pre-provisioned card type has been installed in that slot.
7.90 The system shall meet all applicable requirements of the ITU-T G.984.x specifications for single-
fibre GPON systems with line rates of 2.488 Gbps downstream and 1.244 Gbps upstream in the
basic band. The supplier shall list all areas of non-compliance and provide expected dates for
compliance.
7.91 Each OLT port on a line card must support 2.488Gbps/1.244Gbps (Downstream/Upstream)
transmission Line rate.
7.92 The system shall support a minimum of 1024 subscribers per shelf.
7.93 The system should support up to 64 ONTs per PON.
7.94 The system must support the GPON Encapsulation Method (GEM) framing for carrying Ethernet
traffic.
7.95 The OLT must be able to support an ITU-T Class B+ and Class c+ power budget with up to 1:64
split ratio, a physical reach up to 20-60 km and maximum differential logical reach of 20km -in
accordance with ITU-T Recommendation G.984.1.
7.96 Optical budget of 28dB should be achievable without FEC.
7.97 The system must support AES encryption as specified in ITU-T G.984.3.
Page 17 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.98 The encryption key length shall be at least 128 bits.

7.99 Key exchange shall be initiated by OLT.
7.100 Encryption can be enabled and disabled for each channel identified by Port_ID. The default shall
be enabled (note: the default does not apply to multicast Port_ID)
7.101 Wavelength allocation shall meet ITU-T G.984.3 (wavelength ranges centre wavelengths of 1310
nm upstream and 1490 nm downstream) and 1550nm for the video overlay where applicable.
7.102 Power levelling shall be compliant to the activation sequence specified in G.984.3.
7.103 The system shall support status-reporting DBA method outlined in ITU-T Recommendation
G.984.3. This implies that all ONTs shall be able to report the status of their T-CONT buffers
and that all OLTs shall be able to dynamically and fairly allocate bandwidth based on those
reports.
7.104 Provide details of the Dynamic Bandwidth Assignment (DBA) method supported (status
reporting and non-status reporting).
7.105 T-CONT type 1, 4 and 5 should be supported.
7.106 Specify the number of TCONTs and GEM PORT-Ids supported per PON, per ONT and per UNI.
7.107 DBA implementation should guarantee upstream bandwidth shaping at the level of the individual
Product.
7.108 The system shall support PON Multicast as defined in ITU G.984.3.
7.109 The system shall comply with OMCI in the applicable sections in ITU-T Recommendation
G.984.4 and referenced documents. The OLT shall be able to manage the ONTs using the ONT
Management and Control interface (OMCI).
7.110 The system shall support asymmetric bandwidth allocation to each Product.
7.111 The system shall support symmetric bandwidth allocation to each Product.
7.112 The OLT must be capable of assigning IP addresses to end users with RFC2684 Products via
DHCP relay.
7.113 The OLT is also expected to act as a relay for both IP address assignation and IP address renewal
in order to prevent direct communication between end user devices and the DHCP servers at all
times. Provide details of extended DHCP options that are supported and how these options are
used to offer advanced Products.
7.114 DHCP relay with Option 82 shall be supported.
7.115 PPPoE relay tag shall be supported.
Page 18 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.116 The OLT shall be compliant with TR-101 with regards to handling C-Tag/S-Tag’s. It shall be
able to support transparent bridging of a port onto a VLAN, and support private customer
VLANs (N:1 and 1:1).
7.117 Provide details of the Traffic Management capabilities of the OLT (e.g. Policing) – in terms of a
customer port, VLAN tag or a session/flow for a given user.
7.118 The system shall support VLAN stacking, unstacking, and VLAN transparency.
7.119 The system shall support VLAN Stacking, and allow any combination of outer/inner tag to
identify any combination of Product/customer.
7.120 Customer VLAN tag(s) received within the customer’s GEM Port-ID in the OLT shall be
retained (honored), removed, changed, or Q-in-Q encapsulated (nested) based on provisioning
options available to the Product provider.
7.121 The OLT shall switch traffic based on subscriber VLAN ids and MAC addresses.
7.122 The system shall support IEEE 802.1Q User priority bits (formerly 802.1P bits).
7.123 The system shall support eight (8) Ethernet priority levels per 802.1Q.
7.124 The OLT shall prohibit the bridging of MAC packets among GEM Port-IDs by default.
7.125 System must be able to handle 802.1p priority tagged, untagged, VLAN, or DSCP marked
packets for proper traffic prioritization.
7.126 System must support port default 802.1p bit marking.
7.127 System shall use different GEM Port-IDs on a per customer port basis (other than Multicast
traffic).
7.128 System shall support upstream/downstream traffic shaping on a per customer product basis.
7.129 OLT shall support downstream traffic shaping on a per user per Product basis.
7.130 The OLT shall provide a mechanism to map the Product class of a GEM Port-ID to the Ethernet
priority bits in the corresponding VLAN tag, and vice versa
7.131 When handling IP traffic, the OLT must be capable of supporting advanced IP QoS functionality
per user connection/VLAN/GEM port. Provide details of upstream and downstream QoS
capabilities on the GPON line. The IP QoS capabilities side of the OLT NNI shall also be given.
7.132 Provide details of QoS traffic marking and scheduling, ability to weight queues with the same
priority and the ability to specify the size and depth of all queues. Detail the number of queues
supported per interface. Provide details of 802.1p to IP QOS (Differentiated Products Code
Point) mapping/interworking.
Page 19 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
7.133 Weighted Round Robin (WRR) and Strict Priority (SP) queuing shall be supported on the
network connections of the OLT.
7.134 The OLT shall support the ability to specify the allocation of egress (transmit) and ingress
(receive) buffers across SP and WRR queues.
7.135 The OLT shall support the ability to configure any combination of CoS p-bit values to any of the
egress queues.
7.136 Priority bits on marked traffic received on the ingress of the OLT Network facing Ethernet port
shall be retained (honored), discarded, or overwritten based on provisioning options available to
the Product provider.
7.137 The OLT shall be able to support configuration of buffer sizes across ingress or egress queues.
7.138 The OLT shall support the ability to configure queue weight for the WRR queues.
7.139 The OLT shall support per-VLAN per-Product queuing/scheduling on the egress of northbound
uplinks.
7.140 The OLT shall support configuring the size/depth of all queues.
7.141 The OLT shall support mapping of GEM Port-IDs on the PON side to eight (8) priority levels on
the Ethernet side.
7.142 Provide details on the points of multicast in the OLT architecture.
7.143 The OLT shall support native Multicast functionality. The OLT shall support static joins between
the OLT and the Multicast Router i.e. the OLT Join request shall be independent of all
customers’ Join and Leave requests.
7.144 Provide details on how the OLT can accommodate multiple multicast streams per user.
7.145 The OLT shall support IGMP v3 proxy and snooping.
8 Optical Network Terminal (ONT) Equipment

8.1 The ONT, which shall be located within the end internal or external customer premises (indoor
unit) to terminate the optical signal from the OLT.
8.2 The ONT shall be manageable from the OLT through the OMCI interface.
8.3 Types of ONTs shall be supported:
 Type-1: 1x GPON uplink, 1x 1000BaseT ports
 Type-2: 1x GPON uplink, 4x 1000BaseT Ports, 802.11b/g/n WiFi and router
 Type-3: 1x GPON uplink, 4x 1000 Base T Ports, 2 POTS
Page 20 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
8.4 The ONT shall support 802.1D transparent bridging and MAC address learning among UNI
ports and GPON uplink port. Broadcast, multicast and unknown unicast traffic shall be flooded
to all ports, except for the incoming port. Full range of VLAN IDs 1 – 4094 shall be supported.
8.5 The ONT shall not impose any max traffic rate limit on broadcast, multicast and unknown
unicast traffic in both directions.
8.6 ONT shall be configurable and disabled by default.
8.7 ONT shall be transparently pass through the multicast addresses from “224.0.0.0” to
“224.0.1.255”.
8.8 ONT shall support IGMP Leave ALL message with group address “0.0.0.0” and clear all
registered multicast groups in the IGMP snooping table.
8.9 OLT shall have CLIs to display the IGMP snooping table in the ONT.
8.10 Provide full, current datasheets on the proposed ONT solution.
8.11 Ethernet interfaces shall be available at speeds of Fast Ethernet (FE) and potentially Gigabit
Ethernet (GE).
8.12 The supplier shall provide details of the ONT architecture including switching performance for
Ethernet Frames and IP packets (of various sizes). Include information of switch fabric and
interface throughput in real terms and any relevant functionality that improves the traffic
forwarding capabilities of the ONT.
8.13 The solution shall be compliant to the relevant ETSI standards in this area.
8.14 The supplier shall provide MTBF and MTTR figures for the ONT.
8.15 The supplier shall provide details of interfaces and interface capacities for the ONT.
8.16 The supplier shall provide a detailed, itemized power budget for typical and maximum power
consumption.
8.17 The supplier shall provide details of heat dissipation information for the ONT.
8.18 The supplier shall state what power backup facility is available for the ONT.
8.19 While the intention is for indoor deployment, SEC welcomes information regarding outdoor
ONT placement. Information shall include specification of the outdoor housing, power
requirements, cabling options (power, LAN and voice), battery backup and any other relevant
details.
8.20 POTS interfaces shall be available on ONTs when explicitly requested. Number of POTS
interfaces shall be specified.
Page 21 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
8.21 E1 interfaces shall be available on ONTs when explicitly requested. Number of E1 interfaces
shall be specified.
8.22 The ONT shall provide all products to the customer within 30 seconds when power is returned to
the ONT
8.23 Installation and turn-up of the ONTs shall be “one-step”, i.e., be capable of being completed
during one Product/installation visit by a single trained field technician.
8.24 Installation/removal of a plug-in product module into an ONT shall not impact products from
other modules on the ONT (i.e., be “hot swappable”) or product to any other ONT/customer on
the PON.
8.25 The ONT data interface output shall not be affected by the presence or content, of voice traffic
on a POTS circuits (if installed).
8.26 The ONT shall only pass data packets to the appropriate addresses. For multi-customer ONTs
customers served from the same ONT must be unable to see each other’s traffic. ONTs with
multiple customer/product interfaces shall ensure that traffic on one customer/product interface
cannot be accessed by any other customer interface.
8.27 ONTs shall allow for the remote activation and deactivation of products on a per-interface basis.
Implementation shall be via the OMCI.
8.28 ONTs shall, by default, prohibit the bridging/forwarding of MAC packets among customer ports.
8.29 The ONT shall interface to the network via a single fibre connection.
8.30 Ethernet interfaces shall fully comply with IEEE 802.3i (10BaseT @ 10 Mbps) specifications.
8.31 Ethernet interfaces shall fully comply with IEEE 802.3u (100BaseT @ 100 Mbps) specifications
8.32 10/100 BaseT Ethernet interfaces on the ONT shall be able to sustain 100 Mbps in each
direction, upstream and downstream.
8.33 10/100/1000 BaseT Ethernet interfaces on the ONT shall be able to peak to 400 Mbps in each
direction, upstream and downstream.
8.34 ONTs shall have the capability of being upgraded remotely (via the management system) with
software revisions, without impact to traffic
8.35 Activation of ONT software shall be SEC-initiated.
8.36 GEM-based connections in the ONTs shall not be changed as a result of software upgrades and
patches.
8.37 End-customers shall not be able to modify any software and/or configuration data in the ONT.
Page 22 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
8.38 ONTs shall have a simple mechanism and communications method for input of a registration ID
in order to be able to associate provisioning data when newly installed.
8.39 ONTs shall provide positive confirmation of a successful completion of a configuration request.
If the configuration request cannot be satisfied, the ONTs shall provide an appropriate message
indicating the cause of the failure.
8.40 ONTs shall support EMS-directed provisioning requests.
8.41 Detection of a Product-affecting failure condition in an ONT shall cause the associated network
resource to be placed in an unavailable state for provisioning purposes.
8.42 ONTs shall support a complete discovery mechanism, reporting all inventory configuration
information to the EMS.
8.43 ONTs shall support on-request auditing of software version and hardware diagnostic testing (e.g.,
power-on self-test), and report results to the EMS.
8.44 ONTs shall maintain background checks on hardware and software during normal operation and
report failed checks to the EMS. No ONT reset/reboot shall be required to clear an alarm
condition.
8.45 Where appropriate, there shall be simple visual fault indicators on the ONT faults to aid craft
maintenance procedures.
8.46 During initial ONT turn up, after the ONT is powered up and ONT serial number sent to the
OLT, the ONT shall range; come up on its start-up code; and send information on its current
software version (stored internally) to the OLT. The OLT shall determine if the ONT software
needs to be upgraded. If an upgrade is needed, the OLT shall initiate the ONT upgrade process.
8.47 During initial ONT turn up, the ONT shall be visible to the EMS; shall be capable of being
managed remotely by the EMS; shall have start up code capable of allowing the ONT to provide
basic functions (to be specified) and support the software upgrade process; and shall notify the
OLT or EMS that a start-up code is present.
8.48 ONT shall support Dying Gasp
8.49 ITU-T G.984.5 compliant WBF shall be supported.
8.50 The Ethernet UNI must be capable of transmitting frames up to 2000 bytes. The interface MTU
must be capable of transmitting this IP packet with additional Ethernet and VLAN headers
without fragmentation. The IP MTU for the Ethernet UNI shall be specified.
8.51 ONT shall support VLAN tagging, per IEEE 802.1Q.
8.52 State the maximum sustained data rate capable of being delivered by each ONT. Include the
maximum available burst rate available to each device in the upstream and downstream direction.
Page 23 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
8.53 ONT shall support Dual Stack IPV4/IPV6 to transition from IPV4 to IPV6
8.54 The ONT shall be able to support an ITU-T Class B+ power budget.
8.55 The supplier shall provide details of mechanisms available on the ONT (e.g.
prevention/detection) to deal with potential security attacks such as masquerading etc.
8.56 ONTs shall support a minimum of eight (8) GEM Port-ID per Ethernet/VDSL interface served.
8.57 Installation/removal of an ONT on an existing PON shall not impact Product to any other
ONT/customer on the PON.
8.58 For ONTs supporting the RF overlay, the ONT shall contain an integrated WF2 filter function
that allows both the downstream basic band signal and the video signal to be separated or
isolated thereby inducing no degradation or interference to either signal
8.59 For ONTs/ONUs that do not support the RF overlay, a blocking filter shall be incorporated into
the ONT such that the ONT can operate on a PON that is carrying signals above 1500 nm
without suffering any impairment of the G-PON system.
8.60 The ONT shall be capable of being managed by the OLT using the ONT Management and
Control interface (OMCI). Provide details of the relevant management capabilities of the OLT
with regards ONT configuration management, Fault management, performance management and
security management. Also indicate if remote ONT software upgrades can be carried out from
the OLT
8.61 The ONT must support native Multicast functionality using the GEM port. Also state if Multicast
replication is available on the ONT.
8.62 The ONT shall have the configuration capability to limit the maximum number of switched
channels per subscriber.
8.63 There shall be a mechanism to limit the multicast bandwidth over PON. Please describe what
happens when this bandwidth is under utilized.
8.64 The system shall be capable of selecting and forwarding into the customer premise a minimum
64 IGMP multicast streams per ONT.
8.65 State if the system supports access control for multicast? Preferably, this shall be implemented
by means of channel packages (i.e. group of any multicast channels that share common access
permission). Detail scalability of this solution.
8.66 The ONT shall be configurable to set QoS markings (DSCP and 802.1Q user priority bits) on the
voice bearer traffic it generates
8.67 The ONT shall be configurable to set QoS markings (DSCP and 802.1Q user priority bits) on the
voice signaling traffic it generates.
Page 24 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
8.68 The ONT shall be capable of queuing upstream and downstream traffic into separate
configurable hierarchical queues based on Ethernet priority markings.
8.69 The user shall not be able to set (or change) the ONT’s IP address.
8.70 Authentication of customer gateway’s or customer premise equipment (CPE) on the network to
prevent cloned devices according 802.1x.
8.71 Encryption capabilities to secure data packets across the PON FTTH network.
8.72 Traffic segregation and protocol isolation to be described.
8.73 Prevention of direct user-to-user traffic to avoid malicious use and denial of Product attacks.
8.74 Prevention of duplicated MAC addresses on the same VLAN to avoid malicious use and denial
of Product attacks
8.75 Prevention of ARP-spoofing
8.76 Describe the physical security capabilities of the ONTs or CPEs.
8.77 Describe the capabilities of the system to prevent unacceptable utilization of the network
resources. Include details for support of broadcast storm prevention, access control lists and
traffic filters.
8.78 Fault or error conditions on a single ONT may disrupt the PON for other ONTs on the same
PON. Detail which mechanism is implemented in the system to overcome these scenarios.
8.79 The ONT shall allow for the provisioning of several tiers of data rates, starting at 64 Kbps, and
continuing up to 1Gbps for 10/100/1000 BaseT interfaces.
8.80 The ONT should support optional Forward Error Correction (FEC) as defined in G.984.3 for
both upstream and downstream traffic. FEC overhead should be specified.
8.81 ONTs shall support upstream traffic shaping on a per-PortID basis.
8.82 ONTs shall support queuing/scheduling on a per GEM Port-ID basis.
8.83 The ONT shall supply a minimum of four (4) priority queues on the upstream egress port(s) in
support of priority levels.
8.84 ONTs shall supply a minimum of four (4) priority queues on the downstream egress customer
interface/port in support of priority levels for use when the downstream link bandwidth exceeds
the customer port bandwidth.
8.85 ONTs shall be able to use the eight (8) Ethernet priority levels to map Ethernet frames received
on the customer port(s) to GEM Port-IDs on the network side.
9 EMS/NMS
Page 25 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
9.1 The supplier shall provide a full Network Management System to monitor and manage the FTTH
system.
9.2 The NMS shall provide full functionality via a modern Graphical User Interface (GUI). Its
management responsibilities shall include the full range of event management, alarm
management, configuration management, performance management and security management
functions.
9.3 The supplier shall provide a product provisioning solution, capable of mass provisioning
9.4 The supplier shall provide details of third-party billing solutions that are known to be compatible.
9.5 The EMS/NMS shall comply with open standards for integration with third-party management
and billing.
9.6 The supplier shall state the number of concurrent users capable of being managed through the
NMS.
9.7 The supplier shall describe the standard process to “turn up” a new customer. Identify pre-
configuration, required “truck rolls”, etc..
9.8 The supplier shall describe any tools available for craft applications
9.9 The network element shall forward all alarm information northbound to the element management
system (EMS).
9.10 In the event of a link failure between the element management system (EMS) and the network
element (NE), the EMS shall generate and display an alarm notification on the GUI.
9.11 In the event the link between the element management system (EMS) and the network element
(NE) is down, the NE shall retain all alarm information until the link is re-established and then
forward the stored information to the EMS
9.12 System shall not provide autonomous alarm reports to the EMS for subsequent detection of a
trouble that has already been reported. If the trouble is cleared, the clearing of the trouble shall
be reported to the EMS
9.13 System shall maintain background checks on hardware and software during normal operation and
report failed checks to the EMS. No OLT reset reboot shall be required to clear an alarm
indication.
9.14 System alarming shall be sufficiently detail to identify the discrete system component (individual
OLT cards, ONT) in failure condition.
9.15 The NE shall have the capability to suppress specific alarm reporting as determined by SEC
9.16 The NE shall report failure of power units, circuits, feeders, or fuses to the Local Craft interface
and Element Management System.
Page 26 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
9.17 The NE shall suppress redundant alarm reporting.

9.18 System shall provide critical, major and minor severity alarms, as well as “informational” alerts.
9.19 The GPON system shall support delivery of capacity management data either an Out-of-band
data communications networking interface (TCP/IP/Ethernet) or an In-band (a VLAN in the
Gigabit Ethernet interface) data communications networking interface to the system’s EMS. The
choice shall be configurable by the Product provider installer.
9.20 The GPON system shall provide configuration data for all physical interfaces including card
inventory, virtual interfaces, OSI layer 3 and above protocols into which there is visibility, e.g.
IGMP snooping/proxy, DHCP option 82 imposition (RFC 3046), and EAP over RADIUS.
9.21 The GPON system shall support collection of the physical port status and logical port status.
9.22 The GPON system shall support monitoring of the physical layer including changes in port
status, failover, loss of signal, optical/electrical receive levels, optical/electrical transmit levels,
and bit error rates.
9.23 The GPON system shall support non-intrusive mirroring or tapping of virtual connections and
ports for input to remote diagnostic systems.
9.24 The OLT or the EMS shall be capable of identifying that the ONT needs a software upgrade. A
trap shall be created that identifies the ONT is currently on start up code.
9.25 The software upgrade/transfer process shall be tracked by the EMS. This means that the SEC
shall be able to identify that the transfer has started, and that the transfer has completed. A trap
(informational) shall indicate that start up code was detected and transfer begun. The GUI shall
also give some sort of indication that an ONT upgrade is in progress.
9.26 It shall be possible to identify the type and version of ONTs on the system.
9.27 After the transfer is successful and complete, there shall be positive indication provided to the
EMS regarding the code version present on the ONT. An “Auto ONT Upgrade Successfully
Complete” trap shall be generated.
9.28 During ranging, an ONT may not be properly ranged causing communications to fail. In this case
the OLT shall “remove” the ONT from the PON. This condition shall be alerted to the EMS.
9.29 The ONT shall have a watchdog timer and be policing its activities to ensure that it can disable
the laser if the ONT has for example, started transmitting “illegal” data traffic or entered into an
illegitimate a state. Please describe what other features your ONT has to monitor its performance
and self-police.
9.30 A capability shall be available at the EMS or the OLT to identify a potential Rogue ONT {e.g. a
smart agent on the EMS examining out-of-sequence alarms} and to determine with a certain
level of confidence when a PON is in trouble. Please describe how this process will work.
Page 27 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
9.31 The EMS platform shall support optional redundancy to prevent any single software or hardware
failure from interrupting EMS operations.
9.32 Failure of the EMS shall not impact any existing Products.
9.33 The NMS and the OLT systems shall support remote ONT firmware upgrade:
 Batch Upgrade
 Auto Upgrade
9.34 Batch ONT firmware upgrade capabilities shall be:
a) Multiple upgrade task windows can be initiated in NMS, at least one task window per OLT
system can initiated simultaneously.
b) Each upgrade task window can be specified with start time (or execute immediately) and
end time (or no time limit)
c) Quick ONT selection criteria can be supported, e.g. per OLT system, per OLT slot, per
OLT port, per ONT type, per ONT software version, or per ONT one by one.
d) Multiple ONTs can be upgraded in parallel, at least one ONT per OLT port can be upgraded
simultaneously within an OLT system.
e) Each ONT upgrade can be upgraded within 5 minutes.
f) Both off-line (previously registered) and on-line ONTs can be selected for upgrade, off-line
ONU will be upgraded when it is on-line again.
g) The upgrade task can be aborted and restarted manually in NMS.
h) The upgrade task window can show ONU type and software version of each selected ONU,
a status field indicating whether it is Waiting, Downloading (with % of progress),
Restarting, Completed, Failure with different reasons.
i) Parallel firmware upgrade shall be supported when multiple ONTs are registered at the
same time
9.35 Solution must be capable to support self-provisioning through web portal, and to support features
and application interface, if in later stage SEC decide to implement this feature.
9.36 Solution must support remote “Zero Touch” activation/provisioning, remote management,
performance monitoring and troubleshooting for CPE.
10 Operating Conditions
10.1 All equipment specified shall be capable of operating normally in the temperature range -5 to 40
°C
10.2 The Supplier shall provide a solution for remote locations with an extended operating
temperature range of -5 to 55 °C.
Page 28 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
10.3 All equipment specified shall be capable of being stored without impact to performance in the
temperature: -20 to 70 °C
10.4 All equipment specified shall be capable of an operating normally in the humidity range: 20 to
95% non-condensing
11 Network Reference
11.1 Supplier shall submit at least TEN GPON network references, which shall be installed and with
live traffic with the Network restoration feature being implemented.
12 Installation
12.1 The Supplier shall be responsible for a full installation of all equipment on site which includes
mounting into the racks, cabling in MDF, power cabling etc and if required installation of
rectifiers, DB, batteries, etc as a turnkey solution.
12.2 The Supplier shall be responsible for full configuration of all protocols, features and options
thereby providing optimal performance of system, preserve processing resources and implement
all relevant security standards and protection mechanisms related to deployment scenario.
12.3 The Supplier shall as part of the project fully integrate their solution into SEC existing systems,
from network to applications level (supporting existing products and services)
12.4 The Supplier shall be responsible for the installation and/or integration of a Network
Management System, including configuration and integration of all network elements included in
the solution into NMS. NMS shall provide full functionality for Fault Management, Topology
Map, Configuration, Performance and Security Management. Performance and Fault
management will be based on SEC recommendations and inputs from the vendor's experience.
Vendor shall provide list of all counters and alarms that the equipment supports.
12.5 Integration of FM (alarms and traps) into existing OSS for all proposed components through
central management node.
12.6 Configuration of all components in a legible manner thereby providing templates for plug and
play of all services
12.7 Detailed as built documentation covering all aspects of the installation and detailed operational
procedures.
13 Testing and inspection

13.1 The Supplier shall perform full functional tests, including verifying the establishment of stable
and quality connections end to end
13.2 All commissioning tests shall be performed in the presence of SEC designated witnesses
Page 29 of 30
13-SDMS-11, REV.00
DATE: 06-08-2017G
13.3 Provisional Acceptance Test (PAT) and Final Acceptance Test (FAT) procedures must be
documented and network acceptance will be performed based on the proposed tests and validated
against the expected results.
13.4 Factory Acceptance testing shall be performed when requested by SEC
13.5 Supplier shall assist with the development of user acceptance test plans and acceptance criteria
for approval by SEC.
13.6 Supplier shall assist SEC to develop and document test cases for user acceptance testing.
13.7 Supplier shall assist SEC to coordinate user acceptance testing, including identification and
support for all Authorized Users participating in the testing.
13.8 Supplier shall perform the Acceptance Testing operation, including project management, test
planning, design and execution. All process are designed to fully address the business
requirements and match SEC customer needs
13.9 Prior to SEC UAT, the Supplier will certify that it has completed internal testing on the entire
solution and that all software delivered for UAT shall be free of defects and pass the same tests
when administered by SEC staff.
13.10 The Supplier is required to perform the tests for the system to demonstrate the Acceptance Test
Procedure KPIs.
13.11 The acceptance test scenarios shall aim to simulate the real live processes. A major part of this
complexity will be derived from the data. Therefore, the AT shall be executed with production
data, not synthetic data.
13.12 Supplier shall ensure all important aspects are ready for the UAT execution stage. This shall be
done according to a checklist with pre-defined quality gates. This checklist will be finalized in
consultation with SEC during the AT-Plan phase.
13.13 The Test Execution phase shall contain few rounds, depending on the system scope. Each round
may have a different scope. Test Scenarios are to be executed in parallel on multiple UAT
environments, in order to be efficient and monitor progress in several areas.
13.14 The entire Acceptance Test scope shall include new functionality, regression, defects, interfaces,
business processes, and non-functional testing.
13.15 Prior to PAT, the Supplier shall handover all documentation as may be required by SEC,
including as-built diagrams and O&M documentation
Page 30 of 30

Specifications For Gpon Active Equipment 13-Sdms-11

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Specifications For Gpon Active Equipment 13-Sdms-11

Uploaded by

Copyright:

Available Formats

Saudi Electricity Company ‫الشركة السعودية للكهرباء‬

2 APPLICABLE CODES AND STANDARDS ................................................................................. 3

4 GENERAL REQUIREMENTS ....................................................................................................... 9

5 PRODUCT OFFERINGS AND ROADMAP ............................................................................... 11

6 REFERENCE ARCHITECTURE ................................................................................................ 11

7 OPTICAL LINE TERMINAL (OLT) EQUIPMENT ................................................................. 11

8 OPTICAL NETWORK TERMINAL (ONT) EQUIPMENT ..................................................... 20

13 TESTING AND INSPECTION ..................................................................................................... 29

2 Applicable codes and standards

 ITU-T G.652 Characteristics of a single-mode optical fiber cable.

 IETF RFC 2236 Internet Group Management Protocol, Version 2.

AAA Authentication Authorization Accounting

MPLS Multi Protocol Label Switching

PPP Point-to-Point Protocol

WebCache Cache the HTTP content.

5 Product Offerings and Roadmap

5.1 Internal products and services

5.2 RSP products

7 Optical Line Terminal (OLT) Equipment

 Guarantee for video streaming and business data

7.98 The encryption key length shall be at least 128 bits.

8 Optical Network Terminal (ONT) Equipment

9.17 The NE shall suppress redundant alarm reporting.

13 Testing and inspection

You might also like