Home Gateway Technical Requirements: Residential Profile

0 0 Home Gateway Technical Requirements: Residential Profile Version.0 /0/00 Home Gateway Initiative 00 All Rights Reserved

0 0 PAGE LEFT INTENTIONALLY BLANK Page of

0 0 0 0 0 Table of Contents Table of Contents... Important notice, IPR statement, disclaimer and copyright... Acronyms... Definitions... Introduction and scope of the Home Gateway Initiative (HGI).... Cooperation with other bodies and initiatives... cope and Purpose of this document.... tructure of the pecification.... Definition of profiles and terms... ervices Overview and Use Case ummary.... Overview of Use Cases..... Broadband Connection..... Communication..... Fixed-mobile and ervice Convergence...... Mobile integration scenarios in the home...... Guest and Hotspot Access...... Using IM services from non-im enabled devices: IM proxy..... Home Office..... Entertainment & Information...... Audio content...... Gaming...... IPTV (real-time delivery)...... Extended IPTV (request and store IPTV)...... Media server..... Remote access..... Home Management & ecurity...0... Home surveillance...0... Home ecurity...0... Home Automation...0. Home Gateway General Requirements ummary...0.. Ease of use and simplicity...0.. ecurity...0.. Quality of service: unmanaged services / managed services...0.. Remotely managed gateway / home network...0.. Performance Monitoring and Diagnostics.... ervice Provider Role models..... Role model definitions..... Role model assumptions... HGI Reference Architecture.... End to End Network Architecture..... HG upply Model..... Integrated NT and HG..... WAN interfaces..... LAN interfaces..... Connectivity..... Qo..... Management..... Encapsulation and session support..... IP Addressing.....0 ecurity..... Fixed-Mobile and ervice Convergence... Page of

0 0 0 0 0.. Multicast support..... Remote Device Access..... Parental Control..... Messaging.... Moving towards a more IM like architecture..... IM-based remote access.... Parental control.... Guest and Hotspot Access.... Home Gateway Functional Overview..... Home Gateway Functional Blocks..... Interworking with IM and an NGN core...0. Home Networking Technologies and Architecture..... Home Network Architecture..... Home Network Connectivity..... Home Networking Technologies.... Management Architecture..... Device Management..... ecurity Management..... oftware Management and Upgrade..... Performance Monitoring and Diagnostics & Troubleshooting..... Local Management Application..... Multi ervice Provider upport..... Home Gateway Provisioning.... Quality of ervice Architecture..... Congestion Points..... Bridges and switches in the Home Network..... Basic principle of operation..... DCP and VLAN Usage..... Traffic Classification..... Upstream Classifiers..... Downstream Classifiers..... Transit classifiers..... Qo Mapping.....0 Upstream Queue structure..... Downstream and Transit Queue tructure...0.. Class Based Qo, essions and Policy...0.. DLNA coexistence...0.. Fragmentation and Classification..... Classification and NAT for WAN Ingress.... ecurity Architecture..... Firewall protection..... VPN Capabilities..... Encryption algorithms..... Code authentication / ignature..... Local Configuration ecured Access..... Remote access... Home Gateway Requirements.... WAN ide Interfaces..... Type - ATM over DL Interface (*)..... Type - Ethernet over DL Interface (*)..... Type - Ethernet WAN Interface (*)..... WAN Interface Combinations (+)..... PTN (FXO) Interface (+).... LAN side interfaces... Page of

0 0 0 0 0.. Wired..... Wireless..... Telephony interfaces.... WAN and LAN Networking Requirements...0.. WAN Connectivity and Addressing...0.. Routed Model and Local Area Networking upport...... NAT/NAPT...... IP Addressing schemes...... LAN-side DHCP requirements..... upport of Hybrid Model and Extensions..... ession Initiation and upport.... LANside Interoperability.... Guest Access and Wi-Fi Hotspot (+).... Management..... Northbound Interfaces..... General HG configuration and management..... Definition of the data model supported..... Diagnostics, notifications and alarms...... Notifications and logging...... Mechanisms...... Notification cases...0... tatistics and Diagnostics...... Mechanisms...... Defined diagnostics and statistics..... End device management...... Device Identification...... Activity discovery and Database management..... Local HG management user interface...... General...... Design guidelines...... Operator Portal User Interface link...... Contents and functionality..... Firmware management and updates...... General...... Firmware upgrades...0... Configuration...... Application Layer Gateway Management..... Multi-service provider management.... Remote End-Device Access..... Authentication and Authorization...... Web Based Approach (LM Remote UI)...... IM Approach (+, to be applied in conjunction with ection.. only).. Remote Access Configuration.... ervice upport..... ALGs..... Local IP devices registration..... IP non IM Communication ervices upport (+)..... IM communication services support (+)...... IM Protocol tack...... IM telephony user agent...... IM Interworking...... Local registration and local services support...... upport of call forking and call transfer inside the HN...... Messaging... Page of

0 0 0 0.. Multimedia ervices upport.... ecurity..... Parental Control (+)..... Firewalling...... Firewall management....0 Quality of ervice....0. Classification of traffic....0.. Requirements for Classification of packets received upon the WAN ingress....0.. Requirements for Classification of LAN-LAN traffic....0.. Requirements for Multi-field Classification packets received on the LAN ingress ports....0.. Requirements for Classification of packets received on the LAN ingress using information determined by DHCP...00.0.. Requirements for Classification of bridged packets received on the LAN ingress ports...0.0.. Requirements for Classification of internally generated packets...0.0. LAN-side VLAN support...0.0. Classification Rule ets...0.0.. Overview...0.0.. Requirements for Classification Rule ets...0.0.. Requirements for equencing Among Classification Rule ets...0.0. Overload Protection Mechanism...0.0. Qo Mappings...0.0.. Integrated Access Devices...0.0. Dropping/Congestion Management...0.0. Class Queue structure and cheduling...0.0.. Queuing into the WAN Egress port...0.0.. Queuing into the LAN Egress ports...0.0.. Example of Queuing Configuration...0.0. Requirements on Queue tatistics...0.0.. ervice class monitoring on a per queue basis...0.0. Requirements for Admission Control (+)...0.0.. BBUA requirements for CAC using IP signalling....0.. LAN Interface Capacity Monitoring....0.0 Qo Requirement Mapping to TR-0....0. Non-Integrated Device Requirements....0.. LAN Infrastructure Devices....0.. Non-integrated Ethernet Infrastructure Devices....0... Informative notes on et Top Boxes and VoIP Client Devices....0. DLNA Coexistence Guidelines.... Basic system features... References...0 Page of

0 0 0 Important notice, IPR statement, disclaimer and copyright The Home Gateway Initiative (HGI) is a non-profit making organization created to define guidelines and specifications for broadband Home Gateways. This document is the output of the Working Groups of the HGI and its members as of the date of release. Readers of this document must be aware that it can be revised, edited or have its status changed according to the HGI working procedures. The HGI makes no representation or warranty on the contents, completeness and accuracy of this publication. This document, though formally approved by the HGI member companies, is not binding in any part on the HGI members. IPRs essential or potentially essential to the present document may have been declared in conformance to the HGI IPR Policy and tatutes available at the HGI website www.homegateway.org. Any parts of this document may be freely reproduced (for example in RFPs and ITTs) by HGI and non-hgi members subject only to the following: HGI Requirement numbers not being changed an acknowledgement to the HGI being given in the resulting document. Trademarks and copyrights mentioned in this document are the property of their respective owners. The HGI membership list as of the date of the formal review of this document is: Wire, Inc., Atheros, Alcatel-Lucent, AVM, Belgacom, BeWAN, BT, Conexant, Deutsche Telekom, D, Echelon EMEA, ECI, Emotum, Ericsson AB, Fastweb pa, France Telecom, Fraunhofer EK, Freescale emiconductor, Gigle emiconductor, Huawei, IBM, InAccess Networks, Infineon Technologies AG, Intel, Intellon, Jungo oftware Technologies, KDDI, KPN, LEA - Laboratoire Europeen ADL, Legerity Inc., LG-Nortel Co Ltd, Linksys/Cisco, Marvell emiconductors, Microsoft, Mimos, Motive, Inc, Motorola, Netgear, Netopia, NTT, Philips, Pirelli Broadband olutions, PMC ierra, Portugal Telecom, agem, iconnect, iemens, phairon Access ystems, pidcom, upportsoft, wisscom AG, Telcordia, Telecom Italia, Telefonica, Telekom lovenije, Telekomunikacja Polska, Telenor, Teliaonera, Telkom ZA, Telsey pa, Telstra, Telus Communications Inc., Texas Instruments, Thomson, Tilgin AB, TNO, UEA Technologies Limited, Ubicom Inc., Vtech, ZTE, ZyXEL. Page of

Acronyms 0 0 0 AAL ACL AC ADL ALG ALL AN AP ATA ATF ATM BBUA BG BRA BP B CAC CBR CE CFB CFNR CFU CLF CLIP CNGCF Co CPE CWMP DA DECT DHCP DMZ DN D DCP DL ATM Adaptation Layer Access Control List Auto-Configuration erver Asymmetric Digital ubscriber Line Application Layer Gateway Application Layer Logic Access Network Access Point Analogue Terminal Adapter Architecture Task Force of HGI Asynchronous Transfer Mode Back to Back User Agent Business Group of HGI Broadband Remote Access erver Broadband ervice Provider Business upport ystem Call Admission Control/Connection Admission Control Constant Bit Rate Consumer Electronics Call Forwarding on mobile customer Busy Call Forwarding on No Reply Call Forwarding Unconditional Connectivity session Location and repository Function Calling Line Identification Presentation Customer Network Gateway Configuration Function Class of ervice Customer Premises Equipment CPE WAN Management Protocol Destination Address Digital Enhanced Cordless Telecommunications Dynamic Host Configuration Protocol De-Militarised Zone Domain Name ystem Downstream Differentiated ervices Code Point Digital ubscriber Line Page of

0 0 0 DVB Digital Video Broadcasting EAP Extensible Authentication Protocol ED End Device EDR (Bluetooth) Extended Data Rate EU End User EUD End User Device FTTB Fibre To The Building/Business FTTCab Fibre To The Cabinet FTTH Fibre to the Home FXO Foreign exchange Office FX Foreign exchange ubscriber HG Home Gateway HGI Home Gateway Initiative HGW Home Gateway and Home Network Architecture Working Group of HGI HN Home Network HTTP HyperText Transfer Protocol IEEE Institute of Electrical and Electronics Engineers IGMP Internet Group Management Protocol ILMI Interim Local Management Interface IMPI IP Multimedia Private Identity IMPU IP Multimedia Public Identity IM IP Multimedia ubsystem IP Internet Protocol IPv Internet Protocol version IIM IP Multimedia ervices Identity Module IP Internet ervice Provider ITU-T International Telecommunication Union Telecommunication standardisation sector LTP Layer Tunnelling Protocol LAN Local Area Network LF Location Function LM Remote UI Local Management Remote User Interface MAC Media Access Control MPEG Moving Picture Expert Group NAPT Network Address and Port Translation NAT Network Address Translation NGN Next Generation Network NTP Network Time Protocol Page of

0 0 0 OAM O PCF PCP P-CCF PIN PLT POT PPP PPPoA PPPoE PPTP PTN PVC PVR Qo RCE RM RODM A DO IP NMP OHO P ID TB UI UPnP VA VCI VDL VLAN VoD VoIP VP VPI VPN Operations, Administration & Maintenance Operations upport ystem Parental Control Function Parental Control Profile Proxy-Call ession Control Function Personal Identification Number Power Line Transmission Plain Old Telephone ervice Point-to-Point Protocol PPP over ATM PPP over Ethernet Point to Point Tunnelling Protocol Public witched Telephone Network Permanent Virtual Connection Personal Video Recorder Quality of ervice Remotely Configurable Equipment Remote Management ystem Remote Operations and Device Management group (of HGI) ource Address tandards Development Organization ession Initiation Protocol imple Network Management Protocol mall Office Home Office ervice Provider ervice et Identifier et Top Box User Interface Universal Plug&Play Value Added ervice (equivalent to Managed ervice) Virtual Channel Identifier Very high speed Digital ubscriber Line Virtual Local Area Network Video on Demand Voice over IP Virtual Path Virtual Path Identifier Virtual Private Network Page 0 of

WAN WEP WPA WRR XCAP Wide Area Network Wired Equivalent Privacy Wireless Protected Access Weighted Round Robin XML Configuration Access Protocol Page of

0 0 0 0 Definitions Access Point: connection point where devices using the same link layer technology could be connected to the home network. It can be part of the HG or a separate box providing an integration point for non-common technologies Bridge: link layer function connecting two or more HN segments sharing the same data link layer. For management purposes it may also have an IP address Global usage scenario: As the HG needs to support several usage scenarios at the same time, the global usage scenario describes a scenario where several single usage scenarios are happening at the same time o Example Dual play: Television over broadband + Voice communication using an analogue phone Home Gateway: device connecting the HN to the Internet and ervice Platforms LM Remote UI (Local Management User Interface): UI (typically, but not limited to, a Web-based) to let a user manage the RM client on the gateway from a device on the HN Managed Device: device that has a remote management client that communicates directly or indirectly (via the HG) with a remote management server Managed service: A managed service is a service for which the BP provides preferential treatment (that can include Qo...) for the customer. The service can be a service offered by the BP or operated by the BP on behalf of a third party. A managed service can also be local: watching a video on a PC recorded on the IPTV TB; as explained in the IPTV PVR use case. Managed services do not necessarily involve use of the remote management system; management only means that the operator has taken some responsibility for the service (e.g. its Qo treatment) in order to provide the appropriate quality of experience. Per class Qo management: Qo treatment based on a service classes rather than individual flows. Relative Qo: This term is used to refer to a traffic delivery service without absolute bounds on the achieved bandwidth, packet delay or packet loss rates. It is used to handle certain classes of traffic differently from other classes. Remote Management ystem (RM): is the management entity which includes the Auto-Configuration erver capabilities but provides additional management functionalities. The RM include resource and device inventory, event notification and alarm management, diagnostics and troubleshooting. Unmanaged Device: device that does not have a remote management client or that does not communicate directly or indirectly (via the HG) with a remote management server. Use case: Description of a general user need. It contains the context of usage behaviour that meets the need and serves as an umbrella scenario. o Example: Voice communication Usage scenario: The usage scenario is a real scenario demonstrating the use case. o Each scenario provides details about the user (attitude, knowledge, habits, etc.), the use context (social factors, environment, information requirements, etc.), and a solution that supports or enables the particular use. o Example: Voice communication using an analogue phone. Page of

Unmanaged ervice: An unmanaged service is a service for which the BP has no commitment to the customer (especially in terms of Qo). Page of

0 0 0 Introduction and scope of the Home Gateway Initiative (HGI) Home connectivity has evolved dramatically over recent times. From the initial simple voice service, home services evolved in the 0s to include things such as fax and video text, with the 0s seeing the advent of mass-market Internet access via dial-up modems. At the start of the st century, the world has entered the broadband era. Network operators have deployed technology that offers much larger bandwidths, such as DL, cable or fibre-based access systems. The Internet has been a major driver for the evolution to broadband, creating a new experience for the customer and offering him new services such as email and Internet browsing, and online versions of existing services such as digital photo labs, ticket booking etc. The next generation of broadband services (triple or even multiple-play ) has created a set of new requirements for the Home Gateway, namely: the need to manage the Home Gateway, and to a lesser extent, the home network and the devices beyond the Home Gateway allowing the right device or application to connect to the right service platform with the right service class / Quality of ervice unifying device capabilities in order to offer customers a better integrated home environment. Due to the lack of suitable off-the-shelf and standardized products to support this new, endto-end network and service model, several major Telecom Operators have recently worked separately with a very small number of Home Gateway vendors to specify and develop suitable Gateways. However, such custom development is not cost-effective for either operators or vendors. It became apparent that many operators had similar service aspirations, and so were asking for similar equipment. Therefore in December 00, nine Telecom Operators founded the Home Gateway Initiative to agree on a common Gateway specification. The intention was to involve the relevant vendor community (i.e. vendors of gateways, chipsets, software, devices and transmission systems) so that the specifications would also be pragmatic and could be realized in a costeffective manner. The aim of HGI is therefore to specify a small range of low cost, high capability Gateways which will provide multi-service communication support for the residential and OHO environments. While an end-to-end network view has been taken, the specifications mainly focus on the Home Gateway device which sits between the access network and service platforms on one side, and the in-home networked devices and applications on the other. 0. Cooperation with other bodies and initiatives The Home Gateway Initiative does not wish to become a new, long-term de facto standardization body. Its task is to agree a set of functional requirements for a Home Gateway, wherever possible re-using or referring out to existing specifications. An important aspect of the work is to identify gaps and inconsistencies in or between existing specifications. The HGI will publish its own specifications, but will work alongside other DOs to ensure that issues are addressed in the most appropriate body, that there is no unnecessary duplication of effort, and that the HGI specifications are downstreamed in the most appropriate way. Page of

0 cope and Purpose of this document. tructure of the pecification The HGI starts with prioritized topics proposed by the HGI telecom operators from which specific use cases and business requirements are derived. These are then used to create a set of high level requirements for the HG and, where appropriate, other parts of the network. A summary of the Business Working Group output can be found in ection. The Architectural Requirements (from the Architectural Task Force and detailed architectures derived by the Working Groups) are covered in ection. The Technical Working Groups (Home Gateway and Home Network Architecture, Quality of ervice, Remote Operations and Device Management) then produced detailed sets of formal functional requirements which are contained in ection. 0 0 0. Definition of profiles and terms The HGI is based on the recognition that there is a high degree of consensus among operators about the functionality required in an HG. However the intention was never to produce a rigid specification for a single box, for reasons: there still needs to be the opportunity for vendor product differentiation there is likely to remain a market need for more than one class of HG, e.g. Baseline and Enhanced. Note however that going to too many classes would defeat the purpose of the HGI, and that even a Baseline variant would still be an HG with multiservice support, as opposed to a simple DL modem/router. This specification addresses these needs in the following way. The majority of requirements are all expected be present in a Baseline HG. These are written as MUTs, and denoted by an in the rightmost column of ection. Note that MUT and the designation are not synonymous for the reason given below. In addition to the Baseline requirements there are types of options. The first type, Individual options, are contained within a ection consisting largely of Baseline requirements. These are written as HOULDs, and marked with a + in the rightmost column. They usually (but not always) follow a Baseline requirement and increase the basic requirement in some way (e.g. the number of ports or instances of a function). These options are the ones which vendors might choose to implement to differentiate their product, but would not be sufficient to change the class of device. The other type of option is an Optional ection. This specifies additional (as opposed to enhanced) functionality. An Optional ection is a set of requirements that contains both mandatory and optional requirements and should be considered in its entirety. Optional ections as a whole are marked with a + in the ection heading. + ections add functionality that would only be needed to implement specific services or to support certain network architectures. Within these Optional ections, the essential requirements are written as MUTs, and denoted by *, whereas the associated enhancement options are written as HOULDs and marked by +*. There has been no attempt to indicate which combination of Optional ections would be expected to be present in an Enhanced HG, as it is hard to get consensus on this, and in some cases there are alternative types of additional functionality which serve a similar purpose. In the latter case it would not make sense to implement both of the alternatives. uch ections are marked by +A, with the reference to the alternative ection also being given. The definitions of MUT and HOULD in this document are therefore as follows: Page of

0 MUT A functional requirement which is based on a clear consensus among HGI ervice Provider members, and is the base level of required functionality for a given class of HG. MUT NOT A function which is prohibited by the specification HOULD 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). Notes: These definitions are specific to the HGI and should not be confused with the same or similar terms used by other bodies. These terms only have these meanings when capitalized and used in the Requirements ection of this specification (ection ). Page of

0 0 0 0 ervices Overview and Use Case ummary. Overview of Use Cases The HGI use cases are based around a typical family of four people named the Martins. Mr. Martin purchases his broadband service from a Broadband ervice Provider (BP). The BP is responsible for the operation of the broadband access network and the HG itself. The BP can offer several services over the broadband access. The use cases also take into account the evolution of new technologies in the operator networks, e.g. IM is slowly being introduced into core networks and all the HGI operators are looking at IM as the target architecture. As part of every use case, enhanced customer support has been taken into account by providing diagnostic tools... Broadband Connection Installing a broadband modem/router and its associated Internet connection is still a complex experience for most users. Thus, one use case concerns Mr Martin installing a new broadband connection with Internet service, and sharing that connection between several PCs. Another use case concerns Mr Martin purchasing additional services through his BP which require different versions of HG software. A further use case is about parental control. Mr Martin sees that several devices are connected to the Internet and he wants to ensure that the appropriate parental control and firewall functionalities are applied. Mr Martin s Internet services have evolved to a multiple service environment (with IPTV, voice over IP etc.) and so the HG needs to support a fully featured home network where devices can interact on a single logical home network. The last usage scenario of this type covers the situation when a customer needs to replace the HG in the case of malfunction, or when he wants to migrate to another access network type... Communication Voice is still the main means of communication. Thus, more and more BPs are offering voice services over IP as part of their broadband service bundle. Users expect this service to be as easy to configure and use as their current POT service. The basic use cases cover the connection of a legacy analogue phone to the HG, and of IP phones used for VoIP. The first communication use case concerns Mr. Martin using an IP phone on his home network to connect to the BP s VoIP (Voice over IP) service with plug and play mechanisms. The next use case is about Mr. Martin using a legacy analogue phone or fax to connect to the voice port of his Home Gateway. The last use case adds a videophone for use of a video communication service. Advanced use cases have been devised which extend this basic VoIP functionality to provide Mr Martin with an enriched calling experience i.e.: Call forwarding: Mr Martin is able to pick-up a call from any VoIP device with voice capabilities (thus maintaining a consistent user experience with analogue telephony). Mr Martin can also perform voice call transfer within the home. Distribution of the caller ID to multiple devices throughout the home, e.g. TV, PC. Page of

0 0 0 0 ession-based content sharing. After establishing a voice communication channel between two locations, Mr Martin wants to share content (e.g. photo, video ) either from the web or local storage with another home. Messaging. Mr Martin is able to receive a message on different devices in the home (TV, PC or phone), based on an IM messaging service... Fixed-mobile and ervice Convergence... Mobile integration scenarios in the home Mr Martin brings a mobile phone into the home and uses the Wireless LAN (Wi-Fi) to connect to his mobile services. Three Fixed-Mobile convergence scenarios have been studied: UMA (extending the mobile reach into the home), a G/Wi-Fi dual phone based on a IP stack located in the phone and evolution to a IP-IM phone.... Guest and Hotspot Access Mr Martin s friend visits him and wants to connect a nomadic device (e. g. laptop computer) to the Internet. This use case is about Mr Martin allowing such a guest to connect to the Internet using Mr Martin s broadband connection, without interfering with Mr. Martin premium services and at the discretion of Mr Martin. The HG can also be enabled to allow unknown guest access by acting as a hotspot.... Using IM services from non-im enabled devices: IM proxy Mr Martin is now a customer of the next generation of IM-based services offered by his BP. This use case is about Mr Martin using non IM-capable terminals via an IM-enabled HGI HG to gain access to IM services. This functionality provides the support needed to connect legacy, non-im equipment to the home network. It also provides presence information, e.g. informing the IM core when the user is at home... Home Office Working from home is more and more common today with broadband. This usage scenario describes Mr. Martin using a secure connection to his office. He expects to have a certain Quality of ervice (Qo) for his voice and data service, and to have preferential treatment over other members of the family using other broadband services. However Mr Martin still wants to be able to use local network resources like the family printer... Entertainment & Information Access to entertainment content such as IPTV and IP radio is one of the largest residential markets and it is thus often offered as part of a broadband package.... Audio content The use case deals with audio content and a new way to distribute audio via broadband. Mr. Martin expects to be able to listen to a personal radio station (including a compilation based on his musical tastes) with the same quality of service as his current FM radio service.... Gaming This use case is about using the broadband connection for online gaming. Mr Martin s children want to connect their new networked game consoles and use an online gaming service. The use case considers these different situations: Ethernet connected consoles for online gaming, Wi-Fi multiplayer gaming with Wi-Fi guest accounts for on-line gaming, and Ethernet connected PCs for on-line gaming using additional applications such as instant messaging and VoIP. Page of

0 0 0 0... IPTV (real-time delivery) IPTV is a managed service defined as delivering broadcast quality TV over IP. IPTV also allows watching multiple streams (e.g. tandard Definition video channels over an ADL line) with simultaneous High Definition video distribution within the home. The focus is on network and service connectivity issues and not on the service layers; the HGI addresses the delivery of IPTV services, but currently excludes the involvement of the HG in DRM and/or descrambling of IPTV. Multiple IPTV channels need to be simultaneously accessible by different members of the Martin family from different set top boxes. There are the following additional scenarios: free IPTV (e.g. public service or sponsored), pay IPTV (e.g. premium content or pay-per-view), multiple family members viewing IPTV simultaneously and viewing content from a Video on Demand (VoD) service. Another use case describes viewing a previously recorded movie. The movie was recorded on the main et Top Box (TB) but is being viewed on a device other than the TV, that is physically connected to that TB. The PVR use case also takes into account advanced functions such as VoD trickmodes (play, pause, fast forward) offering Mr Martin a DVD-like experience, PVR-based timeshifting of broadcast IPTV, PVR based scheduled recording. The PVR functionality can be placed either in the home network, or in the BP s network. Another scenario addresses an IPTV interactive service where interaction is happening at the same time as Mr Martin is watching his IPTV program. This includes new types of services such as tele-voting. Finally, the use of multiple devices (TV/TB, PC, PDA, multiservice mobile phones) to deliver free-to-air unprotected content to Mr Martin and his family members at the same time is covered.... Extended IPTV (request and store IPTV) Whereas IPTV can be thought of as just broadcast TV over IP, a new experience can also be offered using the TV to view stored podcasts. One use case of this type is about TV video content being downloaded to the TB both for on-demand and scheduled download (streaming / file transfer). Another use case is about extended IPTV multimedia where Mr Martin can consume or manage TV content from TV content service providers outside the home, or consume or manage video content from local devices.... Media server This scenario covers the Home Gateway supporting a media server (a device storing photos, videos, music, etc.) by delivering media content to the different multimedia devices in the home... Remote access Remote access to home devices and content is one of the latest consumer market trends. Two use cases have been developed: Remote access for recording video content. Mr Martin accesses his Personal Video Recorder (PVR) to initiate a recording remotely. Accessing content stored in the home: Mr Martin can upload/download photos or videos from local storage (e.g. PVR, networked hard disk) from a remote location. The Home Gateway is required to protect access to the home network resources. Page of

0.. Home Management & ecurity Users want to be able to manage their digital home and be in control of their environment.... Home surveillance This use case details Mrs. Martin being able to check, via a web camera, that her children have returned home while she is still in her office.... Home ecurity The home security usage scenario is about Mr Martin using an intrusion detection and alarm system provided over broadband.... Home Automation Two use cases were developed. One that allows Mr Martin to remotely control home appliances, and another that allows Mr Martin to authorize his gas or electricity company to access the home network in order to take a meter reading. 0 0 0. Home Gateway General Requirements ummary This section details some key requirements and concepts developed in the HGI business group that illustrate the above use cases... Ease of use and simplicity The Home Gateway, home network and associated devices and services must be easy to install and configure. Zero-touch configuration and plug and play are key concepts when designing services and devices that will work in the HG eco-system. Appropriate tools for end-users and operators must be made available... ecurity The Home Gateway provides security functions including firewalls, access control and personal monitoring, that makes the home user feel secure against threats that originate on the Internet... Quality of service: unmanaged services / managed services The HGI considered Quality of ervice (Qo) to be one of the first issues to be tackled and so derived a set of business requirements around Qo. A managed service is defined as a service for which the service provider is able to give preferential treatment to the customer s traffic. IPTV and Voice over IP are two such services. Unmanaged services are services for which the service provider has no commitment to the customer (especially in terms of Qo). Examples are peer-peer applications, and general LAN flows within the home. Other examples of services supported included gaming and home working. As a consequence, these unmanaged services can become managed... Remotely managed gateway / home network The HG must support a remote management system to enable remote operations and customer care procedures and to enhance and enable the provisioning of managed services at home. Therefore, the HG needs to be a managed device. In addition, a managed home network is needed to deliver some managed services. The managed network contains managed devices. The managed home network must coexist with home network segments and terminals that are not managed. The interaction between the two networks Page 0 of

or sections (that in practice cannot be simply physically separated) will be controlled and monitored with the support of the HG... Performance Monitoring and Diagnostics The HG must provide a performance monitoring function. The expected approach requires that an action is taken only when a problem is reported by the customer, but then it must be possible to diagnose the problem, i.e. reactive rather than proactive mode. Operators must be able to monitor service performance. 0 0. ervice Provider Role models.. Role model definitions The HGI model is based on the following roles: The Access Network Provider (ANP) takes responsibility for operating the access network active equipment. The ANP can provide layer bitstream connections to BPs. The Broadband ervice Provider (BP) takes responsibility for operating the IP network, including the HG. The BP provides IP connectivity to APs. The BP often provides Internet access to end customers as part of his broadband IP connectivity service. The BP would also be responsible for the IM infrastructure deployed in the HG. The Managed Application ervice Provider (Managed AP) takes responsibility for operating an application, and has a relationship with the BP that allows it to benefit from Qo, multicast, or other advanced network-related features. The Unmanaged Application ervice Provider (Unmanaged AP) takes responsibility for operating an application but does not benefit from Qo, multicast, or other advanced networkrelated features... Role model assumptions The HGI assumes that there is only one BP per customer as there is a need for a single customer facing entity capable of managing the network, Qo and troubleshooting. Multiple APs (both Managed and Unmanaged) may offer their applications on top of the broadband connectivity provided by the BP. Page of

0 0 HGI Reference Architecture. End to End Network Architecture Although the HGI has largely been driven by the Use Case approach, most Network Providers have some more general architectural requirements, and these also need to be taken into account. uch requirements may arise from a need to continue to support existing network features, a view of the overall topology and connectivity required, or the likely architectural evolution (e.g. towards IM). This aspect of the requirements was covered by an Architectural Task Force (ATF). The ATF also translated the business group s (Use Case) commercial requirements into high level technical requirements. The starting point for the ATF work was the overall architectural reference diagram which is shown in Figure. The key features of the diagram are: Multiple service edges which do not connect to a single service aggregation point e.g. a BRA. This has implications for L connectivity and Qo control upport for multiple service providers (APs) A single management entity at any one time controlling the HG (operated by the BP) Qo control via the Remote Management ystem (RM) (see ection.), not directly from a network Qo Manager The HG operating as both a router and a bridge Local turnaround of in-home traffic in the HG upport for remote access to devices on the HN upport for end-device management (both via the RM and not via the RM) upport for the delivery of messages to a variety of end device types upport for intra-home voice Guest access support via Wi-Fi Page of

Remote Access O O Home Environment BP Domain RM NBI Internet 0. RAD Mgmt Qo POT AP BRA Access and Agg 00BaseT Hotspot P AP DL Fibre Ethernet M HG UB M 0 0 Key to the figure: L+.. HG upply Model L 0. Figure. End to End Architectural Model (Unknown) Guest Access M = Managed Device; RAD = Remotely Accessible Device It is assumed that the Home Gateway is provided and managed by the BP although a few mechanisms have been provided which are appropriate to a slight extension of this model in which the Home Gateway is purchased (from a retail outlet) by the customer by selecting it from a list of supported Home Gateways provided by his BP... Integrated NT and HG In most current deployments the HG is an integrated device which includes the appropriate WANside technology. However in some environments, and with the increasing move to fibre based access, the WAN interface may be contained in a separate NT. Optional support for a WAN 00BaseT/GBE interface has therefore also been included. NOTE: The following ections contain a summary of the high-level architectural requirements. The detailed technical requirements are given in ection... WAN interfaces ADL ADL+ VDL Ethernet (00BaseT/GBE) FXO Page of

0 0 0 0.. LAN interfaces Wired Ethernet Wireless (0.a/b/g/n) UB.0 slave and host ports Telephony interfaces (DECT, FX, IDN).. Connectivity Map services into the appropriate L pipe to reach the correct service edge node and/or provide connectivity to different APs upport for multiple BRAs Allow direct connection of other access technologies to end-devices imultaneous routing and bridging upport direct data connectivity (i.e. not via the Access network) between in-home devices. Provide local PBX (Private Branch exchange) functionality without requiring the signalling and media to traverse the Access Network upport secure, Wi-Fi based guest access to provide (e.g. Internet) connectivity for both known and unknown guests (see ection.) No direct connection between guest access and the Home Network.. Qo upport downstream Qo, upstream Qo, and prioritising intrahome traffic with respect to Access Network traffic. upport the Qo remarking of LAN-side traffic Provide a local (i.e. in the HG) Connection Admission Control (CAC) function for IP based voice Provide a means for the End User (EU) to associate devices with a Qo service class Provide locally generated Qo classifier to support remote access (as a transient service) Only allow user Qo configuration via profiles managed via the AC Provide congestion statistics on all queues Co-existence with other, in-home Qo schemes, e.g. DLNA Provide differentiated, service class-specific Qo for both the home and guest user... Management Only allow a single RM per HG at any one time upport RM selection by the HG Manage end-devices (including UPnP) devices as well as the HG itself Remote firmware download Configuration changes without requiring a complete firmware download.. Encapsulation and session support Terminate, originate and transparently pass PPP sessions upport both PPP encapsulated traffic and non-ppp encapsulated traffic Trigger PPP sessions on the basis of LAN-side activity.. IP Addressing upport PPP and DHCP based IP address allocation Page of

0 0 0 0 upport end-devices which have a static, public IP address upport different IP address schemes and subnets on the same physical LAN port, and on different LAN ports upport different IP address schemes and subnets on the WAN port upport IPv with and without NAT/NAPT (simultaneously) upport for multiple WAN-side IP addresses..0 ecurity The management system and HG both need to be authenticated HG authentication must be non service specific upport a specified (and updatable) list of ALGs Provide a Firewall which is remotely configurable by the BP but which must not be applied to Guest access Provide a unique (gateway) hardware ID which can be remotely read upport different classes of user with regard to management access rights Pairing is required for devices connected through a shared (physical) link upport IM-based authentication Provide a proxy function for devices with no IM capability.. Fixed-Mobile and ervice Convergence upport of non-im services based on IP Personalised and non-personalised service support hare a public IM ID between non IM devices The HG must have its own unique IM ID upport individual and group identities upport IM authentication Terminate a limited set of IM services in the HG to support legacy non IM devices such as some phone types upport UMA passthrough Presence support by association with a mobile phone.. Multicast support Multiple in-home devices (in a given HN) able to join the same multicast stream IGMP snooping on all LANside interfaces Ability to support L conversion of multicast to unicast traffic (for shared medium home network technologies).. Remote Device Access upport for accessing data on and controlling end devices not only via the AC ecure remote access to authenticated entities not including content encryption Multiple mechanisms for authenticating remote access with different security levels to allow a security breach to be remedied ACLs to manage remote access Remote access logging.. Parental Control There are different types of Parental control: Restricting access to certain types of content, or sources of content (specific URLs) Page of

0 Restricting the use of specific devices (e.g. a particular PC) or types of device (e.g. networked Games machines) either completely, or on the basis of application type and/or time of day. The HGI decided to completely separate these two, and to provide support for the latter (in the HG), but not the former, on the grounds that this would place an excessive maintenance burden on the HG (e.g. to keep the blacklists updated), and would mean establishing the identity of individuals, rather than machines. The requirements on Parental Control therefore become: Device, time of day and application type control with no explicit user awareness Local configuration only, by the local administrator AC override for troubleshooting purposes Parental control must not be applied to guest access (ee ection. for further detail)... Messaging tore and forward and transparent messaging (e.g. IM, IP, M) support Message delivery to a variety of device types 0 0 0. Moving towards a more IM like architecture Most of the HGI operators are moving towards an IM oriented architecture. However they also have to take into account their legacy networks and services, and the fact that not all services are necessarily best delivered over an IM infrastructure. Therefore this migration has not been rapid and ultimately the pace will be dictated by whether or not there is a business case to support it. Various IM upport capabilities have however been included, e.g. IM based authentication (IIMs) and identity management. There is also the concept of the HG acting as a proxy so some IM services can be delivered to legacy devices. In certain areas, notably Qo, the HGI approach is somewhat at variance with that of IM, although the latter still needs considerable work before it seriously addresses the Access Network and HG. The reason for this is that IM comes from the mobile world where most services are session based and revenue generating, and network resources are scarce and expensive. These are all far less true in a broadband access network. There are some moves towards a more IM like Qo approach with the addition of some limited CAC functionality, but it is believed that the current HGI Qo approach is well suited to the types of services and access networks which are currently being deployed... IM-based remote access Figure shows a high level architecture using IM to enable Remote Access to home devices. The device types of interest include both UPnP and non-upnp devices. Page of

IM Control plane IM Media plane UPnP/DLNA. IP INVITE (IM Control Plane) IM Network non- UPnP Mobile devices Home Gateway. ession (IM Media Plane). IP INVITE Remote Device Figure High level IM based Remote Architecture: overview The principle of IM based Remote Access is that IM control plane is used to route the INVITE message to the HG and to set up the session on the IM media plane between the Remote Device and the HG. The architecture uses an IM/NGN infrastructure to deliver managed remote access services end-to-end with different requirements on Qo, e.g. real-time IPTV streaming (place shifting) versus background upload of JPEG pictures 0 0. Parental control The HG contains a Parental Control Function (PCF) and a Parental Control Profile (PCP). The PCP is the set of restrictions in the HG limiting access to home network attached users. The PCP does not apply to guest access users. The PCF can be activated and de-activated by the AC (for troubleshooting purposes), but is managed locally. The PCP is based on device-id, device type, time of day, day of week, and application type. The PCP is managed by the home parental control administrator. All other parental control restrictions such as content or site categories, and those which depend on knowledge of the user, are beyond the scope of the HGI. These are assumed to be addressed via a separate, network based parental control service which is totally independent of the functions described in ection... The only requirement on the HG to support such an additional service is being able to set the URL of the Parental Control Proxy related to this additional service in the HG management data base. Page of

Home Gateway ervice request Guest Network AC Logging ettings Filtering PCF ervice request Home network Enable/ disable Activate /deactivate Home administrator PCP () settings settings Figure. Parental control scenario 0 0. Guest and Hotspot Access While, the HGI is primarily concerned with supporting the family of users associated with the HG owner at their home location, nomadic access is likely to become increasingly important, and this requires the nomadic user to be able to get Broadband access, normally via some kind of Wireless access. This can obviously be done via a commercial Wireless hotspot, but the coverage of these is still fairly limited, and the services that the user may wish to use in such an open environment may also be limited. Any given HG/access link is likely to be idle or less than fully utilized for a large proportion of the day. This raises the possibility of using some of this capacity for nomadic Guest Access. There are distinct types of Guest, both of which need to be supported: Those who are known to the HG owner, and physically present within the home Those who are not known to the HG owner and are outside the home The key requirements of such a service are: Ensuring the security and integrity of the HG and HN, and its stored data, information and content so that it cannot be compromised by a Guest user. Ensuring that the HG owner s services get the appropriate priority, but without completely starving the Guest User. Ensuring that Guest services which require Qo (in particular voice) can get the appropriate priority, but again without adversely impacting the HG owner s services. The Guest Access Architecture is shown in Figure. Guests are separated from the Home Users by being on separate IDs. The unknown guest uses a broadcast ID, and there is no data encryption at the Wireless layer. The unknown guest can only connect to a commercial hotspot service provider. This could be achieved by a (L) tunnel from the HG to the hotspot AP. Traffic is steered into the tunnel on the basis of the appropriate ID. Traffic arriving in the tunnel is Page of

0 given the appropriate ID. No traffic is allowed to be bridged between different IDs, thereby protecting the HN from the guest user. Guest access can be identified as a service on the basis of ID, tunnel address, packet length etc, and so can have a service signature in the same way as non-guest access. The relative priority of guest and non-guest access, including support for guest voice, can be managed by making this part of the (static) Qo configuration of the HG. This type of access requires the guest to have a hotspot account, and these are often charged on a per minute basis. For known guests e.g. friends or visiting relatives, another type of access may be relevant. Here the guest actually uses the HG owner s BP, but again the traffic is kept away from the rest of the Home Network by the use a separate ID. The data is encrypted, and the ID might not be broadcast. To ensure that access is limited to known guests, and those within the home, pairing of the guest device with the HG is required. This could be done using the simple connect mechanism which requires a button on the guest device and the HG to be pressed within a few seconds, and/or the ID and WEP key values being supplied to the guest by the HG administrator. hared L connection ID Access BP BRA and Agg HG ID ID Known guest Hotspot P L tunnel Unknown guest Figure. Guest Access Architecture 0. Home Gateway Functional Overview.. Home Gateway Functional Blocks Figure illustrates (without describing the implementation) the functions of the HG including the WAN and LAN protocol stacks, the data, control and management planes, the L/L switching and all the possible enablers. Page of

Data plane Control Management UB Host I/F UB Host int. Enablers Common devices Power I/F Powering Discovery and control Maintenance FXO I/F PTN int. Performance processing IM and identity handling Access control (parental) Hotspot processing ecurity Remote access Appl. Layer Gateways i-ata FX I/F Data interoperation Control interoperation L Management interoperation HG-MIM L L L L Qo handling CAC Firewalling Access Auth. L L L L IP address L IP IP witching Private IP address L IP L L L WAN I/F L ETH PHY ETH witching L ETH L - ETH VLAN PHY (LAN I/F) L L Network side stack User side stack 0 Figure Detailed HG block diagram.. Interworking with IM and an NGN core The IM enabler should support services based on an IM platform and interoperate with the NGN core as defined by ETI TIPAN (reference architecture detailed in ETI E 00 []). The following sub-blocks need to be implemented: IM Interworking, mapping external IM messages to internal (home) non-im devices and vice versa. It is based on: Page 0 of

0 0 0 IP UA: generates IP messages for devices that do not have a IP stack on board (IP devices, legacy/pot devices ). The IP UA logic may be different for each type of device. BBUA: terminates one IP session (generated by a IP non-im UA) and translates it into an IM session to the IM core and vice versa. It maps IMPUs to local identities through the Identity management module. It involves an authentication algorithm (IM AKA, http Digest). IP proxy/server: supports local registration of IP devices (it includes the IP registrar function) and proxy functionalities in cooperation with the identity management block. IIM module: stores IMPIs (private identities), IMPUs (public identities), Home Network IM URIs (WAN domain) and long term secrets, and takes part in IIM based authentication (IM AKA). Identity management: maps the IM identity stored in the HG to a local identity. Devices should first register locally with the HG and then the IM core. Device management: stores device capabilities on the HG. This function can be implemented using protocols like IP or UPnP (to locally register devices and share capabilities). elf provisioning: enables the user to modify some service configurations through a (Web) User Interface (UI) on LAN side, at the Application erver (IM) (and/or locally). Note that self-provisioning is not the initial provisioning (which is made by the AC). ecurity: covers local access authentication, network authentication of the HG and firewalling Location Function: provides applications with location information configured by the BP (received from the CNGCF or obtained from the network, typically through DHCP. Remote Access: uses the local identity mapped to IM identity and device capabilities of the local devices, based on UPnP and DHCP, handled by the Identity Management and Device Management function blocks. The remote access rights (on a per IM user basis) to local devices can be configured in an ACL. Functionality for the remote terminal to find devices and corresponding services on the LAN is also supported (ynchronization). Figure shows the various blocks described above. Note that the IIM is optional (in the case of adoption of http digest), in this case identities and keys for authentication must be handled in another way. Page of

elf Provisioning Home Gateway UI NGN ervice Layer Application A IM Core P-CCF IM Interworking IIM BBUA Device mngt Identity mngt Remote Access IP IP IP UPnP device IP device Non IM IP device NGN IP Transport Layer (Access & Core) Ut RCEF, C-BGF Gm RAC e IP proxy/server Firewall Function Qo handling CAC IP UA IP UA IP FX IP device IM device POT IDN NA CNGCF(*) ARF, NACF e ecurity Location Function (LF) Access Authentication Figure. IM interworking sub-blocks. Home Networking Technologies and Architecture.. Home Network Architecture The architectural models covered by HGI for the HG and the IP infrastructure are. Routed model with NAT + PPPoE Passthrough (L partial bridge): the L connectivity is limited to PPPoE traffic. The broadcast PPPoE set-up requests are recognized by the HG, which sets up L bridging for all PPP traffic coming from that device. Page of

0 Figure Routed model with L partial bridge Routed model with proxy: for certain services (e.g. IP) a proxy will be needed in the HG. A proxy allows clients to make indirect connections to other network services by connecting to the specified AN server, or possibly by delivering the service from its cache (e.g. in the case of an HTTP proxy). Hybrid model with separate physical networks: this offers two or more physically separated home networks, one corresponding to the routed, and the other(s) to the bridged modes of operation. The HG has distinct physical interfaces for each network type. Devices can only directly communicate with other devices on the same network segment. Communication between network segments is only possible via the AN. Figure Hybrid model with separate physical networks In-house networking models for IPTV Figure and Figure 0 show the possible networking models for multiroom IPTV, based on the previous description. Page of

Other connections (bridged or routed) LAN HG IPTV Routed Bridging WAN Routing NAT NAT NAT IP Address NAT NAT IPTV connections NAT IP Addr ess Figure. IPTV routed multiroom HG - IPTV Bridged LAN WAN Routing NAT NAT NAT IP Address NAT NAT Other connections (bridged or routed) IPTV connections Bridging Figure 0. IPTV bridged multiroom Page of

0 0 0 In the routed model, traffic to the IPTV terminals can be addressed with or without a dedicated logical WAN connection (e.g. ATM PVC or VLAN). This requires the HG to be able to support both a single WAN IP address, and multiple WAN IP addresses (one per logical interface). Multiroom IPTV terminal support and addressing can be done: tatically, using the physical port where an IPTV terminal is connected. The LAN port can be physically identified in different ways, e.g. using a different colour. This is only appropriate in the case of a single IPTV terminal and for network interfaces capable of being dedicated to a single terminal (e.g. Ethernet) Dynamically, where the IPTV terminals are identified on the basis of traffic classification rules (see Qo traffic classification rules for LAN traffic) In the HGI approach IPTV terminals use end-to-end multimedia protocols, so that functionalities for translating HN IPTV into WAN IPTV protocols are excluded. This does not prevent IPTV terminals having HN protocol translation functions to communicate with other devices on the HN. The model used here considers a single connection between the IPTV devices and the HG. In the case of IPTV terminals with multiple independent connections (multiple VLANs or physical wired/wireless interfaces) to the HG, at least one of these connections must comply with one of the previous architectural models... Home Network Connectivity The following connectivity is supported by the HG and shown in Figure : and provide connection between EDs and different ervice Edge Nodes allows two EDs to communicate via the HG, i.e. it acts as a hub. This could for example be to connect two PCs connects two devices via an external device such as a switch, but the traffic does not go via the HG is a direct ED to ED connection, again with traffic not transiting the HG is a combination of and, i.e. traffic goes via the Hub and a switch. Page of

Access Network Home Network ervice edge nodes ED (TB, PC ) Home Gateway witch 0 0 Figure Possible HN connectivity.. Home Networking Technologies The ideal LAN technology to be incorporated into the HGI home gateway would: support the distribution of multi-channel video throughout the home (WAN-LAN and LAN-LAN) with the appropriate aggregate bitrate (~0-0 Mbit/s net payload). Where the PHY rate of a technology is time or location variant, then this aggregate bitrate must be able to be supported under near worst-case conditions. not require any significant installation of new cabling. conform to mandatory EMC emissions standards and not interfere with access network technologies such as ADL and VDL, or other home network technologies/devices. Unfortunately none of the existing HN technologies meets all these requirements, so a combination solution is therefore required. The HN technologies chosen by the HGI are: IEEE0.a/b/g and IEEE 0.n Draft. This will provide connectivity to laptops, PCs and wireless devices such as PDAs where the key requirement is in-house mobility. It will not necessarily provide whole house coverage, or Qo such that video streaming applications can be supported. 00BaseT Ethernet. This will provide high rate, predictable performance, with video streaming support, but only where it is acceptable to install the required new cabling i.e. within the room containing the HG, with a small amount of additional inter-room wiring in some cases. UB./.0 slave and UB.0 host. This will provide PC or peripheral connection The amount of new cabling that can be tolerated might differ from country to country due to different existing home infrastructures Page of

In order to support the full range of services and connectivity, a combination of the above solutions would typically be incorporated in the HG along with a basic Ethernet switch. Other technologies (e.g. PLT or HPNA) and further infrastructure devices may be required, but these will be external to the HG. This is taken into account to some degree in the Qo architecture. 0 0. Management Architecture The HGI approach is based on DL Forum TR-0 Amendment [] (hereinafter TR- 0 ). Various amendments, additions and the selection of some options from the DL Forum specification are detailed in this document. TR-0 Amendment defines the CPE Remote Management Protocol (CWMP) and the Auto Configuration erver (AC) to manage the HG and TR-0 enabled devices located in the HN. Annex F allows an AC to determine the identity of the HG through which a given ED is connected, and is an updated version of TR- part. Annex G allows an AC to initiate a TR- 0 session with an ED that is operating behind a NAT gateway, and is an updated version of TR- part. The others TRs relate to the data model: TR-0 Amendment []: defines baseline data model requirements for all TR-0 HGs and EDs. TR-0 Amendment []: defines v. of the Internet Gateway Device HG data model. TR-0 []: defines v.0 of the VoIP ED data model. The HG is under the control of a single RM at any one time. The high level management architecture and the entities involved are shown in Figure. ervice provider O/B RM ervice provider AC TR TR-0 config Config Access Network ED Home Gateway Local Mngt Interface Home Network End-users Figure Management entities interactions Device discovery Page of

0 0 0 The Auto-Configuration erver (AC) is the management application which implements device configuration, software updates, device diagnostics, remote operations and reboot requests as defined in TR-0 Amendment. This means that devices (HGs and TR-0 managed EDs) are managed via the CWMP protocol from the AC. The Remote Management ystem (RM) is the management entity which includes the Auto- Configuration erver capabilities but provides additional management functionalities. The RM includes resource and device inventory, event notification and alarm management, diagnostics and troubleshooting. The RM has a northbound interface to the O/B. With this interface, the O/B of the operator is able to establish the policies that the RM implements (by applying the required configurations to the HG). The O/B allows for multi-service provider support as detailed in section... The HG and the end devices are able to interact autonomously to some degree, performing operations such as device discovery. Finally, the user may be allowed to have an interface to tune the configuration of the HG to a small degree. uch an interface may have one part based in the HG itself and the other one located in the Operator s portal O/B. The management architecture of the Home Gateway is shown in Figure and can be broken down into these main functions: Device Management Qo Management ecurity Management Configuration Management Firmware Upgrade Management Performance Monitoring Diagnostics and Troubleshooting (alarms/notifications and log management) Two other components are identified: CWMP Client Local Management Application For both remote and local HG management there is a common Management Abstraction Layer and a Data Model Management module to allow uniform DB access. The main HG management interfaces are: I HG-LM for local management, is an HTML interface I HG-AC for remote management, is a CWMP interface The ED interfaces are: I ED-AC for remote management of bridged ED, is a CWMP interface I ED-HG is a communication ED/HG interface; it can be a DHCP or UPnP interface Page of

Local Mgmt Remote Management ystem Auto Configuration erver IED-AC I HG-LM TR-0 Client Local Mgmt App TR-0 Client I HG-AC Bridged Managed Device HG & ED DB Mgmt Abstraction Layer I ED-HG TR-0 Client Device Mgmt Qo Mgmt ecurity Mgmt Routed Managed Device Configuration Mgmt Fw Upgrade Mgmt Performance Monitoring Diagnostics & Troubleshooting Un- Managed Device Device Discovery Home Gateway 0 Figure Management Architecture.. Device Management End-device management can be divided into two main categories: Device discovery. Device configuration. The HG should also enable some remote management of simple end devices that do not support TR-0 [] but rather UPnP [] or even only DHCP. Also IP devices in the home network should be able to be discovered and remotely managed. It is assumed that the RM only communicates with the HN using TR-0, and therefore three remote management models can be distinguished. The models are depicted in Figure, Figure and Figure. They are: TR-0-enabled end devices with the HG operating in bridged mode TR-0-enabled end devices with the HG operating in routed mode End devices that are not TR-0 enabled with the home gateway operating in proxy (routed) mode. In Figure the model is only given for end devices that are UPnPand DHCP enabled. For IP devices a similar figure holds. Page of

RM gateway interface: to manage the gateway RM server TR- TR-0 + TR- TR-0 DHCP server Access Network interface HGI Gateway RM client Bridge Function TR-0 + TR-0 TR- Home Network interface unmanaged devices DHCP client RM TR-0 TR- client client bridged Bridged TR TR-0 end device RM Device Interface: to manage the bridged end device directly via public IP address Figure Remote management model for TR-0-enabled end devices with the Home Gateway operating in bridged mode RM gateway interface: to manage the gateway TR-0 + TR-0 RM client HGI Gateway unmanaged end-devices RM server (RM) Access Network interface DHCP server Fill Managed Device Table NA(P)T Router gateway Function TR-0 + TR-0 Home Network interface TR-0 Annex F DHCP client RM TR-0 client Routed TR-0 end-device RM Device Identification interface RM device interface: to manage routed HGI gateway is TR-0 managed end-devices behind NA(P)T gateway Figure Remote management model for TR-0-enabled end devices with the Home Gateway operating in routed mode Page 0 of

RM gateway interface: to manage the gateway and routed UPnP and DHCP end-devices RM server (RM) TR-0 + TR-0 0+ + TR-0 Access Network interface HGI Gateway RM client Fill Managed Device Table + end device remote management UPnP RM- Proxy Home Network interface DP + UPnP control/events unmanaged end-devices DHCP client RM UPnP client routed UPnP end-device DHCP server + RM proxy DHCP discovery + options DHCP client routed DHCP end-device RM HN device interface: to manage routed end-devices over the HN 0 0 Figure. Remote management model for UPnP and DHCP-enabled end devices with the Home Gateway operating in proxy mode. A distinction is made between managed and unmanaged end devices. A managed device is a device that communicates directly or indirectly (via the Home Gateway) with a RM of the BP. An unmanaged device is a device that does not communicate directly or indirectly (via the Home Gateway) with a RM of the BP. In the requirements section, the terms manageable device and unmanageable device are also used. Their definitions are slightly different from the ones above: A manageable device has an active and detectable remote management client, and may or may not communicate with the RM of the BP. An unmanageable device is any other type of device. Typically, these are userconfigured or pre-configured IP devices The HGI specification requires the HG to discover and uniquely identify managed devices, and it should discover and uniquely identify manageable but unmanaged devices connected to the home network. All end devices with a remote management client should be discovered (and must be in the case where they are managed). It is useful to distinguish these devices by way of the remote management client(s) they support. even types can then be distinguished. These are given in Table and are referred to in the requirements section. The columns represent the various device types (HGI nomenclature), and the rows show which remote management client stack is supported by each device type. This classification is HGI specific. Page of

Client\Type Z D U CD CU C CWMP X X X UPnP X X DHCP X X X X 0 0 IP X Table HGI types of managed and (manageable) unmanaged devices Note: Type devices represent IP devices (IM compatible as well as legacy IP devices). They can also contain other functionality, e.g. UPnP functionality. However, IP functionality and UPnP functionality are usually independent. For instance, a IP phone might contain a UPnP enabled camera function. These functionalities are discovered by the HG as separate entities in the home network, to avoid unnecessary complexity. The HGI considers managed end devices to be type, C, CD or CU. That qualifies D and U as manageable but unmanaged devices, and type Z as unmanageable. The HG discovers the ID from connected end devices by retrieving and combining information from its ARP [] cache, DHCP repository, UPnP Control Point cache, and IP registrar cache. These caches get their information from the various devices connected to the HG. To avoid conflicts (arising because a device can be discovered by more than one cache), a priority scheme is needed. HGI gives priority to the information retrieved from the DHCP repository. A UPnP device (type U, which includes DHCP client by default, or CU) can be an embedded device in a root device, as described by the UPnP Device Architecture []. It is therefore a logical entity, rather then a physical device, A root device is usually the physical entity. Not only root devices, but also embedded devices need to be discovered to obtain a complete view of the home network. Every UPnP device (root or embedded) can be distinguished by UUID []. The discovery of a IP device (type ) can only be achieved by reading the internal table/cache of the IP registrar in the HG. It might require the IM interworking entity of the HG to include a IP server for registrar purposes. The discovered ID information is used by the HG to fill a Managed Devices Data Base that can be read by the remote management server. In Figure, the Managed Devices DB is shown as a logically separate unit. However, it should be included in the HG data model defined by the DL Forum, in order to be readable by the AC with CWMP. Page of

type HG type CU AC cwmp cwmp TR- Am. Manageable devices Managed Devices DB IP server UPnP CP cache DHCP repository ARP cache type C type CD type U type D.. ecurity Management Figure Device management and discovery type Z 0 0 The HG supports remote management of the firewall and the NAT capabilities of the HG... oftware Management and Upgrade It must be possible to change or upgrade the system level software remotely and transparently to the end user. There are two aspects to the firmware / software: The Operating ystem (O) itself ervice support modules The main operations for the complete O or for service building blocks are: Install Version Update Configuration Uninstall Restore configuration: Rescue boot.. Performance Monitoring and Diagnostics & Troubleshooting Any HG system level fault (e.g. Hardware, O and W related) must be detected and communicated to the RM. Three scenarios are possible and all are supported: RM initiated: o Remote diagnostic tests (periodic or by system operator request). o Performance monitoring statistics. HG initiated Combination of both of the above. Page of

0.. Local Management Application The Local Management interface allows the end user to view or make changes to the HG configuration, user managed services, user managed end devices and other safe settings. Three levels of management will be present in the HG with the following precedence (high to low): AC management (superuser), can manipulate all managed objects in the HG including lower order user rights Administrator management, can manipulate objects that do not interfere with AC or managed service operation. This can manage local user access rights (e.g. additional firewall rules, specific NAT for unmanaged devices). Users can only manipulate objects when allowed by the Administrator. The local user interface access will require access control to limit this to a local Administrator. In Figure, an overview of the local management interface is provided. On the access network side, the RM or AC will configure parameters of this interface through the CWMP management interface as defined in Figure. Local Management interface: to manage the RM client from the gateway LM Local UI: to let a user manage the RM client from the gateway LM Remote UI: to let a user manage the RM client on the gateway from a device on the HN RM server TR + TR Access network interface RM client Local Management Application LM Remote UI server Home network interface http + HTML LM Remote UI client 0 0 HGI gateway Figure Local Management Interface overview In the HG, a Local Management Remote User Interface server (LM Remote UI server) will host a web based Local Management Remote User Interface, which can be used from appropriate end devices equipped with a browser and connected to the HN. The HG is not required to have an embedded user interface, i.e. touch screen or buttons, for local management by the user... Multi ervice Provider upport The HGI supports multiple service providers to the same home. However, a single BP (Broadband ervice Provider) will have control over the AC system controlling a given HG. The BP may offer Application ervices to the end users, but will also allow other Application ervice Providers to offer (the same or other) services. When multiple service providers are offering (the same or different) services, agreements between these providers are needed with regard to specific parameters in the management data model of the HG. These agreements will address parameters (e.g. Qo-related parameters for queuing) that are specific to the service offered by the AP, or parameters that might conflict with similar parameters for a service offered by the BP and/or other APs. Page of

The HGI architecture supports the O-model, as parameters are agreed/resolved at the O level, rather than at the AC or RCE level. Figure shows the example of two BPs, each having a number of ACs controlling their managed RCEs. A BP may have (service level) agreements with a number of APs on commonly agreed parameters. AP O Provider # APm O Provider # O Provider # O Provider # BP NBI AC AC BPn NBI AC AC AC CWMP 0 0 0 RCE RCE... RCE RCE... RCE RCE Figure. O multi-service-provider management model Devices are connected to one and only one AC. The AC is controlled by the BP. Figure shows an example with two BPs, each having three ACs, each controlling a set of RCEs. This model also supports the case where the AP wants to control or manage an end device directly, e.g. in the case of fixed-mobile convergence using UMA, or other cases where an end-toend tunnel is needed. If AP# is a mobile operator delivering services to a UMA phone in the realm of BPn (with O#), then O# and O# should talk to each other to be sure that the AC of BPn is configuring the tunnels and the HG NAT properly. This multi-service provider management architecture does not put any extra requirements on the HG (apart from it being manageable by one AC at any one time)... Home Gateway Provisioning For the successful configuration of the HG by the AC it is necessary that a trust relationship is built between them. The threats that need to be taken into account when establishing this trust relationship are: physical theft of the HG theft of sensitive data (e.g. IP account info) o by spoofing as a trusted HG o by spoofing as a trusted AC o by snooping o by hacking / cracking For the establishment of the trusted relationship, one or more of the below steps can be taken depending on the severity of the threats described above: The HG safely discovers the AC URL. The HG validates the AC connection. The AC safely establishes the link between a customer and an HG. Page of

It is assumed that the BP uses a list of supported HGs from different vendors. This list must be expandable with new types of HG, possibly from a different vendor.. Quality of ervice Architecture The HGI activity is predicated on the need to provide support for services which require Quality of ervice. The HGI Qo solution focuses on the Gateway itself, but also takes into account both the Home Network and the WAN connections to the various services. HG 00 Mbps Low-rate upstream Access High-rate downstream Access High-rate to low-rate bridge Merging WAN-LAN and transit traffic 00 Mbps 00 Mbps Wireless LAN Ethernet-PLT bridge Ethernet witch <0 Mbps 00 Mbps 00 Mbps 0 0 Figure 0 Possible congestion points.. Congestion Points The HGI Qo approach needs to accommodate a variety of both Access and Home Network technologies. There are a number of potential congestion points as shown in Figure 0. Note that the degree to which these are actual congestion points will depend on the technologies used. The Home Gateway upstream For certain Access technologies, in particular ADL, the upstream rate is very much less than the rates of the home network technologies. Even where the Access physical layer capacity is greater than that of the home network technology e.g. for a fibre Access network, there may be a need to constrain the service rate to a value which is again less than that of the home network technologies. There may also be a commercial need to allow the end-user to subscribe to more services than the upstream rate can simultaneously support. The HG Downstream The HG Qo solution needs to be access technology agnostic. For faster access technologies, e.g. ADL+, VDL/VDL, Ethernet or fibre, the HG can become a downstream congestion point. HG Transit Traffic One of the reasons for congestion is where there is a mismatch between the physical rates of different technologies. This can occur in the HG itself, for example when it is acting as a bridge between wired and wireless Ethernet. The other transit problem that can occur is when bridged intra-home traffic is aggregated with the downstream Access Network traffic, and they are Page of

0 0 0 0 competing for access to one of the LAN-side ports. The LAN-LAN traffic can burst at very high rates, and so fill up buffers within the HG thereby significantly delaying lower rate downstream traffic. LAN-LAN traffic will increase in the coming years with the proliferation of connected audio/video... Bridges and switches in the Home Network Rate mismatches can also occur within the Home Network itself, for example in an in-line bridge device such as a PLT-Ethernet adaptor. imple aggregation devices (e.g. an Ethernet switch) which have the same physical interface type and speed on all links, including the aggregating uplink, can also become congestion points. The HG may not have any knowledge of the presence of such devices In order to be less intrusive no new wires technologies are preferred to distribute services in the home. Most of these are shared medium, and/or have time varying capacity at the physical layer, both of which can cause problems from a Qo management perspective. For these reasons there is no attempt in the Qo scheme to cope with full Qo management outside the HG. e.g. in the home network... Basic principle of operation The HGI Qo approach is therefore mainly concerned with managing Qo through the HG itself. It works on the basis of a packet by packet, service classification. The service classifiers are combinations of the ingress packet header fields. LAN-side ingress Qo markings are generally untrusted, but can be used if trust is established by some other means, and/or in combination with other service classifiers. The service classification is used to assign the packet to the appropriate queue, and may be used to set the L markings for a particular HN technology. It is also possible to drop packets on the basis of classification. ervice classifiers are downloaded from the AC as a static policy. Where service instance classification is used (e.g. for the overload protection mechanism described below), the additional classifiers are generated within the HG itself. There is no session awareness, except for that associated with this overload control mechanism and the voice CAC function. Classbased queuing is used. LAN-side ingress DCP markings can be overwritten to zero or a per service configurable value. There is a Qo mapping table for L parameters for LAN-LAN bridged traffic. As well as the overload protection mechanism, the HG can provide a basic CAC mechanism by limiting the number of service instances in a specific service classes. Finally mechanisms to monitor the egress queues for the purposes of service assurance (helpdesk etc.) are specified... DCP and VLAN Usage ome current L Qo schemes are based on DCP markings, with VLAN/Ethernet priority markings being used in L schemes. Although all of these feature to some degree in the HGI scheme, they are not the main mechanisms. There are problems with relying upon DCP in the LAN to WAN direction. Firstly, all traffic of the same type would have the same marking, but what is required is the ability to differentiate on a per service basis. econdly, the DCP markings need to be trusted, but since they can be set by an end-user application they can be easily spoofed. In principle VLAN IDs and/or priority tags could be used as a Qo classifier within the Home Network, however this approach is not part of the HGI Qo strategy. Adding a VLAN header or priority tags increases the Ethernet frame size; some small, unmanaged Ethernet switches may drop such frames. Therefore the HG does not add VLAN headers to any frames. However certain DLNA devices may send tagged frames. The HG needs to be able to receive such frames and in the case of bridged traffic, will forward them transparently. Additional guidelines are also provided to allow coexistence between the HGI Qo model and the DLNA approach. Page of

0 0 0 0.. Traffic Classification The key requirement for traffic classification is to be able to classify a service rather than a traffic type. Queuing, scheduling, and dropping treatments are determined based upon this service classification. The BP/AP wishes to deliver certain quality services. There may well be other traffic of the same type (e.g. VoIP) which should not be given any special treatment if it is not a value-added service. Each packet is classified by inspecting one or more of its header fields. The combination of classifiers used to identify a service is known as the classification rule for that service. There are in fact rather different requirements for the classification of the three basic directions of traffic flow through the Gateway i.e. upstream, downstream and transit. The upstream classification needs to be the most fine-grained, as queuing and scheduling into what is normally the most significant congestion point needs the greatest degree of control. In the downstream direction little can be done to improve the Qo of arriving packets, and the main aim is to maintain this ingress Qo, and ensure that it is not compromised by either transit traffic or the slow operation of any integrated HN technologies. The downstream and transit classifiers are typically a subset of the upstream classifiers. The upstream classifiers are briefly described below with a brief rationale as to when and how they might be used, and the downstream and transit subsets are then noted... Upstream Classifiers IP Destination Address (IP DA) This is a particularly useful service classifier. Many Managed ervices have some kind of Border Gateway, and so there is a single destination IP address associated with that service. This has major advantages: It requires a single, initial configuration It cannot be usefully spoofed, as the traffic would go to an inappropriate destination It can be used for an encrypted service as long as the tunnel address is known. IP ource Address (IP A) This may be appropriate when there is a large number of DAs associated with a service e.g. if there is a large number of video servers. The IP A will often be a locally administered, private address, but if the device type can be identified at the time the address is allocated (for example via DHCP Option 0), then this can be used to automatically configure the A as a service classifier. Physical port Physical port is a useful classifier where a port is dedicated to a service (e.g. an analogue presented VoIP service). Packet Length Different services from the same device may go to the same IP DA. Packet length can then be a useful discriminator between voice and data, and may allow them to be queued separately to avoid excessive voice jitter. MAC A and DA These can be used to distinguish different physical devices, and therefore different instances of the same service. Port number TCP/UDP port number can be used to identify certain applications. Protocol type Page of

0 0 0 0 Distinguishing between TCP and UDP protocols can allow a more general distinction between different types of service. DHCP Options and Classification The HGI strategy includes the use of information learned using DHCP options about devices on the LAN to set classifiers. For example, the device type can be learned in a DHCP exchange, and associated with the MAC A of the device... Downstream Classifiers The main requirement here is to be able to distinguish between managed and unmanaged services, and this can often be done on the basis of IP A alone. ome of the above classifiers are also included in the downstream (D) scheme, as they may sometimes be required. However packet length, MAC address, and physical port are not needed here; there is only WAN port, and so the fact that it is downstream traffic can be taken into account without there needing to be an explicit classifier... Transit classifiers The AP/BP is not directly involved with the transit traffic but wants to prevent it adversely impacting his managed service. This could be done by always separating out D and transit traffic, and simply giving absolute priority to the D traffic. However there may be an opportunity to distinguish between transit streaming and data traffic on the HN, and prioritize the former. The problem is that if this traffic is simply bridged, then it may not be seen by what is essentially a L classification engine, but if all such traffic was forced via the full classifier, this would require it to be able to operate at a line rate of up to 00 Mbps. Further, the BP/AP has no awareness of these LAN-LAN flows which makes a service-based classifier hard to configure. Therefore there is a simple transit priority scheme, which is essentially device-based and uses MAC address pairs (A and DA) to identify traffic which can be given higher priority. eparation between D and transit traffic is still maintained... Qo Mapping The HG primarily works on the basis of a packet by packet service classification and operates largely in isolation from a Qo perspective, therefore mapping between different Qo regimes is not a key element of the scheme. There are however some mappings which may be useful, particularly for bridging between different HN technologies and these are defined...0 Upstream Queue structure In the upstream direction the main functionality required is to avoid excessive delay for voice, provide sufficient bandwidth for voice and video, and to prevent best-efforts traffic being completely starved by higher priority queues. There are fundamentally different types of traffic with regard to Qo, voice, video and data. This would require queues. However there is a need to further distinguish between different types of data (e.g. for higher priority control data or to support a premium data service), Further, the overload protection mechanism requires an additional queue, making the total number required at least. In the case of multiple WANside layer interfaces, each layer interface has the same set of WAN side queues and all the related WAN side egress functions. There are types of queue, strict priority and weighted round robin. There are at least strict priority queues with the remainder being WRR. The highest priority queue is served to exhaustion. The second strict priority queue is served when the highest priority queue is empty, and the scheduling is such that the jitter on the highest priority queue due to all other queues is limited to a single packet. The highest priority queue would normally be used for voice, with the second queue being used for other CBR applications which were less jitter sensitive. Use of strict priority queues means that all traffic which is put into them will be transmitted, as long as there is sufficient physical layer capacity. The only additional requirement is to avoid Page of

0 0 0 0 these queues completely starving all other queues. Note that while the queues are nominally associated with particular traffic types, any service can be mapped to any queue, and the scheduling behaviour is configurable by means of the round-robin weightings. The overall aggregate can be shaped to a rate which can be configured to be less than the physical line rate, and there is also a per queue shaper for the WRR queues. This could be used for example to limit the maximum upstream rate of an Internet service... Downstream and Transit Queue tructure In the downstream direction there are concerns, ensuring that WAN traffic is not blocked by transit traffic, and if there is downstream congestion due to a rate mismatch caused by a slow HN technology, that the value added traffic gets priority. There may be two different types of transit traffic, simple data, and streaming e.g. from a media player. The downstream needs a somewhat simpler queue structure, with queues (WAN Managed ervices, WAN Best Effort, LAN media ervices, LAN Best Effort) per LAN port... Class Based Qo, essions and Policy The HGI Qo approach is essentially traffic class-based, i.e. the Qo treatment is the same for all flows belonging to the same class. This is for reasons of simplicity and scalability. Flows are closely related to sessions, which have possible uses in a Qo scheme allowing a different per session Qo policy to be applied, and preventing new sessions if they would adversely impact existing ones. The basic requirement here is to provide the appropriate Qo for a service type; there is no reason to suppose that this should be different on a session by session basis. Therefore a static policy approach has been adopted. The potential downside of this is that there is no mechanism to prevent a new session overloading the class so that the entire class suffers. If overload is a real concern (as opposed to a theoretical possibility) then some kind of admission control system is needed. Admission control requires a decision to be made about resource availability before a session is established, and so normally involves signalling. However the HG can support a basic overload protection mechanism without signalling which allows a new service instance to be allowed on a trial basis to see whether or not it can be supported, without impacting existing traffic. This mechanism works in the following fashion. Within a service class there is the concept of a recognised and an unrecognised service instance. The simplest way of doing this would be to classify the instance on the basis of the associated LAN IP or MAC address. Any packet with the known service class, but unknown instance would be put into a different queue to recognised instances. Each classification rule has an optional pointer to Application Layer Logic (ALL). For overload protection, the ALL would check if this was a known service instance. If not it would initiate a procedure which would check (over a relatively short period of time) if this new instance could be accommodated without causing overload, as measured by excessive queue length. Further details of this are given along with the requirements in ection.0. As an alternative to the overload protection mechanism, a basic Connection Admission Control (CAC) function is also defined. This works by recognizing new session requests and monitoring session terminations. Particular services are assigned to CAC classes (by configuration of the HG). The bandwidth limit for each CAC class is also configured. The HG recognises a request for a new session by participating in (as opposed to snooping) the signalling for that service. While the case of a IP based voice service is the only one explicitly defined, the underlying CAC functions are applicable to any session based service that uses signalling available to the HG... DLNA coexistence While the focus of HGI Qo is classification by the HG, the HGI recognises that home LAN flows are increasingly using markings that follow DLNA service guidelines. The HGI Qo section provides requirements for respecting these guidelines and the important elements are: Trust establishment of DLNA devices. Page 0 of

0 0 0 0 Dynamic classification rules that can be added to the HG following trust establishment. Rules for the treatment of packets from such trusted devices... Fragmentation and Classification ome applications, for example video streaming, use large UDP or TCP packets. When these are greater than the MTU (typically 00 bytes), the IP layer will fragment them. Whilst each resulting fragment contains a layer header and an IP header, only the first fragment contains the UDP and TCP headers. Therefore, fragments must be handled with particular care by the HG; this includes classification as well as NAT. Classification could treat fragments in ways: Re-assembly of arriving fragments so that all header fields, including the UDP or TCP fields, are available to the classifier. Classification on a fragment-by-fragment basis. The HGI does not actually support either of these methods and so as to avoid this problem, it is recommended that either the AP/BP avoids the use of applications that result in fragmentation, or that classifiers for such applications only use the layer and IP header fields... Classification and NAT for WAN Ingress Classification treats arriving packets according to their header fields. However, NAT may subsequently alter the IP, TCP and UDP fields. TR-0 does not clarify if classification applies to pre- or post- NAT ed headers. It is recommended that the AP/BP configures classifiers on NAT ed flows with particular attention to this issue. To avoid ambiguity, it is also recommended that operators configure classifiers that only use header fields (e.g. IP Destination Address and UDP or TCP source port) which will not change during NAT.. ecurity Architecture There are three main points where security needs to be enforced: in the HG itself, in devices connected to the Home Network which only access the public network through the Gateway, and in devices that can be connected to the Home Network but have another public network interface (e.g. to a mobile network). The HGI takes the above into account, but only addresses those functions that could be implemented in the HG, as described in the following sections... Firewall protection There is a need for a stateful firewall but this may not be effective with applications that include IP addresses and TCP/UDP port information in the payload (e.g. FTP, IP protocols, peer to peer applications). To filter these protocols the firewall has to be augmented by specific Application Level Gateways... VPN Capabilities Different technologies can be adopted for VPNs. These include Layer solutions like PPTP and LTP, application level solutions like L and the standard IP Layer solution, IPsec. An IPsecbased solution has been selected by the HGI because it provides a standard, flexible and network controllable architecture that can be used irrespective of the application; in contrast L cannot be used with applications based on UDP. A VPN passthrough mechanism is supported by the HG for those cases where the VPN client is on the terminal. A VPN client should be implemented in the HG to protect VoIP signalling while the VoIP data streams should be protected using RTP. Page of

0.. Encryption algorithms Encryption algorithms can be used for many different purposes, for example key exchange or authentication. The HGI addresses the need for storing private/public key pairs inside the HG, following the RA protocol, to be used both for authentication and signature purposes... Code authentication / ignature The digital signature function defines two processes: a process for signing data, and a process for verifying signed data. This functionality is used to validate HG firmware updates... Local Configuration ecured Access The HG must be accessible locally or remotely by authorized entities only (user, RM etc.) This is addressed by the use of protocols combined with certificates... Remote access pecific devices in the HN must be accessible remotely, through the HG, by authorized entities. The security related aspects of this are authentication/authorization, and confidentiality and discovery and addressability (from the WAN) of the end devices on the home network Page of

0 0 0 Home Gateway Requirements Extracts from ection. The majority of requirements are all expected be present in a Baseline HG. These are written as MUTs, and denoted by an in the rightmost column of ection. Note that MUT and the designation are not synonymous for the reason given below. In addition to the Baseline requirements there are types of options. The first type, Individual options, are contained within a ection consisting largely of Baseline requirements. These are written as HOULDs, and marked with a + in the rightmost column. They usually (but not always) follow a Baseline requirement and increase the basic requirement in some way (e.g. the number of ports or instances of a function). These options are the ones which vendors might choose to implement to differentiate their product, but would not be sufficient to change the class of device. The other type of option is an Optional ection. This specifies additional (as opposed to enhanced) functionality. An Optional ection is a set of requirements that contains both mandatory and optional requirements and should be considered in its entirety. Optional ections as a whole are marked with a + in the ection heading. + ections add functionality that would only be needed to implement specific services or to support certain network architectures. Within these Optional ections, the essential requirements are written as MUTs, and denoted by *, whereas the associated enhancement options are written as HOULDs and marked by +*. There has been no attempt to indicate which combination of Optional ections would be expected to be present in an Enhanced HG, as it is hard to get consensus on this, and in some cases there are alternative types of additional functionality which serve a similar purpose. In the latter case it would not make sense to implement both of the alternatives. uch ections are marked by +A, with the reference to the alternative ection also being given. The definitions of MUT and HOULD in this document are therefore as follows: MUT A functional requirement which is based on a clear consensus among HGI ervice Provider members, and is the base level of required functionality for a given class of HG. MUT NOT A function which is prohibited by the specification HOULD 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). Notes: These definitions are specific to the HGI and should not be confused with the same or similar terms used by other bodies. These terms only have these meanings when capitalized and used in the Requirements ection of this specification (ection ).. WAN ide Interfaces R. R. The HG WAN interface MUT be easily identifiable and separated from the LAN interface(s). The HG MUT support one of the WAN interfaces described in sections..,..,... R. The HG HOULD support an interface combination as described in ection.. R. + Page of

R. The HG HOULD be equipped with an additional, separate PTN (FXO) interface. +.. Type - ATM over DL Interface (*) R. The HG MUT support ADL+ access network technology (ITU-T. []). * R. R. R. R. R0. R. R. R. R. R. The HG MUT support backwards compatibility with ADL (ITU-T G.. []) and ADL with Annex L (ITU-T G.. []). The HG MUT support backward compatibility with ADL (ITU-T G.. []) and ADL with Annex L (ITU-T G.. []). The HG MUT support the handshake procedure for digital subscriber line transceivers (ITU-T G. []). The HG MUT support the regional PD Masks relevant to each market (Annex A, B or C) (ITU-T G.. [], G.. [] and G.. []) The HG HOULD support the PD Masks defined in Annex M (ITU-T G.. [] and G.. []) The HG HOULD support the PD Masks defined in Annex I, J (ITU-T G.. [] and G.. []) The HG HOULD support upgradeability from ADL+ to VDL ITU-T G.. [] (profile a,b,c,d) The HG MUT support ATM over ADL+, ADL and ADL (ITU-T I./ [0] [] and RFC []) with PVC management The HG MUT be preconfigured with a search list of possible VPI/VCI values (at least 0/, 0/, /, 0/, 0/, 0/, /, /, /, /, 0/, /) OR the HG MUT be preconfigured with a set of VPI/VCI default values specified by the operator The HG HOULD support ILMI (Integrated Local Management Interface protocol) to configure ATM and encapsulation parameters, following the guidelines in DL Forum TR-0 [] and ILMI ATM Forum.0 specification []. If both the HG and the network support ILMI, then ILMI MUT override any preconfigured ATM and encapsulation parameters * * * * +* +* +* * * +* R. The HG MUT be capable of supporting at least PVCs * R. The HG HOULD support dual bearer/dual Latency (interleaved and fast channels). If Dual Bearer/Dual latency is supported, the related parameters such as min rate, max rate and bandwidth ratio between interleaved and fast MUT be configurable per PVC. Note: this does not involve the AC. +* R. The HG MUT support the following ATM traffic classes: CBR, VBR-rt, VBR-nrt, UBR * Page of

R. The HG MUT be able to reply to OAM F cells conforming to ITU-T I.0 [] * R0. The HG MUT reply to F VC-AI cells with VC-RDI. *.. Type - Ethernet over DL Interface (*) R. R. The HG MUT support VDL ITU-T G.. [] (profiles a, b, c, d, a and a) access technology for Central Office or Cabinet deployments with co-existence with ADL+ The HG MUT support VDL ITU-T G.. [] (profiles a, b, a and 0a) access technology for MDU deployments with short loop lengths and no co-existence with ADL+ * * R. The HG MUT support backward compatibility with ADL, ADL and ADL+ * R. R. The HG MUT support the relevant regional PD-Mask (Annex A, B, C of ITU-T G.. []) The HG MUT support PTM-TC (Packet Transfer Mode Transmission Convergence) for Ethernet packets (IEEE EFM 0.ah standard []) * * R. The HG MUT support upstream Pre-emption for PTM-TC * R. The HG HOULD support Dual Bearer for PTM-TC R. The HG HOULD support Dual Latency for PTM-TC +* R. The HG MUT support the related Ethernet protocols at layer, with VLAN management (support for untagged frames and 0.Q [] tagged frames containing priority-tagged information (IEEE 0.p [] and VLAN-ID information). *.. Type - Ethernet WAN Interface (*) R0. R. The HG MUT support Ethernet 00Base-TX [] technology for twisted pair (Cat- or Cat-) The HG MUT support the related Ethernet protocols at layer, with VLAN management (support for untagged frames and 0.Q [] tagged frames containing priority-tagged information (IEEE 0.p []) and VLAN-ID information). * * R. The Ethernet interface MUT be on a dedicated port (i.e. in addition to the LAN-side Ethernet ports) R. The Ethernet interface HOULD be IEEE 0.z compliant (i.e. 0/00/000 BAE-T) * +* Page of

.. WAN Interface Combinations (+) R. R. The HG MUT be equipped with a combination of Type & Type or Type & Type interfaces. When there is more than one WAN interface the Type interface MUT be separate from the Type or Type interface and presented on a dedicated physical connector. * * R. Only one of the WAN interfaces MUT be active at any time *.. PTN (FXO) Interface (+) R. If an FXO port is available, the HG MUT support a failover mechanism to connect at least one FX to the FXO port in the following cases: power failure broadband connection unavailable VoIP service unavailable * R. FXO port MUT use either a RJ- (for legacy POT) or RJ- connector * R. In the case of an xdl connection with an associated PTN service, the HG HOULD support specific regional dialling plans to allow certain numbers (including emergency calls) to be routed to the FXO port (if service availability is detected on the PTN line) instead of being routed to the VoIP outbound proxy. +*. LAN side interfaces.. Wired R0. R. The HG MUT contain a 0/00BaseTX Ethernet (IEEE 0.u) switch on the LAN side, with at least ports. The HG MUT support a MAC frame format which complies with 0. [] (length/type formats) and 0.q [] (VLAN). Applicable only if a PTN service is available at the customer premises IEEE 0. and IO-IEC 0- Page of

R. The HG MUT include an UB. or.0 slave interface. R. The HG MUT be equipped with one UB.0 host interface conforming to UB-IF Universal erial Bus pecification, Revision.0 []. Note: this interface may be used to connect high speed peripherals.. Wireless R. The HG MUT include a wireless interface that operates as an access point. R. The access point interface MUT be IEEE 0.b/g Wi-Fi certified. R. The access point interface MUT be configurable (at least through the LM Remote UI) with regards to mode (i.e. b and/or g ) of operation. R. The access point interface HOULD be IEEE 0.n Draft Wi-Fi certified. + R. If R is implemented, the access point interface MUT be configurable with regards to both mode and frequency of operation. R. The access point interface HOULD be IEEE 0.a Wi-Fi certified with the extension (IEEE 0.h) for European countries. * + R0. R. R. The HG MUT radiate at least 0 mw E.I.R.P. from the antenna measured at the minimum antenna gain. The HG MUT not exceed the maximum limits for radiated power according to the regional regulations. The HG MUT be equipped with a minimum of two (internal or external) antennas with a diversity system R. The HG MUT be Wi-Fi Alliance WPA Personal certified []. R. The HG Wi-Fi interface MUT be WMM certified [], on the basis of Wi-Fi Alliance requirements for interoperability []. R. The HG Wi-Fi interface MUT be compliant with WMM Power ave. R. The HG Wi-Fi interfaces MUT be fully compliant with Wi-Fi Alliance WP - Wi-Fi Protected etup with PIN and with push button R. The HG MUT be able to simultaneously support at least three separate IDs. R. The HG Wi-Fi access point MUT be able to be configured without the wireless interface being active. Page of

R. By default, the HG MUT be provisioned with only one advertised ID. R0. R. The HG MUT support per ID the configuration (through both the LM Remote UI and CWMP) of the following beacon elements: ID name ID advertisement (broadcast or hide) ID encryption type WP WMM parameters Number of allowed associations The HG MUT implement an automatic radio channel selection mechanism to choose the channel with least interference on power up or following a manual request. R. Periodic channel selection HOULD be performed provided that service is not affected. + R. Automatic radio channel selection MUT be able to be enabled/disabled from the local configuration interface as well as from the AC. R. The HG MUT support at least wireless simultaneous clients of which at least MUT be able to be WPA encrypted, across all IDs in use... Telephony interfaces R. The HG MUT provide one FX port. The FX port MUT either be an RJ connector or RJ as defined by IEC 0 0--x in conformance with residential network standard EN 0-x R. The HG HOULD provide two RJ FX ports. + R. The HG MUT support a REN of (Ringer Equivalency Number; for North America: Telcordia GR-0-CORE, for Europe: ETI ET 00 00 Chapter ) per FX port R. The HG HOULD support a REN of (Ringer Equivalency Number) per FX port + R. The HG HOULD support one IDN BRI port + R0. The HG MUT support at least the following basic capabilities on telephony interfaces: DTMF, caller ID type, caller ID presentation, line impedance, line levels, and dial plans for controlling supplementary services Access control to the ID can be achieved by setting the number of associations to zero ome features may only be applicable to certain interface types Page of

R. The HG MUT meet all local telephony interface regulations and operator requirements R. The HG MUT support RFC (NTE Packets) for DTMF tones. R. The HG HOULD implement an echo canceller compliant with ITU-T G., for managing echo paths of delay up to ms. + R. The HG MUT provide an adaptive jitter buffer. R. In order to simulate block dialling the IP UA that supports a device behind the FX port HOULD implement the following: + R. R. R. R. A configurable inter-digit timer; when this timer expires the station should send the INVITE message containing the selected digits The Off hook key should only be used at the end of the complete selection If block dialling is received, an INVITE message should be sent The HG MUT support the following codecs: G Mu-Law, G A-Law, G.A (Narrow-band), G (Wide-band) with the following packetization times: G. 0ms, 0ms, 0ms; 0ms default G. Annex A 0ms, 0ms, 0ms; 0ms default G. 0ms, 0ms, 0ms; 0ms default The order in which codecs are offered MUT be configurable in the HG (according to TR-0). The ATA function in the HG MUT support the following features: VAD (Voice Activity Detection) CNG (Comfort Noise Generation) PLC (Packet Loss Concealment) The ATA function in the HG MUT support Line Echo Cancellation on all FX and FXO ports * * R0. The HG MUT support a fax service through the FX port. R. The following signals indicate the start of fax transmission and MUT be detected on the relevant HG interfaces: CED (answering tone) as per ITU-T Recommendation T.0 ANam (answering tone with amplitude modulation) as per ITU-T Recommendation V. Preamble as per ITU-T Recommendation T.0 section.. CNG (call tone) as per ITU-T Recommendation T.0 Page of

R. As soon as a fax signal is detected the HG MUT be able to set-up a G. call, with a fixed jitter buffer and CNG/VAD disabled. If a voice call was already established (e.g. with G.), the codec type MUT be renegotiated. R. As soon as a fax signal is detected the HG HOULD be able set-up a T. call. + R. Regardless of the type of fax transmission the Non-Linear Processing MUT be disabled and the Line Echo Canceller MUT be handled according to ITU recommendation G./G.. R. In the case of T. fax transmission (ref. R), the following mechanisms MUT be supported AN. version 0, Annex A-B-D-E Error correction to minimize impact of packet losses by use of redundancy UDPTL and TCP Rates: 00, 00, 00, 00, 000, 00 bps. Local and transferred training rate management methods Facsimile non-standard facilities frames handling in order to avoid non-standard facsimile procedures ession statistics Implements spoofing and buffering of data to fight with round-trip delays and jitter. Disable Error Correction Mode use by facsimiles. R. In the case of T. fax transmission, the following mechanism HOULD be supported Error correction to minimize the impact of packet losses: Forward Error Correction (Annex C) R. The HG HOULD be equipped with a DECT, or CAT-iq (DECT NG) interface implementing the Wideband voice basic interoperability profile (vb) as defined in ETI T 0 - New Generation DECT; Part : Wideband speech. * +* +. WAN and LAN Networking Requirements.. WAN Connectivity and Addressing R. The HG MUT support at least IP interface per WAN logical interface. R. The HG MUT support PPP and the associated protocols as defined IETF RFCs [], [], [0], [] and []. Page 0 of

R0. R. R. R. R. R. R. The HG MUT support PPPoE over the encapsulated Ethernet as defined IETF RFC []. If the HG supports ATM, it MUT support PPP over AAL (PPPoA) as defined in IETF RFC []. The HG MUT be able to acquire its WAN IP address information via DHCP (RFC []) and/or PPP IPCP The HG MUT support, via local configuration, static provisioning of the following addressing parameters: IP address subnet mask default gateway address primary and secondary DN addresses The HG MUT support, via local configuration, static provisioning of the following PPP parameters: PPP username and password The HG MUT make its WAN-side IP address known to the AC, for remote access and configuration purposes. The following DHCP options [][] MUT be supported by a DHCP client residing in the HG: ubnet Mask Default Gateway Domain erver yslog ervers NTP erver 0 Requested IP Address Lease Time 0 Vendor Class Identifier Client Identifier User Class 0 IP erver Address Vendor pecific Information Page of

R. The following DHCP options [][] HOULD be supported by a DHCP client residing in the HG: 0 Padding Timer Offset Host Name Domain Name Classful tatic Route Vendor pecific Information DHCP Message Type DHCP erver Identifier Parameter Request List DHCP Notification Message Renewal time rebind time TFTP erver Name Boot Filename Classless tatic Route End Option.. Routed Model and Local Area Networking upport... NAT/NAPT + R. The HG MUT support NAT/NAPT as described in RFC, RFC 0, RFC 0 and RFC [0][][][]. R. The HG MUT support full cone NAT mode as described in RFC []. R00. R0. R0. The HG HOULD support restricted cone and/or port restricted cone NAT modes as described in RFC, the mode MUT be configurable through the LM Remote UI. The HG MUT support port forwarding configurable through CWMP, LM Remote UI and UPnP IGD DCP (Internet Gateway Device, as specified in InternetGatewayDevice: Device Template Version.0 ). NAT rules defined by the Remote Management ystem MUT have a higher priority than rules defined by the user. + Page of

... IP Addressing schemes R0. The HG MUT support partial L bridging from its LAN to its WAN interface for PPPoE recognizing the related broadcast messages and creating appropriate bridging for correct MAC addresses. R0. The HG MUT allocate a private IP address to its LAN side interface. R0. R0. R0. The HG LAN side IP address MUT be on the same subnet as the devices on the Home Network. The HG LAN side IP address MUT be used as the Default Gateway in DHCP replies. Note: as all LAN interfaces are bridged, only one IP address is needed, which is used by all interfaces. The HG MUT allow LAN bridging among different interfaces, enabling intra-lan connectivity.... LAN-side DHCP requirements R0. A LAN side DHCP server MUT be available on the HG. R0. The HG MUT support configuration of its DHCP server, including IP address, IP address range, netmask, lease time, via CWMP and LM Remote UI. Page of

R0. R. R. R. R. The following DHCP options MUT be supported by a DHCP server [][] residing in the HG: 0 Padding ubnet Mask Default Gateway (Router) Domain Name erver Host Name Domain Name NTP erver Vendor pecific Information 0 Requested IP Address Lease Time DHCP Message Type DHCP erver Identifier Parameter Request List DHCP Notification Message Renewal Time Rebinding Time 0 Vendor Class-identifier Client Identifier TFTP server name User Class 0 IP erver Address Vendor specific information End Option The DHCP server MUT support fixed IP address allocation to specific device name or MAC addresses to be used in combination with port forwarding/dmz host. The DHCP server MUT be able to provide the same IP address to each device so long as the device has not been absent from the network for a period greater than 0 days. Where the DHCP server assigns private IP addresses to requesting devices on the home network, they MUT be on the same subnet (RFC []). The HG MUT support use of public IP addresses (that are within the proper subnet mask defined for the gateway WAN IP connection) on the LAN and properly route the device traffic. Note: it is assumed that devices with public IP addresses will be manually configured. Page of

.. upport of Hybrid Model and Extensions R. R. R. If the HG has an ATM WAN interface, it MUT support RFC [] for multi protocol Ethernet bridged encapsulation over AAL. The HG MUT support configuring and enabling multiple instances of bridging between WAN side logical interfaces (PVC, VLAN ) and LAN side physical (Ethernet Port, ID ) interfaces. The HG MUT support configuring and enabling one or more WAN logical interfaces and one or more physical LAN interfaces, to be routed (as described in sections.. and..). R. The HG MUT be able to run both bridging and routing simultaneously. R. The HG MUT be able to forward traffic over the right connection (in the case of multiple PVCs, multiple PPPoE sessions, multiple VLANs etc), on the basis of a number of parameters to be used as classifiers, and defined by DL Forum TR-0... ession Initiation and upport R0. R. R. The HG MUT support a "connect on demand" option for connections which is configurable via CWMP and/or LM Remote UI. In this mode the connection to the access network is initiated when outbound traffic is encountered from the local LAN, and terminated after a timeout period in which no traffic has occurred (connection timeout). The HG MUT support a "manual connect" option for connections which is configurable via CWMP and/or LM Remote UI. In this mode the connection to the DL network is initiated manually via the LM Remote UI and, by default, terminates only when explicitly requested to do so by the user, or due to a power loss or when the connection is lost. The HG MUT support an "always on" mode for connections. In this mode the device MUT NOT time out DL sessions (ATM, IP and PPP) and MUT automatically reestablish any sessions after disconnection, lease expiration or loss and restoration of power. This feature MUT be configurable via CWMP and/or LM Remote UI. R. The connection timeout interval MUT be configurable via CWMP and/or LM Remote UI. R. A manual disconnection method (i.e. without waiting for a connection timeout) MUT be provided via LM Remote UI. R. A default of 0 minutes HOULD be used for the connection timeout. + Page of

. LANside Interoperability R. The HG MUT support UPnP Device Architecture.0 and this MUT be enabled by default. R. It MUT be possible to enable and disable the UPnP IGD DCP in the HG via remote management and the Local Management Remote User Interface (LM Remote UI). Disabling UPnP IGD DCP functionality MUT NOT affect UPnP Device Architecture operation.. Guest Access and Wi-Fi Hotspot (+) R. One of the wireless partitions MUT be able to provide connectivity to a commercial hotspot provider (AP), who need not be the same business entity as the HG owner s BP. R. The HG MUT be able to implement at least one other partition of the wireless network to allow access to the BP only, i.e. without having access to any other part of the HN. R0. The HG MUT support the IEEE 0.X protocol (authenticator role) for connectivity of wireless devices. * * * R. Provisioning for EAP passthrough MUT be remotely manageable. * R. The HG MUT allow the owner to turn access to the partitions defined in R and R off and on (subject to this being allowed by the Terms and Conditions of any agreement with the BP). This control must be limited to the LM Remote UI of the HG. R. The HG MUT provide a local function that automatically turns access to the partitions defined in R and R back on, a configurable time after it has been turned off by the end-user (without requiring any intervention by the AC). R. The forwarding behaviour of the HG MUT be such that it does not allow direct communication between the home network and the wireless partitions defined in R and R. The HG MUT NOT just rely on the use of separate subnets to achieve this separation. R. It MUT be possible to identify which traffic went to/from users on the wireless partitions defined in R and R as opposed to users on the in-home network, e.g. by way of IP address. * * * * The BP will need to specify the default factory setting (enabled/disabled) Page of

. Management This section is based on parts of DL Forum TR-0 Amendment (hereafter called TR- 0 ), TR-0 Amendment (hereafter called TR-0 ), TR-0, and TR-0 Amendment (hereafter called TR-0 ). Requirements that simply emphasize current TR-0 or TR-0 functionality are explicitly labelled as such. Other requirements are refinements of or additions to TR-0 and TR-0... Northbound Interfaces R. R. R. The HG/AC communication interface MUT comply with all the mandatory requirements of the CWMP protocol v as defined in TR-0 []. Any HG management functionality over and above that defined in DL Forum data model TRs MUT conform with the vendor extensibility and usage conventions described in TR-0. Any vendor specific functionality MUT be described in vendor specific profiles following the definition and usage conventions described in TR-0 and MUT be listed in the Deviceummary parameter... General HG configuration and management R. R0. R. R. The HG MUT support and implement a local management graphical user interface. ome details of this interface are defined in section... The HG MUT automatically establish a CWMP management session with the AC, as defined in TR-0 [], including the following cases: Each time the default WAN connection s IP address changes On power-up or reset Whenever an unsuccessfully terminated management session is retried After configuration changes in the HG and the related notifications are activated and the related Active Notification attributes are set After a connection Request from the RM (or AC). This requirement emphasizes a particular subset of current TR-0 functionality. The data exchanged between the HG and the AC MUT be encrypted for in-band management, except for the firmware images. The level of encryption of the exchanged data is the one defined in DL Forum TR-0 (L or TL level). The data exchanged between the HG and the AC HOULD be encrypted for out-ofband management. The level of encryption of the exchanged data is the one defined in DL Forum TR-0 (L or TL level). + In-band management means the management session is in the same communication channel as the data (same VC, VLAN ) Page of

R. All authentication and configuration traffic from local clients to HG and vice-versa HOULD be encrypted. + R. The HG MUT only accept firmware images that have been electronically signed. R. The HG HOULD support the decryption of firmware images and software modules. + R. R. R. R. In order to be able to start communication with the AC, the HG MUT be able to learn its address by one of the following mechanisms: The AC URL is preconfigured The AC URL is locally inserted in a secure way through the LM Remote UI The AC URL is learned by the DHCP option method. This requirement emphasizes current TR-0 functionality. The HG MUT allow the AC to modify the AC URL remotely. This requirement emphasizes current TR-0 functionality. The HG MUT identify itself to the AC with its serial number and OUI, as defined in TR- 0. If the serial number is not unique across the product line, the product class MUT also be provided. This requirement emphasizes current TR-0 functionality. The HG MUT support auto-provisioning of basic L and L connectivity for the management communication channel: When using DHCP, authentication MUT be based on the hardware address of the HG WAN interface or the line identification. When using PPP, authentication MUT be based on a generic username/password burnt in the firmware of the HG or provided locally in a secure way. When using ATM networks, the HG MUT be preconfigured with ATM VC configuration unless it supports ILMI to configure automatically ATM connectivity... Definition of the data model supported R0. The use of profiles for the HGI data model MUT follow the definition and usage conventions described in the TR-0 Error! Reference source not found.. Out-of-band management means the management session is in a separate communication channel from the rest of data (dedicated VC, VLAN ) Page of

R. R. R. The HG MUT support the Baseline: profile definition for InternetGateway:. defined in DL Forum TR-0 []. This profile defines objects regarding: DeviceInfo Managementerver LayerForwarding LANConfigecurity (password of the local management interface) LANDevice WANDevice The HG MUT support the objects related to the WAN Interfaces which it incorporates defined in the following profiles: ADLWAN:, EthernetWAN:, Bridging:. These profiles are defined in the DL Forum TR-0. The HG MUT support the related objects of the LAN Interfaces defined in the following profiles: EthernetLAN:, UBLAN:, WiFiLAN:. These profiles are defined in the DL Forum TR-0... Diagnostics, notifications and alarms... Notifications and logging For notifications, the TR-0 definition is adopted.... Mechanisms R. R. The HG MUT be able to issue notifications and alarms to the RM. Two operating methods MUT be supported (not simultaneously), including the recommendation to throttle event generation in the case of lack of response from the AC: Active Notification: The HG notifies the RM of the alarm as soon as it is produced. This mechanism MUT be implemented using the proactive notification mechanisms defined in TR-0 Passive notification: The HG stores the notification internally and sends it to the RM with the next Inform. This mode MUT be implemented using TR-0. This requirement emphasizes current TR-0 functionality. The HG Data Model MUT include a list of supported events and their notification types. Page of

R. R. The HG MUT be able to log the following events 0 : detection of unsuccessful firmware or configuration download detection of unsuccessful installation of downloaded files whenever the firmware version has changed a software module of the HG has been added, deleted or upgraded whenever the boot process of the HG has finished whenever the IP address of the WAN side has changed whenever a new manageable device is connected or disconnected The HG stores the log information internally and sends it periodically (initiated by the AC) to the RM using a log file. This MUT be implemented using the Upload method, using the option Vendor Log File, as defined in TR-0. + R. The log file MUT be an XML file based on the log information stored in the HG.... Notification cases Active notifications R. The HG MUT issue a notification to inform the RM about its status, when finishing the booting procedure, as defined in TR-0. This requirement emphasizes current TR-0 functionality. R0. The HG MUT issue a notification to inform the RM that its WAN side IP address has changed. By default, this event is actively notified as defined in TR-0. This requirement emphasizes current TR-0 functionality. Passive notifications R. The HG MUT issue an event if a software module of the HG has been added, deleted or upgraded. 0 Defaults settings for the related events (Active, Passive or Log) are left to the BP Page 0 of

... tatistics and Diagnostics... Mechanisms R. The HG MUT support the diagnostic tests defined in TR-0 using TR-0.... Defined diagnostics and statistics Page of

R. R. Diagnostics and reporting of WAN side parameters MUT be supported. The mechanisms are the ones included in TR-0 [] and TR-0 [] using the following objects (note: the objects listed here are linked to specific WAN side technologies and therefore they will be only present in the WAN access technology is present). The statistical data are: The diagnostics are: WANCommonInterfaceConfig (attributes: WANAccessType, LayerUpstreamMaxBitRate, LayerDownstreamMaxBitRate, PhysicalLinktatus, WANAccessProvider, TotalBytesent, TotalBytesReceived, TotalPacketsent, TotalPacketsReceived, MaximumActiveConnections, NumberOfActiveConnections) WANDLInterfaceConfig (attributes: all except Enable) WANDLInterfaceConfig.tats.Total WANDLInterfaceConfig.tats.howtime WANDLLinkConfig (attributes: Linktatus, AutoConfig, ATMTransmittedBlocks, ATMReceivedBlocks, AALCRCErrors, ATMCRCErrors) WANEthernetInterfaceConfig (attributes: tatus, MACAddress) WANEthernetInterfaceConfig.tats WANEthenetLinkConfig WANDLLinkConfig (attributes: Linktatus, LinkType, AutoConfig, ModulationType, ATMTransmittedBlocks unsignedint, ATMReceivedBlocks, AALCRCErrors, ATMCRCErrors, ATMHECErrors) WANIPConnection (attributes: Connectiontatus, PossibleConnectionTypes, Uptime, LastConnectionError) WANIPConnection.tats WANPPPConnection (attributes: Connectiontatus, PossibleConnectionTypes, Uptime, LastConnectionError, PPPEncryptionProtocol, PPPCompressionProtocol, PPPAuthenticationProtocol, CurrentMRUize, TransportType) WANPPPConnection.tats WANDLDiagnostics WANATMLoopbackFDiagnostics The following WAN side parameters HOULD be supported. The mechanisms for diagnostics are the ones included in TR-0 and TR-0 using the following objects: WANDLInterfaceConfig.tats.CurrentDay WANDLInterfaceConfig.tats.QuarterHour WANIPConnection (attribute: RIPAvailable) WANPPPConnection (attribute: RIPAvailable, ExternalIPAddress, RemoteIPAddress, PPPLCPEcho, PPPLCPEchoRetry) Page of

Diagnostics and reporting of LAN side parameters, performance and devices (network level) MUT be supported. The mechanisms for diagnostics are the ones included in TR- 0 and TR-0 in the following objects: LANEthernetInterfaceConfig (attributes: tatus, MACAddress) R. R. R. Argument LANEthernetInterfaceConfig.{i}.tats LANUBInterfaceConfig (attributes: all except Enable) LANUBInterfaceConfig.{i}.tats WLANConfiguration (attributes: tatus, tandard, PossibleChannels, PossibleDataTransmitRates, TotalBytesent, TotalBytesReceived, TotalPacketsent, TotalPacketsReceived, TotalAssociations) Ping and traceroute diagnostic tools MUT be included in the HG to test connectivity in the WAN and LAN interfaces. The mechanisms for diagnostics are the ones included in TR-0 and TR-0 in the following profiles: IPPing: Traceroute: The HG MUT support diagnostics relating to CPU, memory and running processes. The following table describes the objects and associated parameters that MUT be manageable by the RM for remote device diagnostic management. The names of the parameters are descriptive and left to DL Forum to be further defined. Description DeviceDiagnostics.{i} Diagnosticstate Description IsOK DeviceDiagnostic.Errorlist DeviceDiagnostic.Errorlist.NumberError.DeviceDiagnostic.Errorlist.Event.{i} Date Object containing general diagnostics for the CPE. Indicates availability of diagnostic data. One of: None Requested Complete Value may be set to Requested to initiate the diagnostic test. When writing, the only allowed value is Requested. To ensure the use of the proper test parameters (the writable parameters in this object), the test parameters MUT be set either prior to or at the same time as (in the same etparametervalues) setting the Diagnostictate to Requested. When requested, the HG HOULD wait until after completion of the communication session with the RM before starting the diagnostic. When the diagnostic initiated by the RM is completed (successfully or not), the HG MUT establish a new connection to the RM to allow the RM to view the results, indicating the Event code " DIAGNOTIC COMPLETE" in the Inform message. hort description of the diagnostics. Normally a list of modules tested: CPU, memory, Routing daemons Whether the test results were positive (everything is OK) or errors were encountered. Object containing the errors, encapsulated with the event object Number of events (errors) contained in the Errorlist. Object used to encapsulate the errors happened during the diagnostics procedure. Date and time of occurrence of the event. Page of

Argument Type everity Description Type of the event. This is used to classify the events. The precise types of events to be supported depends on the capabilities of the HG and the involved diagnostic Define the seriousness of the event: Information: An event produced that can be used to track problems, collect statistics but that is not an error. Error: Error that will prevent that the HG can perform some of its functions, but the main ones will continue to work. Critical: Error that affects the normal operation of the HG: ome core functions of the HG will not be available. Description hort message describing / identifying the event. R. The following table describes the objects and associated parameters that HOULD be manageable by the RM for remote module diagnostics management. The names of the parameters are descriptive and left to DL Forum to be further defined. + Argument ModulesDiagnostics ModulesDiagnostics.ListTestableModules ModulesDiagnostics. IPDiagnostics ModulesDiagnostics. FirewallDiagnostics Description Object containing module diagnostics for the HG. List of the modules that can be tested remotely (comma-separated list of the names of the modules) Test IP functionality in the HG. This object is identical to DeviceDiagnostics Test the firewall and port mapping functionality in the HG. This object is identical to DeviceDiagnostics ModulesDiagnostics. ATA.. End device management... Device Identification Test the integrated ATA module (if present). This object is identical to DeviceDiagnostics R. R0. R. R. The HG MUT be able to discover and uniquely identify the managed devices connected to the home network. The HG HOULD be able to discover and uniquely identify the unmanaged devices connected to the home network. The HG HOULD be able to discover and uniquely identify the unmanageable devices connected to the home network. A database of devices (device repository) MUT be held in the HG. This database contains the results of the device discovery and capabilities detection mechanisms. + + Page of

R. Each record of the database defined in R MUT contain fields that can contain the following information: LAN side Private IP address and management port number. WAN side Public IP address and management port number (NA(P)T binding) Hardware (MAC) address ManufacturerOUI, which is the organizationally unique identifier of the Device manufacturer as provided to the Gateway by the Device as defined by []. erialnumber UUID (Universally Unique IDentity), as defined by RFC [] and given by the UDN in the UPnP Device Description. ProductClass Device Type Friendly name Manufacturer Model name Type of physical interface through which the ED is connected to the HG. Active flag (device connectivity status) Management protocol by which the device is manageable R. R. R. R. R. R. The database of R MUT enable the RM to distinguish the devices in the home network uniquely. This is required not only for root devices, but also for embedded devices. This may be achieved, for instance, by using UUID, and if the UUID is not available, using {ManufacturerOUI, erialnumber},{manufactureroui, ProductClass, erialnumber} or MAC address. This list of TR-0 manageable end devices as presented by the database of R MUT be the same as given by the InternetGatewayDevice.Managementerver.ManageableDevice.{i} object." The HG MUT update the database described in R with the IP and hardware addresses provided by the DHCP clients on the network. For every ED (managed and unmanaged), the HG MUT determine the IP address and hardware address from its ARP cache [], if not obtained via DHCP. The HG MUT read additional ID information provided by managed EDs of type D (see Table ) and update its database accordingly. The HG HOULD also read ID information provided by the DHCP options 0 (vendor class identifier) [], (client identifier) [], (User Class) [], (V-I vendor class) [] or for other managed and unmanaged devices, and update its database accordingly. + Page of

R0. R. The HG MUT contain an DP Control Point stack as defined in [] for the discovery of the ID information of managed EDs of type U and CU (see Table ) and unmanaged UPnP devices. The HG MUT be able to interpret all standardized UPnP Device Descriptions (XML schemas), and extract the mandatory device ID information from it, such as DeviceType and Friendly Name. R. When the ID-information is retrieved, the HG MUT update its database accordingly. R. The HG MUT discover embedded UPnP devices in UPnP root devices. R. R. R. R. R. A number of values in the database might be provided by the clients by means of DHCP as well as UPnP (Friendly Name, MAC and OUI). In the case of inconsistency, the HG MUT choose the DHCP values. For devices of type, The HG MUT be able to extract the IP URI or IP URI from the IP Register Message and register the discovered IP or IP URIs in the discovered devices data base. The HG MUT discover the managed devices placed behind an access point or a bridge in the same way as those directly connected to the HG. The HG MUT determine if the newly discovered ED supports DHCP, and/or UPnP, and/or CWMP, and if the ED is following the HGI recommendations (see section..). EDs that follow the TR-0 specs can be discovered as such, if they also use the mechanisms as defined in Annex F of TR-0 Amendment. Therefore, the HG MUT follow the TR-0 Amendment Annex F specification.... Activity discovery and Database management R. The database defined in R MUT be accessible by the AC by means of CWMP. R0. The entries in the device database defined in R MUT be kept even if the device is disconnected from the HN. R. The database defined in R MUT be able to store the data from at least devices. R. R. If more devices are discovered than can be stored in the database defined in R the oldest inactive entry MUT be removed from the database. The HG MUT support the byebye message in the UPnP discovery mechanism and update the active flag in the database defined in R. R. The default DHCP lease time from the HG MUT be 0000 seconds. R. The DHCP lease time MUT be configurable by the AC. Page of

R. If a device is present in the database defined in R, but has not been active (i.e. discovered by Gratuitous ARP or DHCP Inform) within a time equal to the DHCP lease time, the active flag MUT automatically be set to False. R. The active flag MUT be automatically set to False at the end of DHCP lease time (DHCP option )... Local HG management user interface... General R. The HG MUT provide a LM Remote UI which allows a user (via a browser in an ED) to interact with it. This interface is based on web technologies (http protocol). R. It MUT be possible for the RM to disable the LM Remote UI of the HG. R00. R0. The HG web server MUT support L/HTTP based remote access authentication on the basis of a static username/password configured in the HG. The HG remote access function MUT be able to be turned off via the LM Remote UI. The LM Remote UI HOULD support Remote control input and navigation, as defined by TV based user interfaces (e.g. CEA-0 []). + R0. The HG HOULD provide another UI, based on a command line interface such as telnet, or a serial cable connection. This interface MUT be password protected.... Design guidelines + R0. R0. R0. R0. The LM Remote UI MUT conform to the HTML standard as defined in WC specification (XHTML.0 []). The LM Remote UI HOULD conform to the CE-HTML standard (XHTML based standard provided as part of WebCE CEA-0 []). The LM Remote UI HOULD be designed for standard resolution of 0 x (: aspect ratio) and x (: aspect ratio). The LM Remote UI HOULD be scalable to support minimum DTV resolutions (NTC / VGA 0 x 0). + + The reference to CEA-0 is limited to the sections of that document that do not require UPnP (or other) features that are either not part of the HGI requirements or that are in contrast with other mandatory or optional requirements. Page of

... Operator Portal User Interface link R0. The LM Remote UI MUT be able to provide a link to a portal hosted by the operator, where the user can access additional functionalities related to the management of the HG that are not directly supported in the LM Remote UI. R0. The link MUT be coded as a URL that can be remotely configurable by the AC. R0. The LM Remote UI and the operator end user portal HOULD be designed using similar design paradigms and look and feel.... Contents and functionality + R0. R. R. The LM Remote UI MUT support at least user profiles: Administrator and General User including password authentication. Administrator. This profile can perform all the operations supported by the LM Remote UI, regardless of whether it affects managed services. A display warning message, reminding the user that the actions done with this profile may affect the managed services, HOULD be presented whenever the end user logs in with this profile. General User. All the operations that can be performed MUT NOT affect managed services. Therefore some restrictions may apply in accessing the interface pages The HG MUT support the ability to perform reset to factory default or boot safe profile (configuration and firmware) from the LM Remote UI. The LM Remote UI MUT include the following information: imple HG Device Information o o o o Manufacturer Name HG Name (Friendly) HG Model Firmware Version imple HG Network Information o o HG Hardware Address HG IP Address Device Information (per device) o o o o Device Name IP Address Hardware Address Device tatus Page of

R. The LM Remote UI MUT allow configuration of the following items: Firewall rules port forwarding (activation of pinholes) and NAT functionalities. ome abstractions, such as to define general security levels, HOULD be offered to simplify this task. User names and passwords of the profiles for the LM Remote UI. General user actions MUT NOT interfere with the existing RM configuration... Firmware management and updates R. The HG MUT support software and firmware upgrades from the RM. The main components to be updated are: Operating system and gateway firmware. This includes complete firmware updates or upgradeable modules. Module additions or removals, in the case of a modular gateway. For example, when a new hardware module is added or removed, the drivers and associated services enablers are included. DL-Forum TR-0 provides mechanisms for firmware upgrades. However, some additional mechanisms and specifications are needed. These add-ons are described in the following sections.... General R. R. Argument TR-0 Appendix A [] MUT be supported for software management and updates. This applies to the firmware of the HG. This requirement emphasizes current TR-0 functionality It MUT be possible to support software modules that can be upgraded remotely. Therefore, the TR-0 data model should be extended with the information included in the following table. The table describes the parameters that MUT be manageable by the RM for remote software module management. The names of the parameters are descriptive and left to the DL Forum to be further defined. Description Module.{i}. Identifier oftwareversion Object for installed module description. Description / Identification of the modules, which MUT be consistent with the list of modules attribute. A string identifying the software module version currently installed in the HG. To allow version comparisons, this element HOULD be in the form of dot-delimited integers, where each successive integer represents a more minor category of variation. For example, a version number can be.0. where the components mean: Major.Minor.Build. Page of

Argument EnabledOptions Description Comma-separated list of the option names of each. Option that is currently enabled in the HG. The mechanism is identical to the one defined for CPE firmware in the DL Forum TR-0. R. If software modules are supported, the TR-0 firmware upgrading mechanism MUT also be fully supported for software management and updates: The DOWNLOAD procedure will include a FileType that specifies the vendor and the module upgrade.... Firmware upgrades R. R. R0. R. R. R. R. The HG MUT support RM initiated firmware upgrades according to TR-0. This requirement emphasizes current TR-0 functionality. It MUT be possible to read the current HG firmware version via CWMP. This requirement emphasizes current TR-0 functionality. The HG HOULD control the firmware integrity (for example MD checksum) and authenticate the signature prior to the flashing procedure. Normal operation (last good state of network provisioning and configuration) of the HG MUT be re-established in terms of provisioning and configuration when the HG itself comes back after a power failure. The HG MUT provide a mechanism that guarantees that the basic functionality and connectivity to the RM can be recovered in the case of a failure of a software upgrade or installation of new software. The HG MUT provide a bootloader that works independently of the rest of the software. For recovery the following mechanisms are possible (one or the other): There is always (but maybe limited) default software together with a default configuration stored on the HG. If software upgrade fails (e.g. the HG is not booting anymore, incompatibilities with hardware are found, mismatch between software and configuration, etc.), the HG automatically loads his default software and configuration. Active notification to the RM is necessary. The HG has enough resources to always keep the latest running software and configuration. If a software upgrade fails the HG automatically reboots with the last good software and configuration. Notification to the RM is necessary. When upgrading the safe boot loader, the old version MUT NOT be overwritten but maintained in the HG memory until the integrity check of the new version has been successfully completed. + Page 0 of

... Configuration R. The HG MUT have a factory-default configuration. R. R. R. The HG factory-default configuration MUT work with any software/firmware and hardware and in particular MUT be able to establish connectivity to the RM. The HG MUT be able to be reset to the factory-default either by the LM Remote UI or by the reset button that HOULD be present. There MUT be two levels for the reset: Reset to factory default configuration Reset to last running software and configuration Note: this requirement is for the exceptional case when the HG is not accessible from the RM. The HG MUT be able to provide the current configuration parameters to the RM e.g. to allow the configuration to be periodically stored in a remote database. Note: This can be implemented using the TR-0 Upload method and the configuration file will be coded in a vendor specific format. R. The HG MUT provide a function that allows the restoration of the configuration parameters stored in the RM. uch events are RM initiated. This can be implemented using the TR-0 Download method, using the FileType attribute to Vendor Configuration File.... Application Layer Gateway Management R0. R. R. Name ALG The ALG list (see ection..) stored in the HG MUT be remotely accessible by the RM. The HG MUT allow the RM to enable or disable the ALGs. These changes can be made either by the RM or by the user through the local management interface (some restrictions may apply in the latter case). The HG MUT support a data model object required for the ALG management as described in the table below. The table describes the parameters that MUT be manageable by the RM for remote ALG management. The names of the parameters are descriptive and left to DL Forum to be further defined. Description ALG table object ALGNumberOfEntries Number of ALG entries Page of

Name ALG.Info.{i} Enable tatus Name Version Description Description Each instance contains objects associated a given ALG Enables or disables this ALG Indicates the status of the ALG entry. Enumeration of: Enabled Disabled Name of the ALG A string identifying the ALG version currently used in the HG A description of the ALG.. Multi-service provider management R. The HG MUT be manageable by one and only one RM at any one time. R. The HG MUT identify itself using DHCP option 0. Note however that the DHCP server may not respond to this request. This requirement emphasizes current TR-0 functionality.. Remote End-Device Access R. The HG MUT only allow remote access of any type on the basis of a set of ACLs. R. The HG MUT be able to set up a secure connection to a rd party AP or a remote user to support secure remote access to in-home devices/content. The tunnel can be set up between the remote entity and the HG or between the remote entity and the end device. R. ACL lists MUT be configurable both by the local administrator and by the BP. In the first case, the HG MUT support ACL configuration through a web server (the LM Remote UI)... Authentication and Authorization... Web Based Approach (LM Remote UI) R. The HG MUT use HTTP/L for the Web based approach. Page of

R. The HG User ACL MUT allow specification of the end-devices which are accessible by each authorized user. R0. Pinholes triggered by remote access log-in MUT be restricted to the source IP address of the authorized users. R. Any protocol session termination MUT close the corresponding pinhole in the HG.... IM Approach (+, to be applied in conjunction with ection.. only) R. The HG MUT support IM control plane integrity according to TIPAN / GPP / IM standards (IPsec) towards the P-CCF (Gm interface). R. The HG MUT have a public identity IMPU dedicated to Remote Access (addressing of the HG). R. The HG MUT support Authorization of Remote User based on P-Asserted Identity in the INVITE message. R. The HG MUT be able to replace the WAN IP address and Port number in the DP part of IP messages that are generated by local (and remote) end devices. * * * * R. Any IM session termination MUT close the corresponding pinhole in the HG. *.. Remote Access Configuration R. Remote access configuration by the user MUT be able to be done on either a temporary or permanent basis. The HG MUT support a timer so that access is automatically disabled after a configurable inactivity time (as a security precaution). R. All remote configuration attempts and the remote access to end devices MUT be logged in the HG. This log MUT be readable as a separate log by the AC.. ervice upport R. A dynamic DN client HOULD to be provided in the HG. + In the case of remote access through a proxy the source IP address of the user must be explicitly entered in the HG Page of

R0. The HG MUT support an NTP (RFC 0 [0]) or NTP (RFC 00 []) client. R. Information related to the NTP or NTP server MUT be advertised to the home devices using DHCP option. R. The HG MUT NOT implement any user-accessible function to reset time and date... ALGs R. R. The HG MUT support an Application Layer Gateway to support interoperability with NAT mechanisms for the below subset of the protocols identified in RFC 0 []: FTP RVP DN MTP IP H. NMP RealAudio The HG MUT provide an additional set of ALGs to support the following protocols: PPTP LTP passthrough IPsec passthrough single and multiple ICMP TELNET HTTP HTTPs POP NTTP RTP PPTP passthrough GRE tunnelling TFTP Page of

R. The following popular applications MUT be supported MN Messenger Yahoo Messenger MN Gaming Zone Windows Media Player DirectPlay (DirectX) Activision Games (e.g. Quake ) Blizzard Games (e.g. Diablo II) QuickTime AOL Instant Messenger R. ALGs MUT be able to be remotely disabled by the RM, on a per protocol or application basis.. Local IP devices registration R. The HG MUT support the discovery of IP devices in the home network R. The HG MUT be able to extract the IP URI from the IP Register Message (in order to support various types of local network services) R. The HG MUT locally register the discovered IP URIs... IP non IM Communication ervices upport (+) R0. The HG MUT implement a IP protocol stack according to RFC [] * R. The HG MUT support IP (RFC ) termination for VoIP communication to all Telephony interfaces One IP UA MUT be able to be mapped to any number of the embedded Telephony Interfaces (i.e. from up to the complete set) It MUT be possible to map each individual Telephony Interfaces to any number of the IP UAs (i.e. from up to the complete set) * Page of

R. R. R. If implemented, the IP UA embedded in the HG MUT support CLIP and CLIR (RFC []) Call Hold and Retrieve (RFC []) Call waiting (RFC [], using 0 response to the caller and second call indication to user) Call forwarding (CFU, CFB, CFNR) (RFC [], using response) CCB/automatic redial UBCRIBE/NOTIFY (RFC [] and RFC []) Call transfer (RFC []) Message Waiting Indication (RFC []) The HG HOULD support a local calling service, without any signalling traffic on the WAN, through an integrated IP proxy supporting the following features: Local IP forking (stateful proxy) direct routing for internal calls between FX and DECT or CAT-iq terminations CLIP (e.g. copy P-Asserted-ID to From) Click call Local database of IP UA on the LAN (built up by proxying REGITER messages) The HG MUT be the repository of IP URI, username and password assigned to the embedded IP UA(s) during the subscription procedure. * +* * R. The IP User Agent MUT be able to be remotely enabled/disabled * R. R. R. An IPsec VPN client in the gateway HOULD be present, in order to establish and terminate a VPN (but only for devices connected to the analogue phone ports of the gateway The HG HOULD support ecure RTP [] to protect VoIP data streams terminating in the embedded ATA TL or IPsec HOULD be supported to protect the signalling traffic for VoIP data streams terminating in the embedded ATA. +* +* +* Page of

.. IM communication services support (+)... IM Protocol tack R. The HG MUT support the IM protocol stack procedures as defined in GPP T. and TIPAN E 00 Technical pecifications. The following procedures MUT be supported: P-CCF Discovery Registration Deregistration Event Package ubscription Capability Exchange (Options method) ession Initiation ession Modification ession Release ubscription and Notification ession Unrelated procedure * R0. The HG MUT support RFC 0 []. * R. The HG MUT support RFC []. * R. R. R. R. R. The IM protocol stack MUT support at least one of the two following authentication methods : IM AKA with IIM authentication (compliant to GPP T.0). HTTP Digest Authentication (compliant to RFC ). The IM protocol stack MUT support HTTP Digest authentication for the registration procedure (on REGITER) and on other IP commands (INVITE, OPTION, UBCRIBE ) In the case of HTTP Digest Authentication, the HG MUT include the Authorization header in the REGITER message The HG MUT be able to use the credentials indicated in DL Forum TR-0 (AuthUserName, AuthPassword) for HTTP Digest Authentication. The HG MUT support the Gm interface between the HG itself and the IM Core as specified in GPP T. and TIPAN E 00. * * * * * The following IM parameters are needed by the HG: a private user identity; one or more public user identity; a home network domain name to address the IP REGITER request to. (TIPAN E 00) Page of

R. The HG HOULD support the Ut interface towards the Applications erver(s) based on XML Configuration protocol (XCAP) as defined in ETI T 0 [0]. +*... IM telephony user agent R. R. R0. R. R. R. The HG HOULD support authentication for XCAP sessions according to ETI T []: "Universal Mobile Telecommunications ystem (UMT); Generic Authentication Architecture (GAA); Access to network application functions using Hypertext and Transfer Protocol over Transport Layer ecurity (HTTP) (GPP T. [])". The Tel URI (URI for telephone numbers) MUT be supported (for interworking with PTN and PLMN) according to RFC []. The IM User Agent (UA) implemented in the BBUA MUT support Emergency calls as specified in GPP T. IP Multimedia ubsystem (IM) emergency session and ETI T 00 (TIPAN endorsement document of GPP T.). The IM UA MUT support the following upplementary ervices: Communication Diversion (CDIV) ETI T 00 [00] Originating Identification Presentation (OIP) ETI T 00 [0] Originating Identification Restriction (OIR) ETI T 00 [0] Terminating Identification Presentation (TIP) ETI T 00 [0] Terminating Identification Restriction (TIR) ETI T 00 [0] Communication Hold (HOLD) ETI T 00 [0] Communication Barring (CB) ETI T 0 [0] Message Waiting Indication (MWI) ETI T 00 [0] Conference (CONF) ETI T 00 [0] Malicious Communication Identification (MCID) ETI T 0 [0] Anonymous Communication Rejection (ACR) ETI T 0 [0] Call Completion Busy ubscriber (CCB) ETI T 0 [] Explicit Call Transfer (ECT) ETI T 0 [0] Advice of Charge (AoC) ETI T 0 [] The HG HOULD support XML schema for imulation ervices Configuration through the Ut interface as specified in ETI T 0 [0]. In relation to the transport protocol for real time applications (RTP), the following RFCs MUT be supported: RFC 0,,. +* * * * +* * Page of

R. RTP flow connection MUT be opened in the following two cases: after receiving a 00 OK message for voice after receiving a session progress provisional response for early media (an in band ringing tone is to be sent by the network).... IM Interworking * R. R. The HG MUT be able to connect IP IM UAs to embedded Telephony Interfaces. One IP IM UA MUT be able to be mapped to any number of the embedded Telephony Interfaces (i.e. from up to the complete set) It MUT be possible to map each individual Telephony Interfaces to any number of the IP IM UAs (i.e. from up to the complete set) In order to allow non-im devices to access the IM core, the HG MUT support a BBUA (Back to Back User Agent) for mapping IP message into IM message * * R. The BBUA MUT be able to access identity and authentication data (e.g. the IIM application if present) to support registration and authentication procedure.... Local registration and local services support * R. The HG HOULD support one or more public IMPUs that can correspond to a family IMPU identity and/or several family member IMPUs. R. The HG HOULD maintain a mapping between the IMPU family identity and the identities associated with each locally registered device in the home environment R0. The HG HOULD maintain a mapping between user identity (IMPU s) in the IM network and: device identities in the HN device identities embedded in the HG R. The HG MUT distinguish between a IP register message from a non-im IP device and a IP register message from an IM device (in order to support various types of local network services) +* +* +* * Family IMPU: IMPU family identity is a specific IMPU that can be shared by a number of possible devices in the house. The association between this identity and the various devices is managed by the HG Page of

R. The HG MUT support a mechanism to allow end devices to discover the local IP proxy/server using DHCP option 0 as defined in RFC []. R. The HG MUT support mechanisms to discover the AP s P-CCF and receive location information from the AC or CLF. * * R. The HG MUT forward the registration of an IM device towards the AP's P-CCF. * R. The HG MUT support the registration of a non-im IP device towards the AP's P- CCF declaring its own identity preconfigured in the device. R. The HG MUT support the registration of a non-im IP device towards the AP's P- CCF declaring as identity an IMPU pre-configured in the HG. R. The HG MUT allow the registration of a non-im IP device or client to a rd party AP s IP server in the network. * * * R. The HG MUT support local registration of non-im IP devices. * R. The HG HOULD support local registration of IP IM devices to a local IP proxy/server. R00. The HG HOULD support the case where a IP device registers a local IP URI e.g. terminalid@myhome, in the BBUA. The terminal-id part of the IP URI is an arbitrary text string that is preconfigured in the device. The domain name part of the IP URI is the address of the local IP server. R0. The HG HOULD implement mechanisms for handling the case where two IP devices register the same local IP URI, in order to support supplementary services such as call transfer or forking. R0. If a device registers a local IP URI to the HG proxy server, then the HG MUT register the associated public IMPUs, if not already registered, to the AP s P-CCF. In the case of an ATA associated with a public IMPU then this IMPU MUT always be registered. R0. If a device de-registers a local IP URI then the HG MUT de-register the associated public IMPUs if no other terminal requires this IMPU. R0. If a device is associated with multiple public IMPUs the preferred IMPU for outgoing calls HOULD be configurable in the HG via CWMP or the LM Remote UI. R0. It HOULD be possible to configure an alias for a local IP URI that can be used locally to address the device in the HN. R0. As soon as the HG receives an INVITE message addressed to a family member IMPU, it HOULD find all the devices associated with that IMPU and select those devices supporting the capabilities required (described in the DP of INVITE message). +* +* +* * * +* +* +* Page 0 of

... upport of call forking and call transfer inside the HN R0. The HG MUT send an INVITE to every device associated with the family IMPU when it receives an INVITE message addressed to the IMPU corresponding to a number associated with the family. Note that the HG must manage the local forking related to devices in its HN. R0. The HG MUT support a local call transfer service according to Explicit Call Transfer (ECT) ETI T 0 [] from an IMPU to an IMPU within the same HN. Note that the HG must manage the local call transfer related to devices in its HN.... Messaging * * R0. The HG MUT implement the transparent delivery of messages to the end user IMcapable devices in both page mode and session mode, as described in RFC and GPP T., T., T. (upport of messaging stage and stage ), endorsed by ETI TIPAN. R0. In the case of the use of non-im capable devices, the HG HOULD terminate the M delivery from the IM core in its IP UA. In this scenario: the HG MUT store M messages to be forwarded to the end devices. the HG MUT forward M messages to the end device(s) corresponding to the IM identity to which the M was sent When forwarding M messages to IP devices the HG MUT perform a signalling protocol adaptation. R. In the case of IM devices, when the end device is not registered to the IM core undeliverable messages MUT NOT be stored by the HG... Multimedia ervices upport * +* * R. The HG MUT support IGMP v/v (according to RFC []). R. The HG HOULD support the IGMP v Querier function (according to RFC []). + R. The HG HOULD support full IGMP v (RFC []). + R. The HG MUT only forward inbound multicast packets to those physical interfaces which are connected to devices that have joined the specific multicast group. R. The HG MUT implement an IGMP proxy mechanism. Page of

R. The HG MUT send IP multicast packets on WLAN interfaces to the unicast MAC address(es) of the recipient(s) (derived from IGMP signalling), i.e. the multicast MAC address must not be used. The IP destination address MUT NOT be modified. R. The HG HOULD be able to send IP multicast packets to the appropriate Ethernet port (s) and use the unicast MAC address(es) of the recipient(s) (derived from IGMP signalling), i.e. the multicast MAC address must not be used. The IP destination address MUT NOT be modified. +. ecurity R. R0. R. The HG MUT provide a function in the LM Remote UI to allow the user to modify high level configuration parameters of the HG (DL login and password, LAN and WLAN configuration etc.) through a web interface. The HG MUT support a Local Configuration ecured Access mechanism to authenticate the user (at least login password access control). Web based remote access: the AC or an accredited administrator MUT be authenticated by the HG in order to remotely access management functionalities (configuration, firmware download, Management Information Base access ). R. The connectivity authentication process HOULD be mutual. + R. The HG MUT support PPP CHAP (RFC ). R. The HG HOULD support EAP (RFC ) for connectivity authentication. + R. R. R. The HG HOULD be pre-configured with a unique certificate by vendors or a trusted Certificate Authority. In order to fulfil the strong authentication for remote management requirement, only ervice Provider s or Manufacturer's Certification Authority MUT be trusted. The HG HOULD be able to store and use cryptographic keys such as A private/public RA pair. The HG HOULD store ensitive data service authentication keys (login PPP, VoIP data for instance) in protected data storage areas + + + The remote access HOULD be based on cryptography like in standards L/TL, H combined with the use of certificates, or IPsec Even if access network provider and IP do not tend to be dynamically changed. To prevent situations in which the HG maintaining subscription to IP A attaches to IP B and possibly reveals some sensitive information, the network has to identify itself and get authenticated by the HG before the communication starts EAP is the next step in authentication evolution, since it can perform CHAP-like authentication using MD but is also extensible in the meaning that it allows to dynamically negotiate method to be used for authentication. Page of

R. R. The HG MUT support a pass-through mechanism for any kind of VPN including VPNs based on IPsec flows terminated on terminals. The HG MUT support at least simultaneous VPN pass-through sessions MUT be supported for different private networks and/or for different services having specific security requirements. R0. The HG MUT support NAT traversal techniques for VPNs... Parental Control (+) R. Access restrictions in the HG MUT be able to be set up via the LM Remote UI by the HG administrator based on device, time of day and application type, and arbitrary combinations thereof * R. The above access restrictions MUT be enforced in the HG * R. It MUT be possible to enable/disable the parental control function in a HG from the AC. * R. The Parental control function MUT NOT be applied to Guest Access devices * R. The HG MUT be able to be configured with the URLs of external servers (such as a Parental Control Proxy) by the AC or the LM Remote UI R. The parental control function MUT restrict access as per the PCP, if the PCP is active. This means blocking the service request and sending a deny information to the device if it is browser based R. The Parental Control Profile (PCP) MUT only be accessible and editable by the HG local administrator and via the LM Remote UI. * * * R. The default value of the PCP MUT be unrestricted access * R. On deactivation of the PCP, the settings in the PCP MUT be maintained. * R0. The HG MUT compile a log file tracking the blocking activity with reference to the applications/protocols used. In the case of access through a HTTP browser the HG MUT also send a notification to the end device from which the HTTP request has been sent. R. The Parental Control Profile in HG HOULD allow the local administrator to associate devices with pre-defined device groups based on sets of identified devices with defined access rights. In this case, the local administrator must be able to edit the device group name using the LM Remote UI. * +* Page of

.. Firewalling... Firewall management The RM has to remotely manage the internal firewall of the HG. To implement this operation, the RM downloads to the HG an XML file. This file integrates the basic firewall configuration that includes the HIGH and LOW configurations (see ecurity ection for more details) DL Forum TR-0 provides mechanisms for configuration file downloads. However, some additional mechanisms and specifications are needed to fully support the HGI requirements. R. R. The HG firewall parameters MUT be configurable via the RM. If this is done using a file, then the HG MUT only use the Download RPC defined in DL Forum TR-0. The version number of the firewall file MUT be readable by the RM to determine if an update is necessary. The HG MUT support the VendorConfigFile objects defined in the TR-0, indicating the name and the version of the basic firewall configuration. (Note: this VendorConfigFile is not included in the Baseline: profile). R. The status (HIGH, LOW) of the firewall of the HG MUT be readable by the RM. R. The HG MUT support the vendor specific parameters described in the following table for remote firewall configuration via the RM. The names of the parameters are descriptive and left to DL Forum to be further defined. 0 Name FWConfig tatus Date Description Vendor specific objects about the firewall Indicates the status of the firewall. Enumeration of: LOW HIGH Date and time when the status of the firewall was modified R. A stateful firewall MUT be implemented performing security control of any incoming flow entering the HN through the HG (note: this does not apply to bridged traffic) Page of

R. R. R. R0. R. At least the following basic firewall configuration MUT be supported by the HG: Configuration HIGH: DROP by default WAN --> LAN: to refuse TCP YN, to refuse connections INVALID, NEW, RELATED in TCP, UDP and ICMP; to authorize already established connections (and known by the stateful firewall) LAN --> WAN: to authorize known ports: o o o o o o o o MTP 0 HTTP 0 (TCP) - POP L EMTP (TCP) - POP - NTP - EMTP to refuse ports 0/UDP, 0/UDP and WIN A second alternative basic firewall configuration HOULD be supported by the HG Configuration LOW: ACCEPT by default o o WAN --> LAN: to refuse ports,, (NETBIO) LAN --> WAN: all authorized. DMZ support MUT be provided by the firewall in cooperation with the routing and address translation (NAT) or port address translation (PAT) capabilities of the HG. The HG MUT reject packets from the WAN with MAC addresses of devices on the local LAN or invalid IP addresses (e.g. broadcast addresses, private IP addresses or IP Addresses matching those assigned to the LAN egment). The HG MUT reject any unidentified Ethernet packets (i.e. any packet that is not associated with IP or PPPoE protocols). + R. The firewall configuration MUT be able to be remotely configured by a BP via CWMP. R. For Guest Access traffic the HG MUT provide Denial of ervice protection only (i.e. no other firewalling will be enabled for the Guest traffic)..0 Quality of ervice This section specifies the Qo datapath functions which need to be supported by the HG, and the Qo management objects which are used to configure Qo policy within the HG. Core Qo traffic management functions include classification, marking, congestion management, queuing, shaping, and egress scheduling. Page of

0 Figure shows a conceptual view of the core Qo traffic management functions as packets are received from the LAN ingress ports or from internal HG sources. This diagram is not meant to determine the implementation structure of the Qo functions nor those of the related datapath functions. LAN Ingress LAN Ingress LAN Ingress n HG traffic source Classifica tion DCP & L Marking Bridging, NAT/ Routing, Firewall HG traffic sink Upstream Congestion Management LAN Congestion Management WAN Class shaping & queuing LAN Queuing Figure Qo Functions from LAN Ingress WAN Port cheduler & haper LAN Ports cheduler WAN Egress WAN Egress WAN Egress n LAN Egress LAN Egress LAN Egress n Figure shows a conceptual view of the core Qo traffic management functions as packets are received from the WAN ingress ports. Note that while these are logical WAN ports, there is only one Physical WAN port. This diagram is not meant to determine the implementation structure of the Qo functions nor those of the related datapath functions. WAN Ingress WAN Ingress WAN Ingress n Classifica tion DCP & L Marking Bridging, NAT/ Routing, Firewall LAN Congestion Management LAN Queuing LAN Ports cheduler LAN Egress LAN Egress LAN Egress n 0 HG traffic sink Figure Qo Functions from WAN Ingress These functions are described in turn below..0. Classification of traffic Packet classification is done using a combination of the ingress header fields. The output of the classification process is a set of decisions about the subsequent handling of that packet. The classification process determines the layer and layer egress marking, handling by the congestion management function, and (in combination with the forwarding decision) the allocation of the packet to an egress queue..0.. Requirements for Classification of packets received upon the WAN ingress The requirements in this subsection pertain to packets received upon the WAN ingress port. Page of

R. The HG MUT classify all packets received on the WAN ingress port. R. R. The HG MUT be able to set the home network priority level for each packet by setting the DCP bits on the basis of the classification result. The HG MUT assign each packet to the appropriate egress queue, drop the packet, or deliver it to an internal sink, on the basis of the classification result combined with the forwarding decision. NOTE: the packet drop in this context refers to an ingress security function where packets may be dropped as a direct result of classification. R. The HG MUT be able to classify packets based upon IP destination address. R. The HG MUT provide a configurable IP destination subnet mask, so that classification is performed only upon the network prefix bits of the IP destination address. R. The HG MUT be able to classify packets based upon IP source address. R0. The HG MUT provide a configurable IP source subnet mask, so that classification is performed only upon the network prefix bits of the IP source address. R. The HG MUT be able to classify packets based upon the DCP field. R. R. R. The HG MUT be able to classify packets based upon the Protocol field in the IP header (e.g. ICMP, IGMP, TCP, UDP, ). The HG MUT be able to classify packets based upon source TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG. This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic. The HG MUT be able to classify packets based upon destination TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG. This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic. R. The HG HOULD be able to classify packets based upon IP packet size. + R. The HG MUT be able to classify packets based upon any combination of up to of the WAN ingress classification parameters R. The HG HOULD be able to classify packets on any combination of the WAN ingress classification parameters. For ATM based access systems, the following requirements also apply + R. The HG MUT be able to classify packets based upon ATM VPI/VCI Page of

Where Ethernet is present on the access link, the following requirements also apply R. R0. The HG MUT be able to classify packets based upon Ethernet priority, as defined in IEEE 0.D The HG MUT be able to classify packets based upon VLAN ID, as defined in IEEE 0.Q R. The HG MUT be able to classify packets based upon MAC source address R. The HG MUT provide a configurable MAC source address mask, so that classification is performed only upon bit fields within the MAC source address determined by this source address mask. R. The HG MUT be able to classify packets based upon MAC destination address R. The HG MUT provide a configurable MAC destination address mask, so that classification is performed only upon bit fields within the MAC destination address determined by this destination address mask. R. The HG MUT be able to classify based upon the Ethernet Length/Type field..0.. Requirements for Classification of LAN-LAN traffic Normally, traffic which enters the gateway on an Ethernet port and leaves from another Ethernet port is subject to the simple classification described in ection.0... In some cases such traffic may require deeper classification. For example, traffic destined to a particular Ethernet port may require deeper classification. The following requirements pertain to the handling of traffic received on the LAN Ethernet ports. R. R. The HG MUT support the simple classification of bridged packets as described in section.0.. The HG HOULD be able to classify packets received on LAN ingress ports and destined to designated LAN Ethernet egress ports according to the multi-field classification described in ection.0... + 0 R. The designated LAN Ethernet egress ports MUT be configurable from the AC. Note that multi-field classification of LAN-LAN traffic may have performance implications..0.. Requirements for Multi-field Classification packets received on the LAN ingress ports The following requirements pertain to the classification of packets received on the LAN ingress ports which are destined for the WAN or are bridged to the LAN after multi-field classification. There is an alternative, simpler classification set for locally bridged, LAN-LAN traffic. Page of

R. The HG MUT classify all packets received on the LAN ingress ports R0. R. R. R. For packets bridged to the LAN, the HG MUT be able to set the home network priority level for each packet by setting the DCP bits on the basis of the classification result. Note: at the classification stage, the means of determining whether the packet will be bridged to the LAN is beyond the scope of this specification. For packets sent to the WAN, the HG MUT be able to set DCP and L egress markings including VLAN QTAG including priority field, for each packet on the basis of the classification result. Note: at the classification stage, the means of determining whether the packet will be sent to the WAN is beyond the scope of this specification The HG MUT assign each packet to the appropriate egress queue, drop the packet, deliver it to application layer logic, or deliver it to internal sink, on the basis of the classification result combined with the forwarding decision. The HG MUT be able to classify packets based upon the LAN type (Ethernet, Wi-Fi, etc.) R. The HG HOULD be able to classify packets based upon physical port. + R. The HG MUT be able to classify packets based upon MAC source address R. The HG MUT have a configurable MAC source address mask, so that classification is performed only upon bit fields within the MAC source address determined by this source address mask. R. The HG MUT be able to classify packets based upon Wi-Fi ID R. The HG MUT be able to classify packets based upon MAC destination address R. The HG MUT have a configurable MAC destination address mask, so that classification is performed only upon bit fields within the MAC destination address determined by this destination address mask. R0. The HG MUT be able to classify packets based upon IP destination address R. The HG MUT provide a configurable IP destination subnet mask, so that classification is performed only upon the network bit field within the IP destination address as determined by this destination subnet mask. R. The HG MUT be able to classify packets based upon IP source address R. The HG MUT provide a configurable IP source subnet mask, so that classification is performed only upon the network bit field within the IP source address as determined by this source subnet mask. R. The HG MUT be able to classify packets based upon DCP. R. The HG MUT be able to classify packets based upon the Protocol field in the IP Header (e.g. ICMP, IGMP, TCP, UDP, ). Page of

R. R. The HG MUT be able to classify packets based upon source TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically Within the HG. This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of an application layer logic. The HG MUT be able to classify packets based upon destination TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG. This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of an application layer logic. R. The HG HOULD be able to classify packets based upon IP packet size + R. R00. The HG MUT be able to classify packets based upon any combination of up to of the LAN ingress classification parameters The HG HOULD be able to classify packets on any combination of the LAN ingress classification parameters. +.0.. Requirements for Classification of packets received on the LAN ingress using information determined by DHCP The classifier can use several LAN-side fields as classification keys. In addition to other means, the HG can learn classification keys through DHCP client requests that it services. In this case, the HG associates information conveyed to the HG in a DHCP client request with a corresponding MAC or IP address. The following sets out requirements for support of classification using keys learned in DHCP client requests. R0. R0. R0. R0. R0. The HG MUT be able to interpret DHCP option 0 messages received on LAN ports and associate a vendor class ID with a source IP address so that the source IP address can be used as a classification parameter. The HG MUT be able to interpret DHCP option 0 messages received on LAN ports and associate a vendor class ID with a source MAC address so that the source MAC address can be used as a classification parameter. The HG MUT be able to interpret DHCP option messages received on LAN ports and associate a client identifier with a source IP address so that the source IP address can be used as a classification parameter. The HG MUT be able to interpret DHCP option messages received on LAN ports and associate a client identifier with a source MAC address so that the source MAC address can be used as a classification parameter. The HG MUT be able to interpret DHCP option messages received on LAN ports and associate a user class ID with a source IP address so that the source IP address can be used as a classification parameter. Page 00 of

R0. R0. The HG MUT be able to interpret DHCP option messages received on LAN ports and associate a user class ID with a source MAC address so that the source MAC address can be used as a classification parameter. The HG MUT be able to interpret DHCP option messages received on LAN ports and associate a V-I Vendor-pecific Information with a source MAC address so that the source MAC address can be used as a classification parameter. R0. The HG MUT be able to interpret DHCP option messages received on LAN ports and associate a V-I Vendor-pecific Information with a source IP address so that the source IP address can be used as a classification parameter..0.. Requirements for Classification of bridged packets received on the LAN ingress ports The following requirements pertain to the classification of packets received on the LAN ingress ports which are destined for the LAN, i.e. simply bridged in the HG. R0. The HG MUT classify all packets received on the LAN ingress ports R0. The HG MUT assign each packet to the appropriate egress queues on the basis of the classification result combined with the forwarding decision R. The HG MUT be able to classify packets based upon MAC source address R. The HG MUT be able to classify packets based upon MAC destination address R. The HG MUT be able to classify packets based upon a combination of the classification parameters described in this section..0.. Requirements for Classification of internally generated packets R. The HG MUT be able to classify all packets generated internally within the HG R. R. For packets sent to the LAN, the HG MUT be able to set the home network priority level for each packet by setting the DCP bits on the basis of the classification result. Note: at the classification stage, the means of determining whether the packet will be sent to the LAN is beyond the scope of this specification. For packets sent to the WAN, the HG MUT be able to set the DCP and L egress markings (including the VLAN QTAG priority field), for each packet on the basis of the classification result. Note: at the classification stage, the means of determining whether the packet will be sent to the WAN is beyond the scope of this specification Page 0 of

R. The HG MUT assign each packet to the appropriate egress queue or deliver it to application layer logic, on the basis of the classification result combined with the forwarding decision. R. The HG MUT be able to classify packets based upon IP destination address. R. The HG MUT provide a configurable IP destination subnet mask, so that classification is performed only upon the network prefix bits of the IP destination address. R0. The HG MUT be able to classify packets based upon IP source address. R. The HG MUT provide a configurable IP source subnet mask, so that classification is performed only upon the network prefix bits of the IP source address. R. The HG MUT be able to classify packets based upon the DCP field. R. R. R. The HG MUT be able to classify packets based upon the Protocol field in the IP header (e.g. ICMP, IGMP, TCP, UDP, ). The HG MUT be able to classify packets based upon source TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG. This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic. The HG MUT be able to classify packets based upon destination TCP/UDP port number or range of port numbers. Port numbers may be either statically configured or determined dynamically within the HG. This specification does not specify methods for dynamic determination of port number. This could be done, for example, by use of application layer logic. R. The HG HOULD be able to classify packets based upon IP packet size. + R. R. The HG MUT be able to classify internally generated voice packets based upon physical port The HG MUT be able to classify packets based upon any combination of up to of the classification parameters R. The HG HOULD be able to classify packets on any combination of the classification parameters..0. LAN-side VLAN support + R0. The HG MUT NOT add VLAN headers to any frames which are transmitted on a LAN side port Page 0 of

R. The HG MUT be able to receive VLAN tagged or priority tagged frames on any of its LAN ports. Where these frames are locally bridged to the LAN, the VLAN ID and priority tag MUT be forwarded unchanged. 0 0 R. Where VLAN or priority tagged frames received on the WAN are bridged to the LAN, the VLAN ID and priority tag HOULD either be forwarded unchanged or removed. This MUT be configurable from the remote management server..0. Classification Rule ets.0.. Overview This section describes requirements in the HG for classification rule sets, which are sets of individual classification rules as defined in ection.0.. This section also describes requirements for sequencing among the classification rule sets. During classification, individual classification rules are checked for a match with the corresponding fields in each packet. A rule-match occurs when all the individual classifiers within that rule match. A rule set is an associated collection of rules. The internal representation of the classification rules and rule sets is not specified. There are four distinct classification rule sets which are present in the HG. They are: WAN_Rule_et, which embodies the classification rules for packets arriving on the WAN ingress. LAN_Rule_et_, which embodies the classification rules for LAN-WAN traffic, and LAN-LAN traffic which is multi-field classified LAN_Rule_et_, which embodies the classification rules which are used to identify LAN-WAN service instances as part of the overload protection mechanism LAN_Rule_et_, which embodies the classification rules for LAN-LAN traffic which is bridged through the HG with no multifield classification..0.. Requirements for Classification Rule ets + R. The HG MUT support a classification rule set for WAN ingress (WAN_Rule_et) R. R. R. The classification rules associated with WAN_Rule_et MUT only be able to be configured by remote download from the AC. The HG MUT support classification rule sets for LAN ingress: LAN_Rule_et_, LAN_Rule_et_, and LAN_Rule_et_ The classification rules associated with LAN_Rule_et_ MUT be able to be configured by remote download from the AC and MUT be able to be modified by the local Application Layer Logic (e.g. the DHCP options). Individual rules associated with LAN_Rule_et_ are formed according to requirements in ection.0.. Page 0 of

R. R. Individual rules associated with LAN_Rule_et_ MUT only be created internally in the HG. (For example, such rules may be created in response to an event, such as signalling that informs the RG that a voice flow is about to start; the HG may use the information received from this signalling to create classification rules that identify the subsequent voice flow) LAN_Rule_et_ contains additional rules for bridged, LAN-LAN traffic. Individual rules associated with LAN_Rule_et_ are formed according to requirements in ection.0... These MUT be able to be downloaded from the AC. R. The rules defined in R HOULD be able to be entered locally by the user. + R0. For each rule in LAN tables and it MUT be possible to configure a pointer to an additional, per packet operation (e.g. application layer logic). The mechanism described in R is an example of this kind of per-packet operation. R. The HG MUT support a minimum of concurrent rules for WAN_Rule_et_ R. The HG MUT support a minimum of concurrent rules for LAN_Rule_et_ R. The HG MUT support a minimum of concurrent rules for LAN_Rule_et_ R. The HG MUT support a minimum of concurrent rules for LAN_Rule_et_.0.. Requirements for equencing Among Classification Rule ets R. R. For routed LAN-WAN traffic, the rules in LAN_Rule_et_ MUT be tested first (i.e. before the rules in LAN_Rule_et_). The first rule match in any Rule_et MUT terminate the classification process for that packet. Note; that if more than one rule match is possible for a given packet, the terminating match will depend on the order in which the rules are specified R. The gateway MUT process the rules in the sequence in which they are configured R. If there is no rule match in LAN_Rule_et_, then the rules in LAN_Rule_et_ MUT be tested R. For WAN-LAN traffic, the rules in the WAN_Rule_et MUT be tested R0. It MUT be possible to configure a default classification in the event of no rule match Testing means that all the classifiers in a rule are checked for a match with the corresponding field in each packet. A rulematch occurs when all the classifiers match. Page 0 of

0.0. Overload Protection Mechanism The following requirements relate to the overload protection mechanism. This description is an example of a protection mechanism; alternative protection mechanisms may be employed. The protection mechanism utilizes an Instance Table within the HG. The Instance Table is used by the HG to record instances of services which have been recognized by the classification using the LAN_Rule_et_. The formulation of the Instance Table is vendor-specific. R. The HG HOULD support a mechanism (e.g. an ALG) which: i. differentiates instances of a service on the basis of one or more single, configured parameters (e.g. IP A) ii. creates a service instance Table entry, for each newly recognised instance of the specified service, subject to a configurable limit. This allows the maximum number of service instances to be constrained if required. There needs to be a Table for each service for which this technique is used iii. increments a packet count every time a recognised service instance packet is classified iv. performs a real time check of each service instance packet count against a configurable upper and lower limit (i.e. < InactivePackets per ampleinterval, > ActivePackets per ampleinterval) v. checks whether a configurable queue length threshold (QueueThreshold) has been exceeded during the same ampleinterval time period vi. when the upper limit is exceeded without the queue length threshold being exceeded, a new classification rule is added to the Rules Table. This rule which is a copy of the non-instance specific rule, with the appropriate instance identifier added, and the queue changed to that appropriate for an established flow. vii. when the lower limit is not met, the instance specific rule is deleted from the Rules Table viii. marks the most recently established flow in some way. This would be typically used by a separate process to delete this service instance rule in the event of subsequent congestion.0. Qo Mappings Note: This section is informative and not normative except where specific requirements are listed and it provides guidance on the use of Qo Markings in the home LAN..0.. Integrated Access Devices The following requirement pertains to the use of priority markings for integrated wireless or powerline access devices within the HG. + R. If both layer and layer egress markings are used, the marking action associated with the classification rules HOULD be configured so that layer and layer markings follow the correspondence with service classes as shown in Table. + Page 0 of

HGI Layer Diffserv WMM / 0.e Layer PLC PLC ( Level) ( Level) ervice Class Transit BE Data Downstream BE Data Transit VA Downstream Video Downstream Voice 0x00 0x 0x0 0x 0x DCP Access Category AC_BE (AC) AC_BE (AC) AC_VI (AC) AC_VI (AC) AC_VO (AC) Channel Access Priority Priority (CA) Priority (CA) Priority (CA) Priority (CA) Priority (CA) CA0 CA CA CA CA Channel Access Priority Table Correspondence between ervice Classes and HG Egress Markings.0. Dropping/Congestion Management 0 The congestion manager monitors the buffer resource consumption by tracking the depth of each class queue for each out-going port. The congestion manager will either permit or deny the packet from being enqueued into the class queue based on the Random Early Discard algorithm. The following requirements pertain to congestion management functions in the HG. R. R. The HG MUT support Random Early Discard (RED) [] for the upstream queues and the LAN egress queues The operation of the RED function in either direction MUT be configurable from the AC for each queue R. The HG MUT support the RED function to be disabled in either direction. R. R. R. R. The HG MUT allow independent configuration of the maximum threshold parameter for RED in each direction. The HG MUT allow independent configuration of the minimum threshold parameter for RED in each direction The HG MUT allow independent configuration of the w_q (weighting factor) parameter for RED in each direction The HG MUT allow independent configuration of the maximum probability parameter for RED in each direction Page 0 of

.0. Class Queue structure and cheduling.0.. Queuing into the WAN Egress port The following requirements apply to the HG s upstream queues and scheduling those queues into the WAN. R0. The HG MUT support at least five class queues at the WAN egress interface R. The HG HOULD support at least eight class queues at the WAN egress interface + R. The HG MUT provide a configurable mapping between WAN egress queues and logical layer WAN ports (i.e. ATM VC or VLAN) R. The HG MUT support configurable shaping per WAN class queue R. The HG HOULD be able to configure each queue for strict priority or Weighted Round Robin scheduling + R. The HG MUT support at least strict priority queues R. The HG MUT support at least queues which use Weighted Round Robin scheduling R. The HG MUT provide a mechanism to prevent starvation of the WRR queues by the strict priority queues. The starvation prevention mechanism is vendor-specific but it MUT be able to be configured in terms of an average, absolute minimum bandwidth (in kbps) which is available to the WRR queues if they need it. If this bandwidth is not required then it MUT be available to the strict priority queues. R. The Round Robin weights MUT be individually configurable R. R0. R. R. R. R. The first strict priority queue MUT be given priority over all other queues i.e. served until exhaustion except when subjected to the starvation prevention mechanism for lower priority queues. Note: this queue would typically be used for voice. The second strict priority queue MUT be given priority over all other queues except the first strict priority queue, except when subjected to the starvation prevention mechanism for lower priority queues. Note: this queue would typically be used for video The first strict priority queue MUT provide very low jitter for voice packets. The first strict priority queue MUT be serviced straight after every single packet is scheduled from any other queue. When all strict priority queues are empty, the WRR queues MUT be serviced according to their weighting priority and subject to any per queue shaping limit. The HG MUT support aggregate shaping into each WAN egress logical layer port, i.e. the overall rate at which all queues are serviced is dependent on this shaping value. Requirements R0, R, R, R, R, R, R, R, R, R0, R, R and R MUT be met for every layer WAN connection. Page 0 of

.0.. Queuing into the LAN Egress ports The following requirements pertain to the HG s LAN egress class queue structures and scheduling from those queues into the port level. R. The HG HOULD support queuing of data from any source into the LAN egress queues (as a result of the classifier) + R. The HG MUT implement at least four class queues for each LAN egress port R. The HG MUT support at least strict priority queues per LAN egress port R. The HG MUT support at least queues which use Weighted Round Robin scheduling per LAN egress port R. The Round Robin weights MUT be individually configurable R0. R. The first strict priority queue MUT be given priority over all other queues i.e. served until exhaustion The second strict priority queue 0 MUT be given priority over all other queues except the first strict priority queue, but might not be served to exhaustion R. When all strict priority queues are empty, the WRR queues according to their weighting priority. MUT be serviced.0.. Example of Queuing Configuration Table provides an example of a queuing configuration that may be configured in the HG. This queue would typically be used for WAN ingress Managed ervices 0 This queue would typically be used for transit streaming (audio/video/voice) traffic One of the WRR queues would typically be used for WAN ingress best efforts traffic, and the other for transit best efforts traffic. Page 0 of

Direction Purpose cheduling into Port Upstream Voice trict Priority (highest) Upstream Video trict Priority (next) Upstream Temporary Voice W Weighted Round Robin Upstream Premium Data, GPR Data, Game Data W Weighted Round Robin Upstream Best Effort Data W Weighted Round Robin Downstream Managed ervices trict Priority (highest) Transit LAN streaming trict Priority (next) Downstream Best Effort Data W Weighted Round Robin 0 Table Example of Queuing Configuration.0. Requirements on Queue tatistics This section defines requirements for the monitoring of egress queues for the purposes of service assurance (helpdesk etc.). These counters maintain information related to the events accumulated over sample and report intervals. For all counters that have an associated sample interval, sample intervals are sequential, for example a 0 second sample interval is accumulated, the result (total of events) computed, and a new sample interval started. A report interval is a defined number (called report sample) of sample intervals. The statistics reported are the last complete report interval result (total over report sample intervals) and the current partial report interval result..0.. ervice class monitoring on a per queue basis The following requirements apply to all WAN, LAN and WLAN egress queues. R. R. All the following counters MUT be available for each WAN, LAN and WLAN egress queue. Every counter MUT be reset upon reception of an appropriate single management command. R. All counters MUT be individually resettable via management command R. Every counter MUT be reset by a reboot. R. The current value of all counters MUT be able to be read by the remote management system. Page 0 of

R. The HG MUT have a single configurable sample interval. The sample interval MUT be configurable from to 0 minutes. R. The sample intervals for all counters MUT be synchronised. R0. The HG MUT store the last N results for the sample interval counters, where N is configurable from to. (NOTE: this together with the last requirement should store at least a day s worth of data) R. The HG MUT maintain a running count of the number of dropped packets. R. The HG MUT maintain a sample interval count of the number of dropped packets. R. The HG MUT maintain a running count of the number of emitted packets. R. The HG MUT maintain a sample interval count of the number of emitted packets. R. The HG MUT maintain a running count of the number of emitted bytes R. The HG MUT maintain a sample interval count of the number of emitted bytes. R. The HG MUT store the peak queue occupancy counted in packets. R. The HG MUT be able to provide the peak percentage queue occupancy R. The HG MUT store the peak queue occupancy in packets for each sample interval R00. The HG MUT be able to provide the peak percentage queue occupancy for each sample interval 0.0. Requirements for Admission Control (+) The Admission control function is specified as two sets of requirements. The first set describes the generic Admission Control function. The second set describes requirements to support a specific use case, namely multi-terminal, multi-line IP- based voice. Further use cases and their specific additional requirements, could be added in future HGI releases based on the same model. In the requirements below, the CAC Class is a conceptual grouping of services, each of which are admission-controlled within a particular bandwidth limit. Classifiers are used to identify flows as belonging to services within a CAC class. There is a bandwidth limit for each CAC Class. A running total of bandwidth being used by flows within each CAC Class determines how much bandwidth remains. For services within a particular CAC Class, new flows are admitted only when there is available bandwidth remaining within that CAC Class. R0. The HG MUT support a CAC function for both inbound and outbound sessions. * Page 0 of

R0. R0. R0. R0. R0. R0. R0. R0. The CAC function MUT operate on a per-cac class basis Note: the Qo classifier for more than one service can be mapped to the same CAC class. This allows (but does not require) more than one service to be included in a single CAC class. The HG MUT be able to calculate and store locally a running total of the bandwidth requested for all the accepted sessions in progress for each CAC class The HG MUT be able to check the requested bandwidth plus the current total for that CAC class against a configurable, per CAC class limit. The HG MUT be able to check the requested bandwidth, plus the sum of all the CAC class running totals against the upstream bandwidth minus a configurable value. If the resulting total requested bandwidth does not exceed either of the above limits, the session signalling MUT be passed on unmodified, and the requested bandwidth MUT be added to the running bandwidth total for that class, otherwise the session MUT be rejected locally, and the requested bandwidth MUT NOT be added to the running total. The HG MUT generate a unique identifier (ession ID) for each accepted session, and store this with the bandwidth requested for that session. The HG MUT be able to monitor all session termination messages (including those which indicate that the session has not been accepted by the called party) and decrement the running bandwidth total by the bandwidth associated with that session as identified by the ession ID. The HG MUT delete the ession ID and bandwidth for the terminated session. The HG MUT provide a mechanism to clean up the state relating to the CAC mechanism so as to allow for abnormal session terminations. For example, this could be a mechanism which monitors the number of packets sent in the queue associated with that CAC class and resets the appropriate running bandwidth total to zero when there has been <0 such packets during the previous T minutes. If the bandwidth total is reset to zero, then all ession IDs and bandwidths associated with that class must be cleared. The running bandwidth totals for all service classes MUT be able to be reset to zero by a single management command. All ession IDs and bandwidths MUT be cleared by the same, single management command (this will not have any impact on existing media flows). The HG CAC function MUT be able to be enabled or disabled by the Remote Management ystem * * * * * * * * R0. All CAC parameters MUT be able to be set via the Remote Management ystem *.0.. BBUA requirements for CAC using IP signalling R. The IP BBUA MUT interact with the CAC function prior to allowing the call * Page of

R. R. R. R. R. R. For all accepted calls, the IP BBUA MUT forward the IP messages and store the ession ID with the call bandwidth. For all locally rejected calls, the IP BBUA MUT return a NOT ACCEPTABLE (0) message to the calling party For all locally rejected calls, the IP BBUA MUT NOT forward the IP messages, to prevent the call being placed. The IP BBUA MUT be able to read the (optional) Bandwidth parameter in the embedded DP string If the optional bandwidth parameter is not set, the IP BBUA MUT read the codec type in the IP INVITE header. The HG MUT provide a configurable mapping table between codec type and bandwidth. The IP BBUA MUT monitor IP BYE messages and use these as the trigger for the HG to decrement the running bandwidth total for that CAC class by the amount associated with that ession ID. * * * * * *.0.. LAN Interface Capacity Monitoring The following can form part of the information that a network-based CAC system can collect to assess service delivery capability. R. R. The HG HOULD be able to monitor the downstream physical layer rate of designated LAN interfaces in order to measure the available bandwidth on those interfaces and report them to a centralized, network based (for example) CAC function as described in the following requirements. The HG HOULD be able to generate and store locally a historical measurement of the physical layer rate of each designated interface in the following form: the rate (R hist ) that was exceeded for x% of the previous t minutes. +* +* 0 R0. The HG HOULD be able to send the R hist value to the AC when it changes and is less than the current WAN downstream PHY rate..0.0 Qo Requirement Mapping to TR-0 These Tables illustrate the mapping of HGI Qo requirements to TR-0 objects and parameters. They do not include: the CAC configuration parameters classifier for internally generated traffic queue congestion statistics as these are not currently covered in TR-0. The following abbreviations are used in these Tables: +* Page of

Abbreviation R W C Description Readable. Readable and writeable. Object instances can be created and deleted Name Type HGI InternetGatewayDevice.QueueManagement. - Enable MaxQueues R R0: WAN egress: must be at least plus R: LAN egress: per LAN egress interface R: WAN egress: should be at least plus R: LAN egress: per LAN egress interface. MaxClassificationEntries R R: WAN ingress: must be at least plus R: LAN ingress:, i.e.. ClassificationNumberOfEntries MaxQueueEntries R R, R: must be at least trict Priority queues R: WAN egress: must be at least WRR queues (so must be at least WAN queues per egress interface) R: LAN egress: must be at least WRR queues (so must be at least LAN queues per egress interface) QueueNumberOfEntries DefaultQueue W R0 DefaultDCPMark DefaultEthernetPriorityMark InternetGatewayDevice.QueueManagement.Classification.{i}. ClassificationEnable Classificationtatus ClassificationOrder ClassInterface W R: WANConnectionDevice instance: VPI/VCI R: LANxxxInterfaceConfig instance: physical port R: WLANConfiguration instance: WLAN ID DestIP W R: WAN ingress R0: LAN ingress DestMask W R: WAN ingress R: LAN ingress ourceip W R: WAN ingress R: LAN ingress ourcemask W R0: WAN ingress R: LAN ingress Protocol W R: WAN ingress R: LAN ingress DestPort W R, R: will be used only when the port can be statically configured. If application layer logic is required in order to determine the port number, the HG will presumably support the standard TR-0 QoDynamicFlow: profile. DestPortRangeMax W R, R W R R R R C W R W Page of

Name Type HGI ourceport W R, R: WAN ingress: will be used only when the port can be statically configured. If application layer logic is required in order to determine the port number, the HG will presumably support the standard TR-0 QoDynamicFlow: profile. ourceportrangemax W R, R ourcemacaddress W R: LAN ingress R: transit ourcemacmask W R: LAN ingress DestMACAddress W R: WAN ingress R: transit DestMACMask W R: WAN ingress Ethertype ourcevendorclassid W R0, R0: LAN ingress ourceclientid W R0, R0: LAN ingress ourceuserclassid W R0, R0: LAN ingress IPLengthMin W R, R DCPCheck W R, R DCPMark W R, R0, R EthernetPriorityCheck W R: Only for WAN ingress. EthernetPriorityMark W R VLANIDCheck W R: Only for WAN ingress. ClassQueue InternetGatewayDevice.QueueManagement.Queue.{i}. QueueEnable Queuetatus QueueInterface QueueBufferLength QueueWeight W R WAN egress QueuePrecedence W R, R0 REDThreshold W R, R, R:RED parameters are not well modelled in TR-0 REDPercentage W R, R, R: RED parameters are not well modelled in TR-0 DropAlgorithm W R: RED R: DT cheduleralgorithm W R: trict Priority. WRR hapingrate W R hapingburstize W R InternetGatewayDevice.WANDevice.{i}.WANConnection- Device.{i}.WANDLLinkConfig. ATMQo W R ATMPeakCellRate W R ATMMaximumBurstize W R ATMustainableCellRate W R InternetGatewayDevice.WANDevice.{i}.WANConnection- Device.{i}.WANIPConnection.{i}. hapingrate W R hapingburstize W R W W C W R W R - - Page of

Name Type HGI InternetGatewayDevice.WANDevice.{i}.WANConnection- Device.{i}.WANPPPConnection.{i}. hapingrate W R hapingburstize W R Table Basic Qo Requirement Mapping Name Req HGI InternetGatewayDevice.QueueManagement. - MaxAppEntries R Must be at least. AppNumberOfEntries MaxFlowEntries R Must be at least. FlowNumberOfEntries AvailableAppList R Must include urn:homegatewayinitiative-org:qos:overloadprotection. InternetGatewayDevice.QueueManagement.Classification.{i}. ClassApp W Must be instance number of the App entry that handles overload protection. InternetGatewayDevice.QueueManagement.App.{i}. C These requirements relate to the App entry that handles overload protection. AppEnable Apptatus ProtocolIdentifier W Must be urn:homegatewayinitiative-org:qos:overloadprotection:. AppName - R R C W R W AppDefaultQueue W Must be the instance number of the queue that is used for flows that are not yet established (i.e. the temporary queue). AppDefaultDCPMark AppDefaultEthernetPriorityMark InternetGatewayDevice.QueueManagement.Flow.{i}. C These requirements relate to the Flow entry that handles overload protection. FlowEnable Flowtatus FlowType W Must be urn:homegatewayinitiative-org:qos:overloadprotection:. W W W R Page of

Name Req HGI FlowTypeParameters W Must encode the overload protection algorithm parameters as specified in TR-0, i.e. (loosely) in the form name=value&name=value. The following parameter names and values Must be supported: FlowName W Name MaxInstances ampleinterval InactivePackets ActivePackets QueueThreshold Value Maximum number of instances of this service (whether established or not) Interval (in ms) between executions of the state machine algorithm If number of packets in sample interval is less than this, service instance is considered inactive If number of packets in sample interval is greater than this, service instance is considered active If established flow queue depth exceeds this within sample interval, no new service instances will be allowed to become established AppIdentifier W Must be instance number of the App entry that handles overload protection. FlowQueue W Must be the instance number of the queue that is used for established flows. FlowDCPMark FlowEthernetPriorityMark Table Overload Protection Parameter Mapping to TR-0.0. Non-Integrated Device Requirements.0.. LAN Infrastructure Devices The following requirements pertain to the use of priority markings for non-integrated wireless or power line access devices and Ethernet LAN devices. W W R. R. A non-integrated wireless or power line device HOULD set its Layer markings for packets it receives from wired or wireless Ethernet by translating the received DCP value to the Layer markings using the translation shown in Table. For packets it sends to Ethernet, a non-integrated wireless or power line device HOULD translate its native layer marking to DCP using the correspondence between DCP and native layer markings shown in Table. + + 0.0.. Non-integrated Ethernet Infrastructure Devices The following requirements pertain to the interpretation of priority markings for nonintegrated Ethernet infrastructure devices such as bridges and switches. Page of

R. A non-integrated Ethernet Infrastructure Device HOULD determine the Qo treatment accorded to packets by translating the received DCP value to User Priority as shown in Table, without the addition of an 0.Q tag. + Layer Diffserv 0.D WMM / 0.e Layer PLC PLC ( Level) ( Level) DCP User Priority 0x0 0x0 0x00 0 0x 0x0 0x 0x0 0x Access Categor AC_BK (AC0) AC_BK (AC0) AC_BE (AC) AC_BE (AC) AC_VI (AC) AC_VI (AC) AC_VO (AC) AC_VO (AC) y Channel Access Priority Priority 0 (CA0) Priority 0 (CA0) Priority (CA) Priority (CA) Priority (CA) Priority (CA) Priority (CA) Priority (CA) Channel Access Priority Table Correspondence between ervice Classes and Infrastructure Device Markings.0... Informative notes on et Top Boxes and VoIP Client Devices CA CA CA0 CA CA CA CA CA 0 0 The following notes pertain to et Top Box (TB) deployed within the home network and not integrated within the HG. The outgoing packets from the TB should have their DCP bits configurable to conform to the Upstream Video category in Table The default DCP markings for outgoing packets from the TB should conform to the Upstream Video category in Table. The following notes pertain to VoIP client devices deployed within the home network and not integrated within the HG. The outgoing packets from the VoIP Client Device should have their DCP bits configurable. The default DCP marking for outgoing voice packets from the VoIP client device should conform to the Upstream Voice category in Table Page of

HGI Layer Diffserv WMM / 0.e Layer PLC PLC ( Level) ( Level) ervice Class Upstream BE Data Transit BE Data Upstream Premium Data Upstream Video Transit VA 0x00 0x 0x0 Upstream Voice 0x DCP Access Category AC_BE (AC) AC_BE (AC) AC_VI (AC) AC_VO (AC) Channel Access Priority Priority (CA) Priority (CA) Priority (CA) Priority (CA) Channel Access Priority Table Correspondence between ervice Classes and End Device Markings.0. DLNA Coexistence Guidelines CA0 CA CA CA 0 The goal of the following requirements is to ensure that transit flows from DLNA devices are treated, in the Qo sense, according to DLNA guidelines. The Qo configuration of the HG should respect as far as possible DLNA Qo markings originating from the LAN, particularly those in the DLNA Video and Audio categories, even for unmanaged services, giving them better treatment than Best Effort traffic, while remaining compatible with the operator's managed stream requirements. Indeed, some LAN-LAN flows used by DLNA devices may be using premium content for which the BP or AP may have a commercial responsibility. This implies active trust establishment for DLNA devices, and the creation of appropriate classification rules for such trusted device streams. Trust could be established, for example, by using unspoofable classifiers. This implies the use of a service running on the HG that detects the arrival of new devices on the LAN, attempts to establish trust with them, and subsequently generates additional classifiers for them in the HG. R. The HG HOULD NOT re-mark LAN-side ingress DCP markings that originate from trusted DLNA devices (see also R). R. Flows recognised as DLNA Video and Audio flows HOULD be given treatment, such as placement in LAN-LAN streaming queues, which limits the possibility of packet dropping and limits latency. R. The HG HOULD be able to treat flows that originate from trusted DLNA devices on the same level as operator managed services, according to operator configured policy. R. The HG HOULD be able to dynamically add classification rules for trusted DLNA devices as they are installed and recognized in the network. + + + + Page of

. Basic system features The powering requirements aim to lower the power consumption of the HG. This is also the objective of the "EU Code of Conduct on Energy Consumption of Broadband Communication Equipment" []. The HGI endorses this Code of Conduct. All appropriate Regional/National regulations on electrical safety, EMC, etc, must also be met. R. R. R0. The HG HOULD support operation modes with different power consumptions: a full operation mode and a low power mode. The HG HOULD be able to enter the low power mode when the traffic does not exceed a predefined threshold during a selectable period. Traffic from the WAN or the LAN side exceeding the predefined threshold HOULD be able to bring the HG back into full operation mode without affecting user experience. Recommended value for the transition period: sec. + + + R. The HG HOULD run on DC power, provided by an external power supply module. + R. R. R. The use of a fan is not recommended for reliability and noise reasons. If a fan is used, the noise MUT NOT exceed dba. The HG HOULD provide Power over Ethernet (according to IEEE0.af) on its Ethernet (LAN side) outlets. The HG HOULD provide a dying gasp to send a message to the RM in the case of power failure. + + The current recommended values for the maximum power consumption (measured on the 0 V AC input) are: W max in the full operation mode and W in the low power mode. The threshold and period must be configurable as factory default Page of

0 0 0 0 References [] DL Forum TR-0 Amendment "CPE WAN Management Protocol [] DL Forum TR-0 Auto-Config for the Connection Between the DL Broadband Network Termination (B-NT) and the Network using ATM (TR-0 update) [] ATM Forum ILMI.0, http://www.mfaforum.org/ftp/pub/approved-specs/af-ilmi-00.000.pdf [] http://standards.ieee.org/getieee0/ [] http://www.wi-fi.org/certification_programs.php [] ITU-T H.0 Full services VDL ystem architecture and customer premises equipment [] RFC (UUID URN Namespace) [] IETF RFC - The PPP Internet Protocol Control Protocol (IPCP) [] IETF RFC - PPP Authentication Protocols [0] IETF RFC - The Point-to-Point Protocol (PPP) [] IETF RFC - PPP Internet Protocol Control Protocol Extensions for Name erver Addresses [] IETF RFC - PPP Challenge Handshake Authentication Protocol (CHAP) [] IETF RFC - A Method for Transmitting PPP Over Ethernet (PPPoE) [] IETF RFC - PPP Over AAL [] IETF RFC - Dynamic Host Configuration Protocol [] UPnP Device Architecture.0; http:www.upnp.org [] IETF RFC - Ethernet Address Resolution Protocol: Or converting network protocol addresses to.bit Ethernet address for transmission on Ethernet hardware [] IETF RFC - DHCP Options and BOOTP Vendor Extensions [] IETF RFC - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version (DHCPv) [0] IANA Private Enterprise Numbers registry. http://www.iana.org [] DL Forum TR-0 Amendment Data Model template for TR-0 enabled devices [] http://www.upnp.org [] IETF RFC 00 - The User Class Option for DHCP [] Organizationally Unique Identifiers (OUIs), http://standards.ieee.org/faqs/oui.html [] ITU-T Recommendation G.. () Asymmetrical Digital ubscriber Line (ADL) Transceivers [] ITU-T Recommendation G.. (00) - Asymmetric Digital ubscriber Line (ADL) transceivers - (ADL) [] ITU-T Recommendation G.. (00), Asymmetric Digital ubscriber Line (ADL) transceivers Extended Bandwidth ADL (ADLplus) [] ITU-T Recommendation G.., 00 - Handshake procedures for digital subscriber line (DL) transceivers [] ITU-T Recommendation G.. (00) - Very high speed digital subscriber line transceivers (VDL) [0] ITU-T Recommendation I.: B-IDN ATM Layer pecification Page 0 of

0 0 0 0 [] ITU-T Recommendation I..: B-IDN ATM Adaptation Layer (AAL) pecification [] IETF RFC - Multiprotocol Encapsulation over ATM Adaptation Layer [] IETF RFC - Address Allocation for Private Internets [] ATM User-Network Interface (UNI) pecification Version.0, ATM Forum, July. [] ITU-T Recommendation I.0 - Integrated ervices Digital Network (IDN): maintenance principles. B-IDN operation and maintenance principles and functions", March [] IEEE td 0.ah-00, Ethernet in the First Mile [] IEEE td. 0.Q-00, Virtual Bridged Local Area Networks [] UB-IF: Universal erial Bus pecification: Revision.0, //000 [] Bluetooth specification Version.0 + EDR [0] IEEE 0.b upplement to 0.-,Wireless LAN MAC and PHY specifications: Higher speed Physical Layer (PHY) extension in the. GHz band [] IEEE 0.g Part : WLAN MAC and PHY specifications Amendment : Further Higher Data Rate Extensions in the. GHz band [] ETI EN 00 -/ V.. Electromagnetic compatibility and Radio spectrum Matters (ERM); Wideband transmission systems; Data transmission equipment operating in the, GHz IM band and using wide band modulation techniques; Harmonized EN covering essential requirements under article. of the R&TTE Directive [] IEEE 0.a Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment : High-speed Physical Layer in the GHz band [] IEEE 0.h Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment : pectrum and Transmit Power Management Extensions in the GHz band in Europe [] DL Forum, TR-0 Base Requirements for an ADL Modem with Routing, Technical Report TR-0, May 00 [] Organizationally Unique Identifiers (OUIs), http://standards.ieee.org/faqs/oui.html [] DL Forum, TR-0 Amendment, Gateway Device Version. Data Model for TR-0 [] IETF RFC list: http://rfc.net/rfc-index.html [] IETF RFC : IP: ession Initiation Protocol [0] IETF RFC 0 "Network Time Protocol (Version ) - pecification, Implementation and Analysis" [] IETF RFC 00 "imple Network Time Protocol (NTP) Version for IPv, IPv and OI" [] IETF RFC - An Offer/Answer Model with ession Description Protocol (DP) [] IETF RFC - ession Initiation Protocol (IP)-pecific Event Notification [] IETF RFC - An INVITE-Initiated Dialog Event Package for the ession Initiation Protocol (IP) [] IETF RFC - The ession Initiation Protocol (IP) Refer Method [] IETF RFC - A Message ummary and Message Waiting Indication Event Package for the ession Initiation Protocol (IP) [] IETF RFC 0 Indicating User Agent Capabilities in the ession Initiation Protocol (IP) [] IETF RFC Caller Preferences for the ession Initiation Protocol (IP) [] IETF RFC The ecure Real-time Transport Protocol (RTP) Page of

0 0 0 0 [0] IETF RFC IP Network Address Translator Terminology and Considerations [] IETF RFC 0 Traditional IP Network Address Translator [] IETF RFC 0 Protocol Complications with the IP Network Address Translator) [] IETF RFC - TUN - imple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) [] ETI T 0 0 - Digital Video Broadcasting (DVB); Transport of MPEG- Based DVB ervices over IP Based Networks [] Floyd,., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume, Number, August, pp. -. ) [] http://www.dslforum.org/techwork/treports.shtml [] XHTML.0 The Extensible HyperText Markup Language (econd Edition), http://www.w.org/tr/xhtml/ [] CEA-0 Web-based Protocol and Framework for Remote User Interface on UPnP Networks and the Internet (WebCE); http://www.ce.org [] http://www.iso.org [0] ITU-T Recommendation H. - Packet-based multimedia communications systems [] ITU-T Recommendation H. - Control protocol for multimedia communication [] ITU-T Recommendation H..0 - Call signalling protocols and media stream packetization for packet-based multimedia communication systems [] CIPR : Information technology equipment - Radio disturbance characteristics - Limits and methods of measurement [] CIPR : Information technology equipment - Immunity characteristics - Limits and methods of measurement [] IEC 00-: Information technology equipment afety Part : General requirements [] IEC 00-: Information Technology equipment afety Part : Remote feeding. [] IEC 000--: Electromagnetic compatibility (EMC) Part -: Limits Limits for harmonic current emissions (equipment input current < A per phase) [] IEC 000--: Electromagnetic compatibility (EMC) Part -: Limits Limitation of voltage changes, voltage fluctuations and flicker in public low-voltage supply systems, for equipment with rated current < A per phase and not subject to conditional connection [] IEC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - Electrostatic Discharge immunity test [0] IEC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - Radiated EM field immunity test [] IEC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - Fast Transient/Burst immunity test [] IEC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - urge immunity test [] IEC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - Conducted RF Disturbances immunity test [] EC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - Power Frequency Magnetic Field immunity test [] IEC 000--: Electromagnetic compatibility (EMC) Part : Testing and measurement techniques section - Voltage fluctuations immunity test Page of

0 0 0 0 [] IEC 00- Appliance couplers for household and similar general purposes - Part : General requirements [] IEC 00 Plugs and socket-outlets for domestic and similar general use standardized in member countries of IEC [] EN 0: Generic standard to demonstrate the compliance of low power electronic and electrical apparatus with the basic restrictions related to human exposure to electromagnetic fields (0 MHz - 00 GHz) - General public [] EN 00 : Electromagnetic compatibility and Radio spectrum Matters (ERM); Wideband transmission systems; Data transmission equipment operating in the, GHz IM band and using wide band modulation techniques; Harmonized EN covering essential requirements under article. of the R&TTE Directive [0] EN 0 -: Electromagnetic compatibility and Radio spectrum Matters (ERM); ElectroMagnetic Compatibility (EMC) standard for radio equipment and services; Part : Common technical requirements [] EN0 -: Electromagnetic compatibility and Radio spectrum Matters (ERM); ElectroMagnetic Compatibility (EMC) standard for radio equipment and services; Part : pecific conditions for, GHz wideband transmission systems and GHz high performance RLAN equipment [] EN 0 Broadband Radio Access Networks (BRAN); GHz high performance RLAN; Harmonized EN covering essential requirements of article. of the R&TTE Directive [] IETF RFC - The tel URI for Telephone Numbers [] GPP T.: "IP Multimedia ubsystem (IM); tage [] GPP T.: "IP Multimedia (IM) ession Handling; IP Multimedia (IM) call model; tage ". [] T. IP Multimedia ystem (IM) Messaging and Presence; Media formats and codecs [] DL Forum TR0 - Provisioning Parameters for VoIP CPE [] ETI E 00 TIPAN: NGN Functional Architecture Release [] IETF RFC - Dynamic Host Configuration Protocol (DHCP-for-IPv) Option for ession Initiation Protocol (IP) ervers [00] ETI T 00 PTN simulation services - Communication Diversion (CDIV); Protocol specification [0] ETI T 00 PTN/IDN simulation services Conference (CONF); Protocol specification [0] ETI T 00 NGN ignalling Control Protocol Message Waiting Indication (MWI) - PTN/IDN simulation services [0] ETI T 00 NGN IM upplementary ervices Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR) PTN/IDN simulation services [0] ETI T 00 NGN IM upplementary ervices Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR) PTN/IDN simulation services [0] ETI T 00 PTN simulation services Communication Hold (HOLD) ; Protocol specification [0] ETI T 0 PTN/IDN simulation services Anonymous Communication Rejection (ACR) and Communication Barring (CB); Protocol specification Page of

0 0 0 0 [0] ETI T 0 NGN IM upplementary ervices Call Waiting (CW) [0] ETI T 0 PTN/IDN simulation services Malicious Communication Identification (MCID); Protocol specification [0] ETI T 0 PTN/IDN simulation services; Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over Ut interface for Manipulating NGN PTN/IDN imulation ervices [0] ETI T 0 PTN/IDN simulation services - Explicit Call Transfer (ECT); Protocol specification [] ETI T 0 IM upplementary ervices; Call Completion on Busy ubscriber (CCB), Call Completion No Reply (CCNR) (draft) [] ETI T 0 IM upplementary ervices; Advice of Charge (AoC) (draft) [] IETF RFC - Internet Group Management Protocol, Version [] IETF RFC - Internet Group Management Protocol, Version [] UB-IF Universal erial Bus pecification, Revision.0. [] IEEE 0.n/D.00 Draft - Draft TANDARD for Information Technology- Telecommunications and information exchange between systems-local and metropolitan area networks-pecific requirements-part : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Amendment : Enhancements for Higher Throughput [] WCN Windows Connect Now-UFD for Windows XP Version. [] T. GPP;Technical pecification Group Core Network; IP Multimedia Call Control Protocol based on ession Initiation Protocol (IP) and ession Description Protocol (DP); tage (Release ) [] ETI E 00 TIPAN: IP Multimedia Call Control Protocol based on ession Initiation Protocol (IP) and ession Description Protocol (DP) tage [0] T.0 GPP; Technical pecification Group A; Access security for IP-based services (Release ) [] T. GPP Technical pecification Group ervices and ystem Aspects; Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer ecurity (HTTP) (Release ) [] ETI T Digital cellular telecommunications system (Phase +);Universal Mobile Telecommunications ystem (UMT);Generic Authentication Architecture (GAA);Access to network application functions using Hypertext Transfer Protocol over Transport Layer ecurity (HTTP) (GPP T. version..0 Release ) [] ETI T 00 TIPAN: NGN Architecture to support emergency communication from citizen to authority [] IETF RFC HTTP Authentication: Basic and Digest Access Authentication [] IETF RFC Dynamic Host Configuration Protocol (DHCP-for-IPv) - Option for ession Initiation Protocol (IP) ervers. [] IETF RFC 0 RTP: A Transport Protocol for Real-Time Applications [] IETF RFC RTP Profile for Audio and Video Conferences with Minimal Control [] IETF RFC RTP Control Protocol Extended Reports (RTCP XR) [] IETF RFC 0 Indicating User Agent Capabilities in the ession Initiation Protocol (IP) [0] IETF RFC Caller Preferences for the ession Initiation Protocol (IP) Page of

[] European Code of Conduct on Energy Consumption of Broadband Equipment http://re.jrc.cec.eu.int/energyefficiency/pdf/coc%0broadband%0equipment%0final% 0version%0%0-%0July%0.pdf Page of