BHS_ADSL2_Tech_Reqs_rev3
-
Upload
jorge-martin-doroteo-rojas -
Category
Documents
-
view
221 -
download
0
Transcript of BHS_ADSL2_Tech_Reqs_rev3
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
1/221
1
2
2
M
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
2/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
3/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
4/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
5/221
. Development requirements
Four categories of requirements are established:
Mandatory (M): the device must support the characteristic in order to achieve Telefnica Group approval.
Highly Recommended (HR): it is highly desirable the device supports this characteristic. This degree ofcompliance can evolve to Mandatory in subsequent versions of the document. Supporting this characteristic
will be valued in the device commercial promotion.
Optional (O): it is left up to the manufacturer whether the device supports this characteristic or not.
Informative (I): manufacturer can enter a free text to provide information about the requirement/question.
. Functional classification
General
WAN Interfaces
LAN Interfaces
Core Functionality
Services
Management
Documentation
. Glossary
In the Scope of this document, the following definitions are applicable (only terms needing some clarification
are included):
3GPP: Third Generation Partnership Program
10 Base-T: Ethernet Local Area Network
AAL:ATM Adaptation Layer.
AC:Alternating Current.
ACCOMP: Address and Control field COMPression
ACS:Auto-Configuration Server.
ADSL: Asymmetric Digital Subscriber Line.
ADSLmn: Asymmetric Digital Subscriber Line multinorm.
AES: Advanced Encryption Standard
ALG: Application Level Gateway
AMR: Adaptive Multi-Rate
ANSI: American National Standards Institute
ATM: Asynchronous Transfer Mode.
ATU-C:ADSL Transceiver Unit, Central office end
ATU-R:ADSL Transceiver Unit, Remote terminal end.
BER: Bit Error Rate
BPS: Bits Per Second
BRAS: Broadband Remote Access Server
CCBS: Completion of Calls to Busy Subscribers
ain blocks are:
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
6/221
CCNR: Call Completion on No Reply
CDV: Cell Delay Variation
CHAP: Challenge Handshake Protocol.
CLIP: Calling Line Identification Presentation
CLIR: Calling Line Identification Restriction
CPE: Customer Premises Equipment
CRC: Cyclic redundancy check
dBrnc: dB over noise reference (-90dBm) according to C curve
DCF: Distributed Coordination Function
DHCP: Dynamic Host Configuration Protocol.
DMT: Discrete Multitone
DNS: Domain Name Service
DRA: Dynamic Rate Adaptation
DRR: Dynamic Rate Repartitioning
DSL: Digital Subscriber Line.
DSLAM: Digital Subscriber Line Access Multiplexer.
DSL Modem: Converts ATM cells to Ethernet packets and vice versa in the use of DSL
DSSS: Direct Sequence Spreading Spectrum
EAP: Extensible Authentication Protocol.
EDCA: Enhanced Distributed Channel Access
EIRP: Equivalent isotropically radiated power
EOC: Embedded Operations Channel.
ETSI: European Telecommunications Standards Institute
FDM: Frequency Division Multiplexing
FEC: Forward Error Correction
FTP: File Transfer Protocol.
GFC: Generic Flow Control
GUI: Graphical User Interface.
HCF: Hybrid Coordination Function
HCCF: Hybrid Coordinator Function Controlled Channel Access
HTML: Hyper Text Mark Language.
HTTP: Hyper Text Transfer Language.
ICMP: Internet Control Message Protocol.
IEC: International Electrotechnical Commission.
IETF: Internet Engineering Task Force
INP: Impulsive Noise Protection
IP: Internet Protocol
IRC: Internet Relay Chat.
ISDN: Integrated Services Digital Network
ISO: International Organization for Standardization
ISP: Internet Service Provider.
ITU: International Telecommunication Union
KBPS: Kilobits per Second.
LAN: Local Area Network.
LED: Light Emitting Diode
MAC: Media Access Control
MBPS: Megabits Per Second
MDI: Medium Dependent Interface
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
7/221
MIC: Message Integrity Check
MIMO: Multiple Input and Multiple Output
NAPT: Network Address & Port Translation.
NAT: Network Address Translation.
NIC: Network Interface Card.
NTR: Network Timing Reference.
OAM: Operation, Administration and Management
OLR: OnLine Reconfiguration
OSI: Open System Interconnection.
PAP: Password Authentication Protocol.
PC: Personal Computer.
PAP: Password Authentication Protocol.
POTS: Plain Old Telephone Service.
PPP: Point to Point Protocol.
PPPoA: PPP over ATM.
PPPoE: PPP over Ethernet.
PSD: Power Spectral Density
PSK: Pre-Shared KeyPSTN: Public Switched Telephone Network
PT: Port Translation.
PVC: Permanent VC.
PvC: Polyvinyl Chloride.
PVP: Permanent Virtual Path.
QoS: Quality of Service
RFC: Request for Comments.
RFQ: Request for Quotation.
RPC: Remote Procedure Call.
RT: Real-time.
RTCP: RTP Control Protocol.
RTP: Real-Time Transport Protocol
RTSP: Real Time Streaming Protocol.
SIM: Subscriber Identity Module.
SDP: Session Description Protocol
SNR: Signal to Noise Ration
SOAP: Simple Object Access Protocol.
SoC: Statement of Compliance.
SRA: Seamless Rate Adaptation
SSID: Service Set Identifier
SVC: Switched VC.
TCM: Trellis Code Modulation.
TCP: Transmission Control Protocol.TKIP: Temporal Key Integrity Protocol
TR: Technical Requirement.
TXOP: Transmit Opportunity
UDP: User Datagram Protocol.
UNE: Una Norma Espaola
USB: Universal Serial Bus
VC: Virtual Connection
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
8/221
VoIP: Voice over IP
VP: Virtual Path.
WAN: Wide Area Network.
WECA: Wireless Ethernet Compatibility Alliance
WEP: Wired Equivalent Privacy
WiFi: Wireless Fidelity
WLAN: Wireless Local Area Network
WMM: WiFi MultiMedia
WPA: WiFi Protected Access.
WPS: Wi-Fi Protected Setup
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
9/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
10/221
Cod Description
TR-GENRQQ General Requirements
TR-GENRQQ-MECDE Mechanical Design
TR-GENRQQ-MECDE-001The device shall be designed to allow vertical (wall mount) and horizontal mounting (desktop design). The c
according to what will be decided by Telefonica
TR-GENRQQ-MECDE-002 Power supply size shall not block or obstruct the use of the adjacent plugs
TR-GENRQQ-MECDE-003 The device housing shall be white
TR-GENRQQ-MECDE-004 The plastic of the device will be ABS+PC
TR-GENRQQ-MECDE-005
The device should use sockets colour scheme as in TR-068:
Yellow (114c pantone) Ethernet ports
Black power connectorGray (matte cool gray 3U) phone ports
TR-GENRQQ-MECDE-006 The device shall have an ON/OFF labelled power button
TR-GENRQQ-MECDE-007 The device shall have a reset button to restore default configuration. The button must be located at the bac
TR-GENRQQ-MECDE-008The device shall have a WLAN ON/OFF button (The same button will be used to activate the simplified con
method)
TR-GENRQQ-POWSU Power Supply
TR-GENRQQ-POWSU-001
The device shall be designed for a local power supply AC mains: TE: 220-230V / 50Hz;
O2CR: 220-230V (+/-10%) / 50Hz (+/- 4%);
TLATAM(br): 90-240V (+/- 15%) / 60Hz (+/- 5%);
TLATAM(pe): 90-240V (+/- 10%) / 60Hz (+/- 5%);
TLATAM(ar;cl): 90-240V (+/- 10%) / 50Hz (+/- 5%)O2 UK: 100-240V (+/- 10%) / 50Hz (+/- 5%)
TR-GENRQQ-POWSU-002 Device power input type: DC
TR-GENRQQ-POWSU-003 The device power adaptor can be external or internal
TR-GENRQQ-POWSU-004 The device power adapter shall be an automatic power switch
TR-GENRQQ-POWSU-005 The device power cord minimum length shall be 2 meters
TR-GENRQQ-POWSU-006 Power supply must be according to each conutry
Argentina
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
11/221
Brazil
Chile
Colombia
Peru
UK
Spain
TR-GENRQQ-POWSU-009 Power supply shall be labelled with device model and name
TR-GENRQQ-POWSU-010 In case of power interruption the device shall reboot automatically
TR-GENRQQ-POWSU-011 The device can not be powered via RJ11 interface
TR-GENRQQ-POWSU-010 Power supply shall be according to EU RD 278/2009
TR-GENRQQ-POWSU-011
The device shall accomplish the European Union Code of Conduct on Energy Consumption of Broadband E
Version 4 from 10 February 2011(Tier 2013-2014), supporting a maximum of 12V DC and 1,5A and a have compatible connector:
- External diameter: 5,50,05mm
- Internal Diameter: 2,10,1mm
- Length: 9,00,1mm
TR-GENRQQ-POWSU-012The Power supply must be in conformity with Telefonica specification for Universal Power supply as defined
document ERQ.c1.0001 2nd edition / Nov 2010 (document in Spanish)
TR-GENRQQ-OPSTA Indication of Operating Status
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
12/221
TR-GENRQQ-OPSTA-001
TR-GENRQQ-OPSTA-002 The frontal Led indicating the Ethernet functionality should be a single led for the four LAN pors
TR-GENRQQ-OPSTA-003 In the Back side of the device it may have indibidual Led for each of the Ethernet ports
TR-GENRQQ-OPSTA-004 A 2 Hz blinking Green-Red round of Broadband led should inform the firmware updating and flash memory w
TR-GENRQQ-OPSTA-003 Additionaly to LED indicators the supplier may provide user software to monitor device activity
TR-GENRQQ-ELCHA Electrical characteristics
TR-GENRQQ-ELCHA-001
The device shall comply ETSI TS 102 913 V1.1.1 technical specification:
4.2 (insulation resistance between terminals)
4.3 (DSL channel input impedance)
4.4 (transitory response to call signal)
4.5 (DC response to call s ignal)
4.6 (voice channel longitudinal balance)
4.7 (insulation resistance between line terminals and ground)
4.8 (voice channel input impedance) sections
TR-GENRQQ-ELCHA-002
Noise level inserted by DSL channel into voice channel must comply:
- 18dBrnC maximum when voice channel is not being used
- less than 15 noise impulses with a maximum of 47dBrncO in 15 minutes during initiation and operation stag
- less than 15 noise impulses with a maximum of 65dBrncO (at 1.004Hz, -13dBm0) in 15 minutes during initioperation stages.
TR-GENRQQ-ELCHA-003 The equipment will meet the established requirements in TS 202 913 V1.2.2 Recommendation in the applica
TR-GENRQQ-ELCHA-004DSL channel longitudinal balance: the device shall comply with the requirements of section 12.3.1 of ANSI T
section A.4.3 of ITU-T G.992.1
TR-GENRQQ-ELCHA-005DSL channel longitudinal balance must be higher than 40dB at [20 - 1.100]kHz when charging the DSL interf
600ohm
LED Colour Mode Status
Power GreenOff Router powered off
On Router powered on
Wifi Green
On Wi-Fi connection is available
Off Wi-Fi connection is not available
Blinking green Negotiation or traffic on line
3G Red/Green
Blinking green Negotiation or traffic on line
Solid green Up
Quick blinking green Tx/Rx traffic on line
Solid red Authentication failed
Off Traffic through broadband interface
Broadband Red/Green
Blinking green PPP/DHCP negotiation
Solid green PPP/DHCP up
Quick blinking green Tx/Rx traffic on line
Solid red Authentication failed
Ethernet Green On Ethernet connection is availableOff Ethernet connection is not available
DSL Green
Off Router powered off
Blinking 2Hz No line detected
Blinking 4Hz Line training
Solid Line up
WPS Red/Green
Solid Green WPS Active
Blinking 2Hz Green WPS Negotiation Open
Solid Red (20 seconds) Problems on WPS registration
Off WPS Functionali ty Disable
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
13/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
14/221
TR-GENRQQ-ELECO-003 No EM interferences between device and PSTN
TR-GENRQQ-ELECO-004The device and its power supply shall continue working in spite of: ESD (ElectroStatic
Discharges), EM radiations, RF transmitters presence and transitories/pulses or other variations in the pow
TR-GENRQQ-ELECO-005
WiFi interface shall comply with EN 300 328: Electromagnetic compatibility and Radio spectrum Matters (ER
Wideband Transmission systems when data transmission equipment operate in the 2,4 GHz ISM band and
spectrum modulation techniques
- Part 1: Technical characteristics and test conditions
- Part 2: Harmonized EN covering essential requirements under article 3.2 of the R&TTE Directive
TR-GENRQQ-ELECO-006
WiFi interface shall comply with EN 301 489: Electromagnetic compatibility and Radio spectrum Matters (ER
ElectroMagnetic Compatibility (EMC) standard for radio equipment and services.
- Part 1: Common technical requirements
- Part 17: Specific conditions for 2,4 GHz wideband transmission systems
TR-GENRQQ-OVERR Overvoltage and Overcurrent ResistibilityTR-GENRQQ-OVERR-001 The device shall comply with the requirements of ITU-T Recommendation K.21
TR-GENRQQ-OVERR-002Power supply shall resist (1000Vrms, 50/60Hz, 200mA current drain) for 30sec between phases and betwe
and ground. After this test the isolated resistance of the power supply must be at least 200Mohm measured
TR-GENRQQ-OVERR-003 The device shall have output overcurrent and overvoltage protection
TR-GENRQQ-OVERR-004 The device shall have a protection fuse
TR-GENRQQ-OVERR-005 The device shall have minimum resistance 1Mohm
TR-GENRQQ-CONNE Connectors
TR-GENRQQ-CONNE-001
The device shall ensure proper contact between the male and female connectors of the elements inserted.
shall be golden with a minimum thick quality equivalent to 1.27um thick gold and they must support stress, e
life cycle and ageing tests.
TR-GENRQQ-CONNE-002 The device shall have a RJ11 female connector for the WAN interface and use its internal pair (3rd and 4th
TR-GENRQQ-CONNE-003The device shall have 4xRJ45 female connectors for the LAN interface according the specification ANSI EI
be used with UTP cat5 cables)
TR-GENRQQ-ENVRQ Environmental Requirements
TR-GENRQQ-ENVRQ-001
The device shall have low environmental impact. So it shall be produced using materials: tagged for recyclin
without cadmium, solvent-free (water-based lacquers) with reusable packaging or failing foams without CFC
and fuel, disposable in landfills or incinerators
TR-GENRQQ-FREEF Freefall
TR-GENRQQ-FREEF-001 The device shall be EM 60068-2-32 regulation compliant
TR-GENRQQ-PPCAS Production Process Control and Samples
TR-GENRQQ-PPCAS-001 The supplier shall provide the samples and means to perform quality tests
TR-GENRQQ-PPCAS-002Device sample for approval test shall be identified by producer name, model name, version, serial number,
chipset model and manufacturer and FW version
TR-GENRQQ-PPCAS-003
Telefonica inspectors can oversee device materials and production processes and
perform recalls if the product does not satisfy any requirement (recalls can be
carried out also when the product has already been delivered). Production critical points shall be notified to
order to take actions if necessary and any SW/HW modifications shall be notified.
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
15/221
TR-GENRQQ-PPCAS-004The device shall have a life cycle (the supplier shall be able to ship devices during 24 months from the tend
- O2CR and TLATAM: 2 years
TR-GENRQQ-PPCAS-005
The device shall ensure a Mean Time Between (Hardware) Failure of:
- O2CR: 100 days
- O2DE: at least 1 year
TR-GENRQQ-PPCAS-006 Faulty (total or partial) device rate = maximum 1 per 100 devices per year
TR-GENRQQ-PPCAS-007 The device manufacturer shall provide a TR069 Score Card
TR-GENRQQ-PPCAS-008
Certificate Requirements. The device manufacturer shall provide a TR069 Certification on RFATS date for e
version of the device.
All mandatory TR-069 methods must be passed.The device must achieve 100% compliance for all profiles
datamodel requested in this document.
TR-GENRQQ-PPCAS-009
The device supplier shall perform Interoperability Tests (IOT) with the supplier of Auto-Configuration Server
selected before shipment of the devices. The OB shall inform the device supplier in advance but the supplie
provide a list of the ACS systems on which IOT have been performed.
TR-GENRQQ-PPCAS-010
The device manufacturer shall provide IEEE 802.11n WECA Certification (according to the last avaliable ve
Alliance accredited test laboratory. A list of 3rd party Wifi devices and tested firmware version has to be pro
device manufacturer
TR-GENRQQ-OTHER Others
TR-GENRQQ-OTHER-001 Non device status dependant phone service
TR-GENRQQ-OTHER-002 The supplier must be cert ified or commit to a deadline for certification in local regulator of each country
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
16/221
Details and comments (English)
Fully Compliant (FC)
Partially Compliant (PC)
Non Compliant (NC)
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
17/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
18/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
19/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
20/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
21/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
22/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
23/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
24/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
25/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
26/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
27/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
28/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
29/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
30/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
31/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
32/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
33/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
34/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
35/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
36/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
37/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
38/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
39/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
40/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
41/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
42/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
43/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
44/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
45/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
46/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
47/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
48/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
49/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
50/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
51/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
52/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
53/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
54/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
55/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
56/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
57/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
58/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
59/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
60/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
61/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
62/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
63/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
64/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
65/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
66/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
67/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
68/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
69/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
70/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
71/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
72/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
73/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
74/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
75/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
76/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
77/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
78/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
79/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
80/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
81/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
82/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
83/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
84/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
85/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
86/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
87/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
88/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
89/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
90/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
91/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
92/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
93/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
94/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
95/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
96/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
97/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
98/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
99/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
100/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
101/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
102/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
103/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
104/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
105/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
106/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
107/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
108/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
109/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
110/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
111/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
112/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
113/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
114/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
115/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
116/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
117/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
118/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
119/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
120/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
121/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
122/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
123/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
124/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
125/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
126/221
TR-PHLRQ-WANTC-027The Power Management feature will be completely supported according to whats described in G.992.3 se
and 10.3. This is, the three states described in the regulation (L0, L2 and L3) must be supported.
TR-PHLRQ-WANTC-028 The device shall support Programmed reduce framing overhead as in G.992.3TR-PHLRQ-WANTC-029 The device shall operate ensuring 10e-7 BER or better with a security noise margin
TR-PHLRQ-WANTC-030 The device shall support Fast and Interleaved transmission modes
TR-PHLRQ-WANTC-031The device shall support Interleaved transmission mode providing protection against impulsive (INP) noise a
including Annex K.2.7
TR-PHLRQ-WANTC-032The device shall transport ATM data over DSL using frames with the format defined in T1.413-6.4, T1.413-7.
and G.992.1-8.4. The Formats 0, 1, 2, 3 and for are mandatory as well
TR-PHLRQ-WANTC-033The device shall transport ATM data over ADSL2 using frame format defined in G.992.3-7.6 with programme
overhead.
TR-PHLRQ-WANTC-034 The device shall transport ATM data over ADSL2+ using frame format defined in G.992.5-7.6
TR-PHLRQ-WANTC-035
The device shall accept NTR (Network Timing Reference) as in T1.413-6.3, T1.413-7.3, G.992.1-7.3, G.992
7.2 and G.992.3-7.8 (depending on the DSL standard in use).The NTR sent by the DSLAM is reconstructed
in T1.413-5.2
TR-PHLRQ-WANTC-036The device shall use Scrambling for error protection as in T1.413-6.5, T1.413-7.5, G.992.1-7.5, G.992.1-8.5
7.7.1.3 (depending on the DSL standards supported)
TR-PHLRQ-WANTC-037 The device shall use CRC checksums to detect errors
TR-PHLRQ-WANTC-038The device shall support Forward Error Correction (FEC) as in T1.413-7.6, G.992.1-7.6, G.992.1-8.6, G.992
G.992.5 (depending on the DSL standards supported)
TR-PHLRQ-WANTC-039 FEC R, S and D parameters of T1.413 Table 10, G.992.1 Table 7.7 and G.992.2 Table 5 parameteres must
TR-PHLRQ-WANTC-040 FEC Reed-Solomon coding support (with 3 words per symbol when G.992.5 is in use)
TR-PHLRQ-WANTC-041The device shall use Trellis Coding Modulation (TCM) as in G.992.1-7.8, G.992.1-8.8, T1.413-7.8 but being a
interoperate with DSLAM with no Trellis Coding Modulation.
TR-PHLRQ-WANTC-042 The device shall support one-bit constellation encoding
TR-PHLRQ-WANTC-043The device shall use Constellation Encoding (no Trellis) with a maximum number of bits per carrier between
T1.413-7.9, G.992.1-7.9 and G.992.1-8.9
TR-PHLRQ-WANTC-044 The device shall perform Gain Scaling as in T1.413-6.10, T1.413-7.10, G.992.1-7.19 and G.992.1-8.10 (depeDSL supported standards)
TR-PHLRQ-WANTC-045 The device shall use modulation as in T1.413-6.11, T1.413-7.11, G.992.1-7.11, G.992.1-8.11 and G.992.1 A
TR-PHLRQ-WANTC-046The device shall use 1.1MHz bandwidth and 256 subcarriers for T1.413/G.992.1/G.992.3 and 2.2MHz and 5
for G.992.5
TR-PHLRQ-WANTC-047 The device shall use subcarriers as in T1.413-6.7, T1.413-7.7, G.992.1-7.7, G.992.1-8.7 and G.992.1 Annex
TR-PHLRQ-WANTC-048 The device shall perform Frequency Bands Separation using FDM
TR-PHLRQ-WANTC-049Besides FDM the device can use Echo Cancellation to perform Frenquency Bands Separation but only if FD
interoperability is guaranteed
TR-PHLRQ-WANTC-050 The device shall use DMT modulation with 4,3125 kHz between subcarriers
TR-PHLRQ-WANTC-051 The device shall control subcarriers transmission spectrum
TR-PHLRQ-WANTC-052The device shall respect the frame structure "reduced overhead with merged fast and sync bytes" according
7.4.3.2 using interleaved buffer
TR-PHLRQ-WANTC-053 The pilot carrier (276kHz) cannot be modulated or transport user data when using T1.413, G.992.1 or G.992when using G.992.3
TR-PHLRQ-WANTC-054 The device shall use Cyclic Prefix as in T1.413-6.12, T1.413-7.12, G.992.1-7.2, G.992.1-8.2 and G.992.1
TR-PHLRQ-WANTC-055The device transmitter dynamic range shall comply T1.413-6.13, T1.413-7.13, G.992.1-7.13 and G.992.1-8.1
on the DSL supported standards)
TR-PHLRQ-WANTC-056The device transmitter spectral response shall comply T1.413-6.14, T1.413-7.14, G.992.1-7.14, G.992.1-8.14
(depending on the DSL supported standards)
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
127/221
TR-PHLRQ-WANTC-057 The device transmitted power spectral density and aggregate power level shall comply ANSI T1.413-1998, s
TR-PHLRQ-WANTC-058Device Initialization Sequence as in T1.413-9, G.992.1-10 and annexes. The R-QUIET2 parameter duration
between 128 and 4000 and a maximum interleaving depth at least of 64.
TR-PHLRQ-WANTC-059 Device Initialization Sequence as in G.992.3-8.13, G.992.3, G.992.5 and transactions as in G.994.1-10
TR-PHLRQ-WANTC-060
Device Initialization Sequence details (all the sequence is controlled by the ISP):
- determination pilot tone location
- fast start up as in G.992.3-8.14
- length control of the different satus in the boot process
- determination of the carriers used to transmit messages in the boot process
- disabling Tones voluntarily
TR-PHLRQ-WANTC-061 The device should support RETRAIN and RESYNC states as in G992.3 Annex D
TR-PHLRQ-WANTC-062 The device should support RETRAIN and RESYNC states as in T1.413 Annex A
TR-PHLRQ-WANTC-063EOC (Embedded Operation Channel) availability as in T1.413-8.1 and G.992.1-9.1 and requirements as in G
(depending on DSL supported standards).
TR-PHLRQ-WANTC-064 The device must support Dying Gasp (device Loss Of Power announcement) using free EOC (Embedded OChannel) and EOC message as defined in T1.413-8.1.5.4, G.992.1-9.2.5.4 and G.992.2-8.3.3.
TR-PHLRQ-WANTC-065 The device should support In-service performance monitoring and surveillance as in T1.413-8.2 and G.992.
TR-PHLRQ-WANTC-066The Device Should Support failure count parameters as in T1.413-8.2.4.3, line far-end failures detection as i
8.2.5.2, atm far-end failures as in T1.413-8.2.7.2 and near-end performance monitoring functions as in T1.41
TR-PHLRQ-WANTC-067 Device Loop Diagnostics Mode supported as in G.992.3-8.12.4 and G.992.3-8.15. Autotest as in G.992.3-9.
TR-PHLRQ-WANTC-068 Values reserved for signalling, OAM functions and resources management shall not be used for data transm
TR-PHLRQ-WANTC-069The device shall be able to perform OLR (OnLine Reconfigurations) to ensure good operation when line or e
conditions change as in T1.413-10 and G.992.1-11.
TR-PHLRQ-WANTC-070The device shall include OLR feature Bit Swapping to perform seamless re-allocation of bits between sub-ca
interrupting the data flow as in G.992.3-10.2.1
TR-PHLRQ-WANTC-071The device shall include OLR feature Dynamic Rate Repartitioning (DRR) to reallocate bandwidth between th
interleave channels as in G.992.3-10.2.1 and G.992.5. This feature can be enabled/disabled by the ISP
TR-PHLRQ-WANTC-072
The device shall include OLR feature Seamless Rate Adaptation (SRA) to avoid dropping the connection cha
rate to accommodate temporary line conditions in G.992.3-10.2.1 and G.992.5. This feature can be enabled/
ISP
TR-PHLRQ-WANTC-073The device shall include OLR feature Dynamic Rate Adaptation (DRA) as in T1.413 Annex K and G.992.1 A
appendix II
TR-PHLRQ-WANTC-074 Operation bit rate can be fixed or adaptative
TR-PHLRQ-WANTC-075The device shall be able to set up both asymmetrical and symmetrical bit rate connections. Those bit rates m
supported depending on the settings in the ADSL-LTs
TR-PHLRQ-WANTC-076 Operation bit rate depends on line characteristics so ATM data bit rate will be adapted in 32kbps steps.
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
128/221
TR-PHLRQ-WANTC-077
The vendor must provide information about minimum and maximum upstream and downstream ATM bit rate
- TE requires a minimum upstream bit rate of 800kbps and a minimum downstream bit rate of 8Mbps using AT1413 and 1M/24M using ADSL2+ G992.5 Annex A.
- TLATAM requires a minimum upstream bit rate of 700kbps and a minimum downstream bit rate of 8000 kb
ADSL (T1.413 or G.DMT), a minimum upstream bit rate of 600kbps and a minimum downstream bit rate of
using ADSL Lite (G.Lite), a minimum upstream bit rate of 900kbps and a minimum downstream bit rate of 12
using ADSL2 (G.992.3)and a minimum upstream bit rate of 900kbps and a minimum downstream bit rate of
when using ADSL2+ (G.992.5)
- O2CR requires an upstream bit rate between 32 to 25000 kbps and a downstream bit rate between 32 and
TR-PHLRQ-WANTC-078 If the device needs a minimum link length larger than 0km the supplier shall report that value.
TR-PHLRQ-LANET LAN Ethernet
TR-PHLRQ-LANET-001The 8-pin interface mechanics shall comply with the requirements of section 3 of the IEEE 802.3 specification
consistent with the figures of 1-5 ISO/IEC 8877: 1992
TR-PHLRQ-LANET-002The device shall have Fast Ethernet 802.3u 100baseTX interface (compatible with 10baseT, 100baseTX, 10
optionally with 1000baseTX) with bit rate autonegotiation
TR-PHLRQ-LANET-003 The device Ethernet 802.3 interface shall detect and operate in half/full duplex modes
TR-PHLRQ-LANET-004The device Ethernet 802.3 interface shall support Auto-MDI/MDI-X feature to detect the connection polarity (
100baseTX or optionally 1000base-TX).
TR-PHLRQ-LANET-005 The residential gateway shall offer four Ethernet ports and be able to operate as a switch at Ethernet level.
TR-PHLRQ-WILAN WLAN
TR-PHLRQ-WILAN-001 The wireless interface can be enabled/disabled via software from the user interface and via hardware facility
TR-PHLRQ-WILAN-002 The device WLAN Interface shall operate in Access Point / Infrastructure Mode
TR-PHLRQ-WILAN-003The router should support the wireless standard 802.11n 2.4GHz(2x2) in the last available version certified b
Alliance. Troughput of WLAN to LAN shall be 100Mbps at last.TR-PHLRQ-WILAN-004 The device WLAN Interface shall ensure interoperability with IEEE 802.11b and IEEE 802.11g clients
TR-PHLRQ-WILAN-005 The device WLAN Interface shall be able to operate at 2.4GHz frequency.
TR-PHLRQ-WILAN-006 The device WLAN Interface shall be able to apply IEEE 802.11n standard features at 2.4GHz frequency ban
TR-PHLRQ-WILAN-007
The device WLAN Interface shall operate over frequency channels in 2.4GHz band: from 1 (2412MHz) to 13
with 5MHz channel spacing. Defined for Europe in 802.11-2007, Wireless LAN Medium Access Control (MA
Layer (PHY) Specifications, Clause 15, Table 15-7
TR-PHLRQ-WILAN-008 The device WLAN Interface shall be able to operate using 20MHz channels in 2.4GHz band according to IE
TR-PHLRQ-WILAN-009The device WLAN Interface may be able to operate using 40MHz bandwidth channels in 2.4GHz band acco
802.11n
TR-PHLRQ-WILAN-010 The device WLAN Interface may have DFS (Dynamic Frequency Selection) feature in 2.4GHz frequency ba
TR-PHLRQ-WILAN-011The device WLAN Interface maximum transmitted power (EIRP) when using channels from 1 to 13 in 2.4GH
not exceed 100mw in any combination of transmitter power output and supplied antenna
TR-PHLRQ-WILAN-012 Power spectral density level shall comply with VO-R/12/08.2005-34 in operation bands (2.4GHz).
TR-PHLRQ-WILAN-013The device WLAN Interface transmitter power output may be configured via web-based user interface (supp
specify the range)
TR-PHLRQ-WILAN-014 The supplier shall specify receiver sensitivity at BER 10-6 in dBm for each frequency band and every single
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
129/221
TR-PHLRQ-WILAN-015The device shall have at least 2 external antennas. The supplier shall also specify technical parameters of s
antennas (gain in dBi, radiation pattern envelope, frequency band).
TR-PHLRQ-WILAN-016
It can be offered internal antennas to replace the external antennas requested on the requirement TR-PHLR
as long as the internal antennas presents no loss in coverage, confirmed by local tests with participation and
local OB..
TR-PHLRQ-WILAN-017The supplier shall specify the number of antennas included to the device. IEEE 802.11n requires a minimum
to take advantage of MIMO features.
TR-PHLRQ-WILAN-018The device WLAN Interface shall offer Multiple Input Multiple Output features (MIMO) to take advantage of IE
improvements
TR-PHLRQ-WILAN-019The supplier shall specify what has been implemented in terms of MIMO (multiple input and multiple output)
IEEE 802.11n standard
TR-PHLRQ-WILAN-020 The supplier shall specify implemented MIMO chipset
TR-PHLRQ-WILAN-021The device WLAN Interface must be able to perform MIMO spatial multiplexing. At least two spatial streams
be received/transmitted but IEEE 802.11n standard allows a maximum of four spatial streams.
TR-PHLRQ-WILAN-022 The supplier shall specify the multiplexing algorithm used in SDM (Spatial Division Multiplexing).
TR-PHLRQ-WILAN-023 The supplier shall specify implemented kind of beamforming (single layer beamforming or multilayer beamfoprecoding) to take advantage of antenna diversity. This feature is optional in IEEE 802.11n standard.
TR-PHLRQ-WILAN-024The supplier shall specify if the device may apply diversity coding techniques (space-time coding) to enhanc
diversity.
TR-PHLRQ-WILAN-025 The device WLAN Interface can be configured to be used without encryption
TR-PHLRQ-WILAN-026 The device WLAN Interface shall support WEP security
TR-PHLRQ-WILAN-027 The device WLAN Interface can be configured to use 64bit key WEP encryption
TR-PHLRQ-WILAN-028 The device WLAN Interface can be configured to use 128bit key WEP encryption
TR-PHLRQ-WILAN-029 The device WLAN Interface using WEP security can use Open authentication
TR-PHLRQ-WILAN-030The device WLAN Interface using WEP security can use Shared Key authentication. This authentication me
secure than Open authentication.
TR-PHLRQ-WILAN-031 The WEP key of the WLAN Interface shall be entered in hexadecimal format
TR-PHLRQ-WILAN-032 The WEP key of the WLAN Interface may be entered in ASCII format
TR-PHLRQ-WILAN-033 The device shall support extended ASCII charactersTR-PHLRQ-WILAN-034 The device WLAN Interface shall support WPA security
TR-PHLRQ-WILAN-035 The device WLAN Interface shall support WPS security
TR-PHLRQ-WILAN-036 WPA user authentication can be performed via PSK (PreShared Key). Personal WPA mode.
TR-PHLRQ-WILAN-037 WPA user authentication can be performed via IEEE 802.1x protocol through EAP framework. Enterprise W
TR-PHLRQ-WILAN-038WPA user authentication via EAP framework shall support the following methods: EAP-TLS, EAP-TTLS/MS
PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC and EAP-SIM as in IETF RFC4017
TR-PHLRQ-WILAN-039 The WPA security shall include RC4-based TKIP (Temporal Key Integrity Protocol) for encryption and rekey
TR-PHLRQ-WILAN-040 The AES re-keying interval may be configured
TR-PHLRQ-WILAN-041 The TKIP re-keying interval may be configured
TR-PHLRQ-WILAN-042WPA security shall include MIC (Message Integrity Code) to avoid CRR (Cyclic Redundance Code) modifica
attackers
TR-PHLRQ-WILAN-043 WPA security shall include Reply Attack Protection mechanisms
TR-PHLRQ-WILAN-044 WPA key of the WLAN Interface shall be entered in hexadecimal formatTR-PHLRQ-WILAN-045 WPA key of the WLAN Interface shall be entered in phrase format
TR-PHLRQ-WILAN-046 WPA key of the WLAN Interface must be random and it will be the same always
TR-PHLRQ-WILAN-047 The device WLAN Interface shall support IEEE 802.11i WPA2 security
TR-PHLRQ-WILAN-048 WPA2 security shall ensure interoperability with WPA clients
TR-PHLRQ-WILAN-049 WPA2 user authentication can be performed via PSK (PreShared Key). Personal WPA2 mode.
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
130/221
TR-PHLRQ-WILAN-050 WPA2 user authentication can be performed via IEEE 802.1x protocol through EAP framework. Enterprise W
TR-PHLRQ-WILAN-051
WPA2 user authentication via EAP framework shall support the following methods: EAP-TLS, EAP-TTLS/M
PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC and EAP-SIM as in IETF RFC4017. EAP peer and authentic
authorization must be supported
TR-PHLRQ-WILAN-052The WPA2 security shall include AES-based CCMP (Counter Mode with Cipher Block Chaining Message Au
Code Protocol) for encryption and rekeying
TR-PHLRQ-WILAN-053WPA2 security shall include MIC (Message Integrity Code) to avoid CRR (Cyclic Redundance Code) modific
attackers
TR-PHLRQ-WILAN-054 WPA2 security shall include Reply Attack Protection mechanisms
TR-PHLRQ-WILAN-055 WPA2 key of the WLAN Interface shall be entered in hexadecimal format
TR-PHLRQ-WILAN-056 WPA2 key of the WLAN Interface shall be entered in phrase format
TR-PHLRQ-WILAN-057The WLAN Interface can be secured using MAC filter to control the access of certain MAC addresses to the
network
TR-PHLRQ-WILAN-058The MAC filter shall be able to operate in whitelist mode (only the registered MAC addresses are allowed to
wireless network)
TR-PHLRQ-WILAN-059The MAC filter shall be able to operate in blacklist mode (only the registered MAC addresses are not allowed
the wireless network)
TR-PHLRQ-WILAN-060 The device shall support MAC addresses self-learning of wireless clients
TR-PHLRQ-WILAN-061 The supplier shall specify maximum number of MAC addresses registered in the access table
TR-PHLRQ-WILAN-062
The SSIDs of the WLAN Interface must be WLAN_XXXX by defect, The SSIDs of the WLAN Interface must
WLAN_XXXX by defect, with "XXXX" the last bytes of MAC Ethernet (all characters of "WLAN_XXXX" must
case)
TR-PHLRQ-WILAN-063 The SSIDs of the WLAN Interface can be changed by the user.
TR-PHLRQ-WILAN-064 The device WLAN Interface can be configured to not broadcast the SSIDs (SSID hiding feature)
TR-PHLRQ-WILAN-065 The device WLAN Interface shall support Multiple SSID feature with a minumum of 4 SSIDs
TR-PHLRQ-WILAN-066When using Multiple SSID, different settings can be asigned to each SSID: encryption, hiding, enabled/disab
filteringTR-PHLRQ-WILAN-067 The device WLAN Interface shall support IEEE 802.11e QoS features
TR-PHLRQ-WILAN-068 The device WLAN Interface shall comply Wifi MultiMedia (WMM) interoperability certification.
TR-PHLRQ-WILAN-069The device WLAN Interface shall support Enhanced DCF Channel Access (EDCA) medium access control
Transmit Opportunity (TXOP)
TR-PHLRQ-WILAN-070 The device WLAN Interface HCF Controlled Channel Access (HCCA) medium access control method is opt
TR-PHLRQ-WILAN-071 The device WLAN Interface shall support Automatic Power Save Delivery (APSD) or other similar mechanis
TR-PHLRQ-WILAN-072The device WLAN Interface may support Block Acknowledgments (BA) to reduce overhead when longer TX
specified
TR-PHLRQ-WILAN-073The device WLAN Interface may be able to send frames with No Acknowledgement (NoAck) service class t
retransmission of highly time-critical data.
TR-PHLRQ-WILAN-074 WPS feature as user-friendly method to establish the WiFi configuration shall be provided in PBC (Push Bu
Configuration) mode.
TR-PHLRQ-WILAN-075Each unit shall have a unique phrase format WPA key and a customized SSID (to allow the user to recogniz
network) in its default configuration
TR-PHLRQ-WILAN-076 The device shall support Adaptive RF (automatic adjustment of signal power and WiFi channel / bandwidth)
TR-PHLRQ-WILAN-077 The device shall support Airtime Fairness functionalityTR-PHLRQ-WILAN-078 The antennas shall have a signal power of 3dBi
TR-PHLRQ-WILAN-079The Mac Address from the Ethernet interfaces and the Mac Address from the WLAN interface shall not be se
one to another (LAN to WLAN) and shall have no correlation between each other
TR-PHLRQ-WILAN-080The supplier shall provide the plans that is been implemented to avoid the vulnerability of the WPS functiona
Force Attack attempts. To have a defined plan to avoid this vulnerability is mandatory.
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
131/221
Details and comments (English)
Fully Compliant (FC)
Partially Compliant (PC)
Non Compliant (NC)
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
132/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
133/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
134/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
135/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
136/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
137/221
Cod Description
TR-LINRQ Link layer Requirements
TR-LINRQ-GENRQQ General Requirements
TR-LINRQ-GENRQQ-001The supplier shall specify ARP table maximum size and expiration time of the entries. The number of entries
than 256 addresses
TR-LINRQ-GENRQQ-002The device should have LAN 802.1p packet priorization (QoS on MAC). The supplier shall provide its roadm
this functionality
TR-LINRQ-GENRQQ-003The device shall use ATM layer to transport data over DSL layer as in IT-BA-003 Ed 2, section 6, ITU-T I.3
I.150
TR-LINRQ-GENRQQ-004The device shall support ATM layer Physical Medium sublayer (PMD) functions and primitives between PMD
layers as in ITU-T I.321TR-LINRQ-GENRQQ-005 The device shall support ATM layer: Convergence sublayer (CS) as in ITU-T I.321
TR-LINRQ-GENRQQ-006The device shall support ATM layer: Transmission Convergence (TC) sublayer primitives (to/from ATM-PMD
management plane) as in ITU-T I.413
TR-LINRQ-GENRQQ-007The device ATM layer, Convergence sublayer shall use HEC field to perform cell alignment, single bit error c
error detection and correction as in ITU-T I.321, I.432.1 and I.361-2.3.5
TR-LINRQ-GENRQQ-008
The device shall support ATM layer Convergence sublayer. Cell Rate Decoupling (CRD) feature using idle c
flow to the transmission system capacity as defined in ITU-T I.321 and I.432.1. If not possible then ATM Foru
for CRD can be used.
TR-LINRQ-GENRQQ-009 The device shall support ATM layer: Convergence sublayer. Cell data randomizing as in ITU-T I.432.1
TR-LINRQ-GENRQQ-010 ATM cell format as in ITU-T I.361. UNI 2.2 and UNI 3.1 must be Supported
TR-LINRQ-GENRQQ-011 Default Cell Loss Priority = 0 (upstream cells) for PPPoE over ATM.
TR-LINRQ-GENRQQ-012 General Flow Control (GFC) bits are not required in the cell header.
TR-LINRQ-GENRQQ-013Filling out of PTI (Payload Type Identifier) field shall be accomplished according to I.361 paragraph 2.3.3 and
incoming and outgoing directions
TR-LINRQ-GENRQQ-014 The device shall support ATM Virtual Channels in both permanent and semipermanent mode
TR-LINRQ-GENRQQ-015The device shall support ATM layer. Transmission of user data is always considered as bidirectional, and th
with the same VPI and VCI only belong to one bidirectional data connection (VC)
TR-LINRQ-GENRQQ-016ATM Virtual Channels Identifiers. VPI Range for 0 to 255 and VCI from 0 to 65535. No limitations in VPI/VCI
valid, but 0/x or x/0 shall be valid)
TR-LINRQ-GENRQQ-017ATM Virtual Channels: VPI/VCI values reserved for signalling, OAM, resource management, etc shall no btransmission or any kind of proprietary communication channel
TR-LINRQ-GENRQQ-018The device shall support al teast 8 PVCs and each one of them may have different configuration (QoS, RIP,
PPPoE sessions...)
TR-LINRQ-GENRQQ-019 ATM requirements. It shall be possible to attach a PVC to each Ethernet, WLAN or USB interface
TR-LINRQ-GENRQQ-020ATM requirements. It shall be possible to attach the same one PVC on more than one interface (Ethernet, W
interface)
TR-LINRQ-GENRQQ-021 ATM requirements. Minimum 2 PPPoE sessions can be initialized per PVC
TR-LINRQ-GENRQQ-022 ATM requirements. Static routes can be assigned to different PVCs without the need of a destination IP add
TR-LINRQ-GENRQQ-023 ATM requirements. Multicast/Unicast can be enabled over 1 PVC to provide video service
TR-LINRQ-GENRQQ-024 ATM requirements. The video PVC shall be able to transport 3 multicast/unicast traffic flows
TR-LINRQ-GENRQQ-025 ATM requirements. The device shall support ATM AAL5 (ITU.363.5)
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
138/221
TR-LINRQ-GENRQQ-026 ATM requirements. The maximum allowed BER is 10e-7 when using ATM AAL5 (ITU.363.5)
TR-LINRQ-GENRQQ-027The device shall support the Multi-protocol Encapsulation over ATM AAL5 according to the specification RF2684, including LLC, LLC SNAP (MTU of AAL5 payload shall be at least 1528 byte -at least 1536 for ATM ce
transport 1518 byte of Ethernet frames without fragmentation through PPPoE or not) and VCMux
TR-LINRQ-GENRQQ-028The device shall support ATM QoS: service classes as in ITU-T I.371 and ATM Forum Traffic Management
UBR, CBR and VBR
TR-LINRQ-GENRQQ-029 Support of ATM QoS service Class ABR
TR-LINRQ-GENRQQ-030 ATM QoS serv ice classes can be configured for each connection from the remote management system
TR-LINRQ-GENRQQ-031ATM asymmetric/symmetric data bit rate is achieved depending on the ATM service class used (QoS param
PCR)
TR-LINRQ-GENRQQ-032 The device shall support ATM QoS Connection Admission Control (CAC) feature.
TR-LINRQ-GENRQQ-033
The device shall support ITU-T I.610 Operation And Maintenance (OAM) functions in F4 and F5 End to End
flows:
OAM F4 and F5 cells support
VC-AIS / VC-RDIContinuity check
Loopback
Forward and backward performance monitoring
Activation / deactivation
System management
TR-LINRQ-GENRQQ-034
If the device support processing of OAM cells (ITU-T I.610, I.751 and I.732) the supplier shall describe in det
implemented algorithms. If OAM feature is not supported then data transmission shall not be affected when t
receives OAM cells.
TR-LINRQ-GENRQQ-035
For operation and maintenance purposes the supplier of the ADSL modem and the type of the modem shall
identified by information stored in the ATU-R registers ATU-R supplier ID (Register #0), ATU-R version nuone (Register #1), ATU-R serial number (Register #2) as specified in the ITU-T recommendation [G.992.1
TR-LINRQ-GENRQQ-036After power up the ADSL modem of the DSL Port may perform a self test and report the self test result via thregister Self test result (Register #3). If the self test succeeded and the ADSL modem is able to transfer datresult should be 0x00. If the self test fails, the result should be a value other than 0x00.
TR-LINRQ-GENRQQ-037 Link layer for Internet service: The device shall support PPP line layer protocol in accordance with RFC791
TR-LINRQ-GENRQQ-038 Link layer for Internet service: The device shall support PPP control protocol for IP (IPCP) in accordance wit
TR-LINRQ-GENRQQ-039 Link layer for Internet service: The device shall not negotiate other network protocol over PPP (IPX, X25)
TR-LINRQ-GENRQQ-040 Link layer for Internet service. PPP. PAP authentication for the PPP protocol (IETF RFC1334)
TR-LINRQ-GENRQQ-041 Link layer for Internet service. PPP. CHAP authentication for the PPP protocol (IETF RFC1994)
TR-LINRQ-GENRQQ-042Link layer for Internet service. PPP. The supplier shall describe if the device supports forced PPP authentica
configured to authenticate using only CHAP, it shall inform the BRAS to use CHAP if it tries to use PAP
TR-LINRQ-GENRQQ-043
Link layer for Internet service. PPP. The supplier shall describe if the modem supports configuration of autom
parameters in case of unsuccessful setup of PPP protocol. Modem must automatically retry setup of PPP pr
delay between to consecutive retries of PPP setup should be configurable on modem in range 5 to 90 secon
1 second. Default value of PPP setup rate must be set from 60 to 90 seconds
TR-LINRQ-GENRQQ-044
Link layer for Internet service. The supplier shall describe the modem behaviour if the modem sends PPPoE
and the BRAS does not answer with PADO. The supplier shall describe the amount of consecutive PADI and
interval within the consecutive PADI are sent. Max. 60 seconds between consecutive PPPoE PADI is requir
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
139/221
TR-LINRQ-GENRQQ-045The device must send PPPoE PADT to BRAS at first when is restarted through internal tools (e.q. restart of
reboot after upgrade of the device).
TR-LINRQ-GENRQQ-046 The PPPoE PADI may be only sent to ADSL port. PPPoE PADI must not be sent to any LAN port when is no
TR-LINRQ-GENRQQ-047
Link layer for Internet service. The modem shall support PPP keep-alive option. PPP keep-alive parameters
configurable on modem. Default value of PPP keep-alive must be set to send keep-alive (PPP echo-request
seconds to BRAS and brings PPP session down if 5 consecutive keep-alive procedures fail (The modem do
PPP echo-replay). The modem must answer to PPP echo-request from the BRAS sending PPP echo-replay
TR-LINRQ-GENRQQ-048
The device shall use the Point-to-Point Protocol over Ethernet (PPPoE) adaptation layer to establish Point-to
(PPP) sessions according to the specifications [RFC 1144], [RFC 1332], [RFC 1334], [RFC 1570], [RFC 166
[RFC 2865], [RFC 2869] with additions.
TR-LINRQ-GENRQQ-049
The device shall establish one PPP session within 1 second for all data traffic and the Auto-Configuration Se
unique MAC address if the PPP session has not been established previously and the Auto-Configuration Clie
Routing functionality requests the data connection
TR-LINRQ-GENRQQ-050
The device shall support the following retry mechanism in the case of an unsuccessful PPP Data session es
No. No of retries Timeouts(secs) Description
1 4 3 The initial retry must follow up relatively quickly in order to guarantee
time.
2 5 60 When the initial retry has failed 4 times this indicates something is w
therefore to avoid unnecessary traffic it is suggested to have a retry after 60 secs until the limit of 5 is reache
3 infinite 900 The device does a retry every 900 secs
TR-LINRQ-GENRQQ-051Link layer for Internet service. The supplier shall describe allowed range and default value of maximum routa
Default value 1492 is expected
TR-LINRQ-GENRQQ-052Link layer for Internet service. The supplier shall describe allowed range and default value of maximum segm
(MSS). Default value 1452 is expected
TR-LINRQ-GENRQQ-053
Link layer for Internet service. Adjusting of TCP maximum segment size: when IP packets with TCP payload
between media with different MTUs (for example Ethernet 1500 and PPPoE 1492) the minimum value shall MSS, remote MSS and the MSS configured in the device)
TR-LINRQ-GENRQQ-054Spanning tree protocol support in the link layer for TV service. This protocol bridging shall be done with no ch
STP frames.
TR-LINRQ-GENRQQ-055 Link layer for TV service. MAC table: limitations and acquiring and releasing rules
TR-LINRQ-GENRQQ-056 Link layer for TV service. FCS checking: rule to check frame integrity
TR-LINRQ-GENRQQ-057 Link layer for TV service. The modem shall support flooding broadcast
TR-LINRQ-GENRQQ-058 Link layer for TV service. The modem shall support bridging all DHCP frames
TR-LINRQ-GENRQQ-059 Link layer for TV service. The modem shall support flooding of multicast frames
TR-LINRQ-GENRQQ-060 Link layer for TV service. The modem shall support flooding of unknown unicast frames
TR-LINRQ-GENRQQ-061
The device shall support a functionality to use prioritisation of outgoing packets between the following interfa
- DSL Port Interface
- LAN Port Interface
TR-LINRQ-GENRQQ-062 The device shall support diffserv
TR-LINRQ-GENRQQ-063 The device shall support the configuration of link type and connection type as per appendix B of TR098 on th
TR-LINRQ-GENRQQ-064
The device shall support a separate layer2bridging instance for the IPTV passthrough.
Above mentioned VCs and some of the Ethernet ports can be assigned to this bridging instance through TRAppendix A5 of TR098 shall be used.
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
140/221
TR-LINRQ-GENRQQ-065The device shall support a separate layer3forwarding instance for the IPTV passthrough.
Above mentioned VCs and some of the Ethernet ports can be assigned to this routing instance through TR0
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
141/221
Details and comments (English)
Fully Compliant (FC)
Partially Compliant (PC)
Non Compliant (NC)
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
142/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
143/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
144/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
145/221
Cod Description
TR-NETRQ Network Layer Requirements
TR-NETRQ-IPCON IP Configurations
TR-NETRQ-IPCON-001 The device shall support RFC791 IP protocol (v4)
TR-NETRQ-IPCON-002
The device shall support RFC2460 IP protocol v6 with at least the following requirements:
- support RFC 4291, IP Version 6 Addressing Architecture
- support RFC 5952 A Recommendation for IPv6 Address Text Representation
- support RFC 4862 IPv6 Stateless Address Autoconfiguration
TR-NETRQ-IPCON-003
The device shall support DHCPv6 (DHCP snoop -for subscriber identification) with at least the following req
- support RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- support Lightweight DHCPv6 Relay Agent draft-ietf-dhc-dhcpv6-ldra-02- support RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6
TR-NETRQ-IPCON-004
The device shall support DUAL STACK IPv6/IPv4 with at least the following requirements:
- support Dual-stack lite broadband deployments post IPv4 exhaustion draft-durand-softwire-dual-stack-lite
- support RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers
- support RFC 4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service
TR-NETRQ-IPCON-005
The device shall support TUNNELING (PPPoE and IPoE) for IPv6 with at least the following requirements:
- support RFC 2473 Generic Packet Tunneling in IPv6 Specification
- support RFC 5072, IP Version 6 over PPP
TR-NETRQ-IPCON-006
The provider shall inform regarding DUAL STACK LITE the following information:
- how long it takes to implement the software in the CPE after the standard it will be defined. (Specify the am
weeks- after T0)- it would be possible to upgrade remotely the change of software. (Detail if it necessary any change in the
- if it is possible in your equipment (detail the model that applies) support both mode Dual Stack and Dual S
- if your offer include the possibility to deliver CPE with Dual Stack and then evolve to Dual Stack Lite (plea
issue and if it is part of the same buying process.
TR-NETRQ-IPCON-007
The provider shall inform regarding INTEROPERABILITY the following information:
- For DS-Lite the provider will inform what AFTRs vendor (Address Family Transition Router) interoperate
solution. Specify model and release and if it were possible the configuration tested.
TR-NETRQ-IPCON-008
The provider shall inform regarding MULTICAST IPv6 AND GROUP MANAGEMENT the following informa
- the mechanism used for MLD ICMPv6 (Multicast Listener Discovery) Reference RFC 4605 Internet Group
Protocol (IGMP) Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
- MLD snooping
- Unicast Transmission of IPv6 Multicast Messages on Link-layer draft-gundavelli-v6ops-l2-unicast-04
TR-NETRQ-IPCON-009
The provider shall inform regarding QoS SUPPORT the following information:
- IPv6 Flow Classification,
- IPv6 Flow Policy
- Queue management
- Marking Traffic Class
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
146/221
TR-NETRQ-IPCON-010
The provider shall inform the planning to address the following issues:
- The A+P Approach to the IPv4 Address Shortage draft-ymbk-aplusp-05- Routing RIPng for IPv6 RFC 2080
- Allowing together with the BRAS the functionality Change of Authorization RFC 5176 Dynamic Authorizto Remote Authentication Dial In User Service (RADIUS)
- IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture
- PPPoE v6 Dialer
- Support of monitoring: MIB v6, V6 Interface stat, etc.
- The recommendation from the Broadband Forum TR-187 IPv6 for PPP Broadband Access
TR-NETRQ-IPCON-011 The device can be configured in IP mode: RFC1483/2684 routed. IPoA (RFC1577)
TR-NETRQ-IPCON-012 The device can be configured in IP mode: RFC1483/2684 routed. IPoE/MER (MAC Encapsulated Routing).
TR-NETRQ-IPCON-013 The device can be configured in IP mode: RFC1483/2684 bridged. EthoA.
TR-NETRQ-IPCON-014The device can be configured in IP mode: RFC1483/2684 bridged. EthoA bridging using IEEE802.1d MAC b
supporting a minimum of 272 MAC addresses
TR-NETRQ-IPCON-015The device can be configured in IP mode: RFC1483/2684 bridged. EthoA bridging using IEEE802.1d MAC b
transparent to PPPoE (RFC2516), VLAN (IEEE802.1Q) and IPSEC protocols
TR-NETRQ-IPCON-016
The device can be configured in IP mode: RFC2364 routed PPPoA (RFC2364) with PAP (RFC1334) or CHA
authentication. Session establishment can be done: manually, on demand or always on (in case session is c
restablished as soon as it becomes possible).
TR-NETRQ-IPCON-017 IP configuration modes PPPoA: Session Terminated on Inactivity Timeout
TR-NETRQ-IPCON-018
The device can be configured in IP mode: RFC1483/2684 routed. PPPoE (RFC2516) with PAP (RFC1334) o
(RFC1994) authentication. Session establishment can be done: manually, on demand or always on (in case
closed it will be restablished as soon as it becomes possible).
TR-NETRQ-IPCON-019 IP configuration modes PPPoE: Session Terminated on Inactivity Timeout
TR-NETRQ-IPCON-020 Secondary IP addresses can be configured in all the device interfaces
TR-NETRQ-IPCON-021 IP subnets can be defined and attached to the LAN interfaces
TR-NETRQ-IPCON-022
VLSM (variable length subnet mask): The modem shall handle the variable subnet mask in accordance with
1878. The modem shall acquire IP address through PPP IPCP within the same network class as is configure
of the modem. For example, when LAN side of the modem is configured with 194.228.208.0/29 network the
able to acquire 194.228.208.8 address at WAN through PPP IPCP.
TR-NETRQ-ROUTI Routing
TR-NETRQ-ROUTI-001
The device shall support a functionality to support routing/forwarding of network packets that have been rece
following interfaces to any of the following interfaces: WAN interface (PPP interface if configured), LAN inter
interface
TR-NETRQ-ROUTI-002 The IP Routing functionality of the device shall use IP Routing Table.
TR-NETRQ-ROUTI-003 The device shall support static routing
TR-NETRQ-ROUTI-004 The supplier shall describe if the device supports establishing of static routing entries through management
TR-NETRQ-ROUTI-005 The device shall support dynamic routing
TR-NETRQ-ROUTI-006 Dynamic routing via RIPv1 and RIPv2 protocol in both LAN and WAN Interfaces
TR-NETRQ-ROUTI-007 The device should have ARP proxy functionality
TR-NETRQ-ROUTI-008 The device shall support ARP cache as defined in RFC 826
TR-NETRQ-ROUTI-009The routing functionality of the device shall support the Address Resolution Protocol (ARP) according the sp
826.
TR-NETRQ-ROUTI-010The device shall have NAT/PAT functionality as in RFC1631/RFC3022 (NAT/PAT basics), RFC2663 (termin
considerations) and RFC3027(protocol complications with the IP NAT) in routed mode that can be enabled o
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
147/221
TR-NETRQ-ROUTI-011The device shall be able to run in NAT mode to translate IP addresses in accordance with IETF RFC 3022. N
preserve TOS field of IP header when IP packet is going through translation process in both directions
TR-NETRQ-ROUTI-012The device shall be able to run in NAT mode to translate IP addresses in accordance with IETF RFC 3022. T
shall specify amount of maximum simultaneously established session
TR-NETRQ-ROUTI-013
The Network and Port Address Translation of the device shall be based on ports defined in the Transmission
Protocol (TCP) according the specification [RFC 793] and in the User Datagram Protocol (UDP) according th
[RFC 768].
TR-NETRQ-ROUTI-014The PAT functionality shall be able to carry out TCP/UDP mappings of external addresses and ports to differ
addresses and ports
TR-NETRQ-ROUTI-015 PAT minimum table size of 80 entries. Vendor shall specify maximum number of entries.
TR-NETRQ-ROUTI-016 The PAT funcionatily shall support DMZ
TR-NETRQ-ROUTI-017 NAT shall be transparent for IPSec (NAT traversal): VPN pass-through
TR-NETRQ-ROUTI-018
NAT shall be transparent for protocols that support NAT/PAT and shall use ALG (Application Level Gateway
not support NAT/PAT: ICMP, HTTP, RTSP, FTP, TELNET, DNS queries, POP3, SMTP, IRC, Real Audio, O
Netmeeting, Instant Messaging (ICQ, MSN...), Softphone, Video Messenger, UPNP, Microsoft MMS...)
TR-NETRQ-ROUTI-019The modem shall support acquiring WAN default route during PPP negotiation. Default route shall be install a
PPP session is established. Default route shall be withdrawn as soon as the PPP session is disconnected
TR-NETRQ-ROUTI-020
Both in bridged or routed modes time to transfer packets among interfaces must comply:
- 5ms between LAN and WLAN
- 15ms between PPP/WAN and LAN or WLAN
TR-NETRQ-ROUTI-021
Both in bridged or routed modes throughtput between interfaces must comply:
- 16Mbps between PPP/WAN and LAN
- 1Mbps between PPP/WAN and WLAN
TR-NETRQ-ROUTI-022 The device shall support IP fragmentation
TR-NETRQ-ROUTI-023The routing functionality of the device shall support the Internet Control Message Protocol (ICMP) according
specification RFC 826.
TR-NETRQ-ROUTI-024 The number of sessions supported by UDP should not be lower than 512 no matter how long the packet is
TR-NETRQ-ROUTI-025 The device shall support IETF RFC 0894 Standards for the Transmission of IP Datagrams over Ethernet Ne
TR-NETRQ-ROUTI-026 The device shall support IETF RFC 0922 Broadcasting Internet Datagrams in the Presence of Subnets
TR-NETRQ-ROUTI-027 The device shall support IETF RFC 0950 Internet Standard Subnetting Procedure
TR-NETRQ-ROUTI-028 The device shall support IETF RFC 1009 Requirements for Internet Gateways (Link Layer issues only)
TR-NETRQ-ROUTI-029 The device shall support IETF RFC 1042 Standard for the Transmission of IP Datagrams over IEEE 802 Ne
TR-NETRQ-ROUTI-030 The device shall support IETF RFC 1112 Host Extensions for IP Multicasting
TR-NETRQ-ROUTI-031 The device shall support IETF RFC 1122 Requirements for Internet Hosts Communication Layers
TR-NETRQ-ROUTI-032 The device shall support IETF RFC 1123 Requirements for Internet Hosts Application and Support
TR-NETRQ-ROUTI-033 The device shall support IETF RFC 1256 ICMP Router Discovery Messages (Router Specification only)
TR-NETRQ-ROUTI-034 The device shall support IETF RFC 1519 Classless InterDomain Routing (CIDR)
TR-NETRQ-ROUTI-035 The device shall support IETF RFC 1812 Requirements for IP Version 4 Routers
TR-NETRQ-ROUTI-036 The device shall support IETF RFC 1918 Address Allocation for Private Internets
TR-NETRQ-ROUTI-037 The device shall support IETF RFC 3600 Internet Official Protocol Standards
TR-NETRQ-SECUR Security
TR-NETRQ-SECUR-001Firewall filtering: default rules to filter NetBIOS traffic (137, 138 and 138 both tcp and udp ports) that can be c
the local and management software
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
148/221
TR-NETRQ-SECUR-002
The device shall have firewall functionality in routed mode with a minimum of 20 filter rules andthroughtput of
packets.
Firewall shall filter by origin/destination IP, mask and origin/destination TCP/UDP ports and can also filter ICM
service types and protocols.
TR-NETRQ-SECUR-003 Firewall shall support port scanning protection
TR-NETRQ-SECUR-004
Firewall shall support Denial of Service (DOS) protection for itself and all routed LAN Port Interface and Wire
Interface including protection from Ping of Death, SYN Flood LAND and variant attacks in routing mode (not
mode).
TR-NETRQ-SECUR-005 The device shall not reply to ICMP echo requests by default but it can be allowed
TR-NETRQ-SECUR-006 The supplier will describe other IP firewall functionalities
TR-NETRQ-SECUR-007 Firewall may be provided as external application installed in the user equipment
TR-NETRQ-SECUR-008The device shall support Access Control List: limited range of IP addresses (Management Center) can remo
device (telnet, ftp, tftp...)
TR-NETRQ-SECUR-009
The device shall support a functionality for Stateful Packet Inspection (SPI) firewall of network packets that h
received on the PPP Data session based at maximum speed of 16Mbit/s. The firewall shall use stateful pack
determine if an inbound connection is allowed through the firewall to the private LAN. A legitimate incoming p
matched with the outbound request for that packet and allowed in
TR-NETRQ-SECUR-010
The device shall reject packets from the WAN with MAC addresses of devices on the local LAN or invalid IP
(including but not limited to broadcast addresses, private IP addresses or IP Addresses matching those assi
DHCP Server to the LAN Port and Wireless LAN Air Interface and their attached clients).
TR-NETRQ-SECUR-019
The device shall drop or deny access requests from WAN side connections to LAN side devices and the DS
except in direct response to outgoing traffic or as explicitly permitted through configuration of the DSL device
forwarding or management)
TR-NETRQ-SECUR-020The device may support a separate firewall log to maintain records of all transactions that violate firewall rule
timestamps. This log shall hold al least the last 100 entries or 10KB text and will be only cleared when reboo
TR-NETRQ-OTHER Others
TR-NETRQ-OTHER-001 Multicasting support to provide video service
TR-NETRQ-OTHER-002 The device must comply "IGMP proxy functionality for 2xSTB IPTV connection Functionality Description v.2"
TR-NETRQ-OTHER-003 Multicasting support to provide video service. The WAN interface shall have an static IP address.
TR-NETRQ-OTHER-004
The device shall support IGMP protocol for multicasting. Configurable parameters are: robuts control, query
query interval, query response interval, group query response interval, last member query interval, last mem
and group query count.
TR-NETRQ-OTHER-005 The supplier shall provide its roadmap to include Layer 2 Multicast (similar to IGMP snooping) support into th
TR-NETRQ-OTHER-006 The device shall support IGMP protocol for multicasting. Multicast packet interchange can be allowed in the
TR-NETRQ-OTHER-007 The device shall support IGMP protocol for multicasting. Multicast group live delay can be configured
TR-NETRQ-OTHER-008 The device shall support IGMP protocol for multicasting. Multicast group live delay msec can be configured
TR-NETRQ-OTHER-009 The device shall support IGMP v2 protocol (RFC2236)
TR-NETRQ-OTHER-010 The device shall support IGMP v3 protocol (RFC3376)
TR-NETRQ-OTHER-011The device shall be able to act as IGMP proxy (using CPE MAC address when sending IGMP packets to thereceiving IGMP messages from DSLAM, sending IGMP messages to the STBs, receiving IGMP messages
sending IGMP messages to the DSLAM
TR-NETRQ-OTHER-012The device shall support IGMP snooping (preserving MAC address of the STB when sending IGMP packets
forwarding IGMP messages from DSLAM to the STBs and IGMP messages from the STBs to the DSLAM
TR-NETRQ-OTHER-013 The device must preserve IP address field of the IGMP packets sent in upstream direction to the DSLAM
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
149/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
150/221
TR-NETRQ-OTHER-032The device shall be used for Internet ADSL and Triple Play Services so it must allow concurrent deployment
O2TV and VoIP Services with respect to requisites of individual services (low latency for VoIP, errorless tran
TR-NETRQ-OTHER-033Different port configurations can be established so ports can be associated to certain services (with its own
and receive certain priority considerations being isolated from the other ports.
TR-NETRQ-OTHER-034Configuration to transport 2 data streams: Internet data (Encapsulation PPPoE as in RFC2264, IP MTU = 14
Firewall and DNS) and Video (Encapsulation EthoA RFC2684, IP MTU = 1500B)
TR-NETRQ-OTHER-035 Transported streams. Internet data services. Internal PPPoE client required
TR-NETRQ-OTHER-036
Configuration to transport 3 data streams in 3 ATM PVC Internet data (Encapsulation PPPoE as in RFC268
1492B, NAT, Firewall and DNS PVC0 VPI/VCI 8-35 To WLAN, LAN1 & LAN2 ) and VoIP (Encapsulation Eth
PVC1 VPI/VCI 8-37 to LAN4 ) with port Mapping Layer 2 and IPTV (Encapsulation EthoA RFC2684, PVC2 V
LAN3 ) with port Mapping Layer 2
TR-NETRQ-OTHER-037 Must support and be able to switch between IPoEoA using 0/101 (for ADSL2+) and PPPoE using 0/38 (for A
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
151/221
Details and comments (English)
Fully Compliant (FC)
Partially Compliant (PC)
Non Compliant (NC)
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
152/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
153/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
154/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
155/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
156/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
157/221
Cod
TR-IPV6
TR-IPV6-GENRQ
TR-IPV6-GENRQ-001
TR-IPV6-GENRQ-002
TR-IPV6-GENRQ-003
TR-IPV6-GENRQ-004
TR-IPV6-GENRQ-005
TR-IPV6-GENRQ-006
TR-IPV6-GENRQ-007
TR-IPV6-GENRQ-008
TR-IPV6-GENRQ-009
TR-IPV6-GENRQ-010
TR-IPV6-GENRQ-011
TR-IPV6-GENRQ-012
TR-IPV6-GENRQ-013
TR-IPV6-NETPT
TR-IPV6-NETPT-001
TR-IPV6-NETV6
TR-IPV6-NETV6-001
TR-IPV6-NETV6-002
TR-IPV6-BRDGE
TR-IPV6-BRDGE-001
TR-IPV6-BRDGE-002
TR-IPV6-BRDGE-003
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
158/221
TR-IPV6-BRDGE-004
TR-IPV6-BRDGE-005
TR-IPV6-CONNEC
TR-IPV6-CONNEC-001
TR-IPV6-CONNEC-002
TR-IPV6-CONNEC-003
TR-IPV6-CONNEC-004
TR-IPV6-CONNEC-005
TR-IPV6-CONNEC-006
TR-IPV6-CONNEC-007
TR-IPV6-CONNEC-008
TR-IPV6-CONNEC-009
TR-IPV6-CONNOD
TR-IPV6-CONNOD-001
TR-IPV6-CONNOD-002
TR-IPV6-CONNOD-003
TR-IPV6-CONNOD-004
TR-IPV6-WANCNTR-IPV6-WANCN-001
TR-IPV6-WANCN-002
TR-IPV6-WANCN-003
TR-IPV6-WANCN-004
TR-IPV6-WANCN-005
TR-IPV6-WANCN-006
TR-IPV6-WANCN-007
TR-IPV6-WANCN-008
TR-IPV6-WANCN-009
TR-IPV6-WANCN-010
TR-IPV6-WANCN-011
TR-IPV6-WANCN-012
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
159/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
160/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
161/221
TR-IPV6-TUNNL-006
TR-IPV6-TUNNL-007
TR-IPV6-LNDDR
TR-IPV6-LNDDR-001
TR-IPV6-LNDDR-002
TR-IPV6-LNDDR-003
TR-IPV6-LNDDR-004
TR-IPV6-LNDDR-005
TR-IPV6-LNDDR-006
TR-IPV6-LNDDR-007
TR-IPV6-LNDDR-008
TR-IPV6-LNDDR-009
TR-IPV6-LNDDR-010
TR-IPV6-DHCP6
TR-IPV6-DHCP6-001
TR-IPV6-DHCP6-002
TR-IPV6-DHCP6-003
TR-IPV6-DHCP6-004
TR-IPV6-DHCP6-005
TR-IPV6-DHCP6-006
TR-IPV6-DHCP6-007
TR-IPV6-DHCP6-008
TR-IPV6-DHCP6-009
TR-IPV6-DHCP6-010
TR-IPV6-DHCP6-011
TR-IPV6-DNSV6
TR-IPV6-DNSV6-001
TR-IPV6-DNSV6-002
TR-IPV6-DNSV6-003
TR-IPV6-DNSV6-004
TR-IPV6-DNSV6-005
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
162/221
TR-IPV6-DNSV6-006
TR-IPV6-DNSV6-007
TR-IPV6-DNSV6-008
TR-IPV6-PFWD6
TR-IPV6-PFWD6-001
TR-IPV6-PFWD6-002
TR-IPV6-PFWD6-003
TR-IPV6-CNFWD
TR-IPV6-CNFWD-001
TR-IPV6-CNFWD-002
TR-IPV6-CNFWD-003
TR-IPV6-CNFWD-004
TR-IPV6-CNFWD-005
TR-IPV6-CNFWD-006
TR-IPV6-CNFWD-007
TR-IPV6-FWBSC
TR-IPV6-FWBSC-001
TR-IPV6-FWBSC-002
TR-IPV6-FWBSC-003
TR-IPV6-FWBSC-004
TR-IPV6-FWBSC-005
TR-IPV6-FWBSC-006
TR-IPV6-FWBSC-007
TR-IPV6-FWSPI
TR-IPV6-FWSPI-001
TR-IPV6-FWSPI-002
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
163/221
TR-IPV6-FWSPI-003
TR-IPV6-FWSPI-004
TR-IPV6-FWSPI-005
TR-IPV6-FWSPI-006
TR-IPV6-FWSPI-007
TR-IPV6-FWSPI-008
TR-IPV6-FWSPI-009
TR-IPV6-FWSPI-010
TR-IPV6-FWSPI-011
TR-IPV6-FWSPI-012
TR-IPV6-FWSPI-013
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
164/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
165/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
166/221
WAN.BRIDGE.6 - The device MUST be able to manage IPv6 bridging separately for each WAN interface (if there are
multiple WAN interfaces).M
WAN.BRIDGE.7 - When IPv6 bridging is enabled on a WAN interface, the device MUST be configurable to act as a host on
that WAN interface (doing SLAAC, etc.). It will not request IA_PD, since that is not a host function.M
IPv6 CONNECT - Connection Establishment
This module applies to IPv6 connections as well as IPv4, but only if the device has an IPv6 stack. I
WAN.CONNECT.1 - The device MUST support an "always on" mode for connections. In this mode the device MUST NOT
time out connection sessions (ATM, IP and PPP) and MUST automatically re-establish anysessions after disconnection,lease expiration or loss and restoration of power. M
WAN.CONNECT.2 - Moved to WAN.CONNECT.ON-DEMAND.1 and 4 M
WAN.CONNECT.3 - The device MUST support a manual connect option for connections. In this mode the connection tothe broadband network is initiated manually through the GUI or via TR-064/TR-069 request and, by default, terminates only
when done so explicitly by the user, due to a power loss or when the connection is lost.
M
WAN.CONNECT.4 - Moved to WAN.CONNECT.ON-DEMAND.6 M
WAN.CONNECT.5 - A manual way of disconnecting without waiting for a connection timeout MUST be provided. M
WAN.CONNECT.6 - Moved to WAN.CONNECT.ON-DEMAND.7 M
WAN.CONNECT.7 - The device MUST follow all standards required to perform an orderly tear down of the associated
connections involved at the associated network levels (e.g., issue a DHCPRELEASE message when using DHCPv4, issue
LCP Terminate-Request/Terminate-Ack and PADT packet when using PPPoE, etc.) and then restart the connections.
M
WAN.CONNECT.8 - The device MUST detect the loss of communications with a network identified DNS server as indicated
by a failed query, and upon failed query, log the event.M
IPv6 - CONNECT.ON-DEMAND - On-Demand Connection Establishment
WAN.CONNECT.ON-DEMAND.3 - If the PPP session contains IPv4 and IPv6, then the device MUST terminate only the
IPv4 session. This will be done using IPCP commands.M
WAN.CONNECT.ON-DEMAND.6 - The interval after which a connection timeout occurs MUST be able to be configured. M
WAN.CONNECT.ON-DEMAND.7 - A default timeout of 20 minutes SHOULD be used for connection timeouts or use an
operator-specific configurationM
WAN.CONNECT.ON-DEMAND.8 - If the device has an active IPv6 connection, and does not have addresses for DNS
recursive name servers to be accessed over IPv6, then the "connect on demand" option MUST be disabled.M
IPv6 - WAN ConnectionWAN.IPv6.1 - The device MUST support automated establishment of an IPv6 connection according to the flow in Annex A.2
of TR-124 issue 2M
WAN.IPv6.2 - The device MUST support dual stack of IPv4 and IPv6 running simultaneously, as described in Section 2 of
RFC 4213, Transition Mechanisms for IPv6 Hosts and Routers.M
WAN.IPv6.3 - The device MUST allow the IPv6 stack to be enabled / disabled. M
WAN.IPv6.6 - The device MUST support specifying in its DHCPv6 prefix delegation request an indication of the length of
prefix it requires.
If the RG supports multiple LANs, or has PD requests from its LAN, it MUST indicate a preferred prefix length at least equal
to the longest length that would enable the RG to assign a /64 prefix to each LAN it supports. Note that the delegated prefix
may vary from the requested length
M
WAN.IPv6.7 - When sending DHCPv6 messages, the device MUST identify itself in OPTION_CLIENTID (1) (client-identifier)
using the same client identifier as for IPv4 (see WAN.DHCPC.3 and .4).M
WAN.IPv6.8 - The device MUST support IPv6 Node Requirements as a host node, per IETF RFC 4294. Note that RFC
2461 reference by RFC 4294 has been obsoleted by RFC 4861.M
WAN.IPv6.9 - The device MUST support stateless address auto-configuration (SLAAC), as a host, per IETF RFC 4862. M
WAN.IPv6.10 - The device MUST support receipt of route information per RFC 4191. If the device only has one WAN
connection, it does not need to place this information in its routing table, but it does need to save it (for possible sending on
the LAN interface).
M
WAN.IPv6.11 - If route information is provided (RFC 4191) and the device has multiple WAN connections, it MUST place
the route information in its routing table.M
WAN.IPv6.12 - If the device does not have a globally-scoped address on its WAN interface after being delegated a prefix, it
MUST create addresses for itself from the delegated prefix. It MUST have at least one address and MAY have more. There
is currently no algorithm defined for address creation and it should be assumed that different service providers will want
different rules for how to create the address, how many addresses to create, and, in the case of multiple addresses, how the
different addresses are used.
M
WAN.IPv6.13 - The device MUST support enabling / disabling of this IPv6 WAN connection interface. M
WAN.IPv6.17 - The connectivity parameters (obtained via RA and DHCPv6) MUST be persistent across loss of WAN
connection (or lack of response from WAN connection).M
WAN IPv6 18 The device MUST continue to use the connectivity parameters (obtained via RA or DHCP) and consider
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
167/221
-
7/28/2019 BHS_ADSL2_Tech_Reqs_rev3
168/221
WAN.QoS.4 - The device MUST by default recognize and provide appropriate treatment to packets marked with
recommended Diffserv Codepoints, whose values and behavior are defined in IETF RFC 2474, 2475, 2597, 3246, and 3260.
Specifically, the values shown in the DSCP column of the table below MUST be supported, except the Cs0-7, which are
optional.
M
WAN.QoS.5 - The device MUST be able to mark or remark the Diffserv codepoint or IEEE 802.1D Ethernet priority of traffic
identified based on any of the classifiers supported by the device.M
WAN.QoS.6 - The device SHOULD support sending the following frame types: untagged frames, priority-tagged frames, and
VLAN-tagged frames in the upstream direction. This satisfies TR-101 R-01.M
WAN.QoS.7 - The device SHOULD support setting the priority tag and VLAN ID values. This satisfies TR-101 R-02. M
WAN.QoS.8 - The device SHOULD support receiving untagged and VLANtagged Ethernet frames in the downstream
direction, and SHOULD be able to strip the VLAN tagging from the ones received tagged. This satisfies TR-101 R-03.M
WAN.QoS.9 - The device MUST support one Best Effort (BE) queue, one Expedited Forwarding (EF) queue and a minimum
of four Assured Forwarding (AF) queues.M
WAN.QoS.10 - The device MUST duplicate the set of queues for each access session. This can be done logically or
physically.M
WAN.QoS.11 - The device SHOULD support the appropriate mechanism to effectively implement Diffserv per hop
scheduling behaviors. A strict priority scheduler is preferred for EF.M
WAN.QoS.12 - The device SHOULD support aggregate shaping of upstream traffic. M
WAN.QoS.13 - The device SHOULD support per-class shaping of upstream traffic. M
WAN.QoS.14 - The device MUST support the capability to fragment traffic on sessions that it originates, in order to
constrain the impact of large packets on traffic delay.M
WAN.QoS.15 - The packet s ize threshold before fragment ing AF and BE packets MUST be configurable. M
QoS.TUNNEL - Quality of Service for Tunneled Traffic
This module only applies when the device is an endpoint for a tunnel to
the WAN. Note