Muse DTF3.1 V09

Project Deliverable
IST - 6th FP
Contract N 507295
D TF3.1 Subscriber Interface
Andreas Foglar
Infineon Technologies, Balanstrasse 73, 81541 Munich, Germany
Andreas.foglar@infineon.com
Identifier:
Deliverable D TF3.1
Class:
Report
Version:
09
Version Date:
20/01/2005
Distribution:
Consortium Confidential
Responsible Partner:
IFX
Filename:
TF3-0001-V09.doc
1/70
Project Deliverable
IST - 6th FP
Contract N 507295
DOCUMENT INFORMATION
Project ref. No.
IST-6thFP-507295
Project acronym
MUSE
Project full title
Multi-Service Access Everywhere
Security (distribution level)
Contractual delivery date
31.12.2004
Actual delivery date
20.01.2005
Deliverable number
TF3.1
Deliverable name
Specification of subscriber interface between public network

and local network
Type
Report
Status & version
09
Number of pages
70
WP / TF contributing
TF3
WP / TF responsible
IFX
Main contributors
EAB, PT, LU, FT, DT, ALC, STM, THO, TID, INR, NTU, UC3
Editor(s)
Alun Foster (STM), Harold Balemans, Willem van Willigenburg

(LU), Alex de Smedt, Sam DHaeseleer (THOB), Arturo Azcorra, Francisco Valera (UC3), Erland Sundberg (TS), Thomas
Haag (DT)
EU Project Officer
Pertti Jauhiainen
Keywords
Home Gateway, Residential Gateway, Subscriber Interface
Abstract (for dissemination)
Functional description of Routing Gateway starting from DSL

Forum TR-58 with addition of new MUSE specific functions:
multi-service and multi-user capability with QoS. Consideration
of new MUSE business role models.
2/70
IST - 6th FP
Contract N 507295
Project Deliverable
DOCUMENT HISTORY
Version
Date
Author
Partner
Comments and actions
01
25.03.04
Foglar
IFX
First draft
01_TS
25.10.04
Sundberg
TS
Included draft on termination of P2P

fibre access (chapt 3.2)and proposed a
new chapter on physical implementation (chapt 7)
02
30.10.04
Foglar
IFX
Fundamental change of ToC decided in

conference calls October 27 and 29
03
04.11.04
De Smedt
THOB
Contribution from WPB3
05.11.04
Azcorra, Balemans, Garca,

Guerrero, Valera, van Willigenburg
UC3M
LU
Contribution from WPD3
09.11.04
Foglar
IFX
Editorial, minor comments
04
17.11.04
Foglar
IFX
Open issues list moved to top and

NT1/2 consolidated (section 1.2
1.2.3). New appendix QoS over 1st
Mile.
05
18.11.04
Foglar
de Smedt
Balemans
IFX
THOB
LU
Inclusion of reference configuration

from Alex and comments from Harold
06
10.12.04
Foglar
Balemans
IFX
LU
Consolidated version with all inputs

from Valladolid meeting and conference call December 21
07
09.01.05
Foglar
IFX
Comments from Foster; functional

blocks adapted to DSL Forum: figures
3 & 10 modified; figure 4 corrected; list
of abbreviations; executive summary
08
11.01.05
Haag
DT
Extension to OAM chapter.
09
20.01.05
Foglar
IFX
Quality review comments worked in
3/70
Project Deliverable
IST - 6th FP
Contract N 507295
TABLE OF CONTENTS
DOCUMENT INFORMATION ..................................................................................................................2
DOCUMENT HISTORY............................................................................................................................3
TABLE OF CONTENTS...........................................................................................................................4
LIST OF FIGURES AND TABLES ..........................................................................................................6
ABBREVIATIONS....................................................................................................................................8
REFERENCES .......................................................................................................................................14
EXECUTIVE SUMMARY........................................................................................................................15
CONCLUSIONS AND NEXT STEPS.....................................................................................................16
1
INTRODUCTION ............................................................................................................................17
1.1
Strategy ..................................................................................................................18
1.2
MUSE specific functions (from SPA, Access Architectures)................................18
1.2.1
Multiple Connections ..............................................................................................19
1.2.2
Quality of Service QoS ...........................................................................................19
1.2.3
New Business Roles...............................................................................................20
CPE FUNCTIONAL BLOCKS........................................................................................................22

2.1
NT1 Functionality....................................................................................................23
2.1.1
Data Path................................................................................................................24
2.1.2
Management Plane.................................................................................................27
2.2
Reference point RG ................................................................................................28
2.3
NT2 Functionality....................................................................................................28
2.3.1
NT2 with IP lookup..................................................................................................30
2.3.2
NT2 as Ethernet Bridge ..........................................................................................30
2.3.3
NT2 Management Plane.........................................................................................31
IMPLEMENTATION OPTIONS ......................................................................................................33

3.1
NT Box Applications ...............................................................................................33
3.1.1
PC ...........................................................................................................................34
3.1.2
Analogue Phone .....................................................................................................34
3.1.3
IP Phone .................................................................................................................34
3.1.4
Home Router ..........................................................................................................35
3.2
NT Box Implementation ..........................................................................................35
MANAGEMENT PLANE ................................................................................................................36

4.1
Management Responsibilities.................................................................................36
4.2
Ethernet OAM .........................................................................................................37
4.2.1
Basics for Operation ...............................................................................................37
4.2.2
Basic requirements for OAM ..................................................................................37
4.2.3
Customer Identification...........................................................................................38
4.2.4
CPE aspects ...........................................................................................................39
4.3
Generic Layer 1 Management Data Base ..............................................................40
CONTROL PLANE.........................................................................................................................41
APPENDIX......................................................................................................................................42
6.1
Home network technologies: USB..........................................................................42
6.1.1
Overview.................................................................................................................42
6.1.2
Bandwidth ...............................................................................................................43
6.1.3
Distance information (meters) ................................................................................43
4/70
Project Deliverable
6.1.4
6.1.5
6.1.6
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.2.5
6.2.6
6.3
6.3.1
6.3.2
6.3.3
6.3.4
6.3.5
6.4
6.4.1
6.4.2
6.4.3
6.4.4
6.4.5
6.4.6
6.4.7
6.4.8
6.4.9
6.5
6.5.1
6.5.2
6.5.3
6.5.4
6.6
6.6.1
6.6.2
6.6.3
6.6.4
6.6.5
IST - 6th FP
Contract N 507295
Latency ...................................................................................................................43
Layer 2 QoS............................................................................................................43
Limitations...............................................................................................................43
Home network technologies: Bluetooth ..................................................................44
Core architecture overview.....................................................................................44
Modulation and Bandwidth .....................................................................................46
Distance information ...............................................................................................46
Latency and QoS ....................................................................................................46
Bluetooth profiles ....................................................................................................47
Limitations...............................................................................................................47
Home network technologies: WLAN.......................................................................48
Overview.................................................................................................................48
Protocol suite ..........................................................................................................49
Available Bandwidth ...............................................................................................49
Latency ...................................................................................................................51
Layer 2 QoS mechanism ........................................................................................51
GSB Traffic Classes over slow Access Lines.........................................................54
Packet multiplexing.................................................................................................55
QoS class support ..................................................................................................55
Jitter calculation for highest priority queue .............................................................57
Jitter calculation for lower priority queues ..............................................................60
ATM or PTM-TC? ...................................................................................................60
Pros and cons of multiple ADSL paths ...................................................................61
Fulfilling GSB traffic classes ...................................................................................62
Correlating low jitter flows.......................................................................................65
Conclusion ..............................................................................................................67
Layer 1 Example: PON...........................................................................................67
Interface for Point to Point Ethernet over SM fibre.................................................67
Optical characteristics of the U interface................................................................67
Performance requirements .....................................................................................68
Mechanical properties of U interface ......................................................................68
Layer 1 Example: SHDSL.......................................................................................68
General Definitions .................................................................................................68
Electrical characteristics of the SHDSL U interface ...............................................69
Performance requirements .....................................................................................69
Mechanical properties of SHDSL U interface.........................................................69
Management of the SHDSL physical layer.............................................................70
5/70
Project Deliverable
IST - 6th FP
Contract N 507295
LIST OF FIGURES AND TABLES

Figures
Figure 1: Customer Premises Equipment..............................................................................16
Figure 2: The business role model that was introduced in DA1.1 [2] ....................................21
Figure 3: CPE Functional Blocks...........................................................................................22
Figure 4: Components of NT1 ...............................................................................................24
Figure 5: Protocol stack in case of ATM-TC..........................................................................26
Figure 6: Protocol stack in case of PTM-TC..........................................................................26
Figure 7: Protocol stack in case of IPv6 over ATM-TC..........................................................27
Figure 8: Minimum Home Network Configuration..................................................................34
Figure 9: Basic Home Network Configuration .......................................................................35
Figure 10: Functional Blocks of NT Box ................................................................................35
Figure 11: Tentative Responsibilities for Functional Blocks ..................................................36
Figure 12: Service Connection set-up Signalling...................................................................41
Figure 13: Bluetooth core system architecture ......................................................................44
Figure 14: Bluetooth transport architecture ...........................................................................45
Figure 15: Relation between upper stack protocols and most common profiles ...................48
Figure 16: WLAN Throughput................................................................................................50
Figure 17: Packet Error Rate vs. Signal to Noise ..................................................................51
Figure 18: WLAN QoS Mechanisms......................................................................................52
Figure 19: WLAN QoS Solution.............................................................................................53
Figure 20: WLAN Framing.....................................................................................................54
Figure 21: Upstream traffic model .........................................................................................55
Figure 22: Output port traffic model.......................................................................................56
Figure 23: Worst case jitter....................................................................................................57
Figure 24: Maximum load per QueueSize given in multiples of PacketSize for packet loss
probability 10-11 ...............................................................................................................59
probability 10-7 .................................................................................................................60
Figure 26: Options for low latency flows................................................................................61
Figure 27: Uncorrelated flows................................................................................................66
Figure 28: Correlated flows ...................................................................................................66
TablesTable 1: NT1 Configuration Parameters .....................................................................28
Table 2: NT1 Error Messages................................................................................................28
6/70
Project Deliverable
IST - 6th FP
Contract N 507295
Table 3: NT2 Configuration Parameters ................................................................................32

Table 4: NT2 Error Messages................................................................................................32
Table 5: Bluetooth maximal bandwidth specifications ...........................................................46
Table 6: WLAN Standards .....................................................................................................49
Table 7: Defaults values EDCA .............................................................................................52
Table 8: tentative values for GSB traffic classes ...................................................................63
Table 9: Some key values for a 1ms-class ............................................................................63
Table 10: Some key values for a 30ms-class ........................................................................64
Table 11: Some key values for a 900ms Guaranteed Rate class..........................................65
Table 12: PON Options..........................................................................................................67
Table 13: PON Optical Parameters .......................................................................................68
Table 14: U-RS pin allocation ................................................................................................70
7/70
Project Deliverable
IST - 6th FP
Contract N 507295
ABBREVIATIONS
AAA
Authentication, Authorization & Accounting
AAL
ATM Adaptation Layer
ACS
Auto-Configuration Server
ADSL
Asymmetric Digital Subscriber Line
AF
Assured Forwarding
ALG
Application Layer Gateway
AM
Access Multiplexer
APON
ATM Passive Optical Network
ARP
Address Resolution Protocol
ASP
Application Service Provider
ATM
Asynchronous Transfer Mode
ATA
Analogue Terminal Adapter
BAS
Broadband Access Server
BER
Bit Error Rate
B-NT
Broadband Network Termination
BRAS
Broadband Remote Access Server
CAC
Call Admission Control
CATV
Cable TV
CHAP
Challenge Handshake Authentication Protocol
CoS
Class of Service
CPE
Customer Premises Equipment
CPN
Customer Premises Network
CRC
Cyclic Redundancy Check
C-VLAN
Customer Virtual Local Area Network
CWDM
Coarse Wavelength Division Multiplexing
DF
Default Forwarding
DiffServ
Differentiated Services
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
DP
Distribution Point
DSCP
Differentiated Services Code Point
DSL
Digital Subscriber Line
DSM
Dynamical Spectrum Management
EAP
Extensible Authentication Protocol
8/70
Project Deliverable
IST - 6th FP
Contract N 507295
EF
Expedited Forwarding
EFM
Ethernet in the First Mile
ELMI
Ethernet Link Management Interface
EOC
Embedded Operation Channel (of ADSL)
EPON
Ethernet Passive Optical Network
ETH
Ethernet
EUT
End-User Terminal
EVC
Ethernet Virtual Connection
FEC
Forward Error Correction
FOO
Sample name for absolutely anything ("whatever"). See RFC3092
FPD
Functional Processing Device
FQDN
Fully Qualified Domain Name
FTTB
Fibre To The Building/Business
FTTCab
Fibre To The Cabinet
FTTEx
Fibre To The Exchange
FTTH
Fibre to the Home
FTTO
Fibre To The Office
FWA
Fixed Wireless Access
GARP
Generic Attribute Registration Protocol
GbE
Gigabit Ethernet
GFR
Generic Frame Rate
GMRP
GARP Multicast Registration Protocol
GPON
Gigabit-capable Passive Optical Network
GSB
Global System for Broadband communication
HSI
High Speed Internet
IAD
Integrated Access Devices
IANA
Internet Assigned Numbers Authority
IEEE
Institute of Electrical and Electronics Engineers
IFG
interframe Gap
IGMP
Internet Group Management Protocol
ILEC
Incumbent Local exchange Carrier,
ILMI
Interim Local Management Interface
IMS
IP Multimedia Subsystem
IntServ
Integrated Services
IP
Internet Protocol
9/70
Project Deliverable
IST - 6th FP
Contract N 507295
IPCP
IP Control Protocol
IPDV
IP packet Delay Variation
IPER
IP packet Error Ratio
IPG
Interpacket Gap
IPLR
IP packet loss ratio
IPTD
IP packet Transfer Delay
IPv4
Internet Protocol version 4
IPv6
Internet Protocol version 6
ISDL
ISDN Digital Subscriber Line
ISP
Internet Service Provider
ITU-T
International Telecommunication Union Telecommunication standardisation sector
LAC
L2TP Access Concentrator
LACP
Link Aggregation Control Protocol
LCP
Link Control Protocol
LER
Label Edge Router
LEx
Local eXchange
LMI
Local Management Interface
LNS
L2TP Network Server
LSP
Label Switched Path
LSR
Label Switching Router
MAC
Media Access Control
MAC DA
Media Access Control Destination Address
MAC SA
Media Access Control Source Address
MAC FF
MAC Forced Forwarding
MBGP
Multicast Border Gateway Protocol
MDF
Main Distribution Frame
MEF
Metro Ethernet Forum
MIDCOM
MIDdlebox COMmunications
MITM
Man-in-the-Middle
MPEG
Motion Picture Expert Group
MPLS
Multi-protocol Label Switching
NAP
Network Access Provider
NAPT
Network Address and Port Translator
NAT
Network Address Translator
NGN
Next Generation Network
10/70
IST - 6th FP
Contract N 507295
Project Deliverable
NSP
Network Service Provider
NT
Network Termination
OSGi
Open Services Gateway Initiative
OAM
Operations, Administration & Maintenance
OLT
Optical Line Terminator
ONT
Optical Network Terminator
ONU
Optical Network Unit
PAP
Password Authentication Protocol
PBX
Private Branch eXchange
PDU
Protocol Data Unit
PDV
Packet Delay Variation
PHY
Physical Layer
PLOAM
Physical Layer Operation, Administration and Maintenance
PON
Passive Optical Network
PoP
Points of Presence
PPP
Point-to-Point Protocol
PPPoA
PPP over ATM
PPPoE
PPP over Ethernet
PPV
Pay Per View
PSTN
Public Switched Telephone Network
PTM
Packet Transfer Mode
P-t-MP
Point to Multi Point
P-t-P
Point to Point
PVC
Permanent Virtual Connection
QoS
Quality of Service
RADIUS
Remote Authentication Dial In User Service
RADSL
Rate-Adaptive Asymmetric Digital Subscriber Line
RE-ADSL
Reach Extended Asymmetric Digital Dubscriber Line
RDI
Remote Defect Indication (OAM function)
RFC
Request for Comment
RG
Reference point at residential Gateway
RGW
Residential Gateway
RNP
Regional Network Provider
SAR
Segmentation and Reassembly
SDH
Synchronous Digital Hierarchy
11/70
Project Deliverable
SDSL
Symmetric Digital Subscriber Line
SG
Service Gateway
SHDSL
Single-pair high-speed digital subscriber line
SIP
Session Initiation Protocol
SLA
Service Level Agreement
SLS
Service Level Specification
SNMP
Simple Network Management Protocol
SP
(MUSE terminology) Sub Project
ST
Service Termination
STB
Set Top Box
STP
Spanning Tree Protocol
S-VLAN
Service Virtual Local Area Network
T-CONT
Traffic Container
TC
Transmission Convergence (layer)
TCP
Transmission Control Protocol
TDM
Time Division Multiplexing
TDMA
Time Division Multiple Access
ToIP
Telephony over IP
ToS
Type of Service
TVoIP
TV over IP
UDP
User Datagram Protocol
UNI
User to Network Interface
URL
Universal Resource Locator
VC
Virtual Channel
VCC
Virtual Channel Connection
VCI
Virtual Channel Identifier
VDSL
Very high speed Digital Subscriber Line
VLAN
Virtual Local Area Network
VoD
Video on Demand
VoDSL
Voice-over Digital Subscriber Line
VoIP
Voice over IP
VP
Virtual Path
VPI
Virtual Path Identifier
WAN
Wide Area Network
WP
(MUSE terminology) Work Package
12/70
IST - 6th FP
Contract N 507295
Project Deliverable
xDSL
IST - 6th FP
Contract N 507295
xDSL refers to different variations of DSL, such as ADSL, HDSL, and RADSL
13/70
Project Deliverable
IST - 6th FP
Contract N 507295
REFERENCES
[1]
Technical Report DSL Forum TR-058 Multi-Service Architecture & Framework Requirements, September 2003
[2]
MUSE deliverable D A1.1 Towards multi-service business models, June 2004
[3]
MUSE deliverable D TF1.2 Node requirements for applying QoS and GoS, December 2004
[4]
Draft Standard P802.1p/D8 IEEE Standards for Local and Metropolitan Area Networks Supplement to Media Access Control (MAC) Bridges: Traffic Class Expediting
and Dynamic Multicast Filtering, October 21, 1997
[5]
ITU-T STUDY GROUP 15 Temporary Document SI-022, ADSL: Draft new G.992.3
Annex K.4 (64/65 based PTM-TC), Stresa, Italy, 18-22 October, 2004
[6]
Draft Standard IEEE P802.1ad/D2.0 Virtual Bridged Local Area Networks Amendment 4: Provider Bridges, December 15, 2003
[7]
QoS as service enabler for BB Access, Presentation by Romain Vinel, France Telecom; Broadband Europe, Bruges - December 8-10, 2004; link:
http://www.ist-muse.org/Documents/BBEurope/BBEurope_RomainVinel.pdf
14/70
Project Deliverable
IST - 6th FP
Contract N 507295
EXECUTIVE SUMMARY
This document reflects one year work on the functional details of the MUSE residential gateway. Starting with DSL Forum reference architecture (TR-58) the functionality of the Routing
Gateway was broken down into small functional blocks. In parallel the enhanced functionality
of MUSE networks was introduced, in particular
Multi-user and multi-service support
Quality of Service QoS support.
Also the new service provider roles defined in WPA1 had to be considered. They lead to
functional entities which can be assigned individually to service providers.
TF3 goal is to assure that a GSB compliant residential gateway shall work in every GSB network. GSB, the Global System for Broadband communication is defined by MUSE for broadband access networks. Within the GSB framework this document specifies an universal residential gateway architecture. Well defined interfaces shall assure easy adaptation to various
first mile technologies and also to the large variety of home network scenarios.
The common residential gateway architecture must support different access technologies
ranging from a few hundred kb/s up to 100Mb/s. Another challenge is the variety of residential network configurations ranging from a simple analogue phone up to mid-size networks
with several terminals and triple play services. Solutions must be scalable and still be cost
effective in all application scenarios.
An answer to this challenge apart from a perfect architecture is the definition of explicit
values for parameters. Explicit values can be hard-coded and must not be configured. This
makes a solution easy to use and less complex. In this document a first attempt is made to
agree on explicit values. Throughout the document explicit values are proposed with the term
default value. In case there is no objection within the run-time of MUSE, these default values could become (industry) standard values.
The main part of this document is the Layer 2 and 3 functional description of the residential
gateway. The physical layer of the 1st mile is not a central part of the specification, but the
Transmission Convergence (TC) sub-layer is considered. For reference two examples for
physical layer interfaces are given, one electrical (SHDSL) and one optical. Another appendix studies thoroughly how to fulfil the high-end QoS of MUSE over slow access lines. Also
some background information about home network technologies is given.
Management protocols such as ELMI, OSGI, SNMP are not covered, but configuration parameters are listed. This simplifies further work on residential gateway management. The
goal of a common set of physical layer parameters could not be achieved for this deliverable.
It will be tackled in future documents.
Control plane functions such as signalling protocols are not yet finalised in SPA. Therefore
no final solution can be given in this document. Control messages use data path connections and no special signalling connection. A control flow may share a connection with another control flow or with a data flow. It could also use a dedicated connection. The QoS of
the control flow must be selected accordingly.
15/70
IST - 6th FP
Contract N 507295
Project Deliverable
CONCLUSIONS AND NEXT STEPS

The Customer Premises Equipment CPE consists of Access Gateway AGW, Residential
Network and Terminals as shown in Figure 1. The Residential Network may contain equipment such as switches or (Home) Routers and Service Gateways. There are several types of
Service Gateways. If from Layer 3 upward all layers are terminated it is denoted a L3+ Service Gateway, such as for example an Analogue Terminal Adapter ATA. Accordingly a L2+
Service Gateway such as a Set-Top Box STB terminates all layers from L2 upwards. The L2
Service Gateway in Figure 1 just terminates Ethernet (ETH) and converts to Bluetooth by
preserving the Layer 3. In case the Access and Service Gateways are integrated in one box
it is called Residential (or Home) Gateway.
Residential
ATA
L3+ Service
Gateway
POTS
Gateway
ETH
Access
1st Mile
ETH
Gateway
Home
L2 Service
Router
Gateway
Bluetooth
ETH
ETH
STB
L2+ Service
Gateway
SCART
Residential Network
Terminals
Figure 1: Customer Premises Equipment

This document describes precisely the functionality of the Access Gateway AGW as the part
of the Residential Gateway which is most relevant for the access to the public network. The
Access Gateway also contains the main part of the additional functionality to support new
GSB features. The description is focussed on the data plane, with a first collection of configuration parameters for the management plane. Next steps will be:
GSB support in Service Gateways and Terminals (e.g. browser plug-in)
Detailed description of management plane as basis for auto-configuration.
16/70
Project Deliverable
IST - 6th FP
Contract N 507295
1 INTRODUCTION
With increasing functionality of the network also the complexity of the network termination NT
increases. In analogue telephony the NT is just a plug. The wire loop is closed in the terminal
(phone). With ISDN an active NT box is installed, which does signal conversion and also includes loop test functions. With ADSL a passive splitter is needed and the signal conversion
and loop test functions move into the modem. The modem could be built into a PC, but in
most cases it is a separate box with more or less additional functionality such as routing,
firewall and protocol conversion. With the additional functionality of the MUSE GSB solution
the complexity of the NT increases. The NT becomes an Access Gateway which includes
many other functions. Optionally in some cases the NT might be realised in a separate box.
In these cases it should contain most MUSE/GSB specific functions.
The GSB (Gobal System for Broadband communication) system defined by MUSE introduces among others two, new, technical features:
1. Multiple connections: while an ADSL modem uses a single connection to an Internet Service Provider ISP the MUSE access network offers several connections to different service providers. These connections can be permanent as with ADSL or dynamically set up on demand.
2. Quality of Service QoS: while ADSL based services today offer best-effort traffic
only, GSB networks will offer several QoS classes with selectable parameters such
as throughput, jitter etc.
Another aspect of MUSE GSB solution is standardisation. Todays ADSL solutions are not
fully compatible, but operator specific. It is not possible to re-use a modem from one operator
in the network of another operator, even within the same country. Also the manufacturer of a
modem must homologise it separately for each operator in each country. This leads to additional costs and is a big barrier for small manufacturers. To improve this situation MUSE
drives for standardisation.
3. MUSE aims at a European or even global standard (GSB) for home gateways. A
GSB compliant home gateway will work with all GSB networks. It is the aim of TF3
and also of this document to consolidate inputs from all subprojects.
Finally MUSE provides solutions for unbundling. Network access and transport are separated
from network and application services.
4. MUSE has defined new service roles such as packager, network access provider,
network service provider, application service provider. The residential gateway must
reflect the different service roles.
All the issues 1-4 listed above lead to enhanced functionality and hence enhanced complexity in the home gateway. On the other hand the home gateway should be as simple as
possible to keep cost low and to simplify operation. One big step to solve this conflict is the
QoS solution described in D TF1.2. It allows to configure automatically the schedulers in the
NT depending on the transmission rate. Another solution to solve this conflict is the agreement on explicit values.
17/70
Project Deliverable
IST - 6th FP
Contract N 507295
If for example explicit values are assigned to the four ATM VCs in the case of ATM segmentation there is no need to configure these values. GSB home gateways will automatically
support four traffic classes without configuration. One of the reasons for the success of
Ethernet and of the Internet is based on the assignment of fixed values. It is made visible in
RFC1340 and RFC3232, Assigned Numbers. On the other hand at the beginning one might
not overlook possible inconsistencies when choosing explicit values. Therefore throughout
this document proposed explicit values are denominated as default values (see Table 1
and Table 3). If within the runtime of MUSE no contradiction is detected these values will be
frozen.
The main part of this document is the Layer 2 and 3 functional description of the home gateway. The physical layer of the 1st mile is not a central part of the specification, but the
Transmission Convergence (TC) sub-layer is considered. For reference two examples for
physical layer interfaces are given, one electrical (SHDSL) and one optical.
Management protocols such as ELMI, OSGI, SNMP are not covered, but configuration parameters are listed. This simplifies further work on home gateway management.
Control plane functions such as signalling protocols are expected to be done in the terminal
and are not described in this document. Control messages use data path connections and no
special signalling connection. A control flow may share a connection with another control flow
or with a data flow. It could also use a dedicated connection. The QoS of the control flow
must be selected accordingly.
1.1 Strategy
MUSE has the goal to establish GSB, an (industry) standard solution for broadband access
networks. It will have added value services to be competitive against other solutions. Therefore MUSE will provide solutions for multi-service, QoS, security and other innovative features. These features must be offered at low cost, which means that maximum synergy must
be exploited from existing systems. For example use of Ethernet brings the economy of scale
from the LAN market into the access network.
Enhanced functionality means also additional complexity. Strategy is to concentrate the additional functions in a few points of the system. For example in the Access Network additional
functions will be located at the border, so that core components are not affected. In the CPE
the strategy is to implement all MUSE specific functions in the Home Gateway. Terminals
connected to the Home Gateway should not be adapted. Standard terminals like (IP) phone
and PC shall be connected to the Home Gateway and benefit from MUSE features.
1.2 MUSE specific functions (from SPA, Access Architectures)

In this section main results from subproject SPA are introduced which influence the home
gateway. These are technical and commercial results.
18/70
Project Deliverable
IST - 6th FP
Contract N 507295
1.2.1 Multiple Connections

In deliverable D A2.1 the service connection was introduced. A customer can have multiple
service connections to different service providers. These are usually addressed by the destination IP address. In an Ethernet base access network the service connections are supported by different flows. Forwarding of the flows in the Ethernet access network is based on
Ethernet MAC and/or VLAN ID. Typically the VLAN ID specifies the service provider, the destination MAC address the specific server and the source MAC address the customer. Several
other options are under investigation, such as stacked VLAN, MAC forced forwarding and
McCircuit. It is expected that MUSE will select one unique solution for supporting multiple
service connections in a carrier-grade Ethernet access network.
Although no clear favourite can be recognised today the home gateway functionality can be
specified in an universal way which fits to all possible scenarios (see Section 2.3).
1.2.2 Quality of Service QoS

In the first year of MUSE two QoS activities have been done. In a top-down approach a QoS
concept was derived in WPA2/TF1. In parallel a respective solution has been worked out in
SPC.
The QoS concept follows the traditional approach of the telecom world. Each service connection with specific QoS must be set up individually. An admission control process in the
network checks for available resources in the network and reserves them for the service
connection. Policing circuits at network border guarantee that the traffic contract is not exceeded.
The QoS solution follows a bottom-up approach. It starts with the specification of the network element behaviour and derives the end-to-end behaviour. Network elements are nodes
and home gateways. The definition of the node behaviour was technology driven, with the
aim to exploit Gigabit Ethernet capabilities. A high-end QoS solution for GSB shall be
achieved.
The QoS solution follows the network as master approach. Its idea is to offer a (small) set
of traffic classes with limited parameter ranges. The terminals are assumed to flexibly adapt
to the network offer. This approach does not try to adapt the network continuously to changing applications.
The QoS solution supports four traffic classes with one of them being best effort with no
guarantees at all. The other three classes are differentiated mainly by fixed values of the
packet jitter. Default jitter values have not yet been agreed, but first calculations have been
carried out using tentative values (see Appendix 6.4). A very low packet loss probability is
targeted for the traffic classes (except best effort). To fulfil the challenging traffic class behaviour restrictions are imposed on to the terminals and to the network.
At the terminal side the most severe restriction is the limitation of packet and/or burst size. At
the network side the most severe restriction is the maximum load allowed for each traffic
class. Typically the traffic class with the lowest jitter can only use a small percentage of the
transmission capacity. The second priority class can use roughly half of the capacity and the
third class close to 100% of the capacity.
19/70
Project Deliverable
IST - 6th FP
Contract N 507295
The QoS solution exploits the capabilities of Ethernet equipment, in particular the strict priority scheduling defined in 802.1p. Four of the eight priorities are used for the QoS solution. At
the network border per-connection policing must be implemented, a feature which is not supported by standard Ethernet equipment, but can be added easily at this point. At the network
border the rates tend to be low as well as the number of connections.
Implementation of the high-end QoS solution over slow access lines needs special measures
to be taken. These are segmentation in the TC layer (ATM or PTM with pre-emption) and restrictions on the number of independent flows. A detailed elaboration is given in Appendix 6.4.
1.2.3 New Business Roles

In WPA1 new business roles were defined (see Figure 2). Some of the provider roles are
relevant for the home gateway:
The Access Network Provider NAP is responsible of the last mile. Loop tests are initiated by the NAP.
The Connectivity Provider CP configures connections between home gateway and

service providers ASP and NSP; either via management or via network level signalling. The CP has network knowledge and is able to provide connectivity with the required QoS. It collects billing data.
The Packager provides a complete (triple play) service bundle to the customer. The
Packager has mainly an accounting role; the customer gets one single bill for all services from the Packager which is based on billing data collected by the CP. It has
no technical knowledge of the network.
Either CP or NAP or Packager provides the IP address of the customer. In case of

IPv6 the address prefix is assigned.
Application level signalling is exchanged between ASP/NSP and the terminals.
Each of the providers needs a counterpart in the CPE. NAP, CP and Packager exist only
once, but many ASP and NSP may be connected.
20/70
IST - 6th FP
Contract N 507295
Project Deliverable
Applications delivered with an assured QoS

Application
Service
Provider
Network
Service
Provider
Application
Service
Provider
Customer
Application
Service
Provider
Content
Provider
Packager
consumer
Connectivity
Provider
Application Service /
Content Provider
Customer
Access
Network
Provider
Regional
Network
Provider
Packager
Network Provider
Figure 2: The business role model that was introduced in DA1.1 [2]
The differentiated provider roles influence the structure of the home gateway. For comparison with ISDN the network termination was separated logically in NT1 and NT2, which are
controlled by network operator and customer, respectively. In MUSE this model must be expanded. There will be a termination for the NAP and one for the CP and one termination per
ASP/NSP. These terminations can be somewhat associated to OSI layers, for example the
NAP termination is Layer 1, CP termination Layer 2 and ASP/NSP terminations Layer 3. In
this document the network terminations for NAP and CP, NT1 and NT2 respectively, are primarily considered.
21/70
IST - 6th FP
Contract N 507295
Project Deliverable
2 CPE FUNCTIONAL BLOCKS

A reference configuration of all functional blocks at the customer premises site is shown in
Figure 3 below. The NT1 or B-NT terminates the physical layer of the first mile transmission
and is the counterpart of the NAP. The data format at the interface to the NT2 has been
uniquely defined as VLAN tagged Ethernet frames. In case the NT1 is a separate box an
Ethernet PHY such as 10/100baseT could be used. The NT2 is the counterpart of the Connectivity Provider CP. It is comparable to the Routing Gateway RGW in DSL Forum [1]. The
NT2 contains a mandatory block for forwarding, filtering and shaping, and optional blocks for
switching, routing and Network Address Translation NAT. This block terminates the IP layer
as shown in the protocol stack below. The Customer Premises Network CPN links to the
Service Termination block ST, which can work on Layer 2 or Layer 3. The ST2 typically terminates MPEG over Ethernet in Set-top boxes.
L3@ (e.g. IP@ )
known in Edge
Node
MAC@ known
in Access
Network
NT2 (RGW)
ST3
CPN
optional
L3 Termination
(e.g. NAT)
n 1
n 1
optional
optional
Ethernet
Ethernet
L3 routing
Forwarding &
Scheduling
n 1 Switching 1 1
Filtering
Filtering
QoS Scheduling
MAC termination
QoS Tagging
VLAN ID known
in Access
Network
Access Gateway AGW
NT1 (B-NT)
1 1
Rate
Adaptation
TC Layer
Filtering
Phy
Termination
ST2
Tcn
T1
RG
Data relay
L3
IP
IP relay
ETH
PHY
PHY
PHY
PHY
Ethernet over
Access Network
specific technology
Ethernet
+ VLAN
Ethernet
MAC relay
802.1P/Q
ETH
ETH
PHY
PHY
ETH relay
PHY
TC
PHY
Service Data
ETH
PHY
Figure 3: CPE Functional Blocks

Notes:
All the functional groupings are situated in equipment located at the customer premises.
So the conglomerate of all this equipment is called Customer Premises Equipment (CPE)
and it is interfacing to the first Access Node in the access network.
The grouping of sub-blocks into blocks is introduced for compatibility with DSL Forum
nomenclature (B-NT and RG). It does no preclude any implementation.
22/70
IST - 6th FP
Contract N 507295
Project Deliverable
The protocol stacks at the bottom of Figure 3 describe the data path. The default protocol stack is IP over Ethernet. One exception is Service Data over Ethernet for the application MPEG over Ethernet. This option avoids Layer 3 processing of high speed video
data.
Not all functional blocks need to be present, nor do functions need to be implemented in
separate devices. When several functions are integrated in a single physical device, related protocol stacks may be collapsed. These stacks are coloured light grey in the diagram.
ST2 is a termination for L2 service (e.g. MPEG over Ethernet) and performs service related network independent functions.
ST3 is a termination for L3 service. All transport framing is removed and service related
data is available for processing. ST3 may include coding and decoding, signaling, etc.
Both ST2 and ST3 can be located in the terminal (as in the case of a PC) or in a Service
Gateway (as in the case of an ATA).
The numbers between the functional blocks indicate the cardinality of the functions, e.g.
there is always exactly one NT1 per access line, but there can be multiple (n) ST2.
Media indicated by Y and Z in the protocol stacks are not necessarily Ethernet. Y may be
any IEEE standard transport technology with compatible MAC addresses. Z can be any
transport technology.
The term relay in the protocol stacks is a synonym for forwarding.
The blocks and the interfaces between are described below.
2.1 NT1 Functionality

This functional block is mainly responsible for the Layer 1 connection towards the Broadband
Access Network, and will therefore typically be managed by the NAP. The NT1 terminates
Layer 1 and provides the correct Transmission Convergence TC layer in ATM or PTM Mode.
Figure 4 shows the decomposition of NT1. The functions are described below.
23/70
Project Deliverable
IST - 6th FP
Contract N 507295
Re-assembly
& Packet
Scheduling
Filtering
TC Rx
TC-
PHY - Rx
Home
Network
Access
Network
Filtering
RG
TC - Tx
Segmentation
& Segment
Scheduling
PHY - Tx
Figure 4: Components of NT1
2.1.1 Data Path

Filtering: discarding of unwanted packets. The integrity of packets can be checked, e.g. by
CRC, and corrupted packets can be discarded. Additionally OAM loop and alarm Ethernet
packets from the access line could be extracted in downstream direction.
Segmentation and scheduling: this function is optional in both upstream and downstream
direction. It is required when the outgoing rate is much lower than the incoming rate. Typically this is the case in upstream direction for slow access lines. In downstream direction the
case that the U interface has much higher rate than the Tq interface is less obvious. It could
occur for example if the U interface is a 100Mb/s optical fibre and the Tc interface a 10baseT
Ethernet interface.
In case of asymmetric access lines it can happen that rate adaptation is necessary in both
up- and downstream direction.
For low access lines (up to ca. 10Mb/s) segmentation is necessary to support the real time
MUSE traffic classes. The calculation method for the queue sizes for the case of ATM TC
sub-layer is given in Appendix 6.4. Once the tentative QoS parameters are frozen a definite
calculation can be done. In case of PTM TC sub-layer pre-emption must be supported. The
highest priority stream will be allowed to pre-empt a pending packet transmission of any
other traffic class. The calculation method for PTM-TC can be done analogous to ATM TC.
The calculation method of Appendix 6.4 is valid also for fast line rates. For every line rate the
queue sizes of the scheduling circuit can be calculated and pre-configured as default values
in the NT1. In case of varying upstream rate a queue size table can be stored in the NT1. For
example an ADSL based access gateway could reconfigure the queue sizes automatically
after each re-training. Without any configuration the AGW could automatically adapt to
changing line rates and still fully support the four traffic classes!
24/70
Project Deliverable
IST - 6th FP
Contract N 507295
The 802.1P VLAN frame is needed by the NT1 as traffic class identifier. The P-bits in the
VLAN are used for this purpose. The VLAN ID is transparent for the NT1. In upstream direction the (optional) Segmentation & Segment Scheduling unit interprets the P-bits to assign
incoming packets to queues. In addition to the four traffic class queues a dummy queue is
provided to discard packets of certain P-bit combinations. For example 111 is used for control traffic which should not leave the home LAN. Mapping of P-bits to queues is programmable, but default values are given (see Table 1).
Note that packet format is always identical in upstream and downstream direction.
Rate adaptation is needed in the NT1. For example in case of ADSL packets in upstream
direction enter the NT1 with 10 or 100Mb/s, but leave the NT1 at the WAN side with about
1Mb/s. This discrepancy may lead to packet loss, but with the MUSE QoS concept only
packets of Best Effort type are lost. As long as the line rate does not fall below a minimum
value packets of higher traffic classes are not dropped. The minimum line rate is configured
by the NAP. It is assumed that the NAP will analyse an access line and introduce some
safety margin before deciding on the minimum rate.
In case the line rate falls below the minimum rate an error message must be issued to the
NAP and also to the customer network. An intelligent Residential Gateway could intercept
the error message to find out which application will be affected. Individual error messages
could then be forwarded to selected terminals.
Another error message must be issued in case upstream data transmission is not possible at
all. The physical Layer has two possibilities to detect this error. Either the link is not synchronised or in training mode or the far end indicates a reception error (for example Remote Defect Indication RDI).
TC Sub-layer: provides framing required on the physical access link. There are two options,
ATM and PTM mode.
In case of ATM four VCs are used which are terminated on both sides of the access line.
Only over the access line Ethernet packets are encapsulated in ATM as shown in Figure 5.
Ethernet Layer 2 is not terminated at NT1 side nor at the access node side.
25/70
IST - 6th FP
Contract N 507295
Project Deliverable
Ethernet
Access Line
NT1
Ethernet Bridge & GSB functions

Ethernet MAC
Access Node
QoS mapping
QoS mapping
Ethernet MAC
Ethernet MAC
RFC2684
RFC2684
AAL5 SAR
AAL5 SAR
ATM
PHY
Ethernet
ATM
ADSL
PHY
Figure 5: Protocol stack in case of ATM-TC

In case of PTM-TC the Ethernet packets are segmented in 64-byte chunks and a1-byte segmentation overhead is added as described in [5].
Access
NT1
Access Node
Ethernet
Ethernet
QoS mapping
QoS mapping
Ethernet MAC
Ethernet MAC
PTM-TC
PHY
PTM-TC
ADS
PHY
Figure 6: Protocol stack in case of PTM-TC

In case of IPv6 payload the Ethernet frame header and trailer could be removed, as source
and destination MAC addresses are replicated in the IPv6 header. This saves bandwidth
which could be interesting for slow access lines. Figure 7 shows the protocol stack for IPv6
over ATM-TC.
26/70
IST - 6th FP
Contract N 507295
Project Deliverable
Ethernet
Access Line
NT1
Access Node
IPv6
Ethernet
IPv6
QoS mapping
AAL5 SAR
Ethernet MAC
ATM
ADSL
PHY
AAL5 SAR
QoS mapping
ATM
Ethernet MAC
PHY
Figure 7: Protocol stack in case of IPv6 over ATM-TC

Physical Layer (PHY): conversion of the electrical bit stream into line signals and vice versa.
This could be a modem function (xDSL) or Optical/Electrical conversion (FTTH).
2.1.2 Management Plane

The NT1 is managed by the NAP. For the physical layer specific in-band management
mechanisms such as EOC for ADSL are used. For the TC layer the obvious protocol for an
Ethernet based system is ELMI. It can be used also in the case of ATM-TC.
The following table collects the configuration parameters for the NT1.
Parameter
Mandatory/ Optional
Comment
Minimum guaranteed rate

ATM or PTM TC
M
M
Queue size Low Latency queue

Queue size Real Time queue
Queue size Guaranteed Rate
queue
Queue size Best Effort queue
VPI/VCI value for Low Latency
ATM VC
VPI/VCI value for Real Time ATM
VC
VPI/VCI value for Guaranteed
Rate ATM VC
VPI/VCI value for Best Effort ATM
VC
P-bits = 111 action
P-bits = 110 action
P-bits = 101 action
P-bits = 100 action
O
O
O
Configured by NAP
Preconfigured in NT1; default:
ATM-TC
Auto-configured from table
P-bits = 011 action
O
O
O
O
O
O
O
O
O
27/70
Default value is total buffer size

ATM-TC only; default value
1/35 (associate to queue 4)
Discard packet
Select queue=4 (Low Latency)
Select queue=3 (Real Time)
Select queue=2 (Guaranteed
Rate)
Select queue=1 (Best Effort)
IST - 6th FP
Contract N 507295
Project Deliverable
Parameter
Mandatory/ Optional
Comment
P-bits = 010 action

P-bits = 001 action
P-bits = 000 action
O
O
O
Discard packet
Table 1: NT1 Configuration Parameters

The NT1 must issue error messages for errors which can only be detected by the NT1. The
messages can be issued upstream towards the NAP and/or downstream to the customer
network.
Error message
Up-/ Downstream
Line rate falls below minimum

guaranteed rate
Upstream data transmission not
possible
Up / Dn
Dn
Comment
Message toward home network
Table 2: NT1 Error Messages
2.2 Reference point RG

There is a one-to-one connection between NT1 and NT2. The data format is Ethernet with
VLAN tagging.
If the interface to the home network is external, it should be 100BaseT or GbE (using an
802.1P/Q frame in both directions). However, for some reasons it is not recommended to
make this interface external:
A)
VLAN tagged Ethernet frames are not commonly used in home networks
B)
At an external interface a customer can connect a hub or other equipment so that

the one-to-one connection between NT1 and NT2 can not be guaranteed. With
multiple NT2 traffic shaping of the NT2 in upstream direction would be destroyed.
C)
The NT2 shapes the packet stream in upstream direction. In case the access line
rate is (slightly) lower than the shaping rate a backpressure signal is needed.
Over an external Ethernet interface the only means to backpressure are pause
frames. However, this mechanism needs a significant amount of buffer in the
NT1.
2.3 NT2 Functionality

This functional grouping is mainly responsible for Layer 2 forwarding. It is assumed that IP
will be used on top of Ethernet (with one exception). Therefore the NT2 will integrate an IP
lookup function.. In case of IP payload the maximum IP packet size is set to such a value
that always one IP packet is transported in one Ethernet packet. With IPv6 this can be
achieved via the packet size negotiation procedure.
28/70
IST - 6th FP
Contract N 507295
Project Deliverable
The Ethernet Switching block of the NT2 has multiple ports towards the home network and
one port towards the NT1. Ethernet frames can be switched among residential network ports.
Hence the NT2 can be considered as an Ethernet switch with a special NT1 port. This port
does accurate filtering and shaping to the uplink rate of the access line. The NT1 port also
does VLAN tagging.
For optimised shaping the rate of the NT1 port must exactly match the upstream access line
rate. Within a box or component this is easy to realise. With an external interface between
NT1 and NT2 the Ethernet pause frame mechanism could be used (see also issue C" in
Section 2.2). Another option is to set the shaper rate slightly lower than the upstream access
line rate. A message protocol is needed to notify the NT2 about rate changes of the access
line (retraining). At residential ports Ethernet packets without VLAN are assumed.
At the NT1 port the Ethernet frames in both directions are VLAN tagged. According to IEEE
802.1ad [6] a VLAN tag is inserted between Source-MAC and EtherType field. It has 32 bit
with the following structure:
TPID
P-bits
16 bit
3 bit
VID
12 bit
With:
TPID: identifier for VLAN tagged frame. For customer (C-)VLAN its value is fixed to 0x8100.
For service (S-)VLAN the value is to be defined.
P-bits: Priority bits. Indicate the User_priority of a packet.
According to [4] the traffic types in IEEE LANs is defined as follows:
User_priority
Acronym
Traffic Type
BK
Background
Spare
0 (Default)
BE
Best Effort
EE
Excellent Effort
CL
Controlled Load
VI
'Video", < 100 milliseconds latency and jitter
VO
'Voice', < 10 milliseconds latency and jitter
NC
Network Control
C: Canonical Format Indicator CFI, 1 bit.

VID: VLAN ID. If C-VID=0 a frame is priority tagged. Otherwise a frame is denoted as VLANtagged.
The NT2 obtains the VID from an internal table which contains an entry for each service
connection.
Generation of VLAN tag
29/70
Project Deliverable
IST - 6th FP
Contract N 507295
The VLAN tag contains two independent fields with different meanings. The VID indicates the
service, which is related to the destination of a packet. The P-bits indicate the QoS of a
packet. It is assumed that MUSE access network architecture will keep these fields orthogonal. For example two packet streams with the same VID, but different P-bits will both reach
the same destination, but with different QoS. (In the MAC tables of the Ethernet switches in
access and aggregation network only one entry will be needed for both flows. The switch
ports will treat the flows with different priorities.) Therefore the NT2 should generate both
fields independently.
In some access network scenarios the VID is not used, but only the (destination) MAC address (McCircuit). In these cases the NT2 sets the VID to zero. Only the P-bits must be generated.
To obtain the VLAN ID two possible methods are presented here.
2.3.1 NT2 with IP lookup

The NT2 obtains the VID from IP layer information. As IP over Ethernet is the default protocol
stack VID and P-bits can be derived from the IP header. This is possible via the well-known
EtherType values for IPv4 and IPv6.
The NT2 could maintain a list of IP (destination) addresses with associated VIDs. IP addresses which are not in the list could get a default VID of all zero. It is left open how this list
will be established and maintained. It is depending among others on the control plane protocols to be worked out in WPA2/TF1. Some issues are discussed here:
If services are statically configured the list will be permanent. Changes only occur
when the customer subscribes a new service or un-subscribes a service. For each
service connection there will be one entry in the list. In this case entries could be updated via management protocols (e.g. ELMI).
Some connections could be pre-configured, for example an always-on, best effort

Internet connection or a (meta-) signalling connection to a service subscription server.
Via the meta-signalling connection other, service specific signalling connections could
be configured. Another means for pre-configuring the table could be via a smart card
which is inserted into the Access Gateway.
In case service connections are established dynamically on demand the list will be
updated by some signalling protocol (e.g. XML). See Figure 12.
2.3.2 NT2 as Ethernet Bridge

As a further option the NT2 instead of an IP table could maintain a MAC+VLAN table via
learning and aging mechanism. In this case all Ethernet packets with unknown MAC destination address are sent upstream to the access network. The access node accepts only packets which belong to valid connections. Other packets are discarded. The accepted packets
will receive answers after some time, e.g. acknowledge packets. Then the NT2 learns the
MAC addresses of the destinations.
In an Ethernet based (Layer 2) access network the NT2 will learn one MAC address
per edge node.
In case of an IP based (Layer 3) access network the NT2 will learn only the MAC address of the access node.
30/70
IST - 6th FP
Contract N 507295
Project Deliverable
This mode works in case of priority tagged VLAN. It does not need any configuration or signalling, but has the disadvantage that packet streams could occupy the (scarce) upstream
bandwidth which are discarded later at the access node. This is due to the fact that the access node filters packets at IP Layer.
For example a terminal could issue two packet flows to the same edge node, one with Best
Effort and one with Real Time traffic class. Both have the same destination MAC address (of
the edge node) and both are accepted by the NT2. But the access node could discard the
Real Time flow if it is not enabled. Hence this flow produces unwanted load on the uplink. It
is in the responsibility of the customer to avoid such a situation.
P-bits: the P-bits can be generated independently from the VID in case of IP. Both IPv4 and
IPv6 headers have a ToS byte which contains the 6-bit DiffServ code point field. Three selected DSCP values are associated to GSB traffic classes. The values are preconfigured as
shown in Table 3. All other DSCP combinations are associated to the Best Effort class. Each
of the four traffic classes has a fixed pattern of the P-bits associated (see Table 3). For Best
Effort traffic the value is 000.
In case the payload of the Ethernet packet is not IPv4 or IPv6 the P-bits could be obtained
from a MAC table.
TPID: the NT2 uses a pre-configured value to generate the TPID.
CFI:
This bit is always set to 0 when the NT2 generates the VLAN tag.
In downstream direction the VLAN tag is removed at the NT1 port without further action.
Some obvious filtering can be done, for example packets with non-IP payload would be discarded.
L3 Routing block:
This functional block is responsible for Layer 2 termination and Layer 3 routing. In case a
home router is used it is represented by this block. In bridging mode this block does not exist.
Optionally this block may change to another Layer 2 technology, for example from Ethernet
to Bluetooth.
The Routing block does not have any MUSE specific function. An off-the-shelf commercial
home router can be used in case it is implemented as separate physical entity. If it is contained in the residential gateway standard routing functionality according to RFC791 (IP) and
RFC1812 (Router Requirements) is implemented.
L3 Termination block:
IP termination: the L3 address may be changed here and the frames may be routed further
into the home network, or delivered directly to the CPN/ST3.
In case of a home router with NAPT this block contains the NAPT function. In case of a
bridged gateway the L3 termination moves into the terminal.
2.3.3 NT2 Management Plane

It is not yet clear which entity manages the NT2. For a later decision the following table collects the configuration parameters for the NT2.
31/70
IST - 6th FP
Contract N 507295
Project Deliverable
Parameter
Default value
Comment
TPID (identifier for VLAN tagged

frame)
DSCP value for highest priority
(Low Latency)
DSCP value for second priority
(Real Time)
DSCP value for third priority
(Guaranteed Rate)
0x8100 (C-VLAN)
16-bit field
101010
Generated P-bits: 110
101110 (EF)
100010 (AF)
Table 3: NT2 Configuration Parameters

Tbd.
Error message
Up-/ Downstream
Comment
Table 4: NT2 Error Messages
32/70
Project Deliverable
IST - 6th FP
Contract N 507295
3 IMPLEMENTATION OPTIONS
In this chapter the CPE Functional Block model (Figure 3) is checked for consistency by applying it to some special configurations.
Especially important are configurations which consist of different boxes. Unlike a complete
residential gateway in one box such configurations need interfaces which are fully interoperable.
Typically some network operators might install NT-boxes in households which are preconfigured for GSB.
The simplest configuration with a NT box is that only one device is connected to it, an IP
phone. The next obvious configuration is an IP phone and a PC. Usually the PC is connected
via the IP phone (Figure 9). Finally a standard home router may be connected to the NT box.
In the following the CPE functional blocks of Figure 3 are mapped to these applications. It
will turn out that the NT box ideally should contain NT1 and part of NT2.
3.1 NT Box Applications

There are different options of last mile termination. For POTS the termination point is just a
plug. In case of ADSL a passive splitter is added. In case of ISDN an active network termination box is used. There are several arguments for both options.
Arguments for a physical NT Box between access line and residential network:
The NT Box is controlled by the network access provider NAP and may even be owned
by the NAP. For example the NAP will perform loop tests.
For fibre based first mile technologies the physical connection is difficult to establish. A
permanent connection is needed.
De-coupling of first mile technology and home network.
Many terminals such as telephone and PC are either already existing and/ or their functionality can not be influenced by MUSE. It is difficult to add MUSE specific features to
these terminals. This argument is investigated in the following for some important terminals.
A disadvantage of the NT-box is that it is considered as installation material, which means

that its life time is expected in the 10 years range. This is not an interesting business case.
Arguments for an all-integrating Residential Gateway:
Cost saving: todays high integration allows to implement all functions in a few components.
Business case: the routing gateway is considered as a consumer product with short life
cycles
33/70
IST - 6th FP
Contract N 507295
Project Deliverable
3.1.1 PC
The PC is driven by Intel and Microsoft. The interfaces are given, mainly 10/100baseT, USB
and WLAN. The operating system is Windows. It includes TCP/IP and higher protocol stacks.
Modifications at this level are difficult as they are possible via registry only, which can only be
done by experts. At intermediate level for example browser plugins could be distributed for
free for consumers enabling them access to MUSE services. Finally at the application level
new programs can be written or existing programs adapted. However, this can only be expected later, once GSB has had some market success.
One major challenge will be the mediation between the two different worlds. The PC operating system assumes a connectionless world where all servers are permanently accessible.
Conversely the MUSE access network is connection based. One or more connections must
be configured to the respective service providers.
If the user tries to access the Internet when no connection is setup the NT Box could return
an error message such as the DSCP message destination unreachable. Otherwise the PC
would have to wait for a timeout.
As an alternative solution a permanent best effort connection to the Internet could be configured (always-on feature).
3.1.2 Analogue Phone

The analogue phone will be around for many years. Every scenario must be checked for
compatibility with analogue phones. Still many subscribers content themselves with one analogue phone.
Access
NT Box
Analogue
Phone
Line
Figure 8: Minimum Home Network Configuration

On the other hand early adopters of GSB are expected to be technically aware people that
have several phones at home with the capability to do internal calls.
3.1.3 IP Phone
The IP phone is certainly not widely deployed, but it is considered as the phone of the future.
Falling prices on the one hand and added value functions on the other hand will proliferate
the IP phone especially for technically aware subscribers.
A basic scenario will have to be considered where an IP phone and a PC are connected to a
NT box. IP phones usually have two Ethernet RJ-45 pugs, so that this configuration does not
need any extra hub or switch.
34/70
IST - 6th FP
Contract N 507295
Project Deliverable
10/100
PC
baseT
10/100
IP
Phone
baseT
Access
NT Box
Line
Figure 9: Basic Home Network Configuration
3.1.4 Home Router

May ADSL users today have a home router. The main advantages are firewall features and
port multiplication. Many devices in the home can share the first mile via the various ports of
the home router. Todays home routers offer a variety of interfaces, for example mixed wireless and copper based Ethernet interfaces. Other options are WLAN, Bluetooth and USB.
3.2 NT Box Implementation

From the previous section it is clear that the NT Box needs two interfaces at the home network side, a RJ11 plug for the analogue phone and a RJ45 plug for 10/100baseT (self
adjusting).
A proposal for the functional blocks of the NT Box is shown in Figure 10.
RJ11 plug
S
L
I
C
ST3
Conversion
Codec
pack/depack
L3
Term. 1 1
L3 routing
Scheduling
2 1
Filtering
MAC termination
3-port
Ethernet 1 1
Switch
Ethernet
Forwarding & 1 1
Filtering
QoS Scheduling
QoS Tagging
Rate
Adaptation
TC Layer
Phy
Termination
U
10/100
base-T
MAC &
PHY
RJ45 plug
NT-Box
Figure 10: Functional Blocks of NT Box

The upper track in Figure 10 is common until the 3-port Ethernet switch. Packets destined to
the built-in analogue terminal adapter ATA continue the upper track to the ST3 where the
voice packets are converted to voice samples and output via the subscriber line integrated
circuit. The control path (not shown) converts DTMF signalling into SIP. All packets not destined to the analogue phone connected at the RJ11 plug are forwarded by the Ethernet
switch via the (auto-sensing) 10/100baseT MAC & PHY block to the RJ45 Ethernet LAN
plug.
35/70
IST - 6th FP
Contract N 507295
Project Deliverable
4 MANAGEMENT PLANE
4.1 Management Responsibilities
The introduction of several business roles (see Figure 2) brings additional complexity to the
management of the various functional blocks. One example scenario is shown in Figure 11.
Control over the functional blocks is authorised to the respective service providers. The NT1
is controlled by the NAP, for example in case of ADSL via the EOC. The Connectivity Provider CP controls the NT2 via ELMI. It provides the IP address either by itself or from the
Packager. In both cases duplicate IP addresses are avoided. This would be the case if the
ASPs would provide IP addresses independently. The Service Terminations STa...c are controlled by the respective ASP or NSP. As there is transparent IP connectivity some control
protocol over IP will be selected or defined.
Functional blocks normally are not allowed to read out relevant data from other blocks. However, some exceptions could be defined. For example the NT2 could be allowed to access
part of the management data base of NT1. In order to adjust the upstream schedulers the
NT2 must be allowed to access the upstream rate of NT1. Other possible parameters such
as bit error rate etc. will be decided on a case by case basis. These Layer 1 management
parameters will be defined in a data format which is independent on the type of first mile
technology.
The whole management issue needs to be worked out further.
STa
L3+ protocol
ASP/NSPa
STb
L3+ protocol
ASP/NSPb
STc
L3+ protocol
ASP/NSPc
NT2
ELMI
CP
EOC
NAP
IP adr.
Packager
Read only
NT1
Figure 11: Tentative Responsibilities for Functional Blocks
36/70
Project Deliverable
IST - 6th FP
Contract N 507295
4.2 Ethernet OAM

Clause 57 of the IEEE 802.3ah-2004 standard defines the Operations, Administration, and
Maintenance (OAM) sub-layer, which provides mechanisms useful for monitoring link operation such as remote fault indication and remote loop-back control. In general, OAM provides
network operators the ability to monitor the health of the network and quickly determine the
location of failing links or fault conditions.
The OAM described in this clause provides data link layer mechanisms that complement applications that may reside in higher layers. OAM information is conveyed in Slow Protocol
frames called OAM Protocol Data Units (OAMPDUs). They contain the appropriate control
and status information used to monitor, test and troubleshoot OAM-enabled links. OAMPDUs
traverse a single link, being passed between peer OAM entities, and as such, are not forwarded by MAC clients (e.g., bridges or switches). OAM does not include functions such as
station management, bandwidth allocation or provisioning functions, which are considered
outside the scope of this standard.
To operate CPE or RG in a mass deployment in a efficient way it is necessary to keep the
operational process as simple as possible. Up to now IEEE802.3ah does not provide sufficient OAM capabilities which are not suitable for mass deployment. Therefore for implementation the following aspects have to be taken into account.
4.2.1 Basics for Operation

In todays DSL networks ATM is widely deployed. There is increasing interest in replacing
ATM with Ethernet at the V-interface. Assuming that the U-interface will keep ATM for the
time being, the inter working between ATM and Ethernet to preserve existing operational
functionality is essential.
When considering OAM functions, Connectivity Check (achieved by Loop Back mechanisms)
seems to be the most useful functionality. Sending AIS - and RDI cells per subscriber have
less utility because in most cases performance of the BRAS set certain limits in processing
simultaneous AIS/RDI per PVC, and failure of a link between a BRAS and an intervening
switch may result in a large number of AIS/RDI sources. Use of Loop Back on-demand originated from the BRAS permits the BRAS to self regulate the OAM processing load directly.
Alternatively Continuity Check can be applied for business customers, but should not be applied to mass market scenario because of performance impacts on network elements processing CC cells. CC is a unidirectional OAM flow that would add complexity to CPE configuration.
So OAM Connectivity Check via Loop Back operations is considered to be the preferred
OAM mechanism in the following chapters.
To define the inter working, it is important to recognize the differences between ATM and
Ethernet with respect to customer identification and CPE aspects.
4.2.2 Basic requirements for OAM

DSL access is commonly used as a virtual leased line connection between CPE and BRAS.
Most of existing trouble tickets are related to CPE problems, so L2 OAM is primarily required
to check the DSL line is working correctly. In order to do this, the following basic requirements are to be met:
37/70
Project Deliverable
IST - 6th FP
Contract N 507295
1.
End to end visibility on L2 between BRAS and CPE (with or without a PPP or DHCP
session being established)
2.
Unique point to point connection between CPE and BRAS within layer 2 for addressing
customer connection(s)
3.
Use of a default Loop Back ID when addressing the connection endpoint at the CPE,
combined with connection ID which assigns the virtual connection between CPE and
BRAS. This provides a unique addressing scheme for DSL connections between CPE
and BRAS
(Administering the CPEs MAC addresses is to complex for operation in a mass market
environment due to the fact that various CPEs could be connected to the open Uinterface)
4.2.3 Customer Identification

Corresponding with chapter 1.2 and 1.3 of contribution DSLForum2004.071 the different addressing approaches are summarized briefly.
2.3.1
ATM based approach
DSL lines are identified in an ATM based network by a one to one mapping between DSL
line and ATM VPI/VCI between BRAS and DSLAM (single VCC model).
Basically in the static ATM approach each customer connection is described similar to a
leased line scenario with four parameters, BRAS ID, physical port ID, ATM VP and VC. The
virtual path identifier consists of 8 to 12 bits and addresses a virtual path which contains several virtual circuits which identify specific customer connection. The VC addresses must not
be unique at all (only per VP) because they are relevant for the point to point connection
only.
2.3.2
Ethernet based approach
Characteristic in an Ethernet environment is the unique MAC address which functions as a

globally unique interface name. That means, each Ethernet enabled network element is
uniquely addressable (although Ethernet MAC addresses cannot be aggregated).
The MAC address field is split into a source and destination address field. For switching on
layer 2 it is absolutely necessary, that each Ethernet switching element needs either static or
dynamically assigned information in a table about the Clients and their MAC addresses. In
the static case it is very complex to operate that scenario and very labour intensive due to
additions, moves and changes. Therefore the dynamic solution using MAC learning is absolutely necessary (it is not ARP but 802.1D like source learning). But in the same way the security mechanism has to provide separation between different groups by filtering, which is
part of VLAN.
MAC based customer identification may see more than one MAC address associated with a
DSL loop due to bridging function in the RG. Alternatively many RGs terminate the
Ethernet/PPPoE layer and perform NAT functionality limiting the number of MAC addresses
visible on the DSL loop to one.
38/70
IST - 6th FP
Contract N 507295
Project Deliverable
IEEE specifies an OAM sub layer as an option. This addressing scheme requires also a
unique loop back address per loop back end point.
Conclusion
Identifying DSL lines by ATM provides full control by the operator, whereas using CPE MAC
addresses to do so (in order to trigger an OAM request like a Loop Back test) is expected to
be much more complicated.
4.2.4 CPE aspects

CPE includes DSL related XTU-R function as well as layer 2 and optional layer 3 functionality. Dominant are CPE with layer 1 and 2 termination. But in principle the control of the CPE
functionalities is dependent on the network operators business model. Some operators provide a CPE to the customer within the contract and manage the CPE like a network termination up to layer 2. Some operators define the U-interface without the splitter device as customer interface and some operators include the splitter device and call the customer interface U-R2.
But all in common is the fact that the CPE can be operated in two modes:
-
Layer1 and Layer2 managed by network operator Network Termination (NT) approach
Layer2 unmanaged; Layer1 managed by network operator only
If an operator needs to identify the CPE by a unique address he needs to get the information
about the CPE.
ATM and Ethernet use different forwarding paradigms. ATM uses a label swapping connection oriented forwarding mechanism. ATM loopback assumes a connection and the integrity
of the connection is verified by a successful loopback of the OAM cell inserted into a particular VCC or VPC.
Ethernet uses a destination based forwarding paradigm whereby the destination MAC address needs to be known to verify Ethernet layer connectivity. An Ethernet loopback would
verify integrity via successfully getting a response from a message directed towards a specific MAC address. The provider does not administer customer MAC addresses, therefore
mechanisms would be required to learn or discover this information (and track corresponding changes).
ATM default Loop Back ID provides the ability to check DSL access end-to-end via layer 2
between BRAS and CPE based on a virtual connection scheme (VPI/VCI value). This can be
performed without requiring a specific CPE addressing scheme, which greatly simplifies operation for the network operator.
39/70
Project Deliverable
IST - 6th FP
Contract N 507295
4.3 Generic Layer 1 Management Data Base

This section describes a generic data base for all physical layer parameters. Examples:
Layer 3 parameters
o
o
o
IPv6 address prefix

IPv4 address
Etc.
For each parameter the read/write access rights are defined:
All parameters are accessible by the operator

Parameters generated locally, such as error statistics, cell count etc.
Parameters configured by the network operator.
Parameters readable by the user, e.g. the available up- downstream rate.
Parameters to be modified by the user?
Functions located in the Router Gateway block can use user accessible parameters to control the functionality of the NT1.
40/70
IST - 6th FP
Contract N 507295
Project Deliverable
5 CONTROL PLANE
For the control plane 4 service models are proposed in WPA2 (see TF1 document [3] or the
public overview presentation [7]). All of them follow the generic approach outlined in Figure
12. The terminal originates a request for a QoS flow via application layer signalling (e.g. SIP,
H.323). A mediator translates it into network layer signalling which is network technology dependent. At the end of the setup process the terminal is informed via application layer signalling. It is assumed that the home gateway is also informed about the successful connection
setup process. For this last step there are two options:
A) The home gateway intercepts the application layer signalling acknowledge message
B) The home gateway receives a separate network layer signalling acknowledge message (e.g. XML).
Application layer signalling
Mediator
Network layer signalling
Network
Control
Home Gateway
Terminal
Option B
Option A
Figure 12: Service Connection set-up Signalling
Further work on control plane issues for home gateway is depending on the selected service
model.
41/70
Project Deliverable
IST - 6th FP
Contract N 507295
6 APPENDIX
6.1 Home network technologies: USB
6.1.1 Overview
The Universal Serial Bus (USB) is an interface standard for interconnecting peripheral devices to a computer. Up to 127 devices can be connected to a single USB bus. USB allows
hot plug/unplug of devices.
2 versions of USB standard are available:
USB 1.1
USB 2.0 (Hi-Speed USB)
USB 2.0 is fully compatible with USB 1.1 and uses the same cables and connectors.
USB supports 4 modes of operation for transferring data:
Control transfers are typically used for command and status operations. They are essential
to set up a USB device with all enumeration functions being performed using control
transfers. They are typically bursty, random packets, which are initiated by the host and
use best effort delivery. The packet length of control transfers in low speed devices must
be 8 bytes, high speed devices allow a packet size of 8, 16, 32 or 64 bytes and full speed
devices must have a packet size of 64 bytes
Interrupt transfers are typically non-periodic, small device "initiated" communication requiring bounded latency. An Interrupt request is queued by the device until the host polls the
USB device asking for data.
The maximum size of data payload size is 8 bytes for low-speed devices, 64 bytes for
full-speed devices and 1024 bytes for high-speed devices
Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream. If there were a delay or retry of data
in an audio stream, then you would expect some erratic audio containing glitches. The
beat may no longer be in sync. However if a packet or frame was dropped every now and
again, it is less likely to be noticed by the listener.
The maximum size of data payload can be up to 1024 bytes for USB 2.0 (1023 for USB
1.1)
Bulk transfers can be used for large bursty data. Such examples could include a print-job
sent to a printer or an image generated from a scanner. Bulk transfers provide error correction in the form of a CRC16 field on the data payload and error detection/retransmission mechanisms ensuring data is transmitted and received without error.
42/70
Project Deliverable
IST - 6th FP
Contract N 507295
Bulk transfers will use spare un-allocated bandwidth on the bus after all other transactions have been allocated. If the bus is busy with isochronous and/or interrupt then bulk
data may slowly trickle over the bus. As a result Bulk transfers should only be used for
time insensitive communication as there is no guarantee of latency.
Bulk transfers are only supported by full-speed and high-speed devices. For full speed
endpoints, the maximum bulk packet size is either 8, 16, 32 or 64 bytes long. For highspeed endpoints, the maximum packet size can be up to 512 bytes long. If the data payload falls short of the maximum packet size, it doesn't need to be padded with zeros. A
bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size of transferred a zerolength packet.
6.1.2 Bandwidth
USB bandwidth is 12Mbits/s in its 1.1 version and reaches up to 480Mbits/s with version 2.0.
Note the USB 1.1 also supports a low speed mode of 1.5Mbits/s
USB 2.0 extends significantly speed of connections over USB 1.1 capabilities. It is more
adapted to new applications such as digital imaging and allows connection of higher speed
devices.
6.1.3 Distance information (meters)

The maximum length of a USB cables is 5 meters. Cascading up to 5 USB hubs can enlarge
distance to 30m.
6.1.4 Latency
Latency can be guaranteed using isochronous transfers only. There is no way to have guaranteed latency when using Bulk transfers.
Isochronous transfers enable pre-negotiated delivery latency.
6.1.5 Layer 2 QoS

Latency can be guaranteed using isochronous transfers only. There is no way to have guaranteed latency when using Bulk transfers.
Isochronous transfers enable pre-allocation of bandwidth.
6.1.6 Limitations
As already exposed above, USB is limited by the reduced distance between devices (30m).
The latency, even in isochronous mode, might affect traffic for time sensitive applications
such as audio or video.
43/70
IST - 6th FP
Contract N 507295
Project Deliverable
6.2 Home network technologies: Bluetooth

6.2.1 Core architecture overview
Like 802.11, Bluetooth operates in the 2.4 GHz ISM band. The Bluetooth core system consists of an RF transceiver, a baseband providing low-level link routines and a protocol stack.
The architecture is illustrated in Figure 13.
Synchronous
unframed traffic
Asynchronous and
isosynchronuous framed
data control
data
control
control
data
L2CAP
Resource
Manager
L2CAP
layer
Channel
Manager
L2CAP
Device
control
services
HCI
Bluetooth controller
Link Manager
layer
Device
Manager
Baseband
layer
Link
Manager
LMP
Baseband resource Manager
LC
Link Controller
Radio
layer
RF
Radio
Figure 13: Bluetooth core system architecture

In a typical configuration, a Bluetooth controller is provided as a separate chip. A Bluetooth
host provides the upper and intermediate layers of the Bluetooth software stack and interfaces to the Bluetooth controller with the HCI interface. The HCI commands are transported
by the Host Controller Transport Layer, which is frequently implemented by a USB or a highspeed serial link. The main goal of this transport layer is transparency. The transport layer
shouldn't require any visibility in the data that the Host Controller driver passes to the controller. This allows the HCI or the controller to be upgraded without affecting the transport layer.
44/70
IST - 6th FP
Contract N 507295
Project Deliverable
L2CAP
Channel
Unicast
Logical
Links
Control
(LMP)
Logical
Transport
ACL
User
(L2CAP)
SCO
Physical
Links
Active
Physical link
Physical
Channel
Inquiry scan
channel
Page scan
channel
Broadcast
Basic
piconet
ESCO
Stream
ASB
PSB
Parked
Physical link
Adapted
piconet channel
Figure 14: Bluetooth transport architecture

Figure 14 shows the different layers in the Bluetooth transport architecture. At the bottom,
several types of physical channels are defined. The inquiry scan channel is used for discovering devices (and being discovered) and the page scan channel is used to connect to a discovered device (and being connected to). Once a connection is established, the basic or
adapted piconet channels are used for frequency hopping based communication during normal operation. The adapted piconet channel was introduced in the Bluetooth core specification v1.2 and includes the use of adaptive frequency hopping (AFH): with AFH a number of
the hop frequencies may be excluded from the hopping pattern by being marked as bad. This
mechanism was developed to improve the performance in the presence of an interfering
source such as an 802.11b/g network.
A Bluetooth piconet is based on a master-slave architecture. There can be up to 7 active
slaves in a piconet. If a slave does not need to participate in receiving or transmitting of data,
but needs to remain active in the piconet, it can be placed in parked mode. The parked slave
broadcast (PSB) logical transport is used to allow communications to parked slaves. A
parked slave may use the inactive periods of the PSB to save power, or it may carry out activities in other physical channels unrelated to the piconet within which it is parked.
Unicast framed data is transported through the Asynchronous Connection-oriented Logical
transport (ACL), while streamed unframed data is transported through the Synchronous
Connection-Oriented logical transport (SCO) or extended SCO (eSCO). The ACL transport
incorporates retransmission (ARQ) to ensure reliable delivery of data. The eSCO logical
transport was introduced in the Bluetooth core specification v1.2 and also allows for a limited
retransmission of voice packets that were corrupted.
45/70
IST - 6th FP
Contract N 507295
Project Deliverable
The logical link control and adaptation protocol (L2CAP) supports higher-level protocol multiplexing, packet segmentation and reassembly, flow control, error control and the conveying
of quality of service information. This protocol is not used for unframed streaming data such
as voice.
6.2.2 Modulation and Bandwidth

RF operation uses a shaped, binary FM modulation with frequency hopping. The hopping
frequency is 1600 hops per second (1 time slot = 625 s).
The symbol rate is 1 Megasymbol per second (Ms/s) resulting in an asymmetric maximum
data rate of approximately 723 Kbit/s. Table 5 lists the maximal bandwidths for several configurations.
Transport
Traffic symmetry
asymmetric
ACL
symmetric
SCO
duplex voice
Transmit
Receive
732.2 Kb/s
57.6 Kb/s
57.6 Kb/s
732.2 Kb/s
433.9 Kb/s
433.9 Kb/s
64 Kb/s (x3 channels)
Table 5: Bluetooth maximal bandwidth specifications

The actual speed may be lower due to transmission errors and also depends on the packet
types that are being used on the links.
6.2.3 Distance information

Each Bluetooth device is classified in one of three power classes:
Class 1: for long range (~100m) devices, with a max output power of 20 dBm
Class 2: for medium range (~10m) devices, with a max output power of 4 dBm
Class 3: for short range (~1m) devices, with a max output power of 0 dBm
The actual ranges can vary from the indicated ranges since they depend on a lot of environmental parameters, but they give a realistic indication. Class 1 is for devices that require a
long range to be useful, such as cordless Bluetooth phones. Class 2 devices are the most
common devices, with typical applications being headsets, PDAs and many others. Class 3
can be used for devices that remain close to a personal computer, such as wireless mice and
keyboards.
6.2.4 Latency and QoS

The LM and L2CAP layer (Figure 13) provide configurable QoS capabilities. Because the
quality of the underlying radio link can never be guaranteed, in practice all that Bluetooth
technology can do is to make an attempt to support the QoS it has guaranteed.
46/70
IST - 6th FP
Contract N 507295
Project Deliverable
An ACL link uses a retransmission scheme based on a CRC check to send data. An acknowledgement bit is provided in each packet header. Since 1 time slot is 625 s, and a
slave is allowed to transmit in the time slot after it has received a packet, the delay before
receiving an acknowledgement may be small. But as the quality of the link goes down, this
delay will increase and may become too large due to the high number of retransmissions. In
order to support isochronous data on a link with variable delay, the old undelivered data can
be flushed and the link controller is forced to take the next data instead.
A poll interval, that is defined as the maximum time between transmissions from the master
to a particular slave on the ACL logical transport, is used to support bandwidth allocation and
latency control.
These parameters managed at the LM-level are reflected in some of the QoS parameters
available at the L2CAP level. The QoS parameters available at the L2CAP level are:
Token Rate
Token Bucket Size (limit burstiness of data)
Peak bandwidth
Access Latency (delay of an L2CAP packet to the air-interface)
Delay Variation
In addition, Bluetooth provides a 64Kb/s synchronous SCO link that is used to carry audio
data. An SCO link reserves time slots in the hopping pattern so that the bandwidth is guaranteed.
6.2.5 Bluetooth profiles

In addition to the core architecture specification, the Bluetooth SIG provides specifications of
several protocols above the L2CAP layer. Examples of such protocols are the Telephony
Control Specification Protocol (TCS.BIN) for call control and the Bluetooth Network Encapsulation Protocol (BNEP) for Ethernet packet encapsulation.
Bluetooth profiles are documents that define the features, protocols and scenarios that are
required for interoperability between two Bluetooth units in a given use case. As an example,
the Cordless Telephony Profile requires that the TCS.BIN protocol is used for call control and
defines the mandatory and optional behaviour for a CTP-terminal (e.g. Bluetooth Phone) and
a CTP-gateway (e.g. residential gateway). Figure 15 illustrates the hierarchical organization
of some common profiles in relation to the Bluetooth core and the upper layer protocols.
6.2.6 Limitations
Interference. Interference of other devices in the ISM band can strongly reduce the
link quality. A problem case is for example a gateway that needs support an SCO
channel over Bluetooth and also acts as an 802.11b/g access point. Collaboration
mechanisms are absolutely necessary, but do not guarantee a transparent coexistence of both technologies. This topic is further described in more detail in the
DB3.1 Part II: Access Gateway document.
47/70
IST - 6th FP
Contract N 507295
Project Deliverable
Bandwidth. The current maximal speed of 723 Kb/s is low in comparison to for example the 802.11g standard. Within a piconet, the master is the bottleneck for all traffic.
User interaction. To connect to a device, a user has typically to go through the following steps: discovery of devices, select device to connect to, select service to connect to, enter PIN code and get authorized. Effort is needed to make this whole process user-friendly and to avoid that the user needs too much knowledge of the inner
workings of the Bluetooth technology.
File
Transfer
Serial
Port
Dial-up
FAX
Cordless
Telephony
Intercom
Object
Push
Synchroniza
tion
Generic Object
Exchange Profile
IP Network
access
Profiles
Protocols
RFCOMM
(Serial)
Telephony Control
(TCS.BIN)
Object
Exchange Protocol
BNEP
L2CAP
Figure 15: Relation between upper stack protocols and most common profiles
6.3 Home network technologies: WLAN

6.3.1 Overview
The basic operation of the 802.11 MAC is referred to in the standard as CSMA/CA (Carrier
Sense Multiple Access/Collision Avoidance). The primary reason for the distinction over
CSMA/CD is that, due to the very large variation in signal power between transmitter and receiver, and also due to the need for cost-effective transceivers to operate in a half-duplex
mode, it is not practical for a wireless terminal to monitor the medium for a possible collision
whilst transmitting. A detailed description of the WLAN MAC operation can be found in the
appropriate standards
Wireless LAN is available in a number of variants: 802.11, 802.11b, 802.11a, 802.11g.
Characteristics
802.11b
802.11g
802.11a
Max. Speed
11 Mbps
54 Mbps
54 Mbps
Modulation
CCK
OFDM & CCK
OFDM
Frequencies
2.4 2.497 Ghz 2.4 2.497 Ghz
48/70
5 Ghz band
Project Deliverable
IST - 6th FP
Contract N 507295
Table 6: WLAN Standards
6.3.2 Protocol suite

6.3.2.1
802.11
The original 802.11 standard specified three different physical layer solutions; a Direct Sequence Spread Spectrum scheme and a Frequency Hopping Spread Spectrum scheme
both providing 1 or 2 Mbps throughput in the 2.4 GHz ISM band - and a third scheme for Infrared based systems. Of these the DSSS scheme has had the most commercial success.
6.3.2.2
802.11b
The 11b annex to the base standard was published in 1999 providing 5.5 and 11 Mbps data
rates using a spread spectrum technique called Complementary Code Keying. The attainment of >10Mbps transmission rates was the trigger which ignited adoption of the technology.
6.3.2.3
802.11a
The 11a annex to the base standard was also published in 1999 but has taken rather longer
to translate to significant adoption in the marketplace. This annex provides a physical layer
solution based on OFDM modulation for the U-NII bands between 5.15 and 5.825 GHz. The
available data rates are 6, 9, 12, 18, 24, 36, 48, and 54 Mbps.
6.3.2.4
802.11g
The 802.11g annex is expected to be officially ratified during 2004. Products based on the
final drafts are however already available. 802.11g provides a higher rate extension of the
existing 11b rates in the 2.4GHz band. Typical implementations make use of the OFDM
modulation applied in the 11a standard to provide rates of 6, 9, 12, 18, 24, 36, 48, and 54
Mbps in addition to the 11b rates. The standard provides for an alternative solution based on
PBCC modulation.
6.3.3 Available Bandwidth

An 802.11 terminal may choose to transmit at any of the physical layer data rates supported
in the current Basic Service Set (BSS). The algorithm by which it makes this decision is not
specified and is left to the designers of each device.
Since the MAC specification includes a number of elements of fixed length (interframe
spaces, backoff slots, physical layer header information) the efficiency of the protocol (in
terms of the maximum potential user data throughput) varies with both the physical data rate
used and the number of user bytes in the frame.
For short packets (<100 bytes) the efficiency of the protocol reduces dramatically.
49/70
IST - 6th FP
Contract N 507295
Project Deliverable
Throughput [Mbit/s]
Throughput for different Packet lengths

50
45
40
35
30
25
20
15
10
5
0
6 Mbit/sec
9 Mbit/sec
12 Mbit/sec
18 Mbit/sec
24 Mbit/sec
36 Mbit/sec
48 Mbit/sec
54 Mbit/sec
0
1000
2000
3000
4000
Packet Length in Bytes
Figure 16: WLAN Throughput

Achievable range in an 802.11 network is not an easy thing to specify. There are of course
an enormous number of factors which influence the range of operation in practice. Multipath
propagation, leading to spatial and frequency selective fading and inter-symbol interference,
signal absorption between the receiver and transmitter and the possible presence of interferers in the unlicensed band (from Bluetooth handsets to microwave ovens) all contribute variables to the picture. Furthermore, because 802.11 allows for a frame length of considerably
variable length, the achieved Packet Error Rate depends not only on the signal to noise
available at the receiver and the chosen transmission rate but also is strongly dependent on
the length of packets to be transported.
50/70
IST - 6th FP
Contract N 507295
Project Deliverable
10
10
Lower
Modulation
Rate
Shorter
Packets
10
-1
10
-1
PER
PER
10
-2
10
mode3
-2
mode4
256 Bytes Packet

54 Bytes Packet
16 Bytes Packet
10
mode6
mode7
mode8
-3
10
15
Eb/No
20
25
10
-3
10
12
14
16
18
20
22
24
26
28
30
Eb/No
Figure 17: Packet Error Rate vs. Signal to Noise
6.3.4 Latency
As the discussion of the 802.11 MAC access mechanism should make clear, predicting latency in an 802.11 system is not possible, since it is entirely dependent on randomised contention with an unknown and uncontrolled set of terminals. The original standard made provision for a Point Coordination Function which could provide for guaranteed access to the medium under AP control. This functionality is not required for WiFi certification and has rarely
been implemented. The 802.11e standard, which is work in progress, specifies two basic approaches to achieving QoS in an 802.11 network. The first, Enhanced Distributed Contention
Function (EDCF), enhances the basic 802.11 distributed access mechanism to provide statistically prioritised access to certain traffic classes. The prioritised technique is labelled WME
(Wireless Multimedia Extensions) by the Wifi Alliance. Whilst providing useful discrimination
for delay-sensitive traffic, it is not capable of providing bandwidth or latency guarantees. The
second, Hybrid Coordination Function (HCF), is an enhancement of the Point Coordination
Function (PCF) which is intended to provide a capability to reserve bandwidth for delay sensitive flows. Medium Access based on the HCF is planned to be adopted by the WiFi Alliance
under the title WSM (wireless scheduled multimedia).
6.3.5 Layer 2 QoS mechanism

802.11e provides for two new approaches to offering QoS under the general title of the Hybrid Coordination Function (HCF): the Enhanced Distributed Channel Access Function
(EDCA) and the HCF Controlled Channel Access (HCCA). Both mechanisms coexist with
and are compatible with the legacy DCF functions. The mechanisms employed are described
in more detail below.
51/70
IST - 6th FP
Contract N 507295
Project Deliverable
Figure 18: WLAN QoS Mechanisms

Enhanced Distributed Channel Access (EDCA)
AC
AIFSN
Cw min
Cw max
(def = 31)
(def = 1023)
TXOP Limit
(802.11b)
TXOP Limit
(802.11a/g)
AC_BK
31
1023
AC_BE
31
1023
Legacy
31
1023
AC_VI
15
31
6.016ms
3.008ms
AC_VO
15
3.264ms
1.504ms
23)
Table 7: Defaults values EDCA

EDCA extends the rules for DCF medium access by the definition of four traffic classes (Access Categories): Background (AC_BK), Best Effort (AC_BE), Voice (AC_VO) and Video
(AC_VI).Table 7 shows the default values for the key parameters which provide discrimination between the four classes for medium access at a terminal.
The Cwmin and Cwmax columns give, respectively, the minimum and maximum bounds on
the number of slots which may be used for a random backoff procedure. This is the primary
means of providing discrimination for the higher priority classes of voice and video over any
legacy terminals which may be present in the network.
Additionally the requirement to wait for a fixed DIFS period before commencing a backoff
procedure has been extended. The IFS period required depends on the class of traffic and is
given by the AIFSN number in the third column.
In order to prevent high priority terminals from capturing the medium for excessive periods, a
limit is placed on their maximum continuous occupancy the Transmit opportunity limit
(TxOP).
52/70
Project Deliverable
IST - 6th FP
Contract N 507295
These parameters may be flexibly controlled by the access point, which regularly broadcasts
the current parameter set in broadcast beacons. The intent is that a QoS enabled AP can
use these mechanisms in an adaptive way to maintain QoS guarantees as the network load
changes, but of course the definition of an algorithm to satisfactorily achieve this is not a trivial proposition.
Mapping to
Access Category
(AC)
Transmit Queues
Per queue
channel access
functions with
internal collision
resolution
Figure 19: WLAN QoS Solution

Traffic in an EDCA terminal contends for access to the medium not only with traffic from
other terminals, but also with traffic of other classes pending in the same terminal.
The draft standard provides for an AP to enforce admission control policies for the high priority access classes. Each terminal must then explicitly request permission to send traffic of the
higher access classes by agreeing a TSPEC with the AP for the new flow. The TSPEC contains parameters describing the traffic flow requirements. It is not yet clear whether admission control will be subject to conformance testing for WiFi accreditation.
HCF Controlled Channel Access (HCCA)

HCCA is an extension of many of the concepts present in the legacy PCF definition. The
most important distinctions between the HCCA and the PCF are:
The HCCA frame sequences can occur within the Contention Free Period or the Contention Period (this means that an AP which does not use PCF procedures can flexibly switch between EDCA and HCCA exchanges)
Within a granted TXOP the terminal may transmit multiple frames provided the overall
TXOP is not exceeded
53/70
IST - 6th FP
Contract N 507295
Project Deliverable
New frame exchange sequences allow for more efficient frame acknowledgement
strategies
Like the legacy PCF, the HCF has privileged access to the medium because it is permitted to
transmit after a shorter IFS than any (E)DCF terminal. Under control of the HCF (a Controlled
Access Phase CAP), a sequence of frame exchanges can be maintained, with SIFS delays
between frames. HCCA supports parameterized QoS, where specific QoS flows from applications can request scheduled TXOPS and tighter control of latency and scheduling.
Figure 20: WLAN Framing

HCCA defines new QoS frame types that allow the HCF to send any combination of data,
poll, and acknowledgement to a station in a single frame. When the HCF sends a poll to a
terminal, the QoS control field contains a TXOP limit value that specifies the duration of the
granted TXOP.
The HCF is responsible for controlling the allocation of time on the medium through the use
of polled TXOPs. It is guided in its decisions on TXOP allocation through the use of TSPECs.
TSPECs are requested by the terminal, and the AP may grant or deny a TSPEC request.
6.4 GSB Traffic Classes over slow Access Lines

This appendix studies the impact of 1st mile technologies on end-to-end QoS, in particular
bandwidth and delay issues. The effect of bit errors is not considered in this section; this issue is for further study.
54/70
IST - 6th FP
Contract N 507295
Project Deliverable
6.4.1 Packet multiplexing

The scenario considered first is shown in Figure 21. It shows the traffic model of the home
network in upstream direction. The home network is represented as a multiplexer which collects packets from many independent sources (terminals) and delivers them with high rate to
the home gateway where the access line is connected. Slow access lines are considered
here. Slow in this context means in comparison with the uplink line speed of the home network which is expected 100Mb/s with tendency to grow towards 1Gb/s in future. Hence the
term slow is justified up to 10Mb/s or even beyond.
In case of a slow access line the major queuing point is the output port of the access node
towards the xDSL line. The home network works at 100Mb/s or Gigabit speeds which means
that the packets are almost instantaneously forwarded to the uplink output port of the home
gateway. The terminals are independent data sources. In case of PCs each of them can
generate several packet streams, for example video, voice and control flow. These flows are
uncorrelated among different terminals and packets may arrive any time at the output port.
Terminal 1
Terminal 2
FE
FE
FE
First
HGW
Terminal N
Mile
CO
FE
N independent Sources
Home network
FE = Fast Ethernet (100Mb/s)
Figure 21: Upstream traffic model
The output port must have some buffering, as packets from different, independent sources
can arrive simultaneously, even if the sum of average rates of each source fits into the upstream bandwidth of the access line. Packet bursts must be stored temporarily in an output
port specific buffer.
6.4.2 QoS class support

With the introduction of QoS it is obvious that some means of QoS support must be built into
the home gateway.
QoS classes are differentiated by delay and error tolerance. While error tolerance obviously
is related to packet loss, the relation between delay and packet jitter needs some explanation. The interesting quantity end-to-end delay is composed of several parts:
55/70
IST - 6th FP
Contract N 507295
Project Deliverable
the transmission delay over the transmission links (including eventual interleave delays over xDSL; it is also referenced as propagation delay with 5s/km),
the processing delay in the nodes (typically below 1ms),
the jitter, which is due to statistical packet queuing and
the de-jitter buffer in the terminal. It is set to the maximum value of the jitter.
As transmission delay and node processing delay are fixed the only means to reduce the
end-to-end delay is to minimise the jitter.
The usual method for QoS support is to separate packet flows according to their QoS class
and store them in different queues as shown in Figure 22. These queues are served by a
multiplexer that prioritises queues with low jitter packet streams.
Current target of MUSE is to align with 3GPP and ITU-T QoS classes. Both have 4 delay priorities. Hence 4 queues are implemented in the downstream port Buffer (Figure 22). The two
loss priorities in both standards translate into queue dimensioning. MUSE strategy is to offer
only low packet loss service, even for loss tolerant applications.
Buffer
1
First
High
Mile
Prio
FE
Serving
3
Prio
Low
4
Prio
Flow
Packet
Detection
Queues 1..4
Priority
Multiplexer
Figure 22: Output port traffic model

With such a separation of traffic and queue serving by strict priority multiplexer 3 mechanisms contribute to the overall jitter:
A) Within each queue jitter occurs by multiplexing packets of same priority but from different independent sources
B) Queues of lower priority have to wait for queues of higher priority
C) A queue of higher priority has to wait for completion of a pending transmission from a
queue with lower priority.
56/70
IST - 6th FP
Contract N 507295
Project Deliverable
The last mechanism is particularly problematic for low rate transmission lines. Assume for
example that the transmission of a maximum size packet of 1500 bytes has just started when
a high priority packet enters an empty queue. In case of a 1Mb/s ADSL upstream link the
long packet needs 12 ms for transmission. To reduce this time there are pre-emption
mechanisms such as:
Use of different ATM VCs: the waiting time reduces to the transmission time for the
first cell (53byt segment), which is 0.42ms for 1Mb/s.
Use of PTM-TC with pre-emption option according to G.992.3 Annex K.4: waiting time
reduces to one 65byte segment which is 0.52ms.
Abort of the long frame and immediate insertion of the high priority packet: this
method leads to frequent packet losses of the low priority flow. It is not considered
further.
Fragmentation at Layer 3. This method leads to inefficient packet size for bulky data
transmission. It is not considered further.
6.4.3 Jitter calculation for highest priority queue

The figure below shows a scenario with jitter causes A and C, multiplexing packets of the
same priority and pending transmission of lower priority. Jitter cause B, queue precedence, is
investigated later. A maximum size Ethernet packet has been received by a low priority
queue followed by 3 VoIP packets received by a high priority queue.
VoIP
Packets
200byte
Serving
Pre-emption segment
Prio
53/65byte
Max. size Ethernet packet
Priority
1500byte
Multiplexer
Figure 23: Worst case jitter

Note: a VoIP packet is assumed here to fit into four ATM cells or to three 65byte frames.
Hence 200byte is taken as average value. Optimisation of VoIP packet size for both cases
could be useful, especially with regard to IPv6. 200byte might also fit to MPEG2 frames (to
be verified).
57/70
IST - 6th FP
Contract N 507295
Project Deliverable
With Figure 23 calculation methods to obtain the maximum number of flows N and the
queue length are derived. For this purpose the following variables are introduced:
LinkRate .............. link rate in b/s
N .......................... number of independent flows
QueueSize........... queue length of high priority queue
SegmentSize ....... given by segmenting mechanism; 53byte for ATM, 65byte for PTM
TC, 1500byte for Ethernet
PacketSize........... maximum packet size
MaxDelay............. maximum delay a packet experiences in the output port
MinDelay.............. minimum delay a packet experiences in the output port
MaxJitter .............. maximum jitter.
The jitter is defined as the difference between maximum and minimum forwarding delay.
From Figure 8.3 the maximum delay is experienced by the last arriving (blue) packet. It has
to wait for a segment from the low priority queue and three packets to be transmitted, including itself:
MaxDelay = (SegmentSize + N x PacketSize) / LinkRate
If on the other hand all queues were empty the minimum delay is experienced by the packet,
the time to be transmitted itself:
MinDelay = (1 x PacketSize) / LinkRate
The difference between both is the jitter:
MaxJitter = (SegmentSize + (N-1) x PacketSize) / LinkRate.
{1}
From {1} one can see that there is a lower bound for MaxJitter for N=1:
MaxJitter SegmentSize / LinkRate,
which can be resolved for LinkRate:
LinkRate SegmentSize / MaxJitter.
{4}
Equation {4} shows that there is a minimum LinkRate for a certain jitter limit. The lowest jitter
can be achieved with 53-byte ATM cells.
Equation {1} is resolved for N to obtain the maximum number of flows possible for a given
link rate:
N = Integer[ (MaxJitter x LinkRate SegmentSize) / PacketSize + 1]
{1a}
Once N is known the required queue size for the high priority queue according to Figure 8.3
obviously is:
QueueSize = N x PacketSize
{2}
With equations {1a} and {2} the queue length and the maximum number of allowed flows can
be calculated. However, for large values of N this deterministic view can be completed by a
statistical one.
58/70
IST - 6th FP
Contract N 507295
Project Deliverable
For values of N beyond 10 it is more and more unlikely that a large number of independent
sources send packets simultaneously. For a given loss probability the maximum allowed load
of an infinite number of flows (N -> ) can be calculated using the M/D/1 model. Results for
packet loss probability 10-11 and 10-7 are shown in Figure 24 and Figure 25, respectively.
With N -> equation {2} can not be used any more for queue size calculation. Replacing N
by {1a} and neglecting SegmentSize and the +1 term leads to
QueueSize = MaxJitter x LinkRate
{3}
Assume for example N=20 is the result of {1a} with a given set of parameters. The deterministic view says that 20 independent flows can share the queue with zero loss probability,
provided that their load sum is <100%. The statistical view according to Figure 24 says that
an infinite number of flows can share the queue with up to ca. 52% load sum for a loss probability of 10-11. The statistical view is usable for links with high rate, used for node interconnection. The number of flows allowed on these links must not be controlled by admission,
just the total rate.
1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
1
10
100
1000
probability 10-11
59/70
IST - 6th FP
Contract N 507295
Project Deliverable
1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
1
10
100
1000
probability 10-7
6.4.4 Jitter calculation for lower priority queues

To dimension the second priority queue (queue 2 in Figure 22) formula {1} is not applicable,
as the serving rate of queue 2 is not known. It depends on the serving rate of the higher priority queue, which is not constant.
To solve this problem a pragmatic proposal is to agree on a maximum load allowed for the
highest priority queue (Prio1Load). Then the average serving rate of the second priority
queue is known. If for example the maximum allowed load on the highest priority queue is
10% the serving rate of queue 2 is LinkRate x 0.9.
Also if the jitter target for queue 2 is much less than the jitter target for queue 1 the effect of
queue 1 on the jitter of queue 2 can be neglected. Combining these two assumptions formula
{1a} can be used to calculate number of flows and queue size approximately replacing the
term LinkRate by LinkRate x (1 Prio1Load).
For the next lower priority this principle can be extended analogous by agreeing on a maximum load for the second priority queue (Prio2Load). Then the term LinkRate in equation
{1a} is replaced by LinkRate x (1 Prio1Load Prio2Load).
The validity of these assumptions and simplifications has to be checked (BUTE).
6.4.5 ATM or PTM-TC?

For example a 1Mb/s ADSL downstream link is considered with N=3 independent VoIP
streams with PacketSize=200byte packet size according to Figure 23. The jitter is calculated
using {1} for three cases:
ATM: SegmentSize=53, MaxJitter=3.62ms
PTM-TC with pre-emption: SegmentSize=65, MaxJitter=3.72ms
60/70
IST - 6th FP
Contract N 507295
Project Deliverable
PTM-TC without pre-emption: SegmentSize=1500, MaxJitter=15.2ms.

When extending the scenario of Figure 23 to four QoS classes the PTM-TC case gets more
complicated. For example in the configuration of Figure 22 a packet arrives for queue 4, then
a packet in queue 3, then queue 2 and finally a packet in queue 1. Then the pre-emption
mechanism would have to be invoked 3 times, i.e. 3 nested pre-emption mechanisms! As the
PTM-TC standard will not allow multiple pre-emption only the highest priority traffic can be
allowed to pre-empt other traffic. This has to be investigated further.
As an additional mechanism in case of ADSL two different paths could be used. Then one
path would be dedicated to the most jitter sensitive QoS class and would not be subject to
pending transmission delay from other queues. The other 3 classes would share the other
path. This reduces the number of nested pre-emption mechanisms to 2 for one path only. But
this method has other drawbacks as outlined in the next section.
In case of ATM TC the solution is simply to use 4 VCs, one for each QoS class.
Conclusion: the ATM TC option with one VC per QoS class is recommended for transmission
links up to 12Mb/s.
Therefore in the remaining part of the document only the ATM TC option is considered. Note
that ATM is assumed between NT1 and the access node port only, basically over the access
line.
6.4.6 Pros and cons of multiple ADSL paths

As mentioned above a dedicated ADSL path reduces jitter if only one QoS class uses this
path. Both for ATM or PTM-TC with pre-emption option the jitter reduction is low; hence it
makes sense only for low jitter QoS classes.
A current MUSE target is an inelastic low latency QoS class with a very low end-to-end jitter
(13ms). For this class a dedicated path could make sense. The low latency class is expected to be expensive and hence will be used only temporarily for selected applications, for
example gaming or high quality voice. When no such special application is running the
bandwidth reserved for this path is lost for other applications. Obviously the first disadvantage of the two ADSL paths option is less flexibility and overall lower link usage. Another disadvantage is the lower performance as shown in the following example (Figure 26).
1Mb/s
Case A
ADSL path 1
ADSL path 2
Case B
0.9Mb/s
ADSL path 1
0.1Mb/s
Figure 26: Options for low latency flows
61/70
IST - 6th FP
Contract N 507295
Project Deliverable
Typically the bandwidth reserved for the low jitter path will be low. Hence in this example a
1Mb/s ADSL link is split into one 0.1Mb/s path for one low jitter connection and a second
path with 0.9Mb/s for all the other connections. This solution is compared to one single
1Mb/s path. In both cases the end-to-end transfer time (including de-jitter buffer) of a 200byte
voice packet is considered. In both cases the interleave delay is 8ms. This value is reasonable in case of omnipresent 100Hz noise. With no interleaving at all (fast path) sporadic bit
errors can not be avoided. Hence 8ms seems to be a practical value.
A) Two path solution
In this case the packet has no waiting time for downstream transmission. The transmission of the 200byte over the 0.1Mb/s link, however, lasts 16ms. The jitter from access
and core network is expected to be below 1ms. The de-jitter buffer compensates this jitter
with a 1ms delay.
Resulting end-to-end delay for the high priority path: 16ms+8ms+1ms=25ms.
B) Single path solution
In this case the packet in worst case has to wait for a 53byte ATM cell from a lower priority queue to be transmitted. At 1Mb/s this lasts 0.42ms. Then the voice packet is transmitted over the access line which lasts 1.6ms. The accumulated jitter from access and core
network is less than 1ms.
Resulting end-to-end delay: 0.42ms+1.6ms+8ms+1ms=11ms.
The single path solution B has much lower end-to-end delay. Even if fast mode is used instead of interleave mode the two path solution would be slower (17ms).
Even if the two path solution has two equal paths of 0.5Mb/s the resulting end-to-end delay is
longer than in the single path solution (12.2ms).
Other disadvantages of the two path solution are the performance degradation for all flows
using ADSL path 1, the lower overall link usage and the missing flexibility.
Conclusion: the single path ADSL mode is preferred versus two path mode.
6.4.7 Fulfilling GSB traffic classes

The following GSB traffic classes have been proposed for MUSE. Each flow has to select
one of these classes. For all classes except best effort burst size and average rate are reserved in the network and are policed at the network border. The average rate is specified in
multiples of 100kb/s. Table 8 summarises the parameters.
Traffic class
Max. burst size
Max. jitter target per node
Max. Packet
loss rate per
node
Max. load per

link
Low Latency
200 byte
1 ms
10-10
10%
Real Time
1500 byte
30 ms
10-10
60%
Guaranteed
Rate
9000 byte
900 ms
62/70
10
-10
<100%
IST - 6th FP
Contract N 507295
Project Deliverable
Traffic class
Max. burst size
Max. jitter target per node
Max. Packet
loss rate per
node
Max. load per

link
Best Effort
Table 8: tentative values for GSB traffic classes

All values in the table above are still to be debated, but as a first estimate they are used here
to investigate their feasibility over slow access lines. The rightmost column lists the maximum
allowed load per traffic class, a parameter which is needed to guarantee jitter values for Medium latency and Elastic traffic classes (see Section 6.4.4).
Slight adjustment of the maximum burst size values, for example 1522 instead of 1500 byte
do not influence the calculations significantly. Hence for simplicity the values are not
changed. However, the maximum packet loss rate for real time classes had to be reduced to
10-10 in order to support T1/E1 over packet application. As safety margin the queues are dimensioned for one magnitude lower than specified.
To implement these traffic classes the circuit of Figure 22 is chosen with a strict priority
multiplexer. It always serves high priority queues first and takes packets of a lower priority
queue only if all higher priority queues are empty.
6.4.7.1 Best Effort class

Best effort traffic is assigned to the lowest priority queue. This makes the higher priority traffic
independent from the best effort traffic (except the pending transmission issue). As the
bandwidth of higher traffic class flows is controlled the best effort queue will always be
served at least by a small bandwidth. Starvation of the best effort queue will not occur.
6.4.7.2 Low Latency class

This traffic is assigned to the highest priority queue. The interesting values are the minimum
link rates needed to transport independent packet streams. Resolving equations {1} for LinkRate gives:
LinkRate (SegmentSize + (N-1) x PacketSize) / MaxJitter {1b}
Using {1a}, {1b} and {2} the following values are calculated for MaxJitter=1ns, SegmentSize=53byte and PacketSize=200byte:
No. of flows N
LinkRate [Mb/s]
QueueSize [byte]
Packet loss rate
0.5 LinkRate < 2.0
200
2.0 LinkRate < 3.6
400
3.6 LinkRate < 5.2
600
6.8 LinkRate < 8.4
1 000
10
14.8 LinkRate < 16.4
2 000
50
100 (load <100%)
10 000
Unlimited
100 (load <81%)
12 500
10-11
Table 9: Some key values for a 1ms-class
63/70
IST - 6th FP
Contract N 507295
Project Deliverable
The LinkRate values in Table 2 are rounded to 100kb/s, the proposed rate granularity.
For the 100Mb/s value both the deterministic view with up to 50 flows and the statistic approach according to Figure 24 are listed. For QueueSize calculation in unlimited case formula {3} has been used. With QueueSize expressed in multiples of PacketSize the allowed
load for an unlimited number of flows is looked up in Figure 24.
At implementation it is recommended to limit the queue size to the calculated value and discard whole packets in case of overflow (partial packet discard PPD). This takes into account
that for inelastic QoS classes timing behaviour is more important than data integrity.
6.4.7.3 Real Time class

These flows are stored in the second priority queue. The parameters for this class are
MaxJitter=30ms and PacketSize=1500byte. For ATM SegmentSize=53byte.
Under the assumption that the low latency class is limited to 10% of the link rate (see Section 6.4.4) equation {1a} and {1b} become:
N = Integer[ (30ms x LinkRate x 0.9 53byte) / 1500byte + 1]
LinkRate (53byte + (N-1) x 1500byte) / 30ms / 0.9
{1a}
{1b}
Using these equations and {2} some values have been calculated in Table 10:
No of flows N
LinkRate [Mb/s]
QueueSize [byte]
Packet loss rate
0.1 LinkRate < 0.5
1 500
0.5 LinkRate < 0.9
3 000
0.9 LinkRate < 1.3
4 500
1.3 LinkRate < 1.8
6 000
1.8 LinkRate < 2.2
7 500
21
8.9 LinkRate < 9.3
31 500
226
100 (load<100%)
339 000
Unlimited
100 (load <94%)
337 500
10-11
Table 10: Some key values for a 30ms-class

For the 100Mb/s link rate the difference between deterministic and statistic view is small.
Buffers size calculation in statistic view is based on {3} with LinkRate replaced accordingly:
QueueSize = 30ms x LinkRate x 0.9 {3}
With QueueSize expressed in multiples of PacketSize the allowed load for an unlimited number of flows is looked up in Figure 24.
As for the low latency class the queue lengths are exact values and in case of overflow a
complete packet must be discarded to account for the inelastic class (partial packet discard
PPD).
64/70
IST - 6th FP
Contract N 507295
Project Deliverable
6.4.7.4 Guaranteed Rate class

This class uses the third priority queue with minimum 40% of the link load. The other parameters are PacketSize=9000byte, MaxJitter=900ms, SegmentSize=53byte.
N = Integer[ (900ms x LinkRate x 0.4 53byte) / 9000byte + 1]
{1a}
LinkRate (53byte + (N-1) x 9000byte) / 900ms / 0.4
{1b}
Using these equations and {2} some values have been calculated in Table 11:
No of flows N
LinkRate [Mb/s]
QueueSize [byte]
Packet loss rate
0 LinkRate < 0.2
9 000
0.2 LinkRate < 0.4
18 000
0.4 LinkRate < 0.6
27 000
0.6 LinkRate < 0.8
36 000
0.8 LinkRate < 1.0
45 000
1.0 LinkRate < 1.2
54 000
10
1.8 LinkRate < 2.0
90 000
51
10 (load<100%)
459 000
Unlimited
10 (load<77%)
450 000
10-11
Unlimited
100 (load <97%)
4 500 000
10-11
Table 11: Some key values for a 900ms Guaranteed Rate class
For the 10Mb/s link both deterministic and statistical view are given. In statistic view the
maximum aggregate load is 77% of the 4Mb/s, hence ~3Mb/s. The remaining ~1Mb/s are
available for best effort traffic.
Queue size calculation for the statistic view is analogous to {3}:
QueueSize = 900ms x LinkRate x 0.4
{3}
With QueueSize expressed in multiples of PacketSize the allowed load for an unlimited number of flows is looked up in Figure 24.
Note that the calculated buffer sizes for the Guaranteed Rate class are minimum values and
can be implemented larger with in the aim of data integrity. For example the calculated
queue size could be used as threshold. When the queue fill exceeds this threshold new arriving packets are discarded, but partially received packets are still accepted (early packet discard EPD).
6.4.8 Correlating low jitter flows

For asymmetrical DSL lines such as ADSL or VDSL2 the uplink is much slower than the
downlink. For example it could be the case that the downstream rate allows a certain number
of flows, while the upstream rate does not. By correlating packet flows this disadvantage can
be partially compensated.
65/70
Project Deliverable
IST - 6th FP
Contract N 507295
Up to now independent terminals in the Home Network have been assumed. Flows arriving
at the Home Gateway are uncorrelated.
However, terminals in a household or SOHO usually are located within short distances.
Their packet flows could be synchronised. For example by collecting packets from three IP
phones in a circular manner, for example 1/2/3, 1/2/3, 1/2/3, etc. as shown in Figure 28. The
uncorrelated flow is shown for reference in Figure 27. However, the procedure could lead to
additional delays within the NT2.
Phone 1
Large jitter
ADSL upstream
NT1
N
T
2
Phone 2
Phone 3
Figure 27: Uncorrelated flows
Phone 1
Zero jitter
NT1
ADSL upstream
N
T
2
Phone 2
Phone 3
Figure 28: Correlated flows
66/70
IST - 6th FP
Contract N 507295
Project Deliverable
As another example if three analogue phones are connected to a Home Gateway correlated
upstream packet streams could be achieved by synchronising the packetisation circuits
within the Home Gateway.
The issue of correlating upstream flows should be further explored.
6.4.9 Conclusion
In this section the realisation of the QoS classes of MUSE for access line rates up to 10Mb/s
is studied. An important result is that an appropriate segmentation mechanism is absolutely
necessary to support the desired low jitter values. ATM turns out to be a valuable solution.
PTM TC mode with pre-emption for the highest priority class could be an alternative which
remains to be investigated.
6.5 Layer 1 Example: PON

6.5.1 Interface for Point to Point Ethernet over SM fibre
General Definitions
Transmission mode for Point to Point Ethernet over SM fibre according to the new IEEE
802.3ah-2004 sets of standards developed for the first mile access, including the following
set of standards:
MB/s
KM
fibres
100BASE-LX10
ONU/OLT
100
10
dual
Symmetrical (1310 nm)
100BASE-BX10-D
OLT
100
10
single
Down-link (1550 nm)
100BASE-BX10-U
ONU
100
10
single
Up-link (1310 nm)
1000BASE-LX10
ONU/OLT
1000
10
dual
Symmetrical (1310 nm)
1000BASE-BX10-D
OLT
1000
10
single
Down-link (1490 nm)
1000BASE-BX10-U
ONU
1000
10
single
Up-link (1310 nm)
Table 12: PON Options

As can be see from the table there are, for each transmission speed (e.g. 100 MB/s and 1
GB/s), one standard set for dual fibre transmission and one set for single fibre transmission.
For dual fibre transmission the same transceiver will be used in both direction (1300 nm),
whereas for single fibre transceiver at 1550 nm will be used in the down-link direction and
1300 nm in the up-link direction.
6.5.2 Optical characteristics of the U interface

Wavelength and optical power parameters for the 100 Mbps and 1000 Mbps IEEE802.3
standard. Measured at BER 10-12.
Transmit
Wavelength
Received
Wavelength
67/70
Pout
min
Sensitivity
max
IST - 6th FP
Contract N 507295
Project Deliverable
Wavelength
[nm]
100BASE-LX10
100BASE-BX10-U
1260-1360
1260-1360
1000BASE-LX10
1000BASE-BX10-U
Wavelength
[nm]
1480-1580
1260-1360
1260-1360
1480-1500
min
[dBm]
max
[dBm]
-15
-25
-14
-28,2
-9
-19,5
-9
-19,5
Table 13: PON Optical Parameters
Return loss
Tbd.
6.5.3 Performance requirements

Tbd.
6.5.4 Mechanical properties of U interface

Single or duel fibre interface?
Multiple fibre connector standard available: FC, SC, LC, MT-RJ, MU, .
6.6 Layer 1 Example: SHDSL

6.6.1 General Definitions
Transmission mode "SDSL" according to ETSI TS 101 524.
At the U-RS interface, SDSL signals are provided or expected, as defined in ETSI TS 101
524.
The guidelines cited in the ITU-T recommendations ITU-T G.991.2 and ITU-T G.994.1 have
to be applied where appropriate.
SDSL definitions Physical Layer
Remote Power Feeding is not provided at the U-RS interface.
Four wire mode is optional.
Operation of regenerators between the SDSL modem and the DSLAM is optional.
Support of all data rates with the corresponding granularity according to the used
application specific Transmission Protocol Specific Transmission Convergence (TPSTC) layer is required.
68/70
IST - 6th FP
Contract N 507295
Project Deliverable
Support for a rate adaptive mode using the Power Measurement Modulation
Session PMMS (Line Probe) is required. The support of the current condition target
margin is mandatory, the support of the worst case condition target margin is optional.
The value for the target noise margin (min. required noise margin) has to be
configurable according to ETSI TS 101 524. For the configuration the DSLAM is
the master.
Support of symmetric Power Spectrum Density (PSD) masks according to ETSI

TS 101 524 section 9.4.1 is mandatory. The support of asymmetric PSD according to ETSI TS 101 524 section 9.4.2 is optional. Default configuration is symmetric PSD.
The SDSL embedded operations channel (eoc) shall be supported according to

ETSI TS 101 524.
The support of the optional reduced power mode, the deactivation and the
warm-start is reserved for future use.
The Vendor ID to be exchanged between SDSL modem and DSLAM during

the handshake procedure in the Vendor ID information block of the Identification
field according to ITU-T G.994.1 represents the chipset manufacturer. The vendor
specific information in the Vendor ID information block should not be used as a mean
to achieve interoperability in order to avoid workarounds and to achieve full standard
compliance.
6.6.2 Electrical characteristics of the SHDSL U interface
Unbalance about earth
The Minimum longitudinal conversion loss and the maximum longitudinal component of the
output signal for a SDSL modem shall be according ETSI TS 101 524, chapter 11.3.
Return loss
The minimum return loss of a SDSL modem shall be according to ETSI TS 101 524, chapter
11.2.
6.6.3 Performance requirements

Following the adoption of ETSI TS 101 524, the achieved performance shall conform to the
range requirements for ETSI Noise Model FB, as established by ETSI TS 101 524, table
12.3. The measurements have to be performed as described in ETSI TS 101 524. The performance shall be proofed at least for the test sequence according to ETSI TS 101 524, Table 12.1.
Note: The modems have to meet the performance objectives in an impedance range
of 100 Ohm up to 150 Ohm.
6.6.4 Mechanical properties of SHDSL U interface

At the customer side the U-RS interface is provided at a separate RJ45 socket (UAE).
The pins in the RJ45 socket (designated "DSL") are allocated as follows:
69/70
IST - 6th FP
Contract N 507295
Project Deliverable
Pin
1
2
3
4
5
6
7
8
Allocation
not allocated, reserved for future use: U-RS2 a
not allocated, reserved for future use: U-RS2 b
not allocated
U-RS a
U-RS b
not allocated
not allocated
not allocated
Table 14: U-RS pin allocation
6.6.5 Management of the SHDSL physical layer

The EOC specified in ETSI TS 101 524 is provided as the management channel from the
DSLAM to the SDSL modem. The DSLAM expects all the functions and management information specified conform to ETSI TS 101 524, in conjunction with the EOC from a connected
SDSL modem.
For operation and maintenance purposes the vendor (not chip manufacturer) of the SDSL
modem and the type of the modem needs to be uniquely identified by information via the
STU-R Inventory Request/Response Messages.
Software updates and configuration of the SDSL modem over and above the in ETSI TS 101
524 specified means cannot be carried out via the DSLAM.
Functions at the customer interface must not provide any access to the DSLAM (manipulation or configuration). Furthermore, it must not impair the DSLAM in any way.
70/70

Muse DTF3.1 V09

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Muse DTF3.1 V09

Încărcat de

Drepturi de autor:

Formate disponibile

Project Deliverable

D TF3.1 Subscriber Interface

D TF3.1 Subscriber Interface

Project full title

Multi-Service Access Everywhere

Security (distribution level)

Contractual delivery date

Actual delivery date

Specification of subscriber interface between public network

Status & version

Alun Foster (STM), Harold Balemans, Willem van Willigenburg

Home Gateway, Residential Gateway, Subscriber Interface

Abstract (for dissemination)

Functional description of Routing Gateway starting from DSL

D TF3.1 Subscriber Interface

Comments and actions

Included draft on termination of P2P

Fundamental change of ToC decided in

Contribution from WPB3

Azcorra, Balemans, Garca,

Contribution from WPD3

Editorial, minor comments

Open issues list moved to top and

Inclusion of reference configuration

Consolidated version with all inputs

Comments from Foster; functional

Extension to OAM chapter.

Quality review comments worked in

D TF3.1 Subscriber Interface

CPE FUNCTIONAL BLOCKS........................................................................................................22

IMPLEMENTATION OPTIONS ......................................................................................................33

MANAGEMENT PLANE ................................................................................................................36

D TF3.1 Subscriber Interface

D TF3.1 Subscriber Interface

LIST OF FIGURES AND TABLES

Table 3: NT2 Configuration Parameters ................................................................................32

D TF3.1 Subscriber Interface

Authentication, Authorization & Accounting

ATM Adaptation Layer

Asymmetric Digital Subscriber Line

Application Layer Gateway

ATM Passive Optical Network

Address Resolution Protocol

Application Service Provider

Asynchronous Transfer Mode

Analogue Terminal Adapter

Broadband Access Server

Bit Error Rate

Broadband Network Termination

Broadband Remote Access Server

Call Admission Control

Challenge Handshake Authentication Protocol

Customer Premises Equipment

Customer Premises Network

Cyclic Redundancy Check

Customer Virtual Local Area Network

Coarse Wavelength Division Multiplexing

Dynamic Host Configuration Protocol

Domain Name System

Differentiated Services Code Point

Digital Subscriber Line

Dynamical Spectrum Management

Extensible Authentication Protocol