HGI-RD016 - Home Gateway Initiative · HGI-RD016 HG and Home Network Diagnostics Module Requirements ... Huawei, Ikanos, Intel, IS2T, KDDI, ... BRAS Broadband Remote Access Server

P a g e 1 © HGI 2013 – All rights reserved

HGI-RD016

HOME GATEWAY AND HOME NETWORK DIAGNOSTICS

MODULE REQUIREMENTS

Published April, 2013

Source HGI02184_R06.doc

HGI-RD016 HG and Home Network Diagnostics Module Requirements


1 CONTENTS 2 Important notices, IPR statement, disclaimers and copyright.............................................................. 5

2.1 About HGI ......................................................................................................................................... 5

2.2 This may not be the latest version of This HGI Document .............................................................. 5

2.3 There is no warranty provided with This HGI Document ................................................................ 5

2.4 Exclusion of Liability ......................................................................................................................... 5

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

2.6 Intellectual Property Rights ............................................................................................................. 6

2.7 Copyright Provisions ........................................................................................................................ 6

2.7.1 Incorporating HGI Documents in whole or part within Documents Related to Commercial

Tenders 6

2.7.2 Copying This HGI Document in its entirety ............................................................................. 6

2.8 HGI Membership .............................................................................................................................. 7

3 Acronyms .............................................................................................................................................. 8

4 Introduction ........................................................................................................................................ 11

4.1 Scope And Purpose ........................................................................................................................ 11

4.2 Definitions Of Terms ...................................................................................................................... 12

5 Troubleshooting Philosophy ............................................................................................................... 13

5.1 Troubleshooting Philosophy And Key Requirements .................................................................... 13

5.2 Detecting A Problem ...................................................................................................................... 14

5.3 Service Specific Diagnostics ........................................................................................................... 14

5.4 Avoiding The Initial Help-desk Call ................................................................................................. 14

5.5 Selecting The Service To Be Investigated ....................................................................................... 15

5.6 Initiating Troubleshooting.............................................................................................................. 15

5.7 Non Service-specific Troubleshooting ........................................................................................... 15

5.8 Self-Care And Help-Desk Assistance .............................................................................................. 15

6 Diagnostics Architecture ..................................................................................................................... 17

7 Types Of Problem ................................................................................................................................ 19

7.1 Examples Of Problems ................................................................................................................... 19



7.1.1 Connectivity........................................................................................................................... 19

7.1.2 Reachability ........................................................................................................................... 20

7.1.3 Speed ..................................................................................................................................... 20

7.1.4 QoS ........................................................................................................................................ 21

7.1.5 HG Hardware Or Software Problem ..................................................................................... 21

7.1.6 Service Provisioning .............................................................................................................. 22

7.1.7 Service Initiation .................................................................................................................... 22

7.2 Real-World Support Issues ............................................................................................................. 23

7.2.1 Survey Results ....................................................................................................................... 23

7.3 High Level Requirements ............................................................................................................... 25

7.3.1 Connectivity........................................................................................................................... 25

7.3.2 Reachability ........................................................................................................................... 26

7.3.3 Speed ..................................................................................................................................... 26

7.3.4 QoS ........................................................................................................................................ 26

7.3.5 Home Gateway Hardware Or Software Fault ....................................................................... 26

7.3.6 Service Provisioning .............................................................................................................. 27

7.3.7 Service Instance Initiation ..................................................................................................... 27

8 Requirements ...................................................................................................................................... 27

8.1 Basic HG Information ..................................................................................................................... 27

8.2 Firmware Management ................................................................................................................. 28

8.3 HG Self-Test.................................................................................................................................... 29

8.4 HG Hardware and Performance monitoring .................................................................................. 30

8.5 Duplicate Address Detection ......................................................................................................... 30

8.6 SWEX Support ................................................................................................................................ 30

8.7 Diagnostics WEB page support ...................................................................................................... 31

8.8 WAN Port Control .......................................................................................................................... 31

8.9 Power Saving .................................................................................................................................. 31

8.10 Service Selection ........................................................................................................................ 32

8.11 Service Configuration Testing .................................................................................................... 32

8.12 Device Discovery ........................................................................................................................ 33



8.13 HG Discovery ............................................................................................................................. 34

8.14 Topology Discovery.................................................................................................................... 34

8.15 Connectivity Testing .................................................................................................................. 35

8.16 Reachability Testing ................................................................................................................... 35

8.17 Speed Testing ............................................................................................................................ 35

8.17.1 Interface Counters ............................................................................................................ 35

8.17.2 Accessing a Network Based Speed Checker ..................................................................... 36

8.17.3 HG Based Speed Checker .................................................................................................. 37

8.18 Service Class Monitoring ........................................................................................................... 37

8.19 Instantaneous Interface Rate Monitoring ................................................................................. 39

8.20 Long Term Interface Rate Monitoring ....................................................................................... 39

8.21 Wireless Interface Logging ........................................................................................................ 40

8.22 Multicast .................................................................................................................................... 40

8.23 Voice Specific Diagnostics .......................................................................................................... 41

8.24 Remote Access Support ............................................................................................................. 42

9 Management Requirements ............................................................................................................... 42

9.1 CWMP ............................................................................................................................................ 42

9.2 SWEX Management ....................................................................................................................... 43

10 References ..................................................................................................................................... 43



2 IMPORTANT NOTICES, IPR STATEMENT, DISCLAIMERS AND

COPYRIGHT

This chapter contains important information about HGI and this document (hereinafter ‘This HGI

Document’).

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

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

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

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

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



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

2.7 COPYRIGHT PROVISIONS © 2013 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 2.7.1 and Section 2.7.2 :

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

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

http://www.homegateway.org/



2.8 HGI MEMBERSHIP The HGI membership list as of the date of the formal review of this document is: Actility, Advanced

Digital Broadcast, Alcatel-Lucent, Arcadyan, Arm, Belgacom, Bouygues Telecom, British Sky Broadcasting

Ltd., Broadcom, BT, Cavium, Celeno, Cisco, Deutsche Telekom, Devolo, Dialog Semiconductor, D-Link

Corporation, DSP Group, eflow, EnOcean Alliance, Ericsson AB, Fastweb SpA, France Telecom, Hitachi,

Huawei, Ikanos, Intel, IS2T, KDDI, KPN, LAN, Lantiq, LG Electronics, Lionic, Makewave, Marvell

Semiconductor, Mindspeed, Mitsubishi, MStar, NEC Corporation, Netgear, NTT, Oki Electric Industory,

Portugal Telecom, ProSyst, Qualcomm Atheros, Sagemcom, Samsung, Seagate, Sercomm Corp., Sigma,

SoftAtHome, Stollmann, Sumitomo, Swisscom AG, Technicolor, Telecom Italia, Telekom Austria,

TeliaSonera, Telstra, TNO, Trac Telecoms & Radio Ltd, Vodafone, Vtech, Zarlink, ZTE, ZyXEL.



3 ACRONYMS

ACS Auto-Configuration Server

ADSL Asymmetric Digital Subscriber Line

AN Access Network

ANP Access Network Provider

ARP Address Resolution Protocol

ATA Analogue Terminal Adapter

BRAS Broadband Remote Access Server

BSP Broadband Service Provider

CAC Call Admission Control/Connection Admission Control

CE Customer Experience

CoS Class of Service

CPE Customer Premises Equipment

CPU Central Processing Unit

CRC Cyclic Redundancy Check

DHCP Dynamic Host Control Protocol

DNS Domain Name Server

DRAM Dynamic Random Access Memory

DSL Digital Subscriber Line

DSLAM DSL Access Multiplexer

ED End Device

EU End user

GPON Gigabit Passive Optical Network

GUI Graphical user Interface



HG Home Gateway

HGI Home Gateway Initiative

HN Home Network

HNID Home Network Infrastructure Device

I/F Interface

MAC Media Access Control

LAN Local Area Network

NAS Network Attached Storage

NAT Network Address Translation

NGN Next Generation Network

NGA Next Generation Access

NT(E) Network Termination (Equipment)

OAM Operations, Administration & Maintenance

OS Operating System

OTT Over The Top (service)

OUI-SN Organisationally Unique Identifier

PHY Physical Layer

PLT Power Line Technology

PM Performance Monitoring

PPP Point-to-Point Protocol

PVR Personal Video Recorder

QoS Quality of Service

RCPI Received Channel Power Indicator

RMS Remote management System



RTP Real Time Protocol

SLA Service Level Agreement

SNMP Simple Network Management Protocol

SP Service Provider

SSID Service Set Identifier

STB Set Top Box

SWEX Software Execution Environment

UI User Interface

UMTS Universal Mobile Telephone System

UPnP Universal Plug and Play

URL Universal Resource Locator

USB Universal Serial Bus

VAS Value Added Service

VDSL Very highspeed Digital Subscriber Line

VoD Video on Demand

VoIP Voice Over IP

WAN Wide Area Network

xDSL ADSL and VDSL



4 INTRODUCTION

4.1 SCOPE AND PURPOSE

Broadband Service Providers (BSPs) are increasingly looking to take broadband beyond basic Internet

access and provide a range of Value Added Services (VASs). These range from fully managed services,

such as IPTV, to others which may simply benefit from some enhanced network treatment, e.g. VoIP or

gaming. Getting additional revenue from VASs is especially important when trying to make the business

case for higher speed access technologies such as VDSL and GPON.

These VASs often place greater transport demands on the network in terms of both quantity and quality.

These will not always be able to be met unless there is a significant upgrade in network capacity; further

in some parts of the network (such as in the home), the required upgrade may not even be possible.

Therefore VASs will not always be delivered in an acceptable way, although QoS management can help

greatly. When a problem does arise, it is essential that it can be resolved as quickly and cheaply as

possible, so that the BSPs’ support costs do not become prohibitive, and the customer experience is not

compromised to the point where the user no longer takes the service. If this can be done by the

customer himself, then there will be benefits in terms of both speed of problem resolution and lower

cost.

It is important to be able to diagnose problems on a service specific basis, because the techniques

required may be service dependent, and so the appropriate service provider is contacted (where this

cannot be avoided). The situation is however complicated by the fact that there may be a variety of

services, sometimes delivered concurrently, and the mix will change over time.

This document specifies a set of diaqnostic functions in the Home Gateway (HG) 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.

While this document takes an end to end architectural view, the main focus is on specifying the

requirements needed in the HG to support this architecture. The role of a Cloud-based service in

augmenting the embedded diagnostics capability is recognised, but there is no intention to define the

details of such a Cloud service, or how it might interact with the HG. HNIDs are included in the

architecture, but this document does not include any specific requirements for HNID diagnostics

functionality; this may be the subject of future HGI work.

Since at least the initial stages of troubleshooting are intended to be done by the user themself, there is

a need for a local (graphical) interface to allow them to interact with the system both to invoke tests,



and observe the system status and test results. This user interface could be implemented on any or all of

the following: PC, laptop, smartphone and tablet. HGI does not plan to specify this interface. The look

and feel, as well as the functionality of such an interface is left to individual BSPs as it is a potentially

significant differentiator. In the Requirements, this interface is referred to generically as the Local UI.

4.2 DEFINITIONS OF TERMS

The definitions of MUST and SHOULD in this document are as follows:

MUST A functional requirement which is based on a clear consensus among HGI Service

Provider members, and is the base level of required functionality for a given class of equipment.

MUST NOT This function is prohibited by the specification.

SHOULD Functionality which goes beyond the base requirements for a given class of HG, and can

be used to provide vendor product differentiation (within that class).

Note: These definitions are specific to the HGI and should not be confused with the same or similar

terms used by other bodies.



5 TROUBLESHOOTING PHILOSOPHY

5.1 TROUBLESHOOTING PHILOSOPHY AND KEY REQUIREMENTS

Broadband Service Providers are increasingly attempting to provide their customers with Value Added

Services, either as direct revenue sources, or to make their overall service bundle more attractive so that

churn is reduced. However these services have to be delivered alongside OTT services and content (such

as YouTube), and in the presence of increasing in-home traffic such as local content streaming from a

PVR or NAS. This can lead to multiple concurrent streams both through the HG, and on the home

network.

VASs range from fully managed services, such as IPTV, to those which may simply benefit from some

enhanced network treatment, e.g. VoIP or gaming. Although the user may have the greatest

expectations of the high-value services, in particular IPTV, there is a need for the diagnostics

architecture to be able to cope with a wider range of services, as the BSP is likely to be held responsible

for all service shortcomings, whether these services are managed or not.

There are many ways in which service delivery can be compromised. These range from provisioning

problems, through connectivity and authorisation, to QoS. The problem might also be with the service

platform itself e.g. temporary unavailability or inadequate capacity to meet a specific service request.

While the HGI QoS scheme ([10]) was designed to be able to cope with a mixture of managed and

unmanaged services, QoS alone cannot help when the sustained load offered to the network is greater

than the physical layer capacity. Admission control is sometimes suggested as the way to avoid

sustained overload, but this presupposes that all applications request permission to start via some

signalling protocol, and in a way which indicates their bandwidth requirements. Further, there needs to

be a way of rejecting a request when necessary. Few applications actually do this, but even if they did, it

would not address the case of physical layers with a time-varying capacity (e.g. wireless and PLT).

Therefore the likelihood of service disruption is increasing, while the revenue opportunities remain

extremely limited. It is therefore very important that support calls and costs are kept to the absolute

minimum.

Few if any residential services have a parameterised SLA i.e. there is no contractual agreement with the

service provider as to the level of service provided. However customers do expect value added services

to provide an appropriate quality of experience, in particular, for video. This means for example no

picture blocking, frame freezing or audio discontinuities. These however will occur from time to time,

and when they do, it is highly desirable that the end-user himself is able to analyse and fix or avoid the

problem without the need to contact the Service Provider, especially when the problem is in the HG or

HN. This is not just a benefit to the SP; the end-user also benefits as helpdesk costs are part of the cost-

stack of any product, and so will ultimately impact its price. The vast majority of customers are however



non-technical - indeed home networking can be a challenge even for industry professionals - therefore it

is necessary to provide some very easy to use diagnostic tools to make this approach feasible.

5.2 DETECTING A PROBLEM

The first issue is how to determine that there is a problem. This document acknowledges the key role of

the user in problem detection, although the BSP is also likely to have their own service monitoring tools

which can proactively detect some service failures, especially those due to the platform itself.

The user is a key element in the diagnostics chain in the HGI approach. If the user is happy with the

service delivery, then there is no problem by definition, even if the service is not being delivered

optimally. Further, it is hard, if not impossible, for an automated system to decide what the user is

doing, and whether his particular mix of services is being delivered satisfactorily. Many services have no

formal signalling so there is no way of knowing what their bandwidth requirements are, let alone the

more subtle characteristics of jitter, packet loss etc. Even value added services, such as voice and video,

can be very bursty, making it hard to detect abnormal behaviour. Probably the worst thing of all would

be to tell the end-user that he had a problem when he didn't, or was maybe not even trying to do

something.

5.3 SERVICE SPECIFIC DIAGNOSTICS

Since this is a multi-service environment, the diagnostics capability needs to be able to be service-

specific. The end-user perspective is also likely to be service-based.

The way in which problems are detected and located may depend on the nature of the transport

requirements of the service. From a commercial perspective, services may be provided by different

service providers, and it is important that if a support call is needed, it is directed to the appropriate

Application Service Provider.

However the approach used here is based on service type rather than service instance. Detecting a

service type can be relatively easy; it is harder to detect every instance. This greatly simplifies the

solution and will hardly detract from the usefulness of the technique as multiple simultaneous VASs of

exactly the same type will be a rare occurrence. The techniques will still work in that particular case, but

it may be more difficult to identify which Service Provider to contact.

5.4 AVOIDING THE INITIAL HELP-DESK CALL

When the user does experience a problem, the first thing to do is to get him to access a self-care system,

rather than calling a helpdesk. One way of doing this would be an application which displays a simple

help button on a PC screen, smartphone or tablet. Clicking this button accesses a URL which is

redirected to the HG and initiates a local diagnostics application. This application generates Web-like

Help pages which are displayed on the appropriate device to guide the end-user through the process.



This self-care can also be a combination of local (HG) and remotely hosted (e.g. Cloud-based)

applications. In the latter case the URL link on the home gateway could provide a redirect to the

network-based self-care platform. This may allow more advanced diagnostics, and means that

maintaining and upgrading the system can be done centrally, rather than having to upgrade a large

number of HGs. However the HG always needs to have some local diagnostics capability, for the case

where the problem is due to lack of WAN connectivity, which would of course prevent access to a

central diagnostics system.

5.5 SELECTING THE SERVICE TO BE INVESTIGATED

Since troubleshooting needs to be service specific, the end-user has to have some way of telling the

diagnostics system which service is having a problem. HGI services are identified by a service signature

for QoS control purposes. This signature is configured in the HG, so that all that is required is that a user-

friendly service name is also configured and stored in the HG for each service. The end-user can then be

prompted to choose the affected service from a drop-down list. Service naming and selection can also

be done remotely (e.g. in the Cloud) where a centralised approach is preferred.

5.6 INITIATING TROUBLESHOOTING

Once the faulty service has been identified by the user, the appropriate diagnostics can be initiated. This

document specifies a set of capabilities in the HG that can be used to support a wide variety of

troubleshooting procedures; which tools are actually used - and the interpretation of the results - is

entirely up to each BSP. It is anticipated that some kind of local expert system would be used to

sequence the tests and interpret the results. This is an ideal use of the SWEX capabilities that are

specified in [2]. Again, a Cloud-based system could be used as well or instead, as long as there is Cloud

connectivity.

5.7 NON SERVICE-SPECIFIC TROUBLESHOOTING

While a lot of the troubleshooting is expected to be service-specific, there are some general problems

which are not; the classic example being slow Internet access. Indeed it may well be appropriate to test

general connectivity and access speed before trying the service specific diagnostics. The HGI diagnostics

approach also provides tools to investigate these more general problems.

5.8 SELF-CARE AND HELP-DESK ASSISTANCE

While the main purpose of this approach is to avoid helpdesk calls, more difficult cases - or less

knowledgeable end-users - may still need to call a helpdesk. In these cases, the helpdesk may also



benefit from having direct access to the diagnostics tools. Requirements are therefore included to allow

secure remote access to local tools and the associated statistics.



6 DIAGNOSTICS ARCHITECTURE

The overall HGI diagnostics architecture is shown in Figure 1, which also gives an indication of the types

of processes that this architecture can support.

FIGURE 1 OVERALL HGI DIAGNOSTICS ARCHITECTURE



The customer realises that he has a problem with a service. He attempts to find a solution by self-care

using a smartphone, tablet or PC. The Help request is intercepted by the HG and redirected to a Web

page. This can either be locally generated, or a real Web page in the Cloud, if there is still WAN

connectivity. It is always necessary to have at least some basic diagnostics capability in the HG for those

cases where WAN connectivity has been lost. The BSP-specific diagnostics procedure is initiated from

this Web page.

The diagnostics application should only request the essential minimum of information from the user;

this has to include the identity of the service which is having the problem. Gathering more information

on the nature of the problem (e.g. by automated structured questioning) may result in more targeted

and therefore quicker testing, but that is entirely a matter for the BSP and what he chooses to put in his

application.

The application can then carry out a series of tests ranging from device presence and connectivity, to

general performance, and finally through to testing or monitoring of the service itself. Again the degree

of user interaction is entirely a matter for the BSP.

If this resolves the problem, which of course could be via a non-technical solution such as suggesting a

change in customer behaviour, the process terminates. If there is a still a problem and it is clearly not in

the customer domain, this is communicated to the user, along with a suggestion as to what to do next. If

however the problem might still be in the customer domain, but more subtle or tricky, the customer (or

the application) can contact a helpdesk which has access to at least the same (and possibly a fuller set

of) tools, and will have more expertise. In certain cases the helpdesk operative will need to interact

directly with the HG, e.g. to start a test, read a counter or a test result etc. This document does not

specify the detailed nature of that interaction, there is simply a high level requirement for direct, secure,

remote access to certain diagnostic functions in the HG. This is shown in Figure 1 by the direct dotted

line between the SP domain and the HG. It is deliberate and significant that this interaction does not go

via the ACS. One of the requirements of this interface is that it should be near real-time, i.e. with a

response time of ~<1 sec. This is both to speed up the troubleshooting, and allow the helpdesk to see

the impact of various user actions, e.g. unplugging a cable, in a timely fashion. ACSs are not generally

designed to have this kind of real-time performance. For other diagnostics operations, in particular

those that involve any significant data transfer, the ACS is likely to be the appropriate entity. In the

Requirements, these 2 cases are distinguished by using the term Remote Agent for the direct

interaction, and ACS for the other, typically more data oriented, interaction.

Background information gathering which may assist troubleshooting can be permanently enabled. This

can include such things as a history of device attachment, and the long-term performance of interface

types. This information can also be used to decide whether or not to allow a user to subscribe to a

particular service. The network management system is shown here generically as an ACS.



7 TYPES OF PROBLEM

There are several types of problem that can adversely impact the delivery of a service:

1. Connectivity

2. Reachability

3. Speed

4. QoS

5. Home Gateway hardware or software fault

6. Service provisioning

7. Service instance initiation (e.g. signalling).

Note: The distinction between connectivity and reachability is related to addressing, i.e. there may be a

Layer 2 connection between 2 points (e.g. PPP connection), but no IP reachability e.g. to the service

Gateway.

Some of these problems can occur anywhere on the end to end path pertaining to the service. One of

the main purposes of troubleshooting is to determine the part of the network in which the problem is

occurring. The scope of this document is limited to the HG, HN (including HNIDs) and end-devices. The

intention is to be able to determine if services are being delivered to the HG, through the HG, and to the

extent possible, across the HN to the end-devices. Where services are not even being delivered correctly

to the HG, then this information is communicated to the user, but this document does not address

troubleshooting the nature or location of WAN problems, except where it is the HG that is the cause of

the problem, e.g. by mismanaging upstream QoS.

7.1 EXAMPLES OF PROBLEMS

The following Tables give some examples of how and where each of the above problem types might

arise, and how various monitoring points could provide useful demarcation information. Monitoring

point here can mean a network location, a device (e.g. HG, HNID), a device attribute (e.g. DSL sync), a

device element (e.g. HG LAN port), or a specific counter on a port.

Note that while HG-based diagnostics can provide fairly granular fault demarcation within the home, it

can only directly determine whether or not a problem is outside the home domain, not where it is.

7.1.1 CONNECTIVITY

Symptom Possible Causes Monitoring points

DSL line will not sync Noise, access network fault, DSLAM fault

HG WAN sync



DSL line frequently resyncs Noise on access line. Incorrect line optimization (low margin, no interleave)

HG WAN stats (e.g. margin)

No PPP session established Login failure, BRAS fault HG

No wireless connectivity between HG and End Device (ED)

Incorrect SSID, incorrect wireless keys, noise, excessive distance

HG access point

No connectivity between HG and ED or HNID

Disconnected or faulty cable. PLT blackspot

LAN ports on HG and HNIDs

7.1.2 REACHABILITY


Cannot access any WAN service No HG IP address

Incorrect Firewall setting

HG

Cannot access a particular WAN service

Service down

DNS failure

Firewall setting

HG

Remote server

Cannot access any LAN device DHCP failure

ARP failure

HG

Cannot access a particular LAN device

DHCP address limit

NAT problem

HG

7.1.3 SPEED


Slow download/browsing DSL line rate reduced

Congestion in aggregation network

DSL WAN port

HG LAN interface ports

HG CPU usage



Internet peering point congestion

Server overload

In-home technology running slowly due to a PHY rate change or congestion.

HG CPU overloaded

HG memory usage

HNID interfaces

ED interfaces

7.1.4 QOS


Service constantly disrupted or fails completely

DSL line slow (PHY rate)

DSL line congested

Excessive packet loss on Access line

No QoS configuration

Incorrect QoS configuration

LAN technology has insufficient bitrate

WAN service rate and error count

LAN service rate and error counts

LAN and WAN queue statistics

Service occasionally disrupted

Excessive packet loss on access line

Excessive packet loss on LAN

Noise

No QoS configuration

Incorrect QoS configuration

WAN I/F (error count)

LAN I/F (error count)

LAN and WAN queue statistics

Wireless interface (noise and PHY rate)

7.1.5 HG HARDWARE OR SOFTWARE PROBLEM

Symptom Possible Cause Monitoring points

Erratic performance or slow response

HG CPU overload, i.e. attempting to execute too much simultaneous processing

HG CPU

All local and WAN HG CPU failure. Overheating, HG internal temperature. HG



connectivity lost static discharge hardware self-test

HG hangs up at various times, but may be able to reboot

HG memory failure

Overheating

Static discharge

HG internal temperature

Memory tests

HG fails to operate properly or at all

Firmware corruption

Firmware bug

Flash or memory fault

SWEX problem

Memory checksums

Memory usage

CPU load

HG frequently reboots Software problem

Firmware corruption

HG memory check

Voice port not active Voice port damaged by over voltage or static

HG port monitoring

LAN ports connection failure (Ethernet, USB)

Port damaged by over voltage or static.

HG port monitoring

7.1.6 SERVICE PROVISIONING


No voice dial tone Voice not been provisioned on the home gateway

Misconfiguration

HG

7.1.7 SERVICE INITIATION


Cannot initiate a service session Service has not been provisioned on the home gateway

Firewall misconfiguration

HG

Service does not work properly on initial attempt

QoS not configured for service HG

ED



No access to a particular service Service platform down

Lack of service platform capacity

Bill not paid

Firewall misconfiguration

User authorization failure

Signalling failure

HG, ED

7.2 REAL-WORLD SUPPORT ISSUES

Section 7.1 lists those problems which could occur in principle. The whole point of remote diagnostics is

to reduce support costs, and improve the customer experience (CE). The focus therefore needs to be on

the most common problems which have the greatest impact on costs and CE.

A survey was undertaken in which HGI SPs were asked to rate a number of service-related fault types for

their impact on support costs, and the degree to which enhanced diagnostics might be able to help.

A summary of the responses is presented below, with the individual BSP responses having been

anonymised, as they may have some commercial sensitivity.

7.2.1 SURVEY RESULTS

The problems covered by the survey are shown in the below Table.

Error Category Description

Service problem Loss of service, service glitches etc.

Network configuration Wrong network configuration (IP, Broadband setup)

WiFi Configuration WiFi Setup (WiFi not enabled, forgotten passwords etc.)

Wiring Unplugged cable, wrongly plugged cable, etc.

Broadband Performance Quality, speed, stability of connection

HG Setup/Configuration Configuration, faulty firmware etc.

End devices SP and non SP devices (PC, NAS, STB etc.)



Broadband line sync Establishment of connection, access line drop-out

Access Parameters Unknown or incorrect login parameters (password, credentials etc.)

Hardware Replacement Replacement of (possibly) faulty hardware

General Support/Guidance

Issues which can only be clarified by a helpdesk agent (information request etc.)

IPTV Availability, quality of IPTV, VoD

VoIP Availability, quality

VAS Availability, quality of other Value Added Services

The categories which were said to have the highest current impact on support costs were as follows:

IPTV – poor video quality or complete loss of service

Poor video quality over WiFi

Poor VoIP quality (network)

Broadband login failure – username/password problems

UMTS misconfiguration (business customers)

PC problems

WiFi Security keys

DSL sync loss

HG frequently reboots.

Not all of these can be identified or solved by diagnostics. The below Table summarises the essential

nature of the problem, and the extent to which diagnostics may help. The solutions have been

categorised by whether they are amenable to a (local or Cloud-based) expert system, and the degree to

which a helpdesk may provide additional capability, although again helpdesk involvement is to be

avoided if possible for cost reasons.

Symptom Actual problem Useful fault demarcation

Expert system Helpdesk added value

IPTV quality Packet delivery Network

HG

HN

Yes Minimal (overall service problem)

WiFi video quality Packet delivery HN Yes Minimal



Local noise

VoIP quality (network) Network congestion

Lack of QoS

Network Yes Minimal

Broadband login failure

Customer forgetfulness

- - Password reset

PC problems Infinite - No – over and above PC wizards

Possible but requires high level of expertise

WiFi Security keys Customer lack of knowledge or ability to enter configuration

- Yes Identifying the type of problem

HG loses DSL sync HG/DSLAM DSL configuration

No No Can trigger an investigation or configuration change

HG loses DSL sync Access cable cut No Possibly Can do a physical line test

HG frequently resyncs Access line noise No No Access to DSLAM stats

This suggests that many of the problems are amenable to automatic identification, and demarcation,

and that a helpdesk will only be of value in a small number of cases. However the challenge will be to

stop the natural customer reaction to call the helpdesk first regardless, and to find a solution that the

customer can implement himself whenever possible.

7.3 HIGH LEVEL REQUIREMENTS

The high-level requirements related to diagnosing the different problem types identified above are as

follows.

7.3.1 CONNECTIVITY

Determine the presence of all the devices on the HN. This needs to include the automatic

detection and logging of changes e.g. when devices are added to or removed from the HN. A log



of changes can be important when attempting to correlate service problems with a change in

the HN configuration

Determine the connectivity between the various end-devices, any HNIDs and the HG. This may

involve both passive monitoring and active probing.

7.3.2 REACHABILITY

Be able to test IP reachability on demand.

7.3.3 SPEED

Measure the aggregate rate on the HG WAN interface for traffic (ingress and egress)

Measure the rate at the ingress to, and egress from, the HG for packets with a given service

signature

Provide access to a (WAN-based) speed checker to test the access speed

Provide a local speed check function for measuring the performance across the LAN in both the

upstream and downstream directions

Measure and store historical rates for all interfaces which have a time-varying PHY.

7.3.4 QOS

The HGI QoS approach is based on the concept of configurable (packet based) service signatures

[10]. The QoS diagnostics need to be able to:

Check the QoS configuration, i.e. which signatures have been configured and the mapping

between service signature and queues

Check the performance of a specific queue in terms of average and maximum queue length, and

dropped packets

Measure the throughput in a given queue over configurable time periods.

7.3.5 HOME GATEWAY HARDWARE OR SOFTWARE FAULT

Hardware self-test capabilities

Software self-test capabilities

Firmware tests i.e. integrity of the firmware image

Monitor and log hardware usage and performance e.g. CPU and memory

Temperature sensing.



7.3.6 SERVICE PROVISIONING

Check firewall settings

Check QoS settings

Check VoIP settings

Check voice dial tone.

7.3.7 SERVICE INSTANCE INITIATION

Check reachability of service platform

Check availability of service platform

Check service subscription

Check firewall settings

Check QoS settings.

8 REQUIREMENTS Some requirements involve the local logging of information in the HG. In some cases these need to be

preserved through a reboot or power cycling of the HG, and therefore need to be stored in non-volatile

memory (Flash). However Flash has a limited number of read-write cycles, and so logs that are expected

to be updated frequently should be stored in DRAM. This is explicitly specified in the appropriate

requirements, with all other logs being written to Flash memory.

8.1 BASIC HG INFORMATION

N° Requirement

R1.

The HG MUST be able to provide the following HG configuration information to a Remote Agent or Local UI on demand:

Device type

Hardware version

Software version

Firmware version

Device status (e.g. device in self-test, active etc.)

R2. The HG SHOULD be able to store a Crash Dump in local non-volatile memory.

R3. The HG MUST preserve the Crash Dump through a power-cycle and reboot.



N° Requirement

R4. The HG MUST be able to upload the Crash Dump to the ACS using CWMP as per [3], [4] and [5].

8.2 FIRMWARE MANAGEMENT

Accurate knowledge of the current hardware and firmware versions is a key initial step in remote diagnosis.

N° Requirement

R5. The HG MUST be able to rollback to a previous, stored firmware version (either stored locally or in the Cloud) on command from a Remote Agent or the Local UI.

R6. The HG MUST be able to return to the firmware version that was running before the rollback on command from a Remote Agent or the Local UI.

R7. The HG MUST be able to be remotely rebooted by the Remote Agent.

R8. The HG MUST be able to be reset to its factory defaults on command from a Remote Agent or the Local UI.

R9. The HG MUST automatically locally store its latest configuration prior to restoring the factory defaults. The HG MUST also be able to store this configuration in the Cloud.

R10. The HG MUST be able to restore its latest stored configuration on command from a Remote Agent or the Local UI.

R11. The HG MUST keep a local log of all firmware download attempts including the date, time, firmware version, and success or failure. This log MUST be accessible by the Remote Agent and the ACS.

R12. The HG MUST be able to delay a firmware download attempt when designated services are active.

R13.

The HG MUST support both complete image and modular firmware upgrades. Modular upgrades SHOULD support both individual modules and multiple modules being upgraded.



N° Requirement

R14.

The HG MUST log the date, time, and version number of each module download. If the download is unsuccessful, then the previous version of that module MUST be automatically reinstalled.

R15. The HG MUST be able to store and load a local rescue firmware version.

8.3 HG SELF-TEST

The HG needs to support the following self-test requirements, but there is no expectation that service

delivery will continue unimpaired, or indeed at all, during a self-test.

N° Requirement

R16.

The HG MUST support a representative hardware test. This MUST include CPU, memory, firmware and all physical interfaces and provide an overall and per category status.

R17.

The HG MUST support a representative software test that checks the integrity of software components and provides a report per component. This MUST as a minimum include a CRC check on a per module basis, and on the complete software image.

R18. The HG MUST support sending a Dying Gasp message to the WAN if connected via xDSL.

R19. The HG MUST support a daemon which monitors DSL line synchronization.

R20. All self-tests MUST be able to be initiated from a Remote Agent and the Local UI.

The HG SHOULD support a hardware button to activate the self-test.

R21. The HG MUST indicate the self-test result as a simple PASS/FAIL, for example by using a LED. This LED SHOULD be readily visible from the front of the HG i.e. not hidden behind or beneath the HG box.



8.4 HG HARDWARE AND PERFORMANCE MONITORING

N° Requirement

R22. The HG MUST measure and keep a DRAM log of its current, mean and peak CPU usage in % terms .

R23. The HG MUST measure and keep a DRAM log of its current, mean and peak memory usage in absolute and % terms. There MUST be a separate log for each different memory type.

R24.

The HG MUST measure and keep a log of the internal temperature of its case. The temperature sensor SHOULD be mounted on the inside of the HG case in a position expected to be near the top of the HG when installed as suggested by the vendor. The HG SHOULD measure and keep a log of the temperature of the CPU heat sink.

R25. The HG SHOULD be able to trigger a local and remote alarm when average DRAM usage exceeds a configurable % threshold.

R26. The HG SHOULD be able to trigger a local and remote alarm when the internal temperature exceeds a configurable threshold.

R27. The HG MUST support resetting the mean and peak values in Requirements R22, R23, and R24 with a single Remote Agent or Local UI command.

8.5 DUPLICATE ADDRESS DETECTION

N° Requirement

R28. The HG SHOULD be able to detect and store in DRAM duplicate LANside MAC addresses. The HG SHOULD be configurable to raise a remote alarm on the first detection of a given duplicate.

R29. The HG SHOULD be able to detect and store in DRAM duplicate LANside IP addresses. The HG SHOULD be configurable to raise an alarm on the Local UI on the first detection of a given duplicate.

8.6 SWEX SUPPORT



The Diagnostics architecture has led to the specification of a number of functional elements. However

these need to be controlled by a BSP-specific diagnostics system at least part of which needs to run on

the HG itself. SWEX allows such systems to be downloaded and upgraded as appropriate.

N° Requirement

R30. The HG MUST support the HGI SWEX as defined in [2], HGI-RWD008-R3 (HG Requirements for Software Execution Environment).

R31. The HG MUST be able to disable all SWEX applications except the diagnostics application itself, but only by means of a command from the Remote Agent or ACS.

R32. The HG MUST log the date, time, and version number of each SWEX module installed.

8.7 DIAGNOSTICS WEB PAGE SUPPORT

N° Requirement

R33. The HG MUST support the generation of Local Web pages to handle the troubleshooting interaction with the user.

R34. The HG MUST be able to intercept and redirect a pre-configured diagnostics URL to the local, or Cloud-based, diagnostics Web page.

R35. The HG MUST be able to display the Local Web pages automatically on detection of loss of WAN connectivity.

8.8 WAN PORT CONTROL

N° Requirement

R36.

Where the HG has an Ethernet WAN port, it MUST support configuration of that port to a specified rate (100 Mbps or 1 Gbps) from the Remote Agent or Local UI i.e. override auto-negotiation.

8.9 POWER SAVING



N° Requirement

R37. The HG MUST be able to disable all power saving features under command of a Remote Agent or Local UI for the duration of the troubleshooting.

8.10 SERVICE SELECTION

N° Requirement

R38. The HG MUST support the configuration of a single, unique service name for each service signature via the Local UI or ACS.

R39. The HG MUST be able to display a list of all the configured services on the Local UI.

R40. The HG MUST support the selection of a single service from this list via a Remote Agent or the Local UI.

R41. Selection of a service MUST overwrite any previous selection (so that only one service is being diagnosed at any one time).

R42. The HG MUST support non-service specific diagnostics, i.e. operations/counts etc. which are applied to all packets irrespective of service signature.

R43. This non-service specific diagnostics option MUST appear in the list of configured services as a selectable option with a user-friendly name e.g. ‘Any Service’.

8.11 SERVICE CONFIGURATION TESTING

N° Requirement

R44.

The HG MUST be able to display the following information related to the selected service on the Local UI and send this information to the Remote Agent.

Service ID

Service signature (number and type of all the constituent elements)

Queue number and type to which this service has been allocated.



N° Requirement

R45. The HG MUST be able to display the information in R44 for all other currently configured services on the Local UI and send this information to the Remote Agent.

8.12 DEVICE DISCOVERY

The purpose of Home Network device discovery and identification in this document is simply to provide

sufficient information to allow device presence and identity to be established, not to provide full

management capability of those devices. These identity requirements are therefore a subset of those

specified in R169-189 of [1].

N° Requirement

R46.

The HG, when acting as an UPnP Control Point, MUST be able to log and display on the Local UI the following information for each UPnP Device on the LAN. The fields are defined in the UPnP Device Architecture [6].

Information From UPnP discovery

Server

Information From UPnP description

DeviceType

FriendlyName

Manufacturer

ModelDescription

ModelName

ModelNumber

UPnPServer

ServiceType [1..n] (this is a list of ServiceType for each supported service)

R47. The HG MUST support Multicast DNS as per [7] (RFC 6762) and DNS-Based Service Discovery as per [8] (RFC 6763), in order to discover Apple devices.



N° Requirement

R48.

The HG MUST be able to keep a DRAM log of all LANside device connections and disconnections (both physical and logical). This log MUST contain at least the following

OUI-SN-Product Class

UPnP ID (where applicable) Device ID

Device OS (in the case of a PC)

IP address

Date and time of event

Running total of the number of connections

Running total of the number of disconnections.

This log MUST be enabled by default.

This log MUST be retained for a configurable time period (in days) of up to 30 days.

8.13 HG DISCOVERY

Although the main emphasis of this document is diagnostics based on the HG itself, making the HG

visible to PC-based network discovery mechanisms may also be useful.

N° Requirement

R49. The HG MUST support Microsoft LLTD responder functionality as per [9].

8.14 TOPOLOGY DISCOVERY

N° Requirement

R50. The HG MUST be able to display a graphical representation of all devices (device icon) and their connectivity on the Local UI.



N° Requirement

R51.

The connectivity map SHOULD include the following:

Device type

Device ID

Device OS (where applicable)

The connecting technology type (wireless, PLT, wired Ethernet etc.)

Link PHY rate

IP address.

8.15 CONNECTIVITY TESTING

N° Requirement

R52.

The HG MUST be able test the Layer 2 connectivity to all identified devices on the HN:

as a complete set

individually on command via a Remote Agent or the Local UI.

8.16 REACHABILITY TESTING

N° Requirement

R53. The HG MUST be able to test the IP reachability of all connected devices via a Ping test initiated by clicking on the device icon via the Local UI.

R54. The HG MUST maintain a Table of all locally DHCP allocated IP addresses.

8.17 SPEED TESTING

8.17.1 INTERFACE COUNTERS The following requirements support the monitoring of data rates on a per logical interface basis (i.e.

where there is more than one logical interface on a physical interface). This is specified for both service

specific and any traffic types.



N° Requirement

R55. All the counters in this sub-section MUST be available for each WAN and LAN interface logical (L2) interface.

R56. All counts MUST be available as the total number of packets per sample time, packets per second and kbps.

R57. Every counter MUST be reset upon reception of a specific, single command from the Remote Agent or Local UI.

R58. All counters SHOULD be individually resettable via a Remote Agent and the Local UI.

R59. The current value of all counters MUST be able to be read by a Remote Agent and the Local UI.

R60.

The HG MUST use a single configurable sample interval. The sample interval MUST be configurable from 1-60 seconds with 1 second granularity and SHOULD be configurable from 1-900 seconds. This configuration MUST be able to be done from a Remote Agent, the Local UI, and the ACS.

R61. The sample intervals of all counters MUST be synchronised.

R62. The HG MUST store in DRAM the last N results for the sample interval counters, where N is configurable from 1 to 2048.

R63. The HG MUST maintain a sample interval count of the number of sent packets with a single, specified service signature.

R64. The HG MUST maintain a sample interval count of the number of received packets with a single, specified service signature.

8.17.2 ACCESSING A NETWORK BASED SPEED CHECKER

N° Requirement

R65. The HG MUST be able to store the IP address of a network based speed checker and connect to it on command from a Remote Agent or the Local UI.

R66. The duration of the speed test MUST be configurable from a Remote Agent, the Local UI, and the ACS.



N° Requirement

R67. The default duration of the speed test MUST be 30 secs.

8.17.3 HG BASED SPEED CHECKER

N° Requirement

R68.

The HG MUST be able to intercept attempted access to the configured IP address of the network based speed checker and generate traffic locally which it sends to the requesting device. This local intercept MUST be able to be requested via the Local UI and a Remote Agent. The fact that it was a local speed check MUST be indicated in the results presented on the Local UI and to a Remote Agent.

R69. The duration of the speed test MUST be configurable between 5-30 seconds via the Local UI, Remote Agent or ACS.

R70. The default duration of the speed test SHOULD be 10 secs.

R71. The speed test rate MUST be able to be greater than the PHY rate of the highest speed LAN interface on the HG.

8.18 SERVICE CLASS MONITORING

The following requirements support the monitoring of the WAN, LAN and WLAN egress queues, and

apply to all such queues. The monitoring is on a per queue basis and so all services which use the same

queue will have their traffic counted. These are based on requirements R483-500 in the HGI Residential

Profile [1] but are not identical. The main difference is that the range of sample intervals is shorter to aid

more real-time diagnosis.

N° Requirement

R73. All the following counters MUST be provided for each WAN and LAN egress queue (including WLAN queues).

R74. Every counter MUST be reset upon reception of a specified single command from the Local UI or Remote Agent.

R75. The HG MUST determine which queues to monitor on the basis of the currently selected diagnostics service signature.



N° Requirement

R76. If the selected diagnostics service signature is ‘any service’ then the HG MUST monitor all queues.

R77. All counters SHOULD be individually resettable via the Local UI or Remote Agent.

R78. All counters MUST be reset when the selected diagnostic service signature is changed.

R79. All counters MUST be reset by a reboot of the HG.

R80. The current value of all counters MUST be able to be read via the Local UI and a Remote Agent.

R81. The HG MUST have a single configurable sample interval. The sample interval MUST be configurable from 1-900 seconds with a 1 second granularity from the Local UI, Remote Agent and ACS.

R82. The sample intervals of all counters MUST be synchronised.

R83. The HG MUST be able to store in DRAM the last N results for the sample interval counters, where N is configurable from 1 to 2048.

R84. The HG MUST maintain a running count of the number of dropped packets.

R85. The HG MUST maintain a sample interval count of the number of dropped packets.

R86. The HG MUST maintain a running count of the number of sent packets.

R87. The HG MUST maintain a sample interval count of the number of sent packets.

R88. The HG MUST maintain a running count of the number of bytes sent.

R89. The HG MUST maintain a sample interval count of the number of bytes sent.

R90. The HG MUST store the peak queue occupancy counted in packets and bytes.

R91. The HG MUST store the peak percentage queue occupancy.

R92. The HG MUST store the peak queue occupancy in packets and bytes for each sample interval.



N° Requirement

R93. The HG MUST be able to provide the peak percentage queue occupancy for each sample interval.

8.19 INSTANTANEOUS INTERFACE RATE MONITORING

N° Requirement

R94. The HG MUST be able to report the current downstream and upstream physical layer rate of the WAN interface via the Local UI and Remote Agent.

R95. The HG MUST be able to report the current downstream and upstream physical layer rate of any selected LAN interface via the Local UI and Remote Agent.

8.20 LONG TERM INTERFACE RATE MONITORING

These Requirements are intended to support the long term monitoring of the PHY rates of specified

interfaces. They allow a performance history to be built up which can be used in the diagnosis of

intermittent faults, or as part of a business decision as to whether to offer a certain service to a given

customer. These are identical to the requirements R518-520 in the HGI Residential Profile [1].

N° Requirement

R96. The HG MUST be able to monitor the downstream physical layer rate of designated LAN interfaces.

R97.

The HG MUST be able to generate and store locally in DRAM a historical measurement of the physical layer rate of each designated interface in the following form: the rate (Rhist) that was exceeded for x% of the previous t minutes.

R98. The HG MUST be able to send the Rhist value to the ACS when it changes and is less than the current WAN downstream PHY rate.



8.21 WIRELESS INTERFACE LOGGING

N° Requirement

R99. The HG MUST be able to measure and log in DRAM the noise level in a 20 MHz band on all wireless channels for any and all relevant spectral bands (i.e. 2.4 and 5 GHz).

R100. The HG MUST keep a time and date-stamped log of the wireless channels used.

R101. The HG MUST be able to determine on demand from the Local UI or Remote Agent the number of SSIDs on each wireless channel.

R102. The HG MUST be able to determine on demand from the Local UI or Remote Agent the SSID strings on each wireless channel that have not hidden their ID.

R103. The HG MUST be able to determine on demand from the Local UI or Remote Agent the security type of each SSID.

R104. The HG MUST be able to determine on demand from the Local UI or Remote Agent the RCPI value for each channel.

R105. The HG MUST keep a log of all unsuccessful attempts to connect to each SSID.

R106. The HG MUST support the disabling of any guest access SSIDs by a Remote Agent.

R107. The HG MUST log the wireless channels currently in use by the embedded HG access point.

R108. The HG MUST log the wireless channels currently in use by any other, (i.e. non-embedded) access points that it can detect.

R109. The HG MUST keep a log of all its configured SSIDs, and their security status.

R110. The HG MUST keep a log of all its currently active SSIDs.

8.22 MULTICAST

N° Requirement

R111. The HG MUST be able to count the total number of received multicast packets with a single resettable counter.



N° Requirement

R112. The HG MUST be able to determine the number of active multicast streams.

8.23 VOICE SPECIFIC DIAGNOSTICS

Where an HG contains an ATA it will have one (or more) voice codecs. The following counters need to be

available, on a per ATA basis for the codec in use (for that ATA)

N° Requirement

R113. The HG MUST be able to provide access to the following counters for each embedded ATA.

R114. The HG MUST reset all the counters for a given ATA at the start of every voice call.

R115. The HG MUST provide access to the count of the total number of voice packets sent, from the Local UI or Remote Agent.

R116. The HG MUST provide access to the count of the total number of voice packets received, from the Local UI or Remote Agent.

R117. The HG MUST provide access to the count of the total number of lost voice packets, using RTP sequence number tracking, from the Local UI or Remote Agent.

R118. The HG MUST provide access to the highest RTP sequence number received, from the Local UI or Remote Agent.

R119. The HG MUST provide access to the count of the total number early packets, i.e. packets arriving earlier than the maximum depth of the de-jitter buffer, from the Local UI or Remote Agent.

R120. The HG MUST provide access to the count of the total number of late packets, i.e. packets arriving after their estimated playout time, from the Local UI or Remote Agent.

R121. The HG MUST provide access to the count of the total number of invalid packets. i.e. packets with the wrong version number, sequence number or playout type, from the Local UI or Remote Agent.

R122. The HG MUST provide access to the mean value of the network jitter estimate, from the Remote Agent.



N° Requirement

R123. The HG MUST provide access to the current value of playout delay (microsecs) from the Remote Agent.

R124. The HG MUST provide access to the minimum value of playout delay (microsecs) from the Remote Agent.

R125. The HG MUST provide access to the maximum value of playout delay (microsecs) from the Remote Agent.

R126.

The HG MUST provide access to the count of the total number of resynchronisations, from the Remote Agent.

Note: a resync will occur when the sequence number or timestamp jumps, e.g. if the transmitter has changed or restarted the transmission and reinitialized the jitter buffer.

8.24 REMOTE ACCESS SUPPORT

N° Requirement

R127. All actions which can be initiated locally MUST also be available to an authenticated remote user, i.e. a Remote Agent.

R128. The HG MUST log the date and time of the most recent attempt by the user to use the self-care system. This data MUST be available to a Remote Agent.

R129.

The HG SHOULD be able to log any tests that were performed by the user, and their results and SHOULD be able to send the history of these tests to a Remote Agent for helpdesk support or offline analysis. This history SHOULD cover at least the previous 24 hours.

9 MANAGEMENT REQUIREMENTS

9.1 CWMP

The diagnostics capability will be managed using the Broadband Forum’s CWMP as defined in TRs 69 [3],

98 [4], and 181 [5] etc.. The HGI Residential Profile already contains a significant number of



management requirements, including management of the basic diagnostics capability that was

contained in that document. That needs to be extended to include management of the more

comprehensive set of objects resulting from the new capabilities defined here. This will be the subject of

a companion document which needs to be developed by the HGI, and then liaised to the Broadband

Forum to do the full specification of the Object Models.

An extended set of notifications is also required; these have been covered in the individual

Requirements Sections.

N° Requirement

R130. The HG MUST support all the management requirements in Section 8.6 of the HGI Residential Profile [1].

9.2 SWEX MANAGEMENT

N° Requirement

R131. The HG MUST support all the management requirements in Section 5.4 of the HGI SWEX specification [2].

R132. In the event of any conflict between the management requirements in the Residential Profile and the SWEX specifications, then the SWEX management requirements MUST take precedence.

10 REFERENCES 1. Home Gateway Technical Requirements: Residential Profile V1.01 - (HGI-RD001-R2.01, 2008)

2. Requirements for Software Execution Environment (SWEX) - (HGI-RD008-R3 HG, 2011)

3. CPE WAN Management Protocol - (TR-069 Amendment 4, Broadband Forum 2011)

4. Internet Gateway Device Data Model for TR-069 - (TR-098 Amendment 2, Broadband Forum 2008)

5. Device Data Model for TR-069 – (TR-181 Issue 2, Amendment 6, Broadband Forum 2012)

6. UPnP Device Architecture 1.0 (2008)

7. RFC 6762, Multicast DNS (2013)

8. RFC 6763, DNS-Based Service Discovery (2013)

9. Link Layer Topology Discovery (LLTD) Protocol Specification, Microsoft (2010),

http://www.microsoft.com/whdc/connect/rally/lltd-spec.mspx

10. Home Gateway QoS Module requirements - (HGI-RD027-R3, 2012)

http://www.microsoft.com/whdc/connect/rally/lltd-spec.mspx



<End of Document>