Muse DTF1.6 V1.0 PDF

IST - 6th FP
Project Deliverable Contract N° 026442
D TF1.6 - Access network architecture III
Antonio J. Elizondo (D TF1.6 editor)

Telefónica I+D
ajea@tid.es
Christophe Alter (TF 1.6 responsible)

France Telecom R&D
christophe.alter@orange-ftgroup.com
Identifier: Deliverable D TF1.6

Class: Report
Version: 1.0
Version Date: 8/11/2006
Distribution: Public
Responsible Partner: TID
Filename: DTF1.6_Access_Architecture_V1.0.doc
D TF1.6 – Access network 1/170 Public

architecture III
IST - 6th FP
DOCUMENT INFORMATION
Project ref. No. IST-6thFP-026442
Project acronym MUSE
Project full title Multi-Service Access Everywhere
Security (distribution level) Public
Contractual delivery date October, 31st 2006
Actual delivery date November, 8th 2006
Deliverable number D TF1.6
Deliverable name Access network architecture III
Type Report
Status & version Final 1.0
Number of pages 170
WP / TF contributing TF1.6, TF1.7, TF1.8
WP / TF responsible TF1.6
Main contributors ALC, EABS, LU, SIE, THOB, BT, FT, PTI, TNO, TID, TP, ROB
Editor(s) Antonio J. Elizondo (TID)
EU Project Officer Pertti Jauhiainen
Keywords Business roles, Authentication and Authorization, IP sessions,

Call Admission Control, Quality of Experience, intelligence
distribution, legal interception, nomadism, Fixed Mobile
Convergence, session continuity, Policy Control and Charging
Abstract (for dissemination) The goal of this deliverable is to provide a more mature
architecture design than that already established in MUSE
phase I, solving those issues that were missing or still open,
considering feedback from lab trials and standardisation, and
incorporating multimedia and FMC capabilities.

architecture III
IST - 6th FP
LIST OF CONTRIBUTORS
Peter Vetter ALC
Benoit De Vos ALC
François Fredricx ALC
Kris Struyve ALC
Tom Van Caenegem ALC
Karsten Oberle ALC
Hans Mickelsson EABS
Wei Zhao EABS
Bob Melander EABS
Govinda Rajan LUNL
Friedrich Armbruster SIE
Mohit Thakur SIE
Alex De Smedt THOB
Dave Thorne BT
Peter Adams BT
Christophe Alter FT
Gilles Bourdon FT
Fabio Costa FT
Mickael Allain FT
Antonio Gamelas PTI
Teresa Almeida PTI
Francisco Fontes PTI
Pieter Nooren TNO
Antonio J. Elizondo TID
Arkadiusz Sitek TP
Tomasz Szantyka TP
Enrique Areizaga ROB
Iñigo Pinilla ROB

architecture III
IST - 6th FP
DOCUMENT HISTORY
Version Date Comments and actions Status
0.0 12/9/2006 First tentative ToC Draft
0.3 15/9/2006 ToC with allocation of chapter Draft

responsibles and tentative # pages
0.4 2/10/2006 First integrated draft Draft
0.41 4/10/2006 Introduction and sections on PCC and Draft

QoS impact for DSBC architecture added
0.5 23/10/2006 Reviewed draft Draft
0.6 30/10/2006 Quality reviewed draft Draft
0.7 3/11/2006 Second quality review draft Draft
1.0 8/11/2006 Final deliverable Final

architecture III
IST - 6th FP
TABLE OF CONTENTS
DOCUMENT INFORMATION .................................................................................................................. 2
DOCUMENT HISTORY ........................................................................................................................... 4
TABLE OF CONTENTS .......................................................................................................................... 5
TABLE OF FIGURES .............................................................................................................................. 8
ABBREVIATIONS ................................................................................................................................. 10
REFERENCES....................................................................................................................................... 17
EXECUTIVE SUMMARY ....................................................................................................................... 21
1 INTRODUCTION ............................................................................................................................ 24
1.1 Objectives............................................................................................................... 24
1.2 Expected results..................................................................................................... 24
1.3 Strategy adopted .................................................................................................... 24
1.4 Starting point .......................................................................................................... 25
1.4.1 Feedback from standardisation phase I................................................................. 25
1.4.2 Feedback from lab trials phase I ............................................................................ 25
2 GENERAL ARCHITECTURE ........................................................................................................ 26
2.1 MUSE business and technical framework ............................................................. 26
2.1.1 Introduction............................................................................................................. 26
2.1.2 Definitions............................................................................................................... 26
2.1.3 Summary responsibilities per role .......................................................................... 27
2.1.4 Architectural analysis of responsibilities ................................................................ 30
2.1.5 Business model inputs to standardisation.............................................................. 36
2.2 AAA ........................................................................................................................ 36
2.2.1 Introduction............................................................................................................. 36
2.2.2 What can be authenticated in broadband access networks? ................................ 36
2.2.3 What do we want to authenticate and why? .......................................................... 38
2.2.4 Specific requirements for Nomadism ..................................................................... 43
2.2.5 Outputs to standardization on AAA ........................................................................ 45
2.3 IP sessions ............................................................................................................. 45
2.3.1 Requirements for IP sessions in WT-146 (dsl2006.392) ....................................... 45
2.3.2 The Challenge of IP Session Monitoring................................................................ 47
2.3.3 ICMP as a mechanism for IP Sessions Monitoring in WT-146 (dsl2006.628) ....... 47
2.3.4 Requirements for IP Sessions Monitoring in WT-146 (dsl2006.671)..................... 49
2.3.5 IP Session monitoring: still under investigation...................................................... 52
2.4 CAC as a resource management tool .................................................................... 52
2.4.1 Analysis of access network potential bottlenecks .................................................. 53
2.4.2 Definition of Call Admission Control (CAC) techniques ......................................... 53
2.4.3 Proposed CAC solutions for unicast traffic ............................................................ 54
2.4.4 Proposed CAC solutions for multicast traffic.......................................................... 55
2.4.5 Integrated resource management for audiovisual flows (unicast and multicast) ... 57
2.4.6 Conclusions on CAC .............................................................................................. 58
3 MULTIMEDIA IN ACCESS ............................................................................................................ 59

architecture III
IST - 6th FP
3.1 Introduction............................................................................................................. 59
3.2 Distribution of intelligence to the access node....................................................... 59
3.2.1 Motivation ............................................................................................................... 59
3.2.2 Retail model ...........................................................................................................65
3.2.3 Wholesale model.................................................................................................... 67
3.2.4 Hybrid model .......................................................................................................... 68
3.2.5 Impact on Authentication........................................................................................ 71
3.2.6 Impact on autoconfiguration and service invocation .............................................. 73
3.2.7 Impact on resource management and QoS ........................................................... 82
3.2.8 Legal interception ................................................................................................... 92
3.2.9 Benefits and conclusion ......................................................................................... 96
3.3 Distribution of intelligence to the residential gateway ............................................ 98
3.3.1 Motivation ............................................................................................................... 98
3.3.2 Impact on AAA .....................................................................................................100
3.3.3 Impact on autoconfiguration and service invocation ............................................101
3.3.4 Impact on resource management and QoS .........................................................104
3.3.5 Conclusion on distributing functionalities into the RGW ......................................106
3.4 Quality of Experience ...........................................................................................106
3.4.1 Introduction...........................................................................................................106
3.4.2 General QoE Aspects ..........................................................................................107
3.4.3 Applications to be considered ..............................................................................108
3.4.4 QoE for Video.......................................................................................................108
3.4.5 QoE for Best Effort Internet Access .....................................................................111
3.4.6 QoE for Gaming ...................................................................................................116
3.4.7 Multi modal / multi party QoE ...............................................................................121
3.4.8 Conclusion............................................................................................................125
4 INTRODUCTION OF FMC CAPABILITIES .................................................................................126
4.1 Use Cases............................................................................................................126
4.1.1 Use Case 1 – Nomadism use case with video call ..............................................126
4.1.2 Use Case 2 – Nomadism use case with IPTV .....................................................127
4.1.3 Use Case 3 – Session Continuity with conversational services ..........................128
4.1.4 Use Case 4 – Nomadic user with public access to private domain .....................130
4.1.5 Resulting requirements ........................................................................................132
4.2 Authentication and Authorization .........................................................................133
4.2.1 EAP ......................................................................................................................133
4.2.2 IEEE 802.1x .........................................................................................................136
4.2.3 SIP........................................................................................................................140
4.2.4 Conclusion for AA mechanisms ...........................................................................145
4.2.5 Architectural Guidelines for AA for Nomadism.....................................................145
4.3 Options for Mobility Management (Session Continuity) .......................................148
4.3.1 Definitions and Scope ..........................................................................................148
4.3.2 Network scenarios................................................................................................149
4.3.3 Mobility techniques...............................................................................................150
4.3.4 Performance comparison .....................................................................................157
4.3.5 Conclusions..........................................................................................................158
4.4 High-level MUSE FMC architecture .....................................................................159
4.4.1 Current status of MUSE FMC Architecture ..........................................................160
4.4.2 Policy control and charging ..................................................................................162
4.4.3 Derivation of a Muse Policy Control Framework..................................................163

architecture III
IST - 6th FP
5 CONCLUSION .............................................................................................................................168
5.1 General architecture studies ................................................................................168
5.2 Multimedia in the Access studies .........................................................................168
5.3 FMC challenges ...................................................................................................169

architecture III
IST - 6th FP
TABLE OF FIGURES
Figure 1: Definition of player, role, and responsibilities ..............................................................27
Figure 2: AAA functions and IP@ allocation functions per role ..................................................31
Figure 3: Technical responsibilities in QoS architecture .............................................................32
Figure 4: Responsibility in case of a single ACS (illustration for model 3, either option A or B
applies) .......................................................................................................................................35
Figure 5: Illustration of Authorization "accepted / rejected" after Authentication.........................38
Figure 6: Service reference model..............................................................................................44
Figure 7: Simplified NGN reference model .................................................................................60
Figure 8: Distributed Session Border Controller Architecture – Retail Model – Signalling..........63
Figure 9: Distributed SBC- Retail Model – Peering SBCs – Signalling.......................................66
Figure 10: Distributed SBC - Retail Model – Roaming................................................................67
Figure 11: Distributed SBC – IP address and Application Wholesale Model – Signalling ..........67
Figure 12: Distributed SBC- Hybrid scenario – Signalling – Service segregation in the RGW ...69
Figure 13: Distributed SBC- Hybrid scenario – Signalling – Service segregation in the Edge
Node ...........................................................................................................................................70
Figure 14: Distributed SBC- Hybrid scenario – Signalling – Service segregation in the distributed
SBC.............................................................................................................................................71
Figure 15: Terminal configuration in one step auto-configuration mechanism with DHCP server
in the Access Node .....................................................................................................................72
Figure 16: Register messages sent by end user in distributed SBC architecture – Policy server
....................................................................................................................................................73
Figure 17: Register messages sent by end user in distributed SBC architecture – Contact field
....................................................................................................................................................74
Figure 18 Register messages sent by end user in distributed SBC architecture – Service Route
....................................................................................................................................................75
Figure 19: VLAN segregation in Access and Aggregation Network............................................76
Figure 20: Network hosted NAT traversal – Interfaces (IP retail)................................................77
Figure 21: Network hosted NAT traversal – Message flow.........................................................78
Figure 22: Network hosted NAPT traversal: Resulting Pinholes, Inbound and outbound rules
and NAT rules on SDP................................................................................................................81
Figure 23: DSBC-TISPAN/RACS mapping.................................................................................83
Figure 24 Reference model for lawful interception (see [10]) with possible segmentation of
lawful interception functions........................................................................................................92
Figure 25: Successful call interception diagram .........................................................................93
Figure 26: Retail mono-provider session ....................................................................................94
Figure 27: Retail multi-provider session......................................................................................94
Figure 28: Retail roaming session ..............................................................................................95
Figure 29: Wholesale model .......................................................................................................96
Figure 30: Extension of secured overlay Network ......................................................................97
Figure 31: NGN Architecture with Distributed RGW ...................................................................99
Figure 32: DHCP based network attachment with explicit authentication.................................102
Figure 33: Service Session Initiation.........................................................................................103

architecture III
IST - 6th FP
Figure 34: Detectability on audio-video desynchronisation (ITU-R BT.1359) ...........................123

Figure 35: Inter destination quality inbalance for a video conference call ................................123
Figure 36: High Level Architecture for Participate! ...................................................................125
Figure 37: Jose showing his mother the photo's of his daughter’s birthday..............................127
Figure 38: José moving from his own home to his friend's home and continues watching a pay
TV soccer match there..............................................................................................................127
Figure 39: Bob's walk to the company's office; without extension ............................................128
Figure 40: Bob's walk to the company's office; with extension for a longer term scenario .......129
Figure 41: Bob uses a public access to a private domain.........................................................130
Figure 42: Third party AAA provider deals with the visitor's authentication ..............................131
Figure 43: Visitor's own service provider deals with the visitor's authentication .......................132
Figure 44: Line Authentication based on 802.1x.......................................................................137
Figure 45: User authentication based on 802.1x authenticator at RGW...................................138
Figure 46: User authentication based on 802.1x authenticator at AN ......................................139
Figure 47: general IMS distributed functions for control plane and user plane .........................141
Figure 48: MD5 Digest Challenge Response Sequence ..........................................................142
Figure 49: SIM Authentication Sequence .................................................................................143
Figure 50: Scheme for storing credential information ...............................................................144
Figure 51: Scheme for storing credential information in case of having multiple public URIs per
private URI ................................................................................................................................144
Figure 52: authentication method for AKA Digest (see also 3GPP TS 33.203 and also IETF RFC
3310).........................................................................................................................................145
Figure 53: Traditional AAA Implementation ..............................................................................146
Figure 54: Generic AA Server Considerations..........................................................................147
Figure 55: Illustration of the definitions. Roaming is a business relation that has impact on all
technical topics .........................................................................................................................149
Figure 56: Different favours of mobility: multiple terminals, access networks, service providers
..................................................................................................................................................150
Figure 57: Top-level view on Fixed-Mobile Convergence, FMC will most likely happen at
common functionality and common services layer ...................................................................159
Figure 58: MUSE FMC architecture..........................................................................................161
Figure 59: Sketch of FMC architecture along the lines of the 3GPP SAE architecture (TR
23.228)......................................................................................................................................162
Figure 60: Policy Management within Fixed Access Network ..................................................164
Figure 61: Inter-Domain Policy Management ...........................................................................165
Figure 62: Policy Execution within Fixed Access Network........................................................166
Figure 63: Inter-Domain Policy Execution.................................................................................167

architecture III
IST - 6th FP
ABBREVIATIONS
3GPP 3rd Generation Partnership Project
A-BGF Access BGF
A-RACF Access RACF
AA Authentication, Authorisation
AAA Authentication, Authorisation, Accounting
ABG Access Border Gateway
ACK Acknowledgement
ACL Access Control List
ACS Auto Configuration Server
AF Application Function
AKA Authentication and Key Agreement
ALG Application Layer Gateway
AMF Access Management Function
AN Access Node
ANP Access Network Provider
AP Access Point
APM Access Policy Manager
AR Access Router
ARF Access Relay Function
ARP Address Resolution Protocol
AS Application Server
ASI Application Specific Information
ASM Application Specific Manager
ASP Application Service Provider
ATM Asynchronous Transfer Mode
AV Attribute Value
B2BUA Back-to-Back User Agent
BB Broadband
BC Border Controller / Binding Cache
BC TV Broadcasted TV
BE Best Effort
BFD Bidirectional Forwarding Detection
BGCF Breakout Gateway Control Function
BGF Border Gateway Function
BPM Business Police Management
BNG Broadband Network Gateway
BRAS Broadband Remote Access Server
BS Base Station
BW Bandwidth
C-BGF Core BGF
C-RACF Core RACF
C-SPDF Core SPDF

architecture III
IST - 6th FP
C-VLAN Customer VLAN

CAC Call Admission Control
CAMEL Customized Applications for Mobile Network Enhanced Logic
CAPEX Capital Expenditure
CAPS Call Attempts Per Second
CC-IIF Content of Communication Internal Interception Function
CCCI Content of Communication Control Interface
CCTF Content of Communication Trigger Function
CCTI Content of Communication Trigger Interface
CDMA Code Division Multiple Access
CLF Connectivity Session Location and Repository Function
CN Correspondent Node
COPS Common Open Policy Service
CoT Care-of Test
CoTI Care-of Test Init
CP Connectivity Provider
CPE Customer Premise Equipment
CPN Customer Premise Network
CSCF Call Session Control Function
DDOS Distributed DOS
DL Downlink
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Service
DOS Denial Of Service
DRM Digital Rights Management
DSBC Distributed SBC
DSCP Differentiated Services Code Point
DSL Digital Subscriber Line
DSLF DSL Forum
E-CSCF Emergency CSCF
EAP Extensible Authentication Protocol
EAPOL EAP over LAN
EPG Electronic Programming Guide
EN Edge Node
ES ETSI Standard
eTOM enhanced Telecom Operations Map
ETSI European Telecommunications Standards Institute
FE Functional Element
FM Fault Management
FMC Fixed Mobile Convergence
FMIPv6 Fast Mobile IPv6
FPS First Person Shooter
GB Giga Byte
GEM GPON Encapsulation Method
GPON Gigabit Passive Optical Network

architecture III
IST - 6th FP
GSB Global System for Broadband communications

GSM Global System for Mobile communications
HA Home Agent
HDTV High Definition Television
HGI Home Gateway Initiative
HMIP Hierarchical Mobile IP
HMIPv6 Hierarchical Mobile Ipv6
HoT Home Test
HoTI Home Test Init
HSI High Speed Internet
HSS Home Subscriber Server
HTML HyperText Mark-up Language
HTTP HyperText Transfer Protocol
I-CSCF Interrogating CSCF
I-WLAN Interworking WLAN
IASA IASA
IASMPM Inter-AS Mobility Policy Manager
IBCF Interconnect Border Control Function
IBGF Interconnect Border Gateway Function
ICE Interactive Connectivity Establishment
ICMP Internet Control Message Protocol
ID Identifier
IEEE Institute of Electrical & Electronics Engineers
IGMP Internet Group Management Protocol
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IntServ Integrated Services
IP Internet Protocol
Ipv6 Internet Protocol version 6
IPCP IP Control Protocol
IPTV Internet Protocol Television
IRI Intercept Related Information
IRI-IIF Intercept Related Information – Internal Intercept Function
ISDN Integrated Services Digital Network
ISP Internet Service Provider
IST Information Society Technologies
ITU-R International Telecommunication Union –Radio standardization sector
ITU-T International Telecommunication Union –Telecommunication
standardization sector
IWF InterWorking Function
L2 Layer 2
L2TP Layer 2 Tunnelling Protocol
L3 Layer 3
LAN Local Area Network
LCP Link Control Protocol

architecture III
IST - 6th FP
LEA Law Enforcement Agencies

LEMF Law Enforcement Monitoring Facility
LI Lawful Interception
LTE Long Term Evolution
MAC Medium Access Control
MAG Media Access Gateway
MAP Mobility Anchor Point
MCP Media Content Provider
MD5 Message Digest 5 algorithm
MF Mediation Function
MGCP Media Gateway Control Protocol
MIP Mobile IP
MIPv6 Mobile Ipv6
MM Multi Modal / MultiMedia / Mobility Manager
MMBB MultiMedia BroadBand
MMO Massively Multiplayer Online
MMOFPS Massively Multiplayer Online First Person Shooter
MMORPG Massively Multiplayer Online Role Playing Game
MMORTS Massively Multiplayer Online Real Time Strategy
MN Mobile Node
MOS Mean Opinion Score
MP Multi Party
MPEG Moving Pictures Expert Group
MRFC Media Resource Function Controller
MRFP Media Resource Function Processor
NACF Network Access Configuration Function
NAP Network Access Provider
NAPT Network Address Port Translation
NAS Network Access Server
NASS Network Attachment SubSystem
NAT Network Address Translation
NAT-PT Network Address Translation – Protocol Translation
NGN Next Generation Networks
NMS Network Management System
NP Network Performance
NPM Network Policy Management
NRP Network Resource Controller
NSIS Next Steps In Signalling
NSP Network Service Provider
OAM Operations, Administration and Maintenance
OCS Offline Charging System
OPEX Operational Expenditure
OSI Open Systems Interconnection
OSS Operations Support System
P-CSCF Proxy CSCF

architecture III
IST - 6th FP
PAE Port Access Entity

PANA Protocol for Carrying Authentication for Network Access
PAR Proactive Address Reservation
PC Personal Computer
PCC Policy Control and Charging
PCC/R7 Policy Control and Charging Release 7
PCEF Policy and Charging Enforcement Function
PCF Policy Control Framework
PCRF Policy and Charging Rules Function
PDF Policy Decision Function
PDG Packet Data Gateway
PDP Policy Decision Point
PE Provider Edge
PEAP Protected EAP
PEP Policy Enforcement Point
PKI Public Key Infrastructure
PM Performance Management
PPP Point to Point Protocol
PSTN Public Switched Telephone Network
QoE Quality of Experience
QoS Quality of Service
RACF Resource and Admission Control Function
RACS Resource and Admission Control Subsystem
RADIUS Remote Authentication Dial-In User Service
RAN Radio Access Network
RAQMON Real-time Application QoS MONitoring
RCEF Resource Control Enforcement Function
RFC Request For Comments
RGW Residential Gateway
RNP Regional Network Provider
RPG Role Playing Game
RSVP Resource Reservation Protocol
RTCP Real-time Transport Control Protocol
RTP Real-time Transport Protocol
RTS Real Time Strategy
RTSP Real Time Streaming Protocol
RUIM Removable User Identity Module
S-CSCF Serving CSCF
SAE System Architecture Evolution
SBC Session Border Controller
SDO Standards Developing/Development Organization
SDP Session Description Protocol
SGSN Serving GPRS Support Node
SIM Subscriber Identity Module
SIP Session Initiation Protocol

architecture III
IST - 6th FP
SLA Service Level Agreement

SLAAC StateLess Address AutoConfiguration
SLF Subscriber Locator Function
SMK Session Master Key
SNMP Simple Network Management Protocol
SP Service Provider
SPDF Service Policy Decision Function
SPOF Single Point Of Failure
SPM Service Policy Management
SPR Subscription Policy Rules
SS7 Signalling System 7
STB Set Top Box
STCP Stream Transmission Control Protocol
STUN Simple Traversal of UDP through NATs
SX Softswitch
TCG Trusted Computing Group
TCP Transport Control Protocol
TIPHON Telecommunications and Internet Protocol Harmonization Over Networks
TISPAN Telecommunications and Internet converged Services and Protocols for
Advanced Networks
TLS Transport Layer Security
TMF TeleManagement Forum
TNC Trusted Network Connect
TOS Type Of Service
TR Technical Report
TS Technical Specification
TTL Time To Live
TTLS Tunnelled TLS
TURN Traversal Using Relay NAT
UA User Agent
UAAF User Access Authentication Function
UDP User Datagram Protocol
UE User Equipment
UL Uplink
UMTS Universal Mobile Telecommunications System
UPM User Policy Management
UPnP Universal Plug and Play
UPSF User Profile Server Function
URI Uniform Resource Identifier
URL Uniform Resource Locator
USIM Universal Subscriber Identity Module
VLAN Virtual LAN
VLAN ID VLAN Identifier
VoD Video on Demand
VoIP Voice over IP

architecture III
IST - 6th FP
VRF Virtual Routing and Forwarding

VQEG Video Quality Expert Group
WAG Wireless Access Gateway
WAN Wide Area Network
WiFi Wireless Fidelity
WIMAX Worldwide Interoperability for Microwave Access
WLAN Wireless LAN
WMM Wireless MultiMedia
WT Working Text

architecture III
IST - 6th FP
REFERENCES
[1] MUSE deliverable DA1.3 “Advanced Application Requirements and User
Behaviours”, November 2005.
[2] MUSE deliverable DA2.2 “Network architecture and functional specifications for
the multi-service access and edge”, January 2005
[3] MUSE deliverable DA2.4 “Network Architecture and Functional Specification for
the Multi-Provider Access and Edge”, December 2005
[4] MUSE deliverable DA4.2 “Standardisation plan”, August 2006
[5] MUSE deliverable DB4.3 “Phase I Integration evaluation report”, July 2006
[6] MUSE deliverable DC4.2 “Preliminary evaluation report on a point-to-point

Ethernet over FTTH access platform for full service end-to-end access”, January 2006
[7] MUSE deliverable D TF1.1 version 6 “Role extensions to the TR-058 business
model”, January 2006
[8] DSL Forum Technical Report TR-069, “CPE WAN Mgmt Protocol”, May 2004
[9] Enhanced Telecom Operations Map (eTOM), TeleManagement Forum,

www.tmforum.org
[10] ETSI DTS/TISPAN-07013 v0.0.11 Telecommunications and Internet converged

Services and Protocols for Advanced Networks (TISPAN); “NGN Lawful Interception;
Lawful Interception functional entities, information flow and reference points”
[11] ETSI ES 282 001 v1.1.1 Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); “NGN Functional Architecture Release
1”
[12] ETSI ES 282 003 V1.6.8 Telecommunications and Internet converged Services and
Protocols for Advanced Networks (TISPAN); “Resource and Admission Control
Subsystem (RACS) Functional Architecture”
[13] ETSI TS 123.228 V5.5.0 Digital cellular telecommunications system (Phase

2+);Universal Mobile Telecommunications System (UMTS); “IP Multimedia Subsystem
(IMS);Stage 2” (3GPP TS 23.228 version 5.5.0 Release 5)
[14] ETSI TS 129 207 v6.4.0 Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS); “Policy control over Go
interface (3GPP TS 29.207 version 6.4.0 Release 6)”

architecture III
IST - 6th FP
[15] IETF RFC 3550, “RTP: A Transport Protocol for Real-Time Applications”, July 2003
[16] ITU-R Recommendation BT.1359, “Relative timing of sound and vision for
broadcasting”
[17] ITU-T Recommendation E.800, “Terms and Definitions related to Quality of Service
and Network Performance including Dependability”
[18] ITU-T Recommendation G.107, “The E-model, a computational model for use in
transmission planning”
[19] ITU-T Recommendation G.1010, “End-user multimedia QoS categories”
[20] ITU-T Recommendation G.1030, “Estimating end-to-end performance in IP

networks for data applications”
[21] ITU-T Recommendation G.1030 Annex A, “Opinion model for web-browsing

applications”
[22] ITU-T Recommendation J.148, “Requirements for an objective perceptual

multimedia quality model”
[23] ITU-T Recommendation P.800, “Methods for subjective determination of

transmission quality”
[24] ITU-T Recommendation P.910, “Subjective video quality assessment methods for
multimedia applications”
[25] ITU-T Recommendation P.911, “Subjective audiovisual quality assessment

methods for multimedia applications”
[26] ITU-T Recommendation P.920, “Interactive test methods for audiovisual

communications”
[27] RFC 1035, “Domain names, implementation and specifications”, November 1987
[28] RFC 3319, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session
Initiation Protocol (SIP) Servers”, July 2003
[29] Armitage, G., “Quake3 playing times”, May 2001
[30] Banerjee, N. et al., “Seamless SIP-based mobility for multimedia applications”
[31] Bettner, P. and Terrano, M., “1500 Archers on a 28.8: Network Programming in
Age of Empires and Beyond”, Presented at GDC2001 - 03/22/2001 2:30p

architecture III
IST - 6th FP
[32] Buddhikot, M. et al., „Integration of 802.11 and Third Generation Wireless Data
Networks”
[33] Chakravorty, R. et al., “Performance issues with Vertical Handovers – experiences

from GPRS cellular and WLAN Hot-Spots Integration”
[34] Dick M., Wellnitz, O. and Wolf, L., “Analysis of Factors Affecting Players’
Performance and Perception in Multiplayer Games”, NetGames’05, October 10–11,
2005
[35] Dutta, A. et al., “Experimental analysis of multi interface mobility management

with SIP and MIP”
[36] GauthierDickey, C., “Distributed Architectures for Massively-Multiplayer Online

Games”
[37] Haverinen, H., Salowey, J. , “Extensible Authentication Protocol Method for GSM
Subscriber Identity Modules (EAP-SIM)”, December 2004
[38] Henderson, T., “The effects of relative delay in networked games”, PhD Thesis,
University of London, February 2003
[39] Hsieh, R. et al., “Performance analysis of Hierarchical Mobile IPv6 with fast-
handoff over end-to-endTCP”
[40] Kim, W. et al., “Link layer assisted mobility support using SIP for Real-Time
multimedia communications”
[41] Kline S., Dyer-Witheford, N. and de Peuter, G. “Digital Play. The Interaction of
Technology, Culture, and Marketing”, Montreal and Kingston: McGill-Queen's
University Press, 2003
[42] Kücklich, J, “Play and Playability as Key Concepts in New Media Studies”, STeM
Centre, Dublin City University
[43] Nakajima, N. et al., “Handoff delay analysis for and measurement for SIP based
mobility in IPv6”
[44] Shacham, R., Schulzrinne, H. et a l., “The Virtual Device: Expanding Wireless
Communication Service through Service Discovery and Session Mobility”
[45] Singhal, S. and Zyda, M., “Networked Virtual Environments: Design and
Implementation.” Addison Wesley, 1999.
[46] Smed, J., Kaukoranta, T., Hakonen, H., “Aspects of Networking in Multiplayer
Computer Games”

architecture III
IST - 6th FP
[47] Tian, J. et al., “Performance of MIP/WLAN in rapid mobility environments”
[48] Yakota, H. et al., “Link layer assisted Mobile IP fast handoff method over Wireless
LAN networks”
[49] “OPScore, or Online Playability Score: A Metric for Playability of Online Games
with Network Impairments”, Ubicom Inc., March 2005
[50] FT laboratory experiments on Mobility Manager handover performance, results

presented by Benoit Radier, Joseph de Biasio and Oliver Roussel during MUSE
consortium meeting in Bilbao, October 2006

architecture III
IST - 6th FP
EXECUTIVE SUMMARY
The objective of this deliverable is to provide a more mature architecture design than that
already established in MUSE phase I. This deliverable is a first result of three different Task
Forces. TF1.6 had the aim of solving those issues that were missing or still open, taking into
account feedback from the first lab trials and from standardisation, whereas TF1.7 focuses on
incorporating multimedia service enablers on the network architecture and TF1.8 addresses
FMC capabilities and their impact on the overall architecture.
One of the first open questions that had to be solved was the robustness of the business roles
model devised in MUSE, especially because lots of further decisions depend on it. A refinement
and agreement of business and technical responsibilities associated to each role was done, and
its consistency was checked against the AAA architecture, IP address allocation process, QoS
framework, and ACS. As a result, various contributions were made to the DSLF, ETSI TISPAN
and the HGI on these topics.
The achievement of several main targets of MUSE such as the support of multiple services by
the same network and nomadic users depends mostly on having a well designed AAA
architecture. Subsequently, several use cases were proposed to cover the most likely scenarios
and requirements to be fulfilled by the AAA architecture were extracted from them.
The control of IP sessions in an environment where more and more services are based on
DHCP instead of PPP, and where multiple operators may share the responsibilities to handle
the traffic of nomadic and non-nomadic subscribers is also an important part of the AAA
architecture. The strengths and weaknesses of different methods to monitor IP sessions, like
BFD, ICMP and traffic detection, were studied and described. Although there is not yet
consensus on which protocol is best suited, a possible approach would be to use an existing
protocol such as ARP or ICMP for session monitoring in the short term, targeting BFD as the
longer term solution.
The usage of CAC as a management tool to help to provide QoS is studied for both unicast and
multicast based services. As a result, the usage of selective CAC at certain network locations
and the concurrence of local and central CAC processes are proposed. The usage of local CAC
techniques for multicast traffic is also put forward as a way to achieve more scalable systems
and to shorten the session initiation delays.
Most of the previous items worked on have resulted in standards contributions. These
contributions have already partially met their goals and contribute to the overall objective of a
standardised "GSB" architecture.
In order to enable Broadband Multimedia support in access networks, both distribution of

functions of the Session Border Controller (SBC) and Quality of Experience (QoE) have been
addressed in TF1.7.

architecture III
IST - 6th FP
The distribution of SBC functions is put forward as a potential way to achieve more flexible,
robust and scalable networks. Two approaches are considered, one is aiming at the distribution
of the SBC functions into the Access Nodes, while the other proposes to distribute some of
these functions to trusted Residential Gateways, potentially making the network even simpler.
The impact on the network in terms of AAA and resources management is studied, showing that
technically both options should be seriously considered provided that security and cost are not
endangered. The latter concern is further investigated in the techno-economic studies of MUSE
WPA3.
With the objective of improving the quality of multimedia services experienced by end-users,
QoE is thoroughly studied, and especially for video (IPTV, VoD), Best Efforts Internet access,
gaming and Multimode multiparty applications. Although the goal of controlling QoE is not easy
to be reached, as different services will produce different QoS requirements to achive a good
QoE, it has been concluded that a measurable QoE would allow feedback on customer
satisfaction, and the most important QoS parameters per service that need to be controlled
have been extracted.
The step towards next generation broadband access architecture includes not only triple play
but also support for quadruple play which in essence means support for mobility. TF1.8 studies
which new or enhanced functions must be added to the current MUSE fixed access network
architecture to support both nomadism and FMC.
To do that, different use cases have been proposed and analysed, in order to derive new
requirements to the MUSE network architecture. Further, architectural solutions for the above
use cases will be worked out.
Again, the work is focused on authentication, as it is a vital function for achieving nomadism and
FMC. Per line and per user authentication have been investigated to find a good solution for
both network access and service authentication. 802.1X is commonly used for authentication
purposes, but in the MUSE scenario this has proven to have difficulties since it does not allow
NAT traversal or routed, un-trusted RGWs. PANA has also been investigated and found to have
similar problems. Work is on-going to provide solutions for this, but the current result is that
there is no good solution for line authentication for routed and or/un-un-trusted RGWs. It is
envisaged that some sort of xSIM must be used for per user/per service authentication in
addition to the per line authentication. Consequently EAP-SIM or EAP-AKA (to be carried over
802.1x or PANA) are the preferred protocols to carry authentication messages.
MUSE considers both network layer and application layer mobility management methods to
support Session Continuity and Continuous Mobility of mobile terminals.

architecture III
IST - 6th FP
With regards to application layer mobility management, current implementations of SIP and MIP
mobility management schemes are able to provide Session Continuity, but with noticeable
service interruption or loss of data while changing network attachment points. Both protocols
show handover latencies of the same order of magnitude. Consequently, it is not possible to
select which one is the best mobility management method. Finally, application layer mobility
management methods can be enhanced by means of PAR (Proactive Address Reservation)
which provides efficient mechanism to improve handover performance. It employs link layer
information to anticipate handover and allows terminal to obtain IP configuration before link
layer handover.
Network-supported handover is a promising concept to provide both network and application

layer seamless mobility. It employs access network elements to assist the terminal whilst
changing the network attachment point. Two candidate methods of this kind are: IP soft
handover (RTP packets are replicated in access network to be delivered to both interfaces of
dual mode terminal) and Mobility Manager (network triggers handover and instructs terminal
what access network to choose). Network-supported handover promises to provide Continuous
Mobility for the moving terminals.
MUSE Session Continuity architecture will consist of IP soft handover for SIP-controlled
conversational services, FMIPv6 for non-SIP services and optionally Mobility Manager to
support terminals with the choice of the most appropriate access network while in the move.
In addition to the functionality described, MUSE is also looking into how fixed access networks
should interact with mobile operators’ networks for supporting FMC and nomadism, considering
multi-access scenarios with roaming between different accesses and possibly also between
different providers as well as session continuity. An architecture with well defined interfaces
both towards the access and towards the IP-transport and application level is being considered
in MUSE with the prime focus on how to re-use 3GPP I-WLAN architecture and to understand
the development of SAE/LTE.
Finally, a policy framework is described within the MUSE architecture that would support FMC
and Nomadism. The application of the policy framework is described with reference to the
management and execution of policies. The aim is to make relevant policies available close to
the point of inception of the service by making them available at local repositories.

architecture III
IST - 6th FP
1 INTRODUCTION
1.1 Objectives
The objective of MUSE TF1.6 is to provide a more mature architecture design than that already
established in phase I. A well defined architecture should serve the functional goals of multi-
service capability, multihosting-capability, secure connectivity and low cost including OPEX.
The goal of TF1.6 is to study new network technologies and missing issues that were not dealt
with in MUSE phase I. It will also take into account feedback from the first lab trials and from
standardisation. As the MUSE architecture of Phase II will also incorporate multimedia service
enablers and FMC capabilities, a summary of the current status of these architecture studies is
included. These two activities will however continue and result in dedicated deliverables (D
TF1.7 and D TF1.8).
The ultimate goal is to deliver a reference document that describes the GSB architecture. TF1.9
will follow the work achieved in TF1.6, to reach that objective.
1.2 Expected results

The following outputs are expected from TF1.6:
• Top level specification of the most important network requirements to guide the work on
the advanced demonstrators of phase II.
• Standardisation of MUSE architecture concepts and solutions in appropriate standards
bodies.
Special focus is given to the following areas:

• Refinement of the business framework with more detailed responsibilities and interfaces.
• Detailed definition of AAA features to support the envisioned services.
• Study of the most appropriate IP sessions management mechanisms.
• Specification of resource management and QoS mechanisms.
• Distribution of intelligence to the Access Node to support multimedia services.
• Distribution of intelligence to the Residential Gateway to support multimedia services.
• Mechanisms to monitor and enhance the Quality of Experience.
• Study of the most appropriate AAA protocols to support the selected FMC use cases.
• Techniques for mobility management with sessions continuity.
1.3 Strategy adopted

The network architecture activity within WPA2 in phase I has provided appropriate answers to
the demands put on the access and aggregation network, which has resulted in a series of
milestones and deliverables (see [1] and [3]).

architecture III
IST - 6th FP
The strategy adopted by TF1.6 in phase II is to capitalize on the material elaborated in the past
two years, and to accelerate bringing the MUSE architecture to international standardisation.
DSLF and ETSI TISPAN are considered the main targets for TF1.6 outputs. Standards
contributions will be in line with the overall strategy decided in WPA4 (see [4]).
1.4 Starting point

1.4.1 Feedback from standardisation phase I
Feedback on the contributions brought by MUSE to the standard bodies in phase I was given by
the partners involved at the beginning of phase 2. The DSL Forum proved to be an appropriate
target for the work done in MUSE on the broadband architecture and interoperability. A total of
12 co-signed contributions on architecture (10 to DSLF and 2 to ETSI TISPAN) were brought to
standardisation by MUSE in phase I, and many more from individual partners, thereby starting
to establish good visibility and obtain some credibility. However the need to bring forward some
more definite proposals and reasoned choices was highlighted. It was decided to step up the
pace in phase 2, with more contributions. It was proposed that MUSE should concentrate efforts
on the following areas first:
• Bandwidth management and ‘end-to-end’ QoS
• Authentication
• IP session control
• Nomadism
• RGW functionality
• OAM
With regard to ETSI-TISPAN, two contributions were brought by MUSE in phase I which led to
the creation of a new work item “QoS Requirements for TISPAN NGN Release 2”. It was
decided to continue in phase II and a number of areas were identified for future contributions in
the scope of TF1.6, TF1.7 and TF1.8, namely:
• Control of the Access Node
• Control of home networks and CPE
• Specification of the Ra interface
• Impact of nomadism and FMC on the various subsystems
• Network deployment scenarios and business roles
1.4.2 Feedback from lab trials phase I

Feedback was received from the MUSE SPB and SPC lab trials on the architecture and node
requirements specified by TF1 in phase I. No showstoppers or major inconsistencies have been
identified so far. More details on the SPB and SPC lab trials can be found in [5] and [6].

architecture III
IST - 6th FP
2 GENERAL ARCHITECTURE
2.1 MUSE business and technical framework
2.1.1 Introduction
In phase I MUSE elaborated a business model in order to define requirements for a multi-
service architecture that is open to multiple providers and flexible enough to support different
scenarios (cf. [3]). The model defines different roles with their respective responsibilities. It
extends the model defined in TR-58 of the DSLF with two new roles, the Connectivity Provider
and the Packager.
In phase II, the business model was further refined. There was a need to make an explicit
distinction between the business responsibilities and the technical responsibilities and
equipment ownership. While a general allocation of technical responsibilities was already done
in phase I (cf. [7]), it was not complete and a more detailed analysis of the technical
responsibilities was required for the AAA architecture, IP address allocation, QoS framework
and ACS. MUSE phase II also followed up on related standardisation.
2.1.2 Definitions
"Role": A role is defined by a logical grouping of responsibilities. The idea is to provide a generic
framework of atomic entities with appropriate granularity that allows for mapping the roles on
different possible real-life actors. A single "role" can be a real life actor or multiple roles can be
combined in one business actor. A role may have "business responsibilities" and/or "technical
responsibilities".
"Business Actor" (also "Player"): A legal entity in real life that combines one or more roles,
each of which must be instantiated as either a "business role" or a "technical role". A Business
Actor must incorporate at least one business role (this is required for the player to survive). The
combination of roles may vary in different countries or change in time (e.g. by acquisitions,
divestments, or establishment of new roles).
"Technical Role" is a role that has only technical responsibilities. It only provides services to
(an)other role(s) within the same player.
"Business Role" is a role that must have one or more specific business responsibilities and will
in several cases also have technical responsibilities. That is the case when a role provides
services to (an)other player(s) outside his organisation and hence also has a business
relationship.
"Business responsibility": fulfilment of a service towards another player in accordance with a

contract.
"Technical responsibility": technical tasks or functions to provide a service to another role;

includes in general the responsibility for equipment.

architecture III
IST - 6th FP
Atomic role
Business Player
Business Role Business Role Business Role
biz tech
-….. -…..
-…. -….
-…. -….
-…. -….
Business Responsibilities Technical Responsibilities
Figure 1: Definition of player, role, and responsibilities

Remark:
Depending on the real-life scenario (that is when we consider business actors), a role can be a
business role or only a technical role. E.g. a Connectivity Provider (CP) role is combined with an
Application Service Provider (ASP) in one player. In case the Connectivity Provider provides the
connectivity only for his own organisation, the Connectivity Provider is a technical role. If the
Connectivity Provider also provides connectivity for another(s) player(s) (e.g. Application
Service Provider), and hence has a business relation with this actor, the Connectivity Provider is
also a business role.
MUSE mainly focuses on the technical responsibilities of a role.
2.1.3 Summary responsibilities per role

The definitions of the different roles were given in [3]. The only newly defined role is the Media
Content Provider (MCP), which provides the content for a service, e.g. the movies for VoD. The
present section summarises the responsibilities per role.
Business responsibilities
Customer • Signs a contract with Packager(s).

• Agrees priorities and profiles with main Packager.
• Pays the bill(s) (e.g. every month).
• Contacts the main Packager in case of problems.
• Chooses the main Packager, if appropriate.
Packager • Contract and equipment delivery to users.
• Installation and configuration (or guide to user).
• SLAs to CP and different service providers, possibly to other Packagers
• Helpdesk.
• Collecting different technical data from providers (e.g. credentials,
server URLs,…).

architecture III
IST - 6th FP
• Agrees priorities and profiles with Customer.

• Exchange of technical data (e.g. user address, credentials, server
URLs,… ) to BB access provider (NAP, CP) for configuration and
management.
• Assembles Accounting from different providers.
• Billing to the Customer.
• Selection of host for ACS in case of multiple CP (NAP or main CP).
NSP • Signs SLA with Packager.
• Provides technical user data (e.g. credentials, server URLs,…) to CP.
• Provides network related settings to Packager.
ASP • Signs SLA with Packager.
• Provides technical user data (e.g. credentials, server and service
URLs,…) to Packager on service activation, management and usage.
MCP • Signs SLA with ASP.
• Advertises content.
CP • Signs SLA with Packager.
• Provides technical data (e.g. credentials, server URLs,…) to Packager.
NAP (also • Signs SLA with CP.
known as • Provider technical data (e.g. addresses, credentials, server URLs,…) to
ANP) Packager.
RNP • Signs SLA with CP.
Technical responsibilities
Customer • Has devices installed and starts provisioning procedures.

User Makes an actual communication:
• Has devices powered on,
• Starts a service session,
• Authenticates if needed, automatically or not.
Packager • No technical equipment responsibilities.
But has technical responsibilities with regard to:
• Installation and configuration of equipment, or installation guide,
• Helpdesk,
• Providing technical data (e.g. credentials, server URLs ) to users (as far
as this is not automated,
• Holds a data base with policy profiles and SLA per subscriber.
NSP • Provides the (network) functions for the Internet or corporate services.
• Provides the credentials for a user to the Packager (for Internet account,
for corporate network access, etc).
• Provide this particular Network Access parameters and IP addresses for
User IP sessions to the CP.
ASP • Provides the A10 functions for delivering and controlling the service.
• Provides the credentials for a user to the Packager (for this service).

architecture III
IST - 6th FP
• Provide this particular service parameters and IP addresses for User IP

sessions to the CP.
• Holds the service policies per user.
MCP • Makes the content in common formats.
• Digital rights management.
• Provides a content platform to offer the A11 functions for content
provisioning.
CP • Interprets those signalling messages that are necessary to determine
the necessary connectivity means (data path) with involved networks
(Internet, corporate, etc). Forwards initial signalling messages bound for
ASPs that are in the same package to the appropriate server (e.g. AAA,
DHCP server).
• Setting up of semi-permanent and permanent connections with required
QoS.
• Holds SPDF (Performs policy decision whether requested QoS
parameters received from the AF are compliant with the SLA between
CP and ASP and sends resource request).
• Optional signalling of QoS requests with core network to provide end-to-
end QoS if congestion in core network is expected.
• Hosts ACS in case of single CP or main CP selected by Packager.
NAP (also • Deals with connections in the access network.
known as • Enforces the authorizations resulting from subscriber profile.
ANP) • Deals with management of residential gateway and home devices via
the ACS and based on configuration data, profiles and priorities
collected by main Packager.
• Receives service requests from a home and distributes it to the
appropriate serving entity(ies).
• Performs admission control at resource level (A-RACF), resource
reservation, and policy enforcement required to provide QoS in the
access network.
• Performs QoS classification, scheduling, shaping, and monitoring in the
data plane of the access network.
• Option to host ACS in case of multiple CPs.
RNP • Provides connections in the regional network between the access edge
and the service edge (border to the service networks).
• Optionally performs resource admission control, resource reservation,
and policy enforcement required to provide QoS in the regional network
in case congestion is expected.

architecture III
IST - 6th FP
2.1.4 Architectural analysis of responsibilities

Analysis of roles and responsibilities in AAA architecture
The present section summarises the technical responsibilities of the different roles to support
AAA. The details of the AAA architecture are explained in section 2.2. Here we consider the
case without nomadism support. The cross-check for nomadism is done in section 4.2, in the
frame of TF1.8 activities on Fixed Mobile Convergence (FMC).
Figure 2 shows the AAA functions per role for the case of L2 pipes in the aggregation network
(VLAN or PPP). The cases of L2 and L3 forwarding are very similar, whereby the AAA proxy
function is accessed directly from the Access Node. Note that the AAA proxy function can be
implemented as a stand-alone box or integrated in an Access Node or Edge Node.
Important requirements were the support of multiple CPs per NAP, as required by regulation,
and multiple CPs per user, depending on the service he/she requests. The NAP therefore hosts
an AAA proxy function to select the right CP. If the NAP is not a CP, then it only has the AAA
proxy function, which selects the correct CP. If the NAP is also a CP, then the NAP has the AAA
server and DHCP server associated with the CP role. There can still be multiple other external
CPs for the NAP, where the AAA request can be sent.
Now, how can the NAP AAA proxy make the selection of CP? The Packager has this
information, but only has a business relationship with the CP. The solution is that the user
device includes two identifiers in the credentials (credentials = username / password / domain)
s/he sends to the network; one to identify the CP, and one to identify the (type of) service that is
being requested. This is set by the Packager at service subscription time, and modified every
time the user takes/leaves a service subscription from the Packager’s offering. This interaction
Customer-Packager happens transparently for the NAP, CP, SP and could be based on
helpdesk/mail/web server/SIM card/other.
The next step is to forward the AAA request to the correct service provider. This is done by the
CP based on the credentials; depending on the (type of) service it sends the AAA request either
to its own AAA server (this is a service that will be offered by an ASP and for which the CP is
responsible for AAA and IP address allocation), or to one of the NSPs, or to one of the ISPs.

architecture III
IST - 6th FP
AAA AAA DHCP

server proxy server
authenticator CP 2 Packager
AAA client
AAA AAA DHCP
DHCP relay server proxy server
CP 1
Applic
If NAP is If NAP is Auth server
also CP CP selection AAA
also CP
server
AAA
opt82
proxy
DHCP NSP
Customer(s) server
Service
Access EN
device L2 AN EN
Ethernet
Terminals
Aggregation network ISP
Access
EN
Applic
CPN Auth server
NAP RNP
RGW
ASP
Figure 2: AAA functions and IP@ allocation functions per role
Although single sign-on is preferred by the end-user, there are several issues related with this,
e.g. multiple CPs, lifetime of a service subscription, or failure of a specific authentication. The
working assumption is that there is an authentication request per service request, which can be
in push mode (CP replicates the authentication request to all SPs related to the user) or in pull
mode (user requests service from a SP and then the SP contacts the CP to seek
authentication).
On top of the described network-based AAA mechanism and transparently to it, there is
application level authentication. This can be implemented either by means of web portal
(manual log-in), or embedded in a device (e.g. SIP exchange).
IP address allocation
When different roles are involved in the business model, it is also important to reach the correct
DHCP server. This can be based on the result of the authentication phase.
During authentication/authorization, the AAA server reply also includes the IP address of the
DHCP server of the corresponding SP. The DHCP relays in the Access Node and Edge Node,
snoops this reply from the AAA server and hence can forward the DHCP Discover message
sent by the user device to the correct DHCP Server.

architecture III
IST - 6th FP
Analysis of roles and responsibilities in QoS framework
Main policy repository per domain

CAC (RACF)
S-PDF CP1 Packager
Policy Repository
Policy (PDF) SLA for individual
service packages
Enforcement (RCEF) per subcribers
Classification S-PDF CP2

Monitoring QoS signalling
Control interaction
Management configuration
Local CAC Central CAC
RACF
(RACF) (RACF) AF
for RN
ASP1
Customer(s) Service
S-VLAN EN
S-VLAN CP2
CP2
device AN
Terminals S-VLAN
S-VLAN CP1
CP1
ISP
Access
Ethernet EN
CPN
RGW Aggregation network NAP RNP
AF
ASP2
Figure 3: Technical responsibilities in QoS architecture
Figure 3 shows the responsibilities in the QoS architecture. Note that only network-level control
interactions have been represented. So, the model supports both push and pull modes as QoS
reservation mechanisms, where the former would use additional application-level signalling
between the UE and the AF. The following responsibilities need to be allocated in the
management plane:
There is a main Policy Repository for each administrative network domain (business role)
which serves as a centralized database for the policy instances in their domain.
The following main policy responsibilities can be distinguished per role:

• Packager: SLA for individual service packages per subscribers.
• ASP/NSP: Holds SLA per subscriber for specific service.
• CP: Translates service policies into network policies per user for access network and
regional network and holds SLA between ASP and CP.
• NAP: Holds an SLA for the aggregate traffic for each CP that uses its infrastructure.
Each policy repository (except for the one with the packager) is associated with a PDF (Policy
Decision Function) that consults the policy repository for the related policy decision when a
session is set-up in the control plane.

architecture III
IST - 6th FP
It is possible that there are additional local policy repositories that contain copies of specific
policy instances to speed up response times of policy decision functions. It is also possible that
policy instances of one role are copied to another role to speed up the response time of a
decision (e.g. the network policies per user from the CP are copied to the NAP to shorten the
delay of the RACF).
In case of having multiple CP, the NAP statically partitions the resources per subscriber and
aggregate resources per CP in the management plane. Dynamic re-partitioning of resources
among CPs is considered too complex in the control plane.
The following responsibilities can be defined in the control plane:
The AF is located in the ASP. It receives the signalling for a service from the user. It verifies
whether the requested service is in line with the SLA of the user and generates a QoS request
to the CP. This QoS request contains QoS parameters (e.g. bandwidth, priority class). It waits
for the response from the CP before granting or denying the service to the user.
The SPDF is located in the CP because it is responsible for the QoS of the connection. The
SPDF verifies whether the QoS parameters requested by the AF are compliant with the SLA
agreed between the CP and the ASP. It enforces priorities between competing services (from
different ASP) per user, following settings received from the packager. The SPDF requests
resources from the access network and the regional network and waits for a response before
giving feedback to the AF.
The RACF is the responsibility of the NAP, because the NAP has the best view of the access
network topology and resources offered to different CPs that use the access infrastructure. The
NAP typically does not want to share this information with another business role, such as a CP.
The RACF can hence not be part of the CP. There is also no open interface defined today
between the CP and the resource database of the NAP. The RACF receives the resource
request from the SPDF in the CP and returns a grant or denial for resources as feedback to the
SPDF. The RACF can be implemented as a centralised RACF, as well as a local RACF on the
AN or EN (cf. section 2.4). Whether the RACF for a specific service is local or centralised,
RACF is a static configuration decided by the NAP. In order to improve the response it is
possible that the PDF and AF are forwarded to the Access Node and configured in the
management plane, but the related responsibilities respectively remain with the CP and ASP).
The NAP is also responsible for the policy enforcement (policing) at the ingress points of its
network (RCEF: Resource Control Enforcement Function).
There may optionally also be a RACF and related policy enforcement function in the RNP. This
is however only needed if congestion is expected on the aggregated connection between the
NAP and the NSP or ASP.

architecture III
IST - 6th FP
The NAP is responsible for the QoS functions in the dataplane like classification and
monitoring. Optionally, the RNP is responsible for these functions in his segment of the
network.
The residential gateway will contain QoS classification functions. Optionally the residential
gateway may also contain a policy decision, call admission control, enforcement, and monitoring
function for the CPN. The complexity and necessity of these functions in the residential gateway
however are for further study. There is also an issue with whether or not such functionality can
be trusted in what may be a customer owned device.
Analysis of responsibilities to manage CPE (by means of ACS)

Several providers have a responsibility to manage functions in the CPE (Customer Premises
Equipment) pertaining to their respective services. E.g. a Connectivity Provider needs to
configure connection parameters, a service provider needs to configure service parameters or
upload new versions of software modules, or a packager is interested in the outcome of
diagnostics functions to fulfil its helpdesk responsibility. CPE can be a residential gateway or
other type of terminal, such as a STB (Set Top Box). The management functions are performed
by an ACS (Auto-Configuration Server). The DSLF TR-069 protocol is used to convey
management messages between the ACS and the CPE. The questions addressed here are:
who is responsible of the ACS and who is responsible for the mediation of agreements to avoid
conflicting configurations by multiple providers?
MUSE TF3 has defined three models for the management of the CPE by multiple providers::
• Model 1: Multiple ACS per CPE: Each provider owns an ACS and manages its
respective parameters in the CPE. A possible implementation is the use of virtual
gateways in the RGW. A policy framework on the CPE enforces priorities in case of
conflicting management actions. These policies can manually be pre-configured in the
CPE or downloaded from a mediating ACS. This requires some adaptations of TR-069
and the related data model of the CPE (e.g. TR-098 for the RGW).
• Model 2: Single ACS per CPE with multiple interfaces to different OSS: Each provider
communicates its management actions from its OSS to the single ACS via a so-called
northbound interface. Mediation of conflicts is done by the ACS. This requires a
standardised northbound interface to allow communication across provider domains,
which is not available today.
• Model 3: Single ACS with one northbound interface to one mediating OSS that
communicates with the different OSS of each provider. The ACS and mediating OSS are
in the same provider domain. Conflicts are mediated at the level of the single ACS or the
mediating OSS.

architecture III
IST - 6th FP
The Packager has the business responsibility of defining priorities between providers to avoid
conflicting configurations on the CPE, because it has the total view of the agreements with all
involved providers and of the requirements of the service package of the subscriber. A majority
of subscribers is expected to use a single packager for their services. The allocation of this
responsibility to the Packager will hence be sufficient in most cases. A regulator is likely to
require that a subscriber should be able to buy services from more than one Packager in order
to prevent the first Packager locking out other service providers, and to accommodate the case
where the required basket of services is not available from a single Packager. In the case of
multiple Packagers, the subscriber either is sufficiently skilled to perform configurations of
priorities himself or selects a main Packager for this purpose.
Since the Packager is a pure business role and does not own network equipment, it has to rely
on someone else to host the ACS and implement the policies used for mediation. In the case of
a single ACS, the following scenarios are foreseen (only Model 3 is illustrated in Figure 4, Model
2 is however similar):
• Scenario of a single CP (Connectivity Provider), the CP is the most logical technical role
to host the ACS, because the configuration of the connectivity parameters in the CPE is
the most essential function to be performed by an ACS (option A in Figure 4).
• Scenario of multiple CPs, the Packager can either select a main CP (option A in Figure
4) or the NAP to host an ACS (option B in Figure 4).
ACS OSS CP 2 Packager
Connection configuration
Monitoring, diagnostics
Option A: Single ACS in CP for helpdesk
- single CP
- multiple CP with “main CP” ACS OSS CP 1
selected by packager
Service configuration
SW updates
OSS ASP1
Customer(s) ACS OSS
Service
EN
device AN Option B: Single ACS in NAP
Terminals - multiple CP
(interactions not shown) ISP
Access
Ethernet EN
CPN
RGW Aggregation network NAP RNP
ASP2
Figure 4: Responsibility in case of a single ACS (illustration for model 3, either option A or B
applies)

architecture III
IST - 6th FP
In the case of multiple ACSs per residential gateway (Model 1), the responsibility of the
mediating ACS could be assigned along the same guidelines as for a single ACS. More
research is however required to understand the supporting technologies on the CPE and their
cost impact. Hence the options in the business model are left open for further study.
2.1.5 Business model inputs to standardisation

MUSE made various contributions to standardisation on business models.
• Contribution dsl2005.556.00 introduced the new business roles of Connectivity Provider and
Packager to the DSLF. It also described the consequent shift of some of the responsibilities
of existing roles to these new roles. The definitions were included in WT134 (the Policy
Control Framework – PCF).
• Based on the MUSE results, BT introduced the Connectivity Provider concept to ETSI
TISPAN by contribution ETSI_11bTD149 for consideration in TISPAN Release 2.
• MUSE presented the MUSE models in HGI (reference HGI00319). The HGI decided to
proceed with a model that reflects vertical integration with two players. The NAP, RNP and
CP are combined in an "Access Provider". The Packager, NSP, and ASP are combined in a
"BB Service Provider".
2.2 AAA
2.2.1 Introduction
Two features mainly motivated the revisiting of the authentication mechanisms described in
current standardisation:
• The first is the support of multiple services by the same network. DHCP-based services
appear in parallel with and/or as a replacement for PPP-based services, and at least the
same level of authentication measures must be possible for the DHCP-based services
as for PPP-based services. Moreover different services can be offered by different
providers, so that the user has to receive a service-specific treatment.
• The second is the additional requirement to support nomadic users, which implies that
users need to be easily authenticated from different places in a network, and even from
different networks (roaming situations).
These considerations lead to the use of credentials for the authentication. Hence a suitable AAA
architecture is required. Also the implication on the different business roles has to be
addressed.
2.2.2 What can be authenticated in broadband access networks?

The network performs authentication by means of an authenticator (which collects the
authentication credentials from the end-user’s side) and an authentication server which
determines whether these credentials match a known entity, and then deduces the authorization
rights related to that entity, or simply logs such information for later processing.

architecture III
IST - 6th FP
An entity is authenticated from the credentials (i.e. unique authentication key) which are
provided to the authentication server. However, such an entity does not necessarily transmit the
credentials itself to the network; further, the credentials of the entity which is to be authenticated
can be provided or configured by another entity. Therefore, neither the device which transmits
the credentials to the network nor the individual who provides these credentials to such a device
do necessarily match the entity which is to be authenticated from these credentials. It is a
combination of both questions – what device transmits the credentials and how was that device
provided with these credentials – which determines the entity which can actually be
authenticated from the credentials, as summarized in the following table:
1/ What is the device which provides the credentials to the

network?
Individual device
Access Node RGW
behind RGW
Physical RGW; Physical device;

Hard coded in Subscriber per line
2/ How are the credentials provided to that device?
factory or
Type of RGW; Type of device;
or
Configurable by the
Subscriber per Subscriber per
operator only Subscriber per circuit
physical RGW; physical device;
Configurable by the
subscriber
Subscriber per
or N/A Subscriber per RGW
device
From a smart card
per subscriber
Configurable by
individual end
users
N/A N/A End user per device
or
From a smart card

per end user
What entity can a network operator authenticate from the

credentials?
Table 1: Entities that can be authenticated in broadband access networks

architecture III
IST - 6th FP
2.2.3 What do we want to authenticate and why?

2.2.3.1 Relation between network authentication and network authorization
One of the most common motivations for operators to implement authentication mechanisms in
their network is to be able to authorize the authenticated entities to access the network
resources.
Authorization can typically take the form of an authorization profile, which is returned by a policy
server to the network node which endorses the role of the authenticator, after the authentication
process is completed. Such an authorization profile can contain a collection of network policies,
to be applied to the traffic issued from or destined to the entity which was authenticated, such
as:
• accepted / rejected: the entity is recognized or not and therefore is or is not allowed to
use the network;
• an Access Control List (ACL): the list of permitted / forbidden network destinations which
the entity is allowed to exchange traffic with; this list can exist at different network layers,
such as a virtual routing instance, a list of IP subnets, or a VLAN;
• QoS and CAC parameters: bandwidth allowed for each class of service used in the
traffic issued from or destined to the entity;
Note that the policy servers used to store users’ profiles may or may not be integrated with the
policy servers used to control the applications which are carried over the network.
Figure 5: Illustration of Authorization "accepted / rejected" after Authentication
2.2.3.2 Priorization of general use cases for AAA

• Use case 1: Dynamic configuration of the Access Network according to the subscriber
profile
o Use case 1.1 for subscriber authentication: to simplify the provisioning of triple-
play access networks available today

architecture III
IST - 6th FP
Dynamic authentication allows the network operator to perform dynamic

configuration of the AN according to the subscriber profile; in other words it
allows the network operator to avoid any static configuration of the AN related to
the services subscribed to by the customers.
As there will be a daily volume of requests to be handled by network operators,

i.e. from customers who want to subscribe or unsubscribe or modify their
subscriptions, it makes sense to automate the related network configurations.
Using standard protocols to authenticate subscribers and configuring the Policy
Enforcement Point (PEP) accordingly avoids the necessity to know a priori the
associations between subscribers and access ports, and therefore this is more
dynamic than having a static configuration of access ports with subscribers’
related profiles.
To summarise, instead of statically configuring the AN with {subscriber profile;

access port} associations, the idea is to:
• configure {subscriber profile; subscriber Id} associations in a policy server
• let {subscriber Id; access port} associations be established dynamically
during the authentication phase
• and let {subscriber profile; access port} associations be established
dynamically during the authorization phase
o Use case 1.2 for subscriber authentication: to allow for nomadism

The motivation to automate the operation of access networks is even more
obvious if subscribers are moving house frequently, or that users can be
nomadic. In these cases, it would be a considerable overhead for operators to
statically reconfigure access ports every time a user moves, and therefore
dynamic mechanisms are a must.
Note that in some cases it will be useful to independently authenticate and

authorize permanent users of a given access point, and occasional users who
are passing by. This would have to be taken into account when enforcing policies
at the network level: the nomadic user must not disturb or change the network
services received by the permanent users of the same access point.
o Use case 1.3: Authentication of end users who are not subscribers
In the case where the different members of a given family would have different
policies to access the network – some being allowed only a limited volume of
download per month, some being forbidden to access certain network
destinations – it would be necessary to authenticate the end user in order to
activate the policies corresponding to end user's profile, prior to grant access to
the network.

architecture III
IST - 6th FP
However, those kind of use cases like "super detailed billing" or "network-level
parental control", which would require to differentiate individual members within a
family, were considered unrealistic as shown later in section 2.2.3.3, and
therefore were not further developed.
• Use case 2: Denying access to stolen or hacked devices, or allowing only certain device
type
The most basic form of authorization is to simply accept or reject traffic attempting to
enter the network, based on whether or not it was possible to authenticate the entity
which is originating that traffic.
o Use case 2.1 for device type authentication: or allowing only a device type or
denying access to hacked RGW/devices,
In an environment where an operator would provide subscribers with managed
RGWs or devices, and some services would be accessible only by subscribers
who connect through the RGW/device provided by the operator, the operator
may wish to be able to check the following before accepting the traffic:
• Is the RGW/device used by the client really an RGW/device of the type
provided by the operator?
• Has it been modified physically since it was provided by the operator?
• Is it running any other software than that provided by the operator?
The motivation for this is to be able to consider the authenticated RGW/device as

a trusted network entity:
• A possible application of a trusted RGW is where the operator wants to
incorporate some security functions into the RGW, like the functions
involved in a distributed SBC or in a public WLAN access point.
• Another example is where an operator wants to restrict access to a
premium VoD service only to a STB of a certified type and block the
service from being provided to a PC.
Authentication of the device type, possibly combined with other mechanisms to

prevent modifications of its hardware and software, is required to perform this
kind of verification.
o Use case 2.2 for physical device authentication: Denying access to stolen
RGW/devices
A motivation for physical device authentication would be to be able to detect
stolen RGWs or devices and prevent them having access to the network. The
principle is the same as in previous use case: check whether or not the
credentials provided by the RGW/device authenticate an authorised piece of
equipment, and therefore authorize or deny access accordingly.
However, this use case was considered unrealistic as shown later in section
2.2.3.3, and therefore were not further developed.

architecture III
IST - 6th FP
• Use case 3: Authentication used for accounting

o Use case 3.1 for subscriber authentication, in order to charge subscribers
Accounting is required for network operators who charge subscribers based on
their usage of the network – it can for example be per minute like in hotspots, or
per GByte of traffic. In order to know who to charge for the carried traffic, the
network operator needs to authenticate the subscriber prior to starting accounting
for the traffic.
o Use case 3.2 for end user authentication, in order to charge particular
subscribers
In the case where some network services are only to be used by some members
of the family, for example if Dad can have access to his company's VPN for
teleworking and such VPN service is paid by Dad's employer, then it might be
necessary to authenticate the end user to allocate the bandwidth reserved for the
VPN service and to start accounting.
Also, in case a detailed billing were required per end user within a family
(example of pay per use services with a super-detailed bill), end user
authentication by the network operator would be required.
o Use case 3.3 for subscriber authentication in order to charge other ASPs
When different entities play the roles of network operator and service provider,
the network operator wants to charge the service providers for their usage on the
network – it can be per GByte of traffic but it can also be per subscriber who
connects to each of the service providers. Therefore, authentication of the
subscribers might also be used when accounting and charging service providers.
To summarize use case 3, as soon as accounting is based on end users or

subscribers usage of the network, authentication of the end users or the
subscribers is required.
• Use case 4: Legal obligations

Subscriber authentication is mandatory for ISPs, who must be able to know and to
record at all times what IP Address was allocated to what subscriber.
Also for legal interceptions, the operator must be able, when requested by the
authorities, to intercept and duplicate the traffic originating from or destined to some
particular subscribers.
Therefore, subscriber authentication is required for these legal obligations.

architecture III
IST - 6th FP
2.2.3.3 Classification of the use cases by order of priority, and the resulting importance of the different technical features
The following table gives a view on the likelihood of network operators deploying the different use cases in the short term. From this,
the relative importance of authenticating each of the entities is deduced.
Use cases
1.1 2.1
1.2 1.3 2.2 3 4
Dynamic Device Level of
Allow Parental Stolen Charge Legal
network type importance
nomadism control device subscriber Obligations
provisioning (trusted)
Subscriber per
Required Required Required 1
line
Entities required to be
Subscriber per
Required Optional Optional 1
Authenticated
circuit
Subscriber per
Required Optional Required Required 1
RGW
Subscriber per
Optional Required Required Required 2
device
End user per
Optional Optional Required Optional Optional 3
device
Physical device Optional Required Optional 4
Device type Required 2
Order of
1 2 3 2 4 1 1
priority
Table 2: Classification of the use cases by order of priority, and level of importance of the different technical features
Note that what is designed here under the terminology "line" is actually called "access loop" in the DSL Forum terminology. For
instance it could be a copper pair carrying ADSL. Note that what is designed here under the terminology "circuit" is actually called
"logical circuit on the access loop" in the DSL Forum terminology. For instance it could be an ATM VC, a VLAN, a GEM-PORT…

architecture III
IST - 6th FP
As a result of this survey among service providers in MUSE, the following can be concluded:
• Network operators must be able to authenticate the following entities:
o One or more of the following, Subscriber authentication per line, Subscriber
authentication per circuit, Subscriber authentication per RGW and Subscriber
authentication per device, MUST be supported in order to allow dynamic
provisioning of the network according to the subscriber's profile, for
nomadism, as well as for legal matters on Internet access and voice services.
o Devices type authentication SHOULD be supported to restrict access to some
services to devices of a certain type.
• It does not appear to be particularly useful for network operators to be able to
authenticate the following entities:
o End user authentication per device. This would only be useful for detailed
accounting per user, or to implement some kind of network level parental
control.
o Physical device instance authentication. This could prevent stolen devices
from having access to the network; however the management overhead to
achieve this would be huge. However physical device authentication is
required to perform subscriber authentication per circuit in the case of shared
media (e.g. required for GEM-ports allocation in GPON).
2.2.4 Specific requirements for Nomadism

The triple play offering is becoming a commodity amongst many operators in many countries.
The next natural step is adding a degree of mobility to the fixed services. This is sometimes
referred to as quadruple play, i.e. triple play with added support for some form of mobility.
Adding nomadism to the fixed service offering will enable a provider to find new ways of
revenue generation as well as a possible reduction in churn.
From the user perspective, besides enhancing the user experience, it will add the possibility
for a user to access services at places other than his home location. This will provide access
to services according to the user service profile, authentication and authorization for access
services and location.
2.2.4.1 Services and Providers

Nomadism should not be regarded as a service on its own, but rather as a feature of some
other service (e.g. a nomadic IPTV service). To better understand what nomadism is, it is
necessary to start with the end user services it is tied to.
The following figure shows different types of service relevant to the discussion on nomadism,
and their relation to the different business roles.

architecture III
IST - 6th FP
Application Application Service

Services Provider
L2/L3 Connectivity Connectivity

Services Provider
Access Link Network Access

Services Provider
Figure 6: Service reference model
2.2.4.2 Nomadism scenarios

Nomadism implies ubiquitous access to subscribed services. This could include:
• Access from the primary residence (home).
• Access from a secondary residence (e.g. summer house).
• Access from a neighbour’s or friend’s residence.
• Access from the office.
• Access using public access (e.g. WiFi hot-spot)
• Access using the mobile/cellular network.
It must also be noted that in these nomadism scenarios, more than one player may take on
the different roles. For example, the NAP connecting the summer house or hot spot may not
necessarily be the same as the one providing access to the home (primary residence). This
implies some kind of “roaming relationship” between the providers.
However, in most scenarios it is essential that service can be obtained from the same service
provider (ASP and/or CP) no matter where the user/device connects.
2.2.4.3 Conclusions on authentication requirements for nomadism

• The user or device must be able to exchange his/her credential information with the
network, both for services that rely on PPP and services that rely on DHCP.
• The Regional / Access Network Provider / Network Service Provider, potentially after
exchanging information with other players, must be able to correlate each user/device
IP address authorized on the network with the identity of a subscriber, and particularly
to the credential information given by this user/device at authentication stage.

architecture III
IST - 6th FP
• The AAA architecture must allow service-specific network level authentication in order
to dynamically perform the necessary authorization between the customer and some
existing and predefined network resources, according to the customer’s service
subscription profile returned by the authentication server/AAA servers while
processing the customer's authentication.
• The AAA architecture must allow the different actors involved to interact properly so
as to allow controlled nomadism for a user connecting from different places in the
home access network, or from a visited network.
• The AAA architecture must allow the different actors involved to interact properly so
as to control roaming for a user connecting or from a visited network.
2.2.5 Outputs to standardization on AAA

According to the study results described above on AAA, MUSE made three contributions to
the DSL Forum WT-144:
• Contribution dsl2005.810 proposed AAA mechanisms based on the AN as a PEP.
• Contribution dsl2006.341 introduced AAA requirements for Nomadism.
• Contribution dsl2006.627 provided a prioritization of AAA related requirements
according to the above analysis of general use cases.
2.3 IP sessions
IP Sessions is a concept which is being developed in DSLF (WT-146), to allow session
control in the absence of PPP. There are several reasons for wanting to move away from
PPP; these include managing individual session packets as close as possible to the edge of
the network without requiring tunnelling it to a centralized point, hence optimizing traffic
distribution in the aggregation network. Moreover, PPP is also usually tightly linked to the
underlying physical topology, and imposes some constraints on backhaul network
architecture.
Replacing PPP is however not that simple. PPP provides an efficient way to authenticate the
end-user, to provision network parameters (host IP Address, DNS, gateway) and to monitor
the session state by using LCP Echo messages. The work conducted within MUSE on IP
Sessions mostly focused on the ways to provide the same level of service provided by PPP.
Four contributions resulting from this work were presented to the DSL Forum:
• dsl2006.127: DHCP relay improvements.
• dsl2006.392: Requirements for IP sessions in WT-146.
• dsl2006.628: ICMP as a mechanism for IP Sessions Monitoring in WT-146.
• dsl2006.671: Requirements for IP Sessions Monitoring in WT-146.
2.3.1 Requirements for IP sessions in WT-146 (dsl2006.392)

The purpose of IP sessions is to provide a means to the service provider to handle each
subscriber according to their individual service contract, in particular in terms of traffic
handling and access rights. This contribution considers several functional requirements
which arise from this, and aims to clarify the different possibilities for associating sessions
with identities and policies.

architecture III
IST - 6th FP
In order to derive the functional requirements, a set of desirable uses of IP sessions was
agreed upon, which shows similarities with the possibilities offered by PPP. These include
AAA, service selection, per-session configuration of ACL, filters and QoS profiles (both for
unicast and multicast traffic), IP anti-spoofing and basic nomadism. Extended mobility
(session continuity, session mobility) is an additional use (currently provided by PPP), but
this requires more investigation.
The functional requirements deduced from these uses are that the IP session-aware network
must support mechanisms to:
• Recognize the session and monitor its existence.
• Perform authentication in order to be able to associate an identity with the IP session.
• Enforce individual policies on individual sessions based on the profile of the identity
associated with the IP session.
• Link the IP address (dynamically allocated address or static address) with a
subscriber identity (recognized during authentication) in order to be able to control the
consumption of IP addresses, and to associate a subscriber identity to an IP session.
• Support nomadic users.
Once IP sessions are created, they must be categorized, in the sense that they must be
associated with a particular identity. In order to do this, one identifying parameter or a set of
such parameters can be used. Although the distinction between different sessions is
determined only by the IP address, more parameters can be used for identifying a session.
The different possible associations for a session are:
• Association with a circuit or a line
• Association with an individual device or device type
• Association with an individual person, being either the Subscriber (owning contract
with service provider and/or network provider) or the End-user (using the service, not
necessarily the actual subscriber)
• Association with a service provider
Once the IP session is created, policies may need to be enforced on the IP session..
Authentication is a special case of a policy, as it will determine what a session will be
associated with (as described above). Different network level authentications are possible in
principle:
(1) subscriber, (a) per-circuit or (b) per-line
(2) subscriber, (a) per-RGW or (b) per-terminal behind the RGW
(3) end-user, per-device
(4) physical device
(5) device type
Note that there is not necessarily a one-to-one relationship between an IP session and an
authentication process result; it can be the case of having a one-to-one relationship like in
(2b), (3), (4), (5), or having multiple IP sessions on a line, which would be considered
authenticated by a single authentication process, like (1), (2a), or having an IP session
authenticated by a combination of several independent authentication results, like for (1)+(3).
Once authentication is performed, and the IP session is associated with a (set of)
identifier(s), the other policies (authorizations, QoS settings etc…) can be enforced based on
the profile linked to that identity. Accounting can also be performed.

architecture III
IST - 6th FP
Finally, two illustrative use cases are described in the dsl2006.392 contribution, showing the
benefit of the awareness of IP sessions for basic AAA actions and for IP anti-spoofing.
2.3.2 The Challenge of IP Session Monitoring

There are currently several access protocols to perform authentication, some are based
upon a standardized and widely adopted protocol1 such as EAP. However not all of these
support session monitoring:
• PPP: keep-alive through LCP Echo packets
• PANA: monitor PANA sessions through PANA-ping messages
• 802.1x: no mechanisms to perform session monitoring
To provide a more generic way of session monitoring, the protocols normally used with IP
were considered:
• ARP: Even when relying on Ethernet at layer 2, ARP is required to identify the next
hop;
• DHCP: By requesting an IP address and tuning the lease timer, one might recreate a
regular checking process;
• ICMP: This widely adopted protocol was devised to check IP connectivity;
• BFD: Still being specified at the IETF, Bidirectional Forwarding Detection is a generic
monitoring protocol that can be used in networks from the edge to the core.
At first, DHCP was studied within MUSE, and contribution dsl2006.127 (DHCP Relay
Improvements) proposes to tie in a more efficient manner DHCP to the RADIUS (AAA)
process in order to apply specific and individual policies (QoS) to the relevant IP Session. It
also proposes creating a pseudo keep-alive mechanism by introducing the notion of an
asymmetric lease, already presented to the DSLF in 2005 (dsl2005.255). The asymmetric
lease mechanism is based upon the DHCP relay capability to obtain a global lease time and
to split it in multiple (smaller) lease times to be provided to the end-user. This way, any
connectivity disruption is detected at a lower granularity, giving the opportunity for the DHCP
relay to send an accounting message to the AAA platform. However, the idea of using DHCP
as a realistic keep-alive mechanism did not achieve consensus among the DSL Forum
Architecture and Transport attendees, and so the work presented below focused on ICMP
and BFD.
2.3.3 ICMP as a mechanism for IP Sessions Monitoring in WT-146

(dsl2006.628)
Almost every IP host implements ICMP, and this protocol is designed to check IP
connectivity. ICMP is today the most commonly used method to monitor IP connectivity.
The ICMP session keep-alive mechanism is already described in WT-146 but it is optional
since it is not considered sufficiently reliable for a network operator. Contribution dsl2006.628
analyses the issues related to using ICMP as a protocol for monitoring IP sessions and
proposes a solution to overcome these issues.
1
Not in current DSL scenarios.

architecture III
IST - 6th FP
2.3.3.1 Known issues with ICMP

The obstacles to using ICMP as a protocol for monitoring IP sessions come from security-
related configurations on IP hosts:
• Some CPE are configured not to respond to ICMP requests on their WAN interface,
in order to avoid being detected (at least on that port) from the Internet and therefore
to avoid malicious attacks like ping-of-death.
• Some operator's equipment (BNG, firewalls, servers) are also configured not to
respond to ICMP requests for security reasons.
Whatever the reasons are for implementing such restrictions, they make ICMP-based
monitoring difficult in the following scenarios:
• If there is IP traffic activity it means the IP session is up.
• If there is no IP traffic activity but ICMP response is received it means the IP session
is up.
• If there is no IP traffic activity and no ICMP response is received it means nothing;
therefore in that case tearing down the IP session will have to be triggered by a timer,
which is not an ideal solution (session termination detection timers have an impact on
accounting load and/or accuracy: if the quiet period is too short, accounting
messages will be numerous and auto re-configuration of the terminal will be required;
if too long, accounting messages will be inaccurate).
Since it is an objective to avoid the last case, it is necessary to "force" the IP hosts to
respond to the protocol chosen for the monitoring of the IP sessions.
2.3.3.2 Solution proposed to overcome these issues

In order to make sure (or at least to improve the chance) that IP hosts will respond to ICMP
requests when used for the monitoring of IP sessions, it is proposed to add a new option to
the DHCP protocol in order to provide DHCP clients with a list of IP addresses which can be
used as ICMP peers for monitoring the IP session.
Standardization of this option should take place at the IETF.
2.3.3.3 Rationale for the solution proposed

Many IP hosts already in the field today do respond to ICMP requests, and the objective is to
allow the rest of the IP hosts to have also their IP session monitored using the ICMP
protocol.
As an alternative to defining a new DHCP option, the default-gateway (conveyed to DHCP

clients via the existing option 3 of the DHCP protocol), could be used to check whether the IP
session is still ok, using the ICMP protocol. The proposal to use a new option X of the DHCP
protocol is however more generic than option 3; it may contain the default gateway, but also
other IP addresses, allowing for end to end monitoring of the IP session from a service
platform for instance.

architecture III
IST - 6th FP
Security limitations:
The proposed solution makes the use of ICMP for session monitoring more secure, by
preventing for instance an IP host on the Internet from scanning IP addresses using the
ICMP protocol. However, the proposed solution would not prevent an IP host on the Internet
spoofing one of the IP addresses contained in the list {X}, in order to attempt a DDOS attack
on operator's equipment. But such a DDOS attack is quite difficult to perform, as ICMP
replies would not get back to the hacker, the hacker is blind and cannot use ICMP for
scanning subscriber IP addresses. Also, such an attack provides limited benefit from the
hacker’s point of view, as it cannot used to steal anything but only to annoy the operator.
Therefore, the remaining risk should not be very significant.
Choice of IP addresses to be part of list {X}:

• It might be useful to provide the address of the BNG in the list {X}, as some CPEs
may not accept ICMP requests even from their default-gateway.
• In some cases, testing the IP connectivity between CPEs and BNGs may be
sufficient; In other cases, it may be necessary to test end to end IP connectivity with a
service platform higher in the network for instance, so the list {X} may contain both IP
addresses from the same subnet as the CPE, as well as IP addresses from different
subnets.
• When several IP addresses are provided to the CPE, it is expected that the CPE
would, in the absence of IP traffic, check if at least one of these IP addresses
responds to ICMP, so that if an operator's equipment in list {X} happens to be down,
the subscribers IP session can still be monitored using other operator's equipment
from list {X}.
2.3.4 Requirements for IP Sessions Monitoring in WT-146 (dsl2006.671)

This work provided inputs and related requirements for the possible use of BFD with IP
Sessions. The main themes discussed focused on:
• Backward compatibility with existing RGWs;
• Adapting BFD configuration to RGW and IP Edge Device roles and respective
requirements;
• BFD and security.
Based on these themes, we proposed a set of requirements for WT-146 about BFD
configuration compared to parameters proposed in the previous propositions mentioned
above.
It is important to note that the requirements proposed here are only suitable in the case
where IP Session monitoring in the network is realized in the forwarding plane, i.e. in the IP
Edge Device (like the BNG for instance). One might consider that IP Sessions could be
monitored from an external platform, but this case is not developed in this document.

architecture III
IST - 6th FP
2.3.4.1 Backward compatibility

The proposed approach here is to make IP traffic detection the primary method for IP
session “liveness” detection, with recommended (but optional) use of an additional
monitoring protocol such as BFD. Then, it is up to each operator to decide whether support
of a monitoring protocol such as BFD is mandatory or not. Subscribers with non compatible
RGWs may have a possible workaround: the user's remote device (such as a PC) can run a
keep-alive utility to generate IP traffic and maintain the IP session, or can even activate BFD
if it is connected to the network via a layer-2 RGW.
2.3.4.2 Adapting BFD configuration to RGW and IP Edge Device

It is important to keep in mind that IP session monitoring is not required for the same purpose
on RGWs and IP Edge Devices:
• RGW: IP session monitoring is useful to determine whether the IP connectivity, and
corresponding configuration (assigned IP address, Gateway, etc.) is still valid. In the
case of IP session failure, BFD can provide the necessary trigger to restart a DHCP
exchange or to restart applications. This is useful when the operator changes the IP
configuration of its network equipment, because the RGW can reconfigure itself
without manual reset.
• IP Edge Device: IP session monitoring is useful for the network operator to manage
its IP resource, and to generate appropriate accounting information, for logging or
billing.
Because of these different needs, the appropriate monitoring solutions might be different.
For the RGW, the matter is not really on the formal relationship between the RGW and the
network operator. Instead, what matters is the ability for the RGW to communicate with NSP
equipments, such as IPTV or VoIP platforms. For this reason, applicative keep-alive
mechanism related to the service can be used to check IP connectivity. IP Session
monitoring can be helpful to quickly detect a communication failure with the IP Edge Device
and notify the end-user, but is not sufficient to ensure service continuity. On the other side,
RGW applicative connectivity mechanisms may not have adapted mechanisms to detect
whether the IP stack needs a reset or not.
It is important for the IP Edge Device to drive the IP session monitoring process with the
RGW, as long as the operator is responsible for accounting.
When an operator decides to use a protocol such as BFD for IP Session monitoring, it is the
responsibility of the operator, to ensure that the BFD session is properly established between
IP Edge Device and RGW. It is also preferable to let the IP Edge Device manage its system
resources to handle bursts of BFD sessions establishment requests, after an IP Edge Device
reboot for instance. Nevertheless, an RGW running BFD in passive role still benefits from all
BFD features as soon as the IP Edge Device establishes the BFD session. Depending on
local policies, the RGW should be able to run in Active mode if the IP Edge Device is
configured to accept incoming requests (not in AdminDown state).
So far, no strong requirements have been identified for using BFD in Asynchronous mode.
Globally, ‘Demand’ mode seems to be more adapted for IP Session monitoring due to the
following reasons:

architecture III
IST - 6th FP
• As mentioned above, enabling a mechanism which monitors connectivity from both

sides with an identical method is not required, since RGW and IP Edge Device do not
share the same requirements;
• As long as upstream traffic is coming through the IP Session, regular BFD Control
Packets sent in Asynchronous mode are not required;
• Enabling Asynchronous mode imposes some constraints on Control Packets
frequency in the IP Edge Device, which might not be acceptable for the network
operator depending on negotiation results with the RGW. The BFD IETF draft states
that Control packets do not need to be sent when Demand mode is activated on both
sides of the session.
2.3.4.3 BFD and Security

BFD has some inherent security issues that have to be addressed for it to be useable in a
public IP network:
• BFD Control packets for a BFD Session can be sent from an IP Source address,
which does not correspond to the IP Source Address of the BFD peer. It might be
desirable to define a specific BFD application in which IP Source address has to be
considered as a valid de-multiplexing element.
• The BFD IETF draft states that BFD Control packets are de-multiplexed using the
"Your Discriminator" field only by default and by other parameters during BFD
Session establishment phase (these parameters are not specified in the BFD IETF
draft). Even though this field is a 32-bit random number, it is still possible for a
malicious user to calculate ‘bfd.LocalDiscr’ values for the IP Edge Device or the RGW
if the random algorithm is known. Thus, a DoS attack is possible by forging Control
packets and stealing BFD sessions.
• Like ICMP, BFD packets can be sent from an RGW to another RGW. BFD should not
be seen as a threat like ICMP, and hence it should not be blocked by firewalls in the
future.
Implementing security with BFD (by activating the Authentication option) is the most reliable
solution, but can become an operational burden, because it means static provisioning of
secret keys or passwords on both sides, or because it may require a link with AAA platforms.
Using BFD authentication with individual secrets/passwords between RGWs and IP Edge
Devices requires a method to build the link between the IP Session to monitor and the
Authentication server managing the IP Session owner. This Authentication server could be
solicited at the time of IP session establishment to get the secret/password to use between
the RGW and the IP Edge Device. Every BFD packet would make use of the Authentication
field according to this secret/password.
Security threats are different for the RGW and for the IP Edge Device:
• RGW
During session establishment phase the "Your Discriminator" field is empty: it is
required to rely upon another parameter to check incoming BFD packets. The RGW
can check the IP Source address used by the IP Edge Device to send BFD Control
Packets: the IP address must correspond to the default gateway IP address
configured for this interface. This gateway IP address can be statically assigned or
configured through DHCP prior to BFD session establishment.

architecture III
IST - 6th FP
Since the IP Edge Device is in charge of session monitoring and located only one IP-
hop away from the RGW, the RGW must drop any BFD packet with a TTL other than
255.
• IP Edge Device
Since the BFD Session is strongly tied to the IP Session, it is appropriate to use the
IP Source address of the incoming BFD Control packet as a valid discriminator. Then,
the BFD IP address must match the IP address used by the IP Edge Device to
identify the related IP session. Using the IP Source address field of BFD control
packet is also helpful to increase security, making BFD session theft from another
RGW more difficult assuming that IP anti-spoofing is activated.
2.3.5 IP Session monitoring: still under investigation

At this stage, there are several IP Session monitoring mechanisms under consideration, and
there is no wide agreement on which method to use. A possible approach would be to use an
existing protocol such as ARP or ICMP for session monitoring in the short term, targeting
BFD as the longer term solution.
2.4 CAC as a resource management tool

Possible CAC solutions for a generic Access Network architecture are described in this
section. CAC solutions for both unicast and multicast based services are discussed and the
results, which have been submitted as two separate contributions to the DSLF during the
September 2006 meeting in Athens, are presented. The requirements for QoS can be
summarized as follows:
• The need to be able to offer absolute QoS guarantees for some services.
• The need for multiple service edges. There are several different types of service
edges in addition to BRAS, for example video servers (already covered to a degree in
TR-101), soft switches, and PE routers. Typically the services associated with these
edge nodes do not go via the BRAS (for scaling and reliability reasons), and so there
is no longer a single point of QoS control.
• The need for resilience, with automatic switchover, at least for some but maybe not
all services. Note that this may also limit the system link loading which may have an
impact on QoS.
• The need to add upstream QoS control, to support services like quality VoIP, video
telephony, etc.
• The need to support a retail/wholesale split in the business model.
• Efficient point-to-point connectivity for business services: This may involve traffic to
turn around prior to the Edge Node, i.e. at the Access Node or in the aggregation
network.
• The possible need to support or control residential peer to peer traffic.

architecture III
IST - 6th FP
2.4.1 Analysis of access network potential bottlenecks

The aggregation network is comprised of multiplexers, where upstream traffic from multiple
nodes is aggregated into one (or more) uplink(s) and, conversely, downstream traffic is
distributed into multiple downlinks. The sum of the physical layer capacity from the ANs can
exceed the aggregate uplink capacity and so give rise to an upstream bottleneck. However, a
downstream bottleneck can also occur either because the downstream traffic is not uniformly
distributed across all the downstream links, or because the limit is set not by the physical
layer capacity, but by a bandwidth product.
Upstream and downstream congestion is possible at Access Nodes, Aggregation Nodes and
Edge Nodes. The solutions proposed in this document, addresses the issues at all these
potential bottlenecks and largely focus on congestion avoidance by means of CAC. Note
however that not all services are session based or use signalling. Therefore CAC alone
cannot solve all QoS issues and additional mechanisms will be required. These are not
described in the current document.
2.4.2 Definition of Call Admission Control (CAC) techniques

The term CAC as used in this document means accepting or rejecting a session request,
based on the availability of network resources for the QoS class applicable to that session.
Signalled CAC refers to the case where signalling is used to request network resources
prior to the session being started. The session or call is allowed or blocked based on the
availability of resources for a particular QoS class.
Non-signalled CAC is defined as meaning a CAC request is not made by the end-device but
by some other network element after detecting traffic classified as a new session of a given
service.
On-demand CAC means that the CAC decision is based on calculating the current usage
and availability of network resources for the requested QoS in real time. On-demand CAC
can support requests (from either end-devices or network elements) that are heterogeneous
in the sense that the calls need not have the same QoS parameters.
Pre-provisioned CAC refers to the CAC process where decision is simply made on the
basis of the number of accepted requests, which must not exceed a previously specified
number (i.e. a threshold). Pre-provisioned CAC supports only homogeneous calls, i.e. those
having the same network requirements, since only the number of accepted calls is counted.
A central CAC system has a complete view of the resources of the appropriate parts of the
Network. For each and every call (signalled) request or (non-signalled) detection, the central
CAC system is consulted, which depending on the availability of the resources decides either
to allow or block the requested call. This decision is sent to the boundary node (the Access
Node or the Edge Node) where enforcement may be done.

architecture III
IST - 6th FP
A local CAC system (meaning local to a given node) is where the CAC decision is made at
the RGW, the Access or Edge Node. For a CAC decision to be made locally, it is necessary
that there is a local view of the availability of network resources that are exclusively available
to that border node. This naturally leads to a reduction of the potential multiplexing gains that
could be obtained, as unused resources allocated to a given border node can not be used by
another border node. In order to avoid this, partitions should be updated on a regular basis
by a central authority that had an historic and global view of network resource usage. Further
refinements of the local CAC are possible, with the introduction of usage thresholds in the
allocations of a given resource to different border nodes.
2.4.3 Proposed CAC solutions for unicast traffic

2.4.3.1 Selective CAC at certain network locations
To avoid scalability and complexity problems, signalled CAC is limited to a subset of
services, and especially to those parts of the network where the network operator has
identified a potential dimensioning problem. Traffic engineering (i.e. the provisioning of virtual
pipes) can be used to segregate the network resources into:
• One set of resources that can be used by services without an on-demand or signalled
CAC process. For best-effort traffic, which has no QoS guarantees, there is no CAC
needed with respect to the usage of network resources.
• Another set of resources for which signalled CAC is needed on a call/session basis.
Note that a given pipe can either be completely dedicated to traffic subject to CAC or,
in order to improve network utilization, may be shared between CAC and non-CAC
traffic. In the case of sharing, then prioritization mechanisms will be required in
addition to CAC. Depending on the network architecture and dimensioning, CAC may
only be needed for certain links within an end to end path.
2.4.3.2 Concurrent local and central CAC

Additionally, network resources can be segregated such that access to some segments of
the network resources can be controlled locally at the border of the network (Access / Edge
Nodes). Access to these segments of network resources is then only controlled locally at one
node. Access to the other segments, which are shared between many border nodes, can
then be controlled by a central CAC system.
2.4.3.3 Proposals for policy enforcement

The proposals for policy enforcement are:

architecture III
IST - 6th FP
• Flow based enforcement at Access Nodes and aggregate based enforcement at

Edge Nodes: after a CAC decision is made, enforcement of the allowed QoS policy
(bandwidth, QoS class, maximum size of packet, etc.) may be required so that
misbehaving flows do not impact the QoS of the other flows. Total protection can only
be provided if enforcement is done on a per flow basis. However it is recommended
that policy enforcement be done on aggregate of IP flows where possible to lower the
processing power required at the nodes. This will not prevent a single misbehaving
flow from impacting the aggregate, but will limit any damage to that aggregate, which
in some cases may simply be the sum of the bandwidth allocated to an individual
access line. Policy enforcement on aggregate IP flows could be based on aggregate-
IDs, such as VLANs, traffic classes or other suitable IDs. Policy enforcement on
individual IP flows could be based on either a L2 parameter or the IP tuple. The
preferred choice of the flow ID for enforcement is the IP tuple. In general,
enforcement of individual IP flows may be more practical at Access Nodes, with
aggregate flows being used at Edge Nodes. This will lower the processing power
requirements at Edge Nodes.
• Policy enforcement for upstream traffic at Access Nodes instead of at Edge Nodes:
For the upstream traffic, it is recommended that the policy enforcement be done at
Access Nodes. This will minimise the chances of misbehaving flows altering the QoS
of other flows in the aggregation network. After the CAC decision, the QoS policy has
to be made available at Access Nodes (either sent from the central CAC system or
available locally in case of having local or non-signalled CAC).
• Policy enforcement for downstream traffic: In addition to the aggregate enforcement
at the Edge Nodes for downstream traffic, it is recommended to have flow-based
enforcement at the Access Node to prevent congestion of the first mile. Per line
enforcement (or shaping) is commonly done at the BRAS in current architectures.
However this is no longer viable in a multi-edge architecture. The only point where all
the traffic for a given line comes together may be the Access Node itself.
2.4.4 Proposed CAC solutions for multicast traffic

Multicast is generally used for TV broadcast types of services, where the number of TV
channels offered to customers is greater than the number of channels that can be
simultaneously carried over the access network (due to either physical layer or bandwidth
pricing reasons) and where at least some channels will be watched by more than one user
on a given Access Node at the same time. The risk of congestion and degradation of QoS
can be high and measures are needed to prevent or minimize the effect.
2.4.4.1 Definition of Admission Control for multicast

Admission Control for multicast refers to the process of either accepting or rejecting a new
multicast flow using the availability of bandwidth as a criterion. Similar to unicast flows, once
accepted by the Admission Control, a multicast flow should not suffer from degradation due
to network congestion.
2.4.4.2 Per-link thresholds (static)

An upper threshold value for multicast traffic is defined for each link, and a local control
mechanism is implemented on that link to keep the volume of multicast traffic within the
allowed threshold. The threshold can be one of the following:
• The number of multicast flows that can be supported on the link

architecture III
IST - 6th FP
• The volume of multicast traffic that can be supported on the link
When new multicast flows are requested and if the resulting multicast bandwidth exceeds the
configured bounds, this local mechanism would block every new multicast flow until the
volume of multicast traffic decreases below the threshold. The control mechanism can either
operate on all the multicast flows of a link, or on a per-bundle basis. The idea of “bundles”
can be useful to manage multicast flows that have very different bandwidth characteristics
(for instance, a bundle of radio channels, TV channels and HDTV channels).
2.4.4.3 Per user thresholds (dynamic)

To enable more service flexibility multicast as a service is tied to user authentication. Based
on these user attributes, which are located globally at a policy server, the local CAC function
can be controlled by the PDP, which is usually the BRAS or the BNG. For controlling the
network elements, the AN and the BRAS or the BNG need to interact. This connection
provides information about the actual line condition from the AN towards the BRAS/BNG.
Based on this information and the decision at the PDP the result is communicated to the
local CAC residing at the AN.
2.4.4.4 Real-Time constraints of multicast Admission Control

The Admission Control for multicast flows must be sufficiently fast to avoid the user
perceiving extra delay in the zapping process. This means that the decision to accept or to
reject a new multicast flow on a link should be taken by the network equipment connected to
that link, which in turn needs a distributed approach to multicast CAC. Each network node
should make policy decisions for multicast flows using policy rules defined locally and
updated by an external system.
2.4.4.5 Mechanisms to allow or block a multicast flow

In IGMP based multicast flows, IGMP messages can be used to either accept or reject a
request, depending on the Admission Control decision, by forwarding IGMP requests or just
discarding them.
Other mechanisms are needed for multicast flows not based on IGMP. For instance the
mechanism could be based on the analysis of IP packets with multicast destination
addresses, as follows:
• Packets with a multicast IP destination address would be always accepted if the flow
already belongs to a list of allowed multicast flows.
• Packets with a new multicast IP destination address that do not belong to the list of
allowed multicast flows would be accepted only if the multicast traffic is under the
threshold defined for multicast on the link. In that case, the new flow is added to the
list of allowed flows.
• When the multicast traffic reaches the threshold, packets with a multicast address
that do not belong to the list of allowed flows would be dropped.
• A flow for which no packet has been received in a given period of time is considered
as completed and removed from the list of allowed multicast flows.

architecture III
IST - 6th FP
2.4.4.6 Bandwidth determination of multicast flows

Bandwidth of IP flows is the most important parameter for providing QoS: appropriate
bandwidth needs to be reserved for that flow if sufficient bandwidth is available; otherwise,
the start of the flow must be blocked. Extending the unicast CAC approach to multicast
raises a multitude of technical questions, in particular:
• The bandwidth used by a multicast TV channel is not indicated in IGMP messages.
However, the bandwidth information associated with a multicast channel will be held
somewhere in the system, since it is normally defined as a part of a contractual
agreement between the network operator and the broadcast channel provider.
• Broadcast providers usually have a contractual agreement for the distribution of
bundles of channels, not for individual channels. The total bandwidth used by the
bundle is contractually defined with the network operator, but the bandwidth of each
channel remains unknown, and can vary over time within the bundle. The bandwidth
used by the bundle is constant, but the bandwidth of every individual channel can be
variable in time, even if it remains under a known peak bandwidth.
• Multicast flows do not always have constant bit rate. Depending on the coding, some
audiovisual flows can be highly variable. In addition to this, multicast can also be
used for data distribution, which could make multicast flows very bursty.
One possible solution for the problem of obtaining bandwidth information for individual
multicast flows would be to use aggregate bandwidth figures. The aggregate bandwidth can
be measured in real time to obtain the global amount of multicast traffic on a link. If the
measured volume exceeds the threshold, then requests for new flows will be rejected.
However, there are some issues that need to be addressed, such as:
• How to prevent the risk of having flows that were admitted while having a low
bandwidth, and whose bandwidth suddenly increases, leading to congestion.
• How to treat multicast flows that are dependent one another, i.e. how to be sure that
a terminal that needs several multicast flows at the same time will receive all of them
and not just a subset which would be unusable.
2.4.5 Integrated resource management for audiovisual flows (unicast and

multicast)
For sharing of resources between unicast and multicast flows, a tight interaction is needed
between the unicast and multicast CAC processes. This can be done as follows:
• There is a global resource management that has a view of all resources used in a
network, both unicast and multicast. This global resource manager can decide
whether a new unicast flow can be accepted or not, or whether the threshold allowed
for multicast traffic on a link could be increased or not.
• A local mechanism embedded in the network equipment keeps the amount of
multicast traffic under a predefined threshold. The central system would get periodic
feedback on the use of the multicast bandwidth, and thresholds could be adjusted in
non real-time (subject to any contractual agreements).

architecture III
IST - 6th FP
2.4.5.1 Statistics report from local control mechanism

The local control mechanism has to regularly report local traffic information to external
systems, in order to aid to take decisions about traffic engineering changes, like
modifications of the thresholds allowed locally for multicast. These statistics can include:
• Number of multicast flows blocked in a period of time.
• Peak volume of multicast traffic observed on the link, globally or per bundle.
• Peak number of multicast flows observed on the link, globally or per bundle.
• Multicast packets lost due to congestion.
Statistics can be pushed by the network equipment to an external system, or regularly pulled
from that external system.
2.4.6 Conclusions on CAC

In order to control the amount of multicast traffic over a network, and to avoid entering into a
congestion situation due to an excess of multicast traffic, it is proposed to investigate a local
multicast Admission Control mechanism embedded in network equipment that should have
the following characteristics:
• It guarantees that the amount of multicast traffic on a network link remains under a
predefined threshold.
• As long as the amount of multicast traffic remains under a predefined threshold, new
multicast flows are accepted on the link.
• If the multicast traffic reaches the threshold, the requests for new multicast flows are
rejected until the multicast traffic decreases below the threshold.
The local control mechanism regularly reports statistics to an external bandwidth manager,
and these statistics will aid taking engineering decisions like increasing or decreasing the
threshold for multicast flows according to the actual needs.
Additionally, there should be interaction between the CAC methods for unicast flows and the
CAC methods for multicast flows, especially when sharing resources between the two types
of flows, which should have the following characteristics:
• A global resource management that has a view of all resources used in a network.
This global resource manager can decide whether a new unicast flow can be
accepted or not, or if the threshold allowed for multicast on a link can be increased or
not.
• A local mechanism embedded in network equipment for multicast flows, such that this
local mechanism is able to keep the amount of multicast traffic under a predefined
threshold and can take the appropriate decisions to prevent congestion due to an
excess of multicast flows.

architecture III
IST - 6th FP
3 MULTIMEDIA IN ACCESS
3.1 Introduction
The second phase of the IST MUSE project builds further on the two architectural network
models developed during the first phase. One of the main objectives is to enrich the MUSE
Ethernet and IP network models with new capabilities to efficiently support and offer new
Broadband services. Another task force (TF1.8) is considering the impact on MUSE
architectures of supporting Fixed Mobile Convergence (FMC).
TF1.7 identified and selected two tracks to enable Broadband Multimedia support in Access:
Service Enablers and Quality of Experience (QoE).
The Service Enablers track is a continuation of the groundwork performed during phase 1
and described in DA2.4 part IV (see [3]). Service Enablers may be defined as the extra
capabilities that are introduced in a network to generate new revenues to the providers by
providing explicit support for certain services. This may be realized by adding value to the
network itself, for instance by integrating intelligence and higher-layer services (operating
above L3) in Access and Aggregation networks (Access node, Aggregation node or Edge
node). The “Service Enablers” section of this document is dedicated to the study of
distributed architectures in which the functions of the “Session Border Controller (SBC),”
usually located centrally in the Service Provider Network domain, are distributed into the
Access Nodes of the Network Access Provider. Different business models are identified and
their impact on the MUSE IP network model is analyzed. In the longer term, some functions
of the SBC could even be pushed further into the Residential Gateway (RGW). The second
section of this part considers the functions that are candidate for further distribution and
studies the general impact on the MUSE architecture, its security, and its cost.
The second track introduced in the second phase of MUSE investigates Quality of
Experience (QoE) The state of the art and some general considerations about QoE are first
analysed in the third section before studying in more details the QoE for selected categories
of application: Gaming, Video (IPTV, VoD), Best effort Internet and Multimode multiparty
applications. The interest of operators in QoE was determined (in particular for Video (IPTV))
via a questionnaire. The ultimate objective is to identify means to improve the quality of
applications experienced by end-users and again, to deduce the impact on the MUSE
Ethernet and IP network models. The work on QoE has already resulted in several
contributions to DSLF WT126.
3.2 Distribution of intelligence to the access node

3.2.1 Motivation
This section explains the motivation to distribute Session Border Controller features into the
access. It gives first an introduction on the importance of SBCs, their location in a reference
Next Generation Network architecture and a brief description of their main features. Then a
new, distributed architecture is proposed for different business models and the
corresponding advantages over the reference architecture are highlighted.

architecture III
IST - 6th FP
With the arrival of Next Generation Networks (NGNs) and the IP Multimedia Subsystem
(IMS), and with the recent evolution of ETSI/TISPAN standards, the role played by Session
Border Controller (SBC) in the newly specified advanced network architectures is expected
to become crucial.
Figure 7 illustrates a simplified high-level overview of the most recent architecture of Next
Generation Networks as deployed today. The retail scenario illustrated involves a single
operator (green) delivering both network access (as Network Access Provider, NAP) and
multimedia services (as Application Service Provider, ASP). End users receive an IP address
belonging to the domain of the NAP to access to the services provided by the (green)
operator.
A Session Border Controller will typically be installed at the edge of the ASP backbone in
order to isolate and to protect the backbone network of the ASP containing all the critical
servers (applications, AAA, ACS, ...) from the rest of the world.
Link with IET F S IP IM S T IS P AN

SIP p ro xy server
CPN S-C S C F
S X: o r B2B U A
I-C S C F
CPE (+re g istra r)
P -C S C F
BC : B2 BU A
SP D F
EN SBC located at edge and consisting of:

Ethernet (router) -ABG Media
AN aggreg. NW NAP/RNP -BC Signaling & Control
Application
Server
CPN
BC
CPE Sx
ABG
#1
Ethernet
EN
aggreg. NW (router) ASP1
AN ASP backbone
NAP/RNP
IP@ in SubNet 1 (e.g. retail)

Addresses that will appear as S or D of messages
Media The NAP owns geographically dispersed
PSTN Gateway
A&A networks
SS7
Figure 7: Simplified NGN reference model
The central Softswitch (SX) element was originally introduced in telephone network
architectures to connect calls from one line to another, entirely by means of software. Simple
NGN for VoIP uses media gateways and a central Softswitch that fulfils the functions of a
Call Agent. The Call Agent takes care of functions like billing, call routing, signalling, call
services and so on. A Call Agent may control several different Media Gateways in
geographically dispersed areas over a TCP/IP link. Control signalling may also be sent over
UDP or STCP. The Media Gateway connects different types of digital media stream together
to create an end-to-end path for the media (voice and data) in the call.

architecture III
IST - 6th FP
Today these functions correspond to those of a SIP proxy server or a Back-to-Back User
Agent (B2BUA). Softswitches also fulfil the role of registrar servers to which end users will
connect. They are used in conjunction with databases in order to provide location services,
allowing management of the location of end users that may connect from different locations
to access the services.
A Session Border Controller (SBC) is introduced into the signalling and media path
between calling and called parties. The SBC acts as if it was the called VoIP phone and
places a second call to the called party. The effect of this behaviour is that not only the
signalling traffic, but also the media traffic (voice, video etc) crosses the SBC. Without an
SBC, the media traffic travels directly between the VoIP phones. Control and security are
therefore assured by forcing the signalling and media traffic of the sessions to traverse the
SBC.
Security is improved thanks to the Back-to-Back User Agent. Indeed, information related to
the end users is hidden from the network and the other way around; information related to
key equipment owned by the network operator is hidden from end users. For instance the IP
address of the registrar server, or the IP address of the SIP proxy of a business entity.
The SBC offers the means for rich interaction with other network entities or protocols. The
first opportunity is to interact with the NRC (Network Resource Controller) to control QoS by
managing usage of resources in the Access and Aggregation Network. Second, it also
informs the charging entity (by using Radius or Diameter protocols). Finally, it interacts with
the SDP to direct the media stream through the ABG. It can also correlate resource
reservations with the amount of resources requested by applications in SDP (SDP offer).
Additionally, some SBCs can also allow VoIP calls to be set up between two phones using
different VoIP signalling protocols (SIP, H.323, Megaco/MGCP, etc...) as well as performing
transcoding of the media stream when different codecs are in use. Many SBCs also provide
firewall features for VoIP traffic (denial of service protection, call filtering, bandwidth
management, etc...).
Although the necessity to have a SBC in a NGN architecture is recognized by all major
operators, the concept of the SBC is sometimes controversial to proponents of end-to-end
systems and peer-to-peer networking.
• SBCs can extend the length of the media path significantly. A long media path is
undesirable, as it increases the delay of voice packets (especially if the SBC
implements transcoding) and the probability of packet loss. Both effects can cause
deterioration in the voice/video quality. Some SBCs can detect if the ends of the call
are in the same subnetwork, and if so release control of the media enabling it to flow
directly between the clients, this is called anti-tromboning.
• SBCs break the end-to-end transparency. VoIP phones cannot use new protocol
features unless they are understood by the SBC. End-to-End encryption cannot be
used if the SBC does not have the key.
• Far-end or hosted NAT traversal can be done without SBCs if the VoIP phones
support protocols like STUN, TURN, ICE, or Universal plug-and-play.

architecture III
IST - 6th FP
An SBC may provide session media (normally using Real-time Transport Protocol) and
signalling (normally using SIP) wiretap services, which can be used by providers to enforce
requests for the lawful interception of network sessions.
The main functions of a Session Border Controller may be presented in two different
subgroups according to whether they belong to control (signalling) or media functionalities.
These functions may be grouped physically into a single network element (SBC) or in two
distinct entities. Usually, they are collocated at the border of the core network in the Network
Service Provider domain. Functions related to the control of streams will be labelled “BC” for
Border Controller whereas functions related to the media part are tagged with ABG or
Access Border Gate (or Gateway).
Essential ABG functions are:

• Pinholing (a.k.a. flow gating): open/close gates of the ABG to un/authorize the
traversal of a particular flow.
• Rate limiting: limiting the bandwidth associated with a particular flow traversing the
ABG.
• NAPT: allocation of addresses and ports for translation. Performs the actual
translation on media streams.
• TOS remarking: adaptation of the TOS bits (DSCP bits) in order to police the traffic
according to the defined rules.
The ABG is a gateway between different IP networks that allows control of the traffic flowing
through it (pinholing and rate limiting) and adapting the traffic (NAT and TOS remarking). The
process of replacing IP addresses and ports in the ABG not only solves the NAT issues but
also provides extra security by hiding end user’s addresses, sensitive network element’s
(servers…) addresses and network topology. This functionality is new compared to what is
defined in SIP, as that protocol did not foresee this translation of addresses in SBC
elements.
The Border Controller is a Back-to-Back User Agent. Functions belonging to the BC part are:
• To interact with ABG to control media and signalling streams:
o NAPT/Pinhole requests to ABG.
o Adapt SDP/SIP with NAT of ABG result in signalling streams.
o Adapt SDP/SIP with service-based policies prevailing in the network (SPDF).
• To proxy SDP/SIP messages to endpoints or softswitches.
• To interact with NRC (Network Resource Controller):
o QoS control (manage BW reservation / release)
• To inform the charging entity (via RADIUS or Diameter)
• Protocol interworking (H.323, MGCP, …)
Some characteristics of the reference architecture (See Figure 7) are listed below:
• This architecture requires a dedicated network element, the Session Border
Controller. In most of current implementations the SBC is a standalone physical
entity. The presence of this extra equipment results in additional cost not only for the
hardware itself but also for its operation (configuration, powering…) and
maintenance.

architecture III
IST - 6th FP
• The reference architecture does not offer the actual means to control usage of
resources in the upstream in the access and aggregation network (and the first mile
link).
• The Session Border Controller is a Single Point of Failure (SPOF). The number of
users that might be affected by a failure of this equipment might be significant. E.g.
100K users, 50 CAPS. Consequently, the SBC needs to be equipped redundantly
and mechanisms must be implemented to switch from the SBC in service to the
standby SBC.
Distributed Architecture
The concept of a distributed Session Border Controller architecture arises as part of a more
general possible evolution whereby the capabilities of the Access or Aggregation Nodes are
significantly enhanced. The SBC could be moved from its current position (i.e. as an edge
device to other networks), to the actual boundary with users, or at least as much closer to
them – i.e. moved from the Edge Nodes to the Access Nodes or to the Aggregation Nodes.
The architecture and the requirements differ according to the different business roles
involved (NAP, NSP, ASP…) and the associated business models.
The most obvious scenario is the retail model (both from the IP address and from the
application perspective), in which the roles of the Network Access Provider (NAP) and of the
Application Service Provider (ASP) are taken by a single entity or by two entities bound by a
privileged and trusted relationship. This scenario is illustrated in Figure 8. The NAP-ASP
owns a softswitch and all SIP messages issued by retail users are firstly directed to the
distributed SBC located in the Access Nodes before being redirected to the central server as
illustrated. Given the existing trusted relationship, the SIP messages exchanged and the
subsequent RTP flows do not necessarily have to traverse any Edge Border Controller
element between the network of the NAP and ASP, as was the case in Figure 7.
CPN
CPE
SBC Session between 2 users
of the same Provider
EN
Ethernet (router)
AN aggreg. NW NAP/RNP Application
Server
SIP
CPN Sx
CPE SBC #1
Ethernet EN ASP1
ASP backbone
aggreg. NW (router)
AN NAP/RNP

Media
PSTN Gateway
SS7
Figure 8: Distributed Session Border Controller Architecture – Retail Model – Signalling

architecture III
IST - 6th FP
In the proposed architecture, the functions of the Access SBC that used to be located at the
Edge Node (see Figure 7) are now distributed to the Access Nodes. Thanks to the
preliminary control performed in the Access Nodes in the upstream direction, it becomes
possible to reduce the Edge SBC functions to a minimum. Simplified policing on aggregates
of flows is a more scalable approach and sufficient in this new, distributed architecture. This
limited control on aggregates of flows could be performed by existing Edge Nodes or Edge
Routers and would free the access network from the need for dedicated equipment (Edge
SBC).
Peering SBCs are still required at the interfaces between different service provider’s domains
as will be shown in the next business model. In the Peering SBC, control and policing may
also be applied to aggregates of flows and based on Service Level Agreements (SLAs)
between service/network providers.
Motivation
There are several reasons to distribute the functions of a central SBC into the Access and
Aggregation Network and in particular, to the actual ingress of the NAP infrastructure (into
the Access Nodes).
By distributing the checkpoint, the secure (Overlay) network is extended to the Access
Nodes as illustrated in Figure 30.
The QoS control and enforcement are performed at the actual “ingress” of the NAP network,
in the first “trusted” element of the network. Shaping at the ingress of the NAP network also
has the benefit of limiting the upstream load on the aggregation part of the network.
A second benefit is the protection of the softswitch against signalling DoS attacks at NW
access (by limiting initial US signalling rate in ABG).
Other motivations for decentralization are better scalability (smaller number of users per local
SBC), and in the case of failure, the number of users impacted is also less. The robustness
is improved (SPOF for far less users than an ABG at the edge). Of course resilience
techniques will have to be implemented to redirect users to a spare local SBC in the case of
failure. This mechanism is already in place for centralised SBCs today. The same
mechanisms for smaller numbers of users should be applicable. It should be noted that in
case of failure of an Access Node element, having a central SBC with redundant platforms
does not help to preserve the existing VoIP sessions since they will not be able to traverse
the Access Node.
The cost reduction benefit (assuming the SBC functionality is well integrated into optimized
AN hardware) will be assessed by the work performed in MUSE WPA3 work on techno-
economics.
Fewer boxes are needed at central locations and the features needed may be limited to
simpler control and policing of aggregate flows. If these functions are reduced, they may be
realised by simpler network elements (existing routers) and remove the need for having any
dedicated, central SBC hardware.

architecture III
IST - 6th FP
The SIP awareness introduced into the Access Nodes with the move of the BC part of the
SBC eases integration of resource management across multiple services in the access node
(VoD, VoIP,…) for the first mile. The Access Node is indeed the best place in the network to
get a thorough view of the resources used by the different services over the first mile but it
requires signalling awareness. One can expect that video services will evolve to also support
SIP for resource reservation or that new services based on SIP will appear. Moreover, the
SIP layer introduced into the Access Nodes allows triggering network resource reservation
from the Access Node.
A-RACF (Resource Management) can also be (partly) distributed with a local function in AN
for normal traffic levels (see section 3.2.7).
Business models
Different business models were considered in this study. The architecture and the
requirements differ according to the different business roles involved (NAP, NSP, ASP…)
and the associated business models. An overview of the following business models is given
in the below sections:
• Retail model Single Provider
• Retail model Multi Provider
• Retail model Roaming
• Wholesale model
• The so-called "Hybrid" model
3.2.2 Retail model
Single provider
As already noted, the most common model is likely to continue to be the retail single
provider, i.e. a single operator provides access to both the infrastructure and the services as
shown in Figure 8. The (green) operator plays the roles of the NAP and ASP simultaneously.
This scenario is based on the current strategy of the major operators and is therefore the
prime focus of the distributed architecture under study.
Multi-provider
Figure 8 (above) illustrates the particular case in which both the session initiator and the
called party belong to the same provider.
Figure 9 (below) shows the signalling flow in the case where the called party is located in the
network of a different provider. Peering back-to-back session Border Controllers are
introduced at the border between the operators’ networks. This allows each of them to verify
at the ingress to their respective networks that the ingress traffic does indeed accord to the
defined Service Level Agreements. Traffic may be policed at the session or aggregate level.
These peering back-to-back session Border Controllers were not considered as candidates
for distribution in this study as they have a different role to the edge Session Border
Controllers, and they need to be at the network border by definition of this role.

architecture III
IST - 6th FP
Multi-provider Application
Server
session
CPN
CPE SIP
SBC
Sx
EN #1
Ethernet (router)
ASP1
AN aggreg. NW NAP/RNP ASP backbone
Peering
SBC
B2B SBCs SBC Application
Server
CPN Sx
CPE #1
SBC
EN ASP2
Ethernet ASP backbone
aggreg. NW (router)
AN NAP/RNP2 IP@ in SubNet 1 (e.g. retail)
Figure 9: Distributed SBC- Retail Model – Peering SBCs – Signalling
Roaming
There are however many drivers to support other business models, involving multiple
providers. The main incentives are the increasing importance of the IP Multimedia Subsytem
(IMS), the recent evolution of ETSI/TISPAN standards with the objective of supporting Fixed
Mobile Convergence, but there are also regulatory drivers such as Network Neutrality2 that
allows any company to launch (new) broadband services, grow, and innovate.
A first stage is to open the network to services from different providers, or to allow nomadic
users to connect to their own/home ASP (blue in Figure 10). The difficulty comes from the IP
address of the RGW allocated by the green NAP in its own (green domain) whereas the
nomadic user/terminal wants to connect to the blue provider in a different domain.
A distributed architecture supporting roaming of VoIP services is depicted in Figure 10. All
VoIP signalling messages have to pass through the DSBC and are always redirected to the
Softswitch of NAP/ASP1. In the case where the caller tries to connect to a different ASP
(blue), the messages are redirected by the Softswitch (SX) to the B2B peering SBC located
at the frontier between the two provider’s domains.
2
The Network Neutrality principle states that public networks such as the Internet should not
discriminate traffic in function of, e.g. the destination or the type of the application.

architecture III
IST - 6th FP
Application
Server
CPN
CPE
SBC
Sx
EN #1
Ethernet (router)
AN ASP1
Roaming aggreg. NW NAP/RNP ASP backbone
SIP
Peering SLA
SBC
B2B SBCs SBC Application
Server
CPN
SBC
CPE
Ethernet EN
(router) Sx
aggreg. NW #1
AN NAP/RNP
ASP2
ASP backbone
Figure 10: Distributed SBC - Retail Model – Roaming
3.2.3 Wholesale model

A more advanced step in the opening of the network to service providers is the wholesale
model. The green NAP provides the connectivity and access to the infrastructure, whereas a
second (blue) provider provides the services (including the IP address to the RGW).
IP
Retail
ASP does
not own SX
CPN
CPE
SBC
EN
Ethernet (router)
ASP1
Application AN aggreg. NW NAP/RNP ASP backbone
Wholesale
IP
Wholesale
Application
Server
SIP
CPN
SBC
CPE
Ethernet
EN BC
SLA Sx
aggreg. NW (router) ABG
#1
AN NAP/RNP
ASP2
ASP backbone
Figure 11: Distributed SBC – IP address and Application Wholesale Model – Signalling

architecture III
IST - 6th FP
This is illustrated at the bottom of Figure 11. Since the blue service provider offers the whole
bundle of services to the second user, the task of the green NAP to ensure connectivity is
also easier (compared to the Hybrid model see 3.2.4). Actually, in the Access Node, the
traffic may be entirely redirected towards the Edge Router corresponding to the blue service
provider.
The green operator has distributed SBC functionality in the access nodes and controls
upstream traffic initiated by end users at these ingress points. In the other direction, the
green operator may control traffic on aggregates of flows in an Edge Node or edge router in
order to check that the overall SLA is respected. Therefore, a trusted relationship exists
between the two operators and an edge/central SBC function is not required anymore for the
retail operator.
In the case where a user from the blue provider would send traffic to a user from the green
provider which exceeded the QoS negotiated during the signalling phase, it is the
responsibility of the blue provider to take the necessary actions and to police the traffic
accordingly.
In the event that the blue operator does not perform his job correctly, the retail operator
(green) will be able to notice this at the egress SBC located in the access Node. He may
then decide to stop the session, notify the blue operator or take any other action as defined
in the SLAs based on the evidence that the contract is not being respected.
The blue operator requires a SBC at the ingress of its network to be sure that users do
respect the QoS that was negotiated.
Because the blue operator has no direct access to the SBC located in the access node,
agreements must be defined on the pools of IP addresses or ports and on the subnets to be
used in the Access Node owned by the NAP.
3.2.4 Hybrid model

The ultimate step is to open completely the network of the NAP to all Service Providers. This
means supporting the capability to have different services offered simultaneously to a single
user by different service providers, and therefore in different IP network domains. In our
example, the green operator provides connectivity and for instance best effort Internet
services. Second and third operators (blue and orange) both offer VoIP services.
There are three different approaches to make this happen depending on whether the actual
service segregation takes place in the RGW, in the Access Node or in the Edge Node:
1) Service segregation in the RGW

The NAP allocates multiple IP addresses to the RGW (one per service provider) and there is
a Virtual Routing and Forwarding (VRF) and a SBC instance in the Access Node per Service
Provider. The traffic is segregated towards the correct Edge Node based on the IP
domain/subnet. This allows different VLANs and different policing per SP on the first mile link
but also in the access and aggregation domain. The SBC instances and the context of the
calls are also separated in the Access Node. This is illustrated in Figure 12.

architecture III
IST - 6th FP
ASP does
not own SX
BE
Internet ASP1
ASP backbone
Application
CPN Server
CPE
SBC
SBC
BC
SLA ABG
Sx
CPN #1
AN SIP
ASP2
ASP backbone
Application
Server
EN
(router)
IP@ in SubNet 1 (e.g. retail) Ethernet SLA
NAP/RNP BC
IP@ in SubNet 2 (ASP2) aggreg. NW Sx
ABG
IP@ in SubNet 3 (e.g. retail) #1
NAP doen’t own any S X ASP3

ASP backbone
Figure 12: Distributed SBC- Hybrid scenario – Signalling – Service segregation in the RGW
2) Service segregation in the Edge Node

The NAP allocates a unique IP address to the RGW belonging to the NAP subnet. In the
Access Node the SBC changes the IP destination address based on the targeted Service
Provider (Server). If the implementation allows it, the VLAN could also be different depending
on the destination IP address. For SIP based services, this implies the need for inspection at
the SIP layer and to look up the domain in the destination field. The traffic is then always
forwarded to the Edge Node (Next Hop) of the green ASP. The Edge Node / Router chooses
the interface/domain corresponding to the destination IP address. This method is illustrated
in Figure 13. Note that this requires the Edge Node to interface to all SPs networks.

architecture III
IST - 6th FP
ASP does
not own SX
BE
Internet
ASP1
ASP backbone
Application
CPN Server
CPE
SBC
BC
SLA Sx
ABG
CPN #1
AN SIP
ASP2
ASP backbone
Application
Server
EN
(router)
Ethernet SLA
IP@ in SubNet 1 (e.g. retail) BC
aggreg. NW NAP/RNP
IP@ in SubNet 2 (ASP2) Sx
ABG

ASP backbone
Figure 13: Distributed SBC- Hybrid scenario – Signalling – Service segregation in the Edge
Node
3) Service segregation in the Distributed SBC

The IP address is allocated to the RGW by the NAP. The difficulty is for the NAP to redirect
the VoIP traffic to the correct edge (Service Provider). Based on the destination (SIP server
address in SIP layer), the local SBC changes the VLAN and directs the traffic to the
corresponding Edge Node/Router (next hop). This is illustrated in Figure 14.

architecture III
IST - 6th FP
ASP does
not own SX
BE
Internet ASP1
ASP backbone
Application
CPN Server
CPE
SBC
BC
SLA Sx
ABG
CPN #1
AN SIP
ASP2
ASP backbone
Application
Server
EN
(router)
Ethernet SLA
aggreg. NW NAP/RNP
ABG

ASP backbone
Figure 14: Distributed SBC- Hybrid scenario – Signalling – Service segregation in the
distributed SBC
The drawback compared to the preceding model 1 (see Figure 12) is that the DSBC
instances in the Access node may not be isolated per Service Provider. The advantage
compared to model 1 is that the RGW need not handle multiple IP addresses.
Compared to model 2, VLAN segregation in the Access and aggregation network is

straightforward and every Service Provider may have a dedicated Edge Node.
3.2.5 Impact on Authentication

After the terminal has got its IP address allocated during the authentication process (see
section 2.2), it must also be configured with the address of its point of contact, which is the IP
address of the Border Controller located in the Access Node (or P-CSCF in IMS
terminology). Manual configuration of the terminal is possible but automatic processes are
preferred.
DHCPv4 option 120 defined in RFC 3361 allows SIP clients to locate a local SIP server that
is to be used for all outbound SIP requests, a so-called outbound proxy server.
The SIP server DHCP option carries either a 32-bit (binary) IPv4 address or, preferably, a
DNS (see [27]) fully qualified domain name to be used by the SIP client to locate a SIP
server.

architecture III
IST - 6th FP
In the case of business users there could be a local SIP proxy, terminals would be configured
using DHCP option 120 with the IP address of the enterprise proxy. The enterprise proxy
would redirect the signalling to the BC located in the Access Node.
In the case of DHCPv6, the equivalent processes are defined with option 21 (Domain Name
List) and option 22 (IPv6 address List) in [28].
PPP could be considered for legacy services only if terminated in the AN in combination with
the MUSE IP Network model. Defining a new IPCP option is too complex and the
recommendation in that case is to limit the use of the PPP mechanism to the allocation of the
IP address and use DHCPINFORM messages to communicate and configure server details.
The requirement is then to have a DHCP server in the backend of the NSP domain and have
a DHCP client of some sort in the NAS server.
For more information, refer to chapter 2.5.3 in [2], where this approach is described into
details.
DHCP relay or
DHCP server in
the Access Node
to add the DHCP
option in the
DHCP offer
message
Figure 15: Terminal configuration in one step auto-configuration mechanism with DHCP server
in the Access Node
It is possible to combine the one step auto-configuration method defined in MUSE [3] with
the configuration of the terminal using DHCP option 120. As illustrated in Figure 15, the
DHCP server located in the Access Node may insert the option 120 in the “DHCP offer field”.
Since the Border Controller is located in the Access Node, its IP address is also known from
that entity.

architecture III
IST - 6th FP
From here on, we will assume that all (subsequent) signalling messages issued by a terminal
will be sent with the IP address of the P-CSCF as destination IP address.
It is the responsibility of the Border Controller (P-CSCF) to determine the most appropriate
next hop. It can be:
• Another SIP proxy – SBC.
• A Softswitch.
• The final destination (terminal) (egress).
3.2.6 Impact on autoconfiguration and service invocation

In the distributed SBC architecture, thanks to the DHCP option 120 described earlier, the
signalling messages are directed to traverse the Border Controller (the P-CSCF) located in
the access node giving control to the operator. The operator may either decide to route the
Register messages to the destination indicated by the end terminal, using DNS lookup if
necessary, or force the requests towards another destination.
Given the number of Access Nodes distributed in a large administrative Access Network may
be important, it should be possible to automatically assign the policy rules to be used in each
Access Node. A central policy server could be integrated in the distributed SBC architecture
to allow easy central control of these rules as illustrated in Figure 16. The rules could be
either downloaded locally to the Access Node (and updated when necessary in order to
optimize performances) or obtained on the fly using, e.g. the COPS protocol.
Looking at the “From” field, a distinction can be made between retail and wholesale users.
Different behaviours can be applied depending on the end user’s characteristics following the
specification defined in the central database of the policy server under the control of the
Network Access Provider. Depending on the business model considered (see 3.2.1) the
distinction could also be performed based on the source or destination IP address.
Retail users ⇒ SX retail.org

Central Wholesale users ⇒ peer SBC wholesale.net
Policy server
XYZ.org ⇒ peer SBC wholesale.org
#1 REGISTER sip:xx.org SIP/2.0 #1’ REGISTER sip:retail.org SIP/2.0

From: sip:yy@xx.org From: sip:yy@xx.org LOCATION
To : sip:yy@xxx.org To : sip:yy@xxx.org SERVER
Contact: <sip:195.31.65.152> COPS Contact: <sip:195.31.65.152>
Route: sip:yy.org Route: sip: peer SBC retail.org
Expires: 3600 Expires: 3600 #2 yy@195.31.65.152
#1 #1’ SIP REGISTRAR

End user SBC
retail.org
#3’
#3
#3 SIP/2.0 200 OK
Figure 16: Register messages sent by end user in distributed SBC architecture – Policy server

architecture III
IST - 6th FP
Signalling messages that are sent by the registrar or invite messages sent by other users will
be destined for the end user’s IP address.
The BC must take action to ensure that it will always be in the loop of all signalling messages
from network (softwitch) to user. There are 2 ways of doing it:
• By changing the IP address in the contact (see message #1’ in Figure 17).
• By using Path header (as a mandatory extension)
In this way, the BC forces its involvement in any signalling message sent to any of the end
users of the corresponding Access Node. Therefore, in this example, the IP address
associated with user “yy” in the location server will be the IP address communicated by the
session Border Controller instead of 195.31.65.152.
Central
Policy server Wholesale users ⇒ peer SBC wholesale.net

From: sip:yy@xx.org From: sip:yy@xx.org
LOCATION
To : sip:yy@xxx.org COPS To : sip:yy@xxx.org SERVER
Contact: <sip:195.31.65.152> Contact: <sip:IP @ of SBC>
Expires: 3600 Expires: 3600 #2 yy@195.31.65.152

End user SBC
retail.org
#3’
#3
#3 SIP/2.0 200 OK
Figure 17: Register messages sent by end user in distributed SBC architecture – Contact field
The registrar indicates in the “Service Route” field of the answer to the Register request (#3
in Figure 18) an IP address and a port to be used by the terminal as the destination of the
next signalling messages. This field may be used to direct subsequent signalling messages
to a different server in order to perform load balancing or for any other reason convenient to
the NAP. The Session Border Controller in the Access Node keeps the information on the
binding between the end user and the corresponding service route.

architecture III
IST - 6th FP

Central
Policy server Wholesale users ⇒ peer SBC wholesale.net

From: sip:yy@xx.org From: sip:yy@xx.org LOCATION
To : sip:yy@xxx.org COPS To : sip:yy@xxx.org SERVER
Contact: <sip:195.31.65.152> Contact: <sip:IP @ of SBC>
Expires: 3600 Expires: 3600
#2 yy@195.31.65.152

End user SBC
retail.org
#3’
#3
#3 SIP/2.0 200 OK
Service Route <sip:Sx2 @ IP:port; transport=udp>
Figure 18 Register messages sent by end user in distributed SBC architecture – Service Route
Note: Another option for auto-configuration could be to intercept all SIP traffic and to filter out
the SIP traffic towards a specific provider-URI. Non-matching SIP traffic can just be passed.
The UA does not need to be configured with an SBC address since it could use any IP-
address as a destination address, for example the address of the default router. This could
facilitate a solution for the redundancy issue. The AN could be configured with an always-on
rule to redirect all SIP-traffic destined to the edge router towards an SBC deeper in the
network. If the SBC in the AN is down, the redundant SBC will handle the traffic.
Setting up a multimedia session – Basic

The previous paragraph explained how the Session Border Controller could learn from a
central policy server which server or proxy it should forward requests to based on the origin
of the message indicated in the “From” field. The mechanism to force every signalling stream
to the Session Border Controller located in the Access Node was also explained and some
proposals were given for the Network Access Provider in order to allow him to keep control of
the SIP sessions initiated on his network.
The present paragraph describes how subsequent signalling (after Register: Invite – Modify –
Bye…) and media streams can be directed to the correct Edge Node. Different solutions for
the allocation of VLANs in the Aggregation Network were considered during the
investigations:
1. Use different VLANs per edge Node (=IP forwarder model)

2. Use different VLANs for signalling and media streams
3. Use different VLANs for retail and wholesale IP addresses
4. Use different VLANs for retail and wholesale Applications
From the feedback received from MUSE Service Providers, it appears that the preferred
option is to have a combination of options 1, 3 and 4.

architecture III
IST - 6th FP
ASP does
not own SX
Retail
edge ASP1
SIP
BE
Internet ASP1
ASP backbone
Application
CPN Server
CPE
SBC
BC
SLA Sx
ABG
CPN #1
AN
ASP2
ASP backbone
Application
Wholesale Server
edge ASP3 EN
(router)
Ethernet SLA
aggreg. NW NAP/RNP
ABG

ASP backbone
Figure 19: VLAN segregation in Access and Aggregation Network
Figure 19 illustrates an allocation of VLANs according to the preferred options. First, different
VLANs are used to make a distinction between retail and wholesale traffic. Second, each
Edge Node (Service Provider) - Access Node pair uses a different VLAN.
Advantages
The advantage of different VLANs for retail and wholesale users is to allow the NAP to police
retail users and wholesale users differently. It then becomes then possible to allocate
different bandwidths to different groups of users, and to have different agreements with
different service providers.
Setting up a multimedia session – with hosted NAPT traversal

In the majority of deployments, the Residential Gateway will be configured with a dynamic
public IP address obtained from the NSP (or from the NAP on behalf of the NSP) whereas
the terminals connected to the RGW will get a private IP addresses from a local DHCP
server in the RGW. The motivation for this is to reduce the number of allocated public IP
addresses.
This is the IP retail model. NAPT is then performed in the RGW to perform the translation
and allow access to multiple services from multiple home terminals that are configured with
private IP addresses.
In the case where the RGW does not provide a SIP ALG (Application Level Gateway) the
private IP addresses will also appear in the payload of the Session Description Protocol
(SDP) leading to issues with the initiation of the session, if not addressed properly.

architecture III
IST - 6th FP
This section explains how a Session Border Controller located in the Access Node may solve
NAPT issues created by the RGW. In the case where NAPT issues are already solved by the
RGW, it is still recommended to perform NAPT in the network in order to hide its topology
and to make end users anonymous.
IPBCa PBCa IPBCa’ PBCa’

IPfromA PfromA EN
SBC
IPsecToA P secToA
(router)
CPN
CPE Application
Ethernet Server
Terminal A RGW A AN aggreg. NW NAP/RNP
Private Address Public Address
IPA PA IPC PC IPC’ PC’
Sx
#1
IPBCb PBCb IPBCb’ PBCb’
IPfromB PfromB EN
SBC
IPsecToB PsecToB ASP1

(router) ASP backbone
CPN
CPE
Ethernet
Terminal A RGW A AN aggreg. NW NAP/RNP
Private Address Public Address
IPB PB IPD PD IPD’ PD’
Figure 20: Network hosted NAT traversal – Interfaces (IP retail)
Figure 20 above describes the IP addresses allocated to the different interfaces involved in
the process:
• IP addresses IPBCa PBCa and IPBCa’ P BCa’ are fixed IP addresses allocated by the NAP
to the physical interfaces of the BC in Access Node A.
• IP addresses IPfromA PfromA and IP secToA P secToA are dynamic IP addresses and ports
allocated by the ABG from its pool of addresses provided by the NAP.
The term “Inbound” refers to incoming traffic from the secured network delimited by the
distributed SBC. The term “Outbound” refers to the traffic leaving the secured network. The
light yellow cloud in Figure 30 illustrates the VoIP secured overlay network.

architecture III
IST - 6th FP
Softswitch
BC
BC
ABG
ABG
IP A P A IPC PC IPD PD IPB PB
1
2
SIP INVITE SIP INVITE SIP INVITE
IPC PC IPBCa PBCa SIP INVITE
IPBCa’ PBCa’ IPSx PSX IPSx PSX IP BCb’ PBCb’
SDP: IPA PA with PA = for Rx SDP IPsecToA PsecToA IPBCb PBCb IPD PD SIP INVITE
SDP IPsecToA PsecToA
SDP IPfrom B Pfrom B IPBCb PBCb IPB P B
SDP IPfrom B Pfrom B
4 3
SIP OK SIP OK
SIP OK SIP OK
IPBCb’ PBCb’ IPSX PSX IPD P D IPBCb PBCb
IPBCa PBCa IPC PC IPSX PSX IP BCa’ PBCa’
SDP IPsecToB PsecToB SDP IPB PB with PB = for Rx
SDP IPfromA PfromA SDP IPsecToB PsecToB
IPC’ PC’ allocated by RGW
5 IPD’ PD’ allocated by RGW
RTP IPsecToA PsecToA IPsecToB PSecToB
RTP IPC’ PC’ IPfromA Pfrom A
7 6
RTP IPsecToB PsecToB IPsecToA PsecToA
RTP IPfromA PfromA IPC’ PC’ RTP IPD’ PD’ IPfrom B Pfrom B
8
RTP IPC’ PC’ IPfromA Pfrom A RTP IPsecToA PsecToA IPsecToB PsecToB RTP IPfrom B Pfrom B IPD’ PD’
RTP IPfrom B Pfrom B IPB PB
Figure 21: Network hosted NAT traversal – Message flow

Figure 21 illustrates the complete flow of messages and the actions taken by the Border
Controller and by the Access Border Gateway to solve the NAPT issue. The Pinholes, the
inbound and outbound rules and the NAT rules on SDP resulting from the complete process
are illustrated in Figure 22.
Assumption:
For the user terminal, the media destination address/port is the same as the media origin
address/port (IPA PA).
Signalling streams:
An Invite message is sent from the terminal A (IPA PA) to the Border Controller (IPBCa PBCa) in
order to invite terminal B to participate to a VoIP session. In this invite message IPA PA are
also mentioned in the SDP content and indicate on which IP address and on which port user
A expects to send and to receive RTP streams.
The RGW C performs NAPT and replaces, in the IP header, the source IP address (IPA PA)
of terminal A by its own IP address and by a temporary port (IPC PC). The message is sent to
the Border Controller. The Access Node checks the destination IP address of the incoming
packet and recognizes the IP address of its own local Border Controller.

architecture III
IST - 6th FP
Step 1) The Access Node knows the message has to be handled by its B2BUA and passes
the messages to the Border Controller. The BC detects the NAPT issue in the SDP payload
of the “SIP INVITE” since the IPA PA mentioned is different from the source IP address
present in the IP header (IPC PC). The BC requests the ABG to create a RTP pinhole so that
the downstream RTP flow will be capable to traverse the Access Node and to reach the
terminal A (S: IPX PX, D: IPSecToA PSecToA). It also requests the ABG to allocate an IP address
to that session in order to solve the NAPT issue. At this point, the final port where RGW C
will send the RTP traffic to is not yet known. The ABG answers to the BC request with the IP
address allocated to the session and either with a dummy port or with a port reserved for this
purpose (IPSecToA PSecToA). The BC performs NAPT in the “SIP INVITE”. The ABG creates an
“OUTBOUND RULE” (meaning towards unsecured network see Figure 30) on the destination
IP address so that future messages with destination (IPSecToA PSecToA) are redirected to IPA PA.
Later on, this rule will be adapted and IPA PA will be replaced by IPC’ PC’. The correct port
PSecToA will also have to be updated and mapped (in case of having used previously a dummy
port for it) later on by the ABG to PC’ (see step 5 and Figure 22).
The Border Controller sends the transformed “SIP INVITE” message to the Softswitch
corresponding to the terminal A, as was indicated by the central policy server during the
registration process. The Softswitch either already knows the Border Controller
corresponding to terminal B or may request this information to its “location service”. The
Softswitch forwards the Invite Request to the Border Controller B. The second Access Node
recognizes the IP address and transfers the “SIP invite” to its Border Controller.
Step 2) The BC detects the NAPT performed in the Network (in SBC A) in the “SIP INVITE”.
The BC requests its ABG to react accordingly with the opening of a pinhole and to solve the
NAPT issue. In the answer, the ABG indicates the allocated IP address and port (IPfromB
PfromB). The BC performs NAPT in the SIP INVITE. It determines the destination IPD (known
from the registration process). The pinhole opened in this case is S: IPX PX, D: IPfromB PfromB
and the associated “INBOUND RULE” (with respect to protected Network) indicates to check
the destination IP address and to replace any IPfromB address by IPSecToA. This ensures the
correct return of answers from terminal B to terminal A via the different border controllers.
The RGW D recognizes the destination IP address as being its own IP address; it performs
NAPT and forwards the message to terminal B. The RGW D knows the message has to be
forwarded to the terminal B because it keeps bindings of all connections where NAPT was
performed and a binding was just created during the registration process. In order to keep
the binding active in a RGW (in the case of having SIP over UDP), there may be a
mechanism needed in the terminal to refresh it every 30 seconds by sending new register
messages. Therefore, in order not to overflow the Softswitch, the Border Controller will block
the majority of the registration requests sent every 30 seconds and their frequency will be
maintained just below 3600 seconds. In the case where SIP over TCP or TLS over TCP are
used, the NAPT bindings are already kept.
The terminal B accepts the invitation and replies with a “SIP 200 OK” message. The
originating IP address IPB and the expected reception (and sending) port PB are indicated in
the payload of the SDP by the terminal B. The RGW D changes the IP source address and
port of this IP packet by IPD PD. The port D being still temporary till the actual RTP traffic is
sent over PD’.

architecture III
IST - 6th FP
Step 3) At this stage, the BC detects the NAT issue created by the RGW in the “SIP OK”
since IPB and the port PB indicated in the SDP are different from the Source IP address in the
IP header (IPD PD).
The ABG allocates the IPSecToB address and port PSecToB. The BC performs NAT in “SIP OK”.
It determines IPBCA’ from the information available at the transaction layer and in some fields
of the “200 OK” message. The “OUTBOUND RULE” created on the destination address
indicates to replace IPSecToB PSecToB by IPB PB (IPB PB needs to be replaced later on by IPD’ PD’
when the origin IP address and Port will be chosen by the RGW D. The port PSecToB will also
have to be mapped at this later stage by the ABGb onto the Port PD’ allocated by the RGW D
to the RTP traffic sent by B if a dummy port was used for PSecToB.
Step 4) At this point of the process, the BC detects the NAT issue resulting from the NAPT
performed in the SBCb in the “SIP OK”. As results of “operation 4”, the IP address is
allocated by the ABG (IPfromA) and the actual NAPT is performed in the “SIP OK” signalling
message. The pinholes created and adapted are respectively S: IPX PX, D: IPfromA PfromA and
S: IPSecToB P SecToB D: IPSecToA P SecToA. The “INBOUND RULE” created will imply to change the
destination IP addresses IPfromA P fromA into IPSecToB PSecToB. The message is forwarded to IPC
PC.
Terminal A receives the acknowledgement from terminal B to start the VoIP session. In the
SDP of this message, the IP address and Port to be used by terminal A to contact terminal B
are indicated. These have been translated all over the path from the original (IPB PB ) into
IPfromA PfromA.
Media streams
Step 5) The RTP flow is sent by the terminal and the actual emitting IP and Port (IPC’ and PC’)
are only fixed by the RGW from that moment on. The destination IP address IPfromA PfromA is
recognized by the Access Node as aimed to the ABG since these address and ports were
chosen by the local SBC of this Access Node during the set-up of the call to resolve NAPT
issue (in step 4).
The results of the local SBC during this step (5) will be the following. The “OUTBOUND
RULE” is adapted and IPC’ PC’ that was just selected by the RGW C replaces IPA PA. The
ABGa allocates PsecToA, if not done yet, and maps it to PC’ (this is now possible because PC’ is
known). In future SDP messages IPA PA will be replaced by IPsecToA PsecToA (RGW C does not
modify the SDP). The “INBOUND RULE” is also created to replace in incoming packets
packets the destination IP address IPfromA PfromA by IPsecToB PsecToB.
The RTP will flow till the egress SBC located in the second Access Node. However, at this
stage of the process no rule apply yet in the second local SBC since PsecToB was not yet
allocated or at least could not be mapped to PD’. Therefore, the first RTP packet may be
dropped if the rule was not created yet (actually, the emitting Port PD’ is missing and a Port
PsecToB could already be reserved and only mapped to PD’ later on). The pinhole S: IPsecToA
PsecToA, D: IPsecToB PsecToB may already be adapted/refined/narrowed down in the SBCb.

architecture III
IST - 6th FP
In the other direction, Terminal B will also start sending RTP packets and RGW D will choose
an IP address and a port for the VoIP session (IPD’ PD’).
Step 6) At this point the “OUTBOUND RULE” is adapted and IPB PB is changed into IPD’ PD’.
The mapping between the real PsecToB and PD’ is performed if necessary and the rules are
made to adapt future SDP content by changing IPB PB by IPsecToB PsecToB and to replace, in
the IP header of all packets, the destination IPfromB by IPsecToA.
Step 7) The RTP packet reaches the local SBC in the first Access Node and triggers the
allocation of the port PfromA in the “INBOUND RULE”. All subsequent RTP packets will be
adapted as follows: IPfromA PfromA will become IPsecToB PsecToB. All packets with destination IP
address IPsecToA PsecToA are forwarded to IPC’PC’.
Step 8) The subsequent RTP packet reaching the local SBC in the second Access Node will
trigger the allocation of the port PfromB since PsecToB is known and mapped onto PD’.
Note: During the process, in the case that an edge or IP aggregation node does not know a
destination IP address, it can generate an ARP message to which the Access Node must
answer with its own MAC address.
Softswitch
BC
BC
ABG
ABG
IP A P A IPC PC’ IPD PD’ IPB PB
OUTBOUND rule: destination INBOUND (wrt SBC) RULE: destination

IPsecToA PSecToA => IPC PC IPfrom B => IPsecToA
INBOUND RULE: destination OUTBOUND (wrt SBC) RULE: destination

IPfromAPfromA IPsecToB PsecToB => IPD PD
=> IPsecToBPsecToB
Adapt in future SDP msgs: Adapt in future SDP msgs:

IPA PA => IPsecToA PsecToA IPB P B => IPsecToB PsecToB
IPsecToB PsecToB => IPfromA PfromA IPsecToA PsecToA => IPfrom B Pfrom B
S: IPX PX > D: IPfromA PfromA S: IPX PX > D: IPfrom B Pfrom B
(S: IPSecToA PSecToA > D: IPsecToB PsecToB)

(S: IPsecToB PsecToB , D: IPsectoA PsectoA )
Figure 22: Network hosted NAPT traversal: Resulting Pinholes, Inbound and outbound rules
and NAT rules on SDP
Note:
In the wholesale scenario, the IP address obtained from the RGW may be in a different
domain (NSP<> NAP). In that case, the IP addresses allocated to the interfaces of the
Border controller and ABG must also be in the NSP domain. The pool of IP addresses and
ports used by the ABG to resolve NAPT issues must also be in the NSP domain.

architecture III
IST - 6th FP
3.2.7 Impact on resource management and QoS

3.2.7.1 Proposal for D-SBC architecture integration on TISPAN/RACS Sub-system
ETSI/TISPAN is organised by sub-systems, each addressing a particular functionality in an
NGN network. One of these sub-systems is the RACS (Resource and Admission Control)
which focuses on resource reservation.
Our interest focuses on the identification of any extensions and adaptations required to
integrate, under TISPAN/RACS, SBC entities in a scenario where these are distributed in the
access network. In such a situation, entities in the access network, owned by the NAP, now
have functionalities at and above layer 3 (IP) and are also aware of multimedia related
events (SIP based).
For the retail scenario, the following have been also considered:
• Many access networks will exist, connected to a single core network (n:1
correspondence; n>=1) by a Core Border Node;
• Many access nodes will exist in one access network (m:1 correspondence; m>=1),
connected to the corresponding Edge Node by an aggregation/ distribution network;
the Edge node establishes the communication with the next network domain (core
network)
• In the simplest configuration, a single A-RACF instance will exist per access network,
controlling resources and performing admission control for its access domain;
• For end-to-end QoS control, core network resources also need monitoring and control
(inclusion of C-RACF and a C-SPDF - see Figure 23.i); the core network may also be
segmented (this is not addressed);
• Communication between A-RACF and C-RACF may be needed for coordinated
management of the resources between edge and core border nodes; for instance, C-
RACF may communicate with A-RACF entities, changes in the maximum allowed
volume of aggregated traffic that can be exchanged to and from the core network;
• Application level signalling (e.g. SIP) will trigger the appropriate actions through its
path; this is the case for the P-CSCF in the access node, being generated by entities
in the domain or externally.
Based on this, the integration of SBC entities under a controlling sub-system like RACS is
presented in Figure 23.ii which shows the traditional distribution of SBC functions, according
to TISPAN/RACS, Release 1.

architecture III
IST - 6th FP
x-CS CF
A-R ACF
SBC C-S P DF A-R ACF
AN EN CN CN
C-R ACF CN EN
AN SBC
SBC SBC SBC
i) network configuration
SIP signalling AF P -CS CF SIP signalling x-CS CF

Other
Gq’ Gq’ domains
BC BC
Rq Rq Rq
A-R ACF S P DF A-S P DF A-R ACF C-S P DF C-R ACF
Acces
Node
Ia Ia Re Re Ia
Re SBC SBC
ABG ABG
A-BGF
R CE F C-B GF +R CE F
R CE F C-BGF
Acces Node
IP E dge
Di Core Ds Acces s Di Core Ds
CP E L2T P Border CP E L2T P B order
Node
Border
Node
Node
ii) R ACS mapping, no S BC distribution iii) P roposed D-S BC integration in R ACS ,

retail scenario
Figure 23: DSBC-TISPAN/RACS mapping
The distribution of SBC functionality towards the network edge is presented in Figure 23.iii.
The SBC is kept almost the same but its new location presents additional challenges. For
consistent distribution and execution of policies, the existence of a central, or core, SPDF (C-
SPDF) is proposed (by MUSE) which acts as a master to all other SPDFs, in the access
nodes (A-SPDF, one for each SBC), in a sort of hierarchical organization. In this process, if
policies are expected to be defined independently for each network domain or even access
node, adaptation of policies could be required. In addition, via the C-SPDF, policies may be
changed in all or part of the A-SPDF, reflecting changes in network and services usage
policies. The interface between SPDFs is left outside the scope of this study.
At the transport level, RCEF and BGF functions are present, being located, as defined by
ETSI/TISPAN, in the IP edge and at the boundary between different network domains
(access to core or between core networks). Distributing the SBC to the access nodes brings
BGF functions to these entities, now also being the network IP edge to users. Analysis of
ETSI/TISPAN documentation has indicated that the RCEF needs to have a subset of the
BGF functions. However, even though it is stated (by TISPAN) that the RCEF will only work
at layer 3 (in the scope of TISPAN Release 1), addressing layer 2 aspects is not precluded
(some examples in that direction are given). Thus, in addition to the new BGF functions in
the access node, now called A-BGF – Access BGF, the existence of L2 specific functions,
provided by RCEF is also considered. This requires the existence of an Re interface to the A-
RACF entity. This entity performs gate open/close and traffic policing and conditioning
actions on the access nodes, as a result of sessions being accepted. Any traffic not
authorised will not enter the access network segment, from the core network domain thereby,
protecting local entities from all sorts of security attacks and traffic overload. This is
performed via the RCEF entity located in the boundary with the core network and controlled
by the access network central A-RACF. The Re interface (defined in RACS) is used here.

architecture III
IST - 6th FP
Having NAT, and hosted NAT, at the access node, supported by the ABG component of
SBC, does not preclude the same NAT functions being performed at the edge between the
access and core networks. In addition, at this boundary, resource control must exist, for
instance to limit the total traffic exchanged with the core network to facilitate resource
management mechanisms in the core, even if both networks belong to the same
administrative domain. Thus, the need to maintain a BGF function (C-BGF) at this boundary
arises. This C-BGF entity may work on aggregates or on micro-flows. For scalability reasons,
considering the current distribution of functions, it is recommended that the C-BGF works on
aggregates, while the A-BGF (or ABG in SBC context), in the D-SBC entities, may work on a
micro-flow basis.
With the proposed integration (by MUSE), a good balance of central and distributed control is
achieved, without major changes to the proposed TISPAN/RACS entities. The only changes
required are the distribution of some of the functions (e.g. SPDF) and moving towards an
end-to-end view of resource control, via the inclusion of a C- RACF. This may involve the
definition of new interfaces, which is beyond the scope of this work. With the proposed
integration, actions triggered at Access Nodes by the AF and A-SPDF should be controlled
locally (e.g. open/close gates and NAT control) in a distributed way, and also centrally (e.g.
CAC), from the access network point of view, by the A-RACF.
3.2.7.2 Resource Reservation

With the delivery of triple play services (IPTV, Voice over IP (VoIP) – and Internet access)
and with the emergence of broadband applications, access and aggregation networks can
become bandwidth bottlenecks. Efficient resource reservation mechanisms will therefore be
crucial in this network segment. Over-provisioning can be very expensive or even impossible,
due to particular characteristics of the different available network technologies and the
topology of the infrastructure.
Absolute or relative QoS guarantees can be given, depending on the supporting technologies
and operator’s policies. For both strategies to work, it is required that Call Admission Control
(CAC) functions (centralised or distributed) are in place, which will trigger the appropriate
configuration and enforcement actions in the network elements. TISPAN, in its RACS sub-
system, current release 1 specification, deals with this by specifying the RACS for access
networks (see previous subsection for details on the RACS relationship with the distributed
SBC work). In this context, SBC entities can also play an important role in the process of
resource control and management, contributing as enforcement entities and triggering
control actions. This chapter explains how resource reservation actions can be performed,
when SBC entities are located at Access Nodes.
3.2.7.2.1 Call Admission Control considerations

Two types of resource assignment can exist:
• Resources assigned based on an explicit call/session request3;
3
Note that in this case, the CAC request can be signalled by the end device (signalled CAC) or by a
network element in the path (non signalled CAC). Besides, the amount of resources could be indicated
(on demand CAC) or the call/session could just be handled in a homogeneous way (pre-provisioned
CAC).

architecture III
IST - 6th FP
• Resources assigned independently from any request4, to be used freely to the

maximum established by contract and specified in a user profile; this maximum may
or may not be variable with time, depending on the context (access network used,
user being at home or in roaming, network load status, etc.).
The second type of resources will only be assigned after the user has successfully
authenticated with providers, and will be part of the subsequent authorization process. If
several transport classes exist in the network, and depending on the user’s contract with his
provider, resources can be assigned in just one (e.g. best-efforts) or in more than one, or
indeed all of the available classes. This way of allocating resources will simplify network
operation (in comparison to allocating resources in a per call/session basis), where a large
number of flows, with no previous establishment signalling, may exist. The overall maximum
the user will be allowed to use (resources used upon explicit request plus resources
assigned automatically), will also depend on the contract he established with his provider
(NAP or Packager).
Resource requests can be done in several ways. We distinguish three main ones:
• Implicit request;
• Explicit request triggered by terminals and using an appropriate protocol. RSVP is the
best positioned protocol at present;; NSIS is another alternative that is gathering
momentum;
• Explicit request, derived from application level signalling parameters, e.g. SIP or
RTSP and triggered by control elements in the network;
Implicit requests are well suited to flows associated with traditional or legacy applications and
services like HTTP and FTP. For these, a set of rules, which must be downloaded to
terminals and network elements, is associated with user profiles, user preferences and,
possibly with the current context, and will establish the proper actions to be executed
regarding packet classification and marking, policing and shaping. This will most likely be
executed at the first network element that traffic encounters when being delivered to the
network.
Explicit requests via an appropriated protocol require the requesting element to enter an
exchange of messages with network control elements, via an appropriate interface to request
the desired QoS. RSVP is the protocol that was defined for that purpose and adopted by
IETF for the IntServ QoS model.
Explicit requests derived from application level signalling are an indirect way of requesting
QoS, based on the analysis of the signalling exchanged between communicating application
instances; such signalling may or may not include QoS parameters. This can be applicable,
for example, to SIP and RTSP. Through the observation and analysis of the messages
exchanged by the involved elements, like P- or S-CSCF, QoS requirements, the required
bandwidth and the most appropriate network transport class may be extracted. In the context
of this work, this last option is the one of most interest.
4
Note that in this case, there is no CAC but just a Traffic Admission Control; that is, admission of
traffic is not made in base to calls/sessions requests but only to the total amount of traffic (of a given
class, if there are several ones).

architecture III
IST - 6th FP
For resource reservations to take place, controlling entities running CAC functions must have
the following information available:
• Required resources for the flow(s) (bandwidth, buffer space, other)
• QoS expected (all or a subset of loss, delay and jitter)
• Flow description (transport protocol and involved origin and destination IP addresses
and ports)
CAC will be performed based on this information, checking for availability of required
resources in the network elements and segments of interest. CAC can be distributed,
focusing on certain segments of the end-to-end path, or centralized. In addition, different
CAC strategies can be adopted in each of those segments (per flow, aggregate, etc).
In the context of the presented RACS and distributed SBC mapping (see previous section),
we will have, in the simplest scenario, one A-RACF instance, running suitable CAC
algorithms, per access network, having a global view of the resources in the access and
aggregation network:
• It receives explicit QoS requests from all SBCs in the access and aggregation
network;
• It will perform per flow CAC at each end of the communication, in an independent
way (in each of the access network segments involved in the session);
In more complex scenarios, several A-RACFs may exist per access network for example to
achieve a better scalability and perform some sort of load balancing. However, a particular
resource must not be controlled by more than one A-RACF at any given time (no overlapping
resources). At the present moment, a central CAC per access network is being considered
as leading to a better usage of resources and easier control. However, it is also being
considered to have some sort of dynamic CAC decision being delegated to distributed SBCs,
in order to improve scalability and response times of the CAC process.
In the core network, it is proposed to have Admission Control techniques on aggregates,

where resources would be managed by Traffic Engineering and QoS routing:
• It is recommended that the C-BGF operates at flow aggregate level rather than at
flow level;
• C-SPDF and C-RACF will define core network resources distribution to ANs
(ingress/egress to core network, at access/core border nodes interfaces);
The A-RACF may have policies changed, by information coming from the C-RACF, in order
to limit the sessions for a defined destination or to another access network. Central AF and
C-SPDF will deal with inter-domain session establishment.
3.2.7.2.2 Analysis of message flow for resource reservation

In section 3.2.6 a simple exchange of messages is shown for the establishment of a bi-
directional session, e.g a VoIP call, in the context of distributed SBC. SIP INVITE messages,
observed in their transit between caller and callee, do not have enough information to specify
the required resource reservation in both directions:
• IP address of called UA is only known after reaching callee’s P-CSCF (only SIP URI
is known).

architecture III
IST - 6th FP
• Ports to be used to receive media at the callee are not known yet.
• Final codecs to be agreed do depend on terminal capabilities.
• The session may be asymmetric in its QoS requirements.
Some information is only available after the OK is sent by the callee, but this happens only
after the call is answered, in line with the flow sequence defined by the IETF. IMS uses a
rather more complex exchange of messages (including Session Progress and PRACK
messages) to agree on a single codec type in both directions and to have all the other
required parameters to make a resource reservation (protocol, ports and addresses).
It is proposed to use the supported request-commit TISPAN model for resource reservation.
This fits with the three-way handshake SIP message exchange, allowing for an initial
authorization (request) for session signalling to progress, without enforcement at network
level. After session establishment at SIP level, resources can then be committed, and
reservation possibly changed, and the policies to be enforced sent to the network elements.
Two possibilities exist, to extract the QoS requirements and characterise flows:
1. use INVITE (to request) and OK (to commit) messages
2. use OK (to request) and ACK (to commit) messages. This case has all the required
information for doing reservations correctly;
Using (2), may have the effect of a call being accepted by both ends and then rejected by the
network (CAC) because of the unavailability of resources action triggered by the OK
message. For this reason this option is rejected.
Adopting (1) and the two-stage reserve-commit resource reservation model, resources are
requested with the INVITE messages but the resources are committed and policies enforced
only after both ends establish the call (OK). For the request some assumptions have to be
made at this point:
• since no information is yet available from the callee, the session is assumed to be
symmetric (same required resources in both directions);
• resources to be reserved must fulfil requirements for the most demanding codecs
identified in the caller SDP list (or alternatively, assuming it is the preferred one, the
first one in the list is chosen);
• since the callee IP address is not yet known, it is assumed the callee is located in a
different access network from the caller and, thus, traffic will cross the access
network boundary with the core network.
After Commit, policies to be enforced are downloaded to the appropriate network elements,
based on the ports indicated in SIP SDP. Due to the NAPT actions performed by the RGW,
addresses and ports for media streams will change, relative to the ones announced in the
SDP fields. In this way the required filters associated with enforcement rules can either be
set at the end of the process, or set first and then changed as soon as final numbers are
known.

architecture III
IST - 6th FP
With the INVITE, an analysis of the multimedia flow must be performed (see section
3.2.7.2.3), parsing SDP. The process may be enhanced via an improved Gq’ interface,
through which one RACS can signal the requesting P-CSCF (in our context SBC’s BC
component) indicating the media for which resources are not available. As a consequence
those may be excluded from the message to be forwarded to next SIP entity. At the same
time, a soft reservation, to be committed later, may be done for the most demanding media.
Because A-RACF entities do not have to be aware of NAPT issues, and having set
correspondent filters at southbound and northbound interfaces of SBC entities with different
IP addresses and port numbers for the same flow, the BC components must take care of that
correspondence and set the specific filters.
It is assumed both users with respective terminal equipment, have already been
authenticated and profiles been downloaded to the required network elements. The following
resources reservation process is proposed (numbers represent the same steps as in Figure
21):
Step 1.) SIP INVITE received at caller’s SBCa at southbound interface (BCa) (A B
direction)
• SDP analysis must be done at AF (BC entity) to extract QoS requirements. This must
be done identifying the type of service being requested, preferred or most demanding
codecs to be used and other possible QoS information included in SDP. Besides not
knowing the final codec to be used, preferred codecs are, at this stage, only known in
the caller to called UA direction. Following the strategy presented above, it will be
assumed that the session will be symmetric.
• With regard to flow description, at this stage only the caller’s IP address is known.
The callee IP address and final ports are not known. For CAC only the IP addresses
are relevant to know the path traffic will have. Based on previous assumptions, it will
be assumed that the session will be established to outside the access network. IP
addresses to be used by A-RACF entities should be the ones allocated by SBC
(IPsecToA and IPsecToB).
Actions:
• BCa extraction of QoS requirements
• Resource request sent to A-RACFa (via SBCa’s internal A-SPDFa) identifying caller
(IPsecToA)
• A-RACFa decision based on network status (if positive, call proceeds, if negative, call
finishes)
• A-RACFa answer sent to BC1 (via A-SPDFa)
Step 2.) SIP INVITE received at called SBCb, at the northbound interface (BCb) (A B
direction)
Same comments as above with the difference that, at this point, IP address of both caller
and called parties are known.
Actions:
• BCb extraction of QoS requirements
• Resources request sent to the respective A-RACFb (via SBC’s internal A-SPDF)
identifying caller and called entities (IPsecToA and IPsecToB)

architecture III
IST - 6th FP
• A-RACFb decision based on network status (if positive, call proceeds, if negative, call
finishes)
• A-RACFb answer sent to BCb (via A-SPDFb)
Steps 3 and 4.) SIP OK received at SBC entities (BC) (B A direction)

At this point, the call was answered by the callee and, thus, resources can be committed.
With information now coming from (b) the called IP address (after NAT), ports and
preferred codecs for reception are now known. However, the final IP address and port to
be used by the media streams after leaving the residential gateway are not known yet
because it will depend on the NAPT actions to be performed. Thus, filters at ABG level
cannot be set yet with all the required final parameters.
In this context, the BC can set filters on the ABG (via the Ia like interface) but leaving
open the addresses and ports for sending/receiving to/from the RGW in the southbound
interface. This will be set after receiving the first RTP packet from the RGW and the
corresponding RTP flow will be identified by matching destination address/port
(IPfromB/PfromB), since no other flow will use the same pair of values.
In addition, within this step, type and volume of requested resources may be updated (in
order to avoid a call rejection at this point resources have to be made previously for the
most demanding codecs).
Actions:
• Extraction of QoS requirements at both BCs (update on actions performed in 1. and
2.).
• Resources commit sent to A-RACF (via internal A-SPDF) identifying caller (IPsecToA)
and called entities (IPsecToB) and ports (PsecToA and PsecToB) and possibly changing
initial request.
• A-RACF answer sent to BC (via A-SPDF) (if positive call proceeds; if negative call
finishes).
• BC sends to ABG (A-BGF) the QoS actions to be executed, including specification of
filters to be set.
Steps 5. and 6.) RTP packets, received at callers SBCa from southbound interface (ABGa)
(A B direction); RTP packets, received at called SBCb from southbound interface (ABGb)
(direction B A)
First R+TP packet to be received must trigger the actual of reservation now that the final
codecs used are known, and the filters already set in the southbound interface for both
uplink and downlink directions.
Actions:
• Filters change at ABG (BC ABG)
Steps 7 and 8 are not needed.
3.2.7.2.3 SDP analysis for resource reservation

The purpose of SDP is to convey information about media streams in multimedia sessions
and allow the recipients of a session description to participate in the session.

architecture III
IST - 6th FP
An SDP session description includes:

• Session name and purpose;
• Time(s) the session is active
• The media comprising the session
• Information needed to receive those media (addresses, ports, formats, etc)
As resources required to participate in a session may be limited, some additional information

may also be desirable:
• Information about the bandwidth to be used by the session
• Contact information for the person responsible for the session
In general, SDP must convey sufficient information to enable applications to join a session
(with the possible exception of encryption keys), and to announce the resources to be used
to any non-participants that may need to know.
3.2.7.2.4 Provisioning of service information at the P-CSCF

The P-CSCF must derive a media component description within the session information from
every SDP media component. The media component description is a global structure that
contains service information for a single media component within an AF session. It may be
based on the SDP exchanged between the AF and the AF client in the UE. The information
may be used by the server to determine authorized QoS and IP flow classifiers for bearer
authorization and charging rule selection. The following table shows the information that
needs to be parsed from SDP about a media.
Media component description in SDP

Media Component Number
Media Sub Component
AF- Application- Identifier
Media Type
Max-Requested-Bandwidth-UL
Max-Requested-Bandwidth-DL
Flow Status
RS-BW
RR-BW
Table 3: Media component description
The Media Type determines the media type of a session component. The media type
indicates the type of media in the same way as the SDP media types, e.g. AUDIO (0),
VIDEO (1) and DATA (2). To get this information it is necessary to parse the SDP and find
the “m” field associated with the media component description that is wanted to describe:
m=<media> <port> <proto> <fmt> ...
• <media> is the media type.

• <port> is the transport port in which the media stream should be received
• <proto> is the transport protocol.
• <fmt> is a media format description.

architecture III
IST - 6th FP
From here, <port> and <proto> are useful to set filters at network elements.
The Max-Requested-Bandwidth-UL indicates the maximum requested bandwidth in bits per

second for an uplink IP flow. The bandwidth contains all the overhead coming from the
IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.
The Max-Requested-Bandwidth-DL indicates the maximum requested bandwidth in bits per

second for a downlink IP flow. The bandwidth contains all the overhead coming from the
IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.
The RR-Bandwidth indicates the maximum required bandwidth in bits per second for RTCP
receiver reports within the session component, as specified in RFC 3556. The bandwidth
contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and
RTCP.
The RS-Bandwidth indicates the maximum required bandwidth in bits per second for RTCP
sender reports within the session component, as specified in RFC 3556. The bandwidth
contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and
RTCP.
To get all of this information about the required bandwidths to the application it is necessary
to parse the SDP and find the “b” field associated with the media component description that
is wanted to describe:
b=<bwtype>:<bandwidth-value>
This OPTIONAL field denotes the proposed bandwidth to be used by the session or media.
The <bwtype> is an alphanumeric modifier giving the meaning of the <bandwidth> figure:
• “AS”: The bandwidth is interpreted to be application-specific (it will be the
application's concept of maximum bandwidth). Normally this will coincide with what is
set on the application's "maximumbandwidth" control if applicable.
• “RS”: indicates the RTCP bandwidth allocated to active data senders (as defined by
the RTP spec)
• “RR”: indicates the RTCP bandwidth allocated to other participants in the RTP
session (i.e. receivers).
The <bandwidth-value> is interpreted as kilobits per second by default.
The Media Sub Component is a structure that contains the requested QoS and filters for the
set of IP flows identified by their common Flow-Identifier. The Flow-Identifier is defined in
[14]. Possible Bandwidth information and Flow-Status information provided within the
Media-Sub-Component structure takes precedence over information within the encapsulating
Media Component Description.

architecture III
IST - 6th FP
3.2.8 Legal interception

3.2.8.1 Introduction
The objective of this section is to form a basis for Lawful Interception (LI) procedure
scenarios for use by telecommunication service providers and network operators when Law
Enforcement Agencies (LEA) request lawful interception of communications.
The scope of the section is:

• decomposition of the functional elements for performing LI
• LI scenarios for different business models
3.2.8.2 Reference model for interception

Figure 24 shows a reference model for lawful interception, divided into functional elements.
Figure 24 Reference model for lawful interception (see [10]) with possible segmentation of
lawful interception functions

architecture III
IST - 6th FP
Lawful interception example dialogue
Figure 25: Successful call interception diagram
Figure 25 shows the dialogue that takes place to successfully intercept a call. After detection
of call establishment by a suspect user, the Content of Communication Trigger Function
(CCTF) in the softswitch sends a trigger to the (CC-IIF) located in the Access Node.
From the moment of reception of the trigger sent by the softswitch, the CC-IIF duplicates the
communication data and transports it to the MF via the INI3 interface. The MF forwards it to
the LEMF over the HI3 interface. Also IRI data are sent by the IRI-IIF located in the
softswitch, to the MF over the INI2 interface and onwards to the LEMF by the HI2 interface.
3.2.8.3 Scenarios
3.2.8.3.1 Retail model mono-provider session
The retail scenario is the simplest one, in which all functions are performed by a single
operator’s equipment and stay in a trusted relationship. The operator owns a softswitch and
all SIP messages, sent by a retail subscriber, are directed to the Session Border Controller
(SBC), located in the Access Node, and then on to the central server, as shown in Figure 26.

architecture III
IST - 6th FP
Figure 26: Retail mono-provider session
After detection of a suspect user ID in the SIP dialogue, the softswitch triggers the
subscribers’ Access Node, which begins to duplicate data and sends it to the LEMF via the
MF.
Data sent between access node and the MF is transmitted over VLAN dedicated for lawful
interception communication.
3.2.8.3.2 Retail model multi-provider session
MF
MF
Intercept Related Information (IRI)

Content of Communication (CC)
Figure 27: Retail multi-provider session
The assumption is that both operators are requested by LEAs to intercept their own
subscribers’ calls and the other operator has no knowledge about the request received, so
the one who received the request should intercept both incoming and outgoing calls of the
target.

architecture III
IST - 6th FP
After detection of call initiation coming from or to the suspect user the softswitch triggers the
access node, irrespective of whether the call is outgoing or incoming. Trigger messages can
be sent directly from the softswitch to the access nodes because of the trusted relationship.
3.2.8.3.3 Retail model – roaming

Figure 28 depicts a situation where a nomadic user connects to his home service provider
(ASP2) from the foreign ASP1 network.
Figure 28: Retail roaming session
Option 1
After receiving the request from the LEA, the ASP2 passes the request to the roaming
operator (ASP1), which processes the request and performs the interception of a suspect
user as if it was its own subscriber. ASP1’s softswitch triggers the Access Node and the
intercepted data is passed to the ASP1’s LEMF. Both incoming and outgoing calls should be
intercepted by the ASP1’s softswitch (IRI) and Access Node (CC).
Option 2
The ASP2 acts on requests coming from the LEA on its own and using its own infrastructure.
One possible interception point is the operator’s back-to-back peering SBC, as it is the first
node in the traffic flow to the home network.
Such an approach allows lawful interception requests to be actioned without the need to
interfere with other operator’s network and avoids any procedural problems with passing
requests between operators.

architecture III
IST - 6th FP
3.2.8.3.4 Wholesale model
Figure 29: Wholesale model
Trigger messages cannot be sent directly from the ASP2’s softswitch to the NAP’s Access
Nodes because of an untrusted relationship. Furthermore, the “green” operator does not
have the technical means to perform the interception because of the lack of central
softswitch and lack of link to a LEMF. The ASP2 can perform the lawful interception process
entirely within its own infrastructure. The interception point node can be anywhere in the
ASP2’s infrastructure, e.g. Session Border Controller at the edge of ASP2’s network.
Intercepted data is forwarded to the LEMF which is connected directly to the network. Such
an approach allows lawful interception requests to be actioned but avoids problems with
other operator’s hardware.
3.2.9 Benefits and conclusion

There are many motivations to distribute the functions of a central SBC into the Access and
Aggregation Network and in particular to the actual ingress of the NAP infrastructure (into the
Access Nodes).
By distributing the actual checkpoint, the area of the secured (overlay) network is extended
until the Access Nodes as illustrated in Figure 30.

architecture III
IST - 6th FP
Secured Overlay
CPN Network
CPE Application
SBC Server
EN
(router)
Inbound AN
Ethernet
aggreg. NW NAP/RNP Sx
Oubound SIP
#1
ASP1
ASP backbone
CPN
CPE SBC
Ethernet
EN
aggreg. NW (router)
AN NAP/RNP
Figure 30: Extension of secured overlay Network
The QoS control and enforcement are performed at the actual “ingress” of NAP’s network, in
the first “trusted” network element of the network. Shaping at ingress of the NAP network has
the benefit of limiting the upstream load on the aggregation part of the network.
A second benefit is the protection of the softswitch against signalling DoS attacks at network
access (limiting initial upstream signalling rate in ABG).
Generic motivations for decentralization are especially of interest in the distributed SBC
architecture. A better scalability is achieved (smaller number of users per local SBC) and in
case of failure, the number of impacted user is also lower. The robustness is improved
(SPOF for far less users than ABG at edge). Of course resilience techniques will have to be
implemented to redirect users to a spare local SBC in case of failure. This mechanism is
already in place for central SBC today. The same mechanisms for smaller amount of users
should be manageable. It should be noted that in case of failure of an Access Node element,
having a central SBC with redundant platforms it would not be of any help to preserve the
running VoIP sessions since they are transported over IP sessions and need to traverse the
Access Node.
The cost reduction (if well integrated on optimized AN hardware) is the prime benefit and
needs to be better assessed by the MUSE WPA3 work on techno-economics.
Centrally, fewer boxes are needed; the features needed may be limited to simpler control
and policing of aggregate flows. If these functions may indeed be alleviated, they may be met
by simpler router network element and suppress the need for having central SBC removing
its cost impact.
The SIP awareness introduced in the access nodes with the move of the BC part of the SBC
eases integration of resource management across multiple services in the access node
(VoD, VoIP,…) for the first mile.

architecture III
IST - 6th FP
A-RACF (Resource Management) can also be (partly) distributed with a local function in AN
for normal traffic levels and consulting central A-RACF when traffic load above a threshold –
this approach off-loads the central A-RACF.
3.3 Distribution of intelligence to the residential gateway

3.3.1 Motivation
Nowadays, the ETSI TISPAN architecture is considered by both the Network Provider and
academic community as the basic architecture for the deployment of NGNs in order to
achieve Fixed Mobile Convergence, even though this is not yet underpinned by any business
case.
The TISPAN Architecture is based upon the following principles:

• Subsystem oriented architecture
• Separation of the transport layer from the service layer
• Interaction between the transport layer and the service layer via a control sub layer
• Use of IMS as the core service subsystem
• Easier integration of future subsystems
• Use of SIP as the signalling protocol for the IMS services
• Definition of every layer by means of a set of functional entities
This functional architecture, which aims to ensure the correct delivery of multi media
services, is based on the principle of putting all the intelligence, logic of service and service
control within the provider's domain. This principle of considering user equipment as external
components of the network is due to the fact that they are considered non-trusted elements
and therefore a possible source of trouble. This general view, which is currently applied in
mobile and PSTN/ISDN networks, may however be softened in the context of NGN and
especially for fixed access where there are fewer security issues.
While NGN services for mobile users are provided by the means of mobile devices which
have limited capacity (battery life, processing power, etc), these services are provided over
fixed networks via residential/home gateways connecting both SIP devices and legacy
analogue terminals, which are generally more powerful.
The exponential growth of residential gateway deployment by network providers and the
growing computing capability offered by these gateways, lead us to rethink the role played by
these network entities in the NGN context in order to get benefit from their deployment.

architecture III
IST - 6th FP
Considering residential gateways as partially trusted parts of the network and as devices
where some of the TISPAN functionalities may be located, enables providers to take
advantage of residential devices by distributing some of the NGN functions to the RGW and
thereby reducing or even eliminating the need for these in the network itself. This may give
rise to benefits such as cost reduction (OPEX and CAPEX), which is under study by MUSE
Techno-Economics activities (WP A3), optimizing network service architecture and
simplifying network integration. Of course, providing these functions in the RGW could
appear to be a disadvantage if we look at only the RGW. But, when an operator deploys, for
example, an IMS solution, reducing the amount of new equipment required in the network
could be of benefit. The question is where the optimum place for various functionalities is: in
the RGW, in the access network and/or in the core network.
The impact of putting the following NGN functional entities within the RGW has been studied:
• Resource admission and control.
• Authentication of user equipment.
• Quality of Service enforcement.
• First point of contact of the NGN for user equipment5.
• Hiding network topology and information from the terminals.
The proposed architecture resulting from the distribution of the above TISPAN NGN
functionalities to the RGW is depicted in Figure 31.
• E/I/S-CSCF • IWF, IBCF, PDF,

• BGCF, MRFC IBGF, MRFC, MRFP
UPSF
SLF Service Border
Domain Domain
• ARF
• Local A-RACF
• Local P-CSCF
• Local C-BGF NASS P-CSCF
• IP Functions (NAT-PT, NAPT,
DHCP Server)
A-RACF SPDF
Access C-BGF Backbone

RGW
Domain Domain
Figure 31: NGN Architecture with Distributed RGW
5
Note that it has been considered that any terminal is user equipment, whereas the RGW is an
equipment of network (which integrates ALG functionalities within).

architecture III
IST - 6th FP
3.3.2 Impact on AAA

In the context of the TISPAN NGN architecture, a user who wants to use its NGN services
must authenticate himself at two levels: transport and service. Transport authentication
consists of authorizing the use of the network resources. Service authentication consists of
authorizing the execution of some services over the network access. Obviously, if the access
is not authenticated and authorized, services cannot be used.
The transport authentication is a procedure which takes place between the NASS and the
user terminal, based on the user network access credentials. Service authentication takes
place between the service layer and the terminal, based upon the user’s service credentials.
Within the architecture proposed in Figure 31, we propose to perform some of the
authentication and authorization procedures at the RGW level. These procedures aim to
alleviate the network from repetitive tasks.
We will now describe the network access and service authentication in the context of this
architecture.
3.3.2.1 Network Access Authentication

Considering the fact that the RGW is the only device that allows terminals to connect to the
network, we identify two levels of network access authentication. The first one concerns the
authentication of the residential gateway by the network (WAN level). The second one is
related to the authentication of the terminal in the home domain (LAN level).
3.3.2.1.1 RGW authentication

In TISPAN NGN, authentication mechanisms are specified between terminal and the NASS,
which also allocates IP addresses. Since the RGW is considered as a terminal in TISPAN,
we can reuse the authentication schemas defined in the NASS specification.
The authentication mechanism described in TISPAN may be explicit, implicit, or both. The
implicit authentication (which is in fact only an identification process) is done through a
physical or logical identity at layer 2. Explicit authentication is done by an authentication
protocol between the UE and the NASS, such as PPP, IEEE802.1x, PANA, etc. These
authentication mechanisms may also be used to authenticate residential gateways. Once the
authentication is successfully achieved, the NASS provisions the RACS (resource admission
control), especially the A-RACF component, with the attached user network profile
information.
3.3.2.1.2 Terminal Authentication

Once the residential gateway is authenticated at network access level, the user equipment
that is connected to it may be authenticated. Three level of authentication may exist:
• No authentication
• Home Authentication (LAN)
• Network Authentication (WAN)

architecture III
IST - 6th FP
3.3.2.1.2.1 No Authentication (non trusted)

The terminal connected to the home network is not authenticated and directly accesses the
network. This case corresponds for example to computers connected behind the RGW.
3.3.2.1.2.2 Home Authentication

In this case, the terminal is authenticated locally by the RGW. In order to carry out this
function, the network must provision the RGW with all the necessary authentication
information, such as authorized user equipment, etc. This provisioning, which can be done
e.g. in function of predefined profiles, is done during the RGW authentication within the
authentication protocol. The home authentication scenario corresponds for example to
wireless phones (WiFi, Bluetooth, UMTS, etc) belonging to the subscriber and known by the
provider (for example a subscriber that wants to use its 3G phone to access NGN services
over the fixed line). In this authentication schema protocols such as PANA, IEEE802.1x can
be used.
3.3.2.1.2.3 Network Authentication

In this case, the terminal is authenticated by the network (NASS) and the RGW acts only as
an authentication relay. This scenario corresponds for example to a nomadism scenario,
where another subscriber wants to use his user equipment (i.e. his terminal) on a “foreign”
fixed line (i.e. not his own home line), or where a mobile subscriber (3G) wants to access
NGN services by using the RGW of another subscriber. To achieve this authentication
scenario, the RGW needs to be provisioned with some information during its authentication
phase about nomadic profiles6. Moreover, the RGW must implement an authentication client,
such as RADIUS/Diameter client.
3.3.2.2 Service Authentication

Service authentication consists of allowing users to access particular services. This
authentication essentially relies on their subscription data, which contain the list of
subscribed services, parameters such as QoS and the related network access. Service
Authentication is done within the IMS subsystem, based on the credentials provided by the
user when initiating a multimedia session.
In order to benefit from the user service profile information proposed in 3.3.2.1, it is
necessary that the AF communicates with the RACS (especially the SPDF) on a per user
basis, rather than per subscriber basis. For this reason, we suggest adding some attributes
to be carried in the Gq' interface, used between the P-CSCF and the SPDF in the TISPAN
NGN architecture. All these proposals will be detailed in future D TF1.7.
3.3.3 Impact on autoconfiguration and service invocation

3.3.3.1 RGW Auto Configuration
The Residential gateway is provisioned with two types of information:
• Basic configuration information: This information is provisioned by the service
provider information system when the RGW is connected for the first time. This
information may change during the life cycle of the RGW connection.
6
Note that roaming users are not being considered.

architecture III
IST - 6th FP
• User Profile Information: this information is provisioned from the CLF to the A-RACF
when the RGW accesses the network. This information is sent toward the local A-
RACF of the RGW.
The provisioning of the RGW may be done in two ways:

• From the provider (NAP).
• From the NASS, during the authentication phase of the RGW.
The information provisioned on the RGW may contain credentials of the authorized user
equipment, the address of the RADIUS server/proxy and other additional information.
The RGW may include a RADIUS/Diameter client to allow network authentication as

discussed in 3.3.2.1. In the TISPAN NGN architecture, this corresponds to the embedding of
the AMF/ARF in RGW.
Pushing some profile information toward the RGW means locating some of the A-RACF
functionalities in the RGW.
The following schema shows the case of DHCP based network attachment with explicit
authentication.
RGW AMF NACF UAAF CLF RACS
802.1x / PANA
Access Request
Network Location
DHCP Request and

option 120 (RFC 3361)
IP Address Allocation
Network Location
Profile Push
DHCP response ( IP
Address )
Profile Push
Figure 32: DHCP based network attachment with explicit authentication

• The RGW sends an 802.1x (or PANA) request to the AMF to access the operator's
network.
• The AMF translates the 802.1x (or PANA) request into an Access request that it
sends to the NASS (UAAF).
• The NASS (the UAAF) sends to the CLF information about the network location of the
RGW (e.g.: the access line).
• The RGW initiates a DHCP request to get network attachment information like the IP
address.

architecture III
IST - 6th FP
• The AMF forwards the network attachment request to the NACF.

• The NASS (the NACF) sends to the CLF the binding information of allocated IP
address, Line ID and IP edge ID.
• The CLF pushes the Access Profile information to the RACS (the A-RACF).
• The CLF pushes Access Profile information to the RGW (local A-RACF).
3.3.3.2 Terminal Registration

The registration phase is the same as defined in TISPAN, except for the fact that the P-
CSCF is located in the RGW.
3.3.3.3 Service Initiation
UE RGW S-CSCF
INVITE
Resource Control
(SDP Of f er) & Reservation
INVITE
Service Control
INVITE
OFFER
OFFER
Configure
Connection
OFFER
Response Conf
Response Conf Response Conf
Conf Ack
Conf Ack
Conf Ack
Ringi ng
Ringi ng
Ri nging
200 OK
200 OK
200 OK
Start
Media
Ack Ack Ack
Figure 33: Service Session Initiation

• The UE sends a request to the RGW to open a service session (INVITE).
• The RGW performs resource control and reservation (e.g.: admission control) and
forwards the request to a CSCF.
• The CSCF, after controlling several criteria to open the session, forwards the request
to the next hop of the service chain (e.g.: another RGW or the I-CSCF of another
operator).
• The CSCF forwards to the RGW the response to the open request.
• The RGW configures the parameters needed to correctly handle the session and
forwards the response to the UE.
• A standard call flow should be followed to setup the session. Then, the media flows
are sent in both directions.
3.3.3.4 Modification
The procedures defined in [13] section 5.11.3 are valid in our proposed architecture, except
for the fact that the RGW verifies locally (A-RACF, P-CSCF) if the modification is allowed
according to the provider's policy and user profile.

architecture III
IST - 6th FP
3.3.3.5 Termination
The termination procedures defined in TISPAN and 3GPP remain valid in our architecture,
except for the fact that the operations and messages exchanged between P-CSCF/RACS/P-
CSCF are not needed, since these functionalities are implemented internally in the RGW.
3.3.4 Impact on resource management and QoS

The RGW implements a local A-RACF, a function that performs resource and admission
control on the access line and the home network. When the network authentication of a user
is successfully achieved, the NASS provisions the RACS, especially the A-RACF
component, with the attached user network profile information. This means that it sends a
message to the A-RACF in the network (remote A-RACF) and to the A-RACF in the RGW
(local A-RACF).
This information is described in Table 4. According to TISPAN R1, it is sent via the e4
interface (Diameter protocol).
Access Profile Push (CLF A-RACF)

Subscriber ID
Physical Access ID
Logical Access ID
Access Network Type
Globally unique IP Address
QoS Information Profile
Initial Gate Setting
Table 4: NASS A-RACF Information
The information in the table is related to a specific subscriber and does not contain any
information on the user that is linked to this subscriber or subscription. Nevertheless, since a
single subscriber may have several users and each user has specific service profiles, with
possibly different quality of service and other parameters; the information of Table 4 is not
sufficient. Thus it is necessary to add a user service profile information record. This service
profile must contain the authorized services, allowed bandwidth, and other information.
Therefore, the information of the Table 4 could be complemented by the following (hence,
needing to extend the e4 interface):
User Identity
Services
Allowed bandwidth
Other Information
This information can then be used in order to implement policy based management control
within the RACS on a per user basis. Such policy control may for example consist of
dropping a call of a specific user if the bandwidth is not available when a user with high
priority initiates a VoIP session.

architecture III
IST - 6th FP
3.3.4.1 Impact on the home network

The RGW can entirely manage the QoS control in the home network and, more in general,
all the resource and admission control mechanisms for local services (local forking,
admission control, local calls, etc.). This is done via the local A-RACF defined above.
The control is based on the user profiles that are sent to the local A-RACF by the NASS.
3.3.4.2 Impact on the first mile (access line)

For remote services, the local A-RACF can also perform the resource and admission control
based on the subscriber and user profiles and on the resources available on the access line
of the subscriber. According to the operator policy, this function can be critical, especially if
not all the resources available are allowed for a service (e.g.: if the total bandwidth is 10
Mbps and a video session needs 4 Mbps, but only one video session per subscriber is
allowed). In this case, it must be implemented on a trusted platform (trusted RGW) that
makes the operator sure of appropriate behaviour.
Of course, all the other mechanisms needed for the resource and admission control must still
be performed by the remote A-RACF, i.e. the A-RACF of the operator's network.
3.3.4.3 Impact on the aggregation network

The only impact on the aggregation network caused by this architecture is indirectly due to
the mechanisms described above: the load of the remote A-RACF is reduced because
resource and admission control is performed by the RGW.
3.3.4.4 Packet marking

Packet marking can be performed by the RGW in both directions (downlink and uplink). In
the first case (downlink), this function cannot help the QoS management in the aggregation
network and the access line, but it can solve resource conflicts in the home network: for
example, the RGW can implement WMM solutions for a congested Wi-Fi residential link. This
function is not critical, because only the subscriber can benefit from it and the operator
cannot get damaged in case of bad behaviour.
In the second case (control of the packet marking or remarking for the uplink traffic), this
function may lighten the load of some network elements (e.g.: routers in the aggregation
network), but that means that it can be a very critical function. Therefore, it is important to
have a trusted RGW whose behaviour is certified.

architecture III
IST - 6th FP
3.3.5 Conclusion on distributing functionalities into the RGW

There are several motivations for an operator to integrate some network functions in the
RGW. The proposal described above takes into consideration some TISPAN/IMS functions
like the P-CSCF and the A-RACF7. Of course in a more general way they could be called
Signalling proxy, Media proxy, Admission Control and marking. These functions enable
managing several Home network services (e.g. several IP phones, etc.), making them
available for multiservice terminals and locally managing the admission control according to
the subscriber or user profile. In addition, these functions exempt an operator from managing
a plethora of heterogeneous SIP stacks, so that the exploitation of VoIP services becomes
much easier.
Moving functions from the network to the RGW enables lightening the load of network
components. Nevertheless, in case of critical functions, this can only be accepted by using a
trusted RGW, i.e. a component whose behaviour is certified and not modifiable. Therefore,
the estimation of cost reduction must take into account not only the network simplification,
but also the increased complexity of the RGW. This point will be studied in detail in D TF1.7.
3.4 Quality of Experience

3.4.1 Introduction
ITU-T has defined many terms related to Quality of Service and Network Performance in its
recommendation E.800 [17]. Where applicable we reference the appropriate ITU-T E.800
definitions. This should allow readers, familiar with the ITU-T terminology, to understand the
relationship between our terms and the ITU-T definitions.
3.4.1.1 Existing Definitions of QoE

It may be argued that QoE is similar in concept to some of the original intents of the term
Quality of Service (QoS). For instance, the basic ITU definition of QoS, expressed for the first
time in E.800 [17], is “the collective effect of service performance which determines the
degree of satisfaction of a user of the service”. As this definition suggests, the QoS term in
the ITU/ETSI approach addresses not only the objective quality but also the perceived one.
Indeed, in [17], the notion of Network Performance (NP) is also introduced to explicitly cover
technical and objective facets.
Thus the MUSE definition of QoE is that it is a term for highlighting the necessity of taking
into account the end user perceptions, which is what eventually matters, and for considering
the problem of providing quality as a whole, considering not only the network and the
application layers and terminal aspects, but also the user, and their interactions.
Hence, it can be concluded that QoE is a term used for highlighting the need to take into
account the end user perceptions on a per service basis, which is ultimately what matters.
This involves considering not only the network and the application layers and terminal
aspects, but also the user, and their interactions with and experience of the different
services.
7
Other functions could also be implemented in the RGW, like the C-BGF, defined by TISPAN in [11]
and [12].

architecture III
IST - 6th FP
3.4.1.2 What MUSE thinks about QoE

In MUSE Task Force 4 (TF4) there were already some activities to test the perceived quality
by a user of voice and video applications in MUSE phase 1. The focus in TF4 is on full
reference testing, i.e. testing in a controlled environment with access to every piece of
equipment involved. Such full reference testing is valuable to find out how different
parameters (be it network or application parameters) influence the perceived quality.
The relationship between network parameters and Quality of Experience determined in these
tests can then be used in designing networks and defining and/or monitoring the parameters
needed to ensure the targeted Quality of Experience, at least as far as the network can
influence it.
The MUSE partners have agreed to focus the detailed research on those QoE aspects that
are really influenced by the network and leave others (that are also important) to the
appropriate standardisation body. One aspect that MUSE will particularly look at is the
monitoring of QoE, i.e. checking those parameters that are known to influence the QoE.
MUSE will also provide recommendations, such as where in the network the appropriate
monitoring points should be located on a per application basis.
MUSE strongly recommends that, whenever a Broadband Service is offered, the provider
should check all aspects as defined below and try to find a solution that provides acceptable
perceived quality to the subscribers of the service. This deliverable will give detailed
information about network impacts (or references to existing information) and also gives an
overview about aspects that are not network related.
3.4.2 General QoE Aspects

From the users’ point of view, it does not matter whether a service is disturbed due to a QoS
problem (e.g. network congestion) or due to a server problem (e.g. DNS Server congestion).
In both cases the user will experience an unsatisfactory QoE (e.g. a delay in response times
in this example).
For a service provider it is also important to know what QoE is delivered to the customers, as
the SP needs to find the optimal balance between customer satisfaction and resources (i.e.
costs) needed.
Within MUSE phase II the following aspects relevant to Quality of Experience have been
investigated:
• Easy first time service setup
• Easy and fast service start and stop
• Available when needed
• Quality matching the expectations/needs
• Responsiveness
• Consistency
• Security
• Cost transparency
• Reliable and comprehensible billing
• Easy de-installation of a service

architecture III
IST - 6th FP
3.4.3 Applications to be considered

The following applications have been selected for a more detailed analysis at this stage:
• Video, broadcast and on demand, focusing on monitoring issues and especially on
finding the points in the network, where monitoring would be best done.
• Internet Access (Web browsing), this already resulted in an input to the DSL
Forum.
• Interactive applications / Gaming, a comprehensive study has been done.
• Multi Modal and Multi Party services, a first discussion of QoE aspects is included.
3.4.4 QoE for Video

3.4.4.1 Scope
In order to define the scope of this section, we refer to the enhanced Telecom Operations
Map (eTOM) [9] from the TeleManagement Forum (TMF). The functional area within this
map that is relevant here is the so-called “Service Management & Operations” functional
area. It includes the following processes:
• Service Configuration & Activation
• Service Problem Management
• Service Quality Management
• Test Service End-to-End
• Diagnose Service Problem
• Survey & Analyze Service Problem
• Monitor Service Quality
• Analyze Service Quality
Relevant ITU-T Operations and Maintenance concepts are:

• Fault management: defects, failures, and correlation
• Performance management: recording, and threshold crossing alarms
3.4.4.2 MUSE Operator Requirements

To gain insight into the QoE requirements for the monitoring of IPTV services, a
questionnaire was sent out to the nine MUSE operators. The questionnaire addressed
Broadcast TV and Video on Demand IPTV services, and considered four business actors
being involved in IPTV service delivery, i.e. content provider, service provider, network
access provider and the residential customer. The questions were grouped in three sections:
questions addressing service providers, questions addressing Network Access Providers
(NAPs), and miscellaneous questions addressing both service and Network Access
Providers.
Conclusions of the survey:

• A majority of service providers will establish a SLA with the residential user. It is
unlikely that the SLA will include a refund mechanism. The SLA will specify IPTV
data, IPTV control and transport and network performance objectives, such as video
picture quality, channel zapping time, billing integrity, bandwidth, packet loss, jitter or
delay. The demarcation point will be situated either at the Modem/RGW or the
STB/RGW end-device.

architecture III
IST - 6th FP
• A majority of service providers require Fault Management (FM) – defects, failures,

and correlation – and Performance Management (PM) – recording – at the
demarcation point. The collection of FM and PM data is mainly in batch-mode. Some
service providers will collect this data reactively upon fault reports from residential
users, and some service providers will collect FM data in real-time.
• Service providers are concerned with third-party problems, such as home wiring
problems, home network misconfigurations, home network interferences, home
network incompatibilities, home network performance and utilisation fluctuations, and
put in place customer support help-desks and tools to help the residential user who
remains responsible to solve these problems.
• All service providers will establish a SLA with their Network Access Provider. Nearly
all will include refund mechanisms. The SLA will specify transport and network
performance objectives. Some service providers will also include IPTV data and IPTV
control performance objectives. The Modem/RGW is the dominant demarcation point.
Both FM and PM will be collected.
• It is unlikely that NAPs will establish SLAs with residential users. A majority of NAPs
however did express a requirement for FM batch-mode link-layer and transport and
network collection at the Modem/RGW.
• In the miscellaneous section, operators indicated a requirement for the monitoring of
zapping performance and EPG synchronisation, better L2/L3 statistics collection at
the RGW, scalable and configurable FM and PM collection, segmented performance
verification, and multicast control and performance.
3.4.4.3 Requirements
As general requirements for IPTV service fulfilment and assurance, we suggest:
• Ability for the operator to monitor the network performance in between demarcation
points (e.g. IP performance metrics).
• Ability for the operator to monitor the performance of network elements (e.g. routers,
switches).
• Ability for the operator to monitor the performance of IPTV middleware servers (e.g.
load of IPTV servers).
• Ability for the operator to monitor the video and metadata quality of Broadcast TV
services at ingress demarcation points (e.g. quality as received from broadcasters).
• Ability for the operator to monitor the video and metadata quality of add-on content
created by the operator (e.g. mosaic streams).
• Ability for the operator to verify the video and metadata integrity of video-on-demand
content (e.g. archived video files).
• Ability for the operator to diagnose a service end-to-end on a per-customer basis (e.g.
STB logging during a specified period to troubleshoot).
• Ability for the operator to diagnose whether the root cause is inside his domain.
• Ability for the user to diagnose whether the root cause is inside his domain.
For services with IPTV Service Level Agreements (SLAs) the requirements may be more
specific (e.g., pertaining to channel zapping times).

architecture III
IST - 6th FP
3.4.4.4 Approaches
The two high-level approaches are active and passive monitoring. Active monitoring
measures for instance the availability, delay, jitter, packet loss and available bandwidth by
inserting probe packets into the network. The size and number of probe packets should be
negligible compared to the user data packets. In the worst case scenario, the probe packets
are competing with user data flows and affect end-users’ QoS. Passive monitoring measures
for instance user traffic characteristics by observing user data packets rather than inserting
probe traffic into the network. Passive monitoring does not increase the network overhead
and reflects application flows more accurately than active monitoring. However, since it has
to analyse many packets, it can be inefficient and requires system overhead.
3.4.4.4.1 End-to-end performance

This section describes approaches to assess the network and/or service performance as
close as possible to the end-user:
• Monitoring in the set-top box: The set-top box, as the final component in the video
chain delivery (apart from the TV), is an important point for monitoring purposes.It is
the termination point of the video data stream, is responsible for decrypting and
decoding the video data, and runs the IPTV client application. In principle, the
monitoring may include the physical up to the video layers. To relay monitoring
information from the customer domain to the provider domain, the following
approaches may be considered:
o Management plane
Extending the STB object model and communicating via the TR-69
protocol [8]. However, the TR-69 protocol may be too inefficient, for
example for real-time monitoring of broadcast TV services on a large-
scale, and may lack support of the CE industry.
Local management protocol, like UPnP, to relay the monitoring data to
the residential gateway, and then use TR-69 protocol to relay relevant
info to the provider domain.
SNMP, RAQMON or other standardized means.
o Embedded overhead channel in data plane
For instance, termination of RTCP reports at the RTP sender being the
video streamer server(s) located in the head-end of the IPTV video
delivery chain [15].
For instance, snooping of RTCP reports within network elements
• Mid-network monitoring: in this approach the end-to-end performance is estimated,
based on measurements from within the network. Here the monitoring may be up to
the MPEG2 TS layer.
o IPTV middleware
o Proxy set-top box functions
o Protocol snooping
3.4.4.4.2 Segment performance

This section describes approaches to assessing the network and/or service performance
across a segment of the network or up to a measurement probe in the “middle” of the
network.
• Monitoring in the residential gateway. The monitoring information is relayed via TR-69
to the provider domain.

architecture III
IST - 6th FP
• Monitoring in the Access Node. The provider has access to the monitoring
information via his NMS and OSS platforms.
• Monitoring in the video head-end: the monitoring may include up to the video layer.
For example, to verify the presence of logos (e.g. 16+ adult content), to verify the
content against the EPG (e.g. black/white cartoons), to perform base-band
measurements (e.g. audio, black screens).
3.4.5 QoE for Best Effort Internet Access

Currently, broadband access is used mainly for access to the Internet and there are no
guarantees on the quality of service of the transport layer as the Internet itself is based on
Best Efforts (BE) transport. The primary applications are web browsing, e-commerce, email,
and file transfer. The presentation of the data may be audio-visual, graphical or pictorial.
Strictly QoE should be defined for each application but underlying all these applications are
QoE parameters that are related to the fundamental service which is typified by web
browsing. Note that certain applications such as audio and even video streaming, and VoIP
are also attempted over a BE network, but discussion of these types of applications and the
associated network requirements are covered in other Sections.
The purpose of this Section is to identify the QoE parameters which are appropriate to web
browsing, to determine the way in which they are related to network performance and QoS
parameters, and therefore how a superior browsing experience could be offered and maybe
even guaranteed.
The ITU guidelines in ITU-T G.1010 [19] have been taken as a starting point, but as the QoE
requirements are understood in more detail, these could be revised if this would lead to a
significantly better QoE for the end-user. Also refer to ITU-T G.1030 (see [20] and [21] in
particular).
3.4.5.1 BE Internet Access QoE Dimensions

The fundamental QoE dimensions for BE Internet access include the following. Some of
these are network related, but some are dependent on the end-points, e.g. the
characteristics of the application server and/or the end-user terminal.
• Initial system response time: i.e. delay from providing URL to the end-user being
aware that a download has started.
• Data download speed. This is frequently communicated to the end-user by means of
a file transfer dialogue box, or the user may be running a network rate meter of some
kind. For smaller downloads, this can be indicated by the rate at which the screen
updates.
• Consistency of download speed. If the download is at a steady rate, then the user has
a good idea (either intuitively or through a meter) of when it will finish. If on the other
hand the rate varies greatly, then the finish time is much less certain and the user
cannot plan how to use the intervening period so effectively. Note that the underlying
bit error rate or congestion induced packet loss will have an impact on the
consistency of download speed.
• Time before there is some new, intelligible content to view. It is often the case that the
display starts to update before the download is complete. As soon as the user has
some new information to consider, the fact that the download is still in progress is
less important.

architecture III
IST - 6th FP
• Time before the user can undertake the next step in the browsing process e.g. a new
link or action button becomes useable; again this may be before the download is
complete.
• Time until the download is complete. In addition to the download rate, the user
experience is also impacted by the absolute time that a download has taken.
• Usability: Application User Interface (initial set up speed, navigational aids).
• Content: information quality/quantity; information presentation.
• Availability of the content source.
• Security/Privacy: for user, service and network providers and content owners;
security impacts on other dimensions (e.g. encryption/decryption delay).
The key factors affecting QoE in a broadband transport network are the QoS parameters of
throughput, delay and packet loss. Packet loss does not result in data errors at the
application level because best efforts internet access uses TCP, but it will affect throughput
and increase rate inconsistency.
3.4.5.1.1 Factors Impacting Download Rate

It is increasingly common for service providers to compete on the basis of peak access rate.
However, there are several reasons why this rate may not always be seen by the end-user.
Most of the performance limiting factors listed below have yet to have a significant effect, but
they do indicate that beyond a certain limit there is little point in increasing the access rate
alone.
• The TCP protocol. While TCP provides reliable transport (via retransmission) it can
also limit the download rate. TCP uses a sliding window approach, with the window
size being the maximum amount of data that can be sent before an
acknowledgement (ACK) must be received by the sender. Therefore the maximum
throughput is one window size per round trip time. Note also that a certain amount of
upstream bandwidth is also needed for the ACKs, a good rule of thumb is 10% of the
real downstream data-rate. If this amount is not available, either because of a highly
asymmetric access system, or the demands of higher priority applications e.g. VoIP,
then the download rate will be reduced.
• The network provider needs to provide aggregate capacity, and while this capacity
must be able to support the peak access rate for at least some users, it is
commercially difficult to provide too much capacity if the higher peak rates do not
provide additional revenue.
• Many information sources are accessed via the Internet, i.e. at least part of the
Network is beyond the control of the Network Service Provider. Constrained
interconnect bandwidth at Internet peering points can for example become a
performance bottleneck.
• Home networking technology. As access rates approach ~10 Mbps, some Home
Networking technologies, notably some Wireless and Powerline systems, can
become the performance bottleneck. Note also that such technologies are inherently
time-varying at the physical layer (due to time varying noise and interference) and so
can also be responsible for download rate variability.
• The PC itself. The PC can be a performance bottleneck in pure network speed terms,
in addition to the impact of other applications (see below).

architecture III
IST - 6th FP
Non-network dependent QoE factors

These are as follows:
• Application level factors such as the content itself and the way it is presented.
• The speed of response of the server. This will be influenced by the capabilities of the
server to service the quantity of simultaneous download requests it is receiving.
• The speed of response of the DNS server.
• The end-user terminal capabilities will affect the receiving and displaying of data.
• The number of other applications running on the end-user terminal.
3.4.5.2 BE Internet Access QoE Measurement

It is useful to distinguish between the application level factors and those that affect the
downloading experience. If the downloading experience is good it may be that users tolerate
poor content and/or presentation because they can quickly move to alternative websites.
Also their discontent will be directed at the website provider rather than the Internet access
provider. The following focuses on the downloading responsiveness factors.
The responsiveness component of QoE for BE internet access could be measured in 3 ways:
1. Subjectively using a controlled usage experiment and experiment participants who
grade the quality using rating scales such as Mean Opinion Score (MOS), as defined
in ITU-T P.800 (see [23]).
2. Objectively - using electronic testing to measure various downloading experience
aspects.
3. Indirectly - using measurements of network performance parameters (throughput,
delay, packet loss) to estimate the impact on the downloading experience.
Subjective experiments are time consuming and costly. There is some published work on the
relationship between user perception and computer response times. However, it is necessary
to do subjective tests specifically for BE Internet access to be able to quantify some
observable parameters that real systems have to achieve to give good QoE.
For objective measurements the observable parameters are measured at the user terminal.
The authors’ personal experience of downloading suggests that there are a few parameters
that if measured should intuitively relate well to QoE. They are:
1. Delay between entering a URL and indication that a website has been found
2. Delay to first indication of the start of a download
3. Delay to reception of sufficient data for the user to start absorbing information
4. Delay to reception of sufficient data for the user to start using the data
5. Delay to completion of the download
6. Percentage of download cancellations (in relation to Bandwidth and/or Object Size)
7. Response delay variation for interactive sessions (such as gaming)
Parameters 1, 2, 5 and 6 are easily measurable on test data and live data. 3 and 4 could be
measurable by careful design of test pages but for live data would require some mechanism
to detect when data begins to make sense to the user and when it becomes useful.
Parameter 7 can be measured in and out of service.

architecture III
IST - 6th FP
Using measurements of network quality of service parameters to indirectly measure QoE is

problematic. The two network QoS parameters of interest are delay and throughput.
Unfortunately the end-to-end delay and throughput perceived by the user can be strongly
affected by the performance of the server and the user terminal. In addition if the user
terminal is connected via a home network that can also add delay and reduce throughput.
However, it is possible to measure round trip delay and throughput from the server to the
user terminal by exploiting the fact that TCP is used. Simple additions at the user terminal
can allow measurement of the response time (round trip delay) and throughput from the
server. In a live situation if they are outside acceptable limits then it is an indication that the
user would be getting a poor QoE. If they are inside limits then this does not mean that the
QoE is acceptable because the user terminal performance may still be poor.
3.4.5.3 BE Internet Access QoE Guidelines

There has been some work in the past in the ITU on defining QoE parameters for data
transfer applications. These have been simply in terms of delay and error tolerance. The
table below is drawn from ITU-T Recommendation G.1010 (Nov 2001) and gives the delay
figures for different types of data transfer applications. Unfortunately, it is not clearly stated in
G.1010 whether the figures are one way delay from server to user or responses times
although this can be inferred from the application. It is clear that both the amounts of data
and the acceptable delays do not accord with current experience and need significant
revision, however they can be used as the starting point for some basic performance
calculations. Response time variation is also an important parameter, but this is not specified
in G.1010. Figures for this parameter need to be added where applicable when this table is
revised.

architecture III
IST - 6th FP
Application Degree of Typical One-way delay or

symmetry amount of data response time
Web-browsing Primarily one- ~10 KB Preferred < 2 s /page
– HTML way Acceptable < 4 s /page
Bulk data transfer/retrieval Primarily one- 10 KB-10 MB Preferred < 15 s
way Acceptable < 60 s
Transaction services – high Two-way < 10 KB Preferred < 2 s
priority e.g. e-commerce, ATM Acceptable < 4 s
Command/control Two-way ~ 1 KB < 250 ms
Still image One-way < 100 KB Preferred < 15 s
Acceptable < 60 s
Interactive games Two-way < 1 KB < 200 ms
Telnet Two-way < 1 KB < 200 ms
(asymmetric)
E-mail (server access) Primarily one- < 10 KB Preferred < 2 s
way Acceptable < 4 s
E-mail (server to server Primarily one- < 10 KB Can be several minutes
transfer) way
Fax ("real-time") Primarily one- ~ 10 KB < 30 s/page
way
Fax (store & forward) Primarily one- ~ 10 KB Can be several minutes
way
Low priority transactions Primarily one- < 10 KB < 30 s
way
Some guidelines for transport parameters can be deduced from the figures above.
The minimum transmission rate of the DSL section can be computed from the ratio of the
amount of data and the maximum delay. So, for example for acceptable bulk data transfer
the DSL link must at least have a rate of about 8x10MB/60s = 1.3Mbit/s and preferably
5.3Mbit/s.
As mentioned earlier the use of TCP means that the throughput rate will be governed by the
window size and the round trip delay. It is not uncommon to have a round trip delay to a site
on the Internet of the order of 100 ms. The maximum window size in TCP is 65 KB8 (although
it is usually set lower) and so the maximum throughput obtainable in that case is just over 5
Mbit/s. This suggests that providing very high rate access transmission rates may not
actually be of much use for best efforts Internet applications unless the DSL is supporting
multiple simultaneous download sessions or the window scaling option is used. There are,
however, potential problems with too large a window size.
8
Unless window scale option (RFC1323) is used.

architecture III
IST - 6th FP
3.4.6 QoE for Gaming

This section addresses the QoE aspect in multiplayer online gaming; that is, where multiple
players located physically at different places can play the same game, interacting with each
other by means of network connectivity. Henceforth, the terms “multiplayer online gaming” or
“networked game” will be used for this type of application.
3.4.6.1 Multiplayer online gaming QoE dimension

Intuitively one can think that the QoE experienced by a user when playing a game is very
close to the entertainment that the game provides. However, this is very subjective and as a
consequence there is not an accepted unique model for evaluating player enjoyment in
games.
For networked games, it is the “functional playability”, which deals with the manageability of
the game, which has the most impact. In particular, any disturbance of the basic illusion
created by the game will decrease its playability: “If the mediated nature of the game
experience becomes apparent […], the playability of the system is deficient." [41]
The following aspects of functional playability are the most critical in networked games:
• Responsiveness. In networked games, this term is related to the time it takes for an
event to be registered by the affected players. The responsiveness will depend
significantly on the network delay experienced.
• Smooth responsiveness. In networked games, delay can be variable, and hence
responsiveness can vary. It is important to note [30] that players are even able to
adapt to a slow “game pace” provided that it is stable enough, developing a mental
expectation of the lag between when they issue an order and when the order is
effectively executed. That is, a consistent slow response is better than alternating
between fast and slow responsiveness.
• Information consistency. In networked games, consistency refers to the similarity of
the view of the game status by the different players. That is, data describing the
status of the game must be well synchronised, so that no significant difference is
experienced by the various players. Absolute consistency means that each player
has exactly the same information.
Network factors impacting on QoE for games

On the one hand, to achieve high consistency [46], it must be ensured that game processes
running on the remote nodes (where players are located) are tightly coupled. This
synchronisation essentially requires no loss of information. That is, consistency requires data
integrity [2], and therefore the associated traffic should be classified as elastic and interactive
[2].
On the other hand, to achieve high responsiveness, data must be distributed among affected
players as quickly as possible, needing a low network delay. Hence, responsiveness requires
time integrity [2], and the associated traffic should be classified as inelastic and interactive.

architecture III
IST - 6th FP
However games traffic cannot be both elastic and inelastic at the same time; it is not possible
to achieve both high consistency and high responsiveness in a networked architecture (and
in particular in a networked game) at the same time. So it is necessary to prioritise one of
these QoE targets over the other, and the choice of network architecture will reflect the trade-
off between these two aspects.
Because of the need for real-time interaction, responsiveness is the critical element in
networked games and consistency may have to be compromised. Therefore the event of
high network delays will mean sacrificing consistency for the benefit of responsiveness. This
will lead to having loosely coupled nodes; that is, impairment of data.
However, the use of intelligent prediction algorithms in the game engines can compensate
for loss of information, leading to a higher consistency as perceived by the players.
With regards to smooth responsiveness, this requires a stable delay. It is common to

sacrifice mean delay in order to guarantee a low delay variation (a.k.a. jitter). Therefore,
different nodes involved in a game try to adapt to the one which suffers the longest delay by
means of using buffering techniques [30]. However this technique must be used only up to a
certain limit, in order not to make the game completely unplayable for all the users.
It can be concluded that responsiveness, and more precisely a smooth or constant

responsiveness is the primary QoE factor for games. Consistency is also desirable but
should take second place to responsiveness. Hence, networked games traffic should be
placed in the “real time” traffic class, which is inelastic and interactive, and the network
should handle this traffic in the same way as real-time voice and video communications (or
even better).
Non-network dependent QoE factors

Design decisions can have dramatic consequences for the QoE of networked games.
Obviously, a good and smart design of the game is fundamental, and up to now, it has been
demonstrated by game coders that even with the BE Internet, a sufficient QoE can be
provided.
From the point of view of game developers, network conditions are just one constraint that
they must work with. An appropriate balance between network and computational resources
must be looked for, and at the end, there is always the possibility of reducing the more
ambitious goals that the game had; that is to say, to redefine the problem that needs to be
solved.
The network architecture will have an impact on the amount of information exchanged and
the delays. For instance, in pure peer-to-peer architectures communication flows directly
between peers, hence obtaining a minimum delay but with an increase in the amount of
exchanged information (this can be reduced sometimes by using multicast/broadcast
network techniques). Conversely, in pure client-to-server architectures, communication does
not flow directly between all the nodes, and hence the communication delay is longer and the
amount of exchanged information is lower. It is also possible to find intermediate
approaches.

architecture III
IST - 6th FP
There are also other design decisions that - although not directly related to the network can
improve considerably the QoE even when having a best-efforts network.
As with any communication service, an effort is made when designing a game to minimise
the amount of information that has to be transmitted through the network. Unlike voice and
video communication, where codecs must deal with anthropomorphic constraints, networked
games are not so constrained, as their goal, which is to implement a virtual environment, can
be relaxed as much as needed to adapt to actual technology possibilities.
A commonly used technique consists of distinguishing between deterministic and non-

deterministic (random) events. The point is that deterministic events can be locally predicted
by replicating in each node the game rules and the deterministic information, whereas
indeterminate events, which are associated with players’ inputs, are produced in any node
and must be communicated to all the other nodes, in order to maintain consistency.
According to the “Networked Virtual Environment Information Principle” [43], the amount of
consumed resources of a networked application is directly related to how much information
has to be sent and received by each participating node and how quickly it has to be delivered
by the network. This can be formalised by the “Information Principle Equation”:
Resources = M × H × B × T × P
where M is the number of messages transmitted, H the average number of destination nodes
for each message, B the average amount of network bandwidth required for a message to
each destination, T the timeliness by which the network must deliver packets to each
destination (large values of T imply a need for minimal delay and vice versa), and P the
number of processor cycles required to receive and process each message.
This equation can be used to trade-off requirements and constraints. By lowering any of the
five variables the network resource demands decrease. However, when one of the variables
is reduced, the QoE may be affected, hence needing to increase another one to compensate
for the loss of QoE.
In [42] a comprehensive review of the current techniques used by game coders to

appropriately balance the different variables of the Information Principle Equation is
presented. The techniques are the following:
• Packet compression
• Packet aggregation
• Interest management
• Dead reckoning
Finally, another important design decision is related to fair play and especially with cheating,
which can be very annoying for the players. For this reason, client-to-server architectures are
mostly preferred, as the server can perform anti-cheating activities or monitoring.

architecture III
IST - 6th FP
3.4.6.2 Multiplayer online gaming QoE measurement

There is no unified way to measure the QoE, or playability, of networked games. There exists
some proposals, such as the OPScore (Online Playability Score) model from UbiCom [47],
which indirectly, via measurements of network performance parameters such as the one-way
delay from client to server, jitter and packet loss, and using a Gaming- or G-model (similar to
the E-model described in [18] for predicting the perceived quality for VoIP applications), try to
estimate the impact on the playability of a networked game.
It is necessary to mention that a G-model for FPS games has also been obtained in MUSE
TF4. This G-model is based on the conclusions, extracted from subjective experiments, that
a large ping time (a measurement of the round trip delay) and jitter have a negative impact
on the MOS, on the acceptability of the gameplay and on the number of kills performed by a
given player, whereas packet loss has no relevant influence.
The MUSE TF4 G-model9, extracted from eight gaming sessions between TNO and Acreo,
and with a correlation factor of 0.92 with the MOS obtained via subjective inquiry is the
following:
MOS_gaming = -0.00000587 x3 + 0.00139 x2 - 0.114 x + 4.37

where x = 0.104 ping_average (average of 200 pings in ms)+ jitter_average (average relative
delay in ms, w.r.t. fastest packet over 300 UDP packets)
With regards to subjective measurements, MOS is commonly used. In fact, in [32] a MOS
scale for gaming is defined:
MOS Description
1 unacceptable environment
impossible to play game
2 very annoying environment
server change necessary
3 clearly impaired environment
although still acceptable
4 minor impairment noticeable
very good environment
5 no noticeable impairments
perfect environment
Networked games QoE is normally measured by means of subjective or indirect tests. It is

obvious that objective measurements are not easy to obtain, because of the high interactivity
nature. From the above discussions, it is clear that the most important network performance
parameters to be monitored and controlled for networked games are the delay and the delay
variation (jitter).
3.4.6.3 Multiplayer online gaming QoE guidelines

First Person Shooter (FPS) games, Role Playing Games (RPG) and Real Time Strategy
(RTS) games are the most popular genres that are played in a networked way.
9
Results to appear in the TF4 test suite.

architecture III
IST - 6th FP
It is rather difficult to provide quantitative details, as literature [29], [30], [35] and [38] provides
different opinions. The main difficulty is that every game title is unique in design, and
although it can be classified in a given genre, responsiveness requirements are highly
dependant on the ability of the coders and the game design. Indeed, similar conclusions are
obtained in [32]. Because of that, some numbers are provided, extracted, as a rule of thumb,
from the different literature previously mentioned and from intuition. These numbers are
rudimentary values, which might need to be refined through measurements in the future.
In an FPS, the main goal is typically to kill enemy players. A player can only sustain several
hits, depending on the used weapon, which results in the need for fast reflexes and short
reaction times. That is, high responsiveness is especially required, needing a low network
latency, which in general is recommended not to be higher than 100-200ms.
In an RPG, one of the main goals is to develop a chosen character by increasing abilities and
gathering new equipment. These goals are achieved by means of exploring new regions of
the virtual world, killing monsters, and sometimes by fighting with other players. Collaboration
with other players is also a way of acquiring the necessary experience for increasing abilities
or to gather power enough to defeat a great enemy. Unlike FPS games, combat is not so
much based on reflexes but in the used abilities and equipment. Thus, the same kind of high
responsiveness as in FPS games is not needed here. Notwithstanding, it is convenient to
have a low enough network delay so that the game can progress in an adequate pace, and
to keep information consistency. The maximum tolerance would be in the range of 200-
500ms.
In an RTS, the virtual world has a given amount of resources which are harvested by the
players in order to be able to create units. These units can be instructed to take some
actions. In this way, players compete with each other to achieve a specific goal in the game
or just to destroy all the enemy units. Combat is more based on an adequate strategy.
Indeed, units can automatically respond to attacks, such that reaction times are not as high
as in FPS and RPG games. However, and for the benefit of the information consistency, an
adequate gameplay pace, and the micromanagement, network delays should not be greater
than 500-1000ms.
Hence, it seems that in general, FPS games are the most demanding, in terms of
responsiveness, whereas RTS would be the least demanding. Fortunately, FPS games are
normally less demanding in terms of information consistency, as they are played on virtual
worlds where long-term state is not so relevant, and the main goal is based on achieving
short term goals, that is, to kill and not to be killed. These games can benefit from dead
reckoning techniques, sacrificing consistency in order to provide faster responsiveness.
Responsiveness Consistency Delay

FPS Highest Lowest 100-200ms
RPG Medium Highest 200-500ms
RTS Lowest Medium 500-1000ms

architecture III
IST - 6th FP
3.4.6.4 Networked games platforms as a business opportunity

Nowadays Massive Multiplayer Online (MMOs) sub-genres of RPG, FPS and RTS
(MMORPG, MMOFPS and MMORTS) are becoming very popular especially as a
consequence of broadband access adoption, creating virtual worlds populated by many
players simultaneously.
An MMO game is a networked game with two distinguishing characteristics. The obvious one
is the number of concurrent players, which is typically very large, from some hundreds in
MMOFPS and MMORTS games to several tens of thousands in MMORPG ones. The
second characteristic is that MMO games have persistent state, allowing players to enter or
leave the game asynchronously without disturbing the gameplay.
There are many reasons for designing controlled client-to-server architectures in the case of
games: allowing MMO playing, neutral arbitration, anti-cheating, isolation of communication
problems (the server being the critical part), creating (real) economy for the virtual world, etc.
In this way, it is very convenient to strategically decide the physical placement of servers.
Because of this, network operators are starting to offer housing and networking facilities to
game developers so that they can put the servers closer to the players and in privileged
conditions, which will ultimately benefit the overall QoE.
It is important to note that games take their own delay measurements. In this way, the
provisioning of common measurement facilities by game hosting platforms may alleviate the
games coder task and provide also a useful mechanism to allocate responsibilities in case of
detecting problems.
3.4.7 Multi modal / multi party QoE

3.4.7.1 Introduction
Most applications and services that are established via a communications network today are
still limited to single mode and/or a 1:1 participation scheme and/or lack any interactivity.
Examples are:
• Voice communications, which are mainly 1:1, single mode but highly interactive.
• Broadcast TV (BC TV), combining audio and video but statically delivered to the end-
user, with no interactivity with other end-users.
For these services the Network requirements and technical means to ensure a particular
QoE are mostly well understood and with respect to objective QoE assessments relevant
metrics and models have been or are being defined, e.g. the E-Model [18] provides a
prediction of the expected voice quality, as perceived by a typical telephone user, for a
complete end-to-end (i.e. mouth-to-ear) telephone connection under conversational
conditions. As another example, the VQEG (Video Quality Expert Group) is working in the
field of video quality assessment and is well on track to standardize an objective quality
estimation tool for digitally compressed video.

architecture III
IST - 6th FP
Multi-mode/multi-party (MM/MP) applications bring however additional complexity with

respect to overall QoE assessment and minimum QoE offering, and some issues will be
discussed in the remainder of this section. Some well-known applications that can be
considered as MM/MP are video conference calling (today mostly 2-party) and multi-player
network gaming and further on we will describe some novel MM/MP applications that can be
offered in an IPTV deployment taking advantage of a converged triple play offering and
architecture.
3.4.7.2 MM/MP QoE assessment (subjective and objective)

There are ITU-T recommendations available giving guidelines on how subjective tests should
be carried out for interactive and non-interactive audio-visual communications, in order to
have a consistent way to generate MOS (Mean Opinion Score) values by test audiences
(e.g. see [23], [24], [25] and [26]).
ITU-T J.148 (see [22]) details the general requirements for the development of an objective
multimedia perceptual quality model, specifically an auditory-visual model.
Recently NTT researchers proposed an audio-visual objective model which includes the
interactivity aspect:
MOS MM = (a + bMOS A )(c + dMOS V )(e + fMOS R )

with MOSR=g exp(-D/h)+i and D =delay ; MOSA = the MOS score for the isolated audio part
and MOSV = the MOS score for the isolated video part and a, b, c, d, e, f, g, h, i, all constants
with the value depending on the kind of application and the type of content.
The multiplicative nature inside these objective models indicates the importance of an inter
media quality balance for multi-mode applications; e.g. no matter how good the video
quality is, a bad audio quality will ruin the multimedia QoE.
The inter media synchronisation, or lip synchronisation, is of course also an important

aspect co-determining the overall multimedia QoE. With respect to audio-video
synchronisation, in ITU-R BT 1359 (see [16]) a graph is shown based on subjective
experiments on how the end-user is impacted by a relative time difference between audio
and video image. It was found that the delay between audio and video has to be less than
150 ms if video advances audio and less than 70 ms if audio advances video.

architecture III
IST - 6th FP
FIGURE 2
Detectability and acceptability thresholds
C Undetectability plateau C'

0
Subjective evaluation results (Diffgrade)
Detectability threshold
B B'
– 0.5
–1
A Acceptability threshold A'

– 1.5
Sound delay wrt Sound advanced wrt
vision vision
–2
– 200 – 180 – 160 – 140 – 120 – 100 – 80 – 60 – 40 – 20 0 20 40 60 80 100
Delay time (ms)
1359-02
Figure 34: Detectability on audio-video desynchronisation (ITU-R BT.1359)
For a multi-party application additional aspects that determine the overall QoE of an
individual participant (besides the media quality) are:
• Inter-destination quality balance: the QoE by an end-user communicating in a

single multi-party session with several other persons will be determined by the sub-
session exhibiting the lowest QoE; also the overall MOS will exhibit a multiplicative
relationship. This is depicted in the figure below.
Figure 35: Inter destination quality inbalance for a video conference call
• Inter-destination synchronisation: All participants of a video/audio conference call

should be presented the same audio/video information at the same time.

architecture III
IST - 6th FP
3.4.7.3 New MP/MM IPTV applications

Amigo TV
AmigoTV provides a community experience sharing created on top of Broadcasted TV (BC
TV). One can describe this application as a mix of a multi-party audio conference call,
combined with instant messaging in overlay with the BC TV service. The TV is hence the
central device of communication, and the community of viewers can chat with each other
(voice in overlay with BC TV audio) where the BC TV display’s content can be the subject of
the conversations and emotion sharing. The TV channel each participant is currently
watching is shown on their friends’ TV screens by means of an avatar (graphical presentation
of the person, his/her personality and mood). Buddy lists can be created, so that one can
control who belongs to his or her community.
Besides overall video and audio quality requirements, there are some particular challenges
to ensuring a certain degree of QoE for the AmigoTV application:
• Inter destination synchronization of BC TV: the reactive nature of AmigoTV with
respect to displayed contents on BC TV requires that BC TV should be
“synchronized” among all end-points. E.g. if a soccer team scores a goal, each
AmigoTV participant in the session should see this on TV before some other
participant reacts to this goal through cheering (or cursing).
• Inter destination quality balance: similar to audio conf calls, the worst audio quality of
a single contact will determine the overall audio QoE experience.
• Note also that BC TV channel “joins” issued by the STB upon channel change by any
participant should be notified to the amigo TV server middleware in real time (which
will then signal this change to all participants), because of the interactive aspect.
Participation TV (Participate!)
With this application all participating IPTV end-users within a small community (e.g. your
friends) truly interact with video / audio contributions. Format examples include quizzes,
charades (where people must guess e.g. what proverb one participant expresses by using
non-verbal (body) language), auction TV (Ebay-on-TV), truth-or-dare, MP karaoke/singing
contest. It includes a format creation environment and provides network-centric real-time
switching of voice, video, and format events as all video and audio flows are forwarded to a
network element, a so-called media reflector. The participation TV architecture consists of, in
addition to these media reflectors, of a format orchestration building block (=engine) and
IPTV proxies performing the mixing, synchronizing (video +audio+ messaging) and the
optional transcoding. The Participate! architecture is depicted in the Figure 36, below.
The specific challenge is that a certain participation community may consist of participants
that are connected via different dedicated delivery networks (Best effort Internet, IPTV and
mobile). This means also that QoE expectations and requirements may be different per
participant, and that inter destination quality balance is not always feasible from the view
point of IPTV-connected end-users which are provided with the largest bandwidth and the
best QoS treatment.

architecture III
IST - 6th FP
Figure 36: High Level Architecture for Participate!
3.4.8 Conclusion
A measurable QoE would allow feedback on customer satisfaction.
This goal is not easy to be reached, as different services will produce different QoS
requirements to achive a good QoE. The following table summarizes the most important QoS
Parameter per Service:
VoIP low delay
Web Browsing low packet loss
Gaming low delay
IPTV low packet loss
Network providers need to be aware of QoE during installation of a service (and the
according network) as well as during the run time of the service.
During service installation, a provider needs to know, what QoS Parameters he needs to
reach for achieving the desired QoE. This can be done by looking at tests that have been
conducted (e.g. in MUSE TF4) or by doing own tests during the test and trial phases.
During service run time, there are several possibilities to get feedback on the QoE per
service.
The discussion above shows some of the possibilities, most of them relying on
measurements done at the customer premises either in the RGW or in the terminal (e.g. set
top box). The mapping of the measured QoS values to the Quality of Experience (QoE) for
the end user is an exercise that each provider needs to do on his own. This can be based on
existing mappings or a provider can start to derive his own mapping by correlating his
measurements with the satisfaction of his customers.

architecture III
IST - 6th FP
4 INTRODUCTION OF FMC CAPABILITIES

Fixed-Mobile Convergence (FMC) is a very broad term describing how fixed broadband
access networks and mobile networks may converge in various ways. There exist a plethora
of descriptions of this (see [1] and [3]). In this deliverable FMC is treated from a network
perspective and addresses network mechanisms that must be in place to make FMC
achievable from a fixed broadband provider perspective.
In MUSE there is very much work in progress and the results described here are a snapshot
of the current achievements that includes the definition of use cases and the resulting
requirements, AA aspects, options for mobility management (session continuity) and a high-
level description of the MUSE FMC architecture.
4.1 Use Cases

In this chapter, four use cases for FMC are presented. Although technology aspects should
in general be left out from a use case in order not to limit possible technology choices
beforehand, in some cases specific technologies are mentioned, since the focus of MUSE on
FMC is rather clear (roaming, session continuity and AAA issues between fixed and wireless
networks).
The goal of the use cases is to find out what kind of FMC scenarios may become realistic in
the future and what impact this could have on the requirements on the architecture. These
requirements include how sessions are handled and AAA is done but also policy aspects as
well as roaming.
Sections 4.1.1 to 4.1.4 describe the use cases, three related to nomadism and one more
related to session continuity. In section 4.1.5 a number of requirements are provided that
have been derived from these use cases.
4.1.1 Use Case 1 – Nomadism use case with video call

Jose, has a broadband access with high speed Internet to his home and subscribes to two
services; IPTV and video-telephony with two lines10 with nomadic features. He is visiting his
mother. As a nomadic user, he will be able to access his subscribed services from different
locations. In his parent’s house who also have a High Speed Internet (HSI) subscription, he
starts his parents PC and access the Web portal of this Service provider (packager)
authenticates himself (by means of a token or a username/password) and due to a nomadic
feature of his services, he has access to all his services according to his service profile.
He then initiates a video over IP call from the PC to his video capable multimedia phone at
home using his own subscription to let his wife know his whereabouts. Next he uses the
Internet to access his media-centre (can be in his CPN or at another location), where he has
stored all the pictures from his daughter’s last birthday, and shows it on the TV screen at his
parents home. After watching the pictures he decides to leave his parents house to watch a
very important football match at home.
10
Two lines mean that the service subscription allows two simultaneous phone calls (not necessarily
on different access lines).

architecture III
IST - 6th FP
Home of Jose's mother Jose's home
Access network
Access network
Home Gateway Home Gateway
settop box
Photo viewer
Television
Computer Computer
Figure 37: Jose showing his mother the photo's of his daughter’s birthday
4.1.2 Use Case 2 – Nomadism use case with IPTV
José's home Manolo's home
Access network
Access network
Home Gateway Home Gateway 1 2 3

4 5 6
7 8 9
* 8 #
settop box settop box
settop box
Television
Television
Television
Figure 38: José moving from his own home to his friend's home and continues watching a pay
TV soccer match there

architecture III
IST - 6th FP
4.1.3 Use Case 3 – Session Continuity with conversational services

4.1.3.1 Short term scenario
Bob works for a company that has customers all over the world. Bob can do most of his work
at home, but sometimes he prefers to be at the company office to consult with a colleague or
to meet a customer.
This afternoon he and a colleague have an appointment with a customer to discuss a new
project. He decided to walk to the company building as he lives only 2 km away.
As he is about to leave home his multimedia IP phone rings, the phone is connected to his
wireless home network that is connected to the fixed access network. On the display Bob
sees that his colleague is trying to reach him via a video call. Bob decides to answer the call
in video mode. His colleague tells him that he will probably be a bit late to the meeting.
While they discuss some details for the meeting, Bob leaves home. Shortly after, his phone
gets out of the reach of the wireless home network…
(At this point the scenario can be extended with text given in section 4.1.3.2)
…soon, the phone is connected to a WIMAX (or UMTS) base station. Since bandwidth is
more expensive on this network, Bob receives a message on his screen asking whether he
wants to continue with the video path. Since video is not really important while walking, Bob
decides to save money and tells his colleague that he will end the video part of the call. The
audio path stays active, so they will be able to continue their conversation. Then he activates
a setting on his phone that will re-establish the video path as soon as the costs of bandwidth
are low enough again.
Company's
building
Bob's home
Park
Access network
Home Gateway
802.11b/g
audio + video
audio+video
Wifi / WiMAX / UMTS
audio
Figure 39: Bob's walk to the company's office; without extension

architecture III
IST - 6th FP
Arriving at the company’s site, the phone connects automatically with the company’s wireless
network and the video connection becomes active again. At his office he transfers the
running video call from the mobile terminal (WLAN, WIMAX, UMTS) to his Notebook
connected to a fixed access network.
4.1.3.2 Possible longer term scenario: WLAN Hopping

The text below is a possible extension to use case 3 for a more advanced longer term
scenario. It introduces private WLAN to private WLAN hopping.
…and starts searching for other wireless LANs in order to continue the video call session.
Like Bob, all neighbours in the street have one or more wireless access points in the house.
They may allow their network service provider to offer network access to strangers over their
access point and access network using the bandwidth that they (temporarily) do not use
themselves; of course under the condition that they are not faced with service degradation or
security threats. Operators might give discounts to people who let the operator do so. For an
operator it is a good excellent way to extend the coverage of his network in a cheap way and
to be able to offer nomadic services. Bob’s phone soon finds a private wireless access point.
He has a subscription with his packager that allows him to connect to the Internet and to
continue the video call. While walking down the street, his phone roams from one access
point to another and he is able to maintain his connection and call, possibly with some short
breaks when roaming between the WLAN access points. Having reached the end of the
street, Bob has to cross a small park to reach the company buildings. Now, the coverage of
private WLAN gets poor and the phone searches for other wireless networks.
Company's
building
Bob's home Bob's neighbors
Access network Park

Access network
settop box
802.11b/g
802.11b/g
Television
audio + video
audio+video
Wifi / WiMAX / UMTS
audio + video
audio
Figure 40: Bob's walk to the company's office; with extension for a longer term scenario

architecture III
IST - 6th FP
4.1.4 Use Case 4 – Nomadic user with public access to private domain
This use case is about private users offering public access to visitors. In fact this aspect is
already taken into account in the longer term scenario of use case 3.The difference is that
use case 4 does not involve any session continuity aspects, while the longer term scenario of
use case 3 does.
4.1.4.1 Use case description

After the meeting at the office Bob returns home. Walking through the park he feels a bit
hungry. He remembers that his refrigerator is almost empty and that there was no time left to
go to the supermarket. Fortunately, there are some very good food delivery services
available in his area. He decides to order a pizza via the website of ‘Mario’s Pizza Place’,
because the pizza’s on the website looks always very tasty. When he comes near the
houses on the other side of the park, he turns on his multimedia device which searches for
available WiFi networks. Some of the houses nearby provide public access over their private
WiFi network. According to the network settings on his multimedia device, Bob gets
connected to one of these networks and orders the pizza over the Internet. Bob now has a
comfortable 20 minutes for his walk home.
Private network owner who Company's

offers public network access building
Bob's home
to visitors
Access network Park

Access network
settop box
802.11b/g
802.11b/g Television
Wifi / WiMAX / UMTS
Bobs multi media device
Figure 41: Bob uses a public access to a private domain
4.1.4.2 Use case business scenarios

This section describes how different players can be involved in the authentication process of
Bob who is visiting a private network of somebody else. From here, Bob will be referred to as
the Visitor; the owner of the private network will be called the Host. Two different scenarios
are presented. In both scenarios the Host is authenticated first at network level by the Host’s
ISP. After the Host has been authenticated, the Visitor is authenticated by either a third party
AAA-provider (described in the first scenario) or the Visitor’s own NSP who is directly
connected (possibly through a proxy) with the same NAP/RNP/CP as the Host (this
described in the second business scenario).

architecture III
IST - 6th FP
Business scenario 1: Third party AAA-provider deals with visitor’s authentication

In the scenario as depicted in Figure 42 a third party AAA-provider, connected via the
Internet with the Hosts ISP, deals with the network level authentication of the Visitor.
Therefore Visitors as well as Hosts must have been registered with the third party AAA-
provider earlier. After a Visitor has been authenticated, data traffic may pass the Host’s
access point.
Regarding the opportunities to support QoS in the network, two variants of this scenario can
be distinguished:
Variant 1: The third party AAA-provider has a business relationship with the Host’s ISP
and/or NAP/RNP/CP.
In this variant it is possible to make QoS arrangements in the NAP/RNP/CP network for both
the upstream and downstream direction, e.g. by letting data traffic flow over a separate
VLAN. The network providers involved may receive compensation for traffic that is initiated
by the Visitor.
Variant 2: There is no business relationship between the third party AAA-provider and the
Host’s ISP and/or NAP/RNP/CP.
If there is no relationship between the third party AAA-provider and the network service
provider, it will be hard to take QoS measures in the network. However in the upstream
direction the Host’s user traffic can be protected by setting QoS parameters in the RGW.
In the case where the RGW is provided by the ISP it is likely that the RGW and the access
point are separate devices.. In the case where the RGW is provided by the third party AAA-
provider the RGW functionality and access point functionality may be in one device and
some QoS can be provided.
Visitor
ASP
Application
Service
Visitor AAA NAP/RNP/CP
Access Point
TALK / DATA
TALK RS CS TR RD TD CD
Host AAA
AAA-proxy-Server
Host ISP
RG Regional
Network
Access
Node Edge
VoIP
Node AAA-Server
Laptop
Internet
network
Third party
AAA-provider
AAA-Server
Figure 42: Third party AAA provider deals with the visitor's authentication

architecture III
IST - 6th FP
Business scenario 2: Visitor’s service provider deals with visitor’s authentication

In the business scenario presented in Figure 43 the authentication of the Visitor is carried out
by the Visitor’s own ISP. In this case the Visitor’s ISP and the Hosts’ ISP have the same NAP
who may use a proxy radius server to route the authentication messages to the
authentication server in the right domain.
In this scenario QoS may be supported, e.g. by separating the Visitor’s traffic and the Host
traffic in different VLANs.
Visitor's
ISP / ASP
Visitor
AAA-Server
ASP
Visitor AAA Application

Service
Access Point Host AAA

TALK / DATA
TALK RS CS TR RD TD CD AAA-proxy-Server
Host ISP
RG Regional
Network
Access
Node Edge
VoIP
Node AAA-Server
NAP/RNP/CP
Laptop
Internet
network
Figure 43: Visitor's own service provider deals with the visitor's authentication
4.1.5 Resulting requirements

Below, a number of high level requirements, deduced from the use cases in section 4.1.1 to
4.1.4, are formulated:
[Req.1] A user should be able to access (a subset of) his services from an arbitrary network
connection.
[Req.2] Authentication should be done based on credentials.
[Req.3] If a nomadic user is allowed to use the access line of somebody else, sufficient
measures should have been taken to protect the privacy of the owner of that
network (including the protection against malicious attacks on devices that are
connected to the owners home network).
[Req.4] The nomadic user must have secure connectivity to each visited network.
[Req.5] It should be possible to temporarily increase the bandwidth of an access line in
order to support the services of a nomadic user.
[Req.6] DRM issues should be solved when a nomadic user is allowed to watch content
from an arbitrary terminal and/or from an arbitrary network connection.

architecture III
IST - 6th FP
[Req.7] It should be possible for services to know if the available bandwidth has been
changed in order to do media adaptation.
[Req.8] The network should support session continuity. Note: The short term focus within
MUSE is to work on nomadism and session continuity, however continuous mobility
can be considered as an option to be investigated in MUSE.
[Req.9] A user should be able to select the service type and the combinations of them based
(audio, video etc.) on the network environment.
Extra requirements, not included in use cases:
[Req.10] It should be possible for services to know if the user has changed his terminal in
order to make adjustments in the media flow.
[Req.11] The location of the user must be known by the network, even when session
continuity or continuous mobility is the case. (eg. for use with emergency calls).
[Req.12] Nodes in the network must provide high resistance against spoofing and DoS
attacks (partly covered by Req.3).
[Req.13] The policy control function must be informed when a nomadic user obtains
connectivity.
[Req.14] Successful authentication must precede interaction with policy control function.
[Req.15] Charging/billing may be adjusted depending on the type of access used.
[Req.16] The network and the terminal should have the capability to communicate the service
level based on the physical connection.
4.2 Authentication and Authorization

In the new scenarios that appear under the FMC framework, AA plays a very important role.
Network operators should move from the existing AA methods in which lines/circuits are
authorized, into a new scenario in which individual users are authenticated and authorized.
This process should be independent (or at least as independent as possible) of the location
of the user, enabling the nomadicity of the customers. Accordingly, new methods and
protocols should be introduced into the new access networks.
As part of the ongoing work within MUSE on FMC, several candidate protocols have being
identified. The following section presents the protocols studied so far as well as the
guidelines agreed for the AA architecture. Herein, EAP, 802.1x and SIP are presented. For
each of these protocols the different features which might be related with nomadism and
FMC are identified.
4.2.1 EAP
The Extensible Authentication Protocol (EAP) is an authentication framework supporting
multiple authentication methods. EAP typically runs directly over data link layers, e.g. PPP or
IEEE 802, without requiring IP. There are three entities involved in EAP signalling: the
authenticator, which is the end of the link initiating EAP authentication, the peer, which is
the end of the link that responds to the authenticator, and the backend authentication server,
which provides the authentication service to the authenticator.

architecture III
IST - 6th FP
EAP is a good candidate for an architectural framework flexible enough to support different
authentication methods; in the following we will briefly discuss a number of TLS and SIM
based EAP methods particularly adapted to the support of nomadic and mobile service
access.
4.2.1.1 EAP-SIM
EAP-SIM, specified in 3GPP and in IETF (see [37]), was developed by 3GPP as an
extension of the GSM SIM based authentication mechanism. In GSM, each subscriber is
equipped, by the network provider, with a smart card Subscriber Identity Module (SIM), which
among other things, contains the subscriber’s International Mobile Subscriber Identity (IMSI)
and a card specific Secret Key, which is used to compute a response to an authentication
challenge by the network. EAP-SIM enhances GSM authentication mechanism by enabling
mutual authentication and the use of a longer cipher key.
EAP-SIM specifies two types of authentication procedures, a full authentication, which is the
normal authentication procedure and an optional fast re-authentication scheme which can be
used by roaming terminals for authentication based on keys derived upon a preceding full
authentication exchange.
It also specifies optional support for protecting the privacy of subscriber identity using the
same concept as GSM, which is using pseudonyms/temporary identifiers.
In EAP-SIM, the station, which is also called “peer” in EAP terminology, communicates with
the authenticator, which typically relays EAP messages to and from an EAP server that is
located on a backend authentication server using an AAA protocol.
For full authentication, the authenticator may start the procedure by issuing an identity
request. The peer’s response to this includes either the user's International Mobile
Subscriber Identity (IMSI) or a temporary identity (pseudonym) if it wishes to maintain identity
privacy. The EAP server then initiates an EAP request SIM /START message with a list of
supported EAP-SIM versions, which is sent to the peer. The peer responds to this request by
including a random number, NONCE_MT and the selected EAP-SIM version. After receiving
the response from the peer, the EAP server obtains n (n =2 or 3) GSM parameters for use in
authenticating the subscriber and derives new keying material called Session Master Key
(SMK) and a new Pseudonym. It then issues a request EAP-SIM challenge, which includes
the n RAND challenges and a message authentication code, AT_MAC, to cover the
challenges. On receipt of the challenge message, the peer runs the GSM authentication
algorithm and calculates a copy of the message authentication code MAC. The peer then
verifies that the calculated MAC equals the received MAC. Now since the RANDs sent to a
peer are accompanied with the message authentication code AT_MAC, and since the peer's
NONCE_MT value contributes to the AT_MAC, the peer is able to verify that the EAP-SIM
message is fresh (not a replay) and that the sender possesses valid GSM triplets for the
subscriber. If all checks out, the peer will issue a response, to the challenge, containing the
AT_MAC attribute that covers the calculated SRES values. The EAP server verifies the MAC
and if it is correct it sends an EAP-Success packet, indicating that the authentication was
successful.
Since this type of authentication is already used in GSM networks it seems to be a good
candidate for a FMC scenario.

architecture III
IST - 6th FP
4.2.1.2 EAP-AKA
EAP-AKA is another Authentication and Key Agreement mechanism developed by 3GPP for
the global third generation mobile network standards such as Universal Mobile
Telecommunications System (UMTS) and cdma2000.
It typically runs in a UMTS Subscriber Identity Module (USIM) or a cdma2000 (Removable)

User Identity Module (RUIM) and is based on challenge-response mechanisms using
symmetric cryptography.
As in the case of EAP-SIM, EAP-AKA specifies two types of authentication procedures used
for full authentication and fast re-authentication. It provides mutual authentication and longer
encryption keys.
To authenticate, the mobile station sends the subscriber identity or pseudonym associated
with its USIM or RUIM to the network. The network will, based on the secret key and a
sequence number, compute an authentication vector which includes a random part RAND,
an authenticator part AUTN used for authenticating the network to the identity module, an
expected result part XRES, a 128-bit session key for integrity check IK, and a 128-bit session
key for encryption CK. The RAND and the AUTN are delivered to challenge the mobile
station. The identity module in the mobile station, verifies the AUTN and if it is valid the
identity module produces an authentication result, RES and sends this to the network. The
network verifies the RES from the identity module and if the result is correct, the IK and CK
can be used to protect further communications between the identity module and the network.
Being used in UMTS and cdma2000 network make EAP-AKA a good candidate in a FMC
scenario as well as EAP-SIM.
4.2.1.3 EAP-TLS
EAP-TLS is an adaptation of transport layer security (TLS) for EAP. Important reasons why
this adaptation was done are that TLS provides the means for mutual authentication of
terminal and network as well as a key management mechanism.
TLS is conceptually a two-layer protocol where the TLS Record Protocol (the lower layer)
provides an encrypted communications channel along with message integrity checks.
The upper layer, the TLS handshake protocol, is used to negotiate ciphers, key exchange
and to perform the actual authentication.
TLS relies on certificates (e.g. x.509) for the authentication of the two involved parties, the
client and the server. EAP-TLS essentially extends TLS by allowing backend (AAA) servers.
Hence, in addition to a two-party authentication model, EAP-TLS also supports a three-party
authentication model. The primary advantages of EAP-TLS are that it provides for mutual
authentication and that its reliance on certificates facilitates roaming situations where the
client may not have a prior trust relationship with the visited network.

architecture III
IST - 6th FP
Reliance on certificates can also be viewed as a disadvantage since it calls for PKIs, which
have scaling problems. Another complication is that EAP-TLS does also not distinguish
between user and terminal certificates. Unless some special mechanism is provided to
couple, on the terminal, a certain certificate to a certain user account, a certificate on the
terminal will authenticate all users of the terminal. Hence, instead of user authentication,
terminal authentication will then take place. Finally, EAP-TLS does not provide for user
identity protection, which raises privacy issues.
4.2.1.4 EAP-TTLS (and EAP-PEAP)

EAP-TTLS (EAP-tunnelled TLS) and the closely related EAP-PEAP (EAP-protected EAP)
can be viewed as extensions of EAP-TLS.
They lessen the requirements of EAP-TLS by mandating certificates only for the server
(client certificates are optional). Even so, both EAP-TTLS and EAP-PEAP offer mutual
authentication. Furthermore, they provide for user identity protection.
What EAP-TTLS and EAP-PEAP effectively do is to use EAP-TLS and server certificates to
authenticate the server and create an encrypted tunnel. That encrypted tunnel is then used
when authenticating the client. Hence, EAP-TTLS and EAP-PEAP achieves mutual
authentication but in two steps.
In the first step, the server is authenticated using EAP-TLS. Then, in the second step, the
terminal is authenticated using some other authentication method transported inside the
tunnel established by EAP-TLS in the first step. This is where EAP-TTLS and EAP-PEAP
primarily differ. EAP-TTLS allow for any legacy authentication protocol (through Attribute-
Value-Pairs (AVP) over TLS records) whereas EAP-PEAP allows only EAP-based
authentication methods.
User identity protection is achieved by allowing the client to use an anonymous identifier in
the initial EAP-TLS conversation. When the encrypted tunnel has been established, the user
identity is protected by the tunnel and can be exchanged in clear text. To support roaming
scenarios, the anonymous identifier needs to include a correct realm (e.g. @myISP.com) so
that the home AAA server can be determined.
4.2.2 IEEE 802.1x

The IEEE 802.1x Standard defines a Port-based network access control which makes use of
the physical access characteristics of IEEE 802 Local Area Networks (LAN) infrastructures in
order to provide a means of authenticating and authorizing devices attached to a LAN port
that has point-to-point connection characteristics, and of preventing access to that port in
cases in which the authentication and authorization process fails.
IEEE 802.1x defines the mechanisms to carry an EAP authentication between a supplicant
and an authentication server. EAP messages are encapsulated in EAPOL messages defined
by the standard.
This Standard relies on the point-to-point connection and accordingly some of its features are
devised with this idea in mind.

architecture III
IST - 6th FP
Addressing is one of these features. It is stated in the Standard that in “MACs where the LAN
technology concerned is such that the individual MAC address of the Supplicant can be
unknown to the Authenticator, and vice versa, all EAPOL frames transmitted by a PAE (Port
Access Entity) shall carry the PAE group address as the destination MAC address. All
EAPOL frames shall carry the individual MAC address associated with the source PAE point
of LAN attachment as the source MAC address.” The PAE group address is a well known
group address and one of the reserved set of group MAC addresses that are not forwarded
by MAC Bridges(IEEE Std 802.1D). Frames sent to the PAE group address are extracted by
MAC Bridges and processed by the Authenticator entity if any or discarded.
Only in the case of “MACs where the LAN technology concerned is such that the individual
MAC address of the Supplicant is known to the Authenticator, and vice versa (for example, in
IEEE 802.11, where the establishment of an association between a station and an access
point involves the exchange of MAC addresses), all EAPOL frames transmitted by a PAE
shall carry the individual MAC address associated with the destination PAE point of LAN
attachment as the destination MAC address”.
Port definition is another feature of the IEEE 802.1x Std. connected to the fact that is point-
to-point oriented. The network access ports are defined as follows “A point of attachment of a
system to a LAN. It can be a physical port, for example, a single LAN MAC attached to a
physical LAN segment, or a logical port, for example, an IEEE 802.11 association between a
station and an access point”.
Finally there is a third feature defined is the Std. which could be seen as point-to-point
connection oriented. It is stated that “EAPOL frames transmitted by a PAE shall not be VLAN
tagged, but may optionally be priority tagged. All PAEs shall be capable of receiving both
priority tagged and untagged EAPOL frames”. This statement implies that the VLAN-ID
information in the VLAN tag is not taken into consideration in the Authentication process.
Since this type of frames do not need to be forwarded by bridges it seems reasonable VLAN-
ID information is not necessary.
Taking all these features into consideration, the following sub-section explains the different
authentication scenarios which could be developed to allow standards were compliant with
MUSE architecture.
4.2.2.1 Per RGW authentication

Authentication server
802.1X Authenticator
on the port
802.1X supplicant
+ Radius client
CPN AAA server
Terminal Bridged aggregation

or routed network
RGW Edge Node
Access Node
Figure 44: Line Authentication based on 802.1x

architecture III
IST - 6th FP
The RGW itself (working either in bridged mode or in routed mode and directly connected to
the Access Node) is the supplicant and gets authenticated by the authenticator in the Access
Node. In this case, the terminals and devices connected to the modem do not participate in
the authentication process.
Regarding nomadism, this scenario enables Subscriber authentication based on per-RGW

credentials. It permits one RGW to get authenticated in different locations since the
identification is not fixed to the line but to the RGW itself.
Upon authentication of the subscriber, from credentials provided by the RGW, access to
network resources is authorized equally to any user or terminal behind the RGW. There is
only one authentication process for the whole group of services and devices a subscriber is
allowed to use.
4.2.2.2 Per Terminal authentication
802.1X
802.1X supplicant Authenticator Authentication
802.1X
802.1X supplicant
authenticator
CPN AAA server
Terminal Bridged aggregation

or routed network
RGW Edge
Access Node
Figure 45: User authentication based on 802.1x authenticator at RGW
A possible solution that can be used for both bridged and routed RGWs is to delegate to the
RGW the authentication enforcement of subscribers per terminal. The subscribers are
authenticated per individual terminals behind the RGW, by means of an 802.1X exchange
between the terminal and the RGW, whereby the RGW must ask for authorization from an
AAA server (e.g. by means of a RADIUS session).
Prior to allowing the RGW to act as an Authenticator, authorization and authentication of the
RGW device type would take place in order to guarantee that the RGW matches the
characteristics of a device that can be trusted by the network operator to perform such an
authenticator function.
In this scenario, authentication takes place at RGW port level. Each port needs to be
authenticated and authorized. In case the same physical port on the RGW is used to access
different services, authentication and authorization will be global to the physical port and not
service aware. The service awareness in this scenario depends on whether each physical
port is used to access one or more services.
From the nomadic perspective this type of authentication enables per-terminal credential
based authentication.

architecture III
IST - 6th FP
This type of authentication brings certain concerns regarding the trust of the RGW and on the
capability/rights of the users to manage their RGW. Is the RGW sufficiently trusted to perform
admission control enforcement? Is the RGW partially/totally managed by the user? Is it
managed by the operator?
There exists a second possibility to perform subscriber authentication per terminal. It is

depicted in Figure 46:
802.1x supplicant 802.1x authenticator

RADIUS
Knows MAC@ D (Knows MAC-@ A)
server
+ RADIUS client
CPN
Aggregation AAA
Bridged server
Terminal network
RGW
with MAC-@ A
Edge
Node
Access
MAC-@ D
Node
Figure 46: User authentication based on 802.1x authenticator at AN
In order to avoid RGW trustiness problems, terminals should be directly authenticated by the
access node. However 802.1X cannot do this directly, since the RGW blocks direct 802.1X
communication between the terminal and the access node (terminals behind a routed RGW
are not visible at layer 2 for the access node and 802.1x communication based on PAE
group addresses are not forwarded by MAC bridges). The exception is for bridged modems
when the entity soliciting the authentication exchange knows the corresponding MAC
address of the peer entity in advance and unicasting is used to communicate Supplicant and
Authenticator.
This scenario permits authentication and authorization of ports at Access Node level based
on subscriber credentials per-terminal, but still authentication and authorization will be global
to the Access Node port and not terminal aware, i.e. no distinction will be made between
different terminals or different subscribers connected through the same port.
From the nomadic perspective, the authentication is based on user credentials per terminal.
However, it would only be suitable in single user per-line environments, as further users are
not requested for authentication.
4.2.2.3 Drawbacks and Limitation on IEEE 802.1x based Architecture

The previous section mentions some features of the IEEE 802.1x Std. which have certain
limitations in the context of the MUSE architecture.
As a summary of these limitations is as follows:

architecture III
IST - 6th FP
• Authentication exchanges can not cross RGWs. In routed mode there is no L2

visibility across the RGW, so a L2 based authentication exchange can not occur.
Even in the case of bridged mode, only when the MAC address of the Supplicant is
known to the Authenticator, and vice versa (unicast would be used in this case) can
802.1x based authentication cross RGWs.
• Port control performed over physical ports. Unless there exists a previous 802.11
association between Authenticator and Supplicant which permits the definition of
logical ports, only physical ports can be controlled.
• VLAN-ID information is not taken into account in the authentication processes. The
Std. does not recognize the VLAN-ID parameter in the authentication process;
accordingly this parameter is not used to identify different authentication processes.
4.2.2.4 RGW blocking authentication processes

As stated in previous sections, it should be possible for Supplicant and Authenticator to
communicate using unicast frames across the RGW. This case is only applicable when the
RGW is working in bridged mode.
In addition to that, the Supplicant needs to know Authenticator MAC address (and vice-
versa) before the authentication exchange starts. Either MAC addresses are pre-configured
in both entities, or some sort of mechanisms is defined to let Supplicant and Authenticator
discover one another MAC address.
4.2.2.5 Controlled Port Definition

IEEE 802.1x was first devised to perform control over physical ports on different points of
attachment to a LAN, e.g: switches or bridges. The standard was expanded to include other
access devices (e.g. 802.11, smart repeater). This expansion brought the definition of logical
ports since 802.11 could not have different physical points of attachment for the different
devices.
Considering the logical port definition described in the standard, different ways to define
logical ports could be studied within MUSE. This definition could extend the authorization and
authentication of more than one device over the same line (user credential based
authentication – option 2).
The different possibilities foreseen are the following:

• Port Definition based on MAC Source Address.
• Port Definition based on Circuit-ID (e.g. VLAN-ID or VPi/VCi or GEM-PORT-ID.
• Port Definition based on Circuit-ID+MAC Source Address.
• Port Definition based on security association (802.11 like).
4.2.3 SIP
This section gives an overview of the SIP protocol features related to AA (Authentication and
Authorization) of a UA (User Agent).
The SIP protocol provides the means to authenticate and grant access to an IP network to a
device/user via the UA function of the SIP-enabled device.

architecture III
IST - 6th FP
SIP Authentication is based on HTTP Digest (Challenge / Response). Related reference

documents are:
• RFC 2617 HTTP/Digest MD5
• RFC 3310 HTTP/Digest AKA
HTTP/Digest AKA has been selected by 3GPP for IMS specifications, since its authentication
framework is stronger than MD5: HTTP/Digest AKA requires user and server mutual
authentication.
The UA must send a register message before the end of the release time.
P-CSCF intercepts each authentication request and authorizes further data transfer only if
the authentication succeeds.
Starting from the first request to attach to a network, each SIP request is authenticated. That
means that sender and recipient must be totally authenticated in order to process the
requests/responses that have been sent out. As for register procedure, un-register procedure
implies mutual authentication. However, for intermediate SIP-AA signalling, authentication is
left optional.
Figure 47: general IMS distributed functions for control plane and user plane
The P-CSCF function is carried out by Session Border Controller (SBC).
This P-CSCF function mainly handles register and release requests. Response delay is
usually low between the P-CSCF and UA and significantly higher between the P-CSCF and
S-CSCF (same as using a proxy DHCP).
The P-CSCF also maintains SIP-session always connected.
The S-CSCF requests to the HSS (HSS is the user database of IMS) are not requested at
each re-register procedure in order to speed up multiple registrations of UA.

architecture III
IST - 6th FP
Figure 48: MD5 Digest Challenge Response Sequence
Details of Authentication Method (Auth-Scheme) for MD5 Digest:

> Digest Access Authentication
• challenge = "Digest" digest-challenge
• credentials = "Digest" digest-response
• ( authentication-info = nextnonce) option
The next nonce can be used at the next re-registration time or the next SIP request.
digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |
[ stale ] | [ algorithm ] | [ qop-options ] |
[auth-param])
digest-response = 1#( username | realm | nonce | digest-uri |
response | [ algorithm ] | [cnonce] | [opaque] |
[message-qop] |[nonce-count] | [auth-param] )
• algorithm directive = "MD5" | "MD5-sess"
MD5 Digest
- Quality of Protection
The response MD5 generated by the UA is:
" H ( H(A1): nonce: nonce-count: cnonce: qop: H(A2) ) "
- A1 if we use MD5,
A1 = username: realm: passwd
H(A1) will have the same value

architecture III
IST - 6th FP
-A1 If we use MD5-sess,

A1 = H( username: realm: passwd: nonce: cnonce )
H(A1) will be different each request.
-A2 = method: digest-uri
SIM authentication
Example 1: a SIM Card with embedded MD5 algorithm.
When a user uses a SIM Card to authenticate, he does not need to configure his User Agent.
The SIM Card firmware will do it for him.
User password will never be known / stored in the user device.
MD5 response is computed by the SIM Card. Therefore, the user device can be used by
different users with no fraud risks.
Figure 49: SIM Authentication Sequence
The SIM card also contains credentials. The user can store more than one credential in his
SIM Card. For SIP-based AA, credential information can be stored this way:
Domain_1 Uri-sip-private_1 Uri-public_1 Display-name_1 H(A1)_1

architecture III
IST - 6th FP
Figure 50: Scheme for storing credential information

To perform a fast authentication response, one solution is to store only H(A1) in the SIM
Card. H(A1) is always the same in MD5.
If the user has more than one public_uri for one private_uri, credentials can be stored as
follows:
Uri-sip-private1 Domain1 Uri-public1.1 Display-name1.1 H(A1).1.1
Uri-public1.2 Display-name1.2 H(A2).1.2
Uri-sip-private2 Domain2 Uri-public2 Display-name2 H(A1).2
Uri-sip-private3 Domain3 Uri-public3 Display-name3 H(A1).3
Figure 51: Scheme for storing credential information in case of having multiple public URIs per
private URI
Example 2: SIP authentication with a SIM Card with AKA-SIM algorithms.
As with MD5, the user has nothing to do to configure his UA, the SIM card firmware will
perform the configuration, based on the credentials stored on the card. But instead of using
only a challenge, AKA-SIM protocol uses authentication vectors. User and server are both
authenticated with these vectors.

architecture III
IST - 6th FP
Figure 52: authentication method for AKA Digest (see also 3GPP TS 33.203 and also IETF RFC
3310)
This technology is the strongest way to authenticate user.
4.2.4 Conclusion for AA mechanisms

Though in MUSE we consider many AAA mechanisms, keeping in mind the scalability,
robustness and the evolution to the FMC architecture, we break down our generic AAA
approach to the use MUSE use cases, which correspond to present and future network
implementation scenarios. Since our use cases consider the fixed scenario, the mobile one
and the mix of both of them, legacy networks would certainly be a part of them. This means
that there will not be a single protocol solution; the AAA solution would require having
multiple protocols depending upon implementation scenarios (MUSE Use Cases). Being
specific, this would boil down to the use of IEEE 802.1x protocol in some scenarios and other
protocols like SIP or PANA which would be and are under study in MUSE. The current status
of AAA work constitutes the study of many AAA mechanisms and the next step would be to
create a solution using these mechanisms for MUSE implementation scenarios (Use Cases).
4.2.5 Architectural Guidelines for AA for Nomadism

Over the years, authentication, authorization and accounting have changed dramatically as
users of new access technologies seek a way to authenticate, authorize, and start
accounting records for billing user time on their networks. For MUSE scenarios we consider
the fundamental yet general requirements for the specification and design of an AA
architecture for nomadism.
Before we consider in detail the specification and design of AA architecture for nomadism, it
is worthwhile revising the basic requirements for AA services.
4.2.5.1 Need for AAA Services

Security for user access to the network and the ability to dynamically define a user’s profile to
gain access to network resources has a legacy dating back to asynchronous dial access.
AAA network security services provide the primary framework through which a network
administrator can set up access control on network points of entry or network access
servers, which is usually the function of a router or access server. Authentication identifies a
user; authorization determines what that user can do; and accounting monitors the network
usage time for billing purposes. AAA information is typically stored in an external database or
remote server such as RADIUS or Diameter. The information can also be stored locally on
the access server or router. Remote security servers, such as RADIUS and Diameter, assign
users specific privileges by associating attribute-value (AV) pairs, which define the access
rights with the appropriate user. All authorization methods must be defined through AAA.

architecture III
IST - 6th FP
4.2.5.2 Traditional AAA Usage

Figure 53 shows the original use of AAA: authenticating and maintaining accounting records
for a dial Point-to-Point Protocol (PPP) user. In this implementation, a user dials a phone
number corresponding to a port on one of the Access Nodes at the edge of the data network.
When the user ID and password are configured, the server looks locally at the NAS database
or makes a query to a preconfigured RADIUS server to determine whether to permit or deny
access to the network. If the user is permitted, the RADIUS server typically sends a
configuration or AV pair to the NAS, which dictates the type of service permitted for that user.
RADIUS
Server 1
Network Network Service
PSTN Access Provider
Computer Provider
RADIUS
Server 2
Figure 53: Traditional AAA Implementation
4.2.5.3 Generic Considerations for AA Architecture

Now, recalling the general requirements which were mentioned in section 4.2.5.2, we make a
basis for defining guidelines for an AA architecture by proposing an AA infrastructure
consisting of a network of cooperating generic AA servers communicating via a standard
protocol. The protocol should be quite general and should support the needs of a wide
variety of applications requiring AA functionality. To realize this goal, the protocol should
operate in a multi-domain environment with multiple service providers as well as entities
taking on other AA roles such as User Home Organizations and AA Proxies. It should be
possible to combine requests for multiple authorizations of different types in the same
authorization transaction. The AA infrastructure will be required to forward the components of
such requests to the appropriate AA servers for authorization and to collect the authorization
decisions from the various AA servers consulted. All of this activity is perfectly general in
nature and can be realized by the common infrastructure. This implies that MUSE
considerations for the design of an AA architecture would not be based on proprietary
solutions.
But the applications requiring AA services will each have their own unique needs. After a
service is authorized, it must be configured and initialized. This will require application
specific knowledge and may require application specific protocols to communicate with
application specific service components. To handle these application specific functions, we
propose an application interface between a generic AA server and a set of one or more
Application Specific Modules (ASMs) which can carry out the unique functionality required by
each application.

architecture III
IST - 6th FP
Since the data required by each application for Authentication, authorization, or accounting
may have unique structure, the standard AA protocol should allow the encapsulation of
opaque units of Application Specific Information (ASI). These units would begin with a
standard header to allow them to be forwarded by the generic infrastructure. When delivered
to the final destination, an ASI unit would be passed by a generic AA server across its
program interface to an appropriate ASM for application specific processing. Nevertheless, it
remains a goal of the design for information units to be encoded in standard ways as much
as possible so as to enable processing by a generic rule based engine.
The interactions of the generic AA server with the Application Specific Modules and with
each other to realize complex AA functions are explored further in the document. Thereafter,
we attempt to further organize the AA functions into logical groups using a protocol layering
abstraction. This abstraction is not intended to be a reference model ready to be used for
protocol design. At this point in the work, there are numerous questions that need to be
addressed and numerous problems that remain to be solved. It may be that an abstraction
other than layering will prove to be more useful or, more likely, that the application layer will
require some substructure of its own.
Generic AAA server

REQUEST AAA Server
rule based engine
Policy and event

repository
Application Specific
Module
Figure 54: Generic AA Server Considerations
Figure 54 illustrates a generic AA Server with connections to the various architectural

components described above. In this model, the user or another AA server contacts the AAA
server to get authorization, and the AA server interacts with the service. The request is sent
to the AA server using the future AA protocol. The server interacts with the service via a
different protocol. It must support some global naming space for the application specific
items. The same holds for the communication used to access the repository.

architecture III
IST - 6th FP
4.2.5.4 Compatibility with Legacy Protocols

Because of the widespread deployment of equipment that implements legacy AA protocols
and the desire to realize the functionality of the new AA protocol while protecting the
investment in existing infrastructure, it may be useful to implement an AA gateway function
that can encapsulate legacy protocol data units within the messages of the new protocol.
Use of this technique, for example, would allow Radius/Diameter attribute value pairs to be
encapsulated in Application Specific Information (ASI) units of the new protocol in such a
way that the ASI units can be digitally signed and encrypted for end-to-end protection
between a service provider's AA server and a home AA server communicating via a
marginally trusted proxy AA server. The service provider's Network Access Node would
communicate via Radius/Diameter to the network service provider's AA server, but the AA
servers would communicate among themselves via the new AA protocol. In this case, the AA
gateway would be a software module residing in the service provider's AA server.
Alternatively the AA gateway could be implemented as a standalone process.
4.3 Options for Mobility Management (Session Continuity)

4.3.1 Definitions and Scope
Session Continuity refers to the “ability of a user or terminal to change the network access
point while maintaining the ongoing session. This may include a session break and resume,
or a certain degree of service interruption or loss of data while changing to the new access
point”, according to ETSI/TISPAN definition incorporated by MUSE.
Apart from the definition above, MUSE defines Continuous Mobility as the “the ability of a
mobile user/terminal/network to change location while media streams are active”, which is
derived from ITU-T. Handover and Seamless Handover are two flavours of Continuous
Mobility:
• Handover (loss of data is limited, real-time services can still be continued)
• Seamless Handover (loss of data is minimal, handover is not perceptible to user)
Nomadism is the another form of mobility defined as the ”ability of the user to change his
network access point on moving; when changing the network access point, the user's service
session is completely stopped and then started again, i.e., there is no session continuity or
handover possible. It is assumed that normal usage pattern is that users shutdown their
service session before moving to another access point.” This definition is taken from
ETSI/TISPAN.
Roaming provides a terminal/user with the ability to access services while moving outside of
his subscribed home network, literally being connected to the visited network. It is defined in
ETSI/TISPAN as “the ability of the users to access services according their user profile while
moving outside of their subscribed home network, i.e. by using an access point of a visited
network. This requires the ability of the user to get access in the visited network, the
existence of an interface between home network and visited network, as well as a roaming
agreement between the respective network operators”. Services during roaming can be
either Nomadic, Session Continued or Continuously Mobile. It is showed on the picture
below:

architecture III
IST - 6th FP
Figure 55: Illustration of the definitions. Roaming is a business relation that has impact on all
technical topics
This chapter describes the MUSE Mobility Management approach to Session Continuity and
Continuous Mobility. MUSE works to define effective solutions for Session Continuity and
Continuous Mobility that will employ network layer or application layer mobility management
mechanisms. Link layer mobility support (e.g. triggering) and network mobility support is not
excluded. Network layer mobility management protocol considered is Mobile IP, while
application layer mobility management protocol is SIP.
4.3.2 Network scenarios

There are multiple different circumstances or conditions influencing the network parts
involved in the different flavours of mobility. Some possibilities are listed below:
1. Discrete mobility (nomadism) / continuous mobility.
2. One single (multi-service) terminal / different terminals
3. Movement within one access network / different access networks
• Same access technology (e.g. xDSL, WIMAX,...) / different access
technologies
• Same access provider / different access provider
4. Movement within the same service provider / different service providers

architecture III
IST - 6th FP
Figure 56: Different favours of mobility: multiple terminals, access networks, service providers
Such classification helps to identify what mobility techniques (network layer or application
layer) can be used in each case.
Mobility within the same access network or between two access networks managed by one
Network Access Provider can be provided via network layer mechanism. In case different
Network Access Providers are being involved, an application layer technique is required.
4.3.3 Mobility techniques

4.3.3.1 Application layer – SIP
In SIP there exist two request types that can be used to transfer a media session. One of
them is called re-INVITE, and the other one is called REFER.
The re-INVITE method is used to modify an existing session including change of addresses
and ports. By sending a new INVITE (re-INVITE) request within an existing session, a
session transfer is requested. The re-INVITE method is the primary mechanism to provide
SIP-based terminal mobility. It can be used for call transfer between terminals as well.
The REFER method also enables call transfers. The recipient of a REFER is requested to
initiate a call with the target device provided in the request. The terminal which has sent the
refer message is notified of the outcome of the request.
4.3.3.1.1 REFER – Session Transfer Method

The REFER message transfers an active session to another terminal. The REFER method
contains a Refer-To and a Referred-By field. Refer-To shows the destination for the transfer
and Referred-By describes the initiator.

architecture III
IST - 6th FP
To trigger the media session transfer, the initiator sends a REFER request to the
corresponding terminal. When the request is accepted by the corresponding terminal, it
invites the device given in the Refer-To field to a new call. After the new call is established,
the call with the transfer initiating terminal is released.
When a REFER request is received, the NOTIFY mechanism is used to inform the call
transfer initiator of the status of the refer transaction. As a response, a 202 Accepted is sent,
indicating that the request has been understood, and that authorization may be granted. Now
the NOTIFY mechanism starts. If the REFER transaction is still pending, the returned
NOTIFY contains the response 100 Trying. If the refer transaction was successful the
NOTIFY contains the body 200 OK.
4.3.3.1.2 re-INVITE – Session Modification Method

Another SIP request method to transfer an active session to another terminal is SIP re-
INVITE. Before re-INVITE method can be used, a media session has to be established
between two terminals. At first the call transfer initiating terminal establishes a second call
with the target device of the call transfer. The call transfer is accomplished by sending a new
INVITE request within the same dialog that established the first media session. An INVITE
request sent within an existing dialog is known as a re-INVITE. The following SIP header
fields, To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set following the same
rules as for regular requests within an existing dialog.
The re-INVITE request contains the returned SDP of the established call with the transfer
target. The correspondent terminal receives the re-INVITE and redirects the media session
to the new connection parameters of the call transfer target that are indicated in the SDP of
the re-INVITE.
4.3.3.1.3 Standard SIP mobility – Summary

SIP is designed to control session establishment in IP-based multimedia sessions. So it
meets the requirement of being harmonized with IP based core networks.
It further supports the separation of control and transport functions, because SIP is a
signalling protocol and does not transport data itself. SIP only defines the protocol used to
transport data in the SDP payload.
As SIP is an application layer protocol it is independent of the network access technology as

well as independent of the IP version and supports user/terminal identification and AAA
functionality. SIP entities can be identified using SIP URIs. As SIP sessions need to be
authenticated, accounted and authorized, SIP has an AAA-interface to communicate with
AAA servers.
But SIP is not able to provide seamless handover management; it is only able to provide
location management functionality.
Even though standard SIP supports session continuity and provides location management
functionality, it does not support seamless handover. When a mobile terminal moves to
another IP address subnet, the SIP signalling and data channels are disconnected, because
the underlying TCP/UDP socket addresses are no longer reachable. Handover management
is only supported in SIP by interworking with a protocol which has a handover procedure.

architecture III
IST - 6th FP
The SIP re-INVITE message for supporting location management has a major drawback in
terms of privacy, because a malicious callee, that receives the re-INVITE message, may
observe the movement of the caller. It is obvious that SIP does not provide the requirement
of location hiding.
Finally it should be noted that SIP is a candidate protocol, because it is able to provide
Personal-, Terminal- and Service- Mobility and it meets almost all protocol requirements.
SIP Advantages:
• Already established protocol for conversational services
• ETSI TISPAN and 3GPP IMS NGN solution is based on SIP
• Support of all Mobility Types – with limitations (Personal, Terminal, Service, and
Session Mobility)
• As application layer protocol, independent of network access technology
SIP Drawbacks:
• In Standardization, modifications in protocol require “some“ effort
• Firewall/NAPT Traversal
• No Continuous Mobility support
• Privacy protection is not guaranteed because moving of terminals or users can be
seen through catching REFER or re-INVITE messages
4.3.3.1.4 New SIP based mobility solutions

There are many protocols which already support portions of mobility issues – at least on a
first view. But on a more detailed view some drawbacks are identified.
New proposals are being worked out to overcome issues from standard SIP based mobility,
respectively to develop methods to enhance standard SIP methods – BUT based on
standard SIP protocol, to provide:
• Privacy
• Continuous mobility
• Inter domain mobility across access and core networks
Terminal mobility, referring to the ability of a terminal to access services while moving across
access networks, can be realized with different protocols. One possibility is to use the SIP re-
INVITE method which was already discussed in the previous chapter. But the mobility
mechanism based on re-INVITE messages to redirect a session has a major drawback in
terms of privacy. As the callee receives the re-INVITE message of the moving caller, he is
able to observe that the caller is in motion.
The privacy problem can be solved by associating the re-INVITE mobility mechanism with
the functionality of Session Border Controllers (SBC). If the movement of the caller is hidden
to the callee, the privacy of the caller is maintained.

architecture III
IST - 6th FP
A SBC acts as a media (RTP) proxy and as a SIP Signalling Proxy (e.g. Back-to-Back user
agent). The signalling and media flows of each session are interposed by Session Border
Controllers in a hop by hop principle. This is achieved by terminating the IP/UDP layer at
each hop (SBC). Incoming RTP packets are unpacked, meaning that the IP and UDP layers
are terminated. Afterwards the outgoing RTP data are repacked which enables network
address and port translation. That means media streams are anonymized and SBCs are able
to hide the provider’s network topology from the users and especially from other providers.
As SBCs interpose the signalling and media flows, involved SBCs have the call state
awareness of established user calls.
The mobility solution of re-INVITE together with SBCs, means that a mobility related re-
INVITE SIP signalling message is intercepted at an appropriate Session Border Controller
and that the media stream is redirected to the new device or domain where the existing
session has to be moved to.
This approach does not provide the requirement for seamless handover. But solutions will
be worked out and described in future deliverable D TF1.8 on FMC solutions for MUSE to
address the seamless mobility issue.
Although seamless mobility is not an inherent feature of SIP, it is indispensable for

conversational services like VoIP. Consequently, some network support for SIP-based
mobility can be used to provide seamless mobility to the moving terminal. One of the
candidates is use of the IP soft handover concept that allows terminal to receive IP packets
from both access networks during handover. This solution is capable of providing Continuous
Mobility and seamless handover.
Another possibility is the use of a Mobility Manager, where some network element instructs
the terminal when the handover has to be performed and to which access network the
terminal should connect to. Decisions taken by the Mobility Manager are based on
information about available network resources, preferences of the user, service profile, signal
quality of the wireless access network and possibly more.
4.3.3.2 MIPv6
Mobile IPv6 (MIPv6) is the solution developed in IETF for Layer 3 (IPv6) host mobility: it
permits an IPv6 host to use a "permanent" home address as it moves around the Internet,
providing support for transparency above the IP layer (including maintenance of active TCP
connections and UDP port bindings). In order to allow a Mobile Node11 (MN) to remain
reachable while moving around in the IPv6 Internet, MIPv6 assigns two addresses to it:
1. a Home Address (H@), which uniquely and statically identifies the node regardless of
its current network point of attachment, and is used by the MN for all communications
with its Correspondent Nodes (CNs);
2. a Care-of Address (CO@), which is acquired by the node in the visited network
through IPv6 autoconfiguration mechanisms (Stateless Address Auto configuration –
SLAAC; DHCPv6): this address depends on the network in which the MN is currently
located, thus it changes as the MN moves from one IPv6 network to another.
11
MIP capable moving terminal

architecture III
IST - 6th FP
While moving, the MN interacts with its Home Agent (HA), a device located in the MN home
network which is responsible for storing H@-CO@ bindings and for traffic forwarding
between the MN and the Correspondent Node the MN is communicating with.
When the MN, as a consequence of its movement from one network to another, acquires a
new CO@, it informs its HA by sending a Binding Update message to it: such a message
contains the H@ and the new CO@ of the MN, and the lifetime of the binding. The HA stores
the information provided by the MN into its Binding Cache (BC), and sends a Binding
Acknowledgment message back to the MN.
Thus, every IPv6 packet destined to the MN (that is, to its H@) reaches its home network
and is intercepted by the HA, which, based on the information stored in its Binding Cache,
forwards the packet to the destination MN by injecting it into an IPv6-in-IPv6 tunnel which is
terminated on the MN current CO@. in the reverse direction, IPv6 packets sent by the MN
(with its H@ as source address) to the CN are encapsulated by the MN itself into the same
IPv6-in-IPv6 tunnel to the HA; upon receipt of the tunnelled packets from the MN, the HA
extracts the inner IPv6 packet and forwards it to the CN. This mechanism is know as
Bidirectional Tunnelling and, of course, can lead to inefficiencies in traffic forwarding due
to the constraint of triangular routing which it imposes.
To avoid the limitations of Bidirectional Tunnelling, a new mechanism named Route

Optimization has been defined. If it is supported by both the MN and the CN, it allows the
MN to communicate its CO@ to the CN too (with a Binding Update/Binding Acknowledge
message exchange similar to the one occurring between the MN and its HA), in order to
make direct communication possible and avoid the tunnelling through the HA.
The drawback of Route Optimization is that it is no longer transparent to the CN (which has
to implement it) and that it has security implications. The security issues have been
addressed by a new signalling mechanism, based on the exchange of Home Test Init (HoTI)
/ Care-of Test Init (CoTI) and Home Test (HoT) / Care-of Test (CoT) messages, which allows
the MN and the CN to establish a Security Association before the Binding Update/Binding
Acknowledge message exchange can actually take place.
Route Optimization is the MIPv6 superior feature over MIPv4. In MIPv6 case, there is no
need to send all user traffic to the MN through HA. MH and CN are able to communicate
without any intermediate Mobile IP node. Sending all traffic to the MN via HA (MIPv4 case)
causes HA to be a single point of failure and significantly reduces scalability of the solution.
Consequently, MIPv4 implementation in the real network turns out to be unlikely.
Mobile IPv6 has significantly evolved as a technology providing basic mobility (nomadism) for
the user. However, not only for mobility, it has also evolved to stand as a potential candidate
for the solution to address session continuity. As the applications grow, the user demands to
have them wherever, and more importantly without breaks, also grow. MIPv6 promises to
continuously operate devices that change IP address when in the move. However, current
handover procedures are too slow, to remain seamless for real-time applications.
Consequently, Continuous Mobility can not be provided by the MIPv6 itself. Multicast mobility
still waits for a convincing design.

architecture III
IST - 6th FP
Two MIPv6 protocol enhancements have appeared which promise handover performance
improvement in terms of blackout time introduced during switching to new network
attachment point. They are HMIPv6 (Hierarchical MIPv6) and FMIPv6 (Fast MIPv6).
4.3.3.2.1 Hierarchical Mobile IPv6 (HMIPv6)

Hierarchical mobility management for Mobile IPv6 (HMIPv6) is designed to reduce the
amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home
Agent. HMIPv6 introduces MAP (Mobility Anchor Point), which is a new Mobile IPv6 node
that acts as a local HA. MAP allows Mobile IPv6 to benefit from reduced mobility signalling
with external networks. It can be located at any level in a hierarchical network of routers,
including the Access Router (AR). Unlike Foreign Agents in IPv4 (which terminates IP in IP
tunnel originated in HA to transport user traffic from CN to MH), a MAP is not required on
each subnet. The MAP will limit the amount of Mobile IPv6 signalling outside the local
domain.
The aim of introducing the hierarchical mobility management model in Mobile IPv6 is to
enhance the performance of Mobile IPv6 while minimising the impact on Mobile IPv6 or other
IPv6 protocols. HMIPv6 does not exclude Fast Mobile IPv6 handovers to help Mobile Nodes
achieve seamless mobility. Furthermore, HMIPv6 allows mobile nodes to hide their location
from correspondent nodes and Home Agents while using Mobile IPv6 route optimization.
4.3.3.2.2 Fast Mobile IPv6 (FMIPv6)

MIPv6 provides the smooth underlying transition from one network to another, keeping it
transparent to the above application layers, by doing handover in a reliable and robust way.
Fast MIPv6 (FMIPv6), as the name goes is the faster version of MIPv6, reducing the
handover time (handover time here refers to the complete process of losing the old IP
address and acquiring a new one without breaking the ongoing communication) by more
than 50% (compared to the basic MIPv6 protocol).
The concept behind FMIPv6 is to allow a terminal to quickly detect that it has moved to the
new subnet and to obtain new IP configuration while still being connected to the old subnet.
Additionally, to reduce handover latency, FMIPv6 protocol specifies the means to set up a
tunnel between old and new access router. During handover, IP packets are tunnelled by old
access router and delivered to the terminal through the new access router. The tunnel
remains active until the MN completes the network access attachment change and resumes
communication with its peers. Afterwards, the usual MIPv6 procedure is employed.
It should be noted that additional requirements for MUSE like QoS, security, and reliable
AAA will provide additional latency to the performance of the existing MIPv6 mobility
management proposals. It will make Continuous Mobility even more difficult to achieve.
4.3.3.3 Mobility Manager

The Mobility Manager concept proposes to enhance Mobile IP or SIP Mobility to improve
Mobility Management and answer the session continuity requirements.
This solution proposes network controlled mobility and enables session adaptation, based
on:
• The access network where the user is located

architecture III
IST - 6th FP
• The type of subscription the user has

• The QoS and the network resource
The Mobility Manager concept is proposed within 3GPP as a part of the SAE architecture.
The terminal must be able to manage a double connectivity network: one for passive and the
other one for active connection. During the network authentication (of the passive
connection), the active session must be able to receive data. When moving from one network
access point to another, the terminal provides the Mobility Manager with information about
available network access points and their signal quality. The Mobility Manager takes into
account information about available resources in each access network provided via the
Resource Managers and decides what network the terminal should move to. The criteria of
the handover decision can be also based on:
• preferences of the user
• service profile
• quality of reception of the terminal
• quality, preferences and profile service available between the various accesses
network
Functional components of Mobility Manager:

1. Inter-AS Mobility Policy Manager (IASMPM) enhances the Mobile IP solution by
including network based handover policy rules. These policy rules can include the
quality of the link, the user subscription profile, the load of the network and more
2. Mobility Manager (MM) Register is a database storing UE Context (e.g. user profile,
radio environment), session context (session parameters) and Access Network
Context. It can contain both static information (e.g. user subscription profile) and
dynamic information (UE location, Access Network status, user on-going session
information and more). These pieces of information are updated through the
Monitoring Information sent to the IASMPM.
3. Resource Manager monitors access resources. It sends Access Network Monitoring
messages to the Inter-AS Mobility Policy Manager regarding the load, resources
usage and QoS achievable in the access network. Additionally it could be able to
manage resources in the access network (e.g. allocate/guarantee resources for the
user in the access network).
4. User Equipment (UE) is end-user terminal. It has several interfaces which allow it to
connect to different types of access networks (e.g. GPRS, UMTS, WLAN). The UE
sends information to the IASMPM on the available access networks (e.g. link quality
measurements) through monitoring messages, and receives Handover Indication
messages from the IASMPM.
5. The Application Server (AS). In case an Application Server is involved in the
session, the Application Server can adapt the service delivery to the access network
being used by the Mobile Terminal. AS adapts the content and format of the service
according to the terminal capabilities and the network access capabilities (available
bandwidth). Service profile of the user may also be taken into account. This function
will be triggered in particular at session initiation or following the notification by the
Inter-AS Mobility Policy Manager of an access network change.

architecture III
IST - 6th FP
4.3.4 Performance comparison

Analysis of the experiments taken by different university laboratories (see [30], [32], [33],
[35], [39], [40], [43], [44], [47], [48] and [50]) indicates that both network layer and application
layer mobility management schemes are able to provide Session Continuity, but with
noticeable service interruption or loss of data while changing to the new access point. On the
other hand, Continuous Mobility is not easy to achieve using either SIP or MIP.
Consequently, conversational services can not be supported by either network layer (MIP) or
application layer (SIP) mobility techniques as far as they follow protocol implementation
based on terminal-driven handover triggering when changing the network attachment point.
The basic implementations of SIP and MIP provide comparable handover latencies. It is not
possible to choose a superior mobility management method (network layer vs. application
layer) in terms of handover blackout. In both cases the majority of handover delay is caused
by link layer handover, movement in network layer detection, IP address acquisition and
configuration. Actual SIP or MIP message exchange is a minor part of the handover delay.
In terms of optimization methods, experimental results point out that PAR (Proactive Address
Reservation) can bring significant handover performance improvement for both SIP and MIP
protocols. PAR performs address allocation and handover procedure before the link layer
handover.
Another solution is to employ IP soft handover. IP soft handover provides network support to
the handover and is capable of providing Continuous Mobility when SIP signalling is used. It
requires the access network elements to be aware of the outgoing handover. It enhances the
PAR scheme by performing the packet replication and filtering functions localized in the
access network and the packet filtering functions implemented on the terminal. Moreover, the
terminal itself has to be able to be simultaneously connected to two network attachment
points during handover. This adds significantly to the functionality requirements of the access
network.
Both Hierarchical MIPv6 and Fast-handoff MIPv6 mobility management techniques enhances
the basic MIPv6 protocol in order to improve its handover performance.
HMIP employs MAP (Mobility Anchor Point) to maintain mobility between itself and the
terminal visiting its domain. MAP acts a local home agent (HA). Unless terminal changes
network attachment point within the MAP domain, it signals that location change to the MAP
only, i.e. the change is not signalled to the HA. Such mechanism brings some improvement
in terms of handover latency.
FMIPv6 allows terminals to anticipate network attachment point changes by means of link
layer information. The terminal acquires a new IP address before the link layer handover
takes place. This is similar to the PAR mechanism. Additionally, FMIPv6 allows old and new
access routers to create tunnels between each other which are used to forward traffic to the
terminal during handover. FMIPv6 is able to provide a fast handover, however session
interruption can still not be avoided.

architecture III
IST - 6th FP
4.3.5 Conclusions
MUSE has considered both network layer and application layer mobility management
methods to support Session Continuity and Continuous Mobility of mobile terminals. Current
implementations of SIP and MIP mobility management schemes are able to provide Session
Continuity, but with noticeable service interruption or loss of data while changing the network
attachment point. Neither SIP nor MIP are able to provide Session Continuity.
The dominant factor of SIP and MIP handover latency is linked to the network layer
movement detection and IP address configuration. SIP or MIP handover signalling causes
only a minor part of the total handover latency. Consequently, it is not possible to point out
superior mobility management method (SIP vs. MIP) in terms of handover performance since
basic implementations of both protocols provide handover latencies of the same order of
magnitude.
In order to improve handover performance provided by MIP protocols, HMIPv6 and FMIPv6
methods were proposed. Even though they are able to significantly reduce handover time,
Continuous Mobility is not achieved.
Application layer mobility management method can be enhanced by means of PAR

(Proactive Address Reservation) which provides an efficient mechanism to improve handover
performance. It employs link layer information to anticipate handover and it allows terminals
to obtain IP configuration before link layer handover.

layer seamless mobility. It employs access network elements to assist the terminal while
the dual mode terminals) and Mobility Manager (network triggers the handover and instructs
the terminal what access network to choose). Network-supported handover promises to
provide Continuous Mobility towards the moving terminals.
The MUSE architecture to support Session Continuity and Continuous mobility is still being
worked out. Final architecture is to be described in the deliverable document D TF1.8.
Existing solutions description and performance evaluation presented above is the basis for
the studies on the optimal functionality distribution. Based on that, it becomes clear that the
MUSE access network will support terminal handover in order to minimize session disruption
while in the move. One of the promising solutions is the IP soft handover, which allows
seamless handover for the SIP applications. SIP-controlled IP soft handover requires access
network to implement SIP B2BUA and RTP proxy functionalities. MUSE DSBC proposal
distributes both control (P-CSCF) and media related (BGF) functions from SBC to the Access
Node. SIP-controlled IP soft handover goes along with the MUSE DSBC proposal due to the
fact that Access Node functionalities required to support seamless handover can be
implemented via DSBC architecture upgrade. Main building blocks for IP soft handover:
Border Controller and Access Border Gateway are already in place.

architecture III
IST - 6th FP
SIP-controlled IP soft handover provides Session Continuity and Continuous Mobility to the
SIP-based applications. Such applications mainly support conversational services, which
require seamless handover in principle. However, IP soft handover does not support mobility
for the applications that do not use SIP as a control protocol. MUSE considers FMIPv6 as a
non-SIP services mobility enabler.
Mobility Manager is able to shorten network movement detection delay and consequently
reduce handover delay significantly. However Mobility Manager itself uses mobility
management protocols like MIP or SIP to signal changes in the IP layer and transport layer.
Consequently, Mobility Manager is not able to provide Continuous Mobility itself, but can act
as a terminal support in terms of the new network attachment point selection.
MUSE Session Continuity architecture will consist of IP soft handover for SIP-controlled
conversational services, FMIPv6 for non-SIP services and optionally Mobility Manager to
support terminals with the choice of the most appropriate access network while in the move.
4.4 High-level MUSE FMC architecture

Figure 57 describes FMC from a high-level use case perspective where multiple access
network specific drop technologies can be used to access a user’s service profile. Above this
layer there is a common functionality layer that can be the same for different access types.
This layer contains functions that can be common for any type of access technology, e.g.
policy control functions, AAA, HA etc.
Common Services
Applications [IMS, ....]
Common Functionality
Common Network Functions [AAA, PCF, QoS, HA, .....]

Access Network Specifics
Fixed Access Fixed Access 3GPP

Network Network Network
* = Eth, DSL, WiMAX,

Access Access Access Access Access WLAN
Drop* Drop* Drop* Drop* Drop
End User Specific
End User End User End User End User End User End User End User
Figure 57: Top-level view on Fixed-Mobile Convergence, FMC will most likely happen at
common functionality and common services layer

architecture III
IST - 6th FP
On top of this common functionality layer the application layer itself resides, this can be IMS
or non-IMS based applications for voice, video and Internet depending on the preference of
the operators.
The challenge for MUSE is to develop an architecture that supports roaming between
different technologies (aka multi-access) but also roaming in a multi-provider environment. In
addition to that, the architecture should support session continuity for services, transfer of
policies between different accesses when the user moves and of course proper mechanisms
for authentication, authorization and accounting (AAA). All this in a well designed architecture
that preferably piggy-backs onto existing solutions. The MUSE key challenges to this work
are to implement this in a multi-provider, multi-service environment.
4.4.1 Current status of MUSE FMC Architecture

The work in MUSE on developing the MUSE architecture for FMC is still in its early stage
and many issues are still to be resolved. However, a few working assumptions already exist
and will act as the base for the architectural development:
• WiMax is considered in MUSE as an important access technology to be able to
interwork (roaming to and from) with. WiMax has already solved session continuity
inside a WiMax domain.
• SIP and IMS are included in MUSE from an interacting perspective; no real protocol
development is included.
• The focus for MUSE FMC architecture is for network layer solutions.
• SAE/LTE architecture is considered in the work but 3GPP drafts are currently not
stable enough to base a FMC architectural solution on.
• I-WLAN is considered as one of the most reasonable starting points even though
many challenges remain.
With these assumptions the following architecture pictures can be drawn. The initial access
shows a user using a DSL, Fibre or WLAN connection in his home and connecting via a
RGW to a broadband access network. The device can be SIP/IMS enabled but it is more
likely that the RGW (NT12) will have this capability.
The next access shows a dual hand-set where access can be achieved by either 3GPP or
WLAN. For pure 3GPP access the terminal accesses the IP network through the 3GPP
network.
For the non-3GPP access the terminal either connects through the broadband access
network as in the first case (#1). Alternatively, the terminal establishes a tunnel through the
broadband access network to the 3GPP WLAN access network where the tunnel is
terminated in the WAG (#2). The preferred solution depends on the type of terminal and the
type of clients it supports. The preferred solution for this case is currently being studied and
includes investigations of I-WLAN, SAE/LTE etc.
The WiMax access is an access that uses its own architecture and connects to the IP
network through an edge node (ASN-GW) that is WiMax specific.

architecture III
IST - 6th FP
The hot-spot access is separated from the broadband access since the access point (AP) is
typically not belonging to the residential gateway (RGW). But towards the IP transport
network, this access connects in the same manner as the broadband access edge node.
IMS
S/T U
Home network Fixed BB Access network (MUSE) Legacy

Broadband networks
access BB-UE (1) NT12 AN EN/
BAS
Non-BB-UE TA
IP transport netrwork
Corp nw
Wi-Fi Hotspot
Hotspot
Wi-Fi-UE (2) NT12 NSP
access
3GPP
I-WLAN hotspot 3GPP WLAN Access network
3GPP WiFi Internet
WLAN-UE (3) OR
Access (R6) NT12 WAG PDG
3GPP ISP
3GPP Access network

3GPP 3GPP-UE (4) RAN SGSN GGSN
Access (R5) (UMTS)
ASP
WIMAX Access network
WIMAX WIMAX-UE (5) BS ASN-GW
Access
BB Access network
Hotspot
Wi-Fi-UE (2) WLAN AP
access EN
Hotspot
Figure 58: MUSE FMC architecture
The description above is focused on describing the access technologies that are considered
by MUSE. However, when considering multi-access scenarios with roaming between
different accesses and possibly also between different providers as well as session
continuity, an architecture with well defined interfaces both towards the access and towards
the IP-transport and application level must be considered. This is currently being studied in
MUSE with the prime focus on how to re-use 3GPP I-WLAN architecture and to understand
the development of SAE/LTE. Since none fully align with the MUSE objectives many
challenges remain.

architecture III
IST - 6th FP
control signaling IMS

UTRAN PS mobile core
UE (terminals)
3GPP anchor
UMTS BS RNC SGSN
Gi SGi
IP
S5b
WLAN access network WLAN 3GPP IP access
SAE anchor
AP WAG PDG
WLAN Wi SGi
Home network MUSE access & aggregation network S5b

WLAN RGW AN SAE anchor
EN
Xx SGi
IASA = Inter Access

(Also other accesses connected in similar
System Anchor
way: WiMax, LTE RAN, …)
Figure 59: Sketch of FMC architecture along the lines of the 3GPP SAE architecture (TR 23.228)
Figure 58 shows the high-level picture of an FMC architecture based on the 3GPP SAE
work. The I-WLAN approach is reused for coupling the WLAN access. The SAE approach to
providing seamless handovers between accesses is to keep the outgoing connection to the
services, the SGi interface, fixed. Thus, the handovers are invisible at the service level. The
Inter Access System Anchor (IASA) provides the fixed SGi interface by routing between the
access networks. As mentioned above, the IASA/anchor architecture is not stable yet in
3GPP and therefore this picture can still change.
4.4.2 Policy control and charging

A PCC framework is presented here for supporting FMC and Nomadism in Access Networks.
Initially a classification and list of types of policies is addressed and then a framework is
proposed to support these types of policies.
4.4.2.1 Classification of Policies

The policies are classified into four main groups as follows:
User policies – Describe the identification of the user, the subscribed services, operational
parameters like priorities within the subscribed services, etc.
Service policies – Describe the service, network element requirements needed for the
service, user device requirements for the service, etc.
Network policies – Describe the functionality needed in the network such as QoS,
admission control, resource management, signalling policy between networks, etc.

architecture III
IST - 6th FP
Business policies – Describe SLAs, roaming agreements, charging rules, etc.
Further topics to be addressed here are to determine who the primary owners of the policies
are and who the responsible for policy enforcement are, etc.
4.4.3 Derivation of a Muse Policy Control Framework

A policy framework is described here within the MUSE architecture that supports FMC. An
overall study on what is going on in relevant SDOs, i.e., IETF, DSLF, ETSI TISPAN and ITU-
T, on this matter is firstly performed, and then a suitable Policy Control Framework is derived
for the specific case of FMC in Muse.
4.4.3.1 Research on Policy Control Framework

The Policy Control Framework presented hereinafter is the result of a research study taking
existing material of the above mentioned SDOs as a basis. This PCF architecture model
provides an abstraction layer between the application and the network layers, which hides
the complexity and variety of the underlying network and presents a single interface for
controlling network resources. In this section, FMC impacts on the PCF architecture will not
be considered.
4.4.3.2 Policy Control Framework for FMC

The objective of this subtask is to derive a Muse Policy Control Framework taking into
account the impact of FMC. As mentioned above, a research study has been initially
performed and an analysis of the MUSE SPC approach has lead to the identification of
several policy management players and associated roles as well as to several
interconnection aspects.
In the following, the application of the MUSE PCF is described with respect to management
and execution of policies. It is to be noted that the start of a service at the fixed access
network includes the scenario when a service session is transferred from another domain,
e.g. the mobile access network, to the fixed access network domain.
The need for a Functional Entity designated by an Access Policy Manager (APM) has been
recognized, which is equivalent to the policy manager mentioned in DSLF WT-134. On the
other hand, and taking the SPC approach on this matter as a basis, other policy
management entities can be identified, e.g., the Business Policy Management (BPM), the
Service Policy Management (SPM), the Network Policy Management (NPM), and the User
Policy Management (UPM). As a next step, the split of the APM into the NPM, SPM, UPM
concept, with BPM handled apart, will be evaluated. Moreover, the various types of policies
that must be present in these managers must be listed, in order to achieve their correct
positioning in the PCF.

architecture III
IST - 6th FP
4.4.3.2.1 Management of Policies

In order to respond as quickly as possible to the services that need fast response times,
relevant policies must be made available close to the point of inception of the service. This
can be achieved by making them available at local policy repositories. The policies that are
needed at these local policy repositories, as well as central policy repositories, need to be
complete as a whole in the sense that subscription policies, QoS policies, roaming policies,
charging policies, and all these types of policies that are used during a normal operation,
need to be available at the time of service inception. Figure 60 depicts the management of
policies within the fixed network domain to support FMC.
Policy Repository Packager
Nomadism
CPs
Provider
Policy Repository
Access Policy
Manager
Provider
FMC
Local Policy Central Policy Repository Local Policy
Repository User, service, network & Repository
User, service, network business rules User, service, network
& business rules & business rules RN
Policy SP1
Agr. N
AN EN SP2
Agr. N
Agr. N
SP3
Figure 60: Policy Management within Fixed Access Network
[0]An Access Policy Manager is needed to first check for race conditions or discrepancies in
the policies and also to be able to distribute the appropriate policies to the different local
policy servers and to the central server. This functionality is not needed for the Connectivity
Provider and for the Packager since there are no local or central policy servers in their
domains. Moreover, the discrepancies can be handled in a simpler way since these roles do
not operate complex networks. If needed, there can be a lightweight policy manager in both
of these latter roles.

architecture III
IST - 6th FP
In this context, another crucial issue that must be considered for suitable operation is related
to the inter-domain transfer of policies. Indeed, to support good response times in
transferring user sessions between different network technologies, e.g., between fixed
access networks and mobile access networks, or between different network administrative
domains, it is necessary to exchange some polices, which are relevant between the different
domains, in anticipation to the actual use of the subscribed services by the users. Just as an
example for the need of this inter-domain transfer of policies, the transfer of management
policies between a 3GPP PCC/R7 type mobility network domain and a fixed access network
domain is considered in Figure 61.
Muse Access Network

Policy Repository Packager
Mobility Provider
Offline Charging
CPs Nomadism System (OCS)
Provider
Policy Repository
Access
Policy
Manager Policy and Charging Subscription
Provider
Rules Function Policy Rules

FMC
(PCRF) (SPR)
Central Policy
Local Policy Repository Local Policy
Repository Repository Online Charging
SP1
Agr. N
System (OCS)
Used only in real time
Service Data
AN EN SP2 Camel Flow based
Agr. N
Agr. N
SCP Credit
Control
SP3
Figure 61: Inter-Domain Policy Management
Some of the relevant polices identified in the beginning are based in information related to
subscription, QoS, charging, etc.
Both the FMC and Nomadism providers depicted in the figure correspond to new types of
anchors that are currently being discussed in the overall architecture, in particular in its
roaming component, but with the intention of being applied to the FMC environment in this
case.
Another issue indicated in Figure 61 is the interconnection between the MUSE PCF
management plane and the PCC/R7 control plane, which is probably not the most
convenient approach. However, the fact is that PCC/R7 does not currently refer to the
management plane. Up till this moment only FEs in the control plane have been described,
where the information between domains would flow through a gateway.
As this inter-domain exchange of information has been considered relevant, it is possible that
the MUSE PCF may result in additional requirements to 3GPP-PCC/R7 to support the
magement framework as described above.

architecture III
IST - 6th FP
4.4.3.2.2 Policy Execution

The global rule of policy execution is that all policies are to be executed locally without
having to escalate policy execution to a remote policy server. It is only in cases where this is
not possible, e.g., due to sharing of network resources between different border nodes, that
the policy execution is escalated to the higher policy servers, such as central policy servers,
policy decision functions at CP level or beyond. Figure 62 shows the different policy servers
and the interaction between them within the fixed access network domain.
Packager
Nomadism
CPs
Provider
PDF
Provider
Central Policy Server
FMC
User, service, network &
Local Policy Server business rules Local Policy Server
User, service, network User, service, network
& business rules & business rules
RN PDF SP1
Agr. N
AN EN SP2
Agr. N
Agr. N
SP3
Figure 62: Policy Execution within Fixed Access Network
Furthermore, in Figure 63 a particular case of policy execution is considered where the user
requests services with an online charging policy type, e.g., prepaid amount decreased per
unit of service. In this case, the online charging system of the mobile access provider must
be accessed as it is needed at the start as well as during or at the end of the operation of the
service.

architecture III
IST - 6th FP
Policy Repository Packager Mobility Provider
Offline Charging
Nomadism
CPs
Provider
Policy Repository
System (OCS)
Access
Policy
Manager
Policy and Charging Subscription
Provider
FMC
Rules Function Policy Rules
Central Policy
(PCRF) (SPR)
Local Policy Repository Local Policy
Repository Repository
SP1 Online Charging
Agr. N
System (OCS)
Used only in real time
EN SP2 Service Data
AN
Agr. N
Agr. N
Camel Flow based

SCP Credit
SP3 Control
Figure 63: Inter-Domain Policy Execution

architecture III
IST - 6th FP
5 CONCLUSION
5.1 General architecture studies
A consolidation of the business roles model devised in MUSE was required as well as a
refinement of the responsibilities associated to each role. Therefore, an explicit distinction
between the business responsibilities and the technical responsibilities was made, together
with a detailed analysis of the technical responsibilities which are required for the AAA
architecture, IP address allocation, QoS framework, and ACS. Various contributions were
made to the DSL Forum, ETSI TISPAN and the HGI on these topics.
As an umbrella specification on the marketing requirements to be fulfilled by the broadband

network architecture, DSLF WT-144 was taken as a target to introduce operator's
requirements to offer authentication, Quality of Service, and to support nomadic services,
through a number of weighted use cases, aligned with the propositions made to ETSI
TISPAN.
DSLF WT-146 was taken as the target to specify the technical architecture that will allow the
performing of AAA and controlling subscribers' IP sessions in an environment where more
and more services are based on DHCP instead of PPP, and where multiple operators may
share the responsibilities to handle the traffic of nomadic and non-nomadic subscribers. The
strengths and weaknesses of different methods to monitor IP sessions, like BFD, ICMP and
traffic detection, were studied and described.
DSLF WT-134 was taken as the target to specify the policy framework in a converged IP
network. Propositions were made to implement CAC for unicast services like voice, as well
as CAC for multicast services like digital TV, in order to guarantee an optimal Quality of
Service to already established flows, taking as a hypothesis that the broadband network is
not dimensioned to carry all services to all users simultaneously.
Most of the items worked on have resulted in standards contributions. These contributions
have already partially met their goals and contribute paving the way for a standardisation of
the "GSB" architecture.
5.2 Multimedia in the Access studies

Chapter 3 on "Multimedia in Access" describes how the MUSE IP network model developed
during the first phase can be enriched with new capabilities to efficiently support and offer
Broadband services. Two methods to enable Multimedia Broadband support in the access
are proposed: distributed architectures and Quality of Experience (QoE).
TF1.7 studied the distribution of the functions of the Session Border Controller (SBC), usually
located centrally in the Service Provider Network domain, at two different levels of the
network. The first approach proposes to distribute the SBC functions into the Access Nodes
of the Access Network Provider. Different business models are identified and their impact on
the MUSE IP network model is analyzed. Finally, the benefits of this first model are
summarized. The feedback received by the operators and current market trends both
indicate that this approach could very well emerge in the short to medium term.

architecture III
IST - 6th FP
In the longer term, some functions of the SBC could even be pushed further into the
Residential Gateway (RGW). This is the second approach followed in the study of distributed
architectures. The document considers the functions that are candidate for further distribution
and studies the general impact on the MUSE architecture but also on its security, and its
cost. The techno-economic analysis of both models is currently being performed in MUSE
WPA3. The expected results from WPA3 should confirm the viability of the first approach of
distribution into Access Nodes and should also help MUSE forge a robust opinion on the
more challenging and longer term solution.
A second method to support MMBB in Access is introduced in part III: Quality of Experience.
(QoE) The state of the art and some general considerations about QoE are first analyzed
before studying in more detail QoE for selected categories of applications: Gaming, Video
(IPTV, VoD), Best Efforts Internet and Multimode multiparty applications. The interest of
operators in QoE was polled (in particular for Video (IPTV)) via a questionnaire. The ultimate
objective is to identify means to improve the quality of applications experienced by end-users
and again, to deduce the impact on the MUSE Ethernet and IP network models. It appears
that one way to solve this would be to derive the relationship between measurable
parameters and a mean QoE Score by tests in a controlled environment. Another way would
be that a provider asked for regular feedback on service quality from his customers and by
correlating this feedback with its network parameters, it would be able to set up the relation
by himself. The work on QoE has already resulted in several contributions to DSLF WT126.
5.3 FMC challenges

The step towards next generation broadband access architecture includes not only triple play
but also support for quadruple play which in essence means support for mobility. In MUSE
this is studied from a network perspective where new or enhanced functions are added to
enable a FMC architecture that will help a fixed access provider to also include mobility
support. The work in MUSE revolves around four use cases:
• Nomadism use case with video call
• Nomadism use case with IPTV
• Session Continuity with conversational services Nomadic user with public access to
private domain
• Nomadic user with public access to private domain
From these, new network requirements are derived and based on these, architectural
solutions for the above use cases will be worked out.
Authentication is a vital function for nomadism and FMC. In this work primarily per line and
per user authentication have been investigated to find a good solution for network access
authentication and service authentication. 802.1X is a common technology to use for
authentication, but in the MUSE scenario this has proven to have difficulties since it does not
allow NAT traversal or routed, un-trusted RGWs. PANA has also been investigated and also
found to have similar problems. Work is on-going to provide solutions for this, but the current
result is that there is no good solution for line authentication for routed and or/un-un-trusted
RGWs.

architecture III
IST - 6th FP
It is envisaged that some sort of xSIM is used for per user/per service authentication in
addition to the per line authentication. Consequently EAP-SIM or EAP-AKA are the preferred
protocols to carry authentication messages.
MUSE considers both network layer and application layer mobility management methods to
support Session Continuity and Continuous Mobility of mobile terminals. Current
implementations of SIP and MIP mobility management schemes are able to provide Session
Continuity, but with noticeable service interruption or loss of data while changing network
attachment points. Neither SIP nor MIP are able to provide Session Continuity.
The dominant factor of SIP and MIP handover latency is linked to the network layer
movement detection and IP address configuration. SIP or MIP handover signalling causes
only a minor part of total handover latency. Consequently, it is not possible to select a
superior mobility management method (SIP vs. MIP) in terms of handover performance since
basic implementations of both protocols have handover latencies of the same order of
magnitude. Studies in MUSE indicate that improvements to the handover mechanisms are
necessary.
Application layer mobility management methods can be enhanced by means of PAR

(Proactive Address Reservation) which provides efficient mechanism to improve handover
performance. It employs link layer information to anticipate handover and allows terminal to
obtain IP configuration before link layer handover.

layer seamless mobility. It employs access network elements to assist the terminal whilst
dual mode terminal) and Mobility Manager (network triggers handover and instructs terminal
what access network to choose). Network-supported handover promises to provide
Continuous Mobility for the moving terminals.
A policy framework is described within the MUSE architecture that supports FMC and
Nomadism. The application of the policy framework is described with reference to the
management and execution of policies. The aim is to make relevant policies available close
to the point of inception of the service by making them available at local repositories.
In addition to the functionality described MUSE is also looking into how fixed access
networks should interact with mobile operators’ networks for supporting FMC and nomadism.

architecture III

Muse DTF1.6 V1.0 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Muse DTF1.6 V1.0 PDF

Uploaded by

Copyright:

Available Formats

IST - 6th FP

Project Deliverable Contract N° 026442

D TF1.6 - Access network architecture III

Antonio J. Elizondo (D TF1.6 editor)

Christophe Alter (TF 1.6 responsible)

Identifier: Deliverable D TF1.6

D TF1.6 – Access network 1/170 Public

Project acronym MUSE

Project full title Multi-Service Access Everywhere

Security (distribution level) Public

Contractual delivery date October, 31st 2006

Actual delivery date November, 8th 2006

Deliverable number D TF1.6

Deliverable name Access network architecture III

Status & version Final 1.0

Number of pages 170

WP / TF contributing TF1.6, TF1.7, TF1.8

Editor(s) Antonio J. Elizondo (TID)

EU Project Officer Pertti Jauhiainen

Keywords Business roles, Authentication and Authorization, IP sessions,

D TF1.6 – Access network 2/170 Public

D TF1.6 – Access network 3/170 Public

0.0 12/9/2006 First tentative ToC Draft

0.3 15/9/2006 ToC with allocation of chapter Draft

0.4 2/10/2006 First integrated draft Draft

0.41 4/10/2006 Introduction and sections on PCC and Draft

0.5 23/10/2006 Reviewed draft Draft

0.6 30/10/2006 Quality reviewed draft Draft

0.7 3/11/2006 Second quality review draft Draft

1.0 8/11/2006 Final deliverable Final

D TF1.6 – Access network 4/170 Public

D TF1.6 – Access network 5/170 Public

D TF1.6 – Access network 6/170 Public

D TF1.6 – Access network 7/170 Public

D TF1.6 – Access network 8/170 Public

Figure 34: Detectability on audio-video desynchronisation (ITU-R BT.1359) ...........................123

D TF1.6 – Access network 9/170 Public

D TF1.6 – Access network 10/170 Public

C-VLAN Customer VLAN

D TF1.6 – Access network 11/170 Public

GSB Global System for Broadband communications

D TF1.6 – Access network 12/170 Public

LEA Law Enforcement Agencies

D TF1.6 – Access network 13/170 Public

PAE Port Access Entity

D TF1.6 – Access network 14/170 Public

SLA Service Level Agreement

D TF1.6 – Access network 15/170 Public

VRF Virtual Routing and Forwarding

D TF1.6 – Access network 16/170 Public

[4] MUSE deliverable DA4.2 “Standardisation plan”, August 2006

[6] MUSE deliverable DC4.2 “Preliminary evaluation report on a point-to-point

[9] Enhanced Telecom Operations Map (eTOM), TeleManagement Forum,

[10] ETSI DTS/TISPAN-07013 v0.0.11 Telecommunications and Internet converged

[13] ETSI TS 123.228 V5.5.0 Digital cellular telecommunications system (Phase

D TF1.6 – Access network 17/170 Public

[19] ITU-T Recommendation G.1010, “End-user multimedia QoS categories”

[20] ITU-T Recommendation G.1030, “Estimating end-to-end performance in IP

[21] ITU-T Recommendation G.1030 Annex A, “Opinion model for web-browsing

[22] ITU-T Recommendation J.148, “Requirements for an objective perceptual

[23] ITU-T Recommendation P.800, “Methods for subjective determination of

[25] ITU-T Recommendation P.911, “Subjective audiovisual quality assessment

[26] ITU-T Recommendation P.920, “Interactive test methods for audiovisual