HGI-RD044 HOME GATEWAY ASE REQUIREMENTS · HGI-RD044 Home Gateway Base Requirements: ... The HGI membership list as of the date of the formal review of this document is:. Advanced

HGI-RD044

HOME GATEWAY BASE

REQUIREMENTS:

RESIDENTIAL PROFILE 2

May, 2016

CONTENTS

Contents ....................................................................................................................................................................... 2

1 Important notices, IPR statement, disclaimers and copyright ............................................................................. 7

About HGI ........................................................................................................................................................ 7

This may not be the latest version of This HGI Document .............................................................................. 7

There is no warranty provided with This HGI Document ................................................................................ 7

Exclusion of Liability ........................................................................................................................................ 7

This HGI Document is not binding on HGI nor its member companies ........................................................... 7

Intellectual Property Rights ............................................................................................................................. 8

Copyright Provisions ........................................................................................................................................ 8

1.7.1 Incorporating HGI Documents in whole or part within Documents Related to Commercial Tenders ... 8

1.7.2 Copying This HGI Document in its entirety ............................................................................................. 8

HGI Membership ............................................................................................................................................. 9

2 Acronyms ............................................................................................................................................................ 10

3 Scope and Purpose of the Document ................................................................................................................. 18

Relationship with other HGI documents ....................................................................................................... 18

4 Introduction ........................................................................................................................................................ 20

5 Architecture ........................................................................................................................................................ 22

High-level end to end architecture ................................................................................................................ 22

Business Model .............................................................................................................................................. 22

Home Network Architecture ......................................................................................................................... 22

Single box architecture .................................................................................................................................. 24

2 box architecture ......................................................................................................................................... 24

The OTT Gateway .......................................................................................................................................... 24

Voice architecture ......................................................................................................................................... 26

The HG and the Cloud.................................................................................................................................... 26

HGI-RD044 Home Gateway Base Requirements: Residential Profile 2

3

Virtualising various HG components ............................................................................................................. 26

QOS Architecture ...................................................................................................................................... 27

IP Addressing ............................................................................................................................................. 28

Multi-Session Support ............................................................................................................................... 28

Security Architecture ................................................................................................................................. 29

5.13.1 Firewalling ........................................................................................................................................ 29

5.13.2 VPN Capabilities ............................................................................................................................... 29

Remote access ........................................................................................................................................... 30

Guest Access and Hotspot Service ............................................................................................................ 30

5.15.1 Guest Access ..................................................................................................................................... 30

5.15.2 Hotspot Service ................................................................................................................................ 30

Management Architecture ........................................................................................................................ 31

5.16.1 HG Management .............................................................................................................................. 31

5.16.2 SWEX Management .......................................................................................................................... 32

5.16.3 Performance Monitoring and Diagnostics & Troubleshooting ........................................................ 33

5.16.4 Local Management ........................................................................................................................... 33

Energy Efficiency ....................................................................................................................................... 33

6 HG Profiles .......................................................................................................................................................... 34

High-End Gateway ......................................................................................................................................... 34

Mid-Range Gateway ...................................................................................................................................... 34

OTT Gateway ................................................................................................................................................. 35

7 Functional requirements .................................................................................................................................... 36

WAN Side Interfaces ...................................................................................................................................... 36

ADSL2+ Interface Requirements .................................................................................................................... 36

VDSL2 Interface Requirements ...................................................................................................................... 37

G.fast Interface Requirements ...................................................................................................................... 38

WAN Interface Combinations ........................................................................................................................ 39


4

7.5.1 Multimode xDSL .................................................................................................................................... 39

7.5.2 xDSL and Ethernet WAN interfaces ...................................................................................................... 39

7.5.3 Backup WAN Interface .......................................................................................................................... 39

LAN side interfaces ........................................................................................................................................ 40

7.6.1 Wired .................................................................................................................................................... 40

7.6.2 VLAN Support ........................................................................................................................................ 41

7.6.3 Other wired interfaces .......................................................................................................................... 41

7.6.4 General Wireless LAN interfaces .......................................................................................................... 41

7.6.5 Wireless Access Point ........................................................................................................................... 41

7.6.6 Wireless Repeaters ............................................................................................................................... 43

7.6.7 SSIDs ...................................................................................................................................................... 43

7.6.8 Authentication ...................................................................................................................................... 44

General PPP Requirements ........................................................................................................................... 44

IP Addressing and Forwarding ....................................................................................................................... 45

7.8.1 IPv4 ....................................................................................................................................................... 45

7.8.2 Port Forwarding .................................................................................................................................... 46

7.8.3 IPv6 ....................................................................................................................................................... 47

7.8.4 Dual Stack Support ................................................................................................................................ 48

7.8.5 Firewall Requirements .......................................................................................................................... 48

7.8.6 ALG Support .......................................................................................................................................... 51

BRG Requirements ........................................................................................................................................ 52

BRG Tunnelling Requirements .................................................................................................................. 54

General Tunnelling Requirements ............................................................................................................ 54

IPSec Requirements .................................................................................................................................. 55

VPN Support .............................................................................................................................................. 56

Guest Access and Hotspot Service ............................................................................................................ 56

Multi-Session Support ............................................................................................................................... 57


5

......................................................................................................................................................................... 57

Service Support ......................................................................................................................................... 59

Voice Support ............................................................................................................................................ 59

Multimedia Service Support ...................................................................................................................... 60

Management and Firmware Upgrades ..................................................................................................... 61

Multi-service provider management ........................................................................................................ 62

QOS Requirements .................................................................................................................................... 63

Diagnostics Requirements ......................................................................................................................... 63

SWEX ......................................................................................................................................................... 64

8 Security Requirements ....................................................................................................................................... 65

Physical Security ............................................................................................................................................ 65

Boot Requirements ........................................................................................................................................ 65

Software Security Requirements ................................................................................................................... 65

Firmware Security Requirements .................................................................................................................. 66

Management ................................................................................................................................................. 67

Credentials and Cryptography ....................................................................................................................... 67

User Related Requirements ........................................................................................................................... 68

Wireless Security Requirements .................................................................................................................... 69

9 OTT Gateway Requirements ............................................................................................................................... 70

WAN Interfaces.............................................................................................................................................. 70

LAN Side Interfaces ........................................................................................................................................ 70

IP addressing and Forwarding ....................................................................................................................... 71

Management ................................................................................................................................................. 71

SWEX .............................................................................................................................................................. 72

Security .......................................................................................................................................................... 72

Power Supply Related .................................................................................................................................... 72

10 Miscellaneous Requirements ........................................................................................................................ 73


6

Power-related ........................................................................................................................................... 73

Memory Related........................................................................................................................................ 73

Miscellaneous ............................................................................................................................................ 73

11 Home Gateway Performance ........................................................................................................................ 75

Measuring Performance ............................................................................................................................ 75

High-End HG Performance ........................................................................................................................ 76

Mid-Range HG Performance ..................................................................................................................... 78

OTT Gateway Performance Targets .......................................................................................................... 79

12 References ..................................................................................................................................................... 80


7

1 IMPORTANT NOTICES, IPR STATEMENT, DISCLAIMERS AND COPYRIGHT

This chapter contains important information about HGI and this document (hereinafter ‘This HGI Document’).

ABOUT HGI

The Home Gateway Initiative (HGI) is a non-profit making organization which publishes guidelines, requirements

documents, white papers, vision papers, test plans and other documents concerning broadband equipment and

services which are deployed in the home.

THIS MAY NOT BE THE LATEST VERSION OF THIS HGI DOCUMENT

This HGI Document is the output of the Working Groups of the HGI and its members as of the date of publication.

Readers of This HGI Document should be aware that it can be revised, edited or have its status changed according

to the HGI working procedures.

THERE IS NO WARRANTY PROVIDED WITH THIS HGI DOCUMENT

The services, the content and the information in this HGI Document are provided on an "as is" basis. HGI, to the

fullest extent permitted by law, disclaims all warranties, whether express, implied, statutory or otherwise, including

but not limited to the implied warranties of merchantability, non-infringement of third parties rights and fitness for

a particular purpose. HGI, its affiliates and licensors make no representations or warranties about the accuracy,

completeness, security or timeliness of the content or information provided in the HGI Document. No information

obtained via the HGI Document shall create any warranty not expressly stated by HGI in these terms and conditions.

EXCLUSION OF LIABILITY

Any person holding a copyright in This HGI Document, or any portion thereof, disclaims to the fullest extent

permitted by law (a) any liability (including direct, indirect, special, or consequential damages under any legal

theory) arising from or related to the use of or reliance upon This HGI Document; and (b) any obligation to update

or correct this technical report.

THIS HGI DOCUMENT IS NOT BINDING ON HGI NOR ITS MEMBER COMPANIES

This HGI Document, though formally approved by the HGI member companies, is not binding in any way upon the

HGI members.


8

INTELLECTUAL PROPERTY RIGHTS

Patents essential or potentially essential to the implementation of features described in This HGI Document may

have been declared in conformance to the HGI IPR Policy and Statutes (available at the HGI website

www.homegateway.org).

COPYRIGHT PROVISIONS

© 2016 HGI. This HGI Document is copyrighted by HGI, and all rights are reserved. The contents of This HGI

Document are protected by the copyrights of HGI or the copyrights of third parties that are used by agreement.

Trademarks and copyrights mentioned in This HGI Document are the property of their respective owners. The

content of This HGI Document may only be reproduced, distributed, modified, framed, cached, adapted or linked

to, or made available in any form by any photographic, electronic, digital, mechanical, photostat, microfilm,

xerography or other means, or incorporated into or used in any information storage and retrieval system, electronic

or mechanical, with the prior written permission of HGI or the applicable third party copyright owner. Such

written permission is not however required under the conditions specified in Section 1.7.1 and Section 1.7.2.

1.7.1 INCORPORATING HGI DOCUMENTS IN WHOLE OR PART WITHIN DOCUMENTS RELATED TO

COMMERCIAL TENDERS

Any or all section(s) of HGI Documents may be incorporated into Commercial Tenders (RFP, RFT, RFQ, ITT, etc.) by

HGI and non-HGI members under the following conditions:

(a) The HGI Requirements numbers, where applicable, must not be changed from those within the HGI Documents.

(b) A prominent acknowledgement of the HGI must be provided within the Commercial document identifying any and all HGI Documents referenced, and giving the web address of the HGI.

(c) The Commercial Tender must identify which of its section(s) include material taken from HGI Documents and must identify each HGI Document used, and the relevant HGI Section Numbers.

(d) The Commercial Tender must refer to the copyright provisions of HGI Documents and must state that the sections taken from HGI Documents are subject to copyright by HGI and/or applicable third parties.

1.7.2 COPYING THIS HGI DOCUMENT IN ITS ENTIRETY

This HGI Document may be electronically copied, reproduced, distributed, linked to, or made available in any form

by any photographic, electronic, digital, mechanical, photostat, microfilm, xerography or other means, or

incorporated into or used in any information storage and retrieval system, electronic or mechanical, but only in its

http://www.homegateway.org/


9

original, unaltered PDF format, and with its original HGI title and file name unaltered. It may not be modified

without the advanced written permission of the HGI.

HGI MEMBERSHIP

The HGI membership list as of the date of the formal review of this document is

The HGI membership list as of the date of the formal review of this document is:. Advanced Digital Broadcast S.A,

Arcadyan, ARM, Bouygues Telecom, Broadcom, BT, Cisco, Deutsche Telekom, devolo AG, Dialog Semiconductor

B.V., Digital TV LabsDigital TV Labs, DSP Group, eflow Inc., EnOcean Alliance, Fastweb SpA, Hitachi, Huawei, Ikanos,

Imagination Technologies, Intel, KPN, Lantiq, LG, Microsemi, MStar, NEC Corporation, Netgear, NTT, Oki, Orange,

Portugal Telecom Inovação, ProSyst, Qualcomm Atheros, Rockethome, SAGEMCOM SAS, Sercomm, SoftAthome,

STMicroelectronics International, Stollmann E+V GmbH, Sumitomo Electrics Industries, Technicolor, Telecom Italia,

Telekom Austria AG, TeliaSonera, Telstra, TNO ICT, ZTE


10

2 ACRONYMS

Acronym Description

3G Third Generation (mobile)

3GPP Third Generation Partnership Project

4G Fourth Generation (mobile, LTE)

6rd IPv6 Rapid Deployment

ACL Access Control List

ACS Auto-Configuration Server

ACS Auto Channel Selection

ADSL Asymmetric Digital Subscriber Line

AELE Alternate Electrical Line Estimation

AKA Authentication and Key Agreement

ALA Active Line Access

ALG Application Layer Gateway

AN Access Network

ANP Access Network Provider

AP Access Point

API Application Programming Interface

ASP Application Service Provider

ATA Analogue Terminal Adapter

B2B Back to Back


11

BBF Broadband Forum

BRAS Broadband Remote Access Server

BRG Bridged Residential Gateway (as in the NERG architecture)

BSP Broadband Service Provider

BSS Business Support System

CHAP Challenge Authentication Protocol

CoS Class of Service

CPE Customer Premises Equipment

CPU Central Processing Unit

CWMP CPE WAN Management Protocol

DECT Digital Enhanced Cordless Telecommunications

DELT Double Ended Line Test

DHCP Dynamic Host Configuration Protocol

DLNA Digital Living Network Alliance

DMS Directed Multicast Service

DMZ Demilitarised Zone

DNS Domain Name Server

DOS Denial Of Service

DPD Dead Peer Detection

DSL Digital Subscriber Line

EAP Extensible Authentication Protocol

ED End Device

EEE Energy Efficient Ethernet


12

EIRP Equivalent Isotropically Radiated Power

EU End User

EU European Union

EUD End User Device

FM Frequency Modulation (radio bands)

FTP File Transfer Protocol

FTTB Fibre To The Building/Business

FTTCab Fibre To The Cabinet

FTTH Fibre to the Home

FTP File Transfer Protocol

FON Company that pioneered the use of a Wi-Fi based, Broadband sharing

service. Now commonly used as the generic name for the service itself

GPON Gigabit Passive Optical Network

GRE Generic Ethernet Encapsulation

GUA Globally Unique Address

GUI Graphical User Interface

GW Gateway

HAN Home Area Network (for Smart Home services)

HG Home Gateway

HGI Home Gateway Initiative

HN Home Network

HNID Home Network Infrastructure Device

HTTP HyperText Transfer Protocol


13

ICMP Internet Control Management Protocol

ID Identity

IDS Intrusion Detection System

IEEE Institute of Electrical and Electronics Engineers

IGMP Internet Group Management Protocol

IKE Internet Key Exchange

IMS IP Multimedia Subsystem

IPCP IP Control Protocol

IPOE Internet Protocol Over Ethernet

IPR Intellectual Property Rights

IPsec IP Security

ISIM IP Multimedia Services Identity Module

ISP Internet Service Provider

ITT Invitation To Tender

ITU-T International Telecommunication Union – Telecommunication

standardisation sector

JTAG Joint Test Action Group

L2TP Layer 2 Tunnelling Protocol

LAN Local Area Network

LCP Link Control Protocol

LTE Long Term Evolution (4G)

MAC Media Access Control

MGCP Multicast Group Control Protocol


14

MIMO Multiple Input Multiple Output

MLD Multicast Listener Discovery

MTU Maximum Transmission Unit

NAPT Network Address and Port Translation

NAT Network Address Translation

NERG Network Enhanced Residential Gateway

NFV Network Functions Virtualisation

NGA Next Generation Access

NTE Network Termination Equipment

NTP Network Time Protocol

OAM Operations, Administration & Maintenance

OS Operating System

OSGi Open Services Gateway Initiative

OSS Operations Support System

OTT Over The Top (Gateway)

PAP PPP Authentication Protocol

PBC Push Button Connection

PCB Printed Circuit Board

PFS Perfect Forward Security

PIN Personal Identification Number

PLC PowerLine Communications

PLT(C) PowerLine Technology (Communications)

PON Passive Optical Network


15

POTS Plain Old Telephone Service

PPP Point-to-Point Protocol

PPPOA PPP Over ATM

PPPOAOE PPP Over ATM Over Ethernet

PPPOE PPP Over Ethernet

PPTP Point to Point Tunnelling Protocol

PSD Power Spectral Density

PSTN Public Switched Telephone Network

PSU Power Supply Unit

PTM Packet Transfer Mode

PVR Personal Video Recorder

QOS Quality Of Service

RAM Random Access Memory

RFI Request For Information

RFI Radio Frequency Interference

RFP Request For Product (information)

RIP Routing Information Protocol

ROM Read Only Memory

RPC Remote Procedure Call

RTSP RealTime Streaming Protocol

SOAP Simple Object Access Protocol

SDO Standards Development Organization

SIP Session Initiation Protocol


16

SLAAC Stateless Address AutoConfiguration

SNMP Simple Network Management Protocol

SNTP Simple Network Time Protocol

SOR Statement of Requirements

SOS Save Our Showtime

SP Service Provider

SRA/FRA Seamless Rate Adaptation/Fast Rate Adaptation

SSH Secure Shell

SSID Service Set Identifier

STB Set Top Box

SWEX Software Execution Environment (now known as Open Platform 2.1)

TCP Transmission Control Protocol

TLS Transport Layer Security

U0 Upstream Zero (band)

UA User Agent

UDP Unreliable Datagram Protocol

UHD Ultra High Definition

UI User Interface

ULE Ultra Low Energy (DECT)

UPBO Upstream Power BackOff

UPnP Universal Plug&Play

URL Universal Resource Locator

USB Universal Serial Bus


17

VAS Value Added Service (equivalent to Managed Service)

VDSL Very high speed Digital Subscriber Line

vG Virtual Gateway, the network located component in the BBF NERG

Architecture

VLAN Virtual Local Area Network

VoD Video on Demand

VoIP Voice over IP

VPN Virtual Private Network

WAN Wide Area Network

WEP Wired Equivalent Privacy

WHAN Wireless Home Area Networks

WMM Wireless Multi Media

WPA Wireless Protected Access

WPS Wireless Protected Setup

XML Extensible Markup Language


18

3 SCOPE AND PURPOSE OF THE DOCUMENT

The HGI Residential Profile contains requirements for Home Gateways intended for use in the residential market,

but it is not a complete product specification, or a compliance document. Service Providers are expected to include

the Requirements in this document (either by incorporation or reference) in formal procurement processes (ITTs,

RFIs etc.), but will need to add some of their own in order to specify a product to the level of detail needed for an

actual procurement.

Three types of HG are specified, which differ with regard to both functionality and performance. These types are:

1. A mid-range (i.e. not entry-level), managed HG which is essentially an updated version of the HG specified in [1].

2. A High-End, managed HG which has higher performance, is suitable for higher speed Broadband Access connections, and can support a SWEX environment [2], which allows both Service Provider, and in principle 3rd party, applications to be run on the HG.

3. A secondary, ‘OTT service Gateway’, intended for use behind the primary HG of another SP to provide services such as energy management and E-health. The connection to the WAN1 is via the primary HG – the OTT HG has no WAN interface of its own - but apart from this connectivity, there is no dependence on functionality within the primary HG.

This document also includes requirements covering a secondary, back-up WAN interface, to support services such

as security, but the topic of a true ‘hybrid access’ Gateway, which can use two WAN connections concurrently is

addressed in [3]. Neither document contains detailed technical requirements for Hybrid Access support.

Requirements are provided to allow the HG to operate in a ‘NERG’ mode as described in BBF TR-317 [4], i.e.

extending the LAN out into the WAN to connect to a network located, ‘virtual HG’ component (vG).

RELATIONSHIP WITH OTHER HGI DOCUMENTS

This document completely deprecates Residential Profile V1 [1]. In line with the modular specification approach

now used by HGI it refers out to three other documents in their entirety

The QOS module [5]

HG Diagnostics [6]

1 The WAN interface on the primary HG can be based on either a fixed network technology such as VDSL or a mobile technology such as LTE.


19

HGI Open Platform 2.1 [2]

It also incorporates some basic multi-session requirements, e.g. specifying the minimum number of sessions that

must be supported. More advanced multi-session requirements which protect sessions of a certain type are

covered in [7].


20

4 INTRODUCTION

The initial goal of the HGI was to specify common operator requirements for mid to High-End Home Gateways

which were provided and managed by the Broadband Service provider. This resulted in the so-called Residential

Profile [1] which was the first published output of HGI. Although subsequently HGI significantly expanded its scope,

firstly into the home network domain with requirements for Home Network Interface Devices (HNIDs), then in-

home wireless technology requirements and most recently the whole Smart Home eco-system, the HG itself

remains the cornerstone of the broadband home and a key topic for HGI.

There have been significant developments in broadband access, in-home technologies and services since the

publication of the first Residential Profile, and therefore the need for a major update of the HG specification arose.

One of the most significant developments is that the processing power and memory available for HGs has increased

dramatically in the past few years, so they have moved from being rather constrained devices, where memory

footprint was a real concern, to much more powerful devices. This opens up the opportunity for them to become

flexible application platforms, even potentially hosting third party applications and services. The need to support

the Smart Home in particular has had a significant impact on the functionality, performance and interfaces that

need to be supported on the HG.

There has been a remarkable increase in the use of mobile Broadband devices, and wireless connectivity is now the

default. However many services are still consumed in the home, either because the end device is not portable

(HD/UHD TVs), or because the service is associated with the home as a location. Further, there is still a significant

difference between the capacity and cost of fixed and mobile broadband services, and so many high bandwidth -

in particular streaming - services continue to be delivered using fixed broadband. As long as this remains the case,

the HG will remain a key element, providing the connection between the operator’s managed network, and the

much less controlled, unmanaged, consumer electronics oriented, home environment. Therefore the original goal

of specifying a common HG from the point of high-level functionality and performance in order to provide guidance

to vendors, and to offer operators a wider and more competitive choice of HGs is as relevant now as ever.

The overall structure of this document is as follows. Chapter 5 covers the key architectural aspects of the system,

which focuses on the HG, but includes both the access and in-home networks in order to put things into context.

The high-level Profiles of the 3 HG types are specified in Chapter 6. Chapter 7 contains the main functional

requirements for the HG itself: WANside, LANside and internal functions. HG security is an increasingly important

topic and so these requirements are now in a separate Chapter, (8). Chapter 9 contains the requirements for a

secondary, so called OTT gateway; this would allow a second operator to provide some managed services where

they are not the BSP. For this scenario, the HG only provides connectivity to the Internet, and the OTT Gateway has

its own functionality and management. Finally, Chapter 11 gives some high-level performance requirements by

gateway type. This has been done so as to not require frequent updating; most of the performance criteria are

specified in terms of percentages of the speed of the access connection and the LAN interfaces.


21

The requirements in this document are technical, but in some cases quite high-level. Its purpose is to define the

common HG features so as to focus vendor developments, act as a common starting point from which operators

can derive their own more detailed specifications, and be an efficient way of referring out to major aspects of HG

functionality where appropriate.


22

5 ARCHITECTURE

HIGH-LEVEL END TO END ARCHITECTURE

While the focus of this specification is on the HG itself, it needs to be seen in a broader context which includes both

the Home Network and the WAN; the latter includes the Access Network and the onward connection to the Service

Platforms where appropriate.

A high-level generic architecture is shown in Figure 1 but there are a number of HG variants depending on the

business model (described in the next sub-section) which include:

The HG incorporates the Access Network termination (1-box model)

The AN termination (e.g. DSL modem or ONT) is in a separate box with a LAN technology (e.g. GBE)

connecting it to the HG (the 2-box model)

The connection to the HG and hand-off from the BRAS (or higher aggregation point) is provided by a single

business entity.

The AN provider sells L2 wholesale access to a 3rd party who may or may not be the ISP. The hand-off at the

customer premises from the ANP can be either wires-only or an Ethernet port. This includes both the

variants of the ALA model [8].

The HG functionality is all contained within a physical box located at the customer’s premises.

Some part of the HG functionality is moved into the network (the Cloud and NFV cases).

There is one primary, wired, WAN connection, but there is also support for a secondary, wireless backup interface

(e.g. LTE).

BUSINESS MODEL

The basic business model is still that the HG is not a retail market device, but specified, provided and managed by

a BSP. In the 2-box model, the modem may be provided and managed by the ANP, or the BSP.

HOME NETWORK ARCHITECTURE

A typical Home Network is as shown in Figure 1. Wireless is being used more and more; although laptops are the

only wireless attached devices shown, there is also greatly increased use of Wi-Fi-attached Smartphones and tablets

which may use Broadband as opposed to 3/4G when the device is in the home (for cost and performance reasons).

It is still the case that all 3 directions of traffic flow through the HG which can result in congestion; The Release 2


23

Residential Profile foresaw the use of higher speed access technologies such as VDSL and GPON which are indeed

now being widely deployed. Although uplink speeds have also increased significantly as a result, they are still slower

than a lot of home network technologies. Further, in some cases, the upstream service rate is less than the physical

line rate. Although wireless rates have also increased, the demands on aggregate in-home bandwidth are also

increasing and wireless still suffers from significant temporal variability. Therefore wired technologies, both ‘old-

wire’ such as PLT and phoneline, and new-wire Ethernet will continue to play a role. In the case of Ethernet, this is

typically used for local, in-room connection via a patch cord; there is still little deployment of residential structured

cabling. Many HGs provide multiple Ethernet ports, and so the use of additional external Ethernet switches is not

that common. Using in-home VLANs for QOS purposes was not supported in the original Residential Profile because

of its management complexity, and concerns that simple switches would drop tagged packets. Given the low

incidence of external in-home switches, there is no case for introducing in-home, VLAN based QOS.

Figure 1 – Typical Home Network

STB with PVR

Embedded STB – no PVR

Ethernet patch cord

Ethernet-PLT Bridge


24

The figure shows a single Access Point embedded in the HG. However additional APs are also supported, e.g. where

a wired technology, such as PLT, is used to connect to 1 (or possibly more) additional APs to increase the wireless

coverage within a home. These may or may not share SSIDs.

SINGLE BOX ARCHITECTURE

All ADSL services are now delivered using the single-box architecture, i.e. the ADSL modem is integrated into the

Home Gateway.

2 BOX ARCHITECTURE

Initial VDSL deployments reverted to the 2 box architecture, i.e. the VDSL modem was in a separate box with an

Ethernet link between the modem and the HG. This is still a valid architecture for the ultimate in performance (this

is typically engineer-installed with a new dedicated point to point cable to the modem) and does not need micro-

filters as the VDSL signals do not go over the existing, in-home telephony extension wiring. However the customer

experience benefits of a self-installable, single box have now made the single box architecture the predominant

VDSL deployment model.

The 2 box approach is however still relevant when the access link is not dedicated to a single service provider (the

so-called L2 wholesale access or ALA model). It also persists in the case of a GPON, where the shared medium

nature of the PON, and the continuing need for an engineer visit to install the fibre mean that the self-install, ‘wires-

only’ model is a much greater challenge. The NTE requirements to support the ALA model have been documented

by HGI in [8].

THE OTT GATEWAY

An OTT Gateway is intended to be used as a secondary HG where an ASP - who is not the primary ISP and does not

provide or manage the primary HG - wants to provide a variety of Smart Home Services. This concept allows the

ASP to offer these service beyond their own Broadband footprint thereby increasing their addressable market. A

secondary Use Case is where the primary ISP wants to offer these services to a user with a legacy HG which they do

not wish to change-out. Where the Smart Home service provider is the main ISP, it may be more efficient in the

long term to embed these extra capabilities in the primary HG, in this case the OTT requirements in Section 9 should

simply be added to those of the appropriate HG type. However before wide-scale deployment, an ‘integrated’

service provider may still benefit from using a separate, Smart Home box.


25

As the OTT Gateway is used in conjunction with a broadband Gateway, it has a subset of the interfaces of the

primary HG - to which it is connected by a single wired Fast Ethernet connection or Wi-Fi. It needs to be able to run

SWEX to support a variety of (downloaded) Smart Home applications, and has a number of additional embedded

Smart Home interfaces such as Zigbee and Bluetooth, as well as USB ports to allow interface dongles to be

connected.

The OTT GW is a managed device, (e.g. via TR-069), but its management traffic is just forwarded as normal IP

packets by the primary HG.

motion detector motion detector video cam sirensmoke detector Overflow detectorunfreeze detector thermometer

Internet

OperatorPlatform

WANWAN

LAN

HomeGateway

Router Smart HomeFunctions

ServiceApplication

Platform

Tablet/PC/SmartPhoneinside the home

HAN

WAN

Ethernet or WiFi

In some cases a better service could be provided if the OTT-GW knows about the nature of the broadband access.

For example, if the primary has mobile access, it would be desirable to know if it is 3G or 4G. It would also be useful

for the OTT-GW to know if the primary GW is operating on power from a battery or the AC mains. This could in

principle be done via RP8 (see [9]) although the interface has not yet been fully defined, and there is no

Requirement related to its use in this document.


26

VOICE ARCHITECTURE

Current Broadband technologies all co-exist with baseband POTS which is likely to remain the primary, fixed-line,

voice delivery mechanism for some considerable time.

However the HG needs to support the termination of a derived Voice Over IP (VOIP) service and provide a single

ATA/analogue voice port, and/or an embedded DECT base-station. This allows a second voice line to be provided.

There is no longer any requirement for the HG to support legacy voice-band services such as fax and modem on the

derived voice line.

THE HG AND THE CLOUD

There are various service scenarios in which the HG needs to co-operate with (as opposed to simply connect to) the

Cloud. These include diagnostics and Smart Home services. There is also the concept of collaborative storage in

which the HG manages the intelligent distribution of storage between the Home and the Cloud; for example in

some cases the physical location is of concern (e.g. for security and privacy reasons) and in others, storage needs

to be duplicated in both places.

Some Smart Home services require a secondary, back-up WAN interface; this is a requirement of some insurance

companies for a security service, for example. It may not be cost-effective to embed this interface in all HGs, given

the possible low take-up of such a service, and so an LTE connection via a USB dongle may be appropriate. This

means that the HG would need to support a USB interface for this purpose, and have an awareness that this was a

WAN rather than a LAN connection in order to implement the appropriate routing, and controls such as Firewalling

and QOS. There also needs to be support for automatically switching over to the backup interface (and reverting to

the main interface), and having QOS rules which can be dependent on which interface is active.

VIRTUALISING VARIOUS HG COMPONENTS

Network functions virtualization (NFV) has attracted much recent attention as it offers the prospect of a more

flexible and scalable network. However NFV is mainly about providing multiple, soft ‘devices’ on a shared,

‘centralised’, standard computing platform, which is essentially functional relocation/redistribution.

The nature of HGs is such that the amount of functional relocation that can be done is limited. Certain functions

have to remain on the customer’s premises, namely:


27

the Access network termination (xDSL, PON etc.)

the home network wired and wireless interfaces (Ethernet and Wi-Fi)

Smart Home technologies.

This requires a box, Power Supply Unit (PSU), connectors and at least one silicon chip, and so any cost or power

benefits will be relatively small. Further, ‘full-function’ HGs are going to continue to need to be specified as

technologies and services evolve e.g. to support:

new generations of Wi-Fi

higher access speeds

introduction of new HN technologies (e.g. PLC).

introduction of Smart Home technologies (e.g. Zigbee, Z-Wave)

Therefore NFV will not result in the sudden obsolescence of today’s HGs.

However there may be some direct or indirect advantages in moving some functions out of the Gateway, and/or

simplifying its behaviour. These include:

L2 forwarding rather than IP routing. This allows LAN discovery protocols to pass through the HG. The main

Use Case for this is the transparent export of DLNA content discovery to the WAN. However, this does not

mean that the HG becomes a simple bridge.

avoiding the need for dual stack IPv4/v6 in the HG by forwarding at L2 rather than L3. The HG would simply

need an IPv6 address for management

adding new service support functionality in the Cloud. This could reduce the time taken to introduce a new

HG feature, which in turn makes service prototyping more feasible.

There are specific HG requirements in this document to support these modes of operation.

QOS ARCHITECTURE

The HGI approach to QOS is a relatively simple and yet very powerful scheme based on real residential service

needs i.e. a wide and evolving mix of services. It recognizes both technology and service provider organizational

boundaries, and is very flexible. The aim is to allow Service Providers to use QOS as part of the differentiation of

their service offerings. While it is largely based on standard techniques, there are some novel features.

The main approach is to manage QOS through the HG itself. It works on the basis of a packet by packet, service

classification done by recognising a ‘service signature’. This service classification is used to assign the packet to the

appropriate queue, and may be used to set the L2 markings for a particular HN technology. It is also possible to

drop packets on the basis of the classification. Note that ‘Service’ is used here in the sense of a specific commercial

instance of a service, not a general service type (e.g. video).


28

The main features are:

identifying services on an (ingress) packet by packet basis by means of a ‘service signature’

sending each packet to the appropriate queue

providing multiple queues (per L2 interface) which support a configurable mixture of Strict Priority and

Weighted Round Robin WRR queuing disciplines

QOS management of all traffic that transits the HG, in any of the following 3 directions HN-WAN, WAN-HN

and HN-HN.

simple, static configuration, by the SP only

relative, and class-based (as opposed to absolute and parameterised)

no dependence on other network nodes

‘peaceful co-existence’ with other QOS schemes, both within the home, and other parts of the network.

The HGI QOS module [5] added support for IPv6 and ALA QOS Support to the original scheme.

HGI-RD012, QOS and Multicast Requirements for Home Network Infrastructure Devices (HNID), extends the

scheme to HNIDs. Use cases are described in which the HG and HNID QOS policies are coordinated through

configuration in order to prevent unmanaged streams from impacting managed ones.

IP ADDRESSING

Although a move to IPv6 is inevitable in the long term, there needs to be continued support for IPv4 in the HG and

HN for the foreseeable future. This document defines support for IPv6 in both the HG and the HN. This requires

that the HG provides a dual IPv4/6 stack. Requirements for IPv6 are included.

There is a wide variety of IPv6 migration techniques (see BBF TR-242, [10]) some of which have implications for the

HG. However these tend to be both operator and region specific, and so have not been included, with the exception

of dual-stack support. Operators will therefore need to add their own specific IPv6 migration requirements.

MULTI-SESSION SUPPORT

An HG is in general connected to multiple home devices, using a variety of technologies. The resulting HG traffic

can vary from almost none (e.g. just keep-alive signals and management) up a large number of flows that can load

the CPU and memory of the gateway to the point where the HG system slows down, and may ultimately crash.

Overload symptoms include a slow web-interface, pixelated IPTV, slow page load times when browsing, not

responding to user and network requests, crashing or even rebooting. The performance degradation depends on

both the amount and nature of the incoming and outgoing traffic, and the system dimensioning in terms of


29

processing power and memory. Reaching the point where the HG slows down significantly or crashes must of course

be avoided. Peer-to-peer services are one of the main causes of session proliferation. These services are used in

both the residential and business environment. Specific examples are BitTorrent, EMule, and Azareus, but there

are many others.

The number of flows through a HG will depend on the number of peer sources available for a given file, the number

of simultaneous downloads per single BitTorrent application and the number of simultaneous BitTorrent

applications for a given user.

SECURITY ARCHITECTURE

Robust HG security is important not just because of continuing attack attempts by hackers, but for two new reasons:

1. The role of the Gateway in Smart Home services, in particular security, E-health and assisted living. These

introduce new concerns with regard to both security and privacy, e.g. protecting confidential health data.

2. The use of the HG as an apps platform (e.g. via HGI Open Platform 2.x or containerisation), which can

include 3rd party apps. The core functions of the HG need to be protected against malicious and accidental

performance or functional impairments as a result of such apps.

Detailed security requirements can be found in Section 8.

5.13.1 FIREWALLING

Firewalling capability is supported in Mid-Range and High-End HGs. It would not normally be needed in the OTT HG

as there is presumed to be a Firewall in the primary HG. However the OTT might need a firewall if it were connected

to a bridged HG (e.g. a NERG BRG). It should be remembered that having 2 firewalls in series can give rise to

problems and the OTT GW operator has no control over, or visibility of, the Firewall settings in the primary HG,

which might block either incoming or outgoing communications.

5.13.2 VPN CAPABILITIES

There is support for IPSec tunnel encryption/decryption to allow corporate VPN access and support one of the

NERG architectures.


30

REMOTE ACCESS

Remote access will become increasingly important as Smart Home related services become mainstream. However

this brings new requirements with regard to privacy and security, and the need to authenticate any unsolicited

attempts to gain access to the HG or HN.

By default, no WAN IP ports must be open, apart from for remote management and helpdesk access.

WAN side SSH access to the HG needs to be supported, but not using static passwords. Ideally cryptographic keys

should be used for authentication. It must be possible to enable/disable SSH access via remote management; SSH

must be disabled by default. Once enabled SSH access must be disabled automatically after a defined period of

time, and an HG reboot.

GUEST ACCESS AND HOTSPOT SERVICE

The original Residential Profile specified a Guest Access service which allowed guests to share someone else’s

Broadband connection. This concept is still supported but has been developed further, and there are now 2 distinct

models. The full details of these services and the associated detailed requirements can be found in RD-057 [11].

This document (RD-044) just contains some high-level requirements referencing that specification, plus a small

number of additional requirements.

5.15.1 GUEST ACCESS

In this model, a guest may, at the primary user’s discretion, be allowed to share the residential broadband

connection with the primary user via a Wi-Fi connection to the HG. Guests only have access to the Internet, and

cannot see or access any of the resources on the home network. The primary user manages the service by setting

the password required to access a separate wireless partition, and only giving this to the guests they are willing to

share with. Guests are allocated a private IP address by the HG. Parental control is not applied to the Guest Access,

but there is the need to be able to identify the traffic that was accessed via this route. The guest would normally

be physically present in the home when using this service.

5.15.2 HOTSPOT SERVICE


31

The Hotspot service is similar from a functional perspective, i.e. connection via Wi-Fi to the Internet only with no

access to the home network. However the management is completely different. The Hotspot service is managed

by the Service Provider, who can enable, disable, and configure the parameters associated with the service via

remote management. If the primary user enters into a commercial arrangement with the Service Provider for their

HG to be used as a hotspot, they have no control over the configuration of the service, or which individuals are

allowed to access it. Authentication and authorization is done by the Hotspot service provider; connection attempts

are tunneled back to their network. Hotspot users can access any HG that is configured to support the service. A

commercial example of such a service is known as FON, and it may be based on the principle of reciprocity, i.e.

anyone who allows their HG to be used as a hotspot can use any other hotspot from that Service Provider.

Hotspots can operate in one of two modes:

• Low-security mode: using web portal authentication through a public SSID. This is the most

common mode of operation.

• High-security mode: using Wi-Fi Protected Access WPA2-Enterprise mode and providing mutual

authentication between the hotspot user’s device and the service provider platform with IEEE

802.11i WPA2- Enterprise mode.

In high-security mode some devices will automatically reconnect to a previously visited hotspot. The user may not

want this to happen, but the HG is not required to support any function to prevent this. Any such functionality is

assumed to be on the end device.

Both Guests and Hotspot users consume part of the access bandwidth, and if this is not constrained, it can affect

the primary user’s services. This can be addressed by QOS management, e.g. simply classifying traffic by SSID [5]

and giving the Guest/Hotspot user traffic the lowest priority and/or limiting the percentage of the bandwidth they

get under congestion. It may also necessary to cap the number of simultaneous connected hotspot users.

For regulatory reasons, it may be necessary to know whether traffic was associated with the hotspot, or the primary

user. As all hotspot traffic is tunnelled to the service provider platform, there are no additional HG requirements

needed to support this.

The Hotspot user may or may not be physically present in the home when using this service; typically they will not

be. The hotspot service is normally only offered on the 2.4 GHz band partly because of this – coverage at 5 GHz

outside the home may be quite limited. The other reason is not to interfere with premium video content delivery

which may depend on the higher capacity and lower noise available at 5 GHz.

MANAGEMENT ARCHITECTURE

5.16.1 HG MANAGEMENT


32

HG management (auto-configuration and dynamic service provisioning, software/firmware image management,

software module management, performance monitoring, and diagnostics) is based upon the CWMP protocol (TR-

069 [12]), and associated data models [TR-181 [13], TR-098 [14]]. Note that while TR-181 contains the more recent,

XML-based data-models, there is still widespread deployment of the models defined in TR-098.

CWMP provides RPC based communication between ACS and HG using HTTP, or HTTPS if security is required,

supporting SOAP messaging. The data models are described in XML documents with the root device data model

being in [13] and specific functionalities, such as telephony services being defined in additional documents (e.g.

[15]).

In some areas of management such as diagnostics, HGI has established specific requirements. These highlight

functional requirements for management but do not define specific data models. Based on HGI requirements, BBF

updated the TR-069 data models.

The key BBF specifications that are required for HG management are:

TR-069 Amendment-5 [12].

This uses a modular XML-based data model. The data model for a device such as HG is divided into root

and services.

TR-181 Issue 2 Amendment 10 (TR-181-2-10-0) [13].

The current root, Device:2, can be located at https://www.broadband-forum.org/cwmp.php#Device:2).

Quoting from [13]:

“The Device:2 data model defined in this Technical Report consists of a set of data objects covering things

like basic device information, time-of-day configuration, network interface and protocol stack configuration,

routing and bridging management, throughput statistics, and diagnostic tests. It also defines a baseline

profile that specifies a minimum level of data model support.”

The root includes object modules for functions like software module management (used to manage the SWEX

function), and diagnostics, which are required by HGI. Device:2 is required in order to support some important

features in a standardized way, in particular IPv6.

5.16.2 SWEX MANAGEMENT

A High-End HG is SWEX capable (by definition) and so needs to conform to the additional management

requirements in [2]. HGI has set out requirements for a Software Execution Environment in HGI-RD048 ([2]). A

Software Execution Environment supports lifecycle services (installation, de-installation, update, start, stop), as well

as API, remote management, module dependency management, etc. HGI-RD048 provides both technology

agnostic and technology specific (OSGi) requirements.

https://www.broadband-forum.org/cwmp.php#Device:2


33

The remote management of the Software Execution Environment uses the BBF CWMP protocol. The Software

Management Data Model is given in TR-181] [13]

5.16.3 PERFORMANCE MONITORING AND DIAGNOSTICS & TROUBLESHOOTING

The HGI diagnostics module, specified in HGI-RD016 [6], defines a set of HG functions to support a flexible

troubleshooting architecture. The way in which these are actually used to diagnose problems is left to the

Broadband Service Provider, thereby presenting an opportunity for BSP differentiation, and to allow them to

integrate the troubleshooting capability into their own processes and back-end systems. While there is a focus

on diagnosing QOS-related issues, this is just one of a number of possible problems, and all of these are covered

to some degree. The requirements needed in the HG itself to support this architecture are defined. The role of a

Cloud-based service in augmenting the embedded diagnostics capability is also recognised, but there are no details

of such a Cloud service, or how it might interact with the HG. The diagnostics module does not include any specific

requirements for embedded HNID diagnostics.

5.16.4 LOCAL MANAGEMENT

Some degree of local management should be provided via an app on a smartphone or tablet. This will be a

proprietary interface and so no details or requirements are given here apart from the need for the local

management to remain available when Broadband connectivity is down, and that the remote management is

always the master in the event of any conflict. A GUI provided by the Gateway Manufacturer is generally made

available to the user.

ENERGY EFFICIENCY

The power consumption targets for HGs are specified in the EU Code of Conduct on Energy Consumption of

Broadband Equipment ([17], currently at V5). HGI was responsible for the modular approach to defining the power

limits of HGs. Further input is needed to cover the addition of High-End HGs specified in this document which may

have slightly higher power consumption.


34

6 HG PROFILES

Three types of HG are specified, which differ with regard to both functionality and performance. These types are:

1. A mid-range, managed HG which is essentially an updated version of the HG specified in [1].

2. A High-End, managed HG which has higher performance, is suitable for higher speed Broadband Access

connections, and can support a SWEX environment [2].

3. A secondary, OTT service Gateway, intended for use behind the primary HG of another SP to provide

services such as energy management and E-health.

These are defined by means of the following profiles which (forward) reference the appropriate Sections of this, and the other HGI documents, that apply.

HIGH-END GATEWAY

A High-End Gateway is expected to meet all the requirements in this document with the exception of the following:

N° Nature of Requirement

R.1 Section 9, OTT Gateway Requirements

MID-RANGE GATEWAY

A mid-range Gateway is expected to meet all the requirements in this document with the exception of the

following:


R.2 Section 9, OTT Gateway Requirements

R.3 SWEX requirements

R.4 DECT basestation support


35

OTT GATEWAY

An OTT Gateway is only expected to meet the following requirements:


R.5 All the requirements in Section 9 of this Document

R.6 SWEX requirements

There are also some performance differences between the Mid-Range and High-End Gateways (see Section 11).


36

7 FUNCTIONAL REQUIREMENTS

WAN SIDE INTERFACES

N° Requirement

R.7

The HG MUST support at least one of the following technologies as its primary WAN

interface:

ADSL2+ ITU-T 992.5 [18]

VDSL2 ITU-T G.993.2 [19]

Ethernet 1000 BASE-T

G.fast ITU-T G.9701 [20]

R.8 The HG WAN interface MUST be easily identifiable and SHOULD be physically separated

from the LAN interface(s).

R.9 Any Ethernet WAN interface SHOULD be on a dedicated port (i.e. in addition to the LAN-

side Ethernet ports)

R.10

The HG MUST support untagged frames and 802.1Q [21] tagged frames containing

priority-tagged information (IEEE 802.1p [22]) and VLAN-ID information) on its WAN

interface.

Note: see Section 7.5.3 for Requirements on a backup WAN interface

ADSL2+ INTERFACE REQUIREMENTS

N° Requirement

R.11 The HG MUST support the optional extended framing parameters in G992.3 [23]

R.12 The HG MUST support L2 Low Power Mode as per G992.3/5

R.13 The HG MUST support Seamless Rate Adaption, in both the upstream and downstream.


37

N° Requirement

R.14 The HG MUST support PPPOA/PPPOEOA, autosensing

R.15 The HG MUST support virtual noise

R.16 The HG MUST support bit swap

R.17 The HG MUST support Annexe M (enhanced upstream) [18]

VDSL2 INTERFACE REQUIREMENTS

N° Requirement

R.18 The HG MUST support PTM

R.19 The HG MUST support 17 MHz operation using Bandplan 998ADE17

R.20 The HG SHOULD support 30MHz operation using Bandplan 998ADE30

R.21 The HG MUST support the U0 band (25kHz-138kHz)

R.22 The HG MUST support Upstream Power Backoff (UPBO)

R.23 The HG MUST support G.INP (G.998.4 [24]) for retransmission in the Downstream

R.24 The HG MUST support G.INP (G.998.4) for retransmission in the Upstream

R.25 The HG MUST support vectoring

R.26 The HG MUST support SRA in both the Downstream and Upstream

R.27 The HG MUST support PPPOE and IPOE concurrently

R.28 The HG MUST support the Alternate Electrical Length Estimation (AELE)

R.29 The HG MUST support Virtual Noise


38

N° Requirement

R.30 The HG MUST support Dying Gasp

R.31 The HG MUST support Save Our Showtime (SOS)

R.32 The HG MUST support DELT

R.33 The HG SHOULD support 2-pair physical layer bonding

R.34 The HG MUST support concurrent SRA, Physical layer retransmission and vectoring

G.FAST INTERFACE REQUIREMENTS

N° Requirement

R.35 The HG MUST comply with the mandatory requirements of ITU-T recommendation

G.9700 [25] (G.fast PSD specification).

R.36

The HG MUST comply with all the mandatory requirements of the G.fast physical layer

specification (ITU-T recommendation G.9701 [20]) including support of:

FM and RFI notching

Vectoring

SRA/FRA and retransmission in both the upstream and downstream directions

R.37 The HG G.fast transceiver MUST be able to operate with an aggregate transmit power of

8dBm.

R.38 The HG G.fast transceiver MUST support 14 bits/tone.


39

WAN INTERFACE COMBINATIONS

7.5.1 MULTIMODE XDSL

N° Requirement

R.39 The HG VDSL2 interface MUST be able to automatically detect and fallback to ADSL2+

mode.

R.40 The HG SHOULD support auto-sensing between G.fast and VDSL2. Implementing VDSL2

fallback MUST NOT adversely impact the G.fast performance.

7.5.2 XDSL AND ETHERNET WAN INTERFACES

N° Requirement

R.41 An HG with a VDSL2 interface SHOULD also provide a 1000BaseT WAN interface in order

to support the 2-box deployment model.

7.5.3 BACKUP WAN INTERFACE

N° Requirement

R.42 The HG MUST support a USB2.0 interface which can be used to connect a wireless dongle

(e.g. LTE).

R.43 The HG MUST be able to detect loss of connectivity on the primary WAN interface and

automatically switch over to the backup interface

R.44 The HG MUST be able to detect the return of connectivity on the primary WAN interface

and automatically revert to the primary interface, subject to management configuration.


40

N° Requirement

R.45 The HG MUST support a configurable timer so that reversion only occurs when the

primary WAN interface is stable.

R.46 The HG MUST be able to store and apply a separate set of QOS rules for the backup

interface

LAN SIDE INTERFACES

7.6.1 WIRED

N° Requirement

R.47 The HG MUST have 4, 100/1000 Ethernet ports

R.48 Link status and connection speed MUST be available in the GUI

R.49 The HG’s Ethernet ports MUST comply with Energy Efficient Ethernet (EEE)

R.50 The Ethernet LAN switch SHOULD support an MTU of 9000 bytes (Jumbo Frames).

R.51

The HG MUST have at least 2 USB 2.0 host interfaces. These MUST be able to be used for

any purpose including connecting a Smart Home wireless dongle and WANside LTE

connection.

R.52 The HG MUST be able to provide the maximum specified USB power on all of its USB ports

simultaneously.

R.53 The HG SHOULD have a USB3.0 interface

Note this can count as 1 of the required 2 USB interfaces.

R.54 Any USB 3.0 interface MUST be able to run at the full USB3.0 rate.

R.55 The HG SHOULD prevent the USB3.0 interface interfering with the 2.4 GHz Wi-Fi band.


41

7.6.2 VLAN SUPPORT

N° Requirement

R.56 The HG MUST be able to add a configured VLAN tag to upstream packets on the basis of

port and/or MAC source address

R.57 The HG MUST be able to remove a VLAN tag from downstream packets on the basis of

MAC destination address

R.58 The HG SHOULD support untagged, priority tagged and VLAN tagged frames on its LAN

interfaces. Note however that VLAN-based QOS is not used

7.6.3 OTHER WIRED INTERFACES

There is no requirement to incorporate PLC technology within the HG itself.

7.6.4 GENERAL WIRELESS LAN INTERFACES

N° Requirement

R.59 The HG MUST provide 2 Wi-Fi interfaces which can operate concurrently at 2.4 GHz and

5 GHz

R.60 Each Wi-Fi interface MUST support Automatic Channel Selection (ACS) as specified in

RD0045v2 [26]

R.61 The HG SHOULD have internal antennas

R.62 The 2.4GHz Wi-Fi MUST support IEEE 802.11b/g/n using 2x2 MIMO and 2 spatial streams.

R.63 The 5GHz Wi-Fi MUST support IEEE 802.11a/n/ac using 3x3 MIMO and 3 spatial streams

7.6.5 WIRELESS ACCESS POINT


42

N° Requirement

R.64 The HG MUST have a Wi-Fi interface that operates as an access point.

R.65 The access point interface MUST be IEEE 802.11b/g/n/ac Wi-Fi certified.

R.66 The access point interface MUST be configurable with regards to mode (e.g. “b” and/or

“g”) of operation.

R.67 The access point interface MUST be configurable with regards to frequency of operation

for 802.11n (2.4 GHz or 5 GHz).

R.68 The HG MUST be able to radiate at least 50 mW E.I.R.P. from the antenna measured at

the minimum antenna gain.

R.69 The HG MUST not exceed the maximum limits for radiated power according to the

regional regulations.

R.70 The HG SHOULD be Wi-Fi Alliance WPA2 Personal certified [27].

R.71 The Wi-Fi interface MUST be WMM certified, on the basis of Wi-Fi Alliance requirements

for interoperability [28]

R.72 The Wi-Fi interface MUST be compliant with WMM Power Save.

R.73 The HG Wi-Fi interfaces MUST be fully compliant with Wi-Fi Alliance WPS - Wi-Fi

Protected Setup - with PIN and with push button.

R.74 The HG MUST only have 1 push button for the WPS-PBC pairing, even when multiple

SSIDs are available.


43

7.6.6 WIRELESS REPEATERS

N° Requirement

R.75 The HG MUST be able to operate as an AP and a client/repeater

R.76 The HG MUST be able to be configured as both an AP and a client/repeater, but

instantaneous simultaneous operation in the 2 modes is not required.

R.77 The HG MUST be able to work in conjunction with other wireless repeaters, i.e. external

APs which can use the same SSID as one of the embedded AP SSIDs.

R.78 The HG MUST support IEEE1905.1 [29] for automatic repeater configuration

7.6.7 SSIDS

N° Requirement

R.79 The HG MUST be able to simultaneously support at least three separate SSIDs.

R.80 The HG’s Wi-Fi access point MUST be able to be configured without the wireless interface

being active.

R.81

By default, the HG MUST be provisioned with one advertised SSID per frequency band

(2.4 GHz / 5 GHz band). (Note that the advertised SSIDs might be the same at 2.4 and 5

GHz band, but the BSSID must be different).


44

N° Requirement

R.82

The HG MUST support the per SSID configuration (through both the local GUI and CWMP)

of the following beacon elements:

SSID name

SSID advertisement (broadcast or hide)

SSID encryption type

WPS

WMM parameters

Number of allowed associations2

R.83 The HG MUST support at least 32 simultaneous wireless clients of which at least 8 MUST

be able to be WPA2 encrypted, across all SSIDs in use.

7.6.8 AUTHENTICATION

N° Requirement

R.84 The HG MUST support PAP (RFC 1334 [30]) and CHAP (RFC 1994 [31]) authentication

protocols, and IPCP (RFC 1332 [32]).

GENERAL PPP REQUIREMENTS

N° Requirement

R.85 The HG MUST support PPPoA (RFC 2364 [33]) and PPPoE (RFC 2684 [34]).

2 Access control to the SSID can be achieved by setting the number of associations to zero


45

N° Requirement

R.86 The HG MUST support a simultaneous PPP session for broadband and an IPoE session

in routed mode.

R.87 The HG MUST be able to send LCP echo requests at a configurable interval (e.g. every

10 seconds).

R.88 If a configurable number of successive keep-alive responses are not received, the PPPoE

session MUST be considered to have dropped

R.89 The HG MUST immediately attempt to re-establish a dropped PPP session, without the

Layer 1 dropping.

R.90 If the PPP session fails to re-establish, the HG MUST implement an exponential back-off

algorithm before trying again.

IP ADDRESSING AND FORWARDING

7.8.1 IPV4

N° Requirement

R.91 The HG MUST be able to request an IPv4 address from a network side DHCP server

R.92 The HG MUST provide an IPv4 DHCP server to allocate addresses to devices on the LAN.

R.93 The HG MUST support ICMP

R.94 The HG MUST support LAN connected hosts using static IP addresses, and/or addresses

allocated dynamically from the LAN DHCP Server

R.95 Once an IP address has been allocated by the DHCP server to a MAC address, the HG SHOULD reserve this IP address for future use by that MAC address.

R.96 The LAN and WANside DHCP address pools MUST be separate


46

N° Requirement

R.97 The HG MUST support NAT (RFC1631) between its WANside public IP address and LAN

side private addresses.

R.98 The NAT implementation MUST be symmetric

R.99 The HG MUST support Restricted Cone NAT.

R.100 The HG MUST support NATP (RFC2766)

R.101 The HG MUST be able to forward upstream packets on the basis of IPv4 destination

address.

R.102 The HG MUST be able to forward downstream packets on the basis of IPv4 destination

address.

R.103 The HG MUST be able to provide any LAN connected devices with a domain name URL so

the HG can be reached by a LAN host by URL.

7.8.2 PORT FORWARDING

N° Requirement

R.104 The HG MUST support the port forwarding destination host being identified by MAC, IP address or host name.

R.105

Port forwarding MUST support the following protocol types

TCP

UDP

All


47

7.8.3 IPV6

No Requirement

R.106 The HG MUST be able to forward upstream packets on the basis of IPv6 destination

address.

R.107 The HG MUST be able to forward downstream packets on the basis of IPv6 destination

address.

R.108 The HG MUST support enabling/disabling IPv6 operation via remote management.

R.109 The HG MUST comply with all requirements in RFC 7084 ‘Basic Requirements for IPv6

Customer Edge Routers’ [35]

R.110 The HG MUST support receiving an IPv6 Link Local address for its WAN port

R.111 The HG MUST support automatic allocation of a link-local address for its WAN port.

R.112 The HG SHOULD support a /127 public GUA.

R.113

The HG MUST support DHCPv6 Prefix Delegation and behave as a requesting router as

per RFC3633. Prefix-delegation MUST support the provision of any valid IPv6 subnet and

mask length.

R.114

The HG MUST support IPv6 SLAAC ([36] RFC4862) based on the Neighbour Discovery

option M and O information fields from the WAN network. This MUST be configurable

via remote management but MUST be disabled by default.

R.115 The HG MUST support at least 2 IPv6 LANs

R.116

The HG MUST advertise the LAN subnet allocated to locally attached clients.

Note: each client will either self-assign their own global IPv6 address (if they support

SLAAC), or request an IPv6 address from the HG via DHCPv6.

R.117 The HG MUST act as an IPv6 host in accordance with RFC4862 [36] and RFC3315 [37],

for the purpose of stateless and stateful address assignment.

R.118 The HG MUST support DHCPv6 client mode in accordance with RFC3315


48

No Requirement

R.119 The HG MUST support Neighbour Discovery as per RFC4861 [38]

R.120

The HG MUST support unicast IPv6 destination address routing, based upon an IPv6

routing table populated with directly connected and static IPv6 routes, between each of

its LAN and WAN ports

R.121 The HG MUST support ICMP for IPv6, in accordance with RFC4443 [39] and RFC4884 [42].

R.122 The HG MUST NOT forward any user traffic between its IPv6 LAN and WAN interfaces,

until successful completion of WAN IPv6 address acquisition.

R.123 The HG MUST disable any active IPv6 traffic forwarding gracefully in the event that the

IPv6 WAN connectivity is lost.

R.124 The HG MUST support configurable LAN-side and WAN-side IPv6 address filters.

7.8.4 DUAL STACK SUPPORT

N° Requirement

R.125 The HG MUST support simultaneous, dual-stack operation of both IPv4 and IPv6.

R.126 The HG MUST be able to simultaneously route IPv4 and IPv6 packets

R.127 In dual-stack mode, the HG MUST operate without any significant loss of performance

compared to its IPv4 only performance.

7.8.5 FIREWALL REQUIREMENTS


49

No Requirement

R.128 The HG MUST support multiple firewall configurations e.g. Default, Block All, Disabled

R.129 The Default configuration MUST block all unsolicited inbound packets, whilst allowing all

outbound requests to be made.

R.130 The default configuration MUST be able to block outbound SMTP traffic (to reduce the

risk of botnet traffic).

R.131 Block All MUST not allow any traffic to pass from the customer’s LAN to the Internet or

from the internet to the customer’s LAN.

R.132 Block All MUST NOT prevent LAN traffic passing between LAN hosts (wired or wireless).

R.133 Block All MUST not prevent access to SP specified managed services e.g. TV, Voice.

R.134 Disabled MUST remove all firewall protection from the HG, allowing all inbound and outbound traffic to pass unhindered.

R.135

The customer MUST be able to view a list of services, and then select which can be accessed from the Internet. These include:

HTTP

HTTPS

FTP

Telnet

DNS

PoP3

H323

R.136 It MUST be possible to view / modify each firewall rule set both locally and remotely

R.137 The HG SHOULD support ordering of the firewall rules in order to allow multiple rules to be actioned in a preferred order

R.138 The HG firewall MUST support IP Source address filtering on a single IPv4 and IPv6 address.


50

R.139 The HG firewall MUST support IP Source address filtering on ranges of

IPv4 and IPv6 addresses.

R.140 IP source address filtering MUST support defining the source port.

R.141 The HG firewall MUST support IP destination address filtering on a single IPv4 and IPv6

address.

R.142 The HG firewall MUST support IP destination address filtering on ranges of

IPv4 and IPv6 addresses.

R.143 IP address filtering MUST support defining the destination port.

R.144

The HG firewall MUST support IP Protocol filtering on at least the following:

UDP

TCP

ICMP

There MUST be the option to specify the customer port numbering.

R.145 The HG MUST support a DMZ.

R.146 The DMZ MUST support a NAT based segment and public IPv4 addresses

R.147 The DMZ MUST support port to NAT’d IP:port address mapping for IPv4 addresses.

R.148 The firewall MUST allow both public and NAT’ed addresses to be on the same internal or

DMZ interface, and MUST be able to route between the two

R.149 The HG MUST support intrusion detection where the intrusion is attempting to

compromise the HG itself.

R.150 The intrusion detection system MUST NOT compromise the normal operation or

performance of the HG.

R.151 The HG MUST support Denial of Service protection

R.152 The HG SHOULD log all intrusion and Denial of Service attempts. This log MUST be

available via the ACS and local GUI


51

R.153 The HG MUST support Firewall rule partitioning per VLAN/IP subnet.

R.154 The firewall MUST support stealthing of ports not configured for passthrough or port

forwarding, with no responses to (for example) ACK/SYN requests.

R.155 The firewall MUST provide an audit trail including login (successful and failed) and DOS

attacks

R.156 The firewall SHOULD provide an audit trail of blocked traffic.

R.157 The firewall logs MUST include the source and destination addresses

R.158 The firewall MUST be separately configurable for each public WAN IPv4 address,

including both dynamic and static addresses.

R.159 The HG MUST support enabling/disabling the firewall per public IPv4 and per IPv6 address

7.8.6 ALG SUPPORT

N° Requirement

R.160 The HG MUST support ALGs including NAT traversal

R.161 It MUST be possible to enable and disable ALGs via the GUI and via the ACS

R.162 A given ALG MUST take precedence over an associated Firewall Rule

R.163

The HG MUST support the following VOIP ALGs:

SIP

H323

MGCP

RTSP


52

N° Requirement

R.164

The HG MUST support the following encryption related ALGs:

GRE

IPSec

L2TP

PPTP

R.165

The HG MUST support the following additional ALGs:

DHCPv4

DNS

FTP

BRG REQUIREMENTS

The following requirements only apply when part of the HG functionality is located in the wide area network. The

main difference is the forwarding model, which is done at L2 rather than L3. However the HG will still be IP aware

for the purposes management and QOS etc.

These requirements are based on a subset of the so-called NERG requirements which can be found in TR-317 [4].

There are 2 connectivity models: the so-called flat model in which the connection to the network located part of

the HG is done via an extension to the local LAN using GRE tunnelling, and the overlay model which uses an IP

tunnel.

One design goal of the NERG architecture is that the LAN must be able to continue to operate when WAN

connectivity is lost. This requires the HG to provide a backup DHCP server and DNS and to monitor the connectivity

to its network located component

N° Requirement

R.166 The BRG MUST support a full learning MAC bridge

R.167 The BRG MUST be able to be configured in operate in BRG or routed mode. In routed

mode all the HG requirements apply.


53

N° Requirement

R.168 The BRG MUST support a local DHCP server

R.169 The BRG MUST snoop all DHCP requests

R.170 The BRG MUST support a keepalive to the vG

R.171 When the BRG has no connectivity to the vG it MUST respond to LANside DHCP requests

and offer an IPv4 address from a configured local pool

R.172 The BRG MUST support a short address lease time (~30 seconds)

R.173 The BRG MUST reject any requests, including renew, to its DHCP server if it has vG

connectivity (via DHCPNAK)

R.174 The BRG MUST support a backup DNS (B-DNS)

R.175 When the DNS in the vG becomes unavailable, the BRG MUST activate the B-DNS in the

BRG.

R.176 When the DNS in the vG becomes available, the BRG MUST de-activate the B-DNS

R.177 When the B-DNS Server NF is deactivated, the B-DNS Server NF MUST NOT respond to

any DNS requests

R.178 The BRG MUST be able to add a configured VLAN tag to upstream packets on the basis

of port and/or MAC source address

R.179 The BRG MUST be able to remove a VLAN tag from downstream packets on the basis of

MAC destination address

R.180 The BRG MUST support the full set of QOS classifiers in [5], including those at L3.

R.181 The BRG MUST support IGMP snooping of upstream packets

R.182 The BRG MUST support downstream multicast packet replication

R.183 The BRG MUST remove the VLAN tag from downstream multicast packets


54

N° Requirement

R.184 The BRG MUST be able to forward a packet to one of multiple WAN interfaces on the

basis of IP destination address

BRG TUNNELLING REQUIREMENTS

.

N° Requirement

R.185 The BRG MUST be able to obtain the IP configuration of its network interface, through

DHCP, prior to tunnel establishment

R.186 The BRG MUST be able to establish a L2 tunnel over IP to its vG using information received

via DHCP.

R.187 The BRG MUST support Ethernet over GRE

GENERAL TUNNELLING REQUIREMENTS

N° Requirement

R.188 The HG MUST be able to set up and operate at least 1 IPSec tunnel

R.189 The HG MUST support Ethernet over GRE


55

IPSEC REQUIREMENTS

N° Requirement

R.190 The HG MUST support classless IP routing.

R.191 The HG MUST have configurable IPSec SA lifetimes.

R.192 The HG MUST complete IKE Authentication using pre-shared keys.

R.193 The HG MUST be able to store IPSec Pre-Shared Key lengths of up to 25 characters.

R.194 The HG MUST support MD5 hashing.

R.195 The HG MUST support SHA-1 hashing.

R.196 The HG MUST support AES encryption.

R.197 The HG MUST support Diffie-Hellman groups 1,2,5.

R.198 The HG MUST have a configurable IKE SA timer.

R.199 The HG MUST support IKE Main mode operation.

R.200 The HG MUST support IKE Quick mode operation.

R.201 The HG SHOULD support IKE Aggressive mode operation

R.202

The HG MUST support IPSec/ESP in the following manner:

AH and AH/ESP.

Null encryption.

MD5 hashing.

SHA-1 hashing.

R.203 The HG MUST support Dead Peer Detection (DPD) and a configurable retry mechanism


56

N° Requirement

R.204 The HG SHOULD support PFS (Perfect Forward Security)

R.205 The HG IKE/IPSec implementation MUST support NAT traversal.

VPN SUPPORT

N° Requirement

R.206 The HG MUST support VPN Server LANside

R.207 The HG MUST support (ALG) Passthrough for a minimum of 64 simultaneous VPN

sessions

R.208 The HG MUST support multiple simultaneous VPN and IPSec passthrough sessions

(incoming and outgoing) by tunnelling multiple clients using PPTP and L2TP protocols

GUEST ACCESS AND HOTSPOT SERVICE

N° Requirement

R.209 The HG MUST support Requirements Guest1– Guest 4 in RD057

R.210 It MUST be possible to identify which traffic went via the Guest partition.

R.211 The HG MUST support Requirements HOTSPOT1-HOTSPOT12 in RD057

R.212 The HG MUST support EAP passthrough

R.213 EAP passthrough MUST be remotely manageable


57

MULTI-SESSION SUPPORT

N° Requirement

R.214 The HG MUST be able to support a minimum of 2000 concurrent transport layer sessions,

any or all of which may be active

R.215 The HG MUST keep a count, J, of the total number of currently active transport layer

sessions.

R.216 Any packet to a new unique 5-tuple MUST be counted as 1 new transport layer session.

R.217 When the HG releases a transport layer session, all the state in the HG associated with

that session MUST be removed and J MUST be decremented by 1.

R.218 J MUST be able to be read by the ACS as well as by the GUI of the HG.

R.219 When no traffic has been sent in a given TCP session during a period of 24 hours, the HG

MUST release that session.

R.220 When no traffic has been sent in a UDP session during a period P, the HG MUST release

that session.

R.221 P MUST be configurable by the ACS, in the range of 10 minutes to 120 minutes.

R.222 The HG MUST be able to limit the maximum number of transport layer sessions to M.

R.223 M MUST be configurable and readable by the ACS only.

R.224 M MUST be pre-configured by the HG vendor to the maximum number of transport layer

sessions that the HG supports under normal operating conditions.

R.225 M MUST be configurable from 10 up to the maximum number of transport layer sessions

that the HG is able to support.


58


59

SERVICE SUPPORT

N° Requirement

R.226 The HG MUST provide a dynamic DNS client,

R.227 The HG MUST support an NTP (RFC 1305 [44]) or SNTP (RFC 2030 [45]) client.

R.228 Information related to the NTP or SNTP server MUST be advertised to the home devices

using DHCP option 42.

VOICE SUPPORT

N° Requirement

R.229

The HG MUST support a SIP or IMS UA (Sip User Agent) compliant to 3GPP TS 24.229 IP

multimedia call control protocol based on Session Initiation Protocol (SIP) and Session

Description Protocol (SDP); Stage 3 (Release 8) and to RFC3261 “SIP: Session Initiation

Protocol”.

R.230

The SIP or IMS protocol stack MUST support at least one of the following authentication

methods3:

IMS AKA with ISIM authentication (compliant to 3GPP TS 33.203).

HTTP Digest Authentication (compliant to RFC 2617).

R.231 The HG MUST be able to connect SIP IMS UAs to embedded telephony Interfaces.

3 The following IMS parameters are needed by the HG:

a private user identity;

one or more public user identity;

a home network domain name to address the SIP REGISTER request to. (TISPAN ES 283 003)


60

N° Requirement

R.232 One SIP IMS UA MUST be able to be mapped to any or all the embedded telephony

Interfaces (i.e. from 1 up to the complete set)

R.233 The HG MUST support mapping each individual telephony Interface to any or all of the

SIP IMS UAs (i.e. from 1 up to the complete set)

R.234

In order to allow non-SIP or non-IMS devices to access the IMS core, the HG MUST

support a B2BUA (Back to Back User Agent) terminating one SIP session (generated by a

SIP non-IMS UA) and translating it into a SIP or IMS session to the SIP or IMS core and

vice versa.

R.235 The B2BUA MUST be able to access identity and authentication data to support

registration and authentication procedure.

R.236

The HG SHOULD support an ATA to present an analogue voice port for a VOIP service.

Note: there is no requirement to support non-voice baseband services such as fax and

modem

R.237 The HG SHOULD support an embedded DECT basestation.

MULTIMEDIA SERVICE SUPPORT

N° Requirement

R.238 The HG MUST support IGMP v3 (RFC 3376 [41]).

R.239 IGMP snooping MUST be used in order to only forward multicast traffic to the LAN

Ethernet interfaces with hosts that requested a specific multicast flow.

R.240 IGMP proxy functionality MUST be supported for multicast requests from the LAN hosts

NAPT submitted or directly routed (public LAN).


61

N° Requirement

R.241

The HG MUST route multicast packets between all LAN interfaces, wired and wireless to

ensure correct operation of devices and services which use multicast addresses, e.g.

UPnP

R.242 IGMP for local services MUST NOT be proxied.

R.243 The HG MUST support DMS as per IEEE802.11v in order to convert a multicast stream to

unicast to a specific Wi-Fi attached device.

R.244 The HG must support upstream prioritisation of IGMP messages over the WAN

MANAGEMENT AND FIRMWARE UPGRADES

N° Requirement

R.245 The HG MUST be able to be managed by an ACS via TR-069 (CWMP).

R.246 The HG MUST only allow remote management of its core functions by a single, identified,

authenticated ACS.

R.247 The HG MUST support a local management interface (GUI) that remains available even

when the connection to its remote ACS is not available

R.248 Remote ACS management MUST take precedence over the local management interface

in the event of a conflict.

R.249 The HG Firmware MUST be upgradeable during its lifecycle via the remote management

system.

R.250 The HG MUST support TR-181 Issue 2 Amendment 10 or later.

R.251 The HG MUST support all MANDATORY aspects of TR-069 Amendment 5 or later.


62

N° Requirement

R.252 The HG MUST support TR-069 Amendment 5 (or later) Annex F (to support management

of TR-069 capable devices on the LAN).

R.253 The HG MUST support TR-143 Enabling Network Throughput Performance Tests and

Statistical Monitoring.

R.254 The HG MUST support TR-157 Issue 1 Amendment 10 or later.

R.255 The HG MUST only allow software downloads from a trusted source.

R.256 The HG MUST be able to hold two complete firmware images and their associated

configuration files

R.257 The HG MUST automatically failover to a previous working firmware or configuration file

in the event of a change and subsequent failure.

R.258 Firmware download MUST NOT be immediately followed by an automatic reboot.

R.259

The HG MUST support a the TR-069 Download RPC (from ACS to HG) to initiate the

firmware image download and a TransferComplete RPC (from HG to ACS) when the

download is complete

R.260 The HG MUST support the TR-069 Reboot RPC (form ACS to HG) to perform an immediate

reboot.

R.261 Transferring to the new firmware after a successful firmware download MUST only be

initiated via a reboot RPC or a local Customer initiated reboot

MULTI-SERVICE PROVIDER MANAGEMENT

The core functions of the HG can only be managed by its own ACS. However in a SWEX environment, authenticated

3rd parties may need access to certain parts of the HG in order to download, run and maintain additional software.


63

N° Requirement

R.262

The HG MUST allow authenticated 3rd party management systems to download and

maintain code within defined limits. Note this does necessarily imply having more than1

ACS associated with a given HG.

R.263 The HG MUST NOT allow 3rd party management systems to access any of its own core

functions

QOS REQUIREMENTS

N° Requirement

R.264 The HG MUST support ALL the QOS requirements in [5]

DIAGNOSTICS REQUIREMENTS

N° Requirement

R.265 The HG MUST support ALL the diagnostics requirements in [6].

R.266 The HG SHOULD keep a log of all reboots with the associated reason (e.g. crash, reset

button, remote reboot etc.). This log MUST be accessible via the ACS.

R.267 The HG SHOULD store a core dump for the last 5 crashes. This data MUST be able to be

uploaded to the ACS via TLS 1.2 protected HTTP POST or equivalent.


64

SWEX


R.268 The HG MUST support ALL the requirements in Open Platform 2.1 [2]. Note: this

requirement only applies to the High-End and OTT Gateways.


65

8 SECURITY REQUIREMENTS

PHYSICAL SECURITY

N° Requirement

R.269 The HG MUST NOT have any debug interfaces including, but not limited, to JTAG

R.270 Any individual debug pins MUST be grounded during final assembly and MUST NOT remain

connected to any signal line on the PCB.

R.271 The HG MUST only use encrypted Flash storage and with keys that are unique to each individual

HG.

R.272 The HG MUST have all sensitive components, such as flash memory, epoxied in

R.273 The HG MUST be resistant to reverse engineering

R.274 The HG MUST be protected against physical tampering.

R.275 The HG MUST NOT be able to be cloned

BOOT REQUIREMENTS

N° Requirement

R.276 The HG MUST use a secure boot process starting with boot code with the root of trust being held

in the chipset ROM.

R.277 The HG MUST use hardware-based, public/private key authentication

SOFTWARE SECURITY REQUIREMENTS


66

N° Requirement

R.278 The HG MUST use privilege separation of components at the OS level

R.279 HG processes MUST NOT be run as root unless absolutely necessary

R.280 The HG Kernel MUST be hardened (e.g. using GRSEC).

R.281 The HG MUST provide immunity against local privilege escalation attacks

R.282 The HG system MUST be constructed in a compartmentalised fashion with well-defined interfaces

and security boundaries

R.283 All software support for debug interfaces SHOULD be removed from production/release code

R.284 If debug interface software support is NOT removed, it MUST be subject to strong authentication

credentials

R.285 All HG software components MUST be able to be updated to address security issues

R.286 The HG MUST filter user input and other untrusted data before storing, interpreting or displaying it

R.287 All unused functionality MUST be removed from the HG code base, not just disabled.

R.288 The HG MUST perform randomisation of ports to minimise the risk of DNS attacks

R.289 The HG MUST NOT use predictable session IDs.

FIRMWARE SECURITY REQUIREMENTS

N° Requirement

R.290 The HG MUST support secure software/firmware download

R.291 All downloaded HG firmware, applications and packages MUST be encrypted and signed,

including the version number, in the signed image


67

N° Requirement

R.292 All signatures MUST be verified before any downloaded software is executed.

R.293 Software Image MUST be downloaded into RAM and fully validated before overwriting any

existing image in Flash

R.294 The HG MUST have a disaster recovery mechanism that enables the HG to revert to a

guaranteed operating state within x seconds of failure (e.g. during firmware upgrade or boot)

MANAGEMENT

N° Requirement

R.295 Remote access to CWMP management MUST be mutually authenticated via HTTPS

R.296 WAN IP ports MUST NOT be left open by default, with the exception of those used for remote

management and helpdesk access.

R.297 The SSH interface SHOULD use a single-use password administered by the ACS.

R.298 It MUST be possible to enable and disable SSH access via the ACS. By default this MUST be

disabled.

R.299 SSH access MUST be automatically disabled after a defined period of time, and after a reboot

CREDENTIALS AND CRYPTOGRAPHY

N° Requirement

R.300 The HG MUST have a unique, tamper proof ID

R.301 Credentials MUST NOT be derived from the HG serial number or MAC address


68

N° Requirement

R.302 All keys MUST be randomly generated or derived from a HG-unique value in the chipset read-

only memory.

R.303 All sensitive data stored on the HG e.g. usernames, passwords, IKE pre-shared keys MUST be

AES encrypted as a minimum.

R.304 Credentials (e.g. keys/ certificates/passwords) MUST be unique to each HG

R.305 The HG MUST use Transport Layer Security (TLS) 1.2 or higher for secure communications with

state of the art cipher suites. The HG MUST NOT use SSL for this purpose

R.306 The HG MUST use public/private key encryption, NOT symmetric encryption

USER RELATED REQUIREMENTS

N° Requirement

R.307 The HG MUST NOT store any data associated with any identifiable individual that might be

deemed to be sensitive from a personal or commercial perspective.

R.308 The HG MUST log all successful and failed authentication attempts for user or management

access

R.309 The HG MUST NOT support any user-accessible function to reset time and date.


69

WIRELESS SECURITY REQUIREMENTS

N° Requirement

R.310 The HGI MUST support Wi-Fi protected set-up (WPS).

R.311 The HG MUST support robust separation of channels (e.g. Open Wi-Fi red and green channels)

R.312 The HG’s default wireless credentials (e.g. WEP or WPA keys) MUST be unique per HG but

MUST NOT be related to any obvious source such as SSID or serial number

R.313 The HG’s wireless devices MUST default to the most secure option

R.314 Wireless passwords MUST be at least 8 characters in length and MUST contain a mixture of

lower and upper case letters, digits and symbols.

R.315 Wireless passwords SHOULD be 12 characters in length


70

9 OTT GATEWAY REQUIREMENTS

WAN INTERFACES

N° Requirement

R.316 The OTT Gateway MUST have a 100/1000Base-T WAN interface.

R.317

The OTT Gateway MUST support Wi-Fi as a WAN interface. If there is only one radio, then

this radio MUST be able to act as both a client to the WAN Wi-Fi network and an AP for

the LAN side network.

LAN SIDE INTERFACES

N° Requirement

R.318 The OTT Gateway MUST support at least 1 100/1000Base-T LANside Ethernet port

R.319 The OTT Gateway MUST support Wi-Fi as a LAN interface.

R.320 The OTT Gateway MUST have a 2.4 GHz Wi-Fi interface.

R.321 The OTT Gateway SHOULD support an additional, concurrent 5 GHz interface.

R.322 The OTT Gateway MUST support at least 2 external USB 2.0 ports

R.323

All USB ports MUST be able to be powered on / off in order to do a hard reset of an

attached dongle without power-cycling the gateway and without involving the user i.e.

via remote management

R.324 The OTT gateway MUST be able to support multiple WHAN technologies

R.325 The OTT SOC MUST have internal interfaces that allow additional WHAN technologies to

be embedded.


71

N° Requirement

R.326

The following technologies MUST be able to be embedded in the OTT gateway:

Zigbee

Bluetooth

DECT ULE

Z-Wave.

The actual choice and versions of these technologies MUST be able to be made at the

time of manufacture (i.e. not a modular system permitting upgrades after

manufacturing). These choices must be compliant with HGI-RD039 Requirements for

Wireless Home Area Networks [42] Supporting Smart Home Services.

R.327 The OTT Gateway MUST employ interference mitigation techniques between any of its

embedded radio interfaces.

R.328 The OTT Gateway MUST support an embedded DECT station, or a B2B SIP UA for voice

support.

IP ADDRESSING AND FORWARDING

N° Requirement

R.329 The OTT gateway MUST support the IPv4 requirements in Section 7.8.1

R.330 The OTT gateway MUST support the IPv6 requirements in Section 0

MANAGEMENT

N° Requirement

R.331 The OTT Gateway MUST meet all the management requirements in Section 7.20


72

N° Requirement

R.332 The OTT Gateway MUST be able to act as a management proxy for its associated devices

that cannot be managed directly by the OTT ACS.

SWEX

N° Requirement

R.333 The OTT Gateway MUST support SWEX as defined in Open Platform 2.1 [2].

SECURITY

N° Requirement

R.334 The OTT gateway SHOULD meet all the security requirements in Section 8.

POWER SUPPLY RELATED

N° Requirement

R.335 The OTT Gateway MUST have its own, dedicated power supply.

R.336 The OTT Gateway MUST be able to be connected to a UPS.


73

10 MISCELLANEOUS REQUIREMENTS

POWER-RELATED

N° Requirement

R.337 The HG MUST support Automatic power save modes,

R.338 Power saving techniques MUST be used whenever possible (see HGI power control spec

HGI-RD009-R3 [43] for general guidance)

R.339

The HG MUST always try to put the HG and all peripherals into the power mode with

lowest power consumption as quickly as possible, as long as this does not adversely affect

HG performance

R.340 The HG MUST comply with the latest version of the EU Code of Conduct on Energy

Consumption of Broadband Equipment [17]

MEMORY RELATED

N° Requirement

R.341 The HG SHOULD have at least 256 Mbytes of Flash Memory

R.342 The HG FLASH MUST support at least 100,000 cycles (100K P/E cycles with 10 years

retention)

MISCELLANEOUS


74

N° Requirement

R.343 The HG MUST provide a Hardware based watchdog mechanism that initiates a reboot in

the event of HG lock-up.

R.344 The HG MUST support (with appropriate hardware) an embedded speed tester that can

be accessed by any device on the customer network

R.345 The HG MUST be able to act as the client for a network located speed tester.

R.346 The HG MUST have an internal temperature sensor that can be read by the ACS


75

11 HOME GATEWAY PERFORMANCE

This section provides general requirements on the level of performance associated with High-End and Mid-Range

HGs. HGI gained considerable experience through industry test events with performance capabilities of HGs in areas

such as packet-per-second routing and forwarding capabilities under various loading conditions, including multiple

simultaneous operations, and these requirements build on that experience.

MEASURING PERFORMANCE

The following are used to characterise performance:

The main performance characterisation is the capability to forward packets, either in isolation, or concurrently with

other, possibly CPU-intensive, functions

One way to measure forwarding performance is in absolute numbers, for example, bits per second, or packets per

second.

An alternative method, and the one adopted in this document, is in terms of percentages; i.e., the percentage of

bandwidth of various interfaces.

Typically, forwarding small packets is more challenging than large packets so performance needs to be measured

with a range of packet sizes. See Table 1 for the set of packet sizes to be used in tests.

The following considerations also apply:

Forwarding performance measures can apply to either an interface or to the HG as a whole.

In some cases, requirements for forwarding are given while the HG is performing more advanced functions which

may involve the CPU.

Performance Testing Packet

Sizes

64 byte

128 byte

256 byte

512 byte

768 byte


76

1024 byte

1500 bytes

Random mix of 64, 256, 768

and 1500 byte packets

Table 1 – packet sizes for performance tests

HIGH-END HG PERFORMANCE

N° Requirement

HE1 Requirements HE2-HE17 MUST be met with:

IPv4 packets only

IPv6 packets only

A mix of IPv4 and IPv6 packets (50% each)

Each packet size in Table 1

With and without PPP encapsulation

2.4 GHz Wi-Fi

5 GHz Wi-Fi

Concurrent 2.4 GHz and 5 GHz Wi-Fi

HE2 The HG MUST be able to forward downstream packets (WAN to wired LAN) at 100% of

the physical layer rate of any of its WAN access interfaces

HE3 The HG MUST be able to forward upstream packets (wired LAN to WAN) at 100% of the

physical layer rate of any of its WAN access links


77

N° Requirement

HE4 The HG MUST be able to simultaneously forward packets downstream and upstream

(WAN and wired LAN) at 100% of the physical layer rates of any of its WAN upstream

links

HE5 The downstream, WAN to wired LAN, forwarding performance MUST NOT be impacted

by any amount of cross-traffic between 2 other LAN Ethernet ports.


by any amount of cross-traffic between 2 wireless devices with the HG acting as an AP


by any amount of cross-traffic between a wireless device and a wired LAN port


by a USB connected mass-storage device operating at a sustained read/write transfer

rate of at least 50 Mbps.

HE9 The downstream, WAN to wired LAN, forwarding performance MUST NOT be degraded

by more than 5% when the Firewall is enabled at its highest level.


by more than 5% when at least 2 ALGs are being invoked.


by more than 5% when at least 2 different, multi-parameter QOS signatures and rules are

being applied.


by more than 10% when the Firewall, ALG and QOS functions specified in HP9-11 are

being simultaneously applied.

HE13 The HG MUST be able to forward a bi-directional stream at the maximum physical layer

rate between any pair of wired LAN interfaces

HE14 The HG SHOULD be able to forward 2 bi-directional streams at 75% of the maximum

physical layer rate between any 2 pairs of wired LAN interfaces


78

N° Requirement

HE15 The HG SHOULD be able to forward packets (wired LAN to Wi-Fi) at 100% of the maximum

bandwidth of each Wi-Fi interface after allowing for the air interface overhead.

HE16 The HG SHOULD be able to forward packets (Wi-Fi to wired LAN) at 100% of the maximum

bandwidth of each Wi-Fi interface after allowing for the air interface overhead.

HE17 The HG SHOULD be able to forward packets (bidirectional Wi-Fi to/from wired LAN) that

consume 100% of the maximum physical layer bandwidth of each Wi-Fi interface (split

equally between transmit and receive).

HE18 The HG MUST be able to meet requirements HE2-HE4 while simultaneously responding

to any remote management command except firmware download.

HE19 The HG MUST meet all the High-End performance requirements with a performance

degradation of no more than 10% while running a representative SWEX application

MID-RANGE HG PERFORMANCE

N° Requirement

MR1 The Mid-Range Gateway MUST meet all the High-End performance requirements, but

with the following modifications

MR2 HE8 modified as follows:

The downstream, WAN to wired LAN, forwarding performance MUST NOT be impacted

a USB connected mass storage device operating at a sustained read/write transfer rate

of at least 30 Mbps.

MR3 HE9 modified as follows

The downstream, WAN to wired LAN, forwarding performance MUST NOT be degraded

by more than 10% when the Firewall is enabled at its highest level.


79

N° Requirement



by more than 10% when at least 2 ALGs are being invoked.



by more than 10% when at least 2 different, multi-parameter QOS signatures and rules

are being applied.



by more than 20% when the Firewall, ALG and QOS functions specified in MP9-11 are

being simultaneously applied.


The HG SHOULD be able to forward 2 bi-directional streams at 50% of the maximum

physical layer rate between any 2 pairs of wired LAN interfaces

OTT GATEWAY PERFORMANCE TARGETS

There are no performance targets for OTT Gateways as they are not expected to be running any particularly

demanding, high-speed applications.


80

12 REFERENCES

[1] HGI-RD001-R2.01 - Home Gateway Technical Requirements: Residential Profile V1.01

[2] HGI-RD048 - HG Requirements For Open Platform 2.0

[3] HGI-SBI054 - Use Cases and Architectures For Hybrid Access

[4] Broadband Forum WT-317 – Network Enhanced Residential Gateway (NERG)

[5] HGI-RD0027-R3 – Home Gateway QOS Module Requirements

[6] HGI-RD016-R3 - HG and Home Network Diagnostics Module Requirements

[7] HGI-RD010-R3 – Home Gateway Requirements for Multi-Session Support

[8] HGI-RD024 - Requirements for an NGA (Active Line Access) capable NT

[9] HGI-GD036 - Smart Home Architecture and System Requirements

[10] Broadband Forum TR-242 – IPv6 Transition Mechanisms for Broadband Networks

[11] HGI-RD-057 – Wi-Fi System Requirements for Home Gateways: NFC Pairing, Guest Access, Hotspot

[12] Broadband Forum TR-069 Amendment-5 – CPE WAN Management Protocol

[13] Broadband Forum TR-181 Amendment 5 - Device Data Model for TR-069

[14] Broadband Forum TR-098 Amendment 2 - Internet Gateway Device Data Model for TR-069

[15] Broadband Forum TR-104 - Provisioning Parameters for VoIP CPE

[16] Broadband Forum TR-157 Amendment 10 - Component Objects for CWMP

[17] EU Code of Conduct on Energy Consumption of Broadband Equipment v5

[18] ITU-T 992.5 - Asymmetric digital subscriber line 2 transceivers – Extended Bandwidth ADSL2 (ADSL2plus)

[19] ITU-T G.993.2 Very high speed digital subscriber line transceivers 2 (VDSL2)

[20] ITU-T G.9701 - Fast access to subscriber terminals (G.fast) - Physical layer specification

[21] IEEE 802.1Q-2011, Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks

[22] IEEE 802.1p: LAN Layer 2 QoS/CoS Protocol for Traffic Prioritization

[23] ITU-T G992.3 - Asymmetric digital subscriber line transceivers 2 (ADSL2)

[24] ITU-T G998.4 - Improved impulse noise protection for digital subscriber line (DSL) transceivers

[25] ITU-T G.9700 - Fast access to subscriber terminals (G.fast) - Power spectral density specification

[26] HGI-RD45v2 - Wi-Fi requirements for Home Gateways - Automatic Channel Selection and Repeaters

[27] IEEE 802.11i-2004: Amendment 6: Medium Access Control (MAC) Security Enhancements

[28] Wi-Fi Alliance requirements for interoperability

[29] IEEE1905.1 – Standard for a convergent digital home network for heterogeneous technologies

[30] RFC1334 - PPP Authentication Protocols (PAP)


81

[31] RFC1994 - PPP Challenge Handshake Authentication Protocol (CHAP)

[32] RFC1332 - The PPP Internet Protocol Control Protocol (IPCP)

[33] RFC2364 – PPP Over AAL5

[34] RFC2684 – PPP Over Ethernet

[35] RFC7084 - Basic Requirements for IPv6 Customer Edge Routers

[36] RFC4862 - IPv6 Stateless Address Autoconfiguration

[37] RFC3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6).

[38] RFC4861 - Neighbor Discovery for IP version 6 (IPv6).

[39] RFC4443 - ICMP for IPv6

[40] RFC4884 - Extended ICMP to Support Multi-Part Messages

[41] RFC3376 - Internet Group Management Protocol, Version 3

[42] HGI-RD039 – Requirements for Wireless Home Area Networks (WHANs)

Supporting Smart Home Services

[43] HGI-RD009-R3 – Requirements for an Energy Efficient Home Gateway

[44] RFC1305 - Network Time Protocol (Version 3) specification

[45] RFC2030 - Simple Network Time Protocol Version 4 for IPv4, IPv6 and OSI

Note that the Broadband Forum versions indicated here above are the most recent available at the time of writing. Due to the continuous update of these BBF Technical Reports their most recent version should be taken into account when developing technical specifications for new products.