Вы находитесь на странице: 1из 130

1.

Development requirements

2. Functional classification
Main blocks are:

3. Glossary

4. Operation Business Reference

1. 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 of compliance 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.

2. Functional classification
Main blocks are: General WAN Interfaces LAN Interfaces Core Functionality Services Management Documentation

3. 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

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 EM: Eletro Magnetic 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 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. POST: Power On Self Test 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 Key PSTN: 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. TBB Client: Telefonica Broad Band Client 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 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

4. Operation Business Reference


In the Scope of this document, the following definitions are applicable for defining the Country of the Telefonica Opetarion Business (OBs) ColTel: Colombia O2CR: Czech Republic O2DE: Germany TASA: Argentina TCh: Chile TdP: Peru TE: Spain (Espaa) Telesp: Brazil TLATAM: Latin America (Argentina, Brazil, Chile, Colombia, Peru)

Cod TR-GENRQQ TR-GENRQQ-MECDE TR-GENRQQ-MECDE-001 TR-GENRQQ-MECDE-002 TR-GENRQQ-MECDE-003 TR-GENRQQ-MECDE-004 TR-GENRQQ-MECDE-005 TR-GENRQQ-MECDE-006 TR-GENRQQ-MECDE-007 TR-GENRQQ-MECDE-008

Description General Requirements Mechanical Design The device shall be designed to allow vertical (wall mount) and horizontal mounting (desktop design). The casing must be according to what will be decided by Telefonica Power supply size shall not block or obstruct the use of the adjacent plugs The device housing shall be white The plastic of the device will be ABS+PC The device should use sockets colour scheme as in TR-068: Yellow (114c pantone) Ethernet ports Black power connector Gray (matte cool gray 3U) phone ports The device shall have an ON/OFF labelled power button The device shall have a reset button to restore default configuration. The button must be located at the back of the unit The device shall have a WPS button to activate the simplified configuration WPS method. This same button can be used for turn on/off the WLAN functionality (the on/off WLAN functionality should be present only on the OBs that indicate the request for this functionality)

Ctg. Details and comments (Spanish)

M M M M M M M M

TR-GENRQQ-POWSU

Power Supply The device shall be designed for a local power supply AC mains: 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%) Device power input type: DC The device power adaptor can be external or internal The device power adapter shall be an automatic power switch The device power cord minimum length shall be 2 meters TE: 220-230V / 50Hz; M

TR-GENRQQ-POWSU-001

TR-GENRQQ-POWSU-002 TR-GENRQQ-POWSU-003 TR-GENRQQ-POWSU-004 TR-GENRQQ-POWSU-005

M M M M La fuente de alimentacin actual tiene un cable de 1.5m. sta se puede customizar siguiendo el requisito de Telefnica si Comtrend entra en lista corta. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta. La fuente de alimentacin es de tipo externa

TR-GENRQQ-POWSU-006

Power supply must be according to each conutry

Argentina

Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta.

Brazil

Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta.

Chile

Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta.

Colombia

Peru

UK

Spain

Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta.

TR-GENRQQ-POWSU-007 TR-GENRQQ-POWSU-008 TR-GENRQQ-POWSU-009 TR-GENRQQ-POWSU-010

Power supply shall be labelled with device model and name In case of power interruption the device shall reboot automatically The device can not be powered via RJ11 interface Power supply shall be according to EU RD 278/2009 The device shall accomplish the European Union Code of Conduct on Energy Consumption of Broadband Equipment Version 4 from 10 February 2011(Tier 2013-2014), supporting a maximum of 12V DC and 1,5A and a have a female compatible connector: - External diameter: 5,50,05mm - Internal Diameter: 2,10,1mm - Length: 9,00,1mm The Power supply must be in conformity with Telefonica specification for Universal Power supply as defined on the document ERQ.c1.0001 3rd edition / Jul 2011 (document in Spanish) Indication of Operating Status In the frontal side of the equipment it has to be included the following LEDS

M M I M

Telefnica tiene que proporcionar el texto de la etiqueta.

TR-GENRQQ-POWSU-011

TR-GENRQQ-POWSU-012 TR-GENRQQ-OPSTA

TR-GENRQQ-OPSTA-001

Nuestro diseo actual tiene los siguientes LEDs: encendido, WPS, WLAN, LAN1X, LAN2X, LAN3X, LAN4X, ADSL, Internet y USB. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta.

TR-GENRQQ-OPSTA-002 TR-GENRQQ-OPSTA-003 TR-GENRQQ-OPSTA-004 TR-GENRQQ-OPSTA-003 TR-GENRQQ-ELCHA

The frontal Led indicating the Ethernet functionality should be a single led for the four LAN pors In the Back side of the device it may have indibidual Led for each of the Ethernet ports A 2 Hz blinking Green-Red round of Broadband led should inform the firmware updating and flash memory writing Additionaly to LED indicators the supplier may provide user software to monitor device activity Electrical characteristics

I M M O Los LEDs LAN se encuentran en el frontal del equipo

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 signal) 4.6 (voice channel longitudinal balance) 4.7 (insulation resistance between line terminals and ground) 4.8 (voice channel input impedance) sections 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 stages - less than 15 noise impulses with a maximum of 65dBrncO (at 1.004Hz, -13dBm0) in 15 minutes during initiation and operation stages. The equipment will meet the established requirements in TS 202 913 V1.2.2 Recommendation in the applicable aspect. DSL channel longitudinal balance: the device shall comply with the requirements of section 12.3.1 of ANSI T1.413-1998 and section A.4.3 of ITU-T G.992.1 DSL channel longitudinal balance must be higher than 40dB at [20 - 1.100]kHz when charging the DSL interface with 600ohm DSL channel nominal impedance of 100ohm at DSL band in the PSTN interface DSL channel return loss at 30Hz - 1.100kHz equal or higher to 10dB Noise level inserted by the device to the DSL channel of the PSTN line shall be lower than -65dBmp Error rate caused by cross-talk interference shall be better than 10e-7 for a minimum noise margin of 6dB (measured as defined in paragraph 5.41: Measuring cross-talk noise margin of ETSI TS 388 V 1.3.1) taking into account the improvement due to the error correction mechanism Errors due to impulsive noise at DSLAM interface shall be less than 0.14% error seconds (up to 15 impulses during 15min and with 1sec between impulses) as defined in ANSI T1.413, section 11.2.2 and ITU-T G.996.1, section 8. The analog ports shall perform according to ETSI ES 201 970 v1.1.1 Inband noise (psophometrically weighted) for narrowband audio (300Hz 3.4kHz) shall be less than 75.0 dBVp Inband noise (psophometrically weighted) for wideband audio (50Hz - 7kHz) will be less than 75.0 dBVp Out-of-band noise (psophometrically weighted) for the human audible spectrum (30Hz - 20kHz) shall be less than 67.0 dBVp Noise at mains frequency (50Hz) should not exceed 0.25 mV (psophometric weighed), this being the value at the line terminals of the subscriber's set (when receiving). The subscriber's set assumed is only powered by the analogue line. (i.e. half of the value in G.120 paragraph 6.1) ALASS and other enhanced services as in 14.3 of ES 201 970 shall be supported Climatic Conditions The device shall comply ETSI 300 019-1-1 to ETSI 300 019-1-8 standards: - class 1.2 device for storage in non temperature-controlled environments - class 2.3 for public transportation - class 3.1 for operation in temperature-controlled environments (5-45C, 5-85% relative humidity, 880-1060mbar and a solar radation of 700w/m2) The device shall be ready to be installed in non temperature or humidity controlled indoor environments at 0-50C and 595% relative humidity conditions Storage temperature [-25, 70]C Device electrical values shall be accomplished in the range [-10,60]C, humidity class F and after 2 hours (DIN 40046).

TR-GENRQQ-ELCHA-002

TR-GENRQQ-ELCHA-003 TR-GENRQQ-ELCHA-004 TR-GENRQQ-ELCHA-005 TR-GENRQQ-ELCHA-006 TR-GENRQQ-ELCHA-007 TR-GENRQQ-ELCHA-008 TR-GENRQQ-ELCHA-009

M M M M M M M

TR-GENRQQ-ELCHA-010 TR-GENRQQ-ELCHA-011 TR-GENRQQ-ELCHA-012 TR-GENRQQ-ELCHA-013 TR-GENRQQ-ELCHA-014 TR-GENRQQ-ELCHA-015 TR-GENRQQ-ELCHA-016 TR-GENRQQ-CLICO

M M M O M M M Nuestro equipo no tiene puerto FXS Nuestro equipo no tiene puerto FXS Nuestro equipo no tiene puerto FXS Nuestro equipo no tiene puerto FXS Nuestro equipo no tiene puerto FXS

TR-GENRQQ-CLICO-001

TR-GENRQQ-CLICO-002 TR-GENRQQ-CLICO-003 TR-GENRQQ-CLICO-004

M M M

TR-GENRQQ-CLICO-005

The device shall correctly work in salted environments (coast areas) as defined on the UNE 20 502-2-3 (Eletrical equipments and components), and shall be provide a certification of this functionality from result of tests on a third part laboratory (as defined on ASTM-B117 Salt spray test.) Security and Protection The device shall comply with the 73/23/CEE directive and the amendments to the 93/68/CEE directive The device shall tolerate security level 3 ESD as in IEC 801, part 2, sections 7 and 8. It's not allowed any alteration over its components due to contact or air discharges Minimum resistance shall be 100Mohm when 100Vcc applied between cover and line contacts, cover and power wires and contacts and power wires Test device manufacturer must supply beforehand the corresponding user safety certification and associated reports issued by an accredited laboratory (EU directive 2006/95/CE compliance). Other norms applicable (technical normative): - UNE EN 60950-1:2006+A11:2009 - EN 50371:2002 - EU Directive 99/05/CE

TR-GENRQQ-SECPR TR-GENRQQ-SECPR-001 TR-GENRQQ-SECPR-002 TR-GENRQQ-SECPR-003

M M M

TR-GENRQQ-SECPR-004

TR-GENRQQ-ELECO TR-GENRQQ-ELECO-001 TR-GENRQQ-ELECO-002 TR-GENRQQ-ELECO-003 TR-GENRQQ-ELECO-004

Electromagnetic Compatibility The device shall comply with the 89/336/CEE directive and the amendments to the 93/68/CEE directive (reviewed if newer directives) The device shall comply ETSI 300 127, EM 55022-Classe A No EM interferences between device and PSTN The 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 power signal, WiFi interface shall comply with EN 300 328: Electromagnetic compatibility and Radio spectrum Matters (ERM) in Wideband Transmission systems when data transmission equipment operate in the 2,4 GHz ISM band and uses spread 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 WiFi interface shall comply with EN 301 489: Electromagnetic compatibility and Radio spectrum Matters (ERM). 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

M M M M

TR-GENRQQ-ELECO-005

Comtrend obtendr el certificado EN300 328 cuando est en lista corta.

TR-GENRQQ-ELECO-006

Comtrend obtendr el certificado EN300 328 cuando est en lista corta.

TR-GENRQQ-OVERR TR-GENRQQ-OVERR-001 TR-GENRQQ-OVERR-002

Overvoltage and Overcurrent Resistibility The device shall comply with the requirements of ITU-T Recommendation K.21 Power supply shall resist (1000Vrms, 50/60Hz, 200mA current drain) for 30sec between phases and between each phase and ground. After this test the isolated resistance of the power supply must be at least 200Mohm measured with 500Vcc

M M El adaptador de alimentacin del equipo tiene proteccin contra sobrecorrientes y sobrevoltajes. Si el equipo (CPE) debe tenerlo, Comtrend puede modificarlo. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta.

TR-GENRQQ-OVERR-003

The device shall have output overcurrent and overvoltage protection

TR-GENRQQ-OVERR-004 TR-GENRQQ-OVERR-005

The device shall have a protection fuse The device shall have minimum resistance 1Mohm

M M

TR-GENRQQ-OVERR-006 TR-GENRQQ-CONNE

On a case of Overvoltage and/or overcurrent, the device shouldn't lose the configurations and shall preserve the Firmware Version unaffected Connectors It shall be ensured good contact between the plug and socket plug elements (male and female conectors) and that the degradation that occurs over time is not significant for the continuity of contact. To ensure this behavior the gold coating thickness shall be of at least 1.27 m. (micrometers). in this case no further testing will be needed. If the thickness of gold coating is between 0.4 m and 1.27 m, willl be performed additional tests to verify the quality of the connectors. Under no circumstances accept lower coating thicknesses of 0.4 um of gold. In the case of filter elements, microfilters, dividers etc ... the gold coating is always equal to or greater than 1.27 um. The device shall have a RJ11 female connector for the WAN interface and use its internal pair (3rd and 4th wires) The device shall have 4xRJ45 female connectors for the LAN interface according the specification ANSI EIA TIA-568B (to be used with UTP cat5 cables) Environmental Requirements The device shall have low environmental impact. So it shall be produced using materials: tagged for recycling, without CFC, without cadmium, solvent-free (water-based lacquers) with reusable packaging or failing foams without CFCs, biostables and fuel, disposable in landfills or incinerators Freefall The device shall be EM 60068-2-32 regulation compliant

TR-GENRQQ-CONNE-001

TR-GENRQQ-CONNE-002 TR-GENRQQ-CONNE-003 TR-GENRQQ-ENVRQ TR-GENRQQ-ENVRQ-001

M M

HR

TR-GENRQQ-FREEF TR-GENRQQ-FREEF-001

TR-GENRQQ-PPCAS TR-GENRQQ-PPCAS-001 TR-GENRQQ-PPCAS-002

Production Process Control and Samples The supplier shall provide the samples and means to perform quality tests Device sample for approval test shall be identified by producer name, model name, version, serial number, SW version, chipset model and manufacturer and FW version 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 Telefonica in order to take actions if necessary and any SW/HW modifications shall be notified. The device shall have a life cycle (the supplier shall be able to ship devices during 24 months from the tender beginning) of: - O2CR and TLATAM: 2 years The device shall ensure a Mean Time Between (Hardware) Failure of: - O2CR: 100 days - O2DE and ColTel: at least 1 year Faulty (total or partial) device rate = maximum 1 per 100 devices per year The device manufacturer shall provide a TR069 Score Card Certificate Requirements. The device manufacturer shall provide a TR069 Certification on RFATS date for each firmware version of the device. All mandatory TR-069 methods must be passed.The device must achieve 100% compliance for all profiles from the TR-098 datamodel requested in this document. M M

TR-GENRQQ-PPCAS-003

TR-GENRQQ-PPCAS-004

TR-GENRQQ-PPCAS-005 TR-GENRQQ-PPCAS-006 TR-GENRQQ-PPCAS-007

M M M

TR-GENRQQ-PPCAS-008

TR-GENRQQ-PPCAS-009

The device supplier shall perform Interoperability Tests (IOT) with the supplier of Auto-Configuration Server that the OB has selected before shipment of the devices. The OB shall inform the device supplier in advance but the supplier may also provide a list of the ACS systems on which IOT have been performed. The device manufacturer shall provide IEEE 802.11n WECA Certification (according to the last avaliable version) by WIFI Alliance accredited test laboratory. A list of 3rd party Wifi devices and tested firmware version has to be provided by the device manufacturer Power On Self Test During the boot process, the CPE will make a POST (Power On Self Test) about the following components at least: main chipset, ADSL Chipset, chipset wifi, memory and switch ethernet. If during this process, some bugs are detected and the CPE isn't going to be able to boot or isn't going to work properly, the power led will light red, as says the technical specification TR-068, paragraph I-30 (Base Requirements for an ADSL Modem with Routing). If during this process,the FW isn't in the CPE or there is a FW error and the CPE isn't going to be able to boot, the power led will blink red. Others Non device status dependant phone service The supplier must be certified or commit to a deadline for certification in local regulator of each country

TR-GENRQQ-PPCAS-010

TR-GENRQ-POSTT

TR-GENRQ-POSTT-001

TR-GENRQQ-OTHER TR-GENRQQ-OTHER-001 TR-GENRQQ-OTHER-002

M M

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC FC FC FC FC FC FC FC

FC

FC Our device power adapter is external FC FC Current adapter is 1.5 meters length for power cord. Comtrend can make a customization FC following your request when we are short list. Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Comtrend can make a customization following FC your request when we are short list.

Telefonica has to provide the new label text.

FC FC FC FC

Our current design is 12V 1A.

PC

FC

LED description table shown on Req 29 of the main RFQ docuemnt (paragraph 3.8 Hardware) Our current Hardware has power, WPS, PC WLAN, LAN1X, LAN2X, LAN3X, LAN4X, ADSL, Internet and USB LEDs. Comtrend can make a customization following your request when we are short list.

FC LED provided in the front panel PC FC

FC

FC

FC FC FC FC FC FC FC

FC Our CPE doesnt have FXS port Our CPE doesnt have FXS port Our CPE doesnt have FXS port Our CPE doesnt have FXS port Our CPE doesnt have FXS port NC NC NC NC NC NC

FC

FC FC FC

FC

FC FC FC

FC

FC FC FC FC

Comtrend is going to get EN300 328 certificate when we are short list.

FC

Comtrend is going to get EN300 328 certificate when we are short list.

FC

FC FC

Comtrend adpater have output overcurrent and overvoltage protection; If CPE should have it, Comtrend can make a customization.

FC

Comtrend can make a customization following FC your request when we are short list. FC

FC

FC

FC FC

FC

FC

FC FC

FC

FC

FC FC NC

FC

FC

FC

FC

FC FC

Cod TR-PHLRQ TR-PHLRQ-WANTC TR-PHLRQ-WANTC-001 TR-PHLRQ-WANTC-002 TR-PHLRQ-WANTC-003 TR-PHLRQ-WANTC-004 TR-PHLRQ-WANTC-005 TR-PHLRQ-WANTC-006 TR-PHLRQ-WANTC-007 TR-PHLRQ-WANTC-008 TR-PHLRQ-WANTC-009 TR-PHLRQ-WANTC-010 TR-PHLRQ-WANTC-011 TR-PHLRQ-WANTC-012 TR-PHLRQ-WANTC-013 TR-PHLRQ-WANTC-014 TR-PHLRQ-WANTC-015 TR-PHLRQ-WANTC-016

Description Physical Layer Requirements Wan Access Technology The device shall interoperate with any supplier DSLAM The device shall support a physical interface to connect, transmit and receive data from/to a DSL port that is compliant to the recommendation [T-Com TR112 (U-R2)]. The device shall have an ADSL over ISDN interface with 2B1Q modulation The device shall comply the standard ANSI T1.413: ADSL The device shall comply the standard G992.1 (G.DMT): ADSL transceivers using DMT modulation The device shall comply the standard G992.2 (G.Lite): ADSL Lite The device shall comply the standard G992.3: ADSL2 The device shall comply the standard G.992.3 Annex L: Extended Range ADSL2 The device shall comply the standard G.992.3 Annex M: Increased Upload Speed ADSL2 The device shall comply the standard G992.5: ADSL2+ The device shall comply the standard G.992.5 Annex L: Extended Range ADSL2+ The device shall comply the standard G.992.5 Annex M: Increased Upload Speed ADSL2+ The DSL standard (ADSL/ADSL2/ADSL2+) to be used shall automatically negotiated between device and DSLAM.Higher speed DSL standard has priority and it is also allowed to statically enable/disable the use of each DSL standard. Transmitters reference model as in T1.413-4, G.992.1-5, G.992.2-4, G.992.3-5 and G.992.5-5 (depending on the standards supported by the operator). The device shall support ATM data transport over DSL as in T1.413-5.2, G.992.1-6.2, G.992.2-5 The device shall support ATM Transport Protocol Specific functionalities over DSL (ATM TPS-TC sublayer) as in ANSI T1.413-7.2, G.992.1-8.2, G.992.2-7.1, G.992.3-6 and Annex K.2 (all parameters in K.2.7.i and K.2.10 can be configured) and G.992.5-6 and Annex K (depending on the standards supported by the operator). The transport model will mandatory be ATM according to the reference model of ANSI T1.413 section 4.2.2. of the regulation. If STM mode is supported, it will be considered a value added, according to ANSI T1.413 section 4.2.1. If STM mode is supported, it will be considered as a value added to support all whats specified in ANSI T1.413 section 5.1 The device shall operate in Simple Latency Mode (upload or download independent) as in T1.413-5.2, G.992.1-6.2, G.992.3 and G.992.5 (depending on the standards supported by the operator) The device should be able to operate in Dual Latency Mode (upload or download independent) as in T1.413-5.2, G.992.16.2, and G.992.3 (depending on the standards supported by the operator) The device shall support PTM Transport Protocol Specific Transmission Convergence functions over ADSL2 as in ITU G.992.3, Section 6 and Annex K.3. All parameters in K.3.7.i and K.3.10 can be configured. The device shall support Physical Media Dependent function as in G.992.3-8 and G.992.5-8 (control parameters as in G.992.3-8.5) The device shall support Physical Media Specific Transmission Convergence function as in G.992.3-7 and G.992.5-7 (transport capabilities as in G.992.3-7.1 and control parameters as in G.992.3-7.5) The device shall support Management Plane Procedures as in G.992.3, section 9 with the primitives described in G.992.38.12.1, G.992.3-8.12.2 and G.997.1. The L0, L1 and L3 states are mandatory as well. The Management Plane Procedure feature will be mandatory supported, according to whats described in G.992.5 section 9.4

Ctg. Details and comments (Spanish)

M M M M M M M M M M M M M M M M

TR-PHLRQ-WANTC-017 TR-PHLRQ-WANTC-018 TR-PHLRQ-WANTC-019 TR-PHLRQ-WANTC-020 TR-PHLRQ-WANTC-021 TR-PHLRQ-WANTC-022 TR-PHLRQ-WANTC-023 TR-PHLRQ-WANTC-024 TR-PHLRQ-WANTC-025

M M M M O M M M M

TR-PHLRQ-WANTC-026 TR-PHLRQ-WANTC-027 TR-PHLRQ-WANTC-028 TR-PHLRQ-WANTC-029 TR-PHLRQ-WANTC-030 TR-PHLRQ-WANTC-031 TR-PHLRQ-WANTC-032 TR-PHLRQ-WANTC-033 TR-PHLRQ-WANTC-034 TR-PHLRQ-WANTC-035 TR-PHLRQ-WANTC-036 TR-PHLRQ-WANTC-037 TR-PHLRQ-WANTC-038 TR-PHLRQ-WANTC-039 TR-PHLRQ-WANTC-040 TR-PHLRQ-WANTC-041 TR-PHLRQ-WANTC-042 TR-PHLRQ-WANTC-043 TR-PHLRQ-WANTC-044 TR-PHLRQ-WANTC-045 TR-PHLRQ-WANTC-046 TR-PHLRQ-WANTC-047 TR-PHLRQ-WANTC-048 TR-PHLRQ-WANTC-049 TR-PHLRQ-WANTC-050 TR-PHLRQ-WANTC-051 TR-PHLRQ-WANTC-052 TR-PHLRQ-WANTC-053 TR-PHLRQ-WANTC-054 TR-PHLRQ-WANTC-055

The device shall support Power Management functionalities as in G.992.3, section 9.5 The Power Management feature will be completely supported according to whats described in G.992.3 section 9.5, 8.17 and 10.3. This is, the three states described in the regulation (L0, L2 and L3) must be supported. The device shall support Programmed reduce framing overhead as in G.992.3 The device shall operate ensuring 10e-7 BER or better with a security noise margin The device shall support Fast and Interleaved transmission modes The device shall support Interleaved transmission mode providing protection against impulsive (INP) noise as in G.992.3, including Annex K.2.7 The device shall transport ATM data over DSL using frames with the format defined in T1.413-6.4, T1.413-7.4, G.992.1-7.4 and G.992.1-8.4. The Formats 0, 1, 2, 3 and for are mandatory as well The device shall transport ATM data over ADSL2 using frame format defined in G.992.3-7.6 with programmed reduction of overhead. The device shall transport ATM data over ADSL2+ using frame format defined in G.992.5-7.6 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.1-8.3, G.992.27.2 and G.992.3-7.8 (depending on the DSL standard in use).The NTR sent by the DSLAM is reconstructed in the device as in T1.413-5.2 The 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 and G.992.37.7.1.3 (depending on the DSL standards supported) The device shall use CRC checksums to detect errors The 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.2, G.992.3, G.992.5 (depending on the DSL standards supported) 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 be supported. FEC Reed-Solomon coding support (with 3 words per symbol when G.992.5 is in use) The 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 able to interoperate with DSLAM with no Trellis Coding Modulation. The device shall support one-bit constellation encoding The device shall use Constellation Encoding (no Trellis) with a maximum number of bits per carrier between 8 and 15 as in T1.413-7.9, G.992.1-7.9 and G.992.1-8.9 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 (depending on the DSL supported standards) 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 Annex A The device shall use 1.1MHz bandwidth and 256 subcarriers for T1.413/G.992.1/G.992.3 and 2.2MHz and 512 subcarriers for G.992.5 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 A The device shall perform Frequency Bands Separation using FDM Besides FDM the device can use Echo Cancellation to perform Frenquency Bands Separation but only if FDM interoperability is guaranteed The device shall use DMT modulation with 4,3125 kHz between subcarriers The device shall control subcarriers transmission spectrum The device shall respect the frame structure "reduced overhead with merged fast and sync bytes" according to G.992.1 item 7.4.3.2 using interleaved buffer The pilot carrier (276kHz) cannot be modulated or transport user data when using T1.413, G.992.1 or G.992.2 but it does when using G.992.3 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 The device transmitter dynamic range shall comply T1.413-6.13, T1.413-7.13, G.992.1-7.13 and G.992.1-8.13 (depending on the DSL supported standards)

M M M M M M M M M M M M M M M M M M M M M M M O M M M M M M

TR-PHLRQ-WANTC-056 TR-PHLRQ-WANTC-057 TR-PHLRQ-WANTC-058 TR-PHLRQ-WANTC-059

The device transmitter spectral response shall comply T1.413-6.14, T1.413-7.14, G.992.1-7.14, G.992.1-8.14 and G.992.1 (depending on the DSL supported standards) The device transmitted power spectral density and aggregate power level shall comply ANSI T1.413-1998, section 7.15. Device Initialization Sequence as in T1.413-9, G.992.1-10 and annexes. The R-QUIET2 parameter duration shall be between 128 and 4000 and a maximum interleaving depth at least of 64. Device Initialization Sequence as in G.992.3-8.13, G.992.3, G.992.5 and transactions as in G.994.1-10 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 The device should support RETRAIN and RESYNC states as in G992.3 Annex D The device should support RETRAIN and RESYNC states as in T1.413 Annex A EOC (Embedded Operation Channel) availability as in T1.413-8.1 and G.992.1-9.1 and requirements as in G.992.1-9.2 (depending on DSL supported standards). The device must support Dying Gasp (device Loss Of Power announcement) using free EOC (Embedded Operation Channel) 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. The device should support In-service performance monitoring and surveillance as in T1.413-8.2 and G.992.1-9.3 The Device Should Support failure count parameters as in T1.413-8.2.4.3, line far-end failures detection as in T1.4138.2.5.2, atm far-end failures as in T1.413-8.2.7.2 and near-end performance monitoring functions as in T1.413-9.3 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.4.1.2 Values reserved for signalling, OAM functions and resources management shall not be used for data transmission The device shall be able to perform OLR (OnLine Reconfigurations) to ensure good operation when line or environment conditions change as in T1.413-10 and G.992.1-11. The device shall include OLR feature Bit Swapping to perform seamless re-allocation of bits between sub-carriers without interrupting the data flow as in G.992.3-10.2.1 The device shall include OLR feature Dynamic Rate Repartitioning (DRR) to reallocate bandwidth between the fast and interleave channels as in G.992.3-10.2.1 and G.992.5. This feature can be enabled/disabled by the ISP The device shall include OLR feature Seamless Rate Adaptation (SRA) to avoid dropping the connection changing the bit rate to accommodate temporary line conditions in G.992.3-10.2.1 and G.992.5. This feature can be enabled/disabled by the ISP The device shall include OLR feature Dynamic Rate Adaptation (DRA) as in T1.413 Annex K and G.992.1 Annex G, appendix II Operation bit rate can be fixed or adaptative The device shall be able to set up both asymmetrical and symmetrical bit rate connections. Those bit rates must be supported depending on the settings in the ADSL-LTs Operation bit rate depends on line characteristics so ATM data bit rate will be adapted in 32kbps steps.

M M M M

TR-PHLRQ-WANTC-060

TR-PHLRQ-WANTC-061 TR-PHLRQ-WANTC-062 TR-PHLRQ-WANTC-063 TR-PHLRQ-WANTC-064 TR-PHLRQ-WANTC-065 TR-PHLRQ-WANTC-066 TR-PHLRQ-WANTC-067 TR-PHLRQ-WANTC-068 TR-PHLRQ-WANTC-069 TR-PHLRQ-WANTC-070 TR-PHLRQ-WANTC-071 TR-PHLRQ-WANTC-072 TR-PHLRQ-WANTC-073 TR-PHLRQ-WANTC-074 TR-PHLRQ-WANTC-075 TR-PHLRQ-WANTC-076

M O M M M O M M M M M M HR M M M

TR-PHLRQ-WANTC-077

The vendor must provide information about minimum and maximum upstream and downstream ATM bit rates: - TE requires a minimum upstream bit rate of 800kbps and a minimum downstream bit rate of 8Mbps using ADSL ANSI T1413 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 kbps when using ADSL (T1.413 or G.DMT), a minimum upstream bit rate of 600kbps and a minimum downstream bit rate of 1500 kbps when using ADSL Lite (G.Lite), a minimum upstream bit rate of 900kbps and a minimum downstream bit rate of 12000 kbps when using ADSL2 (G.992.3)and a minimum upstream bit rate of 900kbps and a minimum downstream bit rate of 22000 kbps 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 8000 kbps. If the device needs a minimum link length larger than 0km the supplier shall report that value.

TR-PHLRQ-WANTC-078

TR-PHLRQ-LANET TR-PHLRQ-LANET-001 TR-PHLRQ-LANET-002 TR-PHLRQ-LANET-003 TR-PHLRQ-LANET-004 TR-PHLRQ-LANET-005

LAN Ethernet The 8-pin interface mechanics shall comply with the requirements of section 3 of the IEEE 802.3 specification and will be consistent with the figures of 1-5 ISO/IEC 8877: 1992 The device shall have Fast Ethernet 802.3u 100baseTX interface (compatible with 10baseT, 100baseTX, 100baseT4 and optionally with 1000baseTX) with bit rate autonegotiation The device Ethernet 802.3 interface shall detect and operate in half/full duplex modes The device Ethernet 802.3 interface shall support Auto-MDI/MDI-X feature to detect the connection polarity (10baseT, 100baseTX or optionally 1000base-TX). The residential gateway shall offer four Ethernet ports and be able to operate as a switch at Ethernet level.

M M M M M

TR-PHLRQ-WILAN TR-PHLRQ-WILAN-001 TR-PHLRQ-WILAN-002 TR-PHLRQ-WILAN-003 TR-PHLRQ-WILAN-004 TR-PHLRQ-WILAN-005 TR-PHLRQ-WILAN-006 TR-PHLRQ-WILAN-007 TR-PHLRQ-WILAN-008 TR-PHLRQ-WILAN-009 TR-PHLRQ-WILAN-010 TR-PHLRQ-WILAN-011 TR-PHLRQ-WILAN-012 TR-PHLRQ-WILAN-013 TR-PHLRQ-WILAN-014

WLAN The wireless interface can be enabled/disabled via software from the user interface and via hardware facility (button). The device WLAN Interface shall operate in Access Point / Infrastructure Mode The router should support the wireless standard 802.11n 2.4GHz(2x2) in the last available version certified by the WIFi Alliance. Troughput of WLAN to LAN shall be 100Mbps at last. The device WLAN Interface shall ensure interoperability with IEEE 802.11b and IEEE 802.11g clients simultaneously with IEEE 802.11n clients. The device WLAN Interface shall be able to operate at 2.4GHz frequency. The device WLAN Interface shall be able to apply IEEE 802.11n standard features at 2.4GHz frequency band. The device WLAN Interface shall operate over frequency channels in 2.4GHz band: from 1 (2412MHz) to 13 (2472MHz) with 5MHz channel spacing. Defined for Europe in 802.11-2007, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Clause 15, Table 15-7 The device WLAN Interface shall be able to operate using 20MHz channels in 2.4GHz band according to IEEE 802.11n The device WLAN Interface may be able to operate using 40MHz bandwidth channels in 2.4GHz band according to IEEE 802.11n The device WLAN Interface may have DFS (Dynamic Frequency Selection) feature in 2.4GHz frequency band The device WLAN Interface maximum transmitted power (EIRP) when using channels from 1 to 13 in 2.4GHz band must not exceed 100mw in any combination of transmitter power output and supplied antenna Power spectral density level shall comply with VO-R/12/08.2005-34 in operation bands (2.4GHz). The device WLAN Interface transmitter power output may be configured via web-based user interface (supplier should specify the range) The supplier shall specify receiver sensitivity at BER 10-6 in dBm for each frequency band and every single supported rate M M M M M M M M O M M M O I

TR-PHLRQ-WILAN-015

The device shall have at least 2 external antennas. The supplier shall also specify technical parameters of supplied antennas (gain in dBi, radiation pattern envelope, frequency band). The antennas shall not be detachable (fixed mounted on the BHS).

TR-PHLRQ-WILAN-016 TR-PHLRQ-WILAN-017 TR-PHLRQ-WILAN-018

It can be offered internal antennas to replace the external antennas requested on the requirement TR-PHLRQ-WILAN-015, as long as the internal antennas presents no loss in coverage, confirmed by local tests with participation and approval of the HR local OB.. The supplier shall specify the number of antennas included to the device. IEEE 802.11n requires a minimum of 2 antennas M to take advantage of MIMO features. The device WLAN Interface shall offer Multiple Input Multiple Output features (MIMO) to take advantage of IEEE 802.11n M improvements El dispositivo transmite y recibe informacin de forma simultnea en la misma banda de frecuencias utilizando las 2 antenas (MIMO). La tcnica empleada es multiplexacin espacial de acuerdo con el estndar 11n, amn de otras tcnicas de optimicacin a nivel fsico y MAC. El equipo utiliza el chipset de Ralink RT5392

TR-PHLRQ-WILAN-019

The supplier shall specify what has been implemented in terms of MIMO (multiple input and multiple output) according to IEEE 802.11n standard

TR-PHLRQ-WILAN-020 TR-PHLRQ-WILAN-021 TR-PHLRQ-WILAN-022

The supplier shall specify implemented MIMO chipset The device WLAN Interface must be able to perform MIMO spatial multiplexing. At least two spatial streams shall be able to be received/transmitted but IEEE 802.11n standard allows a maximum of four spatial streams. The supplier shall specify the multiplexing algorithm used in SDM (Spatial Division Multiplexing). The supplier shall specify implemented kind of beamforming (single layer beamforming or multilayer beamforming with precoding) to take advantage of antenna diversity. This feature is optional in IEEE 802.11n standard. The supplier shall specify if the device may apply diversity coding techniques (space-time coding) to enhance signal diversity. The device WLAN Interface can be configured to be used without encryption The device WLAN Interface shall support WEP security The device WLAN Interface can be configured to use 64bit key WEP encryption The device WLAN Interface can be configured to use 128bit key WEP encryption The device WLAN Interface using WEP security can use Open authentication The device WLAN Interface using WEP security can use Shared Key authentication. This authentication method is less secure than Open authentication. The WEP key of the WLAN Interface shall be entered in hexadecimal format The WEP key of the WLAN Interface may be entered in ASCII format The device shall support extended ASCII characters The device WLAN Interface shall support WPA security The device WLAN Interface shall support WPS security WPA user authentication can be performed via PSK (PreShared Key). Personal WPA mode. WPA user authentication can be performed via IEEE 802.1x protocol through EAP framework. Enterprise WPA mode. WPA user authentication via EAP framework shall support the following methods: EAP-TLS, EAP-TTLS/MSCHAPv2, PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC and EAP-SIM as in IETF RFC4017

I M I

TR-PHLRQ-WILAN-023 TR-PHLRQ-WILAN-024 TR-PHLRQ-WILAN-025 TR-PHLRQ-WILAN-026 TR-PHLRQ-WILAN-027 TR-PHLRQ-WILAN-028 TR-PHLRQ-WILAN-029 TR-PHLRQ-WILAN-030 TR-PHLRQ-WILAN-031 TR-PHLRQ-WILAN-032 TR-PHLRQ-WILAN-033 TR-PHLRQ-WILAN-034 TR-PHLRQ-WILAN-035 TR-PHLRQ-WILAN-036 TR-PHLRQ-WILAN-037 TR-PHLRQ-WILAN-038

O O M M M M M M M M M M M M M M Se puede soportar caracteres extendidos ASCII. Telefonica debe especificar qu tabla de caracteres extendidos se desea utilizar.

TR-PHLRQ-WILAN-039 TR-PHLRQ-WILAN-040 TR-PHLRQ-WILAN-041 TR-PHLRQ-WILAN-042 TR-PHLRQ-WILAN-043 TR-PHLRQ-WILAN-044 TR-PHLRQ-WILAN-045 TR-PHLRQ-WILAN-046 TR-PHLRQ-WILAN-047 TR-PHLRQ-WILAN-048 TR-PHLRQ-WILAN-049 TR-PHLRQ-WILAN-050 TR-PHLRQ-WILAN-051 TR-PHLRQ-WILAN-052 TR-PHLRQ-WILAN-053 TR-PHLRQ-WILAN-054 TR-PHLRQ-WILAN-055 TR-PHLRQ-WILAN-056 TR-PHLRQ-WILAN-057 TR-PHLRQ-WILAN-058 TR-PHLRQ-WILAN-059 TR-PHLRQ-WILAN-060 TR-PHLRQ-WILAN-061 TR-PHLRQ-WILAN-062 TR-PHLRQ-WILAN-063 TR-PHLRQ-WILAN-064 TR-PHLRQ-WILAN-065 TR-PHLRQ-WILAN-066 TR-PHLRQ-WILAN-067 TR-PHLRQ-WILAN-068 TR-PHLRQ-WILAN-069 TR-PHLRQ-WILAN-070 TR-PHLRQ-WILAN-071 TR-PHLRQ-WILAN-072

The WPA security shall include RC4-based TKIP (Temporal Key Integrity Protocol) for encryption and rekeying The AES re-keying interval may be configured The TKIP re-keying interval may be configured WPA security shall include MIC (Message Integrity Code) to avoid CRR (Cyclic Redundance Code) modifications by attackers WPA security shall include Reply Attack Protection mechanisms WPA key of the WLAN Interface shall be entered in hexadecimal format WPA key of the WLAN Interface shall be entered in phrase format WPA key of the WLAN Interface must be random and it will be the same always The device WLAN Interface shall support IEEE 802.11i WPA2 security WPA2 security shall ensure interoperability with WPA clients WPA2 user authentication can be performed via PSK (PreShared Key). Personal WPA2 mode. WPA2 user authentication can be performed via IEEE 802.1x protocol through EAP framework. Enterprise WPA2 mode. WPA2 user authentication via EAP framework shall support the following methods: EAP-TLS, EAP-TTLS/MSCHAPv2, PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC and EAP-SIM as in IETF RFC4017. EAP peer and authenticator authorization must be supported The WPA2 security shall include AES-based CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) for encryption and rekeying WPA2 security shall include MIC (Message Integrity Code) to avoid CRR (Cyclic Redundance Code) modifications by attackers WPA2 security shall include Reply Attack Protection mechanisms WPA2 key of the WLAN Interface shall be entered in hexadecimal format WPA2 key of the WLAN Interface shall be entered in phrase format The WLAN Interface can be secured using MAC filter to control the access of certain MAC addresses to the wireless network The MAC filter shall be able to operate in whitelist mode (only the registered MAC addresses are allowed to access to the wireless network) The MAC filter shall be able to operate in blacklist mode (only the registered MAC addresses are not allowed to access to the wireless network) The device shall support MAC addresses self-learning of wireless clients The supplier shall specify maximum number of MAC addresses registered in the access table The SSIDs of the WLAN Interface must be WLAN_XXXX by defect, The SSIDs of the WLAN Interface must be WLAN_XXXX by defect, with "XXXX" the last bytes of MAC Ethernet (all characters of "WLAN_XXXX" must be on upper case) The SSIDs of the WLAN Interface can be changed by the user. The device WLAN Interface can be configured to not broadcast the SSIDs (SSID hiding feature) The device WLAN Interface shall support Multiple SSID feature with a minumum of 4 SSIDs When using Multiple SSID, different settings can be asigned to each SSID: encryption, hiding, enabled/disabled, mac filtering The device WLAN Interface shall support IEEE 802.11e QoS features The device WLAN Interface shall comply Wifi MultiMedia (WMM) interoperability certification. The device WLAN Interface shall support Enhanced DCF Channel Access (EDCA) medium access control method + Transmit Opportunity (TXOP) The device WLAN Interface HCF Controlled Channel Access (HCCA) medium access control method is optional The device WLAN Interface shall support Automatic Power Save Delivery (APSD) or other similar mechanism The device WLAN Interface may support Block Acknowledgments (BA) to reduce overhead when longer TXOPs are specified

M M O M M M M M M M M M M M M M M M M M O M I M M M M M M M M O M O 128

TR-PHLRQ-WILAN-073 TR-PHLRQ-WILAN-074 TR-PHLRQ-WILAN-075 TR-PHLRQ-WILAN-076 TR-PHLRQ-WILAN-077 TR-PHLRQ-WILAN-078 TR-PHLRQ-WILAN-079 TR-PHLRQ-WILAN-080

The device WLAN Interface may be able to send frames with No Acknowledgement (NoAck) service class to avoid retransmission of highly time-critical data. WPS feature as user-friendly method to establish the WiFi configuration shall be provided in PBC (Push Button Configuration) mode. Each unit shall have a unique phrase format WPA key and a customized SSID (to allow the user to recognize its own WiFi network) in its default configuration The device shall support Adaptive RF (automatic adjustment of signal power and WiFi channel / bandwidth) The device shall support Airtime Fairness functionality The antennas shall have a signal power of 3dBi The Mac Address from the Ethernet interfaces and the Mac Address from the WLAN interface shall not be sequential from one to another (LAN to WLAN) and shall have no correlation between each other The supplier shall provide the plans that is been implemented to avoid the vulnerability of the WPS functionality to Brute Force Attack attempts. To have a defined plan to avoid this vulnerability is mandatory.

O M M M M M M M

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC NC FC FC FC FC FC FC FC FC Support of Annex L,Annex L is defined by G.992.3, but not in G.992.5 FC FC FC FC FC FC

FC FC FC FC NC FC FC FC FC

FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC

FC FC FC FC

FC

FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC

FC

We can support minimun link length 0km.

FC

FC There is no support of 1000baseTX FC FC FC FC

FC FC FC FC FC FC FC FC FC FC FC FC FC FC

FC

FC FC FC For MIMO of our CPE, information is sent and received over 2 antennas simultaneously using the same frequency band. It is accomplished through a combination of FC enhanced MAC and PHY implementations including spatial multiplexing modes in the transmitter and receiver. Our CPE uses RT5392 wireless chipset. FC IEEE 802.11n 20.3.10.10.1 spatial mapping. Both Direct and Spatial are supported. FC FC FC FC FC FC FC FC FC FC We can support extended ASCII characters according to the extended ASCII table Telefonica wants to implement. FC FC FC FC FC FC

FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC 128 FC FC FC FC FC FC FC FC No plan to support NC FC FC

No plan to support

NC FC FC FC FC FC

This requirement should not be needed since the WLAN key is not generated from the LAN's NC MAC FC

Cod

Description

Ctg. Details and comments (Spanish)

TR-LINRQ TR-LINRQ-GENRQQ TR-LINRQ-GENRQQ-001 TR-LINRQ-GENRQQ-002 TR-LINRQ-GENRQQ-003 TR-LINRQ-GENRQQ-004 TR-LINRQ-GENRQQ-005 TR-LINRQ-GENRQQ-006 TR-LINRQ-GENRQQ-007 TR-LINRQ-GENRQQ-008 TR-LINRQ-GENRQQ-009 TR-LINRQ-GENRQQ-010 TR-LINRQ-GENRQQ-011 TR-LINRQ-GENRQQ-012 TR-LINRQ-GENRQQ-013 TR-LINRQ-GENRQQ-014 TR-LINRQ-GENRQQ-015 TR-LINRQ-GENRQQ-016 TR-LINRQ-GENRQQ-017 TR-LINRQ-GENRQQ-018 TR-LINRQ-GENRQQ-019 TR-LINRQ-GENRQQ-020 TR-LINRQ-GENRQQ-021 TR-LINRQ-GENRQQ-022 TR-LINRQ-GENRQQ-023 TR-LINRQ-GENRQQ-024 TR-LINRQ-GENRQQ-025

Link layer Requirements General Requirements The supplier shall specify ARP table maximum size and expiration time of the entries. The number of entries must be higher M than 256 addresses The device should have LAN 802.1p packet priorization (QoS on MAC). The supplier shall provide its roadmap to include HR this functionality The device shall use ATM layer to transport data over DSL layer as in IT-BA-003 Ed 2, section 6, ITU-T I.361, I.321 and M I.150 The device shall support ATM layer Physical Medium sublayer (PMD) functions and primitives between PMD and ATM M layers as in ITU-T I.321 The device shall support ATM layer: Convergence sublayer (CS) as in ITU-T I.321 M The device shall support ATM layer: Transmission Convergence (TC) sublayer primitives (to/from ATM-PMD and M management plane) as in ITU-T I.413 The device ATM layer, Convergence sublayer shall use HEC field to perform cell alignment, single bit error correction and M error detection and correction as in ITU-T I.321, I.432.1 and I.361-2.3.5 The device shall support ATM layer Convergence sublayer. Cell Rate Decoupling (CRD) feature using idle cells to adapt cell flow to the transmission system capacity as defined in ITU-T I.321 and I.432.1. If not possible then ATM Forum proceedings M for CRD can be used. The device shall support ATM layer: Convergence sublayer. Cell data randomizing as in ITU-T I.432.1 ATM cell format as in ITU-T I.361. UNI 2.2 and UNI 3.1 must be Supported Default Cell Loss Priority = 0 (upstream cells) for PPPoE over ATM. General Flow Control (GFC) bits are not required in the cell header. Filling out of PTI (Payload Type Identifier) field shall be accomplished according to I.361 paragraph 2.3.3 and 2.3.4 in the incoming and outgoing directions The device shall support ATM Virtual Channels in both permanent and semipermanent mode The device shall support ATM layer. Transmission of user data is always considered as bidirectional, and therefore cells with the same VPI and VCI only belong to one bidirectional data connection (VC) ATM Virtual Channels Identifiers. VPI Range for 0 to 255 and VCI from 0 to 65535. No limitations in VPI/VCI range (0/0 not valid, but 0/x or x/0 shall be valid) ATM Virtual Channels: VPI/VCI values reserved for signalling, OAM, resource management, etc shall no be used for data transmission or any kind of proprietary communication channel The device shall support al teast 8 PVCs and each one of them may have different configuration (QoS, RIP, NAT, Firewall, PPPoE sessions...) ATM requirements. It shall be possible to attach a PVC to each Ethernet, WLAN or USB interface ATM requirements. It shall be possible to attach the same one PVC on more than one interface (Ethernet, WLAN and USB interface) ATM requirements. Minimum 2 PPPoE sessions can be initialized per PVC ATM requirements. Static routes can be assigned to different PVCs without the need of a destination IP address. ATM requirements. Multicast/Unicast can be enabled over 1 PVC to provide video service ATM requirements. The video PVC shall be able to transport 3 multicast/unicast traffic flows ATM requirements. The device shall support ATM AAL5 (ITU.363.5) M M M M M M M M M M M M M M M M M Mediante la asociciacin de un puerto LAN o IP con un especfico PVC

TR-LINRQ-GENRQQ-026

ATM requirements. The maximum allowed BER is 10e-7 when using ATM AAL5 (ITU.363.5) The device shall support the Multi-protocol Encapsulation over ATM AAL5 according to the specification RFC1483 and RFC 2684, including LLC, LLC SNAP (MTU of AAL5 payload shall be at least 1528 byte -at least 1536 for ATM cell payload - to transport 1518 byte of Ethernet frames without fragmentation through PPPoE or not) and VCMux The device shall support ATM QoS: service classes as in ITU-T I.371 and ATM Forum Traffic Management 4.1, including UBR, CBR and VBR Support of ATM QoS service Class ABR ATM QoS service classes can be configured for each connection from the remote management system ATM asymmetric/symmetric data bit rate is achieved depending on the ATM service class used (QoS parameters: SCR, PCR) The device shall support ATM QoS Connection Admission Control (CAC) feature. The device shall support ITU-T I.610 Operation And Maintenance (OAM) functions in F4 and F5 End to End and Segment flows: OAM F4 and F5 cells support VC-AIS / VC-RDI Continuity check Loopback Forward and backward performance monitoring Activation / deactivation System management If the device support processing of OAM cells (ITU-T I.610, I.751 and I.732) the supplier shall describe in detail the implemented algorithms. If OAM feature is not supported then data transmission shall not be affected when the the device receives OAM cells. For operation and maintenance purposes the supplier of the ADSL modem and the type of the modem shall be uniquely identified by information stored in the ATU-R registers ATU-R supplier ID (Register #0), ATU-R version number minus one (Register #1), ATU-R serial number (Register #2) as specified in the ITU-T recommendation [G.992.1]. After power up the ADSL modem of the DSL Port may perform a self test and report the self test result via the ATU-R register Self test result (Register #3). If the self test succeeded and the ADSL modem is able to transfer data, the self test result should be 0x00. If the self test fails, the result should be a value other than 0x00. Link layer for Internet service: The device shall support PPP line layer protocol in accordance with RFC791 Link layer for Internet service: The device shall support PPP control protocol for IP (IPCP) in accordance with RFC1332 Link layer for Internet service: The device shall not negotiate other network protocol over PPP (IPX, X25) Link layer for Internet service. PPP. PAP authentication for the PPP protocol (IETF RFC1334) Link layer for Internet service. PPP. CHAP authentication for the PPP protocol (IETF RFC1994) Link layer for Internet service. PPP. The supplier shall describe if the device supports forced PPP authentication: if it is configured to authenticate using only CHAP, it shall inform the BRAS to use CHAP if it tries to use PAP Link layer for Internet service. PPP. The supplier shall describe if the modem supports configuration of automatic retry parameters in case of unsuccessful setup of PPP protocol. Modem must automatically retry setup of PPP protocol. The delay between to consecutive retries of PPP setup should be configurable on modem in range 5 to 90 seconds with step of 1 second. Default value of PPP setup rate must be set from 60 to 90 seconds Link layer for Internet service. The supplier shall describe the modem behaviour if the modem sends PPPoE PADI to BRAS and the BRAS does not answer with PADO. The supplier shall describe the amount of consecutive PADI and the time interval within the consecutive PADI are sent. Max. 60 seconds between consecutive PPPoE PADI is required.

TR-LINRQ-GENRQQ-027

TR-LINRQ-GENRQQ-028 TR-LINRQ-GENRQQ-029 TR-LINRQ-GENRQQ-030 TR-LINRQ-GENRQQ-031 TR-LINRQ-GENRQQ-032

M O M M M

TR-LINRQ-GENRQQ-033

TR-LINRQ-GENRQQ-034

TR-LINRQ-GENRQQ-035

TR-LINRQ-GENRQQ-036

TR-LINRQ-GENRQQ-037 TR-LINRQ-GENRQQ-038 TR-LINRQ-GENRQQ-039 TR-LINRQ-GENRQQ-040 TR-LINRQ-GENRQQ-041 TR-LINRQ-GENRQQ-042

M M M M M I

TR-LINRQ-GENRQQ-043

TR-LINRQ-GENRQQ-044

El equipo intentar levantar la sesin PPPoE enviando paquetes PADI de forma ininterrumpida hasta que tenga xito.

TR-LINRQ-GENRQQ-045 TR-LINRQ-GENRQQ-046

The device must send PPPoE PADT to BRAS at first when is restarted through internal tools (e.q. restart of the device or reboot after upgrade of the device). The PPPoE PADI may be only sent to ADSL port. PPPoE PADI must not be sent to any LAN port when is not allowed Link layer for Internet service. The modem shall support PPP keep-alive option. PPP keep-alive parameters should be configurable on modem. Default value of PPP keep-alive must be set to send keep-alive (PPP echo-request) every 30 seconds to BRAS and brings PPP session down if 5 consecutive keep-alive procedures fail (The modem does not receive 5 PPP echo-replay). The modem must answer to PPP echo-request from the BRAS sending PPP echo-replay. The device shall use the Point-to-Point Protocol over Ethernet (PPPoE) adaptation layer to establish Point-to-Point Protocol (PPP) sessions according to the specifications [RFC 1144], [RFC 1332], [RFC 1334], [RFC 1570], [RFC 1661], [RFC 1994], [RFC 2865], [RFC 2869] with additions. The device shall establish one PPP session within 1 second for all data traffic and the Auto-Configuration Service using one unique MAC address if the PPP session has not been established previously and the Auto-Configuration Client or the IP Routing functionality requests the data connection The device shall support the following retry mechanism in the case of an unsuccessful PPP Data session establishment. No. No of retries Timeouts(secs) Description 1 4 3 The initial retry must follow up relatively quickly in order to guarantee a fast setup time. 2 5 60 When the initial retry has failed 4 times this indicates something is wrong and therefore to avoid unnecessary traffic it is suggested to have a retry after 60 secs until the limit of 5 is reached. 3 infinite 900 The device does a retry every 900 secs Link layer for Internet service. The supplier shall describe allowed range and default value of maximum routable unit (MRU). Default value 1492 is expected Link layer for Internet service. The supplier shall describe allowed range and default value of maximum segment size (MSS). Default value 1452 is expected Link layer for Internet service. Adjusting of TCP maximum segment size: when IP packets with TCP payloads are traversing between media with different MTUs (for example Ethernet 1500 and PPPoE 1492) the minimum value shall be kept (local MSS, remote MSS and the MSS configured in the device) Spanning tree protocol support in the link layer for TV service. This protocol bridging shall be done with no changes inside STP frames. Link layer for TV service. MAC table: limitations and acquiring and releasing rules Link layer for TV service. FCS checking: rule to check frame integrity Link layer for TV service. The modem shall support flooding broadcast Link layer for TV service. The modem shall support bridging all DHCP frames Link layer for TV service. The modem shall support flooding of multicast frames Link layer for TV service. The modem shall support flooding of unknown unicast frames The device shall support a functionality to use prioritisation of outgoing packets between the following interfaces: - DSL Port Interface - LAN Port Interface The device shall support diffserv The device shall support the configuration of link type and connection type as per appendix B of TR098 on these VCs.

M M

TR-LINRQ-GENRQQ-047

TR-LINRQ-GENRQQ-048

TR-LINRQ-GENRQQ-049

TR-LINRQ-GENRQQ-050

TR-LINRQ-GENRQQ-051 TR-LINRQ-GENRQQ-052 TR-LINRQ-GENRQQ-053 TR-LINRQ-GENRQQ-054 TR-LINRQ-GENRQQ-055 TR-LINRQ-GENRQQ-056 TR-LINRQ-GENRQQ-057 TR-LINRQ-GENRQQ-058 TR-LINRQ-GENRQQ-059 TR-LINRQ-GENRQQ-060

I I M I I I M M M M

El MRU para el PPPoE es 1492. El tamao mximo de segmento (MMS) es igual a la MTU menos 40.

FCS checking est soportado para todos los modos

TR-LINRQ-GENRQQ-061

TR-LINRQ-GENRQQ-062 TR-LINRQ-GENRQQ-063

M M

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 TR069 methods. Appendix A5 of TR098 shall be used. The 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 TR069 methods

TR-LINRQ-GENRQQ-065

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC
By the association LAN Port/IP Adress with one specific PVC

FC FC FC FC

FC FC FC FC FC FC FC

FC

FC

FC

FC FC FC FC FC FC FC

FC

Our CPE will keep retry to be successfully connected by consecutive PADI tranmitted until it succeed. Never stop.

FC

FC FC

FC

FC FC

FC

The max routable unit of our PPPoE is 1492. The max. is MTU size minus 40

FC FC FC FC FC

Our router can support FCS checking in all mode

FC FC FC FC FC FC FC FC

FC FC

Cod TR-NETRQ TR-NETRQ-IPCON TR-NETRQ-IPCON-001 TR-NETRQ-IPCON-002

Description Network Layer Requirements IP Configurations The device shall support RFC791 IP protocol (v4) 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 The device shall support DHCPv6 (DHCP snoop -for subscriber identification) with at least the following requirements: - 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 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-01 - support RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers - support RFC 4241 A Model of IPv6/IPv4 Dual Stack Internet Access Service 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 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 amount of time weeks- after T0) - it would be possible to upgrade remotely the change of software. (Detail if it necessary any change in the hardware) - if it is possible in your equipment (detail the model that applies) support both mode Dual Stack and Dual Stack Lite. - if your offer include the possibility to deliver CPE with Dual Stack and then evolve to Dual Stack Lite (please detail this issue and if it is part of the same buying process. The provider shall inform regarding INTEROPERABILITY the following information: - For DS-Lite the provider will inform what AFTRs vendor (Address Family Transition Router) interoperate with your solution. Specify model and release and if it were possible the configuration tested. The provider shall inform regarding MULTICAST IPv6 AND GROUP MANAGEMENT the following information: - the mechanism used for MLD ICMPv6 (Multicast Listener Discovery) Reference RFC 4605 Internet Group Management 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

Ctg. Details and comments (Spanish)

M M

TR-NETRQ-IPCON-003

TR-NETRQ-IPCON-004

TR-NETRQ-IPCON-005

TR-NETRQ-IPCON-006

TR-NETRQ-IPCON-007

TR-NETRQ-IPCON-008

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

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 Authorization Extensions to 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 The device can be configured in IP mode: RFC1483/2684 routed. IPoA (RFC1577) The device can be configured in IP mode: RFC1483/2684 routed. IPoE/MER (MAC Encapsulated Routing). The device can be configured in IP mode: RFC1483/2684 bridged. EthoA. The device can be configured in IP mode: RFC1483/2684 bridged. EthoA bridging using IEEE802.1d MAC bridging supporting a minimum of 272 MAC addresses The device can be configured in IP mode: RFC1483/2684 bridged. EthoA bridging using IEEE802.1d MAC bridging is transparent to PPPoE (RFC2516), VLAN (IEEE802.1Q) and IPSEC protocols The device can be configured in IP mode: RFC2364 routed PPPoA (RFC2364) with PAP (RFC1334) or CHAP (RFC1994) authentication. Session establishment can be done: manually, on demand or always on (in case session is closed it will be restablished as soon as it becomes possible). IP configuration modes PPPoA: Session Terminated on Inactivity Timeout The device can be configured in IP mode: RFC1483/2684 routed. PPPoE (RFC2516) with PAP (RFC1334) or CHAP (RFC1994) authentication. Session establishment can be done: manually, on demand or always on (in case session is closed it will be restablished as soon as it becomes possible). IP configuration modes PPPoE: Session Terminated on Inactivity Timeout Secondary IP addresses can be configured in all the device interfaces IP subnets can be defined and attached to the LAN interfaces VLSM (variable length subnet mask): The modem shall handle the variable subnet mask in accordance with IETF RFC 1878. The modem shall acquire IP address through PPP IPCP within the same network class as is configured at LAN side of the modem. For example, when LAN side of the modem is configured with 194.228.208.0/29 network the modem shall be able to acquire 194.228.208.8 address at WAN through PPP IPCP.

TR-NETRQ-IPCON-011 TR-NETRQ-IPCON-012 TR-NETRQ-IPCON-013 TR-NETRQ-IPCON-014 TR-NETRQ-IPCON-015 TR-NETRQ-IPCON-016 TR-NETRQ-IPCON-017 TR-NETRQ-IPCON-018 TR-NETRQ-IPCON-019 TR-NETRQ-IPCON-020 TR-NETRQ-IPCON-021

M M M M M M M M M M M

TR-NETRQ-IPCON-022

TR-NETRQ-ROUTI TR-NETRQ-ROUTI-001 TR-NETRQ-ROUTI-002 TR-NETRQ-ROUTI-003 TR-NETRQ-ROUTI-004 TR-NETRQ-ROUTI-005 TR-NETRQ-ROUTI-006 TR-NETRQ-ROUTI-007 TR-NETRQ-ROUTI-008 TR-NETRQ-ROUTI-009 TR-NETRQ-ROUTI-010

Routing The device shall support a functionality to support routing/forwarding of network packets that have been received on the following interfaces to any of the following interfaces: WAN interface (PPP interface if configured), LAN interface and WLAN interface The IP Routing functionality of the device shall use IP Routing Table. The device shall support static routing The supplier shall describe if the device supports establishing of static routing entries through management interface The device shall support dynamic routing Dynamic routing via RIPv1 and RIPv2 protocol in both LAN and WAN Interfaces The device should have ARP proxy functionality The device shall support ARP cache as defined in RFC 826 The routing functionality of the device shall support the Address Resolution Protocol (ARP) according the specification RFC 826. The device shall have NAT/PAT functionality as in RFC1631/RFC3022 (NAT/PAT basics), RFC2663 (terminology and considerations) and RFC3027(protocol complications with the IP NAT) in routed mode that can be enabled or disabled

M M M I M M HR M M M

TR-NETRQ-ROUTI-011 TR-NETRQ-ROUTI-012 TR-NETRQ-ROUTI-013 TR-NETRQ-ROUTI-014 TR-NETRQ-ROUTI-015 TR-NETRQ-ROUTI-016 TR-NETRQ-ROUTI-017 TR-NETRQ-ROUTI-018

The device shall be able to run in NAT mode to translate IP addresses in accordance with IETF RFC 3022. NAT shall preserve TOS field of IP header when IP packet is going through translation process in both directions The device shall be able to run in NAT mode to translate IP addresses in accordance with IETF RFC 3022. The supplier shall specify amount of maximum simultaneously established session The Network and Port Address Translation of the device shall be based on ports defined in the Transmission Control Protocol (TCP) according the specification [RFC 793] and in the User Datagram Protocol (UDP) according the specification [RFC 768]. The PAT functionality shall be able to carry out TCP/UDP mappings of external addresses and ports to different internal addresses and ports PAT minimum table size of 80 entries. Vendor shall specify maximum number of entries. The PAT funcionatily shall support DMZ NAT shall be transparent for IPSec (NAT traversal): VPN pass-through NAT shall be transparent for protocols that support NAT/PAT and shall use ALG (Application Level Gateway) for those do not support NAT/PAT: ICMP, HTTP, RTSP, FTP, TELNET, DNS queries, POP3, SMTP, IRC, Real Audio, Online gaming, Netmeeting, Instant Messaging (ICQ, MSN...), Softphone, Video Messenger, UPNP, Microsoft MMS...) The modem shall support acquiring WAN default route during PPP negotiation. Default route shall be install as soon as the PPP session is established. Default route shall be withdrawn as soon as the PPP session is disconnected 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 Both in bridged or routed modes throughtput between interfaces must comply: - 16Mbps between PPP/WAN and LAN - 16Mbps between PPP/WAN and WLAN The device shall support IP fragmentation The routing functionality of the device shall support the Internet Control Message Protocol (ICMP) according the specification RFC 826. The number of sessions supported by UDP should not be lower than 512 no matter how long the packet is The device shall support IETF RFC 0894 Standards for the Transmission of IP Datagrams over Ethernet Networks The device shall support IETF RFC 0922 Broadcasting Internet Datagrams in the Presence of Subnets The device shall support IETF RFC 0950 Internet Standard Subnetting Procedure The device shall support IETF RFC 1009 Requirements for Internet Gateways (Link Layer issues only) The device shall support IETF RFC 1042 Standard for the Transmission of IP Datagrams over IEEE 802 Networks The device shall support IETF RFC 1112 Host Extensions for IP Multicasting The device shall support IETF RFC 1122 Requirements for Internet Hosts Communication Layers The device shall support IETF RFC 1123 Requirements for Internet Hosts Application and Support The device shall support IETF RFC 1256 ICMP Router Discovery Messages (Router Specification only) The device shall support IETF RFC 1519 Classless InterDomain Routing (CIDR) The device shall support IETF RFC 1812 Requirements for IP Version 4 Routers The device shall support IETF RFC 1918 Address Allocation for Private Internets The device shall support IETF RFC 3600 Internet Official Protocol Standards Security Firewall filtering: default rules to filter NetBIOS traffic (137, 138 and 138 both tcp and udp ports) that can be changed from the local and management software

M I M M M M M M

TR-NETRQ-ROUTI-019

TR-NETRQ-ROUTI-020

TR-NETRQ-ROUTI-021 TR-NETRQ-ROUTI-022 TR-NETRQ-ROUTI-023 TR-NETRQ-ROUTI-024 TR-NETRQ-ROUTI-025 TR-NETRQ-ROUTI-026 TR-NETRQ-ROUTI-027 TR-NETRQ-ROUTI-028 TR-NETRQ-ROUTI-029 TR-NETRQ-ROUTI-030 TR-NETRQ-ROUTI-031 TR-NETRQ-ROUTI-032 TR-NETRQ-ROUTI-033 TR-NETRQ-ROUTI-034 TR-NETRQ-ROUTI-035 TR-NETRQ-ROUTI-036 TR-NETRQ-ROUTI-037 TR-NETRQ-SECUR TR-NETRQ-SECUR-001

M M M M M M M M M M M M M M M M M

TR-NETRQ-SECUR-002 TR-NETRQ-SECUR-003 TR-NETRQ-SECUR-004 TR-NETRQ-SECUR-005

The device shall have firewall functionality in routed mode with a minimum of 20 filter rules andthroughtput of 46B IP packets. Firewall shall filter by origin/destination IP, mask and origin/destination TCP/UDP ports and can also filter ICMP packets, service types and protocols. Firewall shall support port scanning protection Firewall shall support Denial of Service (DOS) protection for itself and all routed LAN Port Interface and Wireless LAN Air Interface including protection from Ping of Death, SYN Flood LAND and variant attacks in routing mode (not in bridged mode). The device shall not reply to ICMP echo requests by default but it can be allowed

M M M M El equipo posee las siguientes funcionalidades: stateful inspection, Denial of Sevice attack, TCP/IP/Port/interface filtering rules, MAC Layer filtering, Day-time Parental control.

TR-NETRQ-SECUR-006

The supplier will describe other IP firewall functionalities

TR-NETRQ-SECUR-007 TR-NETRQ-SECUR-008

Firewall may be provided as external application installed in the user equipment The device shall support Access Control List: limited range of IP addresses (Management Center) can remotely manage the device (telnet, ftp, tftp...) The device shall support a functionality for Stateful Packet Inspection (SPI) firewall of network packets that have been received on the PPP Data session based at maximum speed of 16Mbit/s. The firewall shall use stateful packet inspection to determine if an inbound connection is allowed through the firewall to the private LAN. A legitimate incoming packet shall be matched with the outbound request for that packet and allowed in The device shall reject packets from the WAN with MAC addresses of devices on the local LAN or invalid IP addresses (including but not limited to broadcast addresses, private IP addresses or IP Addresses matching those assigned by the DHCP Server to the LAN Port and Wireless LAN Air Interface and their attached clients). The device shall drop or deny access requests from WAN side connections to LAN side devices and the DSL device itself except in direct response to outgoing traffic or as explicitly permitted through configuration of the DSL device (e.g., for port forwarding or management) The device may support a separate firewall log to maintain records of all transactions that violate firewall rules with timestamps. This log shall hold al least the last 100 entries or 10KB text and will be only cleared when rebooted

O M

TR-NETRQ-SECUR-009

TR-NETRQ-SECUR-010

TR-NETRQ-SECUR-019

TR-NETRQ-SECUR-020

TR-NETRQ-OTHER TR-NETRQ-OTHER-001 TR-NETRQ-OTHER-002 TR-NETRQ-OTHER-003 TR-NETRQ-OTHER-004 TR-NETRQ-OTHER-005 TR-NETRQ-OTHER-006 TR-NETRQ-OTHER-007 TR-NETRQ-OTHER-008 TR-NETRQ-OTHER-009 TR-NETRQ-OTHER-010 TR-NETRQ-OTHER-011

Others Multicasting support to provide video service The device must comply "IGMP proxy functionality for 2xSTB IPTV connection Functionality Description v.2" document Multicasting support to provide video service. The WAN interface shall have an static IP address. The device shall support IGMP protocol for multicasting. Configurable parameters are: robuts control, query interval, group query interval, query response interval, group query response interval, last member query interval, last member query count and group query count. The supplier shall provide its roadmap to include Layer 2 Multicast (similar to IGMP snooping) support into the device. The device shall support IGMP protocol for multicasting. Multicast packet interchange can be allowed in the interface The device shall support IGMP protocol for multicasting. Multicast group live delay can be configured The device shall support IGMP protocol for multicasting. Multicast group live delay msec can be configured The device shall support IGMP v2 protocol (RFC2236) The device shall support IGMP v3 protocol (RFC3376) The device shall be able to act as IGMP proxy (using CPE MAC address when sending IGMP packets to the DSLAM) receiving IGMP messages from DSLAM, sending IGMP messages to the STBs, receiving IGMP messages from STBs and sending IGMP messages to the DSLAM

M M M M I M M M M M M

TR-NETRQ-OTHER-012 TR-NETRQ-OTHER-013 TR-NETRQ-OTHER-014 TR-NETRQ-OTHER-015

The device shall support IGMP snooping (preserving MAC address of the STB when sending IGMP packets to the DSLAM) forwarding IGMP messages from DSLAM to the STBs and IGMP messages from the STBs to the DSLAM The device must preserve IP address field of the IGMP packets sent in upstream direction to the DSLAM The device shall permit the static addition of a member in the IGMP group The device shall permit the dynamic addition of members in the IGMP group via multicast tables (they bind particular LAN interfaces to particular multicast IP address so it is possible to know which multicast groups are joined by a STB connected to a particular LAN interface) The device shall permit fast leaving feature on its LAN interfaces (the IGMP user must be disconnected from particular multicast group immediately without performing the verification procedure with IGMP GSQ messages). This feature can be disabled. The device shall perform an inmediate leaving of the IGMP user from a particular multicast group when receiving the IGMP LEAVE message but the CPE shall not send the LEAVE message to the DSLAM until it verifies that there is no other IGMP user in the same multicast group. All traffic from particular multicast group including the IGMP messages MUST NOT be sent to any interface with STB that is not joined to this multicast group. IGMP management that the router test device makes,it mustn't influenced in the services deployed in the network and Telefonica services IP throughput (measured with IP packets that are from 512 up to 1492 bytes long when the modem is synchronized at DSL with 640/16000 kbps): LAN to WAN = 512kbps WAN to LAN = 13Mbps WLAN to WAN = 512kbps WAN to WLAN = 13Mbps WLAN to LAN = 33Mbps LAN to WLAN = 33Mbps IP QoS: mapping to queue according to DSCP or DSCP + physical port IP QoS: vendor will specify what physical port of the modem could run in mode: Trusted mode (preserves DSCP values at IP header) Forced mode (set all packets with predefined DSCP value to IP header) Classification mode (set DSCP bits according to traffic classification rules) IP QoS: mapping to queue according to DSCP or DSCP + physical port (if a LAN device cannot set DSCP bits then physical port can be used to prioritize its traffic). Traffic classification rules according to: Layer2: physical port, remote node or SSID Layer3: IP address, IP mask, protocol, packet length, 6-bit DiffServ Code Point (DSCP, RFC2474) Layer4: TCP/UDP port range IP QoS scheduling rules are Weighted Round Robin (defined amount of the packet from the queues are sent to uplink in each cycle) or Strict priority (the highest priority is serviced. Packets from lower priority queues are not sent until the higher priority is not empty) Low latency queuing: supplier should specify if the modem supports mechanism that ensures low latency for delay sensitive services or jitter sensitive services

M M M M

TR-NETRQ-OTHER-016

TR-NETRQ-OTHER-017 TR-NETRQ-OTHER-018 TR-NETRQ-OTHER-019

M M M

TR-NETRQ-OTHER-020

TR-NETRQ-OTHER-021 TR-NETRQ-OTHER-022

M M

TR-NETRQ-OTHER-023

TR-NETRQ-OTHER-024 TR-NETRQ-OTHER-025

M I Configurando el modo bridge se ofrece la mnima latencia. Comtrend puede customizar acorde con el siguiente requisito de Telefnica si Comtrend entra en lista corta. Esta modificacin es posible en la funcin de QoS.

TR-NETRQ-OTHER-026

The supplier should specify if the queue bandwidth could be expressed with percent of upstream without specification in bits per second (to take into account variable upstream speed). It is important when strict priority scheduling rule is used

TR-NETRQ-OTHER-027

Queuing maintenance. Queuing Latency in state of congestion: the supplier has to describe queuing latency of the highest priority queue if the lowest priority queue is in state of congestion for all queuing directions

Los paquetes de la cola de mayor prioridad sern los primeros en ser transmitidos hasta ocupar su mximo ancho de banda. Los paquetes en colas de menor prioridad entrarn en el buffer a la espera de poder ser transmitidos.

TR-NETRQ-OTHER-028 TR-NETRQ-OTHER-029 TR-NETRQ-OTHER-030 TR-NETRQ-OTHER-031 TR-NETRQ-OTHER-032 TR-NETRQ-OTHER-033 TR-NETRQ-OTHER-034 TR-NETRQ-OTHER-035

Queuing maintenance. Congestion Avoidance: The supplier must describe the implemented algorithms if modem supports intelligent mechanism releasing packet during overload of buffers Queuing maintenance. Committed Output Rate: The supplier shall describe regulation mechanism that is able to limit traffic according to contract Queuing maintenance. Overbooking: The supplier shall describe if committed bandwidth for guaranteed services in upstream direction is allowed to be higher than line speed in upstream direction Queuing maintenance. Bandwidth management: The supplier shall describe if low priority services are allowed to consume unused bandwidth from higher priority queues The device shall be used for Internet ADSL and Triple Play Services so it must allow concurrent deployment of Internet, O2TV and VoIP Services with respect to requisites of individual services (low latency for VoIP, errorless transport for TV). Different port configurations can be established so ports can be associated to certain services (with its own configuration) and receive certain priority considerations being isolated from the other ports. Configuration to transport 2 data streams: Internet data (Encapsulation PPPoE as in RFC2264, IP MTU = 1492B, NAT, Firewall and DNS) and Video (Encapsulation EthoA RFC2684, IP MTU = 1500B) Transported streams. Internet data services. Internal PPPoE client required Configuration to transport 3 data streams in 3 ATM PVC Internet data (Encapsulation PPPoE as in RFC2684, IP MTU = 1492B, NAT, Firewall and DNS PVC0 VPI/VCI 8-35 To WLAN, LAN1 & LAN2 ) and VoIP (Encapsulation EthoA RFC2684, PVC1 VPI/VCI 8-37 to LAN4 ) with port Mapping Layer 2 and IPTV (Encapsulation EthoA RFC2684, PVC2 VPI/VCI 10-35 to LAN3 ) with port Mapping Layer 2. The PVC values can be changed by OBs default configuration definition document Must support and be able to switch between IPoEoA using 0/101 (for ADSL2+) and PPPoE using 0/38 (for ADSL).

M I I M M M M M

TR-NETRQ-OTHER-036

TR-NETRQ-OTHER-037

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC FC

FC

FC

FC

FC

FC

FC

FC

FC

FC FC FC FC FC FC FC FC FC FC FC

FC

FC FC FC FC FC FC FC FC FC FC

FC FC FC FC FC FC FC FC

FC

FC

FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC FC

FC

FC FC FC FC Our CPE provides stateful inspection, Denial of Sevice attack, TCP/IP/Port/interface filtering FC rules, MAC Layer filtering, Day-time Parental control FC FC

FC

FC

FC

FC

FC FC FC FC FC FC FC FC FC FC FC

FC FC FC FC

FC

FC FC FC

FC

FC FC

FC

FC Setting Bridge mode can provide the lowest latency FC

Comtrend can make a customization to create this kind of QoS function into Wan setup page FC when we are short list. We can move this QoS function

Highest priority queue is regarded as first handle to occupy all bandwith. As to lowest priority is put in buffer.

FC

FC FC FC FC FC FC FC FC

FC

FC

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 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-CONNOD-005

TR-IPV6-CONNOD-006

TR-IPV6-WANCN TR-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 TR-IPV6-WANCN-013 TR-IPV6-WANCN-014

TR-IPV6-WANCN-015

TR-IPV6-PPPV6 TR-IPV6-PPPV6-001 TR-IPV6-PPPV6-002 TR-IPV6-PPPV6-003 TR-IPV6-PPPV6-004

TR-IPV6-PPPV6-005

TR-IPV6-DOSV6

TR-IPV6-DOSV6-001

TR-IPV6-DOSV6-002 TR-IPV6-DOSV6-003

TR-IPV6-DOSV6-004

TR-IPV6-DOSV6-005

TR-IPV6-QOSV6

TR-IPV6-QOSV6-001

TR-IPV6-QOSV6-002 TR-IPV6-QOSV6-003

TR-IPV6-QOSV6-004

TR-IPV6-QOSV6-005 TR-IPV6-QOSV6-006 TR-IPV6-QOSV6-007

TR-IPV6-QOSV6-008 TR-IPV6-QOSV6-009 TR-IPV6-QOSV6-010 TR-IPV6-QOSV6-011 TR-IPV6-QOSV6-012 TR-IPV6-QOSV6-013

TR-IPV6-QOSV6-014 TR-IPV6-QOSV6-015 TR-IPV6-TUNNL TR-IPV6-TUNNL-001

TR-IPV6-TUNNL-002

TR-IPV6-TUNNL-003

TR-IPV6-TUNNL-004

TR-IPV6-TUNNL-005

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

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

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

TR-IPV6-FWSPI-014

TR-IPV6-FWSPI-015

TR-IPV6-FWSPI-016 TR-IPV6-FWSPI-017

TR-IPV6-TRMGT TR-IPV6-TRMGT-001 TR-IPV6-TRMGT-002

TR-IPV6-TRMGT-003

TR-IPV6-WEBMG TR-IPV6-WEBMG-001

TR-IPV6-WEBMG-002

TR-IPV6-WEBMG-003

TR-IPV6-WEBMG-004

TR-IPV6-WEBMG-005

TR-IPV6-WEBMG-006

TR-IPV6-WEBMG-007

TR-IPV6-WEBMG-008

TR-IPV6-WEBMG-009

TR-IPV6-WEBMG-010

TR-IPV6-WEBMG-011

TR-IPV6-WEBMG-012

TR-IPV6-WEBMG-013

TR-IPV6-WEBMG-014

TR-IPV6-OTHER TR-IPV6-OTHER-001 TR-IPV6-OTHER-002

TR-IPV6-OTHER-003

Description

Ctg.

IPv6 Requirements General Requirements for IPv6 The device shall support Dual Stack the two IPv4 and IPv6 stack on the LAN and WAN interface (RFC4213, TR-124i2)

Network

The device shall support Client DHCPv6-PD Development of the DHCPv6 client that is responsible for the assignment of the prefix of the IPv6 sub network from WAN. Proposed prefix: /64, /56, /48 (RFC3633) The device shall support SLAAC Protocol responsible for the assignment of the IPv6 direction of the WAN of the CPE. On the LAN side it shall be supported to publish the IPv6 prefix (RFC 4862, TR-124i2). The device shall support DNS IPv6 To resolve names of domains of IPv6 directions (RFC3596, TR-124i2). It shall support the utilization of a DNS server with IPv6 address and support the resolution of domain names to an IPv6 address The device shall support Proxy DNSv6 The device shall support DHCPv6 Server To assign IPv6 directions on LAN side (RFC 3315, TR-124i2) The device shall support Statefull firewall Possibility to activate or deactivate a Firewall for IPv6 addresses for the services that requires it (TR-124i2, RFC6092) The device shall support Remote Management Support to remote management of IPv6 parameters by TR-069 (TR-069, TR-124i2) The device shall support Stateful Packet Inspection Possibility to activate or deactivate the Stateful Packet Inspection of IPv6 packets for the services that requires it The device shall support Port Control Protocol (PCP) Dynamic Ports Control (draft-ietf-pcp-base) The device shall support DynDNS Enable the user to point to a DynDNS server with an IPv6 Address The device shall support 6RD Support of tunneled IPv6 (TR-124i2, RFC5569) This functionality is only required for Spain implementation On the next requirements it will be detailed the Broadband Forum specification of its technical report "TR-124 issue 2", for accomplish the characteristics indicates on the requirements TR-IPV6-GENRQ-001 to TR-IPV6-GENRQ-012

M M

M M M M M M

M M

IPv6 - NET - Networking Protocols GEN.NET. 3 - If the device does not support IPV6, it SHOULD be software configurable or upgradeable to support IP Version 6 in the future. This means that the processing power, memory and networking components must be designed appropriately and be sufficiently robust to provide this support. NETv6 - IPv6 Networking Protocols GEN.NETv6.1 - The device MUST support IP Version 6, which is defined in IETF RFC 2460. GEN.NETv6.2 - The device MUST support enabling and disabling of IPv6. BRIDGE - Bridging

M M

WAN.BRIDGE.3 - If bridge mode is enabled for IPv4 on the device by default for LAN connected devices, the device MUST be able to support additional connections for TR-069 remote management addressability (using direct DHCPv4 or Static IPv4, PPP, etc.), and connections for any locally terminated service which require IP (v4 or v6) addressability (e.g. gateway integrated Voice ATA ports, etc.). Note that this special bridge mode that includes a device remote management session connection requires an additional WAN connection from the network. This requirement is considered conditional as a result due to the network side dependency, but the device must support this type of configuration. WAN.BRIDGE.4 - The device MUST be able to bridge IPv6 over Ethernet (EtherType 0x86DD). This includes bridging of multicast frames. WAN.BRIDGE.5 - The device MUST be able to manage IPv6 bridging for a WAN interface, separate from IPv4 treatment. WAN.BRIDGE.6 - The device MUST be able to manage IPv6 bridging separately for each WAN interface (if there are multiple WAN interfaces). 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. IPv6 CONNECT - Connection Establishment This module applies to IPv6 connections as well as IPv4, but only if the device has an IPv6 stack. 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. WAN.CONNECT.2 - Moved to WAN.CONNECT.ON-DEMAND.1 and 4 WAN.CONNECT.3 - The device MUST support a manual connect option for connections. In this mode the connection to the 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. WAN.CONNECT.4 - Moved to WAN.CONNECT.ON-DEMAND.6 WAN.CONNECT.5 - A manual way of disconnecting without waiting for a connection timeout MUST be provided. WAN.CONNECT.6 - Moved to WAN.CONNECT.ON-DEMAND.7 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. 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. IPv6 - CONNECT.ON-DEMAND - On-Demand Connection Establishment WAN.CONNECT.ON-DEMAND.1 - The device MUST support a connect on demand option for IPv4 connections that run over PPP. In this mode the connection to the broadband network is initiated when outbound traffic is encountered from the local LAN and terminated after a timeout period in which no traffic occurs. 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. WAN.CONNECT.ON-DEMAND.4 - The device MUST support a "connect on demand" option for IPv4 connections that run over Ethernet. WAN.CONNECT.ON-DEMAND.6 - The interval after which a connection timeout occurs MUST be able to be configured. WAN.CONNECT.ON-DEMAND.7 - A default timeout of 20 minutes SHOULD be used for connection timeouts or use an operator-specific configuration 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 M M M

I M M

M M M

M M

IPv6 - WAN Connection WAN.IPv6.1 - The device MUST support automated establishment of an IPv6 connection according to the flow in Annex A.2 of TR-124 issue 2 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. WAN.IPv6.3 - The device MUST allow the IPv6 stack to be enabled / disabled. 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 M 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). 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. WAN.IPv6.9 - The device MUST support stateless address auto-configuration (SLAAC), as a host, per IETF RFC 4862. 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). 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. 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. WAN.IPv6.13 - The device MUST support enabling / disabling of this IPv6 WAN connection interface. 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). WAN.IPv6.18 - The device MUST continue to use the connectivity parameters (obtained via RA or DHCP) and consider them valid until either they expire or the device is explicitly told to use different values. WAN.IPv6.19 - The device MUST NOT advertise any address prefixes on the WAN using the IPv6 Neighbour Discovery protocol, or advertise itself as a default router

M M M

M M

M M M M

WAN.IPv6.20 - The device MUST provide up to 4 instances of option-data within a single OPTION_VENDOR_OPTS (17) (RFC 3315) with IANA "ADSL Forum" Enterprise Number as the enterprise-number. Each instance will have one of the 4 sub-options from WAN.DHCPC.7 as the vendor-specific opt-code, with the corresponding value in the vendor-specific option- M data. If the value of a parameter is empty for the device, then the sub-option MUST be omitted. If there are no values to provide, the entire option MUST be omitted.

IPv6 - PPP.IPv6 - PPP Client for establishment of IPv6 connection WAN.PPP.IPv6.1- The device MUST support IPv6 over PPP per IETF RFC 5072 and RFC 5172. WAN.PPP.IPv6.2 - The device MUST support establishment of an IPv6 over PPPoE connection according to the flow in Annex A.1. of TR-124 issue 2 WAN.PPP.IPv6.3 - The device MUST allow any particular PPP connection to be configurable for IPv4-only, IPv6-only, or both. WAN.PPP.IPv6.4 - If the device is configured for multiple PPPoE connections, it MUST be possible to configure it to use the same login and password for all, so that only the domain is unique per connection. WAN.PPP.IPv6.5 - The RG MUST NOT tear down a shared (IPv4 and IPv6) PPP session if error conditions prevent only one IP stack (either IPv4 or IPv6) from working. The session MUST be torn down if error conditions apply to both stacks

M M M M

IPv6 - DoS - Denial of Service Prevention WAN.DoS.1 - The device MUST provide Denial of Service (DOS) protection for itself and all LAN CPE including protection from Ping of Death, SYN Flood LAND and variant attacks. The extent of this protection will be limited when the device is configured as a bridge in which only PPPoE traffic is bridged. This protection MUST be available when the device terminates IP (v4 or v6) or bridges IPv4. WAN.DoS.2 - The device MUST reject packets from the WAN with MAC addresses of devices on the local LAN or invalid IP (v4 or v6) addresses (e.g., broadcast addresses or IP (v4 or v6) Addresses matching those assigned to the LAN Segment). WAN.DoS.3 - The device MUST reject any unidentified Ethernet packets (i.e. any packet that is not associated with IP (v4 or v6) or PPPoE protocols). WAN.DoS.4 - The device MUST perform anti-spoofing filtering for IPv6. All IPv6 traffic sent to the WAN from the LAN MUST have an IPv6 source address with a prefix assigned to the LAN by the device, that was delegated from the WAN (through DHCPv6 or configuration). WAN.DoS.5 - Since the device must perform anti-spoofing filtering for IPv6, until it has an IPv6 LAN prefix delegation it MUST filter all upstream IPv6 traffic from the home.

M M

IPv6 - QoS - Quality of Service

WAN.QoS.1 - The device MUST support classification of WAN directed LAN traffic and placement into appropriate queues based on any one or more of the following pieces of information: (1) destination IP (v4 or v6) address(es) with subnet mask, (2) originating IP (v4 or v6) address(es) with subnet mask, (3) source MAC address, (4) destination MAC address, (5) protocol (TCP, UDP, ICMP, ) (6) source port, (7) destination port, (8) IEEE 802.1D Ethernet priority, (9) FQDN (Fully Qualified Domain Name) of WAN session, (10) Diffserv codepoint (IETF RFC 3260), (11) Ethertype (IEEE 802.3, 1998 Length/Type Field), and (12) traffic handled by an ALG, and (13) IEEE 802.1Q VLAN identification. WAN.QoS.2 - The device MUST support classification of WAN directed LAN traffic and placement into appropriate queues based on any one or more of the following pieces of information: (1) packet length. WAN.QoS.3 - The device MUST support the differentiated services field (DS Field) in IP (v4 or v6) headers as defined in IETF RFC 2474. 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 M

Class EF AF4 in-contract AF4 out-of-contract AF3 in-contract AF3 out-of-contract AF2 in-contract AF2 out-of-contract AF1 in-contract AF1 out-of-contract DE/BE Cs0 (optional) Cs1 (optional) Cs2 (optional) Cs3 (optional) Cs4 (optional) Cs5 (optional) Cs6 (optional) Cs7 (optional)

Description Realtime Premium class4 (in) Premium class4 (out) Premium class3 (in) Premium class3 (out) Premium class2 (in) Premium class2 (out) Premium class1 (in) Premium class1 (out) Default / Best Effort Class Selector 0 Class Selector 1 Class Selector 2 Class Selector 3 Class Selector 4 Class Selector 5 Class Selector 6 Class Selector 7

DSCP marking (name) ef af41 af42,af43 af31 af32, af33 af21 af22, af23 af11 af12, af13 be cs0 cs1 cs2 cs3 cs4 cs5 cs6 cs7

DSCP marking (decimal value) 46 34 36, 38 26 28, 30 18 20, 22 10 12, 14 0 0 8 16 24 32 40 48 56

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. 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. WAN.QoS.7 - The device SHOULD support setting the priority tag and VLAN ID values. This satisfies TR-101 R-02. 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. 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. WAN.QoS.10 - The device MUST duplicate the set of queues for each access session. This can be done logically or physically. 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. WAN.QoS.12 - The device SHOULD support aggregate shaping of upstream traffic. WAN.QoS.13 - The device SHOULD support per-class shaping of upstream traffic.

M M M

M M M M M 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. WAN.QoS.15 - The packet size threshold before fragmenting AF and BE packets MUST be configurable. 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 that this module applies to IPv6 if it is used as either the tunneled or the tunneling protocol. WAN.QoS.TUNNEL.1 - The device MUST be able to mark or remark the Diffserv codepoint of traffic that will be placed over a tunnel, based on classification of that traffic (prior to placing it on the tunnel) using any of the classifiers supported by the device. This only applies when the traffic is going from LAN to WAN. WAN.QoS.TUNNEL.2 - The device MUST be able to mark the Diffserv codepoint of the underlying tunnel or IEEE 802.1D Ethernet priority of Ethernet that is transporting the tunnel, based on classification of the tunneled traffic using any of the classifiers supported by the device. This only applies when the traffic is going from LAN to WAN. WAN.QoS.TUNNEL.3 - When the device receives tunneled traffic from the WAN, it MUST be able to mark or remark the Diffserv codepoint of thattraffic, based on classification of the tunneled traffic using any of the IP-layer or higher layer classifiers supported by the device. WAN.QoS.TUNNEL.4 - When the device receives tunneled traffic from the WAN, it MUST be able to mark the IEEE 802.1D Ethernet priority of the LAN Ethernet frame, based on classification of the tunneled traffic using any of the IP-layer or higher layer classifiers supported by the device. WAN.QoS.TUNNEL.5 - When the device receives tunneled traffic from the WAN, it MUST be able to mark or remark the Diffserv codepoint or mark the IEEE 802.1D Ethernet priority of the LAN Ethernet frame, based on classification of the WAN Ethernet, using any of the Ethernet-layer classifiers supported by the device. WAN.QoS.TUNNEL.6 - When the device receives tunneled traffic from the WAN, it SHOULD be able to mark or remark the Diffserv codepoint or mark the IEEE 802.1D Ethernet priority of the LAN Ethernet frame, based on classification of the underlying tunnel, using any of the IP-layer classifiers supported by the device. ADDRESSv6 - LAN IPv6 Addressing LAN.ADDRESSv6.1 - The device MUST create a Link Local (LL) address for its LAN interface, and perform Duplicate Address Discovery (DAD), per RFC 4862. It MUST always use the same LL address, even after reboot or power failure. LAN.ADDRESSv6.2 - The device SHOULD try alternate LL addresses, if DAD fails. The vendor can define the algorithm to be used in this case. LAN.ADDRESSv6.3 - The device MUST have a ULA prefix [RFC 4193]. It MUST always maintain the same prefix, even after reboot or power failure, unless this prefix is changed through configuration (in which case it maintains the changed value). LAN.ADDRESSv6.4 - The device MAY allow its ULA prefix to be changed through configuration. LAN.ADDRESSv6.5 - The device MUST support advertising a /64 from its ULA prefix through Router Advertisement to be enabled / disabled. When enabled, this /64 will be included in RA messages, with L=1, A=1, and reasonable timer values. LAN.ADDRESSv6.6 - The devices MUST support RFC 4861 Router Specification requirements (section 6.2). LAN.ADDRESSv6.7 - The device MUST support configuration of the following elements of a Router Advertisement: "M and O" flags (RFC 4861), Route Information (RFC 4191), and Default Router Preference (Prf) (RFC 4191). LAN.ADDRESSv6.8 - The device SHOULD support configuration of the following elements of a Router Advertisement: MTU (RFC 4861). LAN.ADDRESSv6.9 - The device MUST advertise (in RA) a /64 prefix from all prefixes delegated via the WAN interface. This will have L=1, A=1, and lifetimes per the received (from the WAN) delegation. LAN.ADDRESSv6.10 - The device SHOULD advertise DNS server using the RDNSS option in Router Advertisements (RFC 5006). DHCPv6 Server LAN.DHCPv6S.1 - The device MUST support DHCPv6 server messages and behavior per IETF RFC 3315. LAN.DHCPv6S.2 - The device MUST support and be configurable to enable/disable address assignment using DHCPv6. LAN.DHCPv6S.3 - The device MUST either have an algorithm or allow configuration (or both) as to which /64 prefix to use, from any received WAN prefixes or its own ULA prefix. LAN.DHCPv6S.4 - The device SHOULD be configurable to support rules as to which host devices will be assigned addresses through DHCPv6. That is, it should be possible for a service provider to place their own host devices in the premises and have the RG only support DHCPv6 address assignment to those devices. Note that this does not require use of the RA "M" flag, as the service provider host devices can be configured to always use DHCPv6 for address assignment. The DUID may help to identify host devices.

M M

M M

M M M M M M M M

M M

LAN.DHCPv6S.5 - The device MUST be configurable to enable/disable prefix delegation via DHCPv6. LAN.DHCPv6S.6 - The device MUST support delegation of any received WAN prefix and its own ULA prefix, that is shorter than /64, using mechanisms of RFC 3633.

M M

LAN.DHCPv6S.7 - The WAN / ULA prefixes that a device is allowed to further delegate SHOULD be configurable. LAN.DHCPv6S.8 - The device MUST support DHCPv6 Information_request messages. LAN.DHCPv6S.9 - The device MUST support the following DHCPv6 options: IA_NA (RFC 3315), IA_PD (RFC 3633), and DNS_SERVERS (RFC 3646). LAN.DHCPv6S.10 - The device SHOULD support Reconfigure Accept (RFC 3315) and pass the additional set of DHCP options received from the DHCP client on its WAN interface to IPv6 hosts.

M M M

LAN.DHCPv6S.11 - The options that the device will provide via DHCPv6 MUST be configurable.

DNSv6 - Naming Services (IPv6) LAN.DNSv6.1 - The device MUST act as a DNS server for IPv6-capable LAN devices by supporting IPv6 (AAAA) records in its DNS server (per RFC 3596) and allowing these records to be queried using either IPv4 or IPv6 transport (RFC 3901). LAN.DNSv6.2 - The device MUST attach all known (for the host device) globally scoped IPv6 addresses to the DNS record for a particular host device (see LAN.DNS.6), as AAAA records for that device. LAN.DNSv6.3 - The device SHOULD support dynamic DNS (DDNS) for devices to provide their own DNS information. This would override any DNS entries the RG may have created for the IP addresses included in the DDNS request. LAN.DNSv6.4 The device MUST be able to query for A and AAAA records using either IPv4 or IPv6 transport to DNS recursive name servers in the WAN. LAN.DNSv6.5 - The device SHOULD use a DNS recursive name server obtained through DHCPv6 option (23 OPTION_DNS_SERVERS) to query for AAAA records to the WAN, as its first choice. LAN.DNSv6.6 - When the device is proxying DNS queries for LAN devices, it SHOULD use the IPv6 transport regardless of the transport mode used by the LAN device, when querying to the WAN. This is only possible if the device has IPv6 addresses for DNS recursive name servers on the WAN. LAN.DNSv6.7 - The device MUST support receiving at least 2 DNS recursive name server IPv6 addresses from the network through DHCPv6 option OPTION_DNS_SERVERS (23) (RFC 3646). LAN.DNSv6.8 - The device SHOULD allow the user to specify that the network-learned or user-specified DNS recursive name server addresses be passed back to the LAN devices in DHCPv6 responses instead of the device's address itself as the DNS recursive name server(s). PFWDv6 - Port Forwarding (IPv6) LAN.PFWDv6.1 - The device MUST support security mechanisms described in draft-ietf-v6ops-cpe-simple-security. LAN.PFWDv6.2 - Individual port forwarding rules MUST be associated with a LAN device, not the IPv6 address of the LAN device, and follow the LAN device should its IPv6 address change. LAN.PFWDv6.3 - The port forwarding mechanism of the device SHOULD be easy to configure for common applications and user protocols (e.g., ftp, http, etc.) by specifying a protocol name or application name in a "Common Applications Names List" instead of a port number and protocol type. A partial list of applications for potential inclusion are identified in Appendix I. FWD - Connection Forwarding Note that the IPv6 parts of this module apply only if the device has an IPv6 stack. LAN.FWD.1 - The device MUST be able to route IP (v4 or v6) over Ethernet to LAN CPE. LAN.FWD.8 - The device MUST support accepting IP (v4 and v6) forwarding/routing information via the TR-069 interface. LAN.FWD.9 - The device MUST maintain route table entries for all connections it maintains on the WAN (e.g., per PVC, IP (v4 and v6) and PPP sessions) and for all LAN networks (including subnets). M M M M

M M M

M M

I M M M

LAN.FWD.10 - The device MUST allow for the selection of which traffic to forward over which connection (in the case of multiple PVCs, multiple PPPoE sessions, GPON Port ID, etc) according to any one or more of the following pieces of information: (1) destination IP (v4 or v6) address(es) with subnet mask, (2) originating IP (v4 or v6) address(es) with subnet mask, (3) source MAC address, (4) destination MAC address, (5) protocol (TCP, UDP, ICMP, ) (6) source port, (7) destination port, (8) IEEE 802.1D user priority, (9) FQDN (Fully Qualified Domain Name) of WAN session, (10) DiffServ codepoint (IETF RFC 3260), (11) Ethertype (IEEE 802.3, 1998 Length/Type Field), and (12) traffic handled by an ALG.

LAN.FWD.20 - If the network implements a TR-059 architecture, the device MUST be able to bridge IPv4 or route IPv4 or IPv6 over an Ethernet session concurrently with at least one device-originated PPPoE session on each PVC that is running bridged Ethernet over the AAL. LAN.FWD.21 - If the network implements a TR-059 architecture, the device MUST be capable of initiating at least two PPPoE sessions per PVC and forward the IP (v4 or v6) traffic above that to the LAN CPE. FW - Firewall (Basic) Note that this module applies to IPv6 as well as IPv4, but only if the device has an IPv6 stack. LAN.FW.1 - The device MUST drop or deny IPv4 access requests from WAN side connections to LAN side devices and the device itself except in direct response to outgoing traffic or as explicitly permitted through configuration of the device (e.g., for port forwarding or management). LAN.FW.2 - The device MUST support a separate firewall log to maintain records of all transactions that violate firewall rules. LAN.FW.3 - The firewall log file MUST be able to hold at least the last 100 entries or 10 Kbytes of text. LAN.FW.4 - If a firewall log is implemented, the file entries SHOULD not be cleared, except when the device is reset to its factory default settings. LAN.FW.5 - If a firewall log is implemented, the device MUST timestamp each firewall log entry. LAN.FW.6 - The RG MUST support the definition of IPv6 firewall rules separate from IPv4

M M

I M M M M M M

FW.SPI - Firewall (Advanced) Note that this module applies to IPv6 as well as IPv4, but only if the device has an IPv6 stack. LAN.FW.SPI.1 - The device MUST support a more robust firewall, such as one which provides a full OSI 7 layer stack stateful packet inspection and packet filtering function. LAN.FW.SPI.2 - The device SHOULD provide protection for the following: - Port scans - Packets with same source and destination addresses - Broadband packets with a broadcast source address - Broadband packets with a LAN source address - Invalid fragmented IP (v4 or v6) packets - Fragmented TCP packets - Packets with invalid TCP flag settings (NULL, FIN, Xmas, etc) - Fragmented packet headers (TCP, UDP and ICMP) - Inconsistent packet header lengths - Packet flooding - Excessive number of sessions - Invalid ICMP requests - Irregular sequence differences between TCP packets The extent of this protection will be limited when the device is configured as a bridge in which only PPPoE traffic is bridged. This protection MUST be available when the device terminates IP (v4 or v6) or bridges IPv4. LAN.FW.SPI.3 - Each type of attack for which protection is provided SHOULD be configurable on the device and on by default. LAN.FW.SPI.4 - The device MUST support passing and blocking of traffic by use of user and configurable defined rules. LAN.FW.SPI.5 - The device MUST support setting firewall rules by the TR-069 ACS which can not be altered by the user. If firewall rules are set via security policies in TR-098 profiles, or via other mechanism such as TR-069 file download, the rules MUST NOT be able to be overridden by user firewall rules.

I M

M M

LAN.FW.SPI.6 - The device MUST support the user temporarily disabling specific user defined rules or all user defined rules. LAN.FW.SPI.7 - The device MUST support the user specifying the order in which firewall rules are processed. LAN.FW.SPI.8 - The device SHOULD support specification of any of the following in a firewall rule: - destination IP (v4 or v6) address(es) with subnet mask - originating IP (v4 or v6) address(es) with subnet mask - source MAC address - destination MAC address - protocol (0-255, or by alias: TCP, UDP, ICMP, IP, IGMP, eigrp, gre, ipinip, pim, nos, ospf, ) - source port - destination port - IEEE 802.1D user priority - FQDN (Fully Qualified Domain Name) of WAN session - DiffServ codepoint (IETF RFC 3260) - Ethertype (IEEE 802.3, 1998 Length/Type Field) - Traffic fitting an ALG filter - IEEE 802.1Q VLAN identification - packet length - TCP flags (urg, ack, psh, rst, syn, fin) - IP option values (potentially name aliases) - logical interface of source - logical interface of destination

M M

LAN.FW.SPI.9 - The device MAY support filtering based on other fields unique to specific protocols. LAN.FW.SPI.10 - The device SHOULD support firewall rules which support generic pattern matching against the header or data payload of traffic. Logically this can be envisioned as: match(header[offset[,length|max]],condition) match(payload[offset[,length|max]], condition) where condition is (relationship, data) such as (=, ne, all, one, and, or) for a hex field (=, ne, gt, ge, lt, le) for a decimal/hex field (=, ne, contains) for a string field LAN.FW.SPI.11 - The device SHOULD support a set of pre-defined rules to which the user can set or reset their firewall settings to. LAN.FW.SPI.12 - If a set of pre-defined rules has been set on the device, the device rule set SHOULD be able to be used as the basis for a user maintained set of firewall rules. LAN.FW.SPI.13 - In addition to blocking or passing traffic identified by a firewall filter, the device MUST support other actions as well, including but not limited to: - logging on success or failure, - notification on success or failure (to email or pager if supported), - sending notification to a PC monitor application (either originator and or centralized source), and - requesting verification from a PC monitor application. LAN.FW.SPI.14 - The device MUST allow for configuration of global firewall values. LAN.FW.SPI.15 - The device firewall SHOULD be either ICSA certified or be able to display all the attributes necessary for ICSA certification for the current version of either the Residential Category or the Small/Medium Business (SMB) Category. LAN.FW.SPI.16 - Unless configured otherwise, DOS, port blocking and stateful packet inspection MUST be provided to all LAN devices receiving traffic from the WAN interface. REMOTE.TR-069 - Remote Management (TR-069) MGMT.REMOTE.TR-069.1 - The device MUST support the remote management protocol as defined in Broadband Forum TR-069 CPE WAN Management protocol. MGMT.REMOTE.TR-069.2 - The device MUST support Broadband Forum TR-098 Gateway Device Version 1.1 Data Model for TR-069 with support for the TR-098 Baseline:1 profile MGMT.REMOTE.TR-069.3 - If the device supports built-in file sharing clients (e.g. Windows Networking, CIFS, Samba) or includes integrated storage server functions, the device MUST NOT allow the use of the TR-069 file transfer mechanisms (i.e. Upload and Download RPCs) to place or retrieve files that are not explicitly authorized by the user on network shared storage locations which the device may have access to. REMOTE.WEB - Remote Management (Web Browser) Note that this module applies to IPv6 as well as IPv4, but only if the device has an IPv6 stack.

M M

M M

M M

MGMT.REMOTE.WEB.1 - The device MUST be able to allow temporary manual remote access to its Web GUI remotely from the WAN interface. MGMT.REMOTE.WEB.2 - When temporary WAN side remote access is enabled to the device, the remote access session MUST be started within 20 minutes and the activated session MUST time out after 20 minutes of inactivity.

MGMT.REMOTE.WEB.3 - The user MUST be able to specify that the temporary WAN side remote access is a read only connection or one which allows for updates. The default MUST be read only.

MGMT.REMOTE.WEB.4 - Temporary WAN side remote access MUST NOT allow for changing the device password.

MGMT.REMOTE.WEB.5 - Temporary WAN side remote access MUST be disabled by default.

MGMT.REMOTE.WEB.6 - Temporary WAN side remote access SHOULD be through HTTP over TLS (i.e., https using TLS).

MGMT.REMOTE.WEB.7 - The device SHOULD use a randomly selected port for temporary WAN side remote access to prevent hacking of a well-known port.

MGMT.REMOTE.WEB.8 - If a default port is used for temporary WAN side remote access, it MUST be 51003.

MGMT.REMOTE.WEB.9 - The user MUST specify a non-blank password to be used for each temporary WAN side remote access session. This information MUST not be saved across sessions.

MGMT.REMOTE.WEB.10 - The User ID for all temporary WAN side remote access sessions, if required based on the method of implementation, MUST be "tech" by default.

MGMT.REMOTE.WEB.11 - The user MUST be able to change the User ID for all temporary WAN side remote access sessions.

MGMT.REMOTE.WEB.12 - The device MUST allow only one temporary WAN side remote access session to be active at a time.

MGMT.REMOTE.WEB.13 - All other direct access to the device from the WAN side MUST be disabled and blocked by default.

HTTPS and Remote Management Complement Additionally from what is defined on the TR-124 issue 2 standard from Broadband Forum, is also required the following two requirements: MGMT.REMOTE.WEB.Additional It should be possible to enable/disable the remote web GUI access using the TR-069 ACS and retrieve the URL details needed to establish a remote GUI session MGMT.REMOTE.TR-069.Additional The device MUST provide a mechanism for the distribution of client certificates and certificate chains from the ACS to the device to facilitate the use of HTTPS for the ACS server and Download server communications.

I M

Details and comments (Spanish)

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC

FC FC

FC FC FC PC PC FC We don't have a PCP implementation ready. Comtrend needs to discuss with Telefonica the NC exactly scenario in order to implement it (Q4/2012). In roadmap. Q2/ 2012 NC FC

Esperando ms informacin

Waiting for further information.

PC

FC

FC FC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

PC

FC FC FC En roadmap. Q2/ 2012 In roadmap. Q2/ 2012 PC

Anotado

Noted FC FC

FC

OK

OK

FC FC

OK

OK

FC

FC

We can implement it if needed

NC

We can implement it if needed We can implement it if needed We can implement it if needed We can implement it if needed We can implement it if needed

NC NC NC NC NC

We can implement it if needed

NC

FC FC FC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

NC En roadmap. Q2/ 2012 In roadmap. Q2/ 2012 PC FC

En roadmap. Q3/ 2012

In roadmap. Q3/ 2012

NC FC

It will be customized according the Telefonica's NC specification once defined

FC FC FC FC

En roadmap. Q4/ 2012

In roadmap. Q4/ 2012

NC

IPv6 sobre PPP en roadmap. Q2/ 2012 IPv6 sobre PPP en roadmap. Q2/ 2012

IPv6 over PPP in roadmap. Q2/ 2012 IPv6 over PPP in roadmap. Q2/ 2012

PC PC FC

IPv6 sobre PPP en roadmap. Q2/ 2012

IPv6 over PPP in roadmap. Q2/ 2012

PC

IPv6 sobre PPP en roadmap. Q2/ 2012

IPv6 over PPP in roadmap. Q2/ 2012

PC

Customized Request we experienced simple DoS protect function on route mode (IPv4) only

PC

Feature not supported. It will be analyzed the NC implementation effort if Comtrend is shorlisted FC System check the source IP address after 'NAT' operation, it does not work with bridge mode and route mode without NAT System check the source IP address after 'NAT' operation, it does not work with bridge mode and route mode without NAT

PC

PC

PC

En roadmap. Q3/ 2012

In roadmap. Q3/ 2012

NC FC

Not all of DSCP markings are already implemented. We need to define the DSCP marking Telefonica specification applicable to the field

PC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC FC FC

En roadmap. Q2/ 2012 En roadmap. Q2/ 2012 En roadmap. Q2/ 2012 En roadmap. Q2/ 2012 En roadmap. Q2/ 2012 En roadmap. Q2/ 2012

In roadmap. Q2/ 2012 In roadmap. Q2/ 2012 In roadmap. Q2/ 2012 In roadmap. Q2/ 2012 In roadmap. Q2/ 2012 In roadmap. Q2/ 2012

NC NC NC NC NC NC

En roadmap. Q2/ 2012 En roadmap. Q2/ 2012

In roadmap. Q2/ 2012 In roadmap. Q2/ 2012

NC NC

Anotado

Noted

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

FC En roadmap. Q3/ 2012 In roadmap. Q3/ 2012 NC

En roadmap. Q2/ 2012 En roadmap. Q2/ 2012 En roadmap. Q2/ 2012

In roadmap. Q2/ 2012 In roadmap. Q2/ 2012 In roadmap. Q2/ 2012

NC NC NC FC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC FC

En roadmap. Q3/ 2012 En roadmap. Q4/ 2012

In roadmap. Q3/ 2012 In roadmap. Q4/ 2012

NC NC

La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012

DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012

PC FC

La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012 La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012

DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012

PC

DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012

NC

FC La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012 La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012 La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012 La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012 La implementacin del servidor DHCPv6 est en proceso de depuracin En roadmap. Q2/ 2012 DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012 DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012 NC

NC FC

DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012 DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012 DHCPv6 server implementation being debugged.In roadmap. Q2/ 2012

NC

NC

NC

FC FC

En roadmap. Q3/ 2012

In roadmap. Q3/ 2012

NC FC FC

En roadmap. Q4/ 2012

In roadmap. Q4/ 2012

PC FC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q4/ 2012 En roadmap. Q2/ 2012

In roadmap. Q4/ 2012 In roadmap. Q2/ 2012

PC NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

Anotado

Noted FC FC FC

FQDN not supported

PC

En roadmap. Q4/ 2012 En roadmap. Q4/ 2012

In roadmap. Q4/ 2012 In roadmap. Q4/ 2012

NC NC

Anotado

Noted PC PC PC PC PC PC

Implementacin del Firewall IPv6 en roadmap. IPv6 FW implementation in roadmap. Q2/ Q2/ 2012 2012 Implementacin del Firewall IPv6 en roadmap. Q2/ 2012 Implementacin del Firewall IPv6 en roadmap. Q2/ 2012 Implementacin del Firewall IPv6 en roadmap. Q2/ 2012 Implementacin del Firewall IPv6 en roadmap. Q2/ 2012 Implementacin del Firewall IPv6 en roadmap. Q2/ 2012 IPv6 FW 2012 IPv6 FW 2012 IPv6 FW 2012 IPv6 FW 2012 IPv6 FW 2012 implementation in roadmap. Q2/ implementation in roadmap. Q2/ implementation in roadmap. Q2/ implementation in roadmap. Q2/ implementation in roadmap. Q2/

Anotado Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

Noted IPv6 SPI FW implementation in roadmap. Q3/ 2012 PC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012 Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012 Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012 IPv6 SPI FW implementation in roadmap. Q3/ 2012 IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC NC

NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012 Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012 IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012

PC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012 Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012 IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC

Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012 Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012 Implementacin del Firewall SPI IPv6 en roadmap. Q3/ 2012

IPv6 SPI FW implementation in roadmap. Q3/ 2012 IPv6 SPI FW implementation in roadmap. Q3/ 2012 IPv6 SPI FW implementation in roadmap. Q3/ 2012

NC

NC NC

FC FC

Debugging stage of security RPC requirements. Schedule TBP

PC

Anotado

Noted

FC Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms Important customization efforts. Comtrend needs to understand the need of this requirement in order to implement it with strong security mechanisms

NC

NC

NC

NC

NC

NC

NC

NC

NC

NC

NC

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

En roadmap. Q2/ 2012

In roadmap. Q2/ 2012

NC

Cod. TR-APPRQ TR-APPRQ-GENRQQ

Description Application Layer Requirements General Requirements The device shall run a DHCP server for local subnets that can be enabled or disabled in both bridged or routed modes and shall provide IP address, subnet, gateway, DNS and lease time to the clients.DHCP generals as in RFC2131 DHCP options and BOOTP vendor extensions as in RFC2132 DHCP functions as in RFC2939 Procedures to define new DHCP functions and message types as in RFC2139 The supplier shall inform the maximum number of IP address in DHCP pool, with the minumum of 253 The device shall support DHCP relay. The device shall support DNS protocol (RFC1034/RFC1035/RFC2181) The device shall support DNS proxy so it can be DNS server for LAN devices. The supplier shall inform the maximum numer of entries in DNS cache DNS servers can be configured statically in the device DNS servers can be acquiered dinamically during PPP/IPCP negotiation as in RFC1877 (LCP method) The device shall support DNS relay so all DNS queries will be forwarded to the configured DNS servers as in RFC1034 and RFC1035 The device shall support an embedded PPPoA client The device will have its own embedded PPPoE client. The modem must be able to run at least one instance of integrated PPPoE client that complies with IETF RFC 2516 The device shall support NTP as in RFC1305 The device will support DHCP options 60, 240, 241, 242, 243, 244, 244. . It shall be also able to recognize special DHCP requests (identified via DHCP option 60: dhcp-class-identifier or vendor-class-identifier) and provide an IP address inside a configur-able subrange depending on DHCP request option 60 value. DHCP Pool-IP from 192.168.1.33 to 192.168.1.252. This definition of DHCP Pool-IP can be changed by request of each OB informed on the default configurations required by the OB DHCP Enable / Disable LAN Port Individualy

Ctg. Details and comments (Spanish)

TR-APPRQ-GENRQQ-001

TR-APPRQ-GENRQQ-002 TR-APPRQ-GENRQQ-003 TR-APPRQ-GENRQQ-004 TR-APPRQ-GENRQQ-005 TR-APPRQ-GENRQQ-006 TR-APPRQ-GENRQQ-007 TR-APPRQ-GENRQQ-008 TR-APPRQ-GENRQQ-009 TR-APPRQ-GENRQQ-010 TR-APPRQ-GENRQQ-011 TR-APPRQ-GENRQQ-012 TR-APPRQ-GENRQQ-013 TR-APPRQ-GENRQQ-014

M M M M M M M M M M M M M

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC

FC FC FC FC FC FC FC FC FC FC FC FC FC

Cod TR-CPEMG TR-CPEMG-GENRQQ TR-CPEMG-GENRQQ-001 TR-CPEMG-GENRQQ-002 TR-CPEMG-GENRQQ-003 TR-CPEMG-GENRQQ-004 TR-CPEMG-GENRQQ-005 TR-CPEMG-GENRQQ-006 TR-CPEMG-GENRQQ-007 TR-CPEMG-GENRQQ-008 TR-CPEMG-GENRQQ-009 TR-CPEMG-GENRQQ-010 TR-CPEMG-GENRQQ-011

Description CPE Management General Requirements Access to device configuration shall be protected via password Password protection shall be only avoided using local physical mechanisms to reset the device to default configurations TCP/UDP port for management interface shall can be changed for security reasons The device shall support a maximum of 3 attempts of authentication on management interface, disconnect if failed Different user profiles can be configured in the device to be used depending on the access method (local or remote, web, telnet, tr-069, etc) The device shall support at least 3 (three) different profile types: User, Admin and Technical Team It must be possible to change local user and password remotely Local management from user terminal (mostly PC) shall be available through LAN or WiFi interfaces All device parameter settings shall be configurable from management interfaces (IP, secondary IP, IGMP. DHCP, Traffic Shaping, IPS filter, QoS, Display random key WPA-PSK) All device parameter settings shall be configurable from management interfaces and apply without restart the CPE: (WAN, IP, DHCP, DNS, Wireless, SSID, Channel, Encryption, WEP 64/128, WPA, WPA2, WPS, Ports, Password) The device should comply ATM Forum Integrated Local Management Interface (ILMI) 4.0 The device shall suport a CLI configuration mode, with following minimum commands: save save_and_exit save_and_reboot reboot restore_defaults Lan configuration Wreless configuration (SSID, Encription mode and key, mac filter, channel) Password configuration virtual server configuration

Ctg. Details and comments (Spanish)

M M M M M M M M M M HR

TR-CPEMG-GENRQQ-012

TR-CPEMG-GENRQQ-013 TR-CPEMG-GENRQQ-014 TR-CPEMG-GENRQQ-015 TR-CPEMG-GENRQQ-016 TR-CPEMG-GENRQQ-017 TR-CPEMG-GENRQQ-018 TR-CPEMG-GENRQQ-019 TR-CPEMG-GENRQQ-020 TR-CPEMG-GENRQQ-021 TR-CPEMG-GENRQQ-022 TR-CPEMG-GENRQQ-023

Configuration protocols and methods. The device shall support TELNET and SSH M Configuration protocols and methods. The device shall support SNMPv1 and SNMPv2 protocol. Vendor shall provide details M about MIBs and SNMP traps support. SNMP v3 is highly recommended HR Configuration protocols and methods. The device shall support upload/download configuration by FTP (RFC0959). ASCII M format configuration text file Configuration protocols and methods. The device shall support TFTP (RFC1350) M Configuration protocols and methods. The device shall support SOAP 1.2 M Configuration protocols and methods. The device shall support TR-064 for LAN side configuration M The device shall support protocol ICMP according to RFC 792 (ping replies) M The device shall support local and remote firmware updates, with the same features than CPE had before. This updates M must be showing it through CPE LEDs The device shall support local and remote firmware updates using FTP M It must be possible to make a FTP firmware update from management system for devices and DSLAM from the same M manufacturer and highly recommended if device and DSLAM were made by different manufacturers

TR-CPEMG-GENRQQ-024 TR-CPEMG-GENRQQ-025 TR-CPEMG-GENRQQ-026

Firmware update process shall not interrupt service, but reboot is allowed It must be possible to cancel a firmware update process The device shall not lose the user settings when a firmware upgrade is done If there is an error during the firmware download and/or flash memory writing process the device shall be able to revert back to the previous firmware version without getting inoperative (must support double image and dual memory bank)

M M M Si se realiza un 'download' hacia una versin anterior que no soporte algunas de las nuevas funcionalidades, los parmetros de configuracin asociados se perdern.

TR-CPEMG-GENRQQ-027

TR-CPEMG-GENRQQ-028 TR-CPEMG-GENRQQ-029 TR-CPEMG-GENRQQ-030 TR-CPEMG-GENRQQ-031 TR-CPEMG-GENRQQ-032 TR-CPEMG-GENRQQ-033 TR-CPEMG-GENRQQ-034 TR-CPEMG-GENRQQ-035 TR-CPEMG-GENRQQ-036

The device shall be capable of being re-imaged with a previous firmware version which is older than the current firmware version. The device shall support Loopback IP (it will be used as origin IP to reply to management request if the device is accessed through this IP and also for SNMP traps) If the device implements a protocol that ensures IP access to the router in an alternative method (instead of using the console port), the supplier shall provide the specification of operation and the implementation details of the protocol

M M M

The supplier should provide the possibility of executing a script at boot HR The device shall support reset to factory defaults. The reset to factory defaults shall be executed by TR069, by software and M by pressing Reset Button (for at least 5 seconds). When performing factory reset, the device shall feedback to the user by a 2Hz blinking of all leds of the device for during the M perform of the factory reset activity (at least during 3 seconds) The device shall support manual enabling/disabling of ADSL connection. O The device shall support remote Management from central management through IP connection M The device shall support a web GUI configuration portal that shall be accessed via HTTP 1.1 according to RFC2616.Portal access must comply RFC2818 and must be correctly displayed in: Mozilla 1.5 or higher, Internet Explorer 6 or higher, Opera M 8.5.1 or higher, Safari 1.2 or higher, Google Chrome 2.0 or higher and Netscape 7 or higher. The device shall support persistent connections The vendor shall provide a GUI interface: - user friendly - mouse based - help menu based on HTML - adapted to OB language - maximum delay of 10s when accesing to the resources - visual or sound configurable alerts when the system state is modified - easily updatable - show supplier, device type, serial number, software/firmware version. upstream and downstream bit rate - multivendor and multiprotocol The web GUI inteface must show: modem vendor, modem type, modem serial number and line rate for upstream and downstream GUI management interface features. Parameters that shall appear in the interface: statistics, diagnosis and monitoring data

TR-CPEMG-GENRQQ-037

TR-CPEMG-GENRQQ-038 TR-CPEMG-GENRQQ-039

M M

TR-CPEMG-GENRQQ-040

GUI management interface features. As a minimum the following parameters shall be able to be read or readable and writeable as detailed below: Firmware Version (Read) Configuration Password (Write) PPP current connection time (read) PPP auto reconnection (read/write) PPP connect/disconnect (read/write) DSL bandwidth (read) Enable Ethernet Bridging (Read/write (This shall be Off by default)) DHCP Server IP address (read/write) WLAN. Encryption Method (WEP, WPA...) (read/write) WLAN. WEP Keys (Read/Write) WLAN. WPA Passphrase (Read/Write) WLAN. WLAN ON/OFF (Read/Write) GUI management interface features. The following parameters shall not be editable by the customer through the WEB GUI: PPP auto connect (always ON, manually only for TBB customers) Periodic Inform Enable (ON) Periodic Inform Interval (24h, 1h is the default value in the fw) ACS url (asc.o2online.de) ACS certificate (non disclosed) ACS username (OUI-serial) ACS password (o2acs) NTP server addresses (ntp0.voip.telefonica.de, ntp1.voip.telefonica.de) GUI management interface features. At least the following PPP session parameters shall be tracked and resetable: Data time counter (read/write) Download data counter (read/write) Upload data counter (read/write) GUI management interface features. It shall support a button to enable/disable the Data PPP session. For example for Time Based Billing users Management interface shall be used to see the user devices connected to the CPE (IPs in the DHCP pool and ARP table with the MAC addresses corresponding to those IP addresses) The management interface shall support device monitoring and diagnosis. Upstream and downstream line rate, upstream and downstream noise margin, upstream and downstream attenuation, upstream and downstream maximum line rate, upstream and downstream output power, DSL performance monitoring (ES, CV, FEC, ESFE, CVFE) The management interface shall support device monitoring and diagnosis about: - hw/sw problems - service adaptation (degradation if neccesary) to line status without DSLAM participation - SELT (Self End Line Test) shall be performed to know: copper loop length, presence of interferences, kind of interferences, etc - synchronized time - number of synchronizations from last reboot The management interface shall support device statistics (connection bit rate, SNR, tx/rx frames, error frames, CRC errors, HEC errors) in different protocol layers Device configurations or updates must not require a reboot of any user equipment (PC, ...) connected to it It must be possible to do ADSL2, ADSL2+ operation mode activation/deactivation from the management system The devices to be installed by Telefonica may have a serial port console according to EIA-232 with a nine-pin female connector or an alternative method of access by console, other connector or reusing an Ethernet port

TR-CPEMG-GENRQQ-041

TR-CPEMG-GENRQQ-042

TR-CPEMG-GENRQQ-043 TR-CPEMG-GENRQQ-044

M M

TR-CPEMG-GENRQQ-045

TR-CPEMG-GENRQQ-046

TR-CPEMG-GENRQQ-047 TR-CPEMG-GENRQQ-048 TR-CPEMG-GENRQQ-049 TR-CPEMG-GENRQQ-050

M M M O

TR-CPEMG-GENRQQ-051 TR-CPEMG-GENRQQ-052 TR-CPEMG-GENRQQ-053 TR-CPEMG-GENRQQ-054 TR-CPEMG-GENRQQ-055 TR-CPEMG-GENRQQ-056 TR-CPEMG-GENRQQ-057 TR-CPEMG-GENRQQ-058 TR-CPEMG-GENRQQ-059 TR-CPEMG-GENRQQ-060 TR-CPEMG-GENRQQ-061 TR-CPEMG-GENRQQ-062

The supplier shall provide the cable between device console port and PC (RS-232, USB...) Trace Interface.The device shall support a pcap interface to allow tracing on WAN interface including both PPP stacks and upper layer IP, TCP and SIP Trace Interface. The device shall support tracing on WAN for both VCIs to be sure which traffic type is going on which VCI Trace Interface. The device shall support the transfer of the pcap file to a monitoring PC using HTTP. This transfer shall be implemented in such a way that the RAM or flash capacity does not limit the size of the capture file. Trace Interface. The device shall provide details on tools and interfaces which are available for logging and viewing the information in [(DE)TR-DSL-TRI-010] and [(DE)TR-DSL-TRI-020] The manufacturer shall provide all the necessary interfaces configuration details to Telefonica in order to develop remote or local (autoinstallator) management apps. Management software, if needed, shall be provided in a format specified by each OB The capacity of CPU process must be higher to 500 MIPS. CPU never overcome 65 % of his capacity using whatever P2P application The configuration parameters of the graphical interface will be defined with each country at the time of deployment, the supplier must inform which parameters can be configured. GUI management interface features. The graphical interface will be customized for Telefonica and the supplier will carry out this development. Telefonica will deliver the standard format for the vendor awarded. GUI management interface must support different screen sizes, including screens of netbooks (10.1 "). If the provider has any problem it should inform and provide a deadline for solution. The supplier shall develop a friendly and visual (no windows terminal).configuration script "Click&install Printer Wizard" and "Click&browse USB Wizard", these scripts will be on the inside of the GUI for the end user can run it, this script should support Windows O.S. (XP, Vista and 7) and MACOSX (Leopard and Snow Leopard). May be considered other solutions that can facilitate self-discovery of their devices (printer and USB disk). The device shall suport a web GUI configuration portal that shall be accessed via HTTP 1.1 according to RFC2616. Portal access must comply RFC2818 and also must be correctly displayed in Google Chrome web browser. GUI shall support a CSS structure order to support up to three zoom levels in Google Chrome, Netscape, Safari, IE7+ and Firefox browsers The device shall support the standards SNMP and TR simultaneously on the same implementation of software/firmware without impacts on the functionality of each one of them

O M M M M I M O M M M M

TR-CPEMG-GENRQQ-063

TR-CPEMG-GENRQQ-064 TR-CPEMG-GENRQQ-065 TR-CPEMG-GENRQQ-066

M M M

TR-CPEMG-TR069 TR-CPEMG-TR069-001 TR-CPEMG-TR069-002 TR-CPEMG-TR069-003 TR-CPEMG-TR069-004

TR069 The device shall support remote management as specified in last version of TR-069 and TR-098 Broadband Forum standards The device shall support TR-143 Broadband Forum standard (this standard is included in TR-098 Amendment 2) The device shall support TR-111 Broadband Forum standard The device shall support the InternetGatewayDevice.DeviceConfig. parameter

M M M M

TR-CPEMG-TR069-005

The supplier must provide a list of full and partial support of the parameters described in the required TRs

TR-CPEMG-TR069-006

The device shall support "vendor-specific" extensions defined by the OB conforming vendor extensibility and usage conventions described in TR-106 and DeviceSummary parameter

TR-CPEMG-TR069-007 TR-CPEMG-TR069-008 TR-CPEMG-TR069-009 TR-CPEMG-TR069-010 TR-CPEMG-TR069-011 TR-CPEMG-TR069-012 TR-CPEMG-TR069-013 TR-CPEMG-TR069-014 TR-CPEMG-TR069-015 TR-CPEMG-TR069-016 TR-CPEMG-TR069-017 TR-CPEMG-TR069-018 TR-CPEMG-TR069-019 TR-CPEMG-TR069-020 TR-CPEMG-TR069-021 TR-CPEMG-TR069-022 TR-CPEMG-TR069-023 TR-CPEMG-TR069-024 TR-CPEMG-TR069-025 TR-CPEMG-TR069-026 TR-CPEMG-TR069-027

The device may support supplier specific provisioning capabilities and parameters conforming vendor extensibility and usage conventions described in TR-106 and DeviceSummary parameter. In that case it shall specify the related details. The device shall state if there is any limitation in the total number of SOAP envelopes that device can send/receive to/from the ACS in a single HTTP response. (MaxEnvelopes) The supplier must specify the different phases for upgrading the firmware over Auto-Configuration Server in detail and what timings can be expected if a Download speed of 1Mbps is assumed and what services are available during the different firmware upgrade phases. In the event of a failure the device shall be able to fall back to the last known working configuration as defined by DeviceConfig parameter ACS discovery. The device shall be pre-configured with the Auto Configuration Server URL. ACS discovery. The device shall use DNS to resolve the IP address of the ACS. ACS discovery. The device may use the DHCP option 82 to discover the IP address of the ACS server ACS discovery. The device shall come pre-configured with a secure root certificate to ensure only a trusted ACS can perform the auto-configuration. ACS discovery. The secure root certificate of the device shall be exchangeable by Firmware Upgrade of the device. OB to provide the root certificate ACS discovery. The device shall use the intermediate and server certificates received from the ACS during the HTTPS authentication process with the ACS ACS discovery. The device shall perform the authentication process from the lowest certificate to the upper one as described in section 6.1 of RFC 2459 ACS discovery. The device shall be capable to be pre-configured with TR-069 shared secrets of ACS as they described in the device Wan Management Protocol. Share secrets can include ACS URL and authentication credentials (username/password). These shall also be configurable by the ACS. ACS discovery. The devices shall be capable to connect to ACS system with or without authentication credentials ACS discovery. The device shall be auto-configurable over the DSL network and only over the preset ATM data PVC connection ACS discovery. Upon initial connection to the service provider network the device shall request its provisioning parameters from the ACS ACS discovery. The device shall provide a mechanism that after a power-up, the device sends an INFORM message to ACS in a certain randomised time. Such a mechanism protects ACS from overloading after a mass power failure in the home network. ACS discovery. When the device cannot contact the ACS, it shall randomly and logarithmically back off on its retries to avoid creating too much network traffic as per WT121 specification from the Broadband Forum The device shall support a port for the ACS to communicate on (ConnectionRequest) The device shall use port 443 to communicate with the ACS. Communication between CPE and ACS shall be performed via HTTPS The device shall use port 80 for firmware download The device shall support TCP keep alive

O I I M M M O M M M M M M M M M M M M M M

TR-CPEMG-TR069-028

The device shall support the following RPC methods defined in section 3.6 (table 5) of TR-069- Device WAN Mgmt Protocol including the optional methods: Device methods Responding Calling - GetRPCMethods - SetParameterValues - GetParameterValues - GetParameterNames - SetParameterAttributes - GetParameterAttributes - AddObject - DeleteObject - Reboot - Download - FactoryReset - Upload - ScheduleInform Server methods Calling Responding - Inform - TransferComplete Download method shall support FileType 3 Vendor Configuration File Upload method shall support at least FileType 1 Vendor Configuration File The device shall have the periodicInformInterval set to a default value. This value shall be reconfigurable by the ACS The device shall not issue a boot inform after the ACS modifies parameters which do not require a reboot of the device. The behaviour of the device after a Parameter change is as follow: - The ACS sends a SetParameterValues RPC to the device. - None of the parameters modified in the SetParameterValues RPC requires the device to reboot. - The SetParameterValuesResponse returned by the device contains a Status element with a value of 0. - The ACS ends the TR-069 session. - The device does NOT send a boot Inform as a result of the parameter change. The drivers of the 3G dongle must be actualize by the network using the ACS to request the new driver will be in a firmware/driver local database, so the modem will request to ACS a new driver according with dongle_ID. In this case the update will be automatic and will avoid the new firmware have all the dongle's drivers, in order to decrease memory space and introduce a flexibility to implement new dongles. The device should support at least the following actions through TR069: Monitoring - Identify LAN connected devices (WiFi and Ethernet), - ADSL / 3G connection status Fault detection Equipment configuration: - Return to factory setting - Firewall rules setting and erasing - NAT rules setting and erasing - WiFi configuration, SSID and WEP - DHCP configuration - 3G interface configuration Equipment firmware upgrading The device shall support the connection request with just one TCP session or with more than one TCP sessions

TR-CPEMG-TR069-029

TR-CPEMG-TR069-030

TR-CPEMG-TR069-031

Para agregar un nuevo driver 3G es necesario hacer una actualizacin de firrmware.

TR-CPEMG-TR069-032

TR-CPEMG-TR069-033

TR-CPEMG-TR069-034

The device shall support minimum one of this methods for SSL ciphers TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062) and TLS_RSA_WITH_RC4_128_MD5 (0x0004) The CPE must be able to complete the establishment of a new connection with the ACS (including the authentication SSL) in less than 10 seconds

TR-CPEMG-TR069-035

TR-CPEMG-DOCUM TR-CPEMG-DOCUM-001 TR-CPEMG-DOCUM-002 TR-CPEMG-DOCUM-003 TR-CPEMG-DOCUM-004

Documentation The supplier shall provide the user manual and administrator manual in OB language The supplier shall notify all HW/SW characteristics and functionalities Software management manuals must be provided by the supplier The device shall be Certified to work with Telefonica ACS Platform for TR069 compatibility. All certification costs should be paid by the proponent

M M M M

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC FC FC FC FC PC FC FC FC FC FC

FC

FC FC FC FC FC FC FC FC FC FC FC

FC FC FC If new SW has a configure at new features but old SW doesn't exist, downgrade to old SW FC will lost the configure in new features.

FC FC FC FC FC FC FC FC FC

FC

FC FC

FC

FC

FC

FC FC

FC

FC

FC FC FC FC

FC FC FC FC FC FC FC FC FC FC FC FC

FC

FC FC FC

FC FC FC FC

supported parameters.xml

FC

FC FC FC FC FC FC NC FC FC FC FC FC FC FC FC FC FC FC FC FC FC

FC

FC

FC

We can't update 3G driver individually. If future driver needs to be added, Comtrend will PC release new SW with that drivers directly.

FC

FC

FC Support TLS_RSA_EXPORT1024_WITH_DES_CBC_ FC SHA (0x0062) and TLS_RSA_WITH_RC4_128_MD5 (0x0004)

FC FC FC FC

Cod TR-OTHER TR-OTHER-GENRQQ TR-OTHER-GENRQQ-001 TR-OTHER-GENRQQ-002 TR-OTHER-GENRQQ-003 TR-OTHER-GENRQQ-004 TR-OTHER-GENRQQ-005

Description Other Features General Requirements Internal throughput capacity of the device: 64 byte Ethernet frames per second Device start up time 60 seconds Device synchronization time 60 seconds (after start up) The supplier will provide device default configuration info: VPI/VCI, Encapsulation, IP configuration, DHCP, Firewall preconfigured with OB parameters The supplier shall describe additional features of the device which may affect suitability of modem usage for the desired services

Ctg. Details and comments (Spanish)

M M M M M

TR-OTHER-GENRQQ-006

Device initialization process: 1) Network fully available and in perfect coverage conditions (it is assumed that the network does not cause any delay and can respond immediately to the PWI device messages) and PC and connection PC to device working properly 2) User connects PC to the LAN Port Interface 3) User powers on the device 3.1) device will initially perform internal checks which take typically around 5 secs. The DSL LED will start flashing. 3.2) device will then perform DSL synchronization which depending on line conditions typically will take around 30 secs. The DSL LED will stop flashing and remain on once the DSL connection is established. 3.3) device will then establish the PPPoE sessions and get IP address 3.4) DNS resolution is achieved 3.5) NTP server is contacted to update date and time of the device 3.6) device contacts with ACS to get its configuration (this only happens the first time the device is powered on or when the device is factory reset) 4) The user opens an Web Browser and the Web Browser displays an Internet Web page after less than 90 seconds

TR-OTHER-GENRQQ-007 TR-OTHER-GENRQQ-008

The memory must be at least 32MB The Flash memory must be at least 8MB The device shall have QR Code support for one-click Smart Phone WiFi configuration. It shall be provided a label to be added on the box with the factory default WiF configuration and also there shall be on the GUI a QR Code picture with the current WiFi configuration (the picture shall reflect the changes made by the user on the WiFI configurations). To use as reference: http://code.google.com/p/zxing/ and http://en.wikipedia.org/wiki/QR_Code

M M

TR-OTHER-GENRQQ-009

Comtrend necesita obtener ms informacin sobre este requisito

TR-OTHER-SERRQ TR-OTHER-SERRQ-001 TR-OTHER-SERRQ-002 TR-OTHER-SERRQ-003 TR-OTHER-SERRQ-004 TR-OTHER-SERRQ-005 TR-OTHER-SERRQ-006

Services Video Service shall be provided using multicast/unicast Simultaneous managing of 3 channel and data traffic with 24/2Mbit(download/upload) Video Service requirements. The DSL system shall inform about the multicast/unicast bandwidth in the user interface Video Service requirements. The DSL system shall inform for each multicast group about the addresses, Eth port, PVC and MAC that are being accessed Video Service requirements. 5 zapping/sec Video Service requirements. 0.3sec channel change maximum time

M M M M M

TR-OTHER-SERRQ TR-OTHER-SERRQ-007 TR-OTHER-SERRQ-008

Support of other key services and features - 3G dongle 3G backup for ADSL line (internet access and ACS/TR069 only, no IPTV, no voice) Automatic 3G backup in case of ADSL PPP session disconnection with configurable timer of 0-10 minutes and granulity 15 seconds ; default setting 1 min.

M M

En roadmap (Q2/2012) En roadmap (Q2/2012) En roadmap (Q2/2012) Comtrend ofrecer el mejor soporte a Telefnica para tener actualizados los drivers 3G en las sucesivas versiones de SW. Sin embargo, Comtrend no puede financiar el coste en certificaciones que implica este requisito. En roadmap (Q2/2012)

TR-OTHER-SERRQ-009

The drivers of the 3G dongle must be actualize by the network.Each 4 mounths, the provider must generate another firmware with the new devices.

TR-OTHER-SERRQ-010 TR-OTHER-SERRQ-011 TR-OTHER-SERRQ-012 TR-OTHER-SERRQ-013 TR-OTHER-SERRQ-014 TR-OTHER-SERRQ-015

Automatic return to ADSL connection after ADSL PPP session has been CONTINUALLY established with configurable timer of 0-10 minutes and granulity 15 seconds; default setting 1 min. Traffic must be routed/forced to the ADSL network once activated, to stop extra usage and extra cost on the 3G Dongle. WEBGUI Manual backup switch on/off HW Button manual backup switch on/off Immediate start of 3G backup in case of plugging of 3G dongle into USB port, when ADSL PPP session is disconnected One USB 2.0 ports USB power supply min. 650mA per port (respectively suitable for powering and connection of USB HDD) USB port status LEDs - Light off no device connected - Light on device connected - Blinking light device connected, data transport active USB printer support and sharing USB web camera . The device should support sharing USB connected disks printers with all devices connected to the LAN (Ethernet and WiFi) using LPD (Line Print Daemon) protocol. The supported printers should be at least the one appear in the following link http://www.qbik.ch/usb/devices/showdevcat.php?id=6 Support of USB flash disk and HDD and sharing USB connected disks with all devices connected to the LAN (Ethernet and WiFi) using SAMBA protocol (Server Message Block (SMB), also known as Common Internet File System, CIFS) USB port supports USB mass storage device for any External flash disk, HDD and 3G dongle modem with internal memory or memory card USB mass storage function without storage capacity limitation The device should support DLNA as a DMA (Digital Media Server), without need of transcoding functionality . DLNA certificate is required The device shall support UPnP (multimedia content) IGD (Internet Gateway Device) protocol for identify and discover the IP devices in the home network FAT, FAT32, NTFS file systems support MacOS and Linux file systems support SMB sharing with access rules per device setting separately for LAN and WAN access (read, read/write) Support of 3G dongle modem with mass storage function Future driver development for another USB dongle devices Modem GUI shall enable 3G dongle basic parameters setup (APN, IP,PAP/CHAP, DNS) default setting APN=internet, CHAP, IP and DNS dynamically set. Default setting APN=internet, CHAP, IP and DNS are dynamically set Setting of PIN code for SIM card and PIN code is not visible in WEBGUI

M M O M M M

TR-OTHER-SERRQ-016

TR-OTHER-SERRQ-017 TR-OTHER-SERRQ-018 TR-OTHER-SERRQ-019

M O M

TR-OTHER-SERRQ-020 TR-OTHER-SERRQ-021 TR-OTHER-SERRQ-022 TR-OTHER-SERRQ-023 TR-OTHER-SERRQ-024 TR-OTHER-SERRQ-025 TR-OTHER-SERRQ-026 TR-OTHER-SERRQ-027 TR-OTHER-SERRQ-028 TR-OTHER-SERRQ-029 TR-OTHER-SERRQ-030 TR-OTHER-SERRQ-031 TR-OTHER-SERRQ-032

M O M O M M M M M M M M M En roadmap (Q2/2012) En roadmap (Q2/2012) En roadmap (Q2/2012)

TR-OTHER-SERRQ-033 TR-OTHER-SERRQ-034 TR-OTHER-SERRQ-035 TR-OTHER-SERRQ-036 TR-OTHER-SERRQ-037 TR-OTHER-SERRQ-038 TR-OTHER-SERRQ-039 TR-OTHER-SERRQ-040 TR-OTHER-SERRQ-041 TR-OTHER-SERRQ-042 TR-OTHER-SERRQ-043 TR-OTHER-SERRQ-044 TR-OTHER-SERRQ-045 TR-OTHER-SERRQ-046 TR-OTHER-SERRQ-047

Support of other key services and features - VPN min. 8 VPN Tunnels in real time with IPSec/L2TP, L2TP nebo PPTP min. 2 Tunnels Dial-out and 6 Tunnels Dial-in in real time Please state max. IPSec throughput and confirm min. IPSec AES throughput 3Mbps summarilly in both directions set-up and save min. 20 Dial-in accounts Embedded IPSec, L2TP & PPTP client/server IKE key management DES, 3DES and AES encryption for IPSec MPPE Encryption for PPTP L2TP over IPSec L2TP/PPTP/IPSec pass-through TR-069 FW upgrade + parameter backup and restore TR-069 FW CPE upgrade + CPE parameter backup and restore TR-069 system Compatibility certificate from Manufacturer TR-069 system Compatibility certificate from Manufacturer Web Interface (GUI) The device shall support on GUI an assistant of configuration (Wizard) for the basic configuration of the device (PPP credentials, WiFi configuration) according to the flowchart and look and feel provided by each OB The device shall store and support the execution of a GUI with at least 1,5Mb size General Default Settings The device provide a firmware version with the parameters provided by each OB (e.g. PPP credentials, SNMP secret, WiFi configuration, TR069 parameters, etc.)

O O O O O O O O O O M M M M M

Details and comments (English)

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC FC FC FC FC

FC

FC FC

Comtrend need to clarify this requirement with PC Telefonica.

FC FC FC FC FC FC

In roadmap (Q2/2012) In roadmap (Q2/2012) In roadmap (Q2/2012)

PC PC PC

Comtrend will offer the best support to Telefonica in order to keep the 3G products NC updated. However, Comtrnd cannot afford the certification costs of this request.

In roadmap (Q2/2012)

PC FC FC FC FC FC

FC

FC PC FC

FC FC FC FC FC FC FC FC FC FC In roadmap (Q2/2012) In roadmap (Q2/2012) In roadmap (Q2/2012) PC PC PC

NC NC NC NC NC NC NC NC NC FC FC FC FC FC FC

Anexx - Specific of each country

Cod

Description

Ctg.

General Requirements
A_TR-GENRQQ-MECDE A_TR-GENRQQ-MECDE-001 A_TR-GENRQQ-POWSU A_TR-GENRQQ-POWSU-001 A_TR-GENRQQ-POWSU-002 A_TR-GENRQQ-POWSU-003 A_TR-GENRQQ-POWSU-004 A_TR-GENRQQ-POWSU-005 A_TR-GENRQQ-POWSU-006 A_TR-GENRQQ-POWSU-007 A_TR-GENRQQ-ELCHA A_TR-GENRQQ-ELCHA-001 A_TR-GENRQQ-ELCHA-002 A_TR-GENRQQ-CLICO A_TR-GENRQQ-CLICO-001 A_TR-GENRQQ-CLICO-002 A_TR-GENRQQ-CLICO-003 A_TR-GENRQQ-SECPR A_TR-GENRQQ-SECPR-001 A_TR-GENRQQ-SECPR-002 Mechanical Design The device shall have a WLAN ON/OFF button (The same button will be used to activate the simplified configuration WPS method) Power Supply The power cord connectors shall comply IRAM 2063 (no ground) or IRAM 2073 (with ground) compliant The power cord connector shall comply SN 354516:2001 The device shall comply ABNT NBR 5410 (low voltage installations) standards and TELEBRAS SDT N. 240-500-700 Emisso 01 AGO 1982: general specifications on DC power supply for telecom equipments The device shall comply SN EN 50160 (Voltage characteristics of electricity supplied by public distribution systems) Maximum power consumption. The devices with 4 Ethernet ports plus a WLAN interface shall not exceed and 8w (deliveries in year 2008) as in TS 102 533 Annex A The PSU shall comply NBR 14136 (Plugs for household until 20A / 250V AC) The device power adaptor shall be external Electrical characteristics The device shall keep active the ADSL connection after 10 dialing impulses series applied to line terminal as specified in sections 6.2.3 and 6.2.3(E)1 of UNE 133001-2 plus UNE 133001-2/1M modification. Lower voltage limit of 170V Climatic Conditions Storage temperature [-25, 70]C Device electrical values shall be accomplished in the range [-10,60]C, humidity class F and after 2 hours (DIN 40046). The maximum guaranteed temperature should be from 50 to 55 C Security and Protection The device shall comply TELEBRAS SDT- SDT 235-430-718: protection modules for general distribution The device shall comply ANATEL 238 (chapter 3) regulation: electrical security Electrical safety measures shall correspond to the requirements of EN 60950-1 (Information technology equipment Safety Part 1: General requirements). ADSL line electrical circuits must satisfy TNV-3 requirements and local interfaces circuits must satisfy SELV requirements M M M

M M M M M M M

M M M

M M

A_TR-GENRQQ-SECPR-003

A_TR-GENRQQ-ELECO A_TR-GENRQQ-ELECO-001 A_TR-GENRQQ-ELECO-002 A_TR-GENRQQ-ELECO-003 A_TR-GENRQQ-ELECO-004 A_TR-GENRQQ-ELECO-005 A_TR-GENRQQ-ELECO-006 A_TR-GENRQQ-ELECO-007

Electromagnetic Compatibility The device shall comply ABNT NBR 12304 (EMC limits and measure methods in IT equipments) The device shall comply TELEBRAS SDT n 240-600-703 Emisso 03 (06/11/1997): conditions and environmental tests for telecom products The device shall comply ANATEL 237 regulation over EMC The device shall comply ETSI EN 300 386 standard regarding telecom network equipments Equipment immunity as in EN 61000-4-2, EN 61000-4-3, EN 61000-4-4, EN 61000-4-5, EN 61000-4-6 and EN 61000-4-11 EM Emissions shall be as in EN 55 022 The device shall comply with homologation of CNC (Comisin Nacional de Comunicaciones - National Communication Commission)

M M M M M M M

A_TR-GENRQQ-ELECO-008 A_TR-GENRQQ-ELECO-009

The device shall comply with what's stated in the 2004/108 CE R.D. 1580 / 2006 Directive The PSU shall comply to UK Electrical regulations

M M

A_TR-GENRQQ-CONNE

Connectors The device shall support a Digital Subscriber Line (DSL) RJ45 port interface plugs according the specification [EIA/TIA-568B]. - 1, 2, 3, 6, 7 and 8 contacts: not used - 4 contact: U-R2a - 5 contact: U-R2b

A_TR-GENRQQ-CONNE-001

A_TR-GENRQQ-PACKA

Packaging and Accessories Packaging shall be properly identified in accordance with the general rules of Telefonica Department of Logistics, as reflected in the "Hoja de Definicin de Embalaje" and labelled according to "Norma de Etiquetado de Materiales de Catlogo" and NT.c0.0001 Ed6 and NT.c0.001 Appendix 1 Ed6. The packaging shall also include SACE label as defined in the product functional specifications provided by Marketing Department. Preparation as in NGA. 001 Ed. 1 March 2002 The device shall comply: - TELEBRAS SDT-201-420-110: barcode use as in UCC/EAN 128 - TELEBRAS SDT-201-420-111: barcode use as in EAN Shall be delivered a buttons based software (CD) for configure the supported services on equipment (PPPoE, IPTV, NAT, Static routes, etc.). The software shall configure automatically the services and should only ask for, through window messages, the parameters to each installation (e.g.: PPPoE credentials). The main goal of this configurator software is to facilitate the installation made by field technicians The packaging and accessories shall be compliance with Telesp Specification "NIM 0990-04" - "Norma de Inspeo de Material / Cdigo: NIM 0990 / Verso: 04 / Data: 15/07/2010"

A_TR-GENRQQ-PACKA-001

A_TR-GENRQQ-PACKA-002

A_TR-GENRQQ-PACKA-003

A_TR-GENRQQ-PACKA-005

A_TR-GENRQQ-PACKA-006

A_TR-GENRQQ-PPCAS A_TR-GENRQQ-PPCAS-001

Production Process Control and Samples The device manufacturer shall provide a CE Certificate on RFATS date for each hardware version of the device. Certificate Requirements. The device manufacturer shall provide a DSL Certificate on RFATS date for each firmware version of the DSL datapump. The DSL Certificate will be based on IOT tests with the DSLAMs used in the O2 DSL network. The test specification will be based on following standards : - 1 TR 112 (DTAG UR-2 7.0) - DSL Forum TR-067 - DSL Forum TR-100 - DSL Forum TR-105 Additional tests with O2 specific DSLAM profiles will be required. Certificate Requirements. The device manufacturer shall provide an Analog Port Certificate on RFATS date for each hardware version of the device. The analog port Certificate will be based around ETSI 201 970. The target values for certain parameters can however be adjusted to reflect the O2 goal to offer a best in market quality. The target values will be selected to represent the better third of what is on offer in the German market. The device shall pass all tests. Certificate Requirements. The device manufacturer shall provide ISDN Conformance Certification for each version of the ISDN firmware implementation. The conformance certificate should proof the correct handling of all Supplementary Services offered by the O2 DSL product. The conformance statement should also proof the correct denial of Supplementary Services not offered by O2 DSL product.Proper interworking with a minimum 99% of the ISDN devices in the german market is required.A list of 3rd party ISDN TE devices tested has to be provided by the device manufacturer

A_TR-GENRQQ-PPCAS-002

A_TR-GENRQQ-PPCAS-003

A_TR-GENRQQ-PPCAS-004

A_TR-GENRQQ-PPCAS-005

The Ethernet cables of the kit shall be UTP category 5e/6. The body of the RJ 45 Cable connector should be polycarbonate 8-way contact with phosphor bronze and layers of nickel and 2.54 m in at least 0.8 m in gold. Its color should be transparent and support a maximum voltage of 250 volts and AC current of 2 amps. The cable must be 4 pair, 24 AWG, Cat 5e / 6, minimum length of 1.5 meters in yellow, and meet the standard IEEE802.3 The body of the RJ 45 Cable connector should be polycarbonate 8-way contact with phosphor bronze and layers of nickel and 2.54 m in at least 0.8 m in gold. Its color should be transparent and support a maximum voltage of 250 volts and AC current of 2 amps. The cable must be 4 pair, 24 AWG stranded 7/32 , Cat 5e / 6, minimum length of 1.5 meters in yellow, and meet the standard IEEE802.3 The body of the RJ 45 Cable connector should be polycarbonate 8-way contact with phosphor bronze and layers of nickel and at least 0.8 m in gold. Its color should be transparent and support a maximum voltage of 250 volts and AC current of 2 amps. The cable must be 4 pair, 24 AWG, Cat 5e / 6, stranded 7/32, minimum length of 1.8 meters in yellow, and meet the standard IEEE802.3 4-way contact filled connectos and 2 pair cable can be acceptable under special agreement

A_TR-GENRQQ-PPCAS-006

A_TR-GENRQQ-PPCAS-007

A_TR-GENRQQ-PPCAS-008

A_TR-GENRQQ-PPCAS-009

Manufacturing Features Outer sheath PVC Type of conductor Circular, stranded Insulation Solid polyethylene Conductor Material Copper nu Nominal Outside Diameter 5.5 mm Approximate weight 33 kg/ km
The outer cover must present a smooth surface, uniform and free from any imperfection. The RJ 45 patch cord must have "boot" in the same color of the cable, injected in the same dimensional RJ-45 plug to prevent fatigue in the cable connection and to prevent accidental disconnection. The RJ45 UTP cable shall attend to ANSI/TIA/EIA-568-B with Standard mount T568B Retardant To Flame CLASS CM-IEC 60332-3 WRAPPING, PACKAGING AND IDENTIFICATION: Each RJ45 UTP cable is individually packed. The package must contain an identification with the following information: name of manufacturer, product description, batch manufacturing and Anatel Certification Identification of the RJ45 UTP cable must be located on its outer covering, with digit height, shape and spacing method for recording or printing, legibly and indelibly. Must appear the name or mark of manufacturer, date of manufacture or lot number and certification number of the UTP cable. The ANATEL Certification Identification of patch cord must be performed by a type identification label, printed legibly and indelibly affixed to one end of the set Identification of the RJ45 UTP cable must be located on its outer covering, with digit height, shape and spacing method for recording or printing, legibly and indelibly. Must appear the name or mark of manufacturer, date of manufacture or lot number and certification number of the UTP cable. WRAPPING, PACKAGING AND IDENTIFICATION: Each RJ45 UTP cable is individually packed. The package must contain an identification with the following information: name of manufacturer, product description and batch manufacturing Cable RJ-11

A_TR-GENRQQ-PPCAS-010

A_TR-GENRQQ-PPCAS-011

A_TR-GENRQQ-PPCAS-012

A_TR-GENRQQ-PPCAS-013

A_TR-GENRQQ-PPCAS-014

A_TR-GENRQQ-PPCAS-015

A_TR-GENRQQ-PPCAS-016

Width thickness length

Cable Size 4.8 mm +/- 0.2 mm 2.3 mm +/- 0.2 mm 1800mm +/- 50 mm

Width thickness length

Cable Size 4.8 mm +/- 0.2 mm 2.3 mm +/- 0.2 mm 1800mm +/- 50 mm

A_TR-GENRQQ-PPCAS-017

Cable RJ-11 - The cable must receive the application of a material that prevents their adherence to the outer casing so as to facilitate their stripping; - The external layer shall be made of gray thermoplastic material , smooth, even and free from any imperfection. - The string must consist of one or two pairs, having flexible conductors, 26 AWG, length 1.80 meters with an RJ-11 connector at each end of the cord. - The RJ-11 / 6 positions must consist of at least two phosphor bronze contacts, gold plated with a minimum thickness of 0.8 gold, on a layer of at least 1.27 a nickel Cable RJ-11 BRANDING: The identification of the cord must be located on an outer wrapping, with digit height, shape and spacing method for recording or printing, legibly and indelibly marked, or adhesive label with the same information above. In this recording must contain the name or mark of manufacturer, manufacturing date month / year or manufacturing lot. WRAPPING, PACKAGING AND IDENTIFICATION: Each RJ-11 cable is individually packed. The package must contain an identification with the following information: name of manufacturer, product description, batch manufacturing and Anatel Certification Cable RJ-11

A_TR-GENRQQ-PPCAS-018

A_TR-GENRQQ-PPCAS-019

A_TR-GENRQQ-PPCAS-020

A_TR-GENRQQ-OTHER

Others The device shall comply: - TELESP GT.ER.3430.012 (DSLmn ATM regulation) - TELESP GT.ER.3430.013 (DSLmn Ethernet regulation) - TELESP SP.ER.3430.012 (multiservice access equipments) - ANATEL 242 resolution and 16.902 report (equipment approval to install the device) Process or products developed from this specification are an intellectual property of Telefonica O2 Group The device shall be homologated agains SEC (Superintendencia de Electricidad y Combustible) and SUBTEL (Subsecretara de Telecomunicaciones)

A_TR-GENRQQ-OTHER-001

A_TR-GENRQQ-OTHER-002 A_TR-GENRQQ-OTHER-003

M M

Physical_Layer_Requiremements
A_TR-PHLRQ-LINRQ A_TR-PHLRQ-LINRQ-001 Line Requirements The device shall comply UNE-TBR 21, section 4 (physical connection procedure for network modems). M

A_TR-PHLRQ-LINRQ-002

IEC 60708 cables in Telefonica O2 Czech Republic access network. Quad copper wires of 0.4, 0.6 or 0.8 mm with polyolefin foamskin insulation with maximum diameter of 1.7 mm and a predominantly polyolefin cable sheath. Cables for internal installation use wires of 0.5 mm diameter with polyolefin foamskin insulation and have PvC M sheaths (both shielded and unshielded). In the older part of the access network are also installed metallic copper-core cables with diameters of 0.4, 0.6 and 0.8 mm with airpaper insulation. Finally underground cables are filled with a moisture-resistant jelly and self-supporting cables not filled with jelly and use only polyolefin insulation Spectral rules in the Czech Republic decompose the network into zones. In different zones may be applied different PSD (power spectral density) in the downstream channel The device shall operate over POTS lines using DSL Annex A (T1.413, G.992.1, G.992.3 and G.992.5)

A_TR-PHLRQ-LINRQ-003 A_TR-PHLRQ-LINRQ-004

M M

A_TR-PHLRQ-LINRQ-005

The device may operate over ISDN lines using DSL Annex B (G.992.1, G.992.3 and G.992.5) and ETSI TS 101 388 V1.1.1 The device shall operate over both POTS/ISDN lines using DSL Annex B (G.992.1, G.992.3 and G.992.5) By configuration, the device shall support SRA as defined on standards ITU-T G.992.3 and ITU-T G.992.5 By configuration, the device shall support G.INP as defined on standards ITU-T G.992.3 and ITU-T G.992.5

A_TR-PHLRQ-LINRQ-006 A_TR-PHLRQ-LINRQ-007 A_TR-PHLRQ-LINRQ-008

M M M

A_TR-PHLRQ-WANTC A_TR-PHLRQ-WANTC-001 A_TR-PHLRQ-WANTC-002 A_TR-PHLRQ-WANTC-003 A_TR-PHLRQ-WANTC-004 A_TR-PHLRQ-WANTC-005 A_TR-PHLRQ-WANTC-006 A_TR-PHLRQ-WANTC-007

Wan Access Technology The device shall have an ADSL over ISDN interface with 4B3T modulation The device shall be fully compatible with the specification ITE-BA 003 Ed 2 section 6 (Interface specification) The device shall be fully compatible with the specification ITE-BA 006 The device shall be fully compatible with the specification ITE-BA 010 The device shall be fully compatible with the specification ITE-BA 011 The device shall be fully compatible with the specification ITE-BA 004 The signals presented in the UR interface comply with paragraphs 5.1 and 6.2 of the Technical Specification TS 101 388. In the upstream solely activated carriers from 29 to 48 The signals presented at the UR interface comply with the initialisation sequence-tion described in paragraph 7 of the Technical Specification TS 101 388 v1.1.1, except that the initialization of the ADSL system is used only C-ACT2m tone. The presence of this tone will be interpreted as that the ADSL network unit is ready to receive carriers also below the per-puter 33. The device shall be able to work with the o2 DSL connection Manager PC Software client The supplier shall describe its future plan for multilatency as in G.992.3 and G.992.5 to support services with different latency requirements and optimize bandwidth optimization The device shall support Fast transmission mode with maximum one-way delay not exceeding 2 ms according to ITU-T G.992.1, section 7.1.4 The device shall support enhanced Interleaved transmission mode with extended range of S&D parameters (to increase INP value and simultaneously to achieve higher DSL rates): 1/16 S (DMT symbol per RS word) 64; 1 D (interleaving depth) 384 (optionally up to 511) Operating with G.992.5 Annex B the downstream bit rate is 16Mbps when the number of INP symbols is 2 with a delay of 16ms and 14Mbps when 4 symbols and 16ms delay. The device shall support measuring and transport of test parameters to ATU-C (DSLAM) as in G.992.3: - Channel characteristics function (CCF-ps) as in G.992.3, section 8.12.3.1 - Quiet line noise PSD (QLN-ps), as in G.992.3, section 8.12.3.2 - Signal-to-Noise Ratio (SNR-ps), as in G.992.3, section 8.12.3.3 - Loop Attenuation (LATN), as in G.992.3, section 8.12.3.4 - Signal Attenuation (SATN), as in G.992.3, section 8.12.3.5 - Signal-to-Noise Ratio margin (SNRM), as in G.992.3, section 8.12.3.6 - Attainable net data rate (ATTNDR), as in G.992.3, section 8.12.3.7 - Actual Aggregate Transmit Power (ACTATP) , as in G.992.3, section 8.12.3.8 The modem must support and show all the primitives on the ADSL line as defined in paragraph 8.12.1 and 8.12.2 of the G.992.5 and G.997.1 (5 / 2003). The modem must support and show the result of all test parameters defined in paragraph 12.3.i of G.992.3.

O M M M M M M

A_TR-PHLRQ-WANTC-008

A_TR-PHLRQ-WANTC-009 A_TR-PHLRQ-WANTC-010 A_TR-PHLRQ-WANTC-011

M I M

A_TR-PHLRQ-WANTC-012

A_TR-PHLRQ-WANTC-013

A_TR-PHLRQ-WANTC-014

A_TR-PHLRQ-WANTC-015 A_TR-PHLRQ-WANTC-016

M M

A_TR-PHLRQ-WANTC-017

Supports initialization process according to paragraph 7.10, 8.5.iy 8.13.i of G.992.5 and G.994.1 including among others the following features: "Power cutback capabilites" twoway transmission (paragraph 8.13.3. i G.992.5). Also include the following features: M "Determination pilot tone location", "short initialization procedure / Fast Start Up according to Clause 8.14 of G.992.5.

A_TR-PHLRQ-WANTC-018 A_TR-PHLRQ-WANTC-019 A_TR-PHLRQ-WANTC-020 A_TR-PHLRQ-WANTC-021 A_TR-PHLRQ-WANTC-022 A_TR-PHLRQ-WANTC-023 A_TR-PHLRQ-WANTC-024 TR-PHLRQ-WILAN A_TR-PHLRQ-WILAN-001

The device shall support inventory command as in G.992.3, section 9.4.1.4. The fields shallb e customized according to ISP: vendor id, version number and serial number The ATM bit rate shall be reported to the user. The supplier shall specify the Cell Delay Variation (CDV) for each relevant interval in a given range. Device shall describe its plan to support establishing multipair lines according to G.998.1 (ATM-based multipair bonding) to improve bit rate to line length ratio The device shall have immunity against continuous Gaussian noise proprietary defined by O2_CR and the device shall reach predifined DSL data rate in donwstream and upstream direction on specific line condition Power cutback capabilities (up and down) as in G.992.3, section 8.13.3 Power cutback capabilities (up and down) as in G.992.5, section 8.13.3i WLAN The SSIDs of the WLAN Interface must be WLAN_XXXX by defect, The SSIDs of the WLAN Interface must be WLAN_XXXX by defect, with "XXXX" the last bytes of MAC Ethernet (all characters of "WLAN_XXXX" must be on upper case) and the full MAC Address as default password It shall be evaluated and informed cost impacts for implementing 4dBi antennas with Tx between 20 and 30 dBm and at least 100 mW with a range of 100m. Application Layer Requirements - General Requirements The device shall be able to establish a VPN from one LAN client device with the paremeters: - LAN client IP - mask (default: 255.255.255.0) - device LAN IP (first of LAN subnet) - WAN IP - WAN mask (default: 255.255.255.252) - DHCP server off - NAT off

M M I I M M M

A_TR-PHLRQ-WILAN-002 TR-APPRQ-GENRQQ

A_TR-APPRQ-GENRQQ-009

Network_Layer_Requirements_IPv6
A_TR-IPV6-GENRQQ General Requirements for IPv6 The device shall be acomplish with the requirements presents in the document attached for IPv6 functionality including 6RD functionality (the 6RD is the major difference from the requirements on folder "Network_Layer_Requirements_IPv6" and this document. M
Especificacin Requisitos IPv6 en el CPE

A_TR-IPV6-GENRQQ-001

CPE_Management
A_TR-CPEMG-GENRQQ A_TR-CPEMG-GENRQQ-001 A_TR-CPEMG-GENRQQ-002 A_TR-CPEMG-GENRQQ-003 A_TR-CPEMG-GENRQQ-004 General Requirements The device shall support double image functionality for the firmware upgrade functionality The device shall have the Motive Certification for TR069 compatibility. All certification costs should be paid by the proponent. The device shall have the Ericsson Certification for TR069 compatibility. All certification costs should be paid by the proponent. The certification shall be presented to Telefonica until 50 days after device purchase's adjudication M M M M

The device shall be TR069 protocol compliance as proprietary extensions of Telefonica of Spain contained in the document Requirements_TR069_IGD_TE_Ed21.pdf , with the possibility to adapt to future requirements A_TR-CPEMG-GENRQQ-005 M

Requirements_TR0 69_IGD_T E_Ed21.pdf


R e q u i r e m e n t s _ T R 0 6 9 _ I G D _ T E _ E d 2 1 . p d f

A_TR-CPEMG-GENRQQ-006 A_TR-CPEMG-GENRQQ-007 A_TR-CPEMG-GENRQQ-008 A_TR-CPEMG-GENRQQ-009 A_TR-CPEMG-GENRQQ-010

The device shall be TR069 protocol compliance as proprietary extensions of Telefonica Latinoamerica, with the possibility to adapt to future requirements It shall be possible to the CPE to inform the MTU and MRU configured, and also it shall be possible to change it if needed It shall be possible to perform the trace route functionality from the CPE It shall be evaluated and informed cost impacts for supporting displaying the web GUI configuration portal correctly in Internet Explorer 5. It shall be evaluated and informed cost impacts for implementing web GUI Barracuda (from Telefonica) on the CPE as the user interface for customers Documentation TR-069

M M M M M

A_TR-CPEMG-DOCUM A_TR-CPEMG-DOCUM-001

A_TR-CPEMG-DOCUM-002

Preconfiguracin Flex para Argentina

A_TR-CPEMG-DOCUM-003

CD Autoinstalacin para Argentina

Other Features
A_TR-OTHER-SERRQ A_TR-OTHER-SERRQ-049 A_TR-OTHER-SERRQ A_TR-OTHER-SERRQ-041 TR-069 system Compatibility certificate from Manufacturer Serigrafia LAN4 "VoIP" Support of other key services and features - Future MiViewTV platform version Encapsulation: IPoE (PTM mod) or IPoEoA (ATM mod) RFC1483 bridged for IPTV VLAN / PVC2 - PVC-8.35, VLAN 835 O M

A_TR-OTHER-SERRQ-042

DHCP option 60 support in CPE (DHCP request with Vendor Class Identifier - VCI for STB ) Based on received option 60 from STB DHCP server in CPE add into DHCP response additional parameters - DHCP option 240 and IPTV DNS server address

A_TR-OTHER-SERRQ-043

One DHCP server - addresses for PC a STB will be from one subnet 192.168.1.0/24 with two pools support Pool1 PC pool= 192.168.1.2 100/24, gateway= .1, dns= internet Pool2 option 60 = class STB, pool= 192.168.1.110 120/24, gateway= .1, dns= private O2TV, option 240=OPCH multicast (get from DHCP client on PVC2) For TO2 CPE there is a new private address pool 192.x.y.z (originally 10.x.y.z) that will be used for public O2TV

A_TR-OTHER-SERRQ-044

DHCP client in CPE will communicate via PVC2 with IPTV DHCP server that will send the information about IPTV DNS server address and static routes to IPTV headend DHCP client shall apply option 121 / RFC 3442 to acquire static ruote to IPTV headend from DHCP IPTV server

A_TR-OTHER-SERRQ-045

CPE will store static-routes leading to IPTV headend into routing table: Internet + VOIP PVC1 - PPPoE - default to internet, NAT, Firewall and IPTV PVC2 - IPoE/IPoEoA , static-route do IPTV headend, DHCP klient, IGMP proxy, IGMP snooping, No Firewall, NAT / PAT - NAT/PAT IP 10.x.y.z , NAT IGMPv2, NAT RTSP, NAT HTTP , No NAT IP Multicast NAT /PAT RTSP IP table with STB IP address + port associated with translated IP address + port and at the same time CPE must properly route UDP VoD stream to proper STB i.e. CPE performs NAT/PAT RTSP TCP session + UDP stream redirect

A_TR-OTHER-SERRQ-046

Operator (Apllicable OB)

Details and comments (Spanish)

Details and comments (English)

TE

TASA O2CR TELESP O2CR O2CR TELESP ColTel

TE TE

TASA TASA TE

TELESP TELESP

Comtrend personalizar este requisito para el cumplimiento con el requisito. Comtrend obtendr el certificado de ANATEL 238 cuando est en lista corta.

Comtrend will make the CPE to comply with it Comtrend is going to get ANATEL 238 certificate when we are short list.

O2CR

TELESP TELESP TELESP O2CR O2CR O2CR TASA Comtrend obtendr el certificado de ANATEL 237 cuando est en lista corta. Comtrend is going to get ANATEL 237 certificate when we are short list.

TE O2 UK

O2DE

Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta.

TE

Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta.

TASA

Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta. Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta.

TELESP

TELESP

TELESP

O2CR O2DE

O2CR O2DE

Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta.

O2DE

El equipo no tiene puerto FXS.

Our CPE doesn't support FXS port

O2DE

Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta.

TELESP / TASA / TCh / TdP

TELESP / TASA / TCh / TdP

TCh

TE

TELESP / TASA / TCh / TdP / TE

TELESP / TASA / TCh / TdP / TE TELESP / TASA / TCh / TdP TELESP / TASA / TCh / TdP

TELESP

TdP

TdP

TELESP

TELESP, TASA, TCh, TE

TELESP, TASA, TCh

TELESP, TASA, TCh

TELESP, TASA, TCh

TELESP

O2 TCh

TE

O2CR

O2CR TLATAM and TE

TLATAM and TE TASA and Telesp Only G992.1 & G992.5 Annex A O2CR and O2DE TE TE

TE TE TE TE TE TE TE

TE

O2DE O2CR O2CR El equipo puede autodetectar G.992.3 y G.992.5. Our CPE can auto-detect G.992.3 & G.992.5 repeatly.

O2CR

O2CR

O2CR

TE TE

TE

O2CR O2CR O2CR O2CR O2CR TLATAM TE

ColTel

ColTel

TELESP

TE

See answers from "Network_Layer_Requirements_IPv6"

TLATAM TE and Tchile TLATAM and TE

TE

IPv6 datamodel schedule Q3/Q4 2012

TLATAM ColTel ColTel ColTel All OBs El coste ser proporcionado por separado. El coste ser proporcionado por separado. Quotation will be provided separatelly Quotation will be provided separatelly

TASA " TASA-TR069- Comtrend puede customizar acorde con el siguiente Comtrend can make a customization Requirements-2009V4- requisito de Telefnica si Comtrend entra en lista following your request when we are short list. 9DIC2009.xls" corta. TASA "PreConfig-WiFi- Comtrend puede customizar acorde con el siguiente Comtrend can make a customization Flex-2009-V6requisito de Telefnica si Comtrend entra en lista following your request when we are short list. 10nov2009.txt" corta. TASA "PreConfigCDAutoi-2009-V721OCT2009.txt" Comtrend puede customizar acorde con el siguiente Comtrend can make a customization requisito de Telefnica si Comtrend entra en lista following your request when we are short list. corta.

TASA

O2CR

O2CR

O2CR

O2CR

O2CR

O2CR

Fully Compliant (FC) Partially Compliant (PC) Non Compliant (NC)

FC

FC FC FC FC

FC FC

FC FC

FC FC FC

FC FC

FC

FC FC FC FC FC FC FC

FC FC

FC

FC

FC

FC

FC

FC

FC

FC

NC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC FC

FC

FC

FC FC

FC

FC FC FC

FC FC FC FC FC FC FC

FC

FC FC FC

FC

FC

FC

FC FC

FC

FC FC FC FC FC FC FC

FC

FC

FC

PC

FC FC FC FC

PC

FC FC FC FC FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

FC

Вам также может понравиться