4.5 IF – Interface Modules

4.5.1 IF.WAN – WAN Interface Modules

4.5.1.1 IF.WAN.ADSL – ADSL and ADSL2+

ID Requirement
IF.WAN.ADSL.1 The RG MUST include an internal ADSL modem.

IF.WAN.ADSL.2

The RG MUST complete training within the following time frames:

  • 60 seconds, for single mode operation on the default inner pair assuming line auto-sensing is not activated, or if auto-sensing is activated and ADSL is present on the default pair

  • 120 seconds, for auto-mode operation or for single mode operation if line auto-sensing is activated and ADSL is not present on the default pair

  • 150 seconds, for DELT-based auto-mode operation on the default inner pair assuming that line auto-sensing is not activated.
IF.WAN.ADSL.3 The RG MUST pass the tests identified in Broadband Forum TR-067 [159], ADSL Interoperability Test Plan, and any subsequent updates or replacements to that document that exist at the time that the modem is tested, prior to its initial deployment. Within 6 months, RGs produced after changed or new test requirements have been approved MUST conform to those new requirements.
IF.WAN.ADSL.4 The RG MUST train and pass data against all ITU-T G.992.1 [27] based ATU-C deployed in North America using Broadband Forum TR-067 [159] criteria.
IF.WAN.ADSL.5 The RG MUST comply with requirements as specified in ANSI T1.413 [152], T1.413a [153] and ITU-T G.992.1 [27] for Annex A or Annex B depending upon regional requirements
IF.WAN.ADSL.6 The RG MUST support FDM mode per ANSI T1.413 and ITU-T G.992.1 [27].
IF.WAN.ADSL.7 The RG MUST comply with ITU-T G.992.3 [28] (ADSL2) and ITU-T G.992.5 [29] (ADSL2+).
IF.WAN.ADSL.8 The RG SHOULD comply with ITU-T G.992.3 [28] Annex L (RE-ADSL2).
IF.WAN.ADSL.9 The RG MUST support trellis coding.

IF.WAN.ADSL.10

The RG MUST be rate-adaptive and able to support all speeds between the minimum and maximum applicable to the associated DSL protocol in use (e.g. ADSL, ADSL2, ADSL2+, RE-ADSL, …) and in the minimum increment applicable to the associated DSL protocol in use.

For example, for ADSL, the RG MUST be able to support speeds in 32 kbps increments from 32 kbps to 8 Mbps downstream and 32 kbps to 800 kbps upstream.
IF.WAN.ADSL.11 The RG MUST support dynamic rate adaptation.
IF.WAN.ADSL.12 The RG MUST support independent upstream and downstream data rate provisioning.
IF.WAN.ADSL.13 The RG MUST support bit swapping.
IF.WAN.ADSL.14 The RG MUST support both fast and interleaved paths. This is not a requirement for dual latency support (e.g. running fast and interleaved at the same time to two different locations).
IF.WAN.ADSL.15 The RG MUST have a high-pass filter at its ADSL line input to prevent the ADSL signal from causing noise on premises wiring.
IF.WAN.ADSL.16 The RG SHOULD NOT incorporate an internal splitter (i.e. SHOULD NOT have a POTS passback port).
IF.WAN.ADSL.17 The default pair used to detect the ADSL signal MUST be the inner pair (RJ-11 pins 3 & 4).

IF.WAN.ADSL.18

The RG SHOULD provide line auto-sensing capabilities to automatically detect and select the ADSL signal on either the inner pair (pins 3 & 4) or outer pair (pins 2 & 5) of an RJ-11 jack.

If the modem reaches showtime after performing DSL auto-sensing, the default pair will be set to the newly discovered pair. This can be the inner pair or the outer pair. The new default pair is stored on the RG across power off situations. DSL auto-sensing will be activated with the new default pair.
IF.WAN.ADSL.19 If DSL line auto-sensing is implemented, the RG MUST allow disabling of the automatic detection of the ADSL signal on the inner and outer pairs and allow specification of which pair to search for the DSL signal.
IF.WAN.ADSL.20 The RG MUST conform to ANSI T1.413 [152] section 7.4.1.3 CRC requirements.
IF.WAN.ADSL.21 The RG MUST support remote testing, remote diagnostics, performance monitoring, surveillance information access and other information access as identified in ANSI T1.413 [152] and ITU-T G.997.1 [35]. At a minimum non-optional requirements from these standards MUST be supported.
IF.WAN.ADSL.22 The RG MUST provide detailed information for current connections and associated parameters including ADSL sync rate, power for both upstream and downstream directions, FEC error count, CRC error count, line attenuation, signal-to-noise margins, relative capacity of line, trained bit rate, graph of bits per tone, and loss of signal, loss of frame and loss of power counts.

4.5.1.2 IF.WAN.VDSL2 – VDSL2

ID Requirement
IF.WAN.VDSL2.1 The RG MUST include an internal VDSL2 modem.
IF.WAN.VDSL2.2 The RG MUST be able to terminate the VDSL2 signal through the inner pair of a 6-position (pins 3 and 4) or 8-position (pins 4 and 5) mini-modular jack (e.g. RJ-11, RJ-14, RJ-45).
IF.WAN.VDSL2.3 The RG MAY be able to terminate VDSL2 over other connections, such as coax.
IF.WAN.VDSL2.4 The RG MUST comply with ITU-T G.993.2 [30].

IF.WAN.VDSL2.5

The RG MUST include support for the following application reference models from ITU-T G.993.2 [30]:

  • G.993.2 clause 5.4.2, Data with POTS service

  • G.993.2 clause 5.4.1, Data service (no POTS or ISDN)
IF.WAN.VDSL2.6 The RG SHOULD support simultaneous transmission of US0 and US1 in profiles for which the capability of US0 has been indicated.
IF.WAN.VDSL2.7 The RG MUST pass the functionality test plan of Broadband Forum TR-115 [163].
IF.WAN.VDSL2.8 The RG MUST pass the VDSL2 performance and interoperability test plans of Broadband Forum TR-114 [162].
IF.WAN.VDSL2.9 [North America] The RG MUST comply with ITU-T G.993.2 [30] Annex A.
IF.WAN.VDSL2.10 [Europe] The RG MUST comply with ITU-T G.993.2 [30] Annex B.

IF.WAN.VDSL2.11

[Europe] The RG MUST include support for the following application reference model from ITU-T G.993.2 [30]:

  • G.993.2 clause 5.4.3, Data with ISDN service

4.5.1.3 IF.WAN.xDSL – xDSL General Requirements

ID Requirement
IF.WAN.xDSL.1 Removing ac power from the RG MUST NOT prevent POTS from operating.
IF.WAN.xDSL.2 A failure in the RG MUST NOT affect the private intra-premises network except for those functions provided by the RG (e.g. DHCP, DNS, L2 bridging).
IF.WAN.xDSL.3 The RG MUST NOT cause any failure in or interference with the xDSL network.
IF.WAN.xDSL.4 Failure or removal of LAN CPE connected to the DSL RG MUST NOT prevent POTS from operating.
IF.WAN.xDSL.5 The RG MUST only synchronize within the minimum and maximum line rate parameters for a line as identified by the DSLAM or RT.
IF.WAN.xDSL.6 RG packet forwarding performance and throughput MUST keep up with the DSL line rate.
4.5.1.3.1 IF.WAN.xDSL.INP – xDSL INP Values
ID Requirement
IF.WAN.xDSL.INP.1 The RG MUST support ADSL INP values of 0, ½, 1, and 2. Note that certain DSL types such as ADSL 1 (ITU-T G.992.1 [27]) do not support setting INP values in the ATU-R.
IF.WAN.xDSL.INP.2 The RG MAY support additional INP settings as specified in the appropriate ITU-T recommendations specific to each type of DSL.
4.5.1.3.2 IF.WAN.xDSL.BOND – xDSL Bonding
ID Requirement
IF.WAN.xDSL.BOND.1 If the RG supports ATM-based bonding, it MUST comply with ANSI T1.427.01 [155] and ITU-T G.998.1 [36].
IF.WAN.xDSL.BOND.2 If the RG supports Ethernet-based bonding, it MUST comply with ANSI T1.427.02 [156] and ITU-T G.998.2 [37].

IF.WAN.xDSL.BOND.3

If the RG supports DSL bonding, the RG MAY support the following parameters in the Web GUI and in vendor-specific extensions to Broadband Forum TR-064i2 [158] and TR-181:

– Group parameters (per group instance):

  • Group ID (group number assigned from ATM based xTU-C)

  • Status (valid values include: Operational, Unavailable)

  • Number of links (number of DSL links in the group)

  • RX cell loss (total number of cells lost in the receive direction for all ATM links)

– Link parameters (per link instance):

  • Group ID (to which the link is a member for all ATM links)

  • Link status (valid values include: Not in use, Standby, Available)

  • Data rate (Should return the TC-layer data rate in bits/sec (in case of ATM, the ATM cell rate at the ATM layer after removal of idle/incorrect cells)
IF.WAN.xDSL.BOND.4 The RG MUST support the bonding mechanism (as described in requirements IF.WAN.xDSL.BOND.1 and .2) associated with the underlying TPS-TC of the RG’s xDSL link.
IF.WAN.xDSL.BOND.5 When the RG has been configured to perform xDSL bonding of 2 pairs and uses a single mini-modular jack to connect to the xDSL lines, it MUST search for the signals on the inner pair (pins 3 & 4 for 6-pin, pins 4 & 5 for 8-pin) and outer pair (pins 2 & 5 for 6-pin, pins 3 & 6 for 8-pin) of the jack.
IF.WAN.xDSL.BOND.6 When the RG has been configured to perform xDSL bonding of 2 pairs and uses two separate mini-modular jacks to connect to the xDSL lines, the pair used to detect the xDSL signal on both jacks MUST be the inner pair (pins 3 & 4 for 6-pin, pins 4 & 5 for 8-pin).
IF.WAN.xDSL.BOND.7 If one of the xDSL connections drops, the remaining xDSL connection(s) MUST NOT be dropped, provided that the minimum provisioned data rate is met.
IF.WAN.xDSL.BOND.8 The RG MUST be clearly labeled indicating that it supports xDSL bonding.

IF.WAN.xDSL.BOND.9

The RG MUST allow manual configuration of the following bonding options:

  • DSL line 1 only (single xDSL link on inner pair only if a single jack, or jack 1 if presented on separate jacks)

  • DSL line 2 only (single xDSL link on outer pair only if a single jack, or jack 2 if presented on separate jacks)

  • xDSL bonding (both xDSL links) using pairs for bonding described in IF.WAN.xDSL.BOND.5 and 6).
IF.WAN.xDSL.BOND.10 The Web GUI on the RG MUST indicate when bonding is in use in terms of the connection type.
IF.WAN.xDSL.BOND.11 When bonding has been enabled on the RG, the Web GUI, Broadband Forum TR-064i2 [158] interfaces and Agent MUST indicate the state of the bonded lines even if one is not up.
4.5.1.3.3 IF.WAN.xDSL.REPORT – xDSL Reporting of Physical Layer Issues
ID Requirement

IF.WAN.xDSL.REPORT.1

The RG MUST be capable of reporting a DSL Re-Initialization Cause Code parameter to the Controller. When the RG re-initializes its DSL connection, it MUST store, in non-volatile memory, a code indicating the cause of the re-initialization. After re-initialization and after a data connection is available to the Controller, the RG MUST report to the server the cause code. At a minimum, the following cause codes MUST be supported:

  1. Autonomous re-initialization of the DSL connection

  2. Loss of local power

  3. External re-initialization, e.g. via a local reset

  4. Cause not determined
IF.WAN.xDSL.REPORT.2 The RG MUST support all requirements in ITU-T G.997.1 [35] (PLOAM).
IF.WAN.xDSL.REPORT.3 The RG MUST be capable of generating threshold-crossing alerts reported to the Controller for all mandatory performance-monitoring parameters (defined in ITU-T G.997.1 [35]) during a data collection interval for which threshold values have been assigned.
IF.WAN.xDSL.REPORT.4 The RG MUST allow the setting of data collection intervals (per ITU-T G.997.1 [35]), and reporting schedules to the Controller for performance monitoring at all monitoring points of the RG. The RG MUST NOT permit modifications to these parameters until the associated data collection is deactivated.
4.5.1.3.4 IF.WAN.xDSL.SEALING – DC Sealing Current
ID Requirement
IF.WAN.xDSL.SEALING.1 The RG MUST provide for the termination of sealing current on either, or both, DSL line pairs. A sample circuit implementation reference diagram is provided in Appendix V.
IF.WAN.xDSL.SEALING.2 The DC termination for sealing current MUST be capable of conducting at least 20mA of current.
IF.WAN.xDSL.SEALING.3 The DC termination MUST meet the requirements as specified in Annex I of ITU-T G.992.3 [28].

IF.WAN.xDSL.SEALING.4

A low-pass filter MUST be in place between the DC termination and the DSL line. The filter MUST meet the following requirements, which are based on xDSL in-line filter requirements in ANSI T1.421 [154]:

  • It MUST introduce less than 25 Ohms DC resistance tip-ring when the DC termination side is shorted.

  • It MUST have an impedance, from either conductor to ground, greater than 5 MΩ.

  • The capacitance, from either conductor to ground, MUST be less than 1 nF on the loop side

  • The attenuation MUST be at least 65 dB between 25 kHz – 12.0 MHz.

  • The input impedance, looking from network side into the LPF when terminated in the ON state on the termination side, MUST result in a bridging loss on the DSL line of not more than 0.25 dB, when measured at any frequency between 25 kHz and 12.0 MHz.

  • The DC resistance between tip and ring, when the DC termination side is open, MUST be at least 3.5 MΩ.

  • The input impedance, looking from the network side into the LPF when terminated in the ON state on the termination side, MUST result in a bridging loss in the voice band of not more than 0.5 dB, when measured at any frequency between 200 Hz and 4.0 kHz.
IF.WAN.xDSL.SEALING.5 The RG MUST support enabling and disabling of the DC termination capability through its local Web GUI, Broadband Forum TR-064i2 [158] interfaces and from the Controller.
IF.WAN.xDSL.SEALING.6 The RG SHOULD be able to detect the presence of POTS service on a line.
IF.WAN.xDSL.SEALING.7 If POTS is detected by the RG, the termination MUST NOT be applied.
4.5.1.3.5 IF.WAN.xDSL.SURGE – AC Power Surge Protection
ID Requirement

IF.WAN.xDSL.SURGE.1

The RG MUST tolerate an AC surge, as specified in EN 61000-4-5, test level 3;

  • Criterion 1: The RG MUST NOT – as a result of the surge – transmit or receive bit errors for more than 2 seconds.

  • Criterion 2: The RG MUST NOT – as a result of the surge – re-initialize.

  • Criterion 3: The RG MUST NOT – as a result of the surge – transmit a dying gasp message.

IF.WAN.xDSL.SURGE.2

The RG MUST tolerate electrical fast transients on the AC mains, as specified in EN 61000-4-4, test level 3:

  • Criterion 1: The RG MUST NOT – as a result of electrical fast transients – transmit or receive bit errors at a rate greater than 10E-7 (care should be taken to ensure that fast transients are not coupled to the DSL pair).

  • Criterion 2: The RG MUST NOT – as a result of electrical fast transients – re-initialize.

  • Criterion 3: The RG MUST NOT – as a result of electrical fast transients – transmit a dying gasp message.

4.5.1.4 IF.WAN.ETH – Ethernet (WAN)

ID Requirement
IF.WAN.ETH.1 If the RG supports an optional WAN Ethernet port, it MUST support a 100BASE-T or connecting a MDU in FTTB scenario a 100/1000BASE-T Ethernet port.
IF.WAN.ETH.2 If the RG supports a WAN Ethernet port in addition to another physical WAN link type (e.g. ADSL, VDSL2, ONU function, etc.), simultaneous use of both WAN ports MUST NOT be supported.
IF.WAN.ETH.3 The RG SHOULD be able to support 2.5GBase-T and 5GBase-T.

IF.WAN.ETH.4

An automatic WAN port selection function MAY be supported as follows:

Upon first boot-up or power cycle of the RG, the RG MUST wait until it is fully operational prior to attempting to selecting the source WAN port to use. The RG MUST first search for a DSL signal prior to selecting the Ethernet port as the WAN link. This is intended to avoid race conditions that happen because DSL typically requires a longer time to detect physical layer than Ethernet.

If both Ethernet and DSL signals are detected simultaneously, the RG MUST by default select the DSL link as the WAN source port.

Once the source of the physical signal has been detected on a valid source connector, it MUST be used persistently until power is removed from the RG or the selection is overridden via Web GUI or from a Controller. In other words, even if a connection is lost, the RG MUST NOT automatically switch to an alternate link source (e.g. DSL to Ethernet, or Ethernet to DSL). Automatic pair detection schemes are excluded from this requirement – meaning that DSL line 1/2 auto selection, and Ethernet auto-MDIX/MDX MUST still operate properly to accommodate end-user faulty wiring. For example if DSL line 1 is detected first, and the customer disconnects DSL and reconnects to line 2 instead, the RG should allow this type of switching and connect to DSL on line 2 and not by accident switch to a potentially present Ethernet signal instead.

IF.WAN.ETH.5

The RG MUST support configuring the current default WAN port being used via Web GUI or from a Controller.

This should result in the RG immediately switching to the selected port.

IF.WAN.ETH.6

Any Ethernet port used as a WAN link SHOULD be non-blocking for LAN to LAN and LAN to WAN traffic flows.

Blocking may occur in some implementations that utilize one port of a multi-port Ethernet switch for WAN use, sometimes as a result requiring LAN to LAN traffic to be forwarded and processed through the RG CPU.

4.5.1.5 IF.WAN.GPON – GPON

ID Requirement
IF.WAN.GPON.1 The RG MUST include an integrated GPON ONU interface.
IF.WAN.GPON.1a The RG MUST comply with all mandatory requirements for the ONU as specified in Broadband Forum TR-156 [166].
IF.WAN.GPON.2 The RG MUST comply with all mandatory requirements for the ONU as specified in ITU-T G.984.1 [20], G.984.2 [21] Amd 1, G.984.3 [22] and G.988 [26] and their amendments.

IF.WAN.GPON.3

The RG MUST support requirements contained in Table 3.2 of ITU-T G.984.2 [21] Amd1 (optical budget, source type, transmitter range, mean launched power min/max, extinction ratio, etc.).

Note: With FEC enabled, the class C+ budget of ITU-T G.984.2 [21] Amd 2 is also possible.
IF.WAN.GPON.4 Requirement deleted
IF.WAN.GPON.5 Requirement deleted
IF.WAN.GPON.6 Requirement deleted
IF.WAN.GPON.7 Requirement deleted
IF.WAN.GPON.8 Requirement deleted
IF.WAN.GPON.9 The RG MUST support a downstream rate of 2488.32 Mbps and an upstream rate of 1244.16 Mbps.
IF.WAN.GPON.10 Requirement deleted
IF.WAN.GPON.11 Requirement deleted
IF.WAN.GPON.12 Requirement deleted
IF.WAN.GPON.13 Requirement deleted
IF.WAN.GPON.14 Requirement deleted
IF.WAN.GPON.15 Requirement deleted
IF.WAN.GPON.16 Requirement deleted
IF.WAN.GPON.17 Requirement deleted
IF.WAN.GPON.18 Requirement deleted
IF.WAN.GPON.19 Requirement deleted
IF.WAN.GPON.20 Requirement deleted
IF.WAN.GPON.21 The RG MUST support forward error correction RS(255,239) as per [22] on the downstream link.
IF.WAN.GPON.22 The RG MUST support forward error correction RS(255,239) as per [22] on the upstream link.
IF.WAN.GPON.23 The RG MUST support static bandwidth assignment operation.
IF.WAN.GPON.24 The RG MUST support dynamic bandwidth allocation (DBA) with the SR (status reporting) mode (mode 0) of operation.
IF.WAN.GPON.25 Requirement deleted; redundant with GPON.2.
IF.WAN.GPON.26 The RG SHOULD support basic GPON interface statistics collection, and display any applicable diagnostic results in the Web GUI and from a Controller based on the architecture framework described in [165].
IF.WAN.GPON.27 The RG MUST comply with Appendix II.2 of ITU-T G.988 [26].
IF.WAN.GPON.28 If the RG supports an integrated G-PON ONU interface in addition to another physical WAN link type (e.g. ADSL, VDSL2, Ethernet, etc.), the RG SHOULD support enabling and disabling of the ONU function.

4.5.1.6 IF.WAN.XG-PON – 10G PON

ID Requirement
IF.WAN.XG-PON.1 The RG MUST include an integrated XG-PON1 ONU interface.
IF.WAN.XG-PON.2 The RG MUST comply with all mandatory requirements for the ONU as specified in ITU-T G.987.1 [23], G.987.2 [24], G.987.3 [25] and G.988 [26] as well as all their valid amendments.
IF.WAN.XG-PON.3 If the RG supports an integrated XG-PON ONU interface in addition to another physical WAN link type (e.g. ADSL, VDSL2, Ethernet, etc.), the RG SHOULD support enabling and disabling of the ONU function.
IF.WAN.XG-PON.4 The RG SHOULD support basic XG-PON status and statistics collection and display via Web GUI or from a Controller, based on the architecture framework described in Broadband Forum TR-142 [165].

4.5.1.7 IF.WAN.XGS-PON – XGS PON

ID Requirement
IF.WAN.XGS-PON.1 The RG MUST include an integrated XGS-PON ONU interface
IF.WAN.XGS-PON.2 The RG MUST comply with all mandatory requirements for the ONU as specified in ITU G.9807.1 [19], and G.988 [26] as well as all their valid amendments.
IF.WAN.XGS-PON.3 If the RG supports an integrated XGS-PON ONU interface in addition to another physical WAN link type (e.g. ADSL, VDSL2, Ethernet, etc.), the RG SHOULD support enabling and disabling of the ONU function.
IF.WAN.XGS-PON.4 The RG SHOULD support basic XGS-PON status and statistics collection and display via Web GUI or from a Controller, based on the architecture framework described in Broadband Forum TR-142 [165].

4.5.1.8 IF.WAN.MoCA – MoCA

ID Requirement
IF.WAN.MoCA.1 The RG MUST support a MoCA WAN interface compliant with the MoCA Alliance specification. Information regarding the specification is available only to members of the MoCA Alliance, further details can be obtained from the consortium at http://www.mocalliance.org.
IF.WAN.MoCA.2 The RG MUST present the MoCA WAN link on an F-connector type coaxial connector.

IF.WAN.MoCA.3

The RG MUST provide a facility to enable or disable the MoCA WAN port via the Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.

Note: The ability to remotely disable the port is intended for RGs with more than one WAN port.
IF.WAN.MoCA.4 If the RG supports a MoCA WAN interface and additional WAN physical interfaces (e.g. xDSL, Ethernet, etc.), the RG SHOULD be able to automatically detect and connect through the active interface if only one such interface is connected.
IF.WAN.MoCA.5 If multiple WAN interface types are supported, the RG MUST allow configuration via the Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller of the default WAN interface that must be used as the active interface. This is intended to prevent inadvertent auto-switching between interfaces due to user wiring issues or temporary service outages.
IF.WAN.MoCA.6 If the RG supports a MoCA WAN port and additional WAN physical interfaces (e.g. xDSL, Ethernet, etc.), simultaneous use of more than one WAN port MUST NOT be supported.
IF.WAN.MoCA.7 If the RG supports both WAN and LAN MoCA connection, it MUST NOT use the same channel for both connections.
IF.WAN.MoCA.8 The RG port MAY have limited support for only two MoCA devices on the MoCA WAN link.
IF.WAN.MoCA.9 The MoCA WAN port MUST support PER (Packet Error Rate) less than 1E-6 on the MoCA link. In this requirement, PER is a measurement of link layer error. Any additional PER caused by the dropping of packets as a result of the RG saturating the MoCA link is not included in the link layer PER specified in this requirement.

IF.WAN.MoCA.10

The MoCA WAN port MUST support the following configurable parameters:

  • Channel

  • Privacy

  • Security key password (used to generate security keys for the MoCA link).

  • Manual or auto-selection of Network Coordinator through interfaces such as the Web GUI.
IF.WAN.MoCA.11 The RG default Security key password MUST comply with the MoCA specification.
IF.WAN.MoCA.12 The RG MAY support configuring a custom Security key password to meet service provider requirements.
IF.WAN.MoCA.13 If the MoCA WAN port can operate on more than one channel the RG MUST support channel selection via the Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller. The frequency range for MoCA LAN port spans from 850MHz to 1.5GHz and each MoCA LAN channel covers 50MHz band.

IF.WAN.MoCA.14

The power control function of a MoCA WAN port MUST comply with the following requirements:

  • The adjustable range of output power MUST be at least 25db

  • The target PHY rate is the maximum rate that a MoCA link should support.

  • If the measured PHY rate is less than the target PHY rate, it MUST be within 30Mbps of the target PHY rate unless the output power is already at maximum.

  • The measured PHY rate MAY be greater than the target PHY rate

IF.WAN.MoCA.15

The MoCA WAN network MUST support the following sustained aggregate MAC throughput with PER < 1E-6 with 50 db attenuation (measured aggregate MAC throughput is based on 1500 byte packets, independent of the traffic pattern):

  • 125Mbps with 2 MoCA devices in the network

  • 117.5Mbps with 3 MoCA devices in the network

  • 110.5Mbps with 4 MoCA devices in the network

  • 103.8Mbps with 5 MoCA devices in the network

  • 98Mbps with 6 and above MoCA devices in the network.
IF.WAN.MoCA.16 The device to device ping reply time (round trip) across two MoCA devices on the same RF channel MUST be within 7ms on average and 10ms maximum.
IF.WAN.MoCA.17 The RG MUST reach optimal MoCA link layer capacity within 5 minutes after power up.
IF.WAN.MoCA.18 The RG SHOULD reach optimal MoCA link layer capacity within 3 minutes after power up.
IF.WAN.MoCA.19 The RG MUST support sending/receiving packet to/from at least 64 MAC addresses on the MoCA interface.
IF.WAN.MoCA.20 The RG MUST support basic MoCA interface statistics collection, parameter provisioning, and diagnostic results display via the Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.

4.5.1.9 IF.WAN.FAST – G.fast

ID Requirement
IF.WAN.FAST.1 The RG MUST include an internal Gfast transceiver or an SFP port hosting a Gfast transceiver.
IF.WAN.FAST.2 The RG Gfast transceiver MUST comply with the ITU-T G.9700 [17] and ITU-T G.9701 [18] specifications.
IF.WAN.FAST.3 The RG Gfast transceiver MUST be BBF.337 Gfast Certified.
4.5.1.9.1 IF.WAN.FAST.BOND – G.fast Bonding
ID Requirement
IF.WAN.FAST.BOND.1 The RG MUST comply with ANSI T1.427.02 [156] and ITU-T G.998.2 [37] to support 2 pair of lines bonding.
IF.WAN.FAST.BOND.2 If one of the Gfast connections drops, the remaining Gfast connection MUST NOT be dropped, provided that the minimum provisioned data rate is met.

4.5.1.10 IF.WAN.LTE – IF.WAN.LTE E-UTRA

ID Requirement
IF.WAN.LTE.1 The RG MUST include an Evolved Universal Terrestrial Radio Access (E-UTRA) interface. The top-level description is in 3GPP TS.36.300 [14].

4.5.1.11 IF.WAN.NR – IF.WAN.NR New Radio

ID Requirement
IF.WAN.NR.1 The RG MUST include a New Radio (NR) interface. The top-level description is in 3GPP TS 38.300 [15]

4.5.2 IF.LAN – LAN Interface Modules

4.5.2.1 IF.LAN.ETH – Ethernet (LAN)

ID Requirement
IF.LAN.ETH.1 The RG MUST support use of a straight-through (patch) cable between the Ethernet interface and a PC.
IF.LAN.ETH.2 The RG SHOULD automatically sense the transmit and receive pair on the Ethernet physical connection.
IF.LAN.ETH.3 The RG MUST have at least one 10/100BASE-T Ethernet port (RJ-45 jack) for connecting it to the home data network. A 1000BASE-T port is recommended.
IF.LAN.ETH.4 The RG MUST be able to support both 100BASE-T and 1000BASE-T with auto negotiate for speed and duplex on a port-by-port basis according to IEEE 802.3 [42].
IF.LAN.ETH.5 The Ethernet LAN interface SHOULD allow for adjusting the inter-frame and collision back off timers so that traffic marked with Ethernet priority (as defined in IEEE 802.1Q) can get statistically better treatment on broadcast LAN segments.
4.5.2.1.1 IF.LAN.ETH.SWITCH – Ethernet Switch
ID Requirement
IF.LAN.ETH.SWITCH.1 If the RG supports additional Ethernet ports for connecting multiple Ethernet devices to the home network, the RG MUST provide at least 10BASE-T/100BASE-T switched Ethernet functionality (e.g. not a hub only). Requirements for individual Ethernet port functionality MUST comply with all “MUST” requirements in the IF.LAN.ETH section.

4.5.2.2 IF.LAN.USB – USB

4.5.2.2.1 IF.LAN.USB.PC – USB (PC)
ID Requirement
IF.LAN.USB.PC.1 The RG SHOULD have a client USB port (series “B” receptacle), allowing it to be a non-powered remote device (i.e. the RG has its own power source and does not get power across the USB interface) for a host computer.
IF.LAN.USB.PC.2 If the RG has a client USB port, its USB interface MUST appear to the PC or other host device to be an Ethernet port (i.e. the PC drivers are Ethernet drivers), and not appear as a DSL modem (i.e. the RG MUST NOT require device modem drivers on LAN CPE).
IF.LAN.USB.PC.3 If the RG has a client USB port, the USB port MUST be based on the USB 1.1 (or later) technical specification.
IF.LAN.USB.PC.4 If the RG has a client USB port and USB 2.0 is supported, the USB interface MUST still work with a USB 1.1 based USB host controller based on the USB 2.0 standard.
IF.LAN.USB.PC.5 Over the USB interface, the RG SHOULD support USB drivers for commercially available operating systems for home computers that have been released over the past seven years.
IF.LAN.USB.PC.6 If the RG has only one Ethernet port and only one client USB port, the RG SHOULD be configurable through the Broadband Forum TR-064i2 [158] interfaces and from a Controller so that only the Ethernet or client USB port is to be active at any one time. In this configuration, whenever one of the ports is in use, the other is disabled. If neither is in use, both are enabled. The default configuration of the RG SHOULD be that both ports are active at the same time.
IF.LAN.USB.PC.7 If the RG has a client USB port, the USB port SHOULD support USB 3.x.

4.5.2.3 IF.LAN.VOICE – Voice

4.5.2.3.1 IF.LAN.VOICE.ATA – Voice ATA Ports
ID Requirement
IF.LAN.VOICE.ATA.1 If the RG supports VoIP ports integrated directly into the RG, it MUST comply with Broadband Forum TR-122 [164] requirements specific to RG Integrated ATA Ports.
IF.LAN.VOICE.ATA.2 If the RG supports VoIP ports integrated directly into the RG, it MUST provide one LED on the front panel of the RG per unique line instance supported to indicate status and be located between the last LAN LED indicator and the Broadband LED indicator. For behavior specifications and labeling requirements of the VoIP port LEDs, refer to Broadband Forum TR-122 [164].
IF.LAN.VOICE.ATA.3 The RG MUST support the VoiceService (TR-104 Issue 1) EndPoint:1 profile if a Voice IP service is supported.
IF.LAN.VOICE.ATA.4 The RG MUST support the VoiceService (TR-104 Issue 1) SIPEndPoint:1 profile if the device supports SIP.
IF.LAN.VOICE.ATA.5 The RG MUST support the VoiceService (TR-104 Issue 1) MGCPEndPoint:1 profile if the device supports MGCP.
IF.LAN.VOICE.ATA.6 The RG MUST support the VoiceService (TR-104 Issue 1) H323EndPoint:1 profile if the device supports H323.
IF.LAN.VOICE.ATA.7 The RG MUST support the VoiceService (TR-104 Issue 1) TAEndPoint:1 profile if the CPE has POTS.

4.5.2.4 IF.LAN.WIRELESS – Wireless

4.5.2.4.1 IF.LAN.WIRELESS.AP – Wireless: General Access Point Functions
ID Requirement
IF.LAN.WIRELESS.AP.1 The RG SHOULD have the ability to mitigate interference generated by wireless and other devices operating in the same or neighboring frequencies by using interference cancellation, management or antenna techniques.
IF.LAN.WIRELESS.AP.2 The RG MUST have the ability to scan the frequency spectrum and select the best channel upon RESET and power on.
IF.LAN.WIRELESS.AP.3 The RG MAY have the ability to perform interference detection dynamically and automatically switch to the best available channel. Interference detection techniques if implemented MUST NOT affect normal operation, performance or availability of the wireless function.
IF.LAN.WIRELESS.AP.4 The RG’s Wi-Fi (802.11) access point MUST be able to have the channel configured to a fixed value selectable through the web GUI.
IF.LAN.WIRELESS.AP.5 The RG MUST allow the user to select which LAN devices are allowed to access it through the wireless interface (i.e. MAC address filtering). By default, this restriction must be disabled.

IF.LAN.WIRELESS.AP.6

The RG Web GUI MUST provide indicators regarding the operational status of the wireless LAN and devices accessing the RG using the wireless interface. This includes but is not limited to the data elements below.

For the AP RG itself, the following are the minimum required data elements (some may be per SSID if multiple SSIDs are supported):

  • SSID(s)

  • SSID broadcast status

  • radio/SSID MAC address (if different from residential gateway)

  • IEEE 802.11b only, 802.11g only 802.b/g mixed mode selection

  • maximum power level

  • configured data rate(s)

  • supported data rate(s)

  • authentication information

  • encryption information

  • key management information

  • current signal strength

  • radio status (disabled, enabled)

  • current radio channel

  • radio channel selection (fixed, automatic, etc…)

  • ERP-PBCC status (if supported; enabled, disabled)

  • DSSS-OFDM status (if supported; enabled, disabled)

  • packets transmitted

  • errored packets transmitted

  • packets received

  • errored packets received

  • devices connected

  • VLAN identification

  • DSCP identification

For each wireless client connected to the RG AP, the following are the minimum required data elements:

  • SSID used

  • authentication used

  • encryption used

  • connection state

  • connected device rate

  • protocol used (IEEE 802.11b, 802.11g, 802.11n)
IF.LAN.WIRELESS.AP.7 The RG MUST be Wi-Fi CERTIFIED for all applicable IEEE 802.11 standards supported by the RG.
IF.LAN.WIRELESS.AP.8 Requirement moved to own subsection 4.5.2.4.1.2.
IF.LAN.WIRELESS.AP.9 Requirement moved to own subsection 4.5.2.4.1.2.
IF.LAN.WIRELESS.AP.10 The RG MUST be Wi-Fi CERTIFIED for Protected Setup as an AP type device with registrar support.
IF.LAN.WIRELESS.AP.11 The RG MUST support the Wi-Fi Protected Setup push button method and MUST include a physical pushbutton and corresponding indicator light.
IF.LAN.WIRELESS.AP.12 The RG MUST implement a Wi-Fi Protected Setup registrar user interface in the Web GUI to allow users to enter Wi-Fi device Protected Setup PIN codes.
IF.LAN.WIRELESS.AP.13 The RG MUST be Wi-Fi CERTIFIED for WMM (Wi-Fi Multimedia subset function of IEEE 802.11e [39]).
IF.LAN.WIRELESS.AP.14 The RG MAY be Wi-Fi CERTIFIED for WMM Scheduled Access.
IF.LAN.WIRELESS.AP.15 The RG MUST be Wi-Fi CERTIFIED for WMM-PS.
IF.LAN.WIRELESS.AP.16 A minimum of 32 devices (without traffic) MUST be able to simultaneously connect to the AP of the RG.
IF.LAN.WIRELESS.AP.17 Requirement moved to own subsection 4.5.2.4.1.1
IF.LAN.WIRELESS.AP.18 Requirement moved to own subsection 4.5.2.4.1.1
IF.LAN.WIRELESS.AP.19 The RG MUST support both entry of hexadecimal encryption keys for use with WEP and ASCII based pass phrases for use with WPA.
IF.LAN.WIRELESS.AP.20 Wireless MUST be enabled by default on the RG using a unique authentication/encryption key and relatively unique SSID name (e.g. “SSIDNAME1234” where the digits represent the last four digits of the RG serial number), or use an operator-specific configuration.
IF.LAN.WIRELESS.AP.21 The SSID and key MUST be printed on a label on the bottom of the RG, or use an operator-specific packaging requirement.
IF.LAN.WIRELESS.AP.22 The RG MUST allow disabling the broadcasting of the primary user SSID via the Web GUI. By default broadcasting MUST be enabled.
IF.LAN.WIRELESS.AP.23 By default, the RG MUST block association requests that do not specify a valid SSID. That is, the RG MUST block association requests that probe for “any” SSID.
IF.LAN.WIRELESS.AP.24a The RG SHOULD be able to simultaneously support at least four separate SSIDs.
IF.LAN.WIRELESS.AP.24b Each SSID SHOULD have its own unique characteristics including protocol configuration, data rate supported, authentication, encryption and broadcasting status. These SHOULD be used in combination with forwarding and firewall mechanisms in the RG to direct traffic to specific connections and destinations.
IF.LAN.WIRELESS.AP.25 The RG MUST support a mechanism based on source SSID of incoming wireless traffic of setting the Differentiated Services Code Point (DSCP) in the IP header as defined in RFC 2474 [68].
IF.LAN.WIRELESS.AP.26 The RG MUST support setting the Ethernet VLAN identifier, defined in IEEE 802.1Q [41], of incoming wireless traffic to a configurable value based on SSID.
IF.LAN.WIRELESS.AP.27 The RG MUST comply with regional regulations.
IF.LAN.WIRELESS.AP.28 The RG MUST support the adjustment of transmitted radio power level manually or automatically.
IF.LAN.WIRELESS.AP.30 The RG MUST be provisioned with only one advertised SSID by default.
4.5.2.4.1.1 IF.LAN.WIRELESS.AP.WEP – Wireless: Wired Equivalent Privacy

Note: WEP encryption is no longer secure and SHOULD not be used anymore

ID Requirement
IF.LAN.WIRELESS.AP.WEP.1 The RG MUST support WEP using a 40 bit key (WEP-40). This is sometimes referred to as 64 bit WEP.
IF.LAN.WIRELESS.AP.WEP.2 The RG MUST support WEP using a 104 bit key (WEP-104) as identified in IEEE 802.11i [39]. This is sometimes referred to as 128 bit WEP.
4.5.2.4.1.2 IF.LAN.WIRELESS.AP.WPA2 – Wireless: WPA2 Personal
ID Requirement
IF.LAN.WIRELESS.AP.WPA2.1 The RG MUST be Wi-Fi CERTIFIED for WPA2-Personal.
4.5.2.4.1.3 IF.LAN.WIRELESS.AP.WPA3 – Wireless: WPA3 Personal
ID Requirement
IF.LAN.WIRELESS.AP.WPA3.1 The RG MUST be Wi-Fi CERTIFIED for WPA3-Personal.
4.5.2.4.1.4 IF.LAN.WIRELESS.AP.WPA2-Enterprise – Wireless: Enterprise WPA2
ID Requirement
IF.LAN.WIRELESS.AP.WPA2-Enterprise.1 The RG MUST be Wi-Fi certified for WPA2-Enterprise.
IF.LAN.WIRELESS.AP.WPA2-Enterprise.2 The RG MUST be able to simultaneously support at least two separate SSIDs.
4.5.2.4.1.5 IF.LAN.WIRELESS.AP.WPA3-Enterprise – Wireless: Enterprise WPA3
ID Requirement
IF.LAN.WIRELESS.AP.WPA3-Enterprise.1 The RG MUST be Wi-Fi certified for WPA3-Enterprise.
IF.LAN.WIRELESS.AP.WPA3-Enterprise.2 The RG MUST be able to simultaneously support at least two separate SSIDs.
4.5.2.4.1.6 IF.LAN.WIRELESS.AP.ERP-Authenticator – Wireless: ERP Authenticator
ID Requirement
IF.LAN.WIRELESS.AP.ERP-Authenticator.1 The RG MUST support ERP Authenticator function RFC 6696 [132]) to get ERP keying material from ERP peer (known as the supplicant).
IF.LAN.WIRELESS.AP.ERP-Authenticator.2 The RG MUST support either a RADIUS client function (RFC 3579 [88]) or a Diameter client function RFC 4072 [98], to carry the ERP frames over the RADIUS or Diameter protocol toward a RADIUS or Diameter server.
IF.LAN.WIRELESS.AP.ERP-Authenticator.3 The RG MUST support configuration of the parameters for it to connect to the RADIUS or Diameter server via Web GUI or from a Controller.
4.5.2.4.2 IF.LAN.WIRELESS.11g – Wireless: 802.11g Access Point
ID Requirement
IF.LAN.WIRELESS.11g.1 The RG SHOULD have internal antennas.
IF.LAN.WIRELESS.11g.2 The RG MUST NOT have an antenna that limits coverage to a single direction.
IF.LAN.WIRELESS.11g.3 The RG MUST include an effective multi-antenna (at least 2) design for diversity reception.
IF.LAN.WIRELESS.11g.4 The RG SHOULD include an effective multi-antenna (at least 2) design for diversity transmit.
IF.LAN.WIRELESS.11g.5 The RG SHOULD support use of an external antenna(s) for improved performance beyond the requirements identified here.
IF.LAN.WIRELESS.11g.6 The RG SHOULD have separate antennas for transmit and receive.
IF.LAN.WIRELESS.11g.7 If an external antenna can be used with the RG, the RG SHOULD have a robust connector (e.g. be durable and not accidentally come off) for this connection.
IF.LAN.WIRELESS.11g.8 The RG’s Wi-Fi access point MUST have a maximum transmit power (EIRP) equal to or greater than 200 mW (23.01 dBm) when operating in the 802.11b mode.
IF.LAN.WIRELESS.11g.9 The RG’s Wi-Fi access point MUST have a maximum transmit power (EIRP) equal to or greater than 100 mW (20 dBm) when operating in the 802.11g mode.
IF.LAN.WIRELESS.11g.10 The RG’s Wi-Fi access point output power MUST be configurable between a minimum of 30 mW and the maximum capable from the RG.

IF.LAN.WIRELESS.11g.11

The RG Wi-Fi access point MUST meet the following minimum receiver sensitivity, maximum allowable path loss (computed as EIRP-receiver sensitivity) and delay spread tolerance specifications:

Data Rate RX Sensitivity Max. Allowable Path Loss Delay Spread Tolerance at < 1% FER
802.11b
11 Mbps -82 dBm 104 dB 65 ns
5.5 Mbps -87 dBm 107 dB 225 ns
2 Mbps -90 dBm 110 dB 400 ns
1 Mbps -93 dBm 113 dB 500 ns
802.11g
54 Mbps -71 dBm 87 dB 120 ns
48 Mbps -73 dBm 89 dB 120 ns
36 Mbps -77 dBm 93 dB 240 ns
24 Mbps -80 dBm 96 dB 240 ns
18 Mbps -82 dBm 98 dB 300 ns
12 Mbps -86 dBm 102 dB 300 ns
9 Mbps -87 dBm 103 dB 300 ns
6 Mbps -89 dBm 105 dB 300 ns
IF.LAN.WIRELESS.11g.12 The RG Wi-Fi access point MUST have an effective automatic data rate selection algorithm to allow the system to work close to its specified receiver sensitivity so as to maximize the AP coverage and throughput.
IF.LAN.WIRELESS.11g.13 The RG MUST be Wi-Fi CERTIFIED for IEEE 802.11g [39].
4.5.2.4.3 IF.LAN.WIRELESS.11a – Wireless: 802.11a Access Point
ID Requirement
IF.LAN.WIRELESS.11a.1 The RG MUST support and be Wi-Fi CERTIFIED for IEEE 802.11a [39]. Note that no radio requirements have been specified in detail for 802.11a when operating in dual-mode with 2.4GHz 802.11b/g
4.5.2.4.4 IF.LAN.WIRELESS.11h – Wireless: 802.11h Access Point
ID Requirement
IF.LAN.WIRELESS.11h.1 The RG MUST support an IEEE 802.11h [39] wireless access point. Note that no radio requirements have been specified in detail for 802.11h when operating in dual-mode with 2.4GHz 802.11b/g.
4.5.2.4.5 IF.LAN.WIRELESS.11n – Wireless: 802.11n Access Point
ID Requirement

IF.LAN.WIRELESS.11n.1

The RG MUST work in one of the following modes:

  • 2.4GHz,

  • 5GHz,

  • 2.4GHz or 5GHz selectable

  • 2.4GHz and 5GHz concurrently.

IF.LAN.WIRELESS.11n.2

The RG MUST implement MIMO technology and support MCS index 15 or above.

Note: MCS defines Modulation and Coding Schemes; MCS-15 supports two spatial streams in both directions. While using 40MHz wide channel and 400ns guard interval, it can achieve 300Mbps through 64-QAM modulation.
IF.LAN.WIRELESS.11n.3 The RG MUST support 802.11n 20/40MHz channel mode in the 5GHz frequency band.

IF.LAN.WIRELESS.11n.4

The RG SHOULD support 802.11n 20/40MHz channel mode in the 2.4GHz frequency band.

Note: WFA mandates not to configure 40MHz channel mode by default in the 2.4GHz band
IF.LAN.WIRELESS.11n.5 The RG MUST support an aggregated MAC service data unit (AMSDU) mechanism for Rx mode.
IF.LAN.WIRELESS.11n.6 The RG MUST support an aggregated MAC protocol data unit (AMPDU) mechanism for Rx and Tx mode.
IF.LAN.WIRELESS.11n.7 The RG MUST be able to adjust the size of A-MSDU and A-MPDU according to the quality of the channel.
IF.LAN.WIRELESS.11n.8 The RG MUST support a short guard interval (GI) of 400ns.
IF.LAN.WIRELESS.11n.9 The RG MUST support dynamic MIMO power saving mode.
IF.LAN.WIRELESS.11n.10 The RG MAY support greenfield mode.
4.5.2.4.6 IF.LAN.WIRELESS.11ac – Wireless: 802.11ac Access Point
ID Requirement
IF.LAN.WIRELESS.11ac.1 The RG MUST support and be Wi-Fi CERTIFIED for IEEE 802.11ac [39].
IF.LAN.WIRELESS.11ac.2 The RG MUST support 802.11ac 20/40/80MHz channel mode in the 5GHz frequency band.
IF.LAN.WIRELESS.11ac.3 The RG SHOULD support 802.11ac 160MHz.
IF.LAN.WIRELESS.11ac.4 The RG SHOULD support MU-MIMO.
4.5.2.4.7 IF.LAN.WIRELESS.11ax – Wireless: 802.11ax Access Point
ID Requirement
IF.LAN.WIRELESS.11ax.1 The RG MUST support and be Wi-Fi CERTIFIED for IEEE 802.11ax [40].
IF.LAN.WIRELESS.11ax.2 The RG MUST support 802.11ax 20/40 MHz channel mode in the 2.4 GHz frequency band.
IF.LAN.WIRELESS.11ax.3 The RG MUST support 802.11ax 20/40/80 MHz channel mode in the 5 GHz frequency band.
IF.LAN.WIRELESS.11ax.4 The RG SHOULD support 802.11ax 160MHz channel mode in the 5 GHz frequency band.
IF.LAN.WIRELESS.11ax.5 The RG SHOULD support 802.11ax 80+80 MHz channel mode in the 5 GHz frequency band.
IF.LAN.WIRELESS.11ax.6 The RG SHOULD support MU-MIMO feature of 802.11ax in the 5 GHz frequency band.

4.5.2.5 IF.LAN.HomePNA – HomePNA (Phoneline/Coax

ID Requirement
IF.LAN.HomePNA.1 The RG MUST comply with all requirements in ITU-T G.9954 - Home networking transceivers – Enhanced physical, media access, and link layer specifications

IF.LAN.HomePNA.2

The RG MUST support at least one of the following connector options for HomePNA:

  1. F-connector coaxial interface

  2. Modular RJ-11 style phone interface (optionally RJ-14 or RJ-45 connectors)
IF.LAN.HomePNA.3 The HomePNA interface type MUST be configurable and persistent across RG restarts and reboots. This parameter MUST be independent of the configuration settings that may be in use by other HomePNA devices on the local LAN.
IF.LAN.HomePNA.4 The RG MUST support enable/disable of its HomePNA interface. The default MUST be enabled, or use an operator-specific configuration. This parameter MUST be independent of the configuration settings that may be in use by other HomePNA devices on the local LAN.
IF.LAN.HomePNA.5 The RG MUST periodically collect Ethernet layer and channel performance data from HomePNA devices in the HomePNA network and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePNA.6 The RG MUST collect HomePNA network utilization information based on RG utilization and network idle time and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePNA.7 The RG MUST be able to collect performance monitoring data from at least 10 HomePNA network devices in every HomePNA interface and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePNA.8 The RG MUST enable provisioning of the specific HomePNA devices from which performance monitoring data will be collected via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.

IF.LAN.HomePNA.9

Ethernet layer performance data MUST be associated with the individual device’s information:

  • HomePNA MAC address

  • HomePNA station/node ID

  • Master/endpoint device indication

IF.LAN.HomePNA.10

Channel performance monitoring data MUST include the following:

  • Channel host source and destination MAC addresses

  • Channel HomePNA source and destination MAC addresses

  • Channel HomePNA PHY rate

  • Channel estimated SNR

  • Number of packets sent in channel. This parameter MUST be synchronized at both transmitter and receiver ends.

  • Number of pre-LARQ packets received in channel. This parameter MUST be synchronized at both transmitter and receiver ends for network packet loss calculation purposes.

IF.LAN.HomePNA.11

Channel performance monitoring data SHOULD include the following:

  • Number of post-LARQ packets received in channel. This parameter MUST be synchronized at both transmitter and receiver ends for network packet loss calculation purposes.

IF.LAN.HomePNA.12

The RG MUST be able to configure and execute full or partial network diagnostics using HomePNA CERT protocol (defined in ITU-T G.9954 [31]) and MUST collect diagnostic results from all HomePNA devices under test. The RG MUST collect the following diagnostics results between any two nodes in the network and report them via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller:

  • Baud and PHY rate

  • SNR

  • Number of received test packets

  • Line attenuation

IF.LAN.HomePNA.13

The RG MUST be able to read the following configuration parameters from HomePNA devices in the HomePNA network. The device MAY optionally enable provisioning of all parameters or a subset of the configuration parameters to be read from local HPNA devices:

  • Noise margin

  • Desired PER

  • MAC address

  • Device master/endpoint mode

  • LARQ enabling

IF.LAN.HomePNA.14

The RG MUST support at least one of the following spectral modes:

  • Spectral mode A: 4-20MHz – twisted pair/coax

  • Spectral mode B: 12-28MHz – twisted pair/coax

  • Spectral mode C: 36-52MHz – coax only

  • Spectral mode D: 4-36MHz – coax only
IF.LAN.HomePNA.15 The RG MAY support more than one HomePNA network operating in different spectral modes on the same or different physical coax cables.

IF.LAN.HomePNA.16

If xDSL and HomePNA coexist on the RG, the xDSL and HomePNA signals MUST NOT interfere with each other or affect performance in any valid spectrum band plan combinations described in the table below:

Band “A” Band “B” Band “C” Band “D”
Phone / Coax Phone / Coax Coax Coax
ADSL 1/2/2+ Yes / Yes Yes / Yes Yes Yes
VDSL2 8x No / No Yes / Yes Yes No
VDSL2 No / No No / No Yes No
IF.LAN.HomePNA.17 The RG MUST NOT support both HomePNA and xDSL simultaneously on the same physical wire if the xDSL and HomePNA spectrum bands used are not indicated as valid in the HomePNA spectrum compatibility table above.
IF.LAN.HomePNA.18 The RG MUST implement sufficient filtering and isolation so that HomePNA and xDSL interfaces will not interfere with each other’s spectrum.
IF.LAN.HomePNA.19 The RG MUST support layer 2 relative QoS on the HomePNA interface.
IF.LAN.HomePNA.20 The RG MUST be able to prioritize network traffic based on at least Diffserv code points and IEEE 802.1Q user priorities for relative QoS.
IF.LAN.HomePNA.21 The RG SHOULD support layer 2 guaranteed QoS on the HomePNA interface.
IF.LAN.HomePNA.22 The RG SHOULD be able to reserve bandwidth (media access time) on the network for services requesting QoS guarantees so as to meet QoS requirements for throughput (rate), latency and jitter.
IF.LAN.HomePNA.23 The RG SHOULD enable provisioning of QoS classification filters and traffic specifications in the HomePNA device.

IF.LAN.HomePNA.24

The RG MUST support classification of LAN directed traffic and placement into appropriate queues on the device side of the HomePNA interface based on any one or more of the following pieces of information:

  • Destination MAC address

  • Destination IP address(es) with subnet mask

  • Source IP address(es) with subnet masks

  • Ethernet type

  • IP ToS

  • Protocol type

  • Source port

  • Destination port

  • 802.1Q user priority

  • VLAN ID

4.5.2.6 IF.LAN.MoCA – MoCA (LAN)

ID Requirement
IF.LAN.MoCA.1 The RG MUST support a MoCA LAN interface compliant with the MoCA Alliance specification. Information regarding the specification is available only to members of the MoCA Alliance, further details can be obtained from the consortium at http://www.mocalliance.org.
IF.LAN.MoCA.2 The RG MUST present the MoCA LAN link on an F-connector type coaxial connector.
IF.LAN.MoCA.3 The RG MUST provide a facility to enable or disable the MoCA LAN port via the Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.MoCA.4 The MoCA LAN port MUST support PER (Packet Error Rate) less than 1E-6 on the MoCA link. Note that PER is the measurement of link layer error. Any additional PER caused by the dropping of packets as a result of the RG saturating the MoCA link is not included in the link layer PER specified in this requirement.

IF.LAN.MoCA.5

The MoCA LAN port MUST support the following configurable parameters:

  • Channel

  • Privacy

  • Security key password (used to generate security keys for the MoCA link).

  • Manual or auto-selection of Network Coordinator through interfaces such a Web GUI.
IF.LAN.MoCA.6 The RG default security key password MUST comply with the MoCA specification.
IF.LAN.MoCA.7 The RG MAY support configuring a custom security key password to meet service provider requirements.
IF.LAN.MoCA.8 If the MoCA LAN port can operate on more than one channel the RG MUST support manual channel selection in the Web GUI or from a Controller. The frequency range for MoCA LAN port spans from 850MHz to 1.5GHz and each MoCA LAN channel covers a 50MHz band.

IF.LAN.MoCA.9

The power control function of a MoCA LAN port MUST comply with the following requirements:

  • The adjustable range of output power MUST be at least 25db

  • The target PHY rate is the maximum rate that a MoCA link should support.

  • If the measured PHY rate is less than the Target PHY rate, it MUST be within 30Mbps of the target PHY rate unless the output power is already at maximum.

  • The measured PHY rate MAY be greater than the target PHY rate.

IF.LAN.MoCA.10

The MoCA LAN network MUST support the following sustained aggregate MAC throughput with PER < 1E-6 with 50db attenuation (measured aggregate MAC throughput is based on 1500 byte packets and independent of the traffic pattern):

  • 125Mbps with 2 MoCA devices in the network

  • 117.5Mbps with 3 MoCA devices in the network

  • 110.5Mbps with 4 MoCA devices in the network

  • 103.8Mbps with 5 MoCA devices in the network

  • 98Mbps with 6 and above MoCA devices in the network.
IF.LAN.MoCA.11 The device to device ping reply time (round trip) across two MoCA devices on the same RF channel MUST be within 7ms on average and 10ms maximum.
IF.LAN.MoCA.12 The RG MUST reach optimal MoCA link layer capacity within 5 minutes after power up.
IF.LAN.MoCA.13 The RG SHOULD reach optimal MoCA link layer capacity within 3 minutes after power up.
IF.LAN.MoCA.14 The RG MUST support sending/receiving packet to/from at least 64 MAC addresses on the MoCA interface.
IF.LAN.MoCA.15 The RG MUST support MoCA interface statistics collection, parameter provisioning, and diagnostic results display via the Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.MoCA.16 The RG SHOULD be able to reserve bandwidth (media access time) on the network for services requesting QoS guarantees so as to meet QoS requirements for throughput (rate), latency and jitter.

4.5.2.7 IF.LAN.HomePlugAV – HomePlug AV (LAN)

ID Requirement
IF.LAN.HomePlugAV.1 The RG MUST comply with the HomePlug AV Specification. The specification is available only to members of the HomePlug Powerline Alliance; and is accessible through http://www.homeplug.org.

IF.LAN.HomePlugAV.2

The RG MUST support one of the following connector options for HomePlug:

  1. Powerline

  2. F-connector type coaxial connector (note this is not formally an option with HomePlug alliance but is supported by vendor implementations)

  3. Both a & b hybrid configuration using coaxial or simultaneous mode by switch or relay
IF.LAN.HomePlugAV.3 If option c) is supported in IF.LAN.HomePlugAV.2, the HomePlug interface connector type MUST be configurable and persistent across RG restarts and reboots. This parameter MUST be independent of the configuration settings that may be in use by other HomePlug devices on the local LAN.
IF.LAN.HomePlugAV.4 The RG MUST periodically collect Ethernet layer and channel performance data from HomePlug devices in the HomePlug network and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.

IF.LAN.HomePlugAV.5

Ethernet layer performance data MUST be associated with the individual device’s information:

  • HomePlug device MAC address
IF.LAN.HomePlugAV.6 The RG MUST collect HomePlug network utilization information based on RG utilization and network idle time and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePlugAV.7 The RG MUST support configuring a custom security key password.
IF.LAN.HomePlugAV.8 The RG MUST be able to collect performance monitoring data from other devices on the powerline network and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePlugAV.9 The RG MUST enable provisioning of the specific HomePlug device from which performance monitoring data will be collected via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePlugAV.10 The RG MUST implement sufficient filtering and isolation so that the HomePlug and xDSL interfaces, and the HomePlug and Ethernet interfaces will not interfere with each other.
IF.LAN.HomePlugAV.11 The RG MUST support layer 2 relative QoS on the HomePlug interface.
IF.LAN.HomePlugAV.12 The RG MUST be able to prioritize network traffic based on at least Diffserv code points and IEEE 802.1Q [41] user priorities for relative QoS.
IF.LAN.HomePlugAV.13 The RG SHOULD support layer 2 guaranteed QoS on the HomePlug interface.
IF.LAN.HomePlugAV.14 The RG SHOULD be able to reserve bandwidth (media access time) on the network for services requesting QoS guarantees so as to meet QoS requirements for throughput (rate), latency and jitter.
IF.LAN.HomePlugAV.15 The RG SHOULD enable provisioning of QoS classification filters and traffic specifications in the HomePlug device.
IF.LAN.HomePlugAV.16 The RG MUST implement the simple connect functionality of section 13.2.4 of the HomeplugAV specification.

4.5.2.8 IF.LAN.HomePlugAV2 – IF.LAN.HomePlugAV2- HomePlug AV2 (LAN)

ID Requirement
IF.LAN.HomePlugAV2.1 The RG MUST comply with the HomePlug AV2 Specification. Information regarding the specification is available only to members of the HomePlug Powerline Alliance; further details can be obtained from the alliance at http://www.homeplug.org.

IF.LAN.HomePlugAV2.2

The RG MUST support one of the following connector options for HomePlug:

  1. Powerline

  2. F-connector type coaxial connector (note this is not formally an option with HomePlug alliance but is supported by vendor implementations)

  3. Both a & b hybrid configuration using coaxial or simultaneous mode by switch or relay
IF.LAN.HomePlugAV2.3 If option c) is supported in IF.LAN.HomePlugAV2.2, the HomePlug interface connector type MUST be configurable and persistent across RG restarts and reboots. This parameter MUST be independent of the configuration settings that may be in use by other HomePlug devices on the local LAN.
IF.LAN.HomePlugAV2.4 The RG MUST periodically collect Ethernet layer and channel performance data from HomePlug devices in the HomePlug network and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.

IF.LAN.HomePlugAV2.5

Ethernet layer performance data MUST be associated with the individual device’s information:

  • HomePlug device MAC address
IF.LAN.HomePlugAV2.6 The RG MUST collect HomePlug network utilization information based on RG utilization and network idle time and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePlugAV2.7 The RG MUST support configuring a custom Security Key Password.
IF.LAN.HomePlugAV2.8 The RG MUST be able to collect performance monitoring data from other devices on the powerline network and report the data via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePlugAV2.9 The RG MUST enable provisioning of the specific HomePlug device from which performance monitoring data will be collected via Web GUI, Broadband Forum TR-064i2 [158] interfaces and from a Controller.
IF.LAN.HomePlugAV2.10 The RG MUST implement sufficient filtering and isolation so that the HomePlug and xDSL interfaces, and the HomePlug and Ethernet interfaces will not interfere with each other.
IF.LAN.HomePlugAV2.11 The RG MUST support layer 2 relative QoS on the HomePlug interface.
IF.LAN.HomePlugAV2.12 The RG MUST be able to prioritize network traffic based on at least Diffserv code points and IEEE 802.1q [41] user priorities for relative QoS.
IF.LAN.HomePlugAV2.13 The RG SHOULD support layer 2 guaranteed QoS on the HomePlug interface.
IF.LAN.HomePlugAV2.14 The RG SHOULD be able to reserve bandwidth (media access time) on the network for services requesting QoS guarantees so as to meet QoS requirements for throughput (rate), latency and jitter.
IF.LAN.HomePlugAV2.15 The RG SHOULD enable provisioning of QoS classification filters and traffic specifications in the HomePlug device.
IF.LAN.HomePlugAV2.16 The RG MUST implement the simple connect functionality of section 13.2.4 of the HomeplugAV2 specification.

4.5.2.9 IF.LAN.Ghn – G.hn (LAN)

ID Requirement
IF.LAN.Ghn.1 The RG MUST comply with ITU-T Recommendations G.9960 [32], G.9961 [33] and G.9964 [34].

IF.LAN.Ghn.2

The RG must support at least one of the following connector options for G.hn:

  1. F-connector coaxial interface

  2. Modular RJ-11 style phone interface (optionally RJ-14 or RJ-45)

  3. Powerline
IF.LAN.Ghn.3 The G.hn interface type (coax, powerline or twisted pair) MUST be configurable and persistent across RG restarts and reboots. The G.hn interface parameters configuration MUST be supported through the Web GUI, UPnP (if present) and from a Controller
IF.LAN.Ghn.4 The RG MUST support the enabling/disabling of each G.hn interface. The default MUST be enabled or use an operator-specific configuration.
IF.LAN.Ghn.5 The RG MUST periodically collect G.hn Ethernet layer and channel performance data and report this data via Web GUI, UPnP (if present) and from a Controller.
IF.LAN.Ghn.6 The RG MUST be able to provide physical media performance data related to at least 10 associated G.hn network devices on every G.hn interface and report this data via Web GUI, UPnP (if present) and from a Controller.
IF.LAN.Ghn.7 The RG MUST implement sufficient filtering and isolation to the G.hn and any other wireline interfaces to prevent interference. E.g. if the RG supports both xDSL and G.hn, it MUST implement sufficient filtering and isolation between G.hn and xDSL to avoid interfering with each other’s spectrum.
IF.LAN.Ghn.8 The RG MUST be able to prioritize downstream network traffic based on IEEE 802.1Q user priorities for relative QoS by supporting at least 2 egress priority queues on every G.hn port.
IF.LAN.Ghn.9 The RG SHOULD be able to reserve bandwidth (media access time) on the G.hn network for services requesting QoS guarantees so as to meet QoS requirements for throughput (rate), latency and jitter, as described in clause 8.6.2 of ITU-T G.9961 [33].
IF.LAN.Ghn.10 The RG SHOULD enable provisioning of QoS classification filters and traffic specifications in the G.hn device, as specified in clause 8.6.2.3.1 of ITU-T G.9961 [33].
IF.LAN.Ghn.11 The RG MUST support configuring a custom network security key password to meet service provider requirements, as defined in clause 9.0 of ITU-T G.9961 [33].