BHS_ADSL2_Tech_Reqs_rev2

download BHS_ADSL2_Tech_Reqs_rev2

of 221

Transcript of BHS_ADSL2_Tech_Reqs_rev2

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    1/221

    1

    2

    2

    M

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    2/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    3/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    4/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    5/221

    . Development requirements

    Four categories of requirements are established:

    Mandatory (M): the device must support the characteristic in order to achieve Telefnica Group approval.

    Highly Recommended (HR): it is highly desirable the device supports this characteristic. This degree ofcompliance can evolve to Mandatory in subsequent versions of the document. Supporting this characteristic

    will be valued in the device commercial promotion.

    Optional (O): it is left up to the manufacturer whether the device supports this characteristic or not.

    Informative (I): manufacturer can enter a free text to provide information about the requirement/question.

    . Functional classification

    General

    WAN Interfaces

    LAN Interfaces

    Core Functionality

    Services

    Management

    Documentation

    . Glossary

    In the Scope of this document, the following definitions are applicable (only terms needing some clarification

    are included):

    3GPP: Third Generation Partnership Program

    10 Base-T: Ethernet Local Area Network

    AAL:ATM Adaptation Layer.

    AC:Alternating Current.

    ACCOMP: Address and Control field COMPression

    ACS:Auto-Configuration Server.

    ADSL: Asymmetric Digital Subscriber Line.

    ADSLmn: Asymmetric Digital Subscriber Line multinorm.

    AES: Advanced Encryption Standard

    ALG: Application Level Gateway

    AMR: Adaptive Multi-Rate

    ANSI: American National Standards Institute

    ATM: Asynchronous Transfer Mode.

    ATU-C:ADSL Transceiver Unit, Central office end

    ATU-R:ADSL Transceiver Unit, Remote terminal end.

    BER: Bit Error Rate

    BPS: Bits Per Second

    BRAS: Broadband Remote Access Server

    CCBS: Completion of Calls to Busy Subscribers

    ain blocks are:

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    6/221

    CCNR: Call Completion on No Reply

    CDV: Cell Delay Variation

    CHAP: Challenge Handshake Protocol.

    CLIP: Calling Line Identification Presentation

    CLIR: Calling Line Identification Restriction

    CPE: Customer Premises Equipment

    CRC: Cyclic redundancy check

    dBrnc: dB over noise reference (-90dBm) according to C curve

    DCF: Distributed Coordination Function

    DHCP: Dynamic Host Configuration Protocol.

    DMT: Discrete Multitone

    DNS: Domain Name Service

    DRA: Dynamic Rate Adaptation

    DRR: Dynamic Rate Repartitioning

    DSL: Digital Subscriber Line.

    DSLAM: Digital Subscriber Line Access Multiplexer.

    DSL Modem: Converts ATM cells to Ethernet packets and vice versa in the use of DSL

    DSSS: Direct Sequence Spreading Spectrum

    EAP: Extensible Authentication Protocol.

    EDCA: Enhanced Distributed Channel Access

    EIRP: Equivalent isotropically radiated power

    EOC: Embedded Operations Channel.

    ETSI: European Telecommunications Standards Institute

    FDM: Frequency Division Multiplexing

    FEC: Forward Error Correction

    FTP: File Transfer Protocol.

    GFC: Generic Flow Control

    GUI: Graphical User Interface.

    HCF: Hybrid Coordination Function

    HCCF: Hybrid Coordinator Function Controlled Channel Access

    HTML: Hyper Text Mark Language.

    HTTP: Hyper Text Transfer Language.

    ICMP: Internet Control Message Protocol.

    IEC: International Electrotechnical Commission.

    IETF: Internet Engineering Task Force

    INP: Impulsive Noise Protection

    IP: Internet Protocol

    IRC: Internet Relay Chat.

    ISDN: Integrated Services Digital Network

    ISO: International Organization for Standardization

    ISP: Internet Service Provider.

    ITU: International Telecommunication Union

    KBPS: Kilobits per Second.

    LAN: Local Area Network.

    LED: Light Emitting Diode

    MAC: Media Access Control

    MBPS: Megabits Per Second

    MDI: Medium Dependent Interface

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    7/221

    MIC: Message Integrity Check

    MIMO: Multiple Input and Multiple Output

    NAPT: Network Address & Port Translation.

    NAT: Network Address Translation.

    NIC: Network Interface Card.

    NTR: Network Timing Reference.

    OAM: Operation, Administration and Management

    OLR: OnLine Reconfiguration

    OSI: Open System Interconnection.

    PAP: Password Authentication Protocol.

    PC: Personal Computer.

    PAP: Password Authentication Protocol.

    POTS: Plain Old Telephone Service.

    PPP: Point to Point Protocol.

    PPPoA: PPP over ATM.

    PPPoE: PPP over Ethernet.

    PSD: Power Spectral Density

    PSK: Pre-Shared KeyPSTN: Public Switched Telephone Network

    PT: Port Translation.

    PVC: Permanent VC.

    PvC: Polyvinyl Chloride.

    PVP: Permanent Virtual Path.

    QoS: Quality of Service

    RFC: Request for Comments.

    RFQ: Request for Quotation.

    RPC: Remote Procedure Call.

    RT: Real-time.

    RTCP: RTP Control Protocol.

    RTP: Real-Time Transport Protocol

    RTSP: Real Time Streaming Protocol.

    SIM: Subscriber Identity Module.

    SDP: Session Description Protocol

    SNR: Signal to Noise Ration

    SOAP: Simple Object Access Protocol.

    SoC: Statement of Compliance.

    SRA: Seamless Rate Adaptation

    SSID: Service Set Identifier

    SVC: Switched VC.

    TCM: Trellis Code Modulation.

    TCP: Transmission Control Protocol.TKIP: Temporal Key Integrity Protocol

    TR: Technical Requirement.

    TXOP: Transmit Opportunity

    UDP: User Datagram Protocol.

    UNE: Una Norma Espaola

    USB: Universal Serial Bus

    VC: Virtual Connection

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    8/221

    VoIP: Voice over IP

    VP: Virtual Path.

    WAN: Wide Area Network.

    WECA: Wireless Ethernet Compatibility Alliance

    WEP: Wired Equivalent Privacy

    WiFi: Wireless Fidelity

    WLAN: Wireless Local Area Network

    WMM: WiFi MultiMedia

    WPA: WiFi Protected Access.

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    9/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    10/221

    Cod Description

    TR-GENRQQ General Requirements

    TR-GENRQQ-MECDE Mechanical Design

    TR-GENRQQ-MECDE-001The device shall be designed to allow vertical (wall mount) and horizontal mounting (desktop design). The c

    according to what will be decided by Telefonica

    TR-GENRQQ-MECDE-002 Power supply size shall not block or obstruct the use of the adjacent plugs

    TR-GENRQQ-MECDE-003 The device housing shall be white

    TR-GENRQQ-MECDE-004 The plastic of the device will be ABS+PC

    TR-GENRQQ-MECDE-005

    The device should use sockets colour scheme as in TR-068:

    Yellow (114c pantone) Ethernet ports

    Black power connectorGray (matte cool gray 3U) phone ports

    TR-GENRQQ-MECDE-006 The device shall have an ON/OFF labelled power button

    TR-GENRQQ-MECDE-007 The device shall have a reset button to restore default configuration. The button must be located at the bac

    TR-GENRQQ-MECDE-008The device shall have a WLAN ON/OFF button (The same button will be used to activate the simplified con

    method)

    TR-GENRQQ-POWSU Power Supply

    TR-GENRQQ-POWSU-001

    The device shall be designed for a local power supply AC mains: TE: 220-230V / 50Hz;

    O2CR: 220-230V (+/-10%) / 50Hz (+/- 4%);

    TLATAM(br): 90-240V (+/- 15%) / 60Hz (+/- 5%);

    TLATAM(pe): 90-240V (+/- 10%) / 60Hz (+/- 5%);

    TLATAM(ar;cl): 90-240V (+/- 10%) / 50Hz (+/- 5%)O2 UK: 100-240V (+/- 10%) / 50Hz (+/- 5%)

    TR-GENRQQ-POWSU-002 Device power input type: DC

    TR-GENRQQ-POWSU-003 The device power adaptor can be external or internal

    TR-GENRQQ-POWSU-004 The device power adapter shall be an automatic power switch

    TR-GENRQQ-POWSU-005 The device power cord minimum length shall be 2 meters

    TR-GENRQQ-POWSU-006 Power supply must be according to each conutry

    Argentina

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    11/221

    Brazil

    Chile

    Colombia

    Peru

    UK

    Spain

    TR-GENRQQ-POWSU-009 Power supply shall be labelled with device model and name

    TR-GENRQQ-POWSU-010 In case of power interruption the device shall reboot automatically

    TR-GENRQQ-POWSU-011 The device can not be powered via RJ11 interface

    TR-GENRQQ-POWSU-010 Power supply shall be according to EU RD 278/2009

    TR-GENRQQ-POWSU-011

    The device shall accomplish the European Union Code of Conduct on Energy Consumption of Broadband E

    Version 3, supporting a maximum of 12V DC and 1,5A and a have a hembra compatible connector:- External diameter: 5,50,05mm

    - Internal Diameter: 2,10,1mm

    - Length: 9,00,1mm

    TR-GENRQQ-POWSU-012The Power supply must be in conformity with Telefonica specification for Universal Power supply as defined

    document ERQ.c1.0001 2nd edition / Nov 2010 (document in Spanish)

    TR-GENRQQ-OPSTA Indication of Operating Status

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    12/221

    TR-GENRQQ-OPSTA-001

    TR-GENRQQ-OPSTA-002 Additional led Indicator to the four LAN ports

    TR-GENRQQ-OPSTA-003 In the Back side of the device it has to be identified a led for each of the Ethernet ports

    TR-GENRQQ-OPSTA-004 A 2 Hz blinking Green-Red round of Broadband led should inform the firmware updating and flash memory writing

    TR-GENRQQ-OPSTA-003 Additionaly to LED indicators the supplier may provide user software to monitor device activity

    TR-GENRQQ-ELCHA Electrical characteristics

    TR-GENRQQ-ELCHA-001

    The device shall comply ETSI TS 102 913 V1.1.1 technical specification:

    4.2 (insulation resistance between terminals)4.3 (DSL channel input impedance)

    4.4 (transitory response to call signal)

    4.5 (DC response to call signal)

    4.6 (voice channel longitudinal balance)

    4.7 (insulation resistance between line terminals and ground)

    4.8 (voice channel input impedance) sections

    TR-GENRQQ-ELCHA-002

    Noise level inserted by DSL channel into voice channel must comply:

    - 18dBrnC maximum when voice channel is not being used

    - less than 15 noise impulses with a maximum of 47dBrncO in 15 minutes during initiation and operation stages

    - less than 15 noise impulses with a maximum of 65dBrncO (at 1.004Hz, -13dBm0) in 15 minutes during initiation an

    operation stages.

    TR-GENRQQ-ELCHA-003 The equipment will meet the established requirements in TS 202 913 V1.2.2 Recommendation in the applicable as

    TR-GENRQQ-ELCHA-004DSL channel longitudinal balance: the device shall comply with the requirements of section 12.3.1 of ANSI T1.413-

    section A.4.3 of ITU-T G.992.1

    TR-GENRQQ-ELCHA-005DSL channel longitudinal balance must be higher than 40dB at [20 - 1.100]kHz when charging the DSL interface w

    600ohm

    TR-GENRQQ-ELCHA-006 DSL channel nominal impedance of 100ohm at DSL band in the PSTN interface

    TR-GENRQQ-ELCHA-007 DSL channel return loss at 30Hz - 1.100kHz equal or higher to 10dB

    TR-GENRQQ-ELCHA-008 Noise level inserted by the device to the DSL channel of the PSTN line shall be lower than -65dBmp

    LED Colour Mode Status

    Power Green Off Router powered offOn Router powered on

    Wifi Green

    On Wi-Fi connection is available

    Off Wi-Fi connection is not available

    Blinking green Negotiation or traffic on line

    3G Red/Green

    Blinking green Negotiation or traffic on line

    Solid green Up

    Quick blinking green Tx/Rx traffic on line

    Solid red Authentication failed

    Off Traffic through broadband interface

    Broadband Red/Green

    Blinking green PPP/DHCP negotiation

    Solid green PPP/DHCP up

    Quick blinking green Tx/Rx traffic on line

    Solid red Authentication failed

    DSL Green

    Off Router powered off

    Blinking 2Hz No line detected

    Blinking 4Hz Line training

    Solid Line up

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    13/221

    TR-GENRQQ-ELCHA-009

    Error rate caused by cross-talk interference shall be better than 10e-7 for a minimum noise margin of 6dB (m

    defined in paragraph 5.41: Measuring cross-talk noise margin of ETSI TS 388 V 1.3.1) taking into account tdue to the error correction mechanism

    TR-GENRQQ-ELCHA-010Errors due to impulsive noise at DSLAM interface shall be less than 0.14% error seconds (up to 15 impulse

    and with 1sec between impulses) as defined in ANSI T1.413, section 11.2.2 and ITU-T G.996.1, section 8.

    TR-GENRQQ-ELCHA-011 The analog ports shall perform according to ETSI ES 201 970 v1.1.1

    TR-GENRQQ-ELCHA-012 Inband noise (psophometrically weighted) for narrowband audio (300Hz 3.4kHz) shall be less than 75.0 d

    TR-GENRQQ-ELCHA-013 Inband noise (psophometrically weighted) for wideband audio (50Hz - 7kHz) will be less than 75.0 dBVp

    TR-GENRQQ-ELCHA-014Out-of-band noise (psophometrically weighted) for the human audible spectrum (30Hz - 20kHz) shall be les

    dBVp

    TR-GENRQQ-ELCHA-015

    Noise at mains frequency (50Hz) should not exceed 0.25 mV (psophometric weighed), this being the value

    terminals of the subscriber's set (when receiving). The subscriber's set assumed is only powered by the ana

    half of the value in G.120 paragraph 6.1)

    TR-GENRQQ-ELCHA-016 ALASS and other enhanced services as in 14.3 of ES 201 970 shall be supported

    TR-GENRQQ-CLICO Climatic Conditions

    TR-GENRQQ-CLICO-001

    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-1060

    solar radation of 700w/m2)

    TR-GENRQQ-CLICO-002The device shall be ready to be installed in non temperature or humidity controlled indoor environments at 0

    95% relative humidity conditions

    TR-GENRQQ-CLICO-003 Storage temperature [-25, 70]C

    TR-GENRQQ-CLICO-004 Device electrical values shall be accomplished in the range [-10,60]C, humidity class F and after 2 hours (

    TR-GENRQQ-CLICO-005 The device shall correctly work in salted environments (coast areas)

    TR-GENRQQ-SECPR Security and Protect ion

    TR-GENRQQ-SECPR-001 The device shall comply with the 73/23/CEE directive and the amendments to the 93/68/CEE directive

    TR-GENRQQ-SECPR-002The device shall tolerate security level 3 ESD as in IEC 801, part 2, sections 7 and 8. It's not allowed any a

    components due to contact or air discharges

    TR-GENRQQ-SECPR-003Minimum resistance shall be 100Mohm when 100Vcc applied between cover and line contacts, cover and p

    contacts and power wires

    TR-GENRQQ-SECPR-004

    Test device manufacturer must supply beforehand the corresponding user safety certification and associate

    by an accredited laboratory (EU directive 2006/95/CE compliance). Other norms applicable (technical norm

    - UNE EN 60950-1:2006+A11:2009

    - EN 50371:2002

    - EU Directive 99/05/CE

    TR-GENRQQ-ELECO Electromagnetic Compatibility

    TR-GENRQQ-ELECO-001The device shall comply with the 89/336/CEE directive and the amendments to the 93/68/CEE directive (rev

    directives)

    TR-GENRQQ-ELECO-002 The device shall comply ETSI 300 127, EM 55022-Classe A

    TR-GENRQQ-ELECO-003 No EM interferences between device and PSTN

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    14/221

    TR-GENRQQ-ELECO-004The device and its power supply shall continue working in spite of: ESD (ElectroStatic

    Discharges), EM radiations, RF transmitters presence and transitories/pulses or other variations in the pow

    TR-GENRQQ-ELECO-005

    WiFi interface shall comply with EN 300 328: Electromagnetic compatibility and Radio spectrum Matters (ER

    Wideband Transmission systems when data transmission equipment operate in the 2,4 GHz ISM band and

    spectrum modulation techniques

    - Part 1: Technical characteristics and test conditions

    - Part 2: Harmonized EN covering essential requirements under article 3.2 of the R&TTE Directive

    TR-GENRQQ-ELECO-006

    WiFi interface shall comply with EN 301 489: Electromagnetic compatibility and Radio spectrum Matters (ER

    ElectroMagnetic Compatibility (EMC) standard for radio equipment and services.

    - Part 1: Common technical requirements

    - Part 17: Specific conditions for 2,4 GHz wideband transmission systems

    TR-GENRQQ-OVERR Overvoltage and Overcurrent Resistibility

    TR-GENRQQ-OVERR-001 The device shall comply with the requirements of ITU-T Recommendation K.21

    TR-GENRQQ-OVERR-002Power supply shall resist (1000Vrms, 50/60Hz, 200mA current drain) for 30sec between phases and betwe

    and ground. After this test the isolated resistance of the power supply must be at least 200Mohm measured

    TR-GENRQQ-OVERR-003 The device shall have output overcurrent and overvoltage protection

    TR-GENRQQ-OVERR-004 The device shall have a protection fuse

    TR-GENRQQ-OVERR-005 The device shall have minimum resistance 1Mohm

    TR-GENRQQ-CONNE Connectors

    TR-GENRQQ-CONNE-001

    The device shall ensure proper contact between the male and female connectors of the elements inserted.

    shall be golden (or other similar material) with a minimum thick quality equivalent to 1.27um thick gold and t

    support stress, environmental life cycle and ageing tests.

    TR-GENRQQ-CONNE-002 The device shall have a RJ11 female connector for the WAN interface and use its internal pair (3rd and 4th

    TR-GENRQQ-CONNE-003 The device shall have 4xRJ45 female connectors for the LAN interface according the specification ANSI EIbe used with UTP cat5 cables)

    TR-GENRQQ-ENVRQ Environmental Requirements

    TR-GENRQQ-ENVRQ-001

    The device shall have low environmental impact. So it shall be produced using materials: tagged for recyclin

    without cadmium, solvent-free (water-based lacquers) with reusable packaging or failing foams without CFC

    and fuel, disposable in landfills or incinerators

    TR-GENRQQ-FREEF Freefall

    TR-GENRQQ-FREEF-001 The device shall be EM 60068-2-32 regulation compliant

    TR-GENRQQ-PPCAS Production Process Control and Samples

    TR-GENRQQ-PPCAS-001 The supplier shall provide the samples and means to perform quality tests

    TR-GENRQQ-PPCAS-002Device sample for approval test shall be identified by producer name, model name, version, serial number,

    chipset model and manufacturer and FW version

    TR-GENRQQ-PPCAS-003

    Telefonica inspectors can oversee device materials and production processes and

    perform recalls if the product does not satisfy any requirement (recalls can be

    carried out also when the product has already been delivered). Production critical points shall be notified to

    order to take actions if necessary and any SW/HW modifications shall be notified.

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    15/221

    TR-GENRQQ-PPCAS-004The device shall have a life cycle (the supplier shall be able to ship devices during 24 months from the tend

    - O2CR and TLATAM: 2 years

    TR-GENRQQ-PPCAS-005

    The device shall ensure a Mean Time Between (Hardware) Failure of:

    - O2CR: 100 days

    - O2DE: at least 1 year

    TR-GENRQQ-PPCAS-006 Faulty (total or partial) device rate = maximum 1 per 100 devices per year

    TR-GENRQQ-PPCAS-007 The device manufacturer shall provide a TR069 Score Card

    TR-GENRQQ-PPCAS-008

    Certificate Requirements. The device manufacturer shall provide a TR069 Certification on RFATS date for e

    version of the device.

    All mandatory TR-069 methods must be passed.The device must achieve 100% compliance for all profiles

    datamodel requested in this document.

    TR-GENRQQ-PPCAS-009

    The device supplier shall perform Interoperability Tests (IOT) with the supplier of Auto-Configuration Server

    selected before shipment of the devices. The OB shall inform the device supplier in advance but the supplie

    provide a list of the ACS systems on which IOT have been performed.

    TR-GENRQQ-PPCAS-010

    The device manufacturer shall provide IEEE 802.11n WECA Certification (according to the last avaliable ve

    Alliance accredited test laboratory. A list of 3rd party Wifi devices and tested firmware version has to be pro

    device manufacturer

    TR-GENRQQ-OTHER Others

    TR-GENRQQ-OTHER-001 Non device status dependant phone service

    TR-GENRQQ-OTHER-002 The supplier must be cert ified or commit to a deadline for certification in local regulator of each country

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    16/221

    Details and comments (English)

    Fully Compliant (FC)

    Partially Compliant (PC)

    Non Compliant (NC)

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    17/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    18/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    19/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    20/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    21/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    22/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    23/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    24/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    25/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    26/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    27/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    28/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    29/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    30/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    31/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    32/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    33/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    34/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    35/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    36/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    37/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    38/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    39/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    40/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    41/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    42/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    43/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    44/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    45/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    46/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    47/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    48/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    49/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    50/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    51/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    52/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    53/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    54/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    55/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    56/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    57/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    58/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    59/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    60/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    61/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    62/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    63/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    64/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    65/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    66/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    67/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    68/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    69/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    70/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    71/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    72/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    73/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    74/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    75/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    76/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    77/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    78/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    79/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    80/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    81/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    82/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    83/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    84/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    85/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    86/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    87/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    88/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    89/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    90/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    91/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    92/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    93/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    94/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    95/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    96/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    97/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    98/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    99/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    100/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    101/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    102/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    103/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    104/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    105/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    106/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    107/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    108/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    109/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    110/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    111/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    112/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    113/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    114/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    115/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    116/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    117/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    118/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    119/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    120/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    121/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    122/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    123/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    124/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    125/221

    Cod Description

    TR-PHLRQ Physical Layer Requirements

    TR-PHLRQ-WANTC Wan Access Technology

    TR-PHLRQ-WANTC-001 The device shall interoperate with any supplier DSLAM

    TR-PHLRQ-WANTC-002The device shall support a physical interface to connect, transmit and receive data from/to a DSL port that is

    the recommendation [T-Com TR112 (U-R2)].

    TR-PHLRQ-WANTC-003 The device shall have an ADSL over ISDN interface with 2B1Q modulation

    TR-PHLRQ-WANTC-004 The device shall comply the standard ANSI T1.413: ADSL

    TR-PHLRQ-WANTC-005 The device shall comply the standard G992.1 (G.DMT): ADSL transceivers using DMT modulation

    TR-PHLRQ-WANTC-006 The device shall comply the standard G992.2 (G.Lite): ADSL Lite

    TR-PHLRQ-WANTC-007 The device shall comply the standard G992.3: ADSL2

    TR-PHLRQ-WANTC-008 The device shall comply the standard G.992.3 Annex L: Extended Range ADSL2

    TR-PHLRQ-WANTC-009 The device shall comply the standard G.992.3 Annex M: Increased Upload Speed ADSL2

    TR-PHLRQ-WANTC-010 The device shall comply the standard G992.5: ADSL2+

    TR-PHLRQ-WANTC-011 The device shall comply the standard G.992.5 Annex L: Extended Range ADSL2+

    TR-PHLRQ-WANTC-012 The device shall comply the standard G.992.5 Annex M: Increased Upload Speed ADSL2+

    TR-PHLRQ-WANTC-013The DSL standard (ADSL/ADSL2/ADSL2+) to be used shall automatically negotiated between device and D

    speed DSL standard has priority and it is also allowed to statically enable/disable the use of each DSL stand

    TR-PHLRQ-WANTC-014Transmitters 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

    supported by the operator).

    TR-PHLRQ-WANTC-015 The device shall support ATM data transport over DSL as in T1.413-5.2, G.992.1-6.2, G.992.2-5

    TR-PHLRQ-WANTC-016

    The device shall support ATM Transport Protocol Specific functionalities over DSL (ATM TPS-TC sublayer)

    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

    and G.992.5-6 and Annex K (depending on the standards supported by the operator).

    TR-PHLRQ-WANTC-017The transport model will mandatory be ATM according to the reference model of ANSI T1.413 section 4.2.2.

    regulation. If STM mode is supported, it will be considered a value added, according to ANSI T1.413 section

    TR-PHLRQ-WANTC-018 If STM mode is supported, it will be considered as a value added to support all whats specified in ANSI T1.4

    TR-PHLRQ-WANTC-019The device shall operate in Simple Latency Mode (upload or download independent) as in T1.413-5.2, G.992

    and G.992.5 (depending on the standards supported by the operator)

    TR-PHLRQ-WANTC-020The device should be able to operate in Dual Latency Mode (upload or download independent) as in T1.413

    6.2, and G.992.3 (depending on the standards supported by the operator)

    TR-PHLRQ-WANTC-021The device shall support PTM Transport Protocol Specific Transmission Convergence functions over ADSL

    G.992.3, Section 6 and Annex K.3. All parameters in K.3.7.i and K.3.10 can be configured.

    TR-PHLRQ-WANTC-022The device shall support Physical Media Dependent function as in G.992.3-8 and G.992.5-8 (control parame

    G.992.3-8.5)

    TR-PHLRQ-WANTC-023 The device shall support Physical Media Specific Transmission Convergence function as in G.992.3-7 and G(transport capabilities as in G.992.3-7.1 and control parameters as in G.992.3-7.5)

    TR-PHLRQ-WANTC-024The device shall support Management Plane Procedures as in G.992.3, section 9 with the primitives describ

    8.12.1, G.992.3-8.12.2 and G.997.1. The L0, L1 and L3 states are mandatory as well.

    TR-PHLRQ-WANTC-025The Management Plane Procedure feature will be mandatory supported, according to whats described in G9.4

    TR-PHLRQ-WANTC-026 The device shall support Power Management functionalities as in G.992.3, section 9.5

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    126/221

    TR-PHLRQ-WANTC-027The Power Management feature will be completely supported according to whats described in G.992.3 se

    and 10.3. This is, the three states described in the regulation (L0, L2 and L3) must be supported.

    TR-PHLRQ-WANTC-028 The device shall support Programmed reduce framing overhead as in G.992.3TR-PHLRQ-WANTC-029 The device shall operate ensuring 10e-7 BER or better with a security noise margin

    TR-PHLRQ-WANTC-030 The device shall support Fast and Interleaved transmission modes

    TR-PHLRQ-WANTC-031The device shall support Interleaved transmission mode providing protection against impulsive (INP) noise a

    including Annex K.2.7

    TR-PHLRQ-WANTC-032The device shall transport ATM data over DSL using frames with the format defined in T1.413-6.4, T1.413-7.

    and G.992.1-8.4. The Formats 0, 1, 2, 3 and for are mandatory as well

    TR-PHLRQ-WANTC-033The device shall transport ATM data over ADSL2 using frame format defined in G.992.3-7.6 with programme

    overhead.

    TR-PHLRQ-WANTC-034 The device shall transport ATM data over ADSL2+ using frame format defined in G.992.5-7.6

    TR-PHLRQ-WANTC-035

    The device shall accept NTR (Network Timing Reference) as in T1.413-6.3, T1.413-7.3, G.992.1-7.3, G.992

    7.2 and G.992.3-7.8 (depending on the DSL standard in use).The NTR sent by the DSLAM is reconstructed

    in T1.413-5.2

    TR-PHLRQ-WANTC-036The device shall use Scrambling for error protection as in T1.413-6.5, T1.413-7.5, G.992.1-7.5, G.992.1-8.5

    7.7.1.3 (depending on the DSL standards supported)

    TR-PHLRQ-WANTC-037 The device shall use CRC checksums to detect errors

    TR-PHLRQ-WANTC-038The device shall support Forward Error Correction (FEC) as in T1.413-7.6, G.992.1-7.6, G.992.1-8.6, G.992

    G.992.5 (depending on the DSL standards supported)

    TR-PHLRQ-WANTC-039 FEC R, S and D parameters of T1.413 Table 10, G.992.1 Table 7.7 and G.992.2 Table 5 parameteres must

    TR-PHLRQ-WANTC-040 FEC Reed-Solomon coding support (with 3 words per symbol when G.992.5 is in use)

    TR-PHLRQ-WANTC-041The device shall use Trellis Coding Modulation (TCM) as in G.992.1-7.8, G.992.1-8.8, T1.413-7.8 but being a

    interoperate with DSLAM with no Trellis Coding Modulation.

    TR-PHLRQ-WANTC-042 The device shall support one-bit constellation encoding

    TR-PHLRQ-WANTC-043The device shall use Constellation Encoding (no Trellis) with a maximum number of bits per carrier between

    T1.413-7.9, G.992.1-7.9 and G.992.1-8.9

    TR-PHLRQ-WANTC-044 The device shall perform Gain Scaling as in T1.413-6.10, T1.413-7.10, G.992.1-7.19 and G.992.1-8.10 (depeDSL supported standards)

    TR-PHLRQ-WANTC-045 The device shall use modulation as in T1.413-6.11, T1.413-7.11, G.992.1-7.11, G.992.1-8.11 and G.992.1 A

    TR-PHLRQ-WANTC-046The device shall use 1.1MHz bandwidth and 256 subcarriers for T1.413/G.992.1/G.992.3 and 2.2MHz and 5

    for G.992.5

    TR-PHLRQ-WANTC-047 The device shall use subcarriers as in T1.413-6.7, T1.413-7.7, G.992.1-7.7, G.992.1-8.7 and G.992.1 Annex

    TR-PHLRQ-WANTC-048 The device shall perform Frequency Bands Separation using FDM

    TR-PHLRQ-WANTC-049Besides FDM the device can use Echo Cancellation to perform Frenquency Bands Separation but only if FD

    interoperability is guaranteed

    TR-PHLRQ-WANTC-050 The device shall use DMT modulation with 4,3125 kHz between subcarriers

    TR-PHLRQ-WANTC-051 The device shall control subcarriers transmission spectrum

    TR-PHLRQ-WANTC-052The device shall respect the frame structure "reduced overhead with merged fast and sync bytes" according

    7.4.3.2 using interleaved buffer

    TR-PHLRQ-WANTC-053 The pilot carrier (276kHz) cannot be modulated or transport user data when using T1.413, G.992.1 or G.992when using G.992.3

    TR-PHLRQ-WANTC-054 The device shall use Cyclic Prefix as in T1.413-6.12, T1.413-7.12, G.992.1-7.2, G.992.1-8.2 and G.992.1

    TR-PHLRQ-WANTC-055The device transmitter dynamic range shall comply T1.413-6.13, T1.413-7.13, G.992.1-7.13 and G.992.1-8.1

    on the DSL supported standards)

    TR-PHLRQ-WANTC-056The device transmitter spectral response shall comply T1.413-6.14, T1.413-7.14, G.992.1-7.14, G.992.1-8.14

    (depending on the DSL supported standards)

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    127/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    128/221

    TR-PHLRQ-WANTC-077

    The vendor must provide information about minimum and maximum upstream and downstream ATM bit rate

    - TE requires a minimum upstream bit rate of 800kbps and a minimum downstream bit rate of 8Mbps using AT1413 and 1M/24M using ADSL2+ G992.5 Annex A.

    - TLATAM requires a minimum upstream bit rate of 700kbps and a minimum downstream bit rate of 8000 kb

    ADSL (T1.413 or G.DMT), a minimum upstream bit rate of 600kbps and a minimum downstream bit rate of

    using ADSL Lite (G.Lite), a minimum upstream bit rate of 900kbps and a minimum downstream bit rate of 12

    using ADSL2 (G.992.3)and a minimum upstream bit rate of 900kbps and a minimum downstream bit rate of

    when using ADSL2+ (G.992.5)

    - O2CR requires an upstream bit rate between 32 to 25000 kbps and a downstream bit rate between 32 and

    TR-PHLRQ-WANTC-078 If the device needs a minimum link length larger than 0km the supplier shall report that value.

    TR-PHLRQ-LANET LAN Ethernet

    TR-PHLRQ-LANET-001The 8-pin interface mechanics shall comply with the requirements of section 3 of the IEEE 802.3 specification

    consistent with the figures of 1-5 ISO/IEC 8877: 1992

    TR-PHLRQ-LANET-002The device shall have Fast Ethernet 802.3u 100baseTX interface (compatible with 10baseT, 100baseTX, 10

    optionally with 1000baseTX) with bit rate autonegotiation

    TR-PHLRQ-LANET-003 The device Ethernet 802.3 interface shall detect and operate in half/full duplex modes

    TR-PHLRQ-LANET-004The device Ethernet 802.3 interface shall support Auto-MDI/MDI-X feature to detect the connection polarity (

    100baseTX or optionally 1000base-TX).

    TR-PHLRQ-LANET-005 The residential gateway shall offer four Ethernet ports and be able to operate as a switch at Ethernet level.

    TR-PHLRQ-WILAN WLAN

    TR-PHLRQ-WILAN-001 The wireless interface can be enabled/disabled via software from the user interface and via hardware facility

    TR-PHLRQ-WILAN-002 The device WLAN Interface shall operate in Access Point / Infrastructure Mode

    TR-PHLRQ-WILAN-003The router should support the wireless standard 802.11n 2.4GHz(2x2) in the last available version certified b

    Alliance. Troughput of WLAN to LAN shall be 100Mbps at last.TR-PHLRQ-WILAN-004 The device WLAN Interface shall ensure interoperability with IEEE 802.11b and IEEE 802.11g clients

    TR-PHLRQ-WILAN-005 The device WLAN Interface shall be able to operate at 2.4GHz frequency.

    TR-PHLRQ-WILAN-006 The device WLAN Interface shall be able to apply IEEE 802.11n standard features at 2.4GHz frequency ban

    TR-PHLRQ-WILAN-007

    The device WLAN Interface shall operate over frequency channels in 2.4GHz band: from 1 (2412MHz) to 13

    with 5MHz channel spacing. Defined for Europe in 802.11-2007, Wireless LAN Medium Access Control (MA

    Layer (PHY) Specifications, Clause 15, Table 15-7

    TR-PHLRQ-WILAN-008 The device WLAN Interface shall be able to operate using 20MHz channels in 2.4GHz band according to IE

    TR-PHLRQ-WILAN-009The device WLAN Interface may be able to operate using 40MHz bandwidth channels in 2.4GHz band acco

    802.11n

    TR-PHLRQ-WILAN-010 The device WLAN Interface may have DFS (Dynamic Frequency Selection) feature in 2.4GHz frequency ba

    TR-PHLRQ-WILAN-011The device WLAN Interface maximum transmitted power (EIRP) when using channels from 1 to 13 in 2.4GH

    not exceed 100mw in any combination of transmitter power output and supplied antenna

    TR-PHLRQ-WILAN-012 Power spectral density level shall comply with VO-R/12/08.2005-34 in operation bands (2.4GHz).

    TR-PHLRQ-WILAN-013The device WLAN Interface transmitter power output may be configured via web-based user interface (supp

    specify the range)

    TR-PHLRQ-WILAN-014 The supplier shall specify receiver sensitivity at BER 10-6 in dBm for each frequency band and every single

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    129/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    130/221

    TR-PHLRQ-WILAN-050 WPA2 user authentication can be performed via IEEE 802.1x protocol through EAP framework. Enterprise W

    TR-PHLRQ-WILAN-051

    WPA2 user authentication via EAP framework shall support the following methods: EAP-TLS, EAP-TTLS/M

    PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC and EAP-SIM as in IETF RFC4017. EAP peer and authentic

    authorization must be supported

    TR-PHLRQ-WILAN-052The WPA2 security shall include AES-based CCMP (Counter Mode with Cipher Block Chaining Message Au

    Code Protocol) for encryption and rekeying

    TR-PHLRQ-WILAN-053WPA2 security shall include MIC (Message Integrity Code) to avoid CRR (Cyclic Redundance Code) modific

    attackers

    TR-PHLRQ-WILAN-054 WPA2 security shall include Reply Attack Protection mechanisms

    TR-PHLRQ-WILAN-055 WPA2 key of the WLAN Interface shall be entered in hexadecimal format

    TR-PHLRQ-WILAN-056 WPA2 key of the WLAN Interface shall be entered in phrase format

    TR-PHLRQ-WILAN-057The WLAN Interface can be secured using MAC filter to control the access of certain MAC addresses to the

    network

    TR-PHLRQ-WILAN-058The MAC filter shall be able to operate in whitelist mode (only the registered MAC addresses are allowed to

    wireless network)

    TR-PHLRQ-WILAN-059The MAC filter shall be able to operate in blacklist mode (only the registered MAC addresses are not allowed

    the wireless network)

    TR-PHLRQ-WILAN-060 The device shall support MAC addresses self-learning of wireless clients

    TR-PHLRQ-WILAN-061 The supplier shall specify maximum number of MAC addresses registered in the access table

    TR-PHLRQ-WILAN-062

    The SSIDs of the WLAN Interface must be WLAN_XXXX by defect, The SSIDs of the WLAN Interface must

    WLAN_XXXX by defect, with "XXXX" the last bytes of MAC Ethernet (all characters of "WLAN_XXXX" must

    case)

    TR-PHLRQ-WILAN-063 The SSIDs of the WLAN Interface can be changed by the user.

    TR-PHLRQ-WILAN-064 The device WLAN Interface can be configured to not broadcast the SSIDs (SSID hiding feature)

    TR-PHLRQ-WILAN-065 The device WLAN Interface shall support Multiple SSID feature with a minumum of 4 SSIDs

    TR-PHLRQ-WILAN-066When using Multiple SSID, different settings can be asigned to each SSID: encryption, hiding, enabled/disab

    filteringTR-PHLRQ-WILAN-067 The device WLAN Interface shall support IEEE 802.11e QoS features

    TR-PHLRQ-WILAN-068 The device WLAN Interface shall comply Wifi MultiMedia (WMM) interoperability certification.

    TR-PHLRQ-WILAN-069The device WLAN Interface shall support Enhanced DCF Channel Access (EDCA) medium access control

    Transmit Opportunity (TXOP)

    TR-PHLRQ-WILAN-070 The device WLAN Interface HCF Controlled Channel Access (HCCA) medium access control method is opt

    TR-PHLRQ-WILAN-071 The device WLAN Interface shall support Automatic Power Save Delivery (APSD) or other similar mechanis

    TR-PHLRQ-WILAN-072The device WLAN Interface may support Block Acknowledgments (BA) to reduce overhead when longer TX

    specified

    TR-PHLRQ-WILAN-073The device WLAN Interface may be able to send frames with No Acknowledgement (NoAck) service class t

    retransmission of highly time-critical data.

    TR-PHLRQ-WILAN-074 WPS feature as user-friendly method to establish the WiFi configuration shall be provided in PBC (Push Bu

    Configuration) mode.

    TR-PHLRQ-WILAN-075Each unit shall have a unique phrase format WPA key and a customized SSID (to allow the user to recogniz

    network) in its default configuration

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    131/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    132/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    133/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    134/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    135/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    136/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    137/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    138/221

    TR-LINRQ-GENRQQ-027

    The device shall support the Multi-protocol Encapsulation over ATM AAL5 according to the specification RF

    2684, including LLC, LLC SNAP (MTU of AAL5 payload shall be at least 1528 byte -at least 1536 for ATM cetransport 1518 byte of Ethernet frames without fragmentation through PPPoE or not) and VCMux

    TR-LINRQ-GENRQQ-028The device shall support ATM QoS: service classes as in ITU-T I.371 and ATM Forum Traffic Management

    UBR, CBR and VBR

    TR-LINRQ-GENRQQ-029 Support of ATM QoS service Class ABR

    TR-LINRQ-GENRQQ-030 ATM QoS serv ice classes can be configured for each connection from the remote management system

    TR-LINRQ-GENRQQ-031ATM asymmetric/symmetric data bit rate is achieved depending on the ATM service class used (QoS param

    PCR)

    TR-LINRQ-GENRQQ-032 The device shall support ATM QoS Connection Admission Control (CAC) feature.

    TR-LINRQ-GENRQQ-033

    The device shall support ITU-T I.610 Operation And Maintenance (OAM) functions in F4 and F5 End to End

    flows:

    OAM F4 and F5 cells support

    VC-AIS / VC-RDI

    Continuity checkLoopback

    Forward and backward performance monitoring

    Activation / deactivation

    System management

    TR-LINRQ-GENRQQ-034

    If the device support processing of OAM cells (ITU-T I.610, I.751 and I.732) the supplier shall describe in det

    implemented algorithms. If OAM feature is not supported then data transmission shall not be affected when t

    receives OAM cells.

    TR-LINRQ-GENRQQ-035

    For operation and maintenance purposes the supplier of the ADSL modem and the type of the modem shall

    identified by information stored in the ATU-R registers ATU-R supplier ID (Register #0), ATU-R version nuone (Register #1), ATU-R serial number (Register #2) as specified in the ITU-T recommendation [G.992.1

    TR-LINRQ-GENRQQ-036

    After power up the ADSL modem of the DSL Port may perform a self test and report the self test result via th

    register Self test result (Register #3). If the self test succeeded and the ADSL modem is able to transfer datresult should be 0x00. If the self test fails, the result should be a value other than 0x00.

    TR-LINRQ-GENRQQ-037 Link layer for Internet service: The device shall support PPP line layer protocol in accordance with RFC791

    TR-LINRQ-GENRQQ-038 Link layer for Internet service: The device shall support PPP control protocol for IP (IPCP) in accordance wit

    TR-LINRQ-GENRQQ-039 Link layer for Internet service: The device shall not negotiate other network protocol over PPP (IPX, X25)

    TR-LINRQ-GENRQQ-040 Link layer for Internet service. PPP. PAP authentication for the PPP protocol (IETF RFC1334)

    TR-LINRQ-GENRQQ-041 Link layer for Internet service. PPP. CHAP authentication for the PPP protocol (IETF RFC1994)

    TR-LINRQ-GENRQQ-042Link layer for Internet service. PPP. The supplier shall describe if the device supports forced PPP authentica

    configured to authenticate using only CHAP, it shall inform the BRAS to use CHAP if it tries to use PAP

    TR-LINRQ-GENRQQ-043

    Link layer for Internet service. PPP. The supplier shall describe if the modem supports configuration of autom

    parameters in case of unsuccessful setup of PPP protocol. Modem must automatically retry setup of PPP pr

    delay between to consecutive retries of PPP setup should be configurable on modem in range 5 to 90 secon

    1 second. Default value of PPP setup rate must be set from 60 to 90 seconds

    TR-LINRQ-GENRQQ-044

    Link layer for Internet service. The supplier shall describe the modem behaviour if the modem sends PPPoE

    and the BRAS does not answer with PADO. The supplier shall describe the amount of consecutive PADI and

    interval within the consecutive PADI are sent. Max. 60 seconds between consecutive PPPoE PADI is requir

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    139/221

    TR-LINRQ-GENRQQ-045The device must send PPPoE PADT to BRAS at first when is restarted through internal tools (e.q. restart of

    reboot after upgrade of the device).

    TR-LINRQ-GENRQQ-046 The PPPoE PADI may be only sent to ADSL port. PPPoE PADI must not be sent to any LAN port when is no

    TR-LINRQ-GENRQQ-047

    Link layer for Internet service. The modem shall support PPP keep-alive option. PPP keep-alive parameters

    configurable on modem. Default value of PPP keep-alive must be set to send keep-alive (PPP echo-request

    seconds to BRAS and brings PPP session down if 5 consecutive keep-alive procedures fail (The modem do

    PPP echo-replay). The modem must answer to PPP echo-request from the BRAS sending PPP echo-replay

    TR-LINRQ-GENRQQ-048

    The device shall use the Point-to-Point Protocol over Ethernet (PPPoE) adaptation layer to establish Point-to

    (PPP) sessions according to the specifications [RFC 1144], [RFC 1332], [RFC 1334], [RFC 1570], [RFC 166

    [RFC 2865], [RFC 2869] with additions.

    TR-LINRQ-GENRQQ-049

    The device shall establish one PPP session within 1 second for all data traffic and the Auto-Configuration Se

    unique MAC address if the PPP session has not been established previously and the Auto-Configuration Clie

    Routing functionality requests the data connection

    TR-LINRQ-GENRQQ-050

    The device shall support the following retry mechanism in the case of an unsuccessful PPP Data session es

    No. No of retries Timeouts(secs) Description

    1 4 3 The initial retry must follow up relatively quickly in order to guarantee

    time.

    2 5 60 When the initial retry has failed 4 times this indicates something is w

    therefore to avoid unnecessary traffic it is suggested to have a retry after 60 secs until the limit of 5 is reache

    3 infinite 900 The device does a retry every 900 secs

    TR-LINRQ-GENRQQ-051Link layer for Internet service. The supplier shall describe allowed range and default value of maximum routa

    Default value 1492 is expected

    TR-LINRQ-GENRQQ-052Link layer for Internet service. The supplier shall describe allowed range and default value of maximum segm

    (MSS). Default value 1452 is expected

    TR-LINRQ-GENRQQ-053

    Link layer for Internet service. Adjusting of TCP maximum segment size: when IP packets with TCP payload

    between media with different MTUs (for example Ethernet 1500 and PPPoE 1492) the minimum value shall MSS, remote MSS and the MSS configured in the device)

    TR-LINRQ-GENRQQ-054Spanning tree protocol support in the link layer for TV service. This protocol bridging shall be done with no ch

    STP frames.

    TR-LINRQ-GENRQQ-055 Link layer for TV service. MAC table: limitations and acquiring and releasing rules

    TR-LINRQ-GENRQQ-056 Link layer for TV service. FCS checking: rule to check frame integrity

    TR-LINRQ-GENRQQ-057 Link layer for TV service. The modem shall support flooding broadcast

    TR-LINRQ-GENRQQ-058 Link layer for TV service. The modem shall support bridging all DHCP frames

    TR-LINRQ-GENRQQ-059 Link layer for TV service. The modem shall support flooding of multicast frames

    TR-LINRQ-GENRQQ-060 Link layer for TV service. The modem shall support flooding of unknown unicast frames

    TR-LINRQ-GENRQQ-061

    The device shall support a functionality to use prioritisation of outgoing packets between the following interfa

    - DSL Port Interface

    - LAN Port Interface

    TR-LINRQ-GENRQQ-062 The device shall support diffserv

    TR-LINRQ-GENRQQ-063 The device shall support the configuration of link type and connection type as per appendix B of TR098 on th

    TR-LINRQ-GENRQQ-064

    The device shall support a separate layer2bridging instance for the IPTV passthrough.

    Above mentioned VCs and some of the Ethernet ports can be assigned to this bridging instance through TRAppendix A5 of TR098 shall be used.

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    140/221

    TR-LINRQ-GENRQQ-065The device shall support a separate layer3forwarding instance for the IPTV passthrough.

    Above mentioned VCs and some of the Ethernet ports can be assigned to this routing instance through TR0

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    141/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    142/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    143/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    144/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    145/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    146/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    147/221

    TR-NETRQ-ROUTI-011The device shall be able to run in NAT mode to translate IP addresses in accordance with IETF RFC 3022. N

    preserve TOS field of IP header when IP packet is going through translation process in both directions

    TR-NETRQ-ROUTI-012The device shall be able to run in NAT mode to translate IP addresses in accordance with IETF RFC 3022. T

    shall specify amount of maximum simultaneously established session

    TR-NETRQ-ROUTI-013

    The Network and Port Address Translation of the device shall be based on ports defined in the Transmission

    Protocol (TCP) according the specification [RFC 793] and in the User Datagram Protocol (UDP) according th

    [RFC 768].

    TR-NETRQ-ROUTI-014The PAT functionality shall be able to carry out TCP/UDP mappings of external addresses and ports to differ

    addresses and ports

    TR-NETRQ-ROUTI-015 PAT minimum table size of 80 entries. Vendor shall specify maximum number of entries.

    TR-NETRQ-ROUTI-016 The PAT funcionatily shall support DMZ

    TR-NETRQ-ROUTI-017 NAT shall be transparent for IPSec (NAT traversal): VPN pass-through

    TR-NETRQ-ROUTI-018

    NAT shall be transparent for protocols that support NAT/PAT and shall use ALG (Application Level Gateway

    not support NAT/PAT: ICMP, HTTP, RTSP, FTP, TELNET, DNS queries, POP3, SMTP, IRC, Real Audio, O

    Netmeeting, Instant Messaging (ICQ, MSN...), Softphone, Video Messenger, UPNP, Microsoft MMS...)

    TR-NETRQ-ROUTI-019The modem shall support acquiring WAN default route during PPP negotiation. Default route shall be install a

    PPP session is established. Default route shall be withdrawn as soon as the PPP session is disconnected

    TR-NETRQ-ROUTI-020

    Both in bridged or routed modes time to transfer packets among interfaces must comply:

    - 5ms between LAN and WLAN

    - 15ms between PPP/WAN and LAN or WLAN

    TR-NETRQ-ROUTI-021

    Both in bridged or routed modes throughtput between interfaces must comply:

    - 16Mbps between PPP/WAN and LAN

    - 1Mbps between PPP/WAN and WLAN

    TR-NETRQ-ROUTI-022 The device shall support IP fragmentation

    TR-NETRQ-ROUTI-023The routing functionality of the device shall support the Internet Control Message Protocol (ICMP) according

    specification RFC 826.

    TR-NETRQ-ROUTI-024 The number of sessions supported by UDP should not be lower than 512 no matter how long the packet is

    TR-NETRQ-ROUTI-025 The device shall support IETF RFC 0894 Standards for the Transmission of IP Datagrams over Ethernet Ne

    TR-NETRQ-ROUTI-026 The device shall support IETF RFC 0922 Broadcasting Internet Datagrams in the Presence of Subnets

    TR-NETRQ-ROUTI-027 The device shall support IETF RFC 0950 Internet Standard Subnetting Procedure

    TR-NETRQ-ROUTI-028 The device shall support IETF RFC 1009 Requirements for Internet Gateways (Link Layer issues only)

    TR-NETRQ-ROUTI-029 The device shall support IETF RFC 1042 Standard for the Transmission of IP Datagrams over IEEE 802 Ne

    TR-NETRQ-ROUTI-030 The device shall support IETF RFC 1112 Host Extensions for IP Multicasting

    TR-NETRQ-ROUTI-031 The device shall support IETF RFC 1122 Requirements for Internet Hosts Communication Layers

    TR-NETRQ-ROUTI-032 The device shall support IETF RFC 1123 Requirements for Internet Hosts Application and Support

    TR-NETRQ-ROUTI-033 The device shall support IETF RFC 1256 ICMP Router Discovery Messages (Router Specification only)

    TR-NETRQ-ROUTI-034 The device shall support IETF RFC 1519 Classless InterDomain Routing (CIDR)

    TR-NETRQ-ROUTI-035 The device shall support IETF RFC 1812 Requirements for IP Version 4 Routers

    TR-NETRQ-ROUTI-036 The device shall support IETF RFC 1918 Address Allocation for Private Internets

    TR-NETRQ-ROUTI-037 The device shall support IETF RFC 3600 Internet Official Protocol Standards

    TR-NETRQ-SECUR Security

    TR-NETRQ-SECUR-001Firewall filtering: default rules to filter NetBIOS traffic (137, 138 and 138 both tcp and udp ports) that can be c

    the local and management software

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    148/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    149/221

    TR-NETRQ-OTHER-014 The device shall permit the static addition of a member in the IGMP group

    TR-NETRQ-OTHER-015

    The device shall permit the dynamic addition of members in the IGMP group via multicast tables (they bind p

    interfaces to particular multicast IP address so it is possible to know which multicast groups are joined by a S

    to a particular LAN interface)

    TR-NETRQ-OTHER-016

    The device shall permit fast leaving feature on its LAN interfaces (the IGMP user must be disconnected from

    multicast group immediately without performing the verification procedure with IGMP GSQ messages). This

    disabled.

    TR-NETRQ-OTHER-017

    The device shall perform an inmediate leaving of the IGMP user from a particular multicast group when rece

    LEAVE message but the CPE shall not send the LEAVE message to the DSLAM until it verifies that there is

    user in the same multicast group.

    TR-NETRQ-OTHER-018All traffic from particular multicast group including the IGMP messages MUST NOT be sent to any interface

    not joined to this multicast group.

    TR-NETRQ-OTHER-019IGMP management that the router test device makes,it mustn't influenced in the services deployed in the net

    Telefonica services

    TR-NETRQ-OTHER-020

    IP throughput (measured with IP packets that are from 512 up to 1492 bytes long when the modem is synchr

    with 640/16000 kbps):LAN to WAN = 512kbps

    WAN to LAN = 13Mbps

    WLAN to WAN = 512kbps

    WAN to WLAN = 13Mbps

    WLAN to LAN = 13Mbps

    LAN to WLAN = 13Mbps

    TR-NETRQ-OTHER-021 IP QoS: mapping to queue according to DSCP or DSCP + physical port

    TR-NETRQ-OTHER-022

    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)

    TR-NETRQ-OTHER-023

    IP QoS: mapping to queue according to DSCP or DSCP + physical port (if a LAN device cannot set DSCP b

    port can be used to prioritize its traffic). Traffic classification rules according to:

    Layer2: physical port, remote node or SSIDLayer3: IP address, IP mask, protocol, packet length, 6-bit DiffServ Code Point (DSCP, RFC2474)

    Layer4: TCP/UDP port range

    TR-NETRQ-OTHER-024

    IP QoS scheduling rules are Weighted Round Robin (defined amount of the packet from the queues are sen

    each cycle) or Strict priority (the highest priority is serviced. Packets from lower priority queues are not sent

    priority is not empty)

    TR-NETRQ-OTHER-025Low latency queuing: supplier should specify if the modem supports mechanism that ensures low latency for

    services or jitter sensitive services

    TR-NETRQ-OTHER-026The supplier should specify if the queue bandwidth could be expressed with percent of upstream without spe

    per second (to take into account variable upstream speed). It is important when strict priority scheduling rule

    TR-NETRQ-OTHER-027Queuing maintenance. Queuing Latency in state of congestion: the supplier has to describe queuing latency

    priority queue if the lowest priority queue is in state of congestion for all queuing directions

    TR-NETRQ-OTHER-028Queuing maintenance. Congestion Avoidance: The supplier must describe the implemented algorithms if mo

    intelligent mechanism releasing packet during overload of buffers

    TR-NETRQ-OTHER-029Queuing maintenance. Committed Output Rate: The supplier shall describe regulation mechanism that is ab

    according to contract

    TR-NETRQ-OTHER-030Queuing maintenance. Overbooking: The supplier shall describe if committed bandwidth for guaranteed serv

    upstream direction is allowed to be higher than line speed in upstream direction

    TR-NETRQ-OTHER-031Queuing maintenance. Bandwidth management: The supplier shall describe if low priority services are allowe

    unused bandwidth from higher priority queues

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    150/221

    TR-NETRQ-OTHER-032The device shall be used for Internet ADSL and Triple Play Services so it must allow concurrent deployment

    O2TV and VoIP Services with respect to requisites of individual services (low latency for VoIP, errorless tran

    TR-NETRQ-OTHER-033Different port configurations can be established so ports can be associated to certain services (with its own

    and receive certain priority considerations being isolated from the other ports.

    TR-NETRQ-OTHER-034Configuration to transport 2 data streams: Internet data (Encapsulation PPPoE as in RFC2264, IP MTU = 14

    Firewall and DNS) and Video (Encapsulation EthoA RFC2684, IP MTU = 1500B)

    TR-NETRQ-OTHER-035 Transported streams. Internet data services. Internal PPPoE client required

    TR-NETRQ-OTHER-036

    Configuration to transport 3 data streams in 3 ATM PVC Internet data (Encapsulation PPPoE as in RFC268

    1492B, NAT, Firewall and DNS PVC0 VPI/VCI 8-35 To WLAN, LAN1 & LAN2 ) and VoIP (Encapsulation Eth

    PVC1 VPI/VCI 8-37 to LAN4 ) with port Mapping Layer 2 and IPTV (Encapsulation EthoA RFC2684, PVC2 V

    LAN3 ) with port Mapping Layer 2

    TR-NETRQ-OTHER-037 Must support and be able to switch between IPoEoA using 0/101 (for ADSL2+) and PPPoE using 0/38 (for A

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    151/221

    Details and comments (English)

    Fully Compliant (FC)

    Partially Compliant (PC)

    Non Compliant (NC)

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    152/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    153/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    154/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    155/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    156/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    157/221

    Cod

    TR-IPV6

    TR-IPV6-GENRQ

    TR-IPV6-GENRQ-001

    TR-IPV6-GENRQ-002

    TR-IPV6-GENRQ-003

    TR-IPV6-GENRQ-004

    TR-IPV6-GENRQ-005

    TR-IPV6-GENRQ-006

    TR-IPV6-GENRQ-007

    TR-IPV6-GENRQ-008

    TR-IPV6-GENRQ-009

    TR-IPV6-GENRQ-010

    TR-IPV6-GENRQ-011

    TR-IPV6-GENRQ-012

    TR-IPV6-GENRQ-013

    TR-IPV6-NETPT

    TR-IPV6-NETPT-001

    TR-IPV6-NETV6

    TR-IPV6-NETV6-001

    TR-IPV6-NETV6-002

    TR-IPV6-BRDGE

    TR-IPV6-BRDGE-001

    TR-IPV6-BRDGE-002

    TR-IPV6-BRDGE-003

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    158/221

    TR-IPV6-BRDGE-004

    TR-IPV6-BRDGE-005

    TR-IPV6-CONNEC

    TR-IPV6-CONNEC-001

    TR-IPV6-CONNEC-002

    TR-IPV6-CONNEC-003

    TR-IPV6-CONNEC-004

    TR-IPV6-CONNEC-005

    TR-IPV6-CONNEC-006

    TR-IPV6-CONNEC-007

    TR-IPV6-CONNEC-008

    TR-IPV6-CONNEC-009

    TR-IPV6-CONNOD

    TR-IPV6-CONNOD-001

    TR-IPV6-CONNOD-002

    TR-IPV6-CONNOD-003

    TR-IPV6-CONNOD-004

    TR-IPV6-WANCNTR-IPV6-WANCN-001

    TR-IPV6-WANCN-002

    TR-IPV6-WANCN-003

    TR-IPV6-WANCN-004

    TR-IPV6-WANCN-005

    TR-IPV6-WANCN-006

    TR-IPV6-WANCN-007

    TR-IPV6-WANCN-008

    TR-IPV6-WANCN-009

    TR-IPV6-WANCN-010

    TR-IPV6-WANCN-011

    TR-IPV6-WANCN-012

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    159/221

    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

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    160/221

    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

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    161/221

    TR-IPV6-TUNNL-006

    TR-IPV6-TUNNL-007

    TR-IPV6-LNDDR

    TR-IPV6-LNDDR-001

    TR-IPV6-LNDDR-002

    TR-IPV6-LNDDR-003

    TR-IPV6-LNDDR-004

    TR-IPV6-LNDDR-005

    TR-IPV6-LNDDR-006

    TR-IPV6-LNDDR-007

    TR-IPV6-LNDDR-008

    TR-IPV6-LNDDR-009

    TR-IPV6-LNDDR-010

    TR-IPV6-DHCP6

    TR-IPV6-DHCP6-001

    TR-IPV6-DHCP6-002

    TR-IPV6-DHCP6-003

    TR-IPV6-DHCP6-004

    TR-IPV6-DHCP6-005

    TR-IPV6-DHCP6-006

    TR-IPV6-DHCP6-007

    TR-IPV6-DHCP6-008

    TR-IPV6-DHCP6-009

    TR-IPV6-DHCP6-010

    TR-IPV6-DHCP6-011

    TR-IPV6-DNSV6

    TR-IPV6-DNSV6-001

    TR-IPV6-DNSV6-002

    TR-IPV6-DNSV6-003

    TR-IPV6-DNSV6-004

    TR-IPV6-DNSV6-005

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    162/221

    TR-IPV6-DNSV6-006

    TR-IPV6-DNSV6-007

    TR-IPV6-DNSV6-008

    TR-IPV6-PFWD6

    TR-IPV6-PFWD6-001

    TR-IPV6-PFWD6-002

    TR-IPV6-PFWD6-003

    TR-IPV6-CNFWD

    TR-IPV6-CNFWD-001

    TR-IPV6-CNFWD-002

    TR-IPV6-CNFWD-003

    TR-IPV6-CNFWD-004

    TR-IPV6-CNFWD-005

    TR-IPV6-CNFWD-006

    TR-IPV6-CNFWD-007

    TR-IPV6-FWBSC

    TR-IPV6-FWBSC-001

    TR-IPV6-FWBSC-002

    TR-IPV6-FWBSC-003

    TR-IPV6-FWBSC-004

    TR-IPV6-FWBSC-005

    TR-IPV6-FWBSC-006

    TR-IPV6-FWBSC-007

    TR-IPV6-FWSPI

    TR-IPV6-FWSPI-001

    TR-IPV6-FWSPI-002

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    163/221

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    164/221

    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-WEBMGTR-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

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    165/221

    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)

    M

    The device shall support Client DHCPv6-PD Development of the DHCPv6 client that is responsible for the assignment ofthe prefix of the IPv6 sub network from WAN. Proposed prefix: /64, /56, /48 (RFC3633)

    M

    The device shall support SLAAC Protocol responsible for the assignment of the IPv6 direction of the WAN of the CPE. Onthe LAN side it shall be supported to publish the IPv6 prefix (RFC 4862, TR-124i2).

    M

    The device shall support DNS IPv6 To resolve names of domains of IPv6 directions (RFC3596, TR-124i2). It shall supportthe utilization of a DNS server with IPv6 address and support the resolution of domain names to an IPv6 address

    M

    The device shall support Proxy DNSv6 M

    The device shall support DHCPv6 Server To assign IPv6 directions on LAN side (RFC 3315, TR-124i2) M

    The device shall support Statefull firewall Possibility to activate or deactivate a Firewall for IPv6 addresses for the servicesthat requires it (TR-124i2)

    M

    The device shall support Remote Management Support to remote management of IPv6 parameters by TR-069 (TR-069,TR-124i2, PD-193)

    M

    The device shall support Stateful Packet Inspection Possibility to activate or deactivate the Stateful Packet Inspection ofIPv6 packets for the services that requires it

    M

    The device shall support Port Control Protocol (PCP) Dynamic Ports Control (draft-ietf-pcp-base) M

    The device shall support DynDNS Enable the user to point to a DynDNS server with an IPv6 Address M

    The device shall support 6RD Support of tunneled IPv6 (TR-124i2, RFC5569) This functionality is only required for Spainimplementation

    M

    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-012I

    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 designedappropriately and be sufficiently robust to provide this support.

    M

    NETv6 - IPv6 Networking Protocols

    GEN.NETv6.1 - The device MUST support IP Version 6, which is defined in IETF RFC 2460. M

    GEN.NETv6.2 - The device MUST support enabling and disabling of IPv6. M

    BRIDGE - Bridging

    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.

    M

    WAN.BRIDGE.4 - The device MUST be able to bridge IPv6 over Ethernet (EtherType 0x86DD). This includes bridging ofmulticast frames.

    M

    WAN.BRIDGE.5 - The device MUST be able to manage IPv6 bridging for a WAN interface, separate from IPv4 treatment. M

    Network

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    166/221

    WAN.BRIDGE.6 - The device MUST be able to manage IPv6 bridging separately for each WAN interface (if there are

    multiple WAN interfaces).M

    WAN.BRIDGE.7 - When IPv6 bridging is enabled on a WAN interface, the device MUST be configurable to act as a host on

    that WAN interface (doing SLAAC, etc.). It will not request IA_PD, since that is not a host function.M

    IPv6 CONNECT - Connection Establishment

    This module applies to IPv6 connections as well as IPv4, but only if the device has an IPv6 stack. I

    WAN.CONNECT.1 - The device MUST support an "always on" mode for connections. In this mode the device MUST NOT

    time out connection sessions (ATM, IP and PPP) and MUST automatically re-establish anysessions after disconnection,lease expiration or loss and restoration of power. M

    WAN.CONNECT.2 - Moved to WAN.CONNECT.ON-DEMAND.1 and 4 M

    WAN.CONNECT.3 - The device MUST support a manual connect option for connections. In this mode the connection tothe broadband network is initiated manually through the GUI or via TR-064/TR-069 request and, by default, terminates only

    when done so explicitly by the user, due to a power loss or when the connection is lost.

    M

    WAN.CONNECT.4 - Moved to WAN.CONNECT.ON-DEMAND.6 M

    WAN.CONNECT.5 - A manual way of disconnecting without waiting for a connection timeout MUST be provided. M

    WAN.CONNECT.6 - Moved to WAN.CONNECT.ON-DEMAND.7 M

    WAN.CONNECT.7 - The device MUST follow all standards required to perform an orderly tear down of the associated

    connections involved at the associated network levels (e.g., issue a DHCPRELEASE message when using DHCPv4, issue

    LCP Terminate-Request/Terminate-Ack and PADT packet when using PPPoE, etc.) and then restart the connections.

    M

    WAN.CONNECT.8 - The device MUST detect the loss of communications with a network identified DNS server as indicated

    by a failed query, and upon failed query, log the event.M

    IPv6 - CONNECT.ON-DEMAND - On-Demand Connection Establishment

    WAN.CONNECT.ON-DEMAND.3 - If the PPP session contains IPv4 and IPv6, then the device MUST terminate only the

    IPv4 session. This will be done using IPCP commands.M

    WAN.CONNECT.ON-DEMAND.6 - The interval after which a connection timeout occurs MUST be able to be configured. M

    WAN.CONNECT.ON-DEMAND.7 - A default timeout of 20 minutes SHOULD be used for connection timeouts or use an

    operator-specific configurationM

    WAN.CONNECT.ON-DEMAND.8 - If the device has an active IPv6 connection, and does not have addresses for DNS

    recursive name servers to be accessed over IPv6, then the "connect on demand" option MUST be disabled.M

    IPv6 - WAN ConnectionWAN.IPv6.1 - The device MUST support automated establishment of an IPv6 connection according to the flow in Annex A.2

    of TR-124 issue 2M

    WAN.IPv6.2 - The device MUST support dual stack of IPv4 and IPv6 running simultaneously, as described in Section 2 of

    RFC 4213, Transition Mechanisms for IPv6 Hosts and Routers.M

    WAN.IPv6.3 - The device MUST allow the IPv6 stack to be enabled / disabled. M

    WAN.IPv6.6 - The device MUST support specifying in its DHCPv6 prefix delegation request an indication of the length of

    prefix it requires.

    If the RG supports multiple LANs, or has PD requests from its LAN, it MUST indicate a preferred prefix length at least equal

    to the longest length that would enable the RG to assign a /64 prefix to each LAN it supports. Note that the delegated prefix

    may vary from the requested length

    M

    WAN.IPv6.7 - When sending DHCPv6 messages, the device MUST identify itself in OPTION_CLIENTID (1) (client-identifier)

    using the same client identifier as for IPv4 (see WAN.DHCPC.3 and .4).M

    WAN.IPv6.8 - The device MUST support IPv6 Node Requirements as a host node, per IETF RFC 4294. Note that RFC

    2461 reference by RFC 4294 has been obsoleted by RFC 4861.M

    WAN.IPv6.9 - The device MUST support stateless address auto-configuration (SLAAC), as a host, per IETF RFC 4862. M

    WAN.IPv6.10 - The device MUST support receipt of route information per RFC 4191. If the device only has one WAN

    connection, it does not need to place this information in its routing table, but it does need to save it (for possible sending on

    the LAN interface).

    M

    WAN.IPv6.11 - If route information is provided (RFC 4191) and the device has multiple WAN connections, it MUST place

    the route information in its routing table.M

    WAN.IPv6.12 - If the device does not have a globally-scoped address on its WAN interface after being delegated a prefix, it

    MUST create addresses for itself from the delegated prefix. It MUST have at least one address and MAY have more. There

    is currently no algorithm defined for address creation and it should be assumed that different service providers will want

    different rules for how to create the address, how many addresses to create, and, in the case of multiple addresses, how the

    different addresses are used.

    M

    WAN.IPv6.13 - The device MUST support enabling / disabling of this IPv6 WAN connection interface. M

    WAN.IPv6.17 - The connectivity parameters (obtained via RA and DHCPv6) MUST be persistent across loss of WAN

    connection (or lack of response from WAN connection).M

    WAN IPv6 18 The device MUST continue to use the connectivity parameters (obtained via RA or DHCP) and consider

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    167/221

    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 routerM

    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-

    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.

    M

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

    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 2M

    WAN.PPP.IPv6.3 - The device MUST allow any particular PPP connection to be configurable for IPv4-only, IPv6-only, or

    both.M

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

    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 stacksM

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

    M

    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).M

    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).M

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

    M

    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

    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.

    M

    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.

    M

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

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    168/221

    WAN.QoS.4 - The device MUST by default recognize and provide appropriate treatment to packets marked with

    recommended Diffserv Codepoints, whose values and behavior are defined in IETF RFC 2474, 2475, 2597, 3246, and 3260.

    Specifically, the values shown in the DSCP column of the table below MUST be supported, except the Cs0-7, which are

    optional.

    M

    WAN.QoS.5 - The device MUST be able to mark or remark the Diffserv codepoint or IEEE 802.1D Ethernet priority of traffic

    identified based on any of the classifiers supported by the device.M

    WAN.QoS.6 - The device SHOULD support sending the following frame types: untagged frames, priority-tagged frames, and

    VLAN-tagged frames in the upstream direction. This satisfies TR-101 R-01.M

    WAN.QoS.7 - The device SHOULD support setting the priority tag and VLAN ID values. This satisfies TR-101 R-02. M

    WAN.QoS.8 - The device SHOULD support receiving untagged and VLANtagged Ethernet frames in the downstream

    direction, and SHOULD be able to strip the VLAN tagging from the ones received tagged. This satisfies TR-101 R-03.M

    WAN.QoS.9 - The device MUST support one Best Effort (BE) queue, one Expedited Forwarding (EF) queue and a minimum

    of four Assured Forwarding (AF) queues.M

    WAN.QoS.10 - The device MUST duplicate the set of queues for each access session. This can be done logically or

    physically.M

    WAN.QoS.11 - The device SHOULD support the appropriate mechanism to effectively implement Diffserv per hop

    scheduling behaviors. A strict priority scheduler is preferred for EF.M

    WAN.QoS.12 - The device SHOULD support aggregate shaping of upstream traffic. M

    WAN.QoS.13 - The device SHOULD support per-class shaping of upstream traffic. M

    WAN.QoS.14 - The device MUST support the capability to fragment traffic on sessions that it originates, in order to

    constrain the impact of large packets on traffic delay.M

    WAN.QoS.15 - The packet s ize threshold before fragment ing AF and BE packets MUST be configurable. M

    QoS.TUNNEL - Quality of Service for Tunneled Traffic

    This module only applies when the device is an endpoint for a tunnel to

    the WAN. Note that this module applies to IPv6 if it is used as either thetunneled or the tunneling protocol.

    I

    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.

    M

    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.

    M

    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.

    M

    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.

    M

    DSCP DSCP

    marking marking

    Class Description (name) (decimal value)

    EF Realtime ef 46

    AF4 in-contract Premium class4 (in) af41 34

    AF4 out-of-contract Premium class4 (out) af42,af43 36, 38

    AF3 in-contract Premium class3 (in) af31 26

    AF3 out-of-contract Premium class3 (out) af32, af33 28, 30

    AF2 in-contract Premium class2 (in) af21 18

    AF2 out-of-contract Premium class2 (out) af22, af23 20, 22

    AF1 in-contract Premium class1 (in) af11 10

    AF1 out-of-contract Premium class1 (out) af12, af13 12, 14

    DE/BE Default / Best Effort be 0

    Cs0 (optional) Class Selector 0 cs0 0

    Cs1 (optional) Class Selector 1 cs1 8

    Cs2 (optional) Class Selector 2 cs2 16

    Cs3 (optional) Class Selector 3 cs3 24Cs4 (optional) Class Selector 4 cs4 32

    Cs5 (optional) Class Selector 5 cs5 40

    Cs6 (optional) Class Selector 6 cs6 48

    Cs7 (optional) Class Selector 7 cs7 56

  • 7/30/2019 BHS_ADSL2_Tech_Reqs_rev2

    169/221

    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.

    M

    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.

    M

    ADDRESSv6 - LAN IPv6 Addressing

    LAN.ADDRESSv6.1 - The device MUST create a Link Local (LL) address for its LAN interface, and perform DuplicateAddress Discovery (DAD), per RFC 4862. It MUST always use the same LL address, even after reboot or power failure.

    M

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

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

    M

    LAN.ADDRESSv6.4 - The device MAY