REQUIREMENTS FOR AN NGA (A L A CAPABLE NT Requirements for an NGA ... TeliaSonera, Telstra, TNO, Trac Telecoms & Radio Ltd, Vodafone, Vtech, Zarlink, ZTE ... CAC Call Admission Control

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

HGI-RD024

REQUIREMENTS FOR AN NGA (ACTIVE LINE ACCESS)

CAPABLE NT

Published April, 2013

Source HGI02185_R06

HGI-RD024 Requirements for an NGA (Active Line Access) Capable NT


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

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

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

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

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

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

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

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

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

Tenders 6

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

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

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

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

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

4.2 Definitions Of Terms ...................................................................................................................... 11

5 ALA Background and Introduction ...................................................................................................... 12

5.1 ALA Business Entities ..................................................................................................................... 13

5.1.1 ALA Commercial Model ......................................................................................................... 13

5.2 ALA Basic Concepts ........................................................................................................................ 13

5.3 ALA QoS Architecture .................................................................................................................... 14

5.4 ALA Service Classes ........................................................................................................................ 14

5.5 Access Line Sharing ........................................................................................................................ 15

5.6 ALA Port Types ............................................................................................................................... 15

5.6.1 Frame handling at a port based UNI ..................................................................................... 15

5.6.2 Frame handling at an S-tagged UNI ...................................................................................... 16

5.6.3 Frame handling at an customer edge port UNI..................................................................... 16

5.7 ALA Multicast ................................................................................................................................. 16



5.8 ALA OAM ........................................................................................................................................ 16

5.8.1 ALA-User MEG ....................................................................................................................... 17

5.8.2 Extended AUC MEG ............................................................................................................... 17

5.8.3 AUC MEG ............................................................................................................................... 17

5.8.4 UNI MEG ................................................................................................................................ 18

5.8.5 NNI MEG ................................................................................................................................ 18

5.9 ALA and Line Sharing...................................................................................................................... 18

6 2-box History in the HGI ...................................................................................................................... 19

6.1 Overview of the Existing HGI Document ....................................................................................... 19

6.2 Rationale for a New Document...................................................................................................... 19

6.3 Relationship to ETSI Work .............................................................................................................. 19

7 Generic Requirements ........................................................................................................................ 20

7.1 Physical Connections and Connectivity ......................................................................................... 20

7.2 ALA Port Mode Support ................................................................................................................. 20

7.3 VLAN Handling ............................................................................................................................... 21

7.3.1 S-tagged UNI.......................................................................................................................... 21

7.3.2 Customer Edge Port UNI ....................................................................................................... 22

7.3.3 Port Tagged UNI .................................................................................................................... 22

7.4 Frame Transparency ...................................................................................................................... 22

7.5 Upstream QoS Support .................................................................................................................. 23

7.6 QoS Markings ................................................................................................................................. 24

7.7 Energy Efficiency ............................................................................................................................ 25

7.8 Multicast Support .......................................................................................................................... 25

7.9 Secondary LAN Interfaces .............................................................................................................. 25

8 Technology Specific Requirements ..................................................................................................... 27

8.1 VDSL2 ............................................................................................................................................. 27

8.1.1 WAN-side Interfaces ............................................................................................................. 27

8.1.2 LAN-side Interfaces ............................................................................................................... 28

8.2 Upstream Queues .......................................................................................................................... 28

8.3 Ethernet WAN Interface ................................................................................................................ 28



8.3.1 WAN interface ....................................................................................................................... 28

8.3.2 LAN Interfaces ....................................................................................................................... 29

8.4 Upstream Queues .......................................................................................................................... 29

8.5 GPON .............................................................................................................................................. 29

8.5.1 WAN interface ....................................................................................................................... 29

8.5.2 LAN Interfaces ....................................................................................................................... 29

8.5.3 T-Conts .................................................................................................................................. 30

8.6 Point to Point Fibre ........................................................................................................................ 30

8.6.1 WAN Interface ....................................................................................................................... 30

8.6.2 LAN Interfaces ....................................................................................................................... 30

8.7 Upstream Queues .......................................................................................................................... 31

9 Diagnostics .......................................................................................................................................... 32

10 OAM ............................................................................................................................................... 33

10.1 ALA-User MEG ........................................................................................................................... 33

11 Management .................................................................................................................................. 34

12 References ..................................................................................................................................... 35

1 Annexe 1 ............................................................................................................................................. 36



2 IMPORTANT NOTICES, IPR STATEMENT, DISCLAIMERS AND

COPYRIGHT

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

Document’).

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

requirements documents, white papers, vision papers, test plans and other documents concerning

broadband equipment and services which are deployed in the home.

2.2 THIS MAY NOT BE THE LATEST VERSION OF THIS HGI DOCUMENT This HGI Document is the output of the Working Groups of the HGI and its members as of the date of

publication. Readers of This HGI Document should be aware that it can be revised, edited or have its

status changed according to the HGI working procedures.

2.3 THERE IS NO WARRANTY PROVIDED WITH THIS HGI DOCUMENT The services, the content and the information in this HGI Document are provided on an "as is" basis.

HGI, to the fullest extent permitted by law, disclaims all warranties, whether express, implied, statutory

or otherwise, including but not limited to the implied warranties of merchantability, non-infringement of

third parties rights and fitness for a particular purpose. HGI, its affiliates and licensors make no

representations or warranties about the accuracy, completeness, security or timeliness of the content or

information provided in the HGI Document. No information obtained via the HGI Document shall create

any warranty not expressly stated by HGI in these terms and conditions.

2.4 EXCLUSION OF LIABILITY Any person holding a copyright in This HGI Document, or any portion thereof, disclaims to the fullest

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

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

any obligation to update or correct this technical report.

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

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

upon the HGI members.



2.6 INTELLECTUAL PROPERTY RIGHTS Patents essential or potentially essential to the implementation of features described in This HGI

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

HGI website www.homegateway.org).

2.7 COPYRIGHT PROVISIONS © 2013 HGI. This HGI Document is copyrighted by HGI, and all rights are reserved. The contents of This

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

agreement. Trademarks and copyrights mentioned in This HGI Document are the property of their

respective owners. The content of This HGI Document may only be reproduced, distributed, modified,

framed, cached, adapted or linked to, or made available in any form by any photographic, electronic,

digital, mechanical, photostat, microfilm, xerography or other means, or incorporated into or used in

any information storage and retrieval system, electronic or mechanical, with the prior written

permission of HGI or the applicable third party copyright owner. Such written permission is not

however required under the conditions specified in Section 2.7.1 and Section 2.7.2 :

2.7.1 INCORPORATING HGI DOCUMENTS IN WHOLE OR PART WITHIN DOCUMENTS RELATED

TO COMMERCIAL TENDERS Any or all section(s) of HGI Documents may be incorporated into Commercial Tenders (RFP, RFT, RFQ,

ITT, etc.) by HGI and non-HGI members under the following conditions:

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

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

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

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

2.7.2 COPYING THIS HGI DOCUMENT IN ITS ENTIRETY This HGI Document may be electronically copied, reproduced, distributed, linked to, or made available in

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

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

mechanical, but only in its original, unaltered PDF format, and with its original HGI title and file name

unaltered. It may not be modified without the advanced written permission of the HGI.

http://www.homegateway.org/



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

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

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

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

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

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

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

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

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



3 ACRONYMS

ACS Auto-Configuration Server

ADSL Asymmetric Digital Subscriber Line

AN Access Network

ANP Access Network Provider

ARP Address Resolution Protocol

ATA Analogue Terminal Adapter

BRAS Broadband Remote Access Server

BSP Broadband Service Provider

CAC Call Admission Control/Connection Admission Control

CE Customer Experience

CoS Class of Service

CPE Customer Premises Equipment

CPU Central Processing Unit

CRC Cyclic Redundancy Check

DHCP Dynamic Host Control Protocol

DNS Domain Name Server

DRAM Dynamic Random Access Memory

DSL Digital Subscriber Line

DSLAM DSL Access Multiplexer

ED End Device

EU End user

GPON Gigabit Passive Optical Network

GUI Graphical user Interface



HG Home Gateway

HGI Home Gateway Initiative

HN Home Network

HNID Home Network Infrastructure Device

I/F Interface

MAC Media Access Control

LAN Local Area Network

NAS Network Attached Storage

NAT Network Address Translation

NGN Next Generation Network

NGA Next Generation Access

NT(E) Network Termination (Equipment)

OAM Operations, Administration & Maintenance

OS Operating System

OTT Over The Top (service)

OUI-SN Organisationally Unique Identifier

PHY Physical Layer

PLT Power Line Technology

PM Performance Monitoring

PPP Point-to-Point Protocol

PVR Personal Video Recorder

QoS Quality of Service

RCPI Received Channel Power Indicator

RMS Remote management System



RTP Real Time Protocol

SLA Service Level Agreement

SNMP Simple Network Management Protocol

SP Service Provider

SSID Service Set Identifier

STB Set Top Box

SWEX Software Execution Environment

UI User Interface

UMTS Universal Mobile Telephone System

UPnP Universal Plug and Play

URL Universal Resource Locator

USB Universal Serial Bus

VAS Value Added Service

VDSL Very highspeed Digital Subscriber Line

VoD Video on Demand

VoIP Voice Over IP

WAN Wide Area Network

xDSL ADSL and VDSL



4 INTRODUCTION

4.1 SCOPE AND PURPOSE

The purpose of this document is to define the HGI Service Provider requirements for a Next Generation

Access/Active Line Access Capable NT device. The scope of the requirements provided is ALA-specific

requirements, Layer 2 marking and handling, Quality of Service, Diagnostics, technology specific

requirements on the NT line side, and technology specific requirements on the NT WAN side.

4.2 DEFINITIONS OF TERMS

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

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

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

MUST NOT This function is prohibited by the specification.

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

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

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

terms used by other bodies.



5 ALA BACKGROUND AND INTRODUCTION

Most ADSL Broadband deployments use an integrated modem-router, i.e. the ADSL modem which

terminates the access network transmission is combined with L3 functionality to produce an integrated

Home Gateway. With the move to higher speed access systems this model may change, with the VDSL

modem or GPON ONT being standalone, separate devices. There are different reasons in the 2 cases. For

optimum performance, VDSL needs a centralised splitter, and so is less amenable to self-install than

ADSL which can use distributed microfilters. Further, the state of multi-vendor VDSL interoperability and

performance is not yet as advanced as with ADSL and so BSPs may want to offer bookended

transmission systems so as to maximise performance, without necessarily wanting to provide the HG

themselves. In the GPON case, the network provider may wish to retain control of the ONT because of

the shared-medium nature of GPON, and the impact a ‘rogue’ 3rd party device can have on all other

users on the GPON, while again not wishing to provide the HG as a whole.

Two of the main drivers for competition in ADSL have been wires-only and local loop unbundling. Wires-

only has allowed competition in HGs (via price, functionality, performance and branding), but wires-only

NGA suffers from the above difficulties. Local loop unbundling is also problematic with NGA; while

subloop unbundling, (i.e. allowing access to that part of the loop between the cabinet and the home to

3rd parties) is technically feasible, it is commercially and logistically challenging. Deploying electronics at

the cabinet has high fixed costs, and so sharing that cost between a smaller number of customers, as

would be the case if there was equipment there from multiple operators, makes this financially

unattractive. In the GPON case, there is no separate infrastructure link to individual customers, and so a

GPON cannot be unbundled at the individual customer level.

The UK regulator, Ofcom, therefore considered how competition could be provided in the absence of

unbundling, and came up with the concept of Active Line Access (ALA) [Ref 1]. This is a Layer 2,

Ethernet-presented bitstream service which allows access to individual customers, via an aggregate

handover, and it can support multiple services, via several different levels of network QoS. The intention

is to provide this access service at the lowest possible Layer, and so there is no presumption of higher

Layer protocols, e.g. PPP, although these can be supported. It differs from previous bitstream products

in that there is less requirement to specify the internal details of the connectivity. Both point to point

and point to multipoint connectivity (specifically for multicast) are supported.

While the initial drive behind ALA came from the UK, the expectation is that it will have a much broader

applicability, both within and beyond the EU, in particular in any NGA market where there is L2

Wholesale rather than vertical integration.



5.1 ALA BUSINESS ENTITIES

The ALA service is defined in terms of three different business entities each of which has a specific role

with regard to the ALA service. These are as follows.

The ALA Provider who is responsible for the provision of the active and passive infrastructure over

which ALA is delivered. The ALA provider offers standardised interfaces to which the ALA user can

connect, and delivers the ALA user’s traffic between these interfaces, across the ALA domain. The ALA

domain extends from the end-user premises to an interconnect point further up the network. ALA

providers may include both fixed and some types of wireless infrastructure providers. They may own or

lease the passive and active parts of network, e.g. an ALA provider may own the active electronics, but

lease the passive infrastructure.

The ALA User purchases Ethernet transport to an end-user from the ALA provider over which it delivers

services such as voice, video and internet connectivity. The ALA user has a direct, contractual

relationship with the ALA provider. The ALA user may also have a direct relationship with the LAN side or

with other communications providers on a wholesale basis.ALA users include ISPs and triple-play

operators.

The End-User is the ultimate recipient of the services provided over ALA. End-users include both

residential consumers and business users. The end-user is unaware of the ALA service and of the

interfaces between the ALA provider and the ALA user. An end-user is typically (but not always) served

by a single ALA provider. The end-user may buy services from multiple ALA users who would in turn buy

service from the ALA provider(s) serving the end-user. This means that at a given end-user premises it is

possible to have multiple ALA users consuming the service offered by a single ALA provider.

5.1.1 ALA COMMERCIAL MODEL In the ALA model, the NT itself is provided by the Access Network provider. The retail service provider is

typically a different business entity to the ANP. The retail service provider is responsible for providing

the HG, and just as in the single box model, would normally want to control and manage the HG. The HG

in the ALA model therefore remains a SP provided or specified box, rather than supporting an open

retail HG market.

5.2 ALA BASIC CONCEPTS

The ALA service delivers Ethernet packets between the UNI on the NT and a handover point (NNI) in the

network. This is done over an AUC – ALA User connection. There are 2 types of AUC, point to point, and

point to multipoint which is exclusively used for multicast. A single AUC can support all 4 ALA service

classes. AUCs are not shared between ALA Providers, but there can be multiple AUCs on the same access

line.



5.3 ALA QOS ARCHITECTURE

ALA does not presume a single service edge, a single BNG (or indeed any BNG), and although its main

focus is residential, there is an intention to be able to support business services as well. There is a need

for QoS management at the ALA UNI, and therefore the NT.

5.4 ALA SERVICE CLASSES

ALA supports 4 QoS Classes (A,B,C,D), A, B and C have some aspects of the traditional IP EF, AF and BE

Classes. While they are intended to support a variety of service types, some typical examples are given

in the below Table.

Class Typical Use

A Realtime, delay sensitive applications e.g. voice

B Streaming applications (video)

C Internet data

D Guest or 3rd party Access

Each of these classes has associated performance objectives that form a per-class Service Level

Specification. These performance objectives are such that Class A will have better performance than

Class B, which will have better performance than Classes C and D.

In order to meet the Service Level Specification, it is expected that the ALA Provider (L2 Wholesale

Access Provider) will need to implement strict priority scheduling at any congestion points in their

network to prioritise transmission of Class A traffic over Class B traffic, which in turn would be prioritised

over Class C and D traffic. Starvation of the lower priority queues can be avoided by the use of per class

policers.

Classes A and B only support committed bandwidth. The bandwidth available for each of Classes A and B

may need to be restricted by the ALA provider to ensure that appropriate performance levels can be

delivered for lower priority classes and other ALA users.

Classes C and D support both committed and excess bandwidth. The bandwidth profiles at the UNI and

NNI can be configured to be colour aware so that the ALA User’s drop precedence marking is respected



within these classes. In the case that both classes C and D send excess traffic at the same time, the ALA

provider will limit the bandwidth share of Class D. Typical use cases for Class D would be to support

(wireless) guest access at the end-user premises, or to limit the bandwidth of a background application

such as push video.

5.5 ACCESS LINE SHARING

Another new feature of ALA is access line sharing; this means that there can be more than one ALA user

on a given access line. The business rationale for this is not primarily to have more than one multi-play

service provider (although this is supported), but for secondary or niche service providers in addition to

the main multiplay SP. Examples of such service types are utility services such as smart grid related,

security, E-health, work at home and corporate voice. This means that the QoS mechanisms need to be

able to protect different ALA users on the same line from each other; for example it is not sufficient to

simply provide shared queues or only strict priority scheduling.

5.6 ALA PORT TYPES

ALA supports three (user) port types:

• A port based UNI • An S-Tagged UNI • A customer edge port based UNI.

The S-Tagged UNI requires the ALA User to identify the AUC of a frame using either an S-VLAN tag or the

default S-VLAN on the port. This means that to use a VLAN tagged presentation at the UNI in the S-

Tagged interface, the ALA User needs to send two VLAN tags at the NNI and configure which S-VLAN to

use at the UNI.

A customer edge port based UNI offers the same capability but in this case the CVLAN tags used at the

UNI are tunnelled over a point-to-point AUC. This means that to use a VLAN-tagged presentation at the

UNI the ALA User will need to send three VLAN tags at the NNI; where the two outer VLAN tags are

defined by the AUC endpoint map at the NNI and the inner-most VLAN tag needs to match the VLAN tag

being used by the ALA User at the UNI. This inner-most VLAN tag is not significant to the ALA provider at

the NNI and is carried transparently over it.

5.6.1 FRAME HANDLING AT A PORT BASED UNI At a port based UNI the UNI identifier identifies the AUC. All service frames received on the UNI that

have a TPID of 0x8100 are accepted regardless of any VLAN tagging, and treated as untagged frames. All

service frames received on the UNI that have a TPID of 0x88A8 are accepted regardless of any VLAN

tagging and treated as untagged frames. VLAN tagging is preserved through the ALA provider’s network.

In the downstream direction (towards the end-user) any VLAN tags used by the ALA provider to identify



the AUC will be stripped off before the frame is passed over the UNI. Note that this mode only supports

a single ALA Class of Service.

5.6.2 FRAME HANDLING AT AN S-TAGGED UNI At an S-tagged UNI the AUC end point map uses the S-VID of the frame to identify the AUC. The UNI AUC

end point map will therefore contain a list of S-VID to AUC mappings. Traffic arriving over the AUC will

be passed out over the UNI with the appropriate S-tag. An S-VID will map to at most one AUC, and an

AUC will map to only one S-VID.

At each S-tagged UNI it is possible to define a default VLAN to which any untagged or priority tagged

frames are mapped. This default VLAN can be mapped to an AUC (as for any other S-tagged VLAN) by

the end point map. If no default VLAN is defined for the UNI then untagged and priority tagged frames

will be dropped since they do not match a defined S-VID.

5.6.3 FRAME HANDLING AT AN CUSTOMER EDGE PORT UNI At a customer edge port UNI, one C-Tag value is used to identify the multicast AUC. This value needs to

be defined by the ALA provider as part of their product description. All other frames, untagged, priority

tagged or tagged with a value other than the multicast tag, are mapped to the point to point AUC. The

priority within the AUC for frames entering the network at the UNI is mapped from the priority bits of

the C-tags received.

5.7 ALA MULTICAST

ALA always uses a separate (point to multipoint) VLAN for multicast between the ALA provider and ALA

user. A given access line can support more than one multicast AUC, but there is no sharing of a given

multicast AUC between different service providers.

5.8 ALA OAM

The mapping of Ethernet OAM to the ALA architecture is shown in figure 1:



Figure 1 – Ethernet OAM Architecture

Figure 1 shows the following MEGs

5.8.1 ALA-USER MEG The ALA provider configures the ALA-user MEG on the VLAN that supports the AUC. It supports MIPs

that allow the ALA-User to perform linktrace and loopback operations to the UNI and NNI for each AUC.

This MEG is equivalent to the EVC MEG in the MEF architecture and the Customer MEG in the

Broadband Forum Architecture.

5.8.2 EXTENDED AUC MEG

The Extended-AUC MEG allows an ALA user to monitor the Frame Delay and Frame Loss performance of

an AUC without deploying CPE. It supports a MEP at the ALA UNI which supports loopback and linktrace

and generation of Y.1731 LMR and DMR Messages in response to a Y.1731 LMM or DMM message from

a remote MEP. This allows support for single ended frame loss measurement and two-way frame delay

Measurement.

5.8.3 AUC MEG

The ALA provider can configure the ALA-user MEG on the VLAN that supports the AUC. It supports MEPs

that allow the ALA-provider to run continuity check, linktrace and loopback operations between the UNI

and NNI for each AUC. Support of this MEG by the ALA provider allows the ALA provider to report the

state of the AUC to the ALA User using ETH-AIS. This MEG is equivalent to the Operator MEG in the MEF

architecture, and the Carrier MEG in the Broadband Forum Architecture.

A1, A2 CPE NTU

A3, A4

UNI MEG NNI MEG

AUC MEG

ALA-User MEG

Untagged

Tagged

Extended-AUC MEG



The AUC MEG exists entirely within the domain of the ALA provider. The operation of this MEG is

therefore a matter for the ALA-Provider and does not need to be specified as part of ALA. The only

related requirement arising from the ALA service definition is that a MEG level is reserved for the use of

the ALA provider.

5.8.4 UNI MEG

The UNI MEG monitors the UNI interface. It can support Continuity Check, Loopback and Linktrace.

This MEG is equivalent to the Access Link MEG in TR-101 [2] and the MEF UNI MEG.

5.8.5 NNI MEG

The NNI MEG monitors the NNI interface. It can support Continuity Check, Loopback and Linktrace.

This MEG is equivalent to the MEF NNI MEG.

5.9 ALA AND LINE SHARING

The ALA service provides a technology agnostic bit-stream service. Therefore it is possible to provide

more than one ALA service connection on a single line, also known as line-sharing. The main business

rationale for this is to support services beyond traditional triple-play, which may not necessarily be

provided by the main Broadband Service. Examples of such services are utilities such as smart metering

or smart grid, business services such as work at home (remote corporate LAN and voice access), and

mobile data offload. The ALA service definition and architecture support such line sharing. The

implications for the NT are that additional QoS and policing functionality are required, and there is an

impact on the number of physical ports, and their functionality (i.e. no local bridging or switching

between LAN ports). There is architectural support for both having a dedicated port per ALA User, and

sharing ports between users, although the latter has significant implications for the in-home network(s).



6 2-BOX HISTORY IN THE HGI

6.1 OVERVIEW OF THE EXISTING HGI DOCUMENT

The concept of a 2-box model is not particularly new. While the HGI Residential Profile Release 1 [3]

focuses on an integrated Gateway, the possibility of a separate NT was recognised in HGI-RD007-R2 [4];

this describes the 2-box scenario, the resulting requirements for the HG, and recommendations (not

requirements) for the NT functionality. The reason for this was that at that time the HGI did not want to

set requirements for boxes other than HGs, and there were few proposed 2-box deployments.

6.2 RATIONALE FOR A NEW DOCUMENT

The HGI has now extended its remit beyond the HG itself and interest in the 2-box model has increased

with the deployment of NGA. Therefore at the very least the 2-box document would have needed to be

updated to turn the recommendations into Requirements. However ALA goes beyond this with its

explicit support for line sharing, and the specification of multiple network QoS classes. This document

therefore specifies NT requirements, driven by, but not limited to, the support of ALA.

This document makes HGI-RD007-R2 obsolete

6.3 RELATIONSHIP TO ETSI WORK

ETSI has also produced a specification for a 2-box NT and while there is some overlap, this does not

obviate the need for this HGI document for the following reasons. The ETSI document contains

significant detail on the physical aspects of the NT box (LEDs etc.) whereas HGI specifies functionality

only. There is a lot of detail on the WAN interfaces in the ETSI case. This is much simpler in the HGI case

and done by reference. The ETSI specification contains elements of ATM where the HGI NT is for pure

Ethernet WAN attachment. Upstream QoS is optional in the ETSI document, whereas it is mandatory in

the HGI case, and it must meet the specific requirements of ALA QoS. The resulting queue structure is

different in the 2 cases. Finally ALA is a pure L2 service with the exception of essential IGMP support

functionality, and while it is able to support the use of PPP, DHCP etc. the HGI NT itself has no

knowledge or awareness of these protocols.



7 GENERIC REQUIREMENTS

7.1 PHYSICAL CONNECTIONS AND CONNECTIVITY

ALA requires support for multiple interfaces on the LAN side; the number is dependent on the access

technology type, and so is specified in the technology-specific Sections.

N° Requirement

R1. The NT MUST NOT allow any local bridging of packets between LANside ports.

R2. The NT MUST forward any ingress customer packets which map to a configured or the default AUC to the upstream Ethernet port.

R3. The NT MUST forward any ingress WAN packets to the appropriate LAN side port on the basis of the S-Tag.

7.2 ALA PORT MODE SUPPORT

ALA specifies 3 port modes at the UNI; S-tagged, Customer Edge tagged and Port tagged. Port tagged is

intended to support a TLS for business customers and only provides a single class of service. While the

use of Port tagged mode is not expected to be common in the residential market, it is included in this

specification to avoid the need for (and possible confusion of) a separate NT specification just for

business use. The S-tagged interface identifies different AUCs, and so allows multiple AUCs to be

supported on a given port. These can belong to the same ALA User or to different ones. Note that a

single AUC can support all the ALA service classes. The Customer Edge port supports a single ALA User

per port, although that user can have both a multicast and unicast service, and access to all 4 service

classes. This mode requires the minimum of configuration, and allows the ALA User the maximum

flexibility with regard to packet tagging.

N° Requirement

R4. The NT MUST support the S-tagged mode on any of its LAN side interfaces.

R5. The NT MUST support the Port tagged mode on any of its LAN side interfaces.

R6. The NT MUST support the Customer edge tagged port mode on any of its LAN side

interfaces.



N° Requirement

R7. The NT MUST only allow the configuration of a single port mode type per physical

(LAN side) interface.

R8. The port mode types for each LAN side physical interface on a given NT device MUST

be able to be independently configured, i.e. they do not need to be of the same type.

7.3 VLAN HANDLING

The following 3 subsections specify the VLAN tag adding, removal and translation for the 3 different

port types. The handling is dependent on both the tagging of the incoming packets, and whether the

handover at the NNI is single or double tagged.

7.3.1 S-TAGGED UNI

N° Requirement

R9. The NT MUST support the configuration of one and only one S-VID per LAN side port as the untagged UNI.

R10. The NT MUST support the configuration at least 4 SVIDs per LAN side port (including the untagged UNI S-VID).

R11.

The NT MUST accept any LAN side, ingress untagged, priority tagged, or S-tagged frames with the VID that matches the configured, untagged UNI VID, remove the S-tag (if present), add the configured default NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.

R12.

The NT MUST accept any LAN side ingress S-tagged frames with a VID which matches any of the configured VID values for that port, remove the S-tag, add the configured NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.

R13. The NT MUST drop any LAN side ingress S-tagged frames with an SVID which does not match the untagged UNI VID, or any of the other configured S-tags for that port.



7.3.2 CUSTOMER EDGE PORT UNI

N° Requirement

R14. The NT MUST support the configuration of one and only one CVID per LAN side port as the multicast VID.

R15. The NT MUST accept any LAN side, ingress C-tagged frame with a VID that matches the configured, multicast VID, remove the C-tag, add the configured NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.

R16.

The NT MUST accept any LAN side, ingress untagged, priority tagged, or C-tagged frames with a VID that does NOT match the configured, multicast VID, add the configured default NNI S-tag or S and C tag pair and forward to the appropriate upstream WAN port queue.

R17. The NT MUST be able to copy the .1p bits in the outermost customer tag to the added S-tag, or S and C-tags.

R18. The NT MUST forward WAN side, ingress frames to ports on the basis of the S-tag. The NT MUST remove the S or S+C tags imposed by the ALA network.

7.3.3 PORT TAGGED UNI

N° Requirement

R19. The NT MUST accept any LAN side, ingress frames, add the configured NNI S-tag or S and C tag pair for that port, and forward to a single upstream WAN port queue regardless of any ingress .1p markings.

R20. The NT MUST forward WAN side, ingress frames to ports on the basis of the S-tag. The NT MUST remove the S or S+C tag imposed by the ALA network.

7.4 FRAME TRANSPARENCY

N° Requirement

R21. The NT MUST transparently forward any VLAN tags that may be present in the payload of the Ethernet frame that are not used for AUC classification.



N° Requirement

R22.

The NT MUST transparently forward any Ethernet frame types except for the following control frames which MUST be dropped:

nBmB Line Code

Inter-Frame Gap

Preamble

Start of frame delimiter

Pause Frames.

R23. The NT MUST process the Frame Check Sequence and discard any errored frames.

.

7.5 UPSTREAM QOS SUPPORT

ALA provides 4 Classes of service, which allows support for a variety of service types such as voice,

unicast and multicast video, data and a lower class data service which receives a maximum defined

share of the available bandwidth under congestion.

N° Requirement

R24. The NT MUST support all 4 ALA classes of service (A,B,C,D).

R25. The NT MUST support giving Class A traffic strict priority over all other classes.

R26. The NT MUST support giving Class B traffic strict priority over classes C and D.

R27. The NT MUST support a configurable weighting between Class C and Class D traffic in the event of upstream congestion.

R28. The NT MUST support a configurable, per-Class policer for Classes A, B and C+D for each AUC.

R29. The NT MUST support a total of at least 8 queues (allocated over all its AUCs), of which at least 6 MUST be able to be strict priority.



7.6 QOS MARKINGS

N° Requirement

R30.

The NT MUST allocate packets to Classes on the basis of the following markings for C-tagged frames, or S-tagged frames with a TPID=0x8100:

PCP Class

4 A

3 B

2 C

1 C drop eligible

0 D

R31.

The NT MUST allocate packets to Classes on the basis of the following markings for S-tagged frames with a TPID=0x88a8:

PCP DEI Class

4 X A

3 X B

2 0 C

2 1 C drop eligible

1 X C drop eligible

0 X D

R32. The NT MUST treat user packets which do not have a defined PCP marking, i.e. PCP = 5, 6 or 7, as Class C, Drop Eligible or drop them.



7.7 ENERGY EFFICIENCY

The ALA NT is a simpler device than a full blown HG, and further, the primary purpose of the NT is to

terminate the access transmission system. There is therefore less opportunity for power saving than

with an HG, especially given the increase in services such as Smart Grid, security and Cloud which

require a continuous access connection.

However one of the features of the ALA NT is its multiple LAN side Ethernet interfaces. These may not all

be used in all deployments and so there is the opportunity to turn some off. This is done automatically

by detecting the absence of a cable, rather than by management control.

N° Requirement

R33. The NT MUST automatically power down any LAN side Ethernet port which is not connected to an external cable.

R34. The NT MUST ensure that any LAN side Ethernet ports is powered up within 3 seconds

of an external cable being plugged into that port.

R35. The NT MUST comply with the appropriate power consumption levels of the EU CoC

on Broadband Power.

R36. The NT Ethernet ports MUST be of the Energy Efficiency type (IEEE 802.az).

7.8 MULTICAST SUPPORT

.N° Requirement

R37. The NT MUST only deliver multicast frames to the LAN side port mapped to a given AUC.

R38. The NT MUST NOT broadcast multicast packets to LAN side ports.

R39. The NT MUST NOT support IGMP snooping and replication.

7.9 SECONDARY LAN INTERFACES

The primary purpose of a secondary LAN interface is to provide L2, wireless connectivity to sensors or

controllers used as part of a utility service such as security and home automation, or Smart Grid related

applications.



N° Requirement

R40.

The NT SHOULD be able to support at least one of the following secondary LAN interfaces:

Zigbee

Z-Wave

DECT ULE.



8 TECHNOLOGY SPECIFIC REQUIREMENTS

Four different types of WAN interface are specified in this document:

VDSL2

Ethernet (short reach, electrical)

GPON

Point to point fibre (long reach, single mode)

Any given NT would normally only have one of these WAN interface types.

While the same architecture can in principle apply to a cable network, there are some significant technology, functional and commercial differences between a cable network and the above access types, and so cable access is not covered in this document.

8.1 VDSL2

8.1.1 WAN-SIDE INTERFACES

N° Requirement

R41. The NT MUST support VDSL2 as per [5].

R42.

The NT MUST support at least the following VDSL2 Region B bandplans:

Plan 997, 7 MHz

Plan 997, 12 MHz

Plan 997, 17 MHz

Plan 998, 8.5 MHz

Plan 998, 12 MHz

Plan 998, 17 MHz.

R43. The NT SHOULD support the bonding of 2 VDSL access systems according to G.bond.



8.1.2 LAN-SIDE INTERFACES

N° Requirement

R44. The NT MUST provide at least 2 LAN-side 100/1000 Mbps Ethernet ports.

Note: 100/1000 Mbps means the ability to support 100 Mbps and 1Gbps

R45. The LAN-side ports MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.

8.2 UPSTREAM QUEUES

N° Requirement

R46. The NT MUST support allocating any queue to any AUC.

R47. The NT MUST support mapping packets to queues on the basis of VID and priority bit.

R48. The NT MUST support at least 8 strict priority queues with at least 6 different priority levels.

R49. Each queue MUST have a configurable weighting.

R50.

Where 2 or more queues have the same priority level, the NT MUST schedule between

these queues on a WRR basis. Where the weights are equal, the scheduling

opportunities MUST be done on a single packet by packet basis.

R51. The NT MUST support a configurable policer per queue.

An example queuing implementation is shown in Annexe 1.

8.3 ETHERNET WAN INTERFACE

8.3.1 WAN INTERFACE

N° Requirement

R52. The NT MUST support a single 100/1000 Mbps WANside electrical Ethernet interface.



N° Requirement

R53. The WANside port MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.

8.3.2 LAN INTERFACES

N° Requirement

R54. The NT MUST provide at least 4 LAN side 100/1000 Mbps Ethernet interfaces.

R55. The LAN side ports MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.

8.4 UPSTREAM QUEUES

N° Requirement





8.5 GPON

8.5.1 WAN INTERFACE

N° Requirement

R60. The NT MUST provide a GPON interface as per ITU-T G.984 [6]




N° Requirement

R61. The NT MUST provide 4 LAN side100/1000 Mbps interface.

R62. The LAN side interfaces MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.

8.5.3 T-CONTS

N° Requirement

R63. The NT MUST support at least 4, Type 5 T-CONTs per port.

8.6 POINT TO POINT FIBRE

8.6.1 WAN INTERFACE

N° Requirement

R64. The NT MUST support a single mode, Gigabit Ethernet Fibre (LX) interface.


N° Requirement

R65. The NT MUST provide at least 4 LAN side100/1000 Mbps ports.

R66. The LAN side ports MUST support rate auto-negotiation between 100 Mbps and 1 Gbps.



8.7 UPSTREAM QUEUES

N° Requirement







9 DIAGNOSTICS

These requirements are a simplified subset of the HG diagnostics requirements specified in [7]. The NT

has no concept of service signatures, and so packet counting can only be qualified by the value of the

.1p bits. Access to these counters is only available remotely.

N° Requirement

R71. All the following counters in this Section MUST be available for each WAN and LAN interface logical (L2) interface.

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

R73. Every counter MUST be reset upon reception of a specific remote management command.

R74. All counters SHOULD be individually resettable via a remote management command.

R75. The current value of all counters MUST be able to be read by a remote management system.

R76.

The NT MUST have a single configurable sample interval. The sample interval MUST be configurable from 1-60 seconds with 1 second granularity and SHOULD be configurable from 1-900 seconds.

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

R78. The NT MUST store in DRAM the last N results for the sample interval counters, where N is configurable from 1 to 256.

R79. The NT MUST maintain a sample interval count of the number of sent packets with a specified .1p marking.

R80. The NT MUST maintain a sample interval count of the number of received packets with a specified .1p marking.



10 OAM

These requirements are adapted from the RG OAM requirements in the BB Forum TR-101v2

specification [2].

10.1 ALA-USER MEG

N° Requirement

R81. The NT MUST support a Maintenance association End Point (MEP) on a per VLAN basis.

R82. The NT MUST support a default ME level value of 5 for the Customer level.

R83.

The NT SHOULD support a Loopback Message (LBM) function that can generate a Multicast LBM towards its peer MEP(s). This requirement allows the HG to dynamically learn the MAC address of the BNG MEP (i.e. from the LBR) and could also be used to announce the HG MEP MAC address to the BNG upon request.

R84. The NT MUST support a Loopback Reply (LBR) function towards its peer MEP(s) in response to both unicast and multicast LBMs.

R85. The NT MUST support a Link Trace Reply (LTR) function towards the source address of a received LTM.

R86. The NT SHOULD support generating Continuity Check Messages (CCMs).

R87. The NT MUST support turning off the sending of CCMs, while keeping the associated MEP active.

R88. The NT MUST support receiving AIS messages.

R89. The NT SHOULD trigger the appropriate alarms for Loss of Continuity.



11 MANAGEMENT

Management of GPON NTs is expected to be done by OMCI, and so there are no additional ONT

management requirements.

Management of VDSL, Ethernet and point to point fibre NTs will be IP-based and therefore require an IP-

stack and support for CWMP.

N° Requirement

R90. Non GPON NTs MUST have an IP stack for management purposes.

R91. Non GPON NTs MUST support CWMP based management as per [8], [9] and [10] etc.



12 REFERENCES 1 NICC ND 1644 V1.1.1

http://www.niccstandards.org.uk/files/current/ND1644v1.1.1.pdf?type=pdf 2 Migration to Ethernet-Based Broadband Aggregation - TR101v2, Broadband Forum, 2011 3 Home Gateway Technical Requirements: Residential Profile V1.01 - HGI-RD001-R2.01, 2008 4 Requirements for HG Interworking with an External NT- HGI-RD007-R2, 2009 5 ITU G.993.2, 2011 6 ITU G.984.1, 2008 7 HGI-RD016 ”Home Gateway and Home Network Diagnostics Module Requirements” 8 CPE WAN Management Protocol - (TR-069 Amendment 4, Broadband Forum 2011) 9 Internet Gateway Device Data Model for TR-069 - TR-098 Amendment 2, Broadband Forum,

2008 10 Device Data Model for TR-069 - TR-181 Issue 2, Amendment 6, Broadband Forum, 2012

http://www.niccstandards.org.uk/files/current/ND1644v1.1.1.pdf?type=pdf



1 ANNEXE 1

Figure 2 shows a scheduling implementation at the ALA NT VDSL2 upstream interface supporting 2, 4-

Class ALA users. However as the primary reason for not sharing Class B queues is to control multicast

injection, in this example (upstream) Class B traffic is shown sharing a queue.

Figure 2: VDSL interface upstream scheduling example

On the ALA NT upstream ingress, class A and class B traffic is policed according to the ingress bandwidth

profile for the AUC group corresponding to each ALA User. This allows traffic from ALA User X and ALA

User Y to share the Class B upstream queue, but the Class A traffic for each user is queued separately so

the jitter is constrained to a single packet. Class A traffic is scheduled with strict priority over Class B

traffic. Class B traffic is scheduled with strict priority over Class C/D traffic.

Class C and Class D are scheduled using a weighted round robin algorithm. The weighting between Class

C and Class D traffic is combined with any weighting desired between the traffic of different ALA Users.

In this case the bandwidth is split 60:40 between ALA Users (as they are taking different products) and

the split between Class C and Class D is 90:10 for User X, and 75:25 for User Y. The Class C and Class D

queues use WRED to ensure that drop eligible frames tend to be discarded first.

Priority 3

Priority 2

Priority 1

VDSL2

interface (US)

DWRR

Class A, ALA User X

ALA User X, Class C, Weight = 54%

ALA User X, Class D, Weight = 6%

ALA User Y, Class C, Weight = 30%

ALA User Y, Class D, Weight = 10%

Class B, ALA User X&Y

Class A, ALA User Y

Round

Robin



<End of Document>