ORGANIZATION OF AMERICAN STATES
INTER-AMERICAN TELECOMMUNICATION COMMISSION
PERMANENT CONSULTATIVE COMMITTEE I:
TELECOMMUNICATION STANDARDIZATION
Technical Notebook:
NEXT GENERATION NETWORKS
Standards Overview
TECHNICAL NOTEBOOK-1 rev.113 (2011)
Output of XVII CITEL PCC.I Meeting (Lima, Peru)
Next Generation Networks – Standards Overview
Reference: P1!T-478/04 & P1!T-581/05 & P1!T-686/05 & P1!T-776/06 & P1!T-863/06 &
P1!T-991/07& P1!T-1206/07 & P1!T-1297/08 & P1!T-1438/08 & P1!T-1658/09 rev.2, &
P1!T-1751/09, P1!T-1898/09, & P1!T-2120/10
CITEL
Inter-American Telecommunication Commission
1889 F St.NW #1020
Washington, DC
United States
http://citel.oas.org
For additional information please contact:
Wayne Zeuch
Tel: +1 732 290 0247
E-mail: waynezeuch@aol.com
or
Executive Secretary of CITEL
Tel: +1 202 458 3004
Fax: +1 202 458 6854
E-mail: citel@oas.org
@ CITEL, OctoberMarch 2011
All rights reserved. No part of this publication may be reproduced or utilized in any form or by
any means, electronic or mechanical, including photocopying and microfilm, without permission
in writing from the CITEL.
ii
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
TECHNICAL NOTEBOOK1
A Technical Notebook provides a formalised means of maintaining a file of a project’s technical
information that will be available to the telecommunications industry in the Member States.
CITEL uses Technical Notebooks when:
a) Publishing technical information for network characterizations or service functionality for new or
existing services.
b) Describing/reporting the status of a study project for the current or future use of a Working
Group.
c) Publicizing findings of a study, review or survey.
d) Documenting procedures, inter-working or interconnection issues which would benefit the
industry but which are not adaptable or practical as a Coordinated Standard Document (CSD).
e) Documenting standards, completed or in progress, for new or existing services, which may be
considered for future development into a CSD in accordance with the approval procedures of the
Technology Working Group.
The members of CITEL have not approved the contents of this document.
1
PCC.I/RES. 142 (XV-01)
iii
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
INDEX
1
NGN ARCHITECTURE .................................................................... Error! Bookmark not defined.
1.1
NGN Voice/Data Converged Architecture .................................... Error! Bookmark not defined.
1.2
NGN Service Converged Architecture .......................................... Error! Bookmark not defined.
1.3
NGN Release 1 Architecture ......................................................... Error! Bookmark not defined.
1.3.1
Transport Layer.............................................................................. Error! Bookmark not defined.
1.3.1.1
Transport Functions .......................................................... Error! Bookmark not defined.
1.3.1.1.1 Access network functions ............................................ Error! Bookmark not defined.
1.3.1.1.2 Edge functions ............................................................. Error! Bookmark not defined.
1.3.1.1.3 Core transport functions .............................................. Error! Bookmark not defined.
1.3.1.1.4 Gateway functions ....................................................... Error! Bookmark not defined.
1.3.1.2
Media handling functions ................................................. Error! Bookmark not defined.
1.3.2
Transport control functions ............................................................ Error! Bookmark not defined.
1.3.2.1
Resource and admission control functions (RACF) ......... Error! Bookmark not defined.
1.3.2.2
Network attachment control functions (NACFs) .............. Error! Bookmark not defined.
1.3.3
Service Layer functions ................................................................. Error! Bookmark not defined.
1.3.3.1
Service control functions .................................................. Error! Bookmark not defined.
1.3.3.2
Application support functions and service support functions .......... Error! Bookmark not
defined.
1.3.4
End-user functions ......................................................................... Error! Bookmark not defined.
2
NGN SERVICE CAPABILITIES ...................................................... Error! Bookmark not defined.
2.1
ITU-T NGN Service Architecture ................................................. Error! Bookmark not defined.
2.2
Open Programmability Environment Standards ............................ Error! Bookmark not defined.
2.2.1
Parlay ............................................................................................. Error! Bookmark not defined.
2.2.1.1
Parlay Specifications......................................................... Error! Bookmark not defined.
2.2.2
Open Mobile Alliance (OMA) Service Environment .................... Error! Bookmark not defined.
2.3
IPTV............................................................................................... Error! Bookmark not defined.
2.3.1
ATIS IPTV Interoperability Forum (IIF) ....................................... Error! Bookmark not defined.
2.3.2
ITU-T Standardization ................................................................... Error! Bookmark not defined.
2.3.2.1
IPTV FG Working Groups................................................ Error! Bookmark not defined.
2.3.2.2
IPTV Global Standards Initiative (IPTV-GSI) ................. Error! Bookmark not defined.
2.4
Emergency Telecommunications Services .................................... Error! Bookmark not defined.
2.4.1
Emergency Telecommunications Services Types.......................... Error! Bookmark not defined.
2.4.2 Standardization Activity on Emergency Telecommunications ServicesError! Bookmark not
defined.
2.4.2.1
ITU Activities ................................................................... Error! Bookmark not defined.
2.4.2.2
IETF Activities ................................................................. Error! Bookmark not defined.
2.4.2.3
ETSI Activities ................................................................. Error! Bookmark not defined.
2.4.2.4
ATIS Activities ................................................................. Error! Bookmark not defined.
2.4.2.5
Other Fora Activities ........................................................ Error! Bookmark not defined.
1
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
2.5
Service Oriented Networks ............................................................ Error! Bookmark not defined.
2.5.1
ATIS SON Forum .......................................................................... Error! Bookmark not defined.
2.5.2
Objectives ...................................................................................... Error! Bookmark not defined.
2.5.3
SON Framework ............................................................................ Error! Bookmark not defined.
2.5.4
SON Forum Task Forces ............................................................... Error! Bookmark not defined.
2.5.4.1
Policy and Data Models TF .............................................. Error! Bookmark not defined.
2.5.4.2
OSS/BSS and Virtualization TF ....................................... Error! Bookmark not defined.
2.5.4.3
Service Delivery Creation and Enablers TF ..................... Error! Bookmark not defined.
2.6
Home Networking...................................................................................................................... 2.5.5
SON Standards ............................................................................... Error! Bookmark not defined.
2.6.1
ATIS Home Networking (HNET) Forum ..................................................................................... 2.6
Cloud Computing ........................................................................... Error! Bookmark not defined.
2.6.2
HNET Forum Objectives ........................................................................................................... 2.6.1
ATIS Cloud Services Forum .......................................................... Error! Bookmark not defined.
2.6.3
HNET Work Plan.......................................................................................................................... 2.7
Home Networking.......................................................................... Error! Bookmark not defined.
3
NGN MOBILITY........................................................................................................................... 2.7.1
ATIS Home Networking (HNET) Forum .......................................... Error! Bookmark not defined.
4
NGN QUALITY OF SERVICE ..................................................................................................... 2.7.2
HNET Forum Objectives ................................................................... Error! Bookmark not defined.
5
NGN SIGNALING ........................................................................................................................ 2.7.3
HNET Work Plan ............................................................................... Error! Bookmark not defined.
5.1
Wireline Access ............................................................................................................................ 2.8
SMART GRID ............................................................................... Error! Bookmark not defined.
5.1.1
Metallic Access Standards ......................................................................................................... 2.8.1
U.S. Smart Grid Program (NIST) .................................................. Error! Bookmark not defined.
5.1.1.1
Testing and Maintenance ........................................................................................... 2.8.1.1
Standards Priorities ........................................................... Error! Bookmark not defined.
5.1.1.1.1 Basic Objective of L.75 Recommendation .............................................................. 2.8.2
Smart Grid Interoperability Panel (SGIP) ................... Error! Bookmark not defined.
5.1.2
Fiber Access Standards .................................................................................................................... 3
NGN MOBILITY .......................................................................... Error! Bookmark not defined.
5.1.3
Power Line Access Standards .......................................................................................................... 4
NGN QUALITY OF SERVICE .................................................... Error! Bookmark not defined.
5.2
Wireless Access ............................................................................................................................... 5
NGN SIGNALING ........................................................................ Error! Bookmark not defined.
5.2.1
WLAN (IEEE 802.11) Wi-Fi ........................................................................................................ 5.1
Wireline Access ............................................................................. Error! Bookmark not defined.
5.2.2
Mobile Broadband Wireless Access (IEEE 802.20) .................................................................. 5.1.1
Metallic Access Standards ............................................................. Error! Bookmark not defined.
2
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
5.3
6
Satellite ................................................................................................................................... 5.1.1.1
Testing and Maintenance ............................................................... Error! Bookmark not defined.
SECURITY .............................................................................................................................. 5.1.1.1.1
Basic Objective of L.75 Recommendation......................................... Error! Bookmark not defined.
65.1
ITU-T Security.2Fiber
Error! Bookmark not defined.
Access
Standards
6.1.1
Approved ITU-T Security Recommendations ........................................................................... 5.1.3
Power Line Access Standards ........................................................ Error! Bookmark not defined.
6.1.2
SG 17 Security Work in progress (selected items) ....................................................................... 5.2
Wireless Access ............................................................................. Error! Bookmark not defined.
6.1.3
SG 13 security work in progress (Q15/13) ............................................................................... 5.2.1
WLAN (IEEE 802.11) Wi-Fi ......................................................... Error! Bookmark not defined.
6.2
Identity Management ................................................................................................................. 5.2.2
Mobile Broadband Wireless Access (IEEE 802.20) ...................... Error! Bookmark not defined.
6.2.1
Identity Management Concepts .................................................................................................... 5.3
Satellite .......................................................................................... Error! Bookmark not defined.
6.2.2
Activities .......................................................................................................................................... 6
SECURITY .................................................................................... Error! Bookmark not defined.
6.2.2.1
ITU-T Security Standards bodies and similar organizations ........... Error! Bookmark not
defined.
6.2.2.2
Research Activities ....................................................................................................... 6.1.1
Approved ITU-T Security Recommendations .................. Error! Bookmark not defined.
6.2.2.3
Other Identity Management Related Activities ............................................................ 6.1.2
SG 17 Security Work in progress (selected items) ........... Error! Bookmark not defined.
ANNEX 1 - Standards Endorsed by CITEL PCC.I Resolutions .......................................................... 6.1.3
.................................................................................................... SG 13 security work in progress (Q15/13)
.................................................................................................................... Error! Bookmark not defined.
ANNEX 2 - NGN Library........................................................................................................................ 6.2
...................................................................................................................................... Identity Management
.................................................................................................................... Error! Bookmark not defined.
7
NGN Introduction .......................................................................................................................... 6.2.1
Identity Management Concepts .......................................................... Error! Bookmark not defined.
7.1
NGN Standards Efforts .............................................................................................................. 6.2.2
Activities ........................................................................................ Error! Bookmark not defined.
7.2
ITU .......................................................................................................................................... 6.2.2.1
Standards bodies and similar organizations ................................... Error! Bookmark not defined.
7.3
ETSI ........................................................................................................................................ 6.2.2.2
Research Activities ........................................................................ Error! Bookmark not defined.
7.4
ATIS........................................................................................................................................ 6.2.2.3
Other Identity Management Related Activities ............................. Error! Bookmark not defined.
3
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
7.5
8
IETF ................................................................................................................................................. 7
CONFORMANCE AND INTEROPERABILITY ........................ Error! Bookmark not defined.
Signaling Standards ........................................................................................................................... 7.1
ITU-T Standardization ....................................................................... Error! Bookmark not defined.
8.1
SIGTRAN (SIGnaling TRANsport) .......................................................................................... 7.1.1
Joint Coordination Activity – Conformance and Interoperability TestingError! Bookmark not
defined.
87.1.2 BICCITU-T
Error! Bookmark not defined.
8.3
Study
Group
11
Megaco/H.248............................................................................................................................ 7.1.3
ITU-T Approved Standards on Test Specifications ....................... Error! Bookmark not defined.
87.1.4 SIPITU-T
Draft
and
Error! Bookmark not defined.
Completed
Standards
on
Test
Specifications
8.4.1
SIP Operation ............................................................................................................................. 7.1.5
ITU-T Interoperability Events ....................................................... Error! Bookmark not defined.
8.5
SIP-TANNEX 1
Standards
Error! Bookmark not defined.
8.6
Q.1912.5ANNEX
2
Error! Bookmark not defined.
8.7
H.323................................................................................................................................................ 8
NGN Introduction .......................................................................... Error! Bookmark not defined.
9
9.1
Endorsed
-
by
CITEL
PCC.I
Resolutions
NGN
Library
Access8.1 ..........................................................................................................NGN Standards Efforts
Error! Bookmark not defined.
Wired Access Standards .............................................................................................................. 8.2
ITU ................................................................................................. Error! Bookmark not defined.
9.1.1
Digital Subscriber Line (DSL) Access Standards ......................................................................... 8.3
ETSI ............................................................................................... Error! Bookmark not defined.
9.1.1.1
ATM over ADSL ............................................................................................................. 8.4
ATIS ................................................................................. Error! Bookmark not defined.
9.1.1.2
AAL5 over ATM ............................................................................................................. 8.5
IETF .................................................................................. Error! Bookmark not defined.
9.1.1.3
Protocol ‘x” over AAL5 ..................................................................................................... 9
Signaling Standards .......................................................... Error! Bookmark not defined.
9.1.2
IP Access Requirements ............................................................................................................... 9.1
SIGTRAN (SIGnaling TRANsport) .............................................. Error! Bookmark not defined.
9.1.2.1
PPP (Point-to-Point Protocol) ...............................................................................................
BICC ................................................................................. Error! Bookmark not defined.
9.1.2.1.1 IP Considerations ........................................................................................................ 9.3
Megaco/H.248 ............................................................. Error! Bookmark not defined.
9.1.2.1.2 PPP over AAL5 .......................................................................................................... 9.4
SIP ............................................................................... Error! Bookmark not defined.
9.1.2.1.3 PPP over Ethernet .................................................................................................... 9.4.1
SIP Operation .............................................................. Error! Bookmark not defined.
4
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
9.1.2.1.4
9.1.2.16
9.1.2.1.6
IP over AAL5 ............................................................................................................. 9.5
SIP-T............................................................................ Error! Bookmark not defined.
Q.1912.5 ........................................................................................ IP over Ethernet
Error! Bookmark not defined.
Layer 2 Tunneling Protocol (L2TP) ........................................................................... 9.7
H.323 ........................................................................... Error! Bookmark not defined.
9.1.3
Cable 10Access
Error! Bookmark not defined.
9.2
Wireless10.1Wired
Error! Bookmark not defined.
9.2.1
Broadband Wireless Access (IEEE 802.16) WiMAX ............................................................ 10.1.1
Digital Subscriber Line (DSL) Access Standards .......................... Error! Bookmark not defined.
9.2.2
IMT-2000 (3GPP, 3GPP2).................................................................................................... 10.1.1.1
ATM over ADSL ........................................................................... Error! Bookmark not defined.
9.2.2.1
3GPP ........................................................................................................................ 10.1.1.2
AAL5 over ATM .............................................................. Error! Bookmark not defined.
9.2.2.2
3GPP2 ...................................................................................................................... 10.1.1.3
Protocol ‘x” over AAL5 ................................................... Error! Bookmark not defined.
10
Transport Standards ..................................................................................................................... 10.1.2
IP Access Requirements ..................................................................... Error! Bookmark not defined.
10.1
Standards
Access
Standards
Requirements for Transport Functions ................................................................................. 10.1.2.1
PPP (Point-to-Point Protocol) ........................................................ Error! Bookmark not defined.
Transport Technologies and their evolution ................................................................................... 10.1.2.1.1
IP
Considerations
.................................................................................................................... Error! Bookmark not defined.
10.2
Circuit-switched technologies ............................................................................................ 10.1.2.1.2
PPP over AAL5 ............................................................................. Error! Bookmark not defined.
10.1.2.1
SONET/SDH .............................................................................................................................. .3
PPP over Ethernet ...................................................................... Error! Bookmark not defined.
10.2.2
Optical Transport Network (OTN) ................................................................................ 10.1.2.1.4
IP over AAL5 ............................................................................ Error! Bookmark not defined.
10.3
Packet-switched technologies ............................................................................................ 10.1.2.1.5
IP over Ethernet ............................................................................. Error! Bookmark not defined.
10.3.1
Ethernet as NGN transport technology .......................................................................... 10.1.2.1.6
Layer 2 Tunneling Protocol (L2TP) .......................................... Error! Bookmark not defined.
10.3.2
Ethernet network topologies ................................................................................................ 10.1.3
Cable Access Standards ............................................................. Error! Bookmark not defined.
10.3.3
Evolution to "Carrier-class" Ethernet ..................................................................................... 10.2
Wireless Access Standards ........................................................ Error! Bookmark not defined.
10.3.4
Issues that need to be completed in a “Carrier-class” Ethernet ........................................... 10.2.1
Broadband Wireless Access (IEEE 802.16) WiMAX .............. Error! Bookmark not defined.
5
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
10.3.5
Present standards activities on Ethernet .............................................................................. 10.2.2
IMT-2000 (3GPP, 3GPP2) ........................................................ Error! Bookmark not defined.
10.3.6
Similarities and differences between IP and “Carrier-class” Ethernet ............................. 10.2.2.1
3GPP .......................................................................................... Error! Bookmark not defined.
10.4
Transport MPLS (T-MPLS) .................................................................................................. 10.2.2.2
3GPP2 ............................................................................................ Error! Bookmark not defined.
11Transport
Standards
Error! Bookmark not defined.
10.4.1
11
landscape
for
MPLS-T
Management Standards ................................................................................................................... 11.1
Requirements for Transport Functions ............................................... Error! Bookmark not defined.
11.1
ITU-T SG 4Transport
Technologies
Error! Bookmark not defined.
11.1.1
11.2
and
their
evolution
NGN Network Management Focus Group ............................................................................. 11.2
Circuit-switched technologies ................................................... Error! Bookmark not defined.
IETF ................................................................................................................................................ .1
SONET/SDH ................................................................................. Error! Bookmark not defined.
11.2.1
Simple2Optical
Transport
Error! Bookmark not defined.
11.2.2
NETCONF Configuration Protocol ........................................................................................ 11.3
Packet-switched technologies .................................................... Error! Bookmark not defined.
12
Management
Protocol
(SNMP(OTN)
Service Creation Standards .......................................................................................................... 11.3.1
Ethernet as NGN transport technology .............................................. Error! Bookmark not defined.
12.1
13
Network
Intelligent Network Capability Set (IN CS-4) ......................................................................... 11.3.2
Ethernet network topologies .......................................................... Error! Bookmark not defined.
Security Standards ........................................................................................................................ 11.3.3
Evolution to "Carrier-class" Ethernet ................................................. Error! Bookmark not defined.
13.1
IP Security (IPSec) ................................................................................................................... 11.3.4
Issues that need to be completed in a “Carrier-class” Ethernet ..... Error! Bookmark not defined.
13.1.1
Security Associations (SAs) ................................................................................................ 11.3.5
Present standards activities on Ethernet .................................... Error! Bookmark not defined.
13.1.2
Authentication Header (AH) ............................................................................................... 11.3.6
Similarities and differences between IP and “Carrier-class” EthernetError! Bookmark not
defined.
13.1.3
Encapsulation Security Payload (ESP) ................................................................................... 11.4
Transport MPLS (T-MPLS) ...................................................... Error! Bookmark not defined.
13.1.4
Key Management ................................................................................................................. 11.4.1
Standards landscape for MPLS-T .............................................. Error! Bookmark not defined.
13.1.5
Manual Key Exchange............................................................................................................... 12
Management Standards.............................................................. Error! Bookmark not defined.
6
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
13.2
Internet Key Exchange (IKE) ..................................................................................................... 12.1
ITU-T SG 4 .................................................................................... Error! Bookmark not defined.
13.2.1
Main Mode .......................................................................................................................... 12.1.1
NGN Network Management Focus Group ................................ Error! Bookmark not defined.
13.2.2
Aggressive Mode .................................................................................................................... 12.2
IETF........................................................................................... Error! Bookmark not defined.
13.2.3
Quick Mode ......................................................................................................................... 12.2.1
Simple Network Management Protocol (SNMP) ...................... Error! Bookmark not defined.
13.3
Security Architecture for Systems Providing End-to-End Communications ........................... 12.2.2
NETCONF Configuration Protocol ............................................... Error! Bookmark not defined.
13.3.1
Security Dimensions .................................................................................................................. 13
Service Creation Standards ........................................................ Error! Bookmark not defined.
13.3.2
Security Layers ....................................................................................................................... 13.1
Intelligent Network Capability Set (IN CS-4) ........................... Error! Bookmark not defined.
13.3.314 Security Planes .............................................................................................................. Standards
Error! Bookmark not defined.
14
QoS and Performance Standards ..................................................................................................... 14.1
IP Security (IPSec) ............................................................................. Error! Bookmark not defined.
14.1
QoS in IP-based Networks ....................................................................................................... 14.1.1
Security Associations (SAs) .......................................................... Error! Bookmark not defined.
14.1.1
Achieving Traditional PSTN Service Quality in IP Networks ............................................ 14.1.2
Authentication Header (AH) ..................................................... Error! Bookmark not defined.
14.1.2
VoIP Service Characteristics and Expectations ................................................................... 14.1.3
Encapsulation Security Payload (ESP) ...................................... Error! Bookmark not defined.
14.1.3
Strategy for QoS in IP-based Networks............................................................................... 14.1.4
Key Management ....................................................................... Error! Bookmark not defined.
14.1.4
Technologies supporting QoS in IP Networks .................................................................... 14.1.5
Manual Key Exchange............................................................... Error! Bookmark not defined.
14.1.4.1 Integrated Services (Int-Serv) ........................................................................................ 14.2
Internet Key Exchange (IKE) ........................................... Error! Bookmark not defined.
14.1.4.2 Differentiated Services (Diff-Serv)............................................................................. 14.2.1
Main Mode........................................................................ Error! Bookmark not defined.
14.1.4.3 Quality-of-Service Policy ........................................................................................... 14.2.2
Aggressive Mode .............................................................. Error! Bookmark not defined.
14.1.4.4 Multi-Protocol Label Switching (MPLS) ................................................................... 14.2.3
Quick Mode ...................................................................... Error! Bookmark not defined.
14.2
Network Performance Objectives ............................................................................................... 14.3
Security Architecture for Systems Providing End-to-End CommunicationsError! Bookmark not
defined.
14.23.1
Y.1540Security
Error! Bookmark not defined.
Dimensions
7
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
14.2.2
15
Y.1541 ................................................................................................................................. 14.3.2
Security Layers .......................................................................... Error! Bookmark not defined.
Evolutionary Standards ................................................................................................................ 14.3.3
Security Planes ................................................................................... Error! Bookmark not defined.
Internet Protocol version 6 (IPv6) .................................................................................................. 15
QoS and Performance Standards ................................................... Error! Bookmark not defined.
15.1
15.1.1
IPv4 Workarounds .................................................................................................................. 15.1
QoS in IP-based Networks ........................................................ Error! Bookmark not defined.
15.1.2
Location Tracking ............................................................................................................... 15.1.1
Achieving Traditional PSTN Service Quality in IP Networks .. Error! Bookmark not defined.
15.1.3
IPv6 Addressing .................................................................................................................. 15.1.2
VoIP Service Characteristics and Expectations ......................... Error! Bookmark not defined.
15.1.4
IPv6 Address Representation............................................................................................... 15.1.3
Strategy for QoS in IP-based Networks..................................... Error! Bookmark not defined.
15.1.5
IPv6 Address types .............................................................................................................. 15.1.4
Technologies supporting QoS in IP Networks .......................... Error! Bookmark not defined.
15.1.6
IPv6 Unicast Addresses .................................................................................................... 15.1.4.1
Integrated Services (Int-Serv) .................................................... Error! Bookmark not defined.
15.1.7
IPv6 Anycast Addresses ................................................................................................... 15.1.4.2
Differentiated Services (Diff-Serv) ........................................... Error! Bookmark not defined.
15.1.8
Multicast Addresses.......................................................................................................... 15.1.4.3
Quality-of-Service Policy .......................................................... Error! Bookmark not defined.
15.2
Electronic Numbering (ENUM) ........................................................................................... 15.1.4.4
Multi-Protocol Label Switching (MPLS) ...................................... Error! Bookmark not defined.
Resolutions............................................................................................................................................... 15.2
................................................................................................................... Network Performance Objectives
.................................................................................................................... Error! Bookmark not defined.
References ............................................................................................................................................. 15.2.1
............................................................................................................................................................ Y.1540
.................................................................................................................... Error! Bookmark not defined.
Acronyms and Abbreviations ............................................................................................................... 15.2.2
Y.1541 ....................................................................................... Error! Bookmark not defined.
16
Evolutionary Standards .................................................................................................................... 102
16.1
Internet Protocol version 6 (IPv6) ................................................................................................ 102
16.1.1
IPv4 Workarounds ................................................................................................................... 102
16.1.2
Location Tracking ................................................................................................................... 104
16.1.3
IPv6 Addressing ...................................................................................................................... 104
16.1.4
IPv6 Address Representation................................................................................................... 104
8
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
16.1.5
IPv6 Address types .................................................................................................................. 105
16.1.6
IPv6 Unicast Addresses ........................................................................................................... 105
16.1.7
IPv6 Anycast Addresses .......................................................................................................... 105
16.1.8
Multicast Addresses................................................................................................................. 106
16.2
Electronic Numbering (ENUM) .................................................................................................. 106
Resolutions................................................................................................................................................ 108
References ................................................................................................................................................. 109
Acronyms and Abbreviations ................................................................................................................... 110
9
533576827
02.10.09
04.03.11
Next Generation Networks– Standards Overview
NEXT GENERATION NETWORKS – STANDARDS
OVERVIEW
Summary
Next Generation Networks (NGN) are converged voice/data multi-service networks that operate in a
multi-vendor environment. NGNs require an architecture that provides seamless integration of both new
and traditional telecommunications services across high-speed packet networks, interworking among
clients of heterogeneous capabilities. This architecture is usually structured around four major layers of
technology. The core connectivity layer includes routing and switching, network and access gateways.
The access and customer-premises equipment (CPE) layer includes the various technologies used to reach
customers. The application server layer contains enhanced services and value-added applications. The
management layer provides network services and business management functions. Each of these layers is
supported by a number of standards that are key to the successful implementation of an NGN. An
emerging vision of an NGN, which is based on a wireless and wireline networks converged paradigm, is
being actively developed by the ITU-T.
The Next Generation Networks – Standards Overview document identifies NGN related standards that the
Rapporteur Group on Standards, Conformance, and Interoperability is studying, including architecture,
service capabilities, relevant protocols, and Internet Telephony. As relevant contributions are submitted
and discussed by the Working Group on Deployment of Technologies and Services, this document will be
updated on an ongoing basis.
10
533576827
02.10.09
04.03.11
1
NGN ARCHITECTURE
The architecture and implementation of the Next Generation Network (NGN) must be based on open,
standard-based interfaces and protocols. This is essential to achieve multi-vendor interworking and to
accelerate the rate on innovation. It is also well accepted that the NGN must also be based on a distributed
architecture that helps greatly to reduce the implementation costs while giving flexibility in the actual
deployment. The ITU-T Recommendation Y.2001, “General Overview of NGN”, Dec. 2004, provides a
definition of an NGN.
The NGN must be able to support highly customizable services that are easily and rapidly created as well
as deployed economically throughout the network. While it is important to enable new services, it is also
critical to preserve the existing services provided by the legacy network.
NGN and the Internet
The phrase “Next Generation Network” (NGN) has both a generic and specific meaning. Generically, it
is used to refer to “some future version of networking”, while specifically it refers to work described in
ITU-T Recommendation Y.2001. When not used precisely, an impression is built that “the NGN” is
intended to supplant “the Internet”. According to ITU-T Recommendation Y.2001, a Next Generation
Network (NGN) is a packet-based network that separates services from underlying transport. This allows
providers to develop and deploy new services without changing the underlying network hardware, in
ways that are not possible with traditional circuit-switched networks. NGN-based networks provide Voice
over IP (VoIP) on the packet-based network, rather than maintaining a separate voice network switching
infrastructure.
A focused definition of the Internet is that it is a global network of networks, consisting of millions of
participating commercial, academic, public, and government networks using packet-switching technology
based on the Internet Protocol (IP). As a network, it provides mechanisms for routing packets from one
endpoint to another endpoint anywhere in the global network. It is defined independently of the
underlying transmission layer and the applications and services that are defined to use it.
Internet protocol specifications, including IP and MPLS, are developed and maintained by the Internet
Engineering Task Force (IETF – http://www.ietf.org). Therefore, no choice is required between the
Internet and the NGN. The NGN represents one, but not the only, set of applications and services that
can be supported.
[Ref: P1!T-1779_i.doc; 2009-09]
1.1 NGN Voice/Data Converged Architecture
Figure 1 describes an NGN architecture of a converged voice/data network that is generally consistent
with the vision that most operators have. The architecture can be decomposed into several layers: Core
connectivity, Access and Customer Premise Equipment (CPE), Services, and Management.
11
533576827
02.10.09
04.03.11
Figure 1 - Next Generation Network Voice/Data Converged Architecture
Core Connectivity Layer
The core connectivity layer provides the general routing and switching of network traffic from one end of
the network to the other. It is based on packet technology, either ATM or IP, providing maximum
flexibility. The technology of choice will be dictated by business considerations, but service transparency
and quality of service (QoS) have to be ensured in any case since quality disturbances such as delay, jitter
and echo must not affect the customer traffic.
At the edge of the packet backbone are the gateways: their main role is to adapt the customer and control
traffic to the NGN technology. The gateways interface either with other networks, in which case they are
called network gateways, or directly with end-user equipment, in which case they are called access
gateways. The gateways interwork with the Service layer components using open protocols to deliver
existing and new services.
Access Layer
The access layer includes the various technologies used to reach customers. Access was usually limited in
the past to copper lines or DS1/E1. We now see a proliferation of technologies that have emerged to
address the need for higher bandwidth and to provide competitive carriers with a means to directly reach
customers. Cable, xDSL and wireless are among the most promising solutions that are experiencing rapid
growth and innovation.
Customer Premise Equipment, either owned or leased, provides the adaptation between the operator’s
network and the customer’s network or equipment. It can be a simple phone, but we see a progressive
migration toward intelligent devices supporting both voice and data services.
12
533576827
02.10.09
04.03.11
Service Layer
This layer consists of the equipment that provides available services and applications to the network.
Services will be available to the whole network, regardless of the user’s location. These services will be
made as independent as possible from whatever access technology is used. The distributed nature of the
NGN will make it possible to consolidate much of the equipment that delivers services in centrally
located centers where greater efficiencies can be accomplished. In addition, it also makes it possible to
distribute the services to the end users equipment rather than to the network. The types of service that
will be offered include all of the existing voice services and a range of data and other new multimedia
services.
Management Layer
Key to minimizing the operation costs of running an NGN, the management layer provides the network,
service and business management functions. It allows end-to-end service provisioning, monitoring,
recovery and performance analysis required to run the network.
1.2 NGN Service Converged Architecture
While voice/data convergence has enabled new efficiencies, service convergence will enable service
providers to deliver innovative new services to any device over any type of access network. Subscribers
will define themselves by their network profile and presence rather than by their access line or their
handset. At the heart of the converged network there will be a new services infrastructure known as the IP
Multimedia Subsystem (IMS). IMS is a product of extensive work done by 3GPP and 3GPP2 to describe
core network aspects for mobility standards and is now being used as a basis for converged networks in
the NGN standards development of the ITU-T. Next Generation Networks will need to support a wide
variety of access technologies and core services, and IMS is designed to satisfy this requirement. As
shown in Figure 2, the IP Multimedia Subsystem is one of several possible subsystems envisioned in the
evolution of an NGN architecture [13].
13
533576827
02.10.09
04.03.11
Figure 2 - NGN Subsystem Architecture, showing IMS
IMS enables network operators to offer multimedia services based on and built upon Internet applications,
services and protocols. Examples of IP multimedia applications include speech communication, real time
multimedia applications, and virtual meeting/conferencing applications. IMS enables IP multimedia
sessions that support IP multimedia applications. Application of IMS to converged networks necessitates
access independence and interoperability. In order to achieve access independence and ensure network
interoperability, IMS is based on the widely accepted Internet standards of the Internet Engineering Task
Force (IETF), Session Initiation Protocol (SIP) being one such example. IMS is intended to serve as the
core network support for the development and delivery of services. IMS enables the convergence of, and
access to, voice, video, messaging, data and web-based technologies for the end user.
Standards Definition Challenges
Standards Development Organizations (SDOs) face a number of challenges when specifying Next
Generation Networks standards. Some of these are:
 smooth/seamless inter-working between the IP-based network and the PSTN;
 levels of service performance as currently offered by the legacy telephony infrastructure (e.g., call
setup delays);
 interoperability across multiple administrative domains taking into account different signaling
protocols;
 scalability to support very large number of customers;
 simplicity; and
 the ability to support new services.
14
533576827
02.10.09
04.03.11
It should be kept in mind that many of the standards used for NGN interfaces and applications are
evolving/changing rapidly.
1.3 NGN Release 1 Architecture
NGN Release 1 is structured in a two-layer model: Transport Layer (or Transport Stractum) and Service
Layer (or Service Stractum). Transport layer is responsible to deal directly with end-user and other
networks traffics, supporting the requirements of service layer. Service Layer is responsible to
accommodate add-value services in NGN network, such as a telephone service, web service, etc.
Service Layer
Control, management and user services plan
Control and Management
Transport Layer
Control, management and user data plan
Figure 3 – NGN layered model overview
Some logical functions have been defined by ITU for transport and services layers. Figure 3 is an example
of functions in NGN Architecture.
The following sub items describe the Transport and Service Layers in accordance with the text contained
in Y.2006 [5] and Y.2012 [4] recommendations.
1.3.1
Transport Layer
Transport layer is the part of NGN architecture responsible to provide the control and transfer data user
functions, and the transport layer resources management. This layer includes two sub layers: transport
functions and transport control functions.
1.3.1.1 Transport Functions
Conform Y.2012; transport functions provide the connectivity for all components and physically
separated functions within the NGN. These functions provide support for the transfer of media
information, as well as the transfer of control and management information. Access network, edge, core
transport, gateway and media handling functions are included in this sub layer.
15
533576827
02.10.09
04.03.11
Applications
Application support functions and service support functions
Service control functions
(PSTN/ISDN emulation, IP multimedia service and service user profile functions)
Service Layer
Network Attachment
Control Functions
Resource and admission
control functions
Transport
user
profiles
Transport control functions
End-user
functions
Other
Networks
Transport functions
(Access network, edge and core transport functions)
Transport Layer
Control
Media
Figure 4 – NGN architecture overview
1.3.1.1.1
Access network functions
The access network functions are responsible to provide IP connectivity between end-users functions and
the core transport functions. These functions take care of end-users access to the network as well as
collecting and aggregating the traffic coming from these accesses towards the core network, where QoS
control mechanisms dealing directly with user traffic can be performed.
The access network includes access-technology dependent functions, e.g., for W-CDMA technology and
xDSL access. Depending on the technology used for accessing NGN services, the access network may
includes several capabilities. The following list, contained in Series Y Supplement 1[3], is the proposed
technologies that implement access transport functions in the NGN Release 1 Architecture:

Wire Technologies
16
533576827
02.10.09
04.03.11
o
o
o
o
o
o

xDSL: The NGN Release 1 includes ADSL (Recs. G.992.1, G.992.3 and G.992.5);
SHDSL (Rec. G.991.2); and VDSL (Recs. G.993.1 and G.993.2).
SDH.
Optical Access: this covers point to point (IEEE 802.3ah 100Base-LX/BX) and xPON
transport systems.
Cable networks based on PacketCable multimedia specifications as another type of
access transport function.
LANs, including 10Base-T, Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet.
PLC network.
Wireless Technologies
o IEEE 802.X wireless networks.
o 3GPP or 3GPP2 IP-CAN.
o Broadcast networks, for example, 3GPP/3GPP2 Internet broadcast/multicast.
1.3.1.1.2
Edge functions
The edge functions are used for media and traffic processing when aggregated traffic coming from
different access networks is merged into the core transport network; they include functions related to
support for QoS and traffic control.
The edge functions are also used between core transport networks.
1.3.1.1.3
Core transport functions
The core transport functions are responsible to provide IP connectivity across the core network, ensuring
information transport within the network. These functions provide QoS mechanisms dealing directly with
user traffic within the network, including buffer management, queuing and scheduling, packet filtering,
traffic classification, marking, policing, shaping, gate control and firewall capability.
1.3.1.1.4
Gateway functions
The gateway functions are responsible to provide internetworking with end-user functions and/or other
networks with NGN. These functions also provide internetworking with other types of NGN and many
existing networks, such as the PSTN/ISDN, the public Internet, and so forth.
Figure 5 – Example of gateway function
Gateway functions can be controlled either directly from the service control functions or through the
transport control functions.
1.3.1.2 Media handling functions
Media handling functions provide media resource processing for service provision, such as generation of
tone signals and transcoding. These functions are specific to media resource handling in the transport
stratum.
17
533576827
02.10.09
04.03.11
1.3.2
Transport control functions
Transport control functions layer is subdivided in two sub layers: transport functions and transport control
functions.
1.3.2.1 Resource and admission control functions (RACF)
Resource and admission control functions is a control layer that supports dynamic verification of resource
availability and configuration of policy enforcement functional elements in the bearer path. These
functions act as the arbitrator between service control functions and transport functions for QoS related
transport resource control within access and core networks. RACF is responsible to perform the policy
based transport resource control upon the request of the service control function, determines the transport
resource availability and admission, and applies controls to the transport functions to enforce the policy
decision, including resource reservation, admission control and gateway control, NAPT and firewall
control, and NAPT traversal. The RACF interacts with transport functions for the purpose of controlling
one or more of the following functions in the transport layer: bandwidth reservation and allocation, packet
filtering; traffic classification, marking, policing, and priority handling; network address and port
translation and firewall.
The RACF takes into account the capabilities of transport networks and associated transport subscription
information for subscribers in support of the transport resource control. Transport subscription
information is the responsibility of the network attachment control functions (NACFs). The RACF and
NACF interact to exchange relevant transport subscription information.
1.3.2.2 Network attachment control functions (NACFs)
The network attachment control functions (NACFs) provide registration at the access level and
initialization of end-user functions for accessing NGN services. These functions provide transport stratum
level identification/authentication, manage the IP address space of the access network, and authenticate
access sessions. They also announce the contact point of NGN functions in the service stratum to the end
user.
The Y.2012 Recommendation establishes the following NACF functionalities:
• Dynamic provisioning of IP addresses and other user equipment configuration parameters.
• By endorsement of user, auto-discovery of user equipment capabilities and other parameters.
• Authentication of end user and network at the IP layer (and possibly other layers). Regarding the
authentication, mutual authentication between end user and the network attachment is performed.
• Authorization of network access, based on user profiles.
• Access network configuration, based on user profiles.
• Location management at the IP layer.
The NACF includes transport user profile that takes the form of a functional database representing the
combination of a user’s information and other control data into a single "user profile" function in the
transport stratum.
18
533576827
02.10.09
04.03.11
1.3.3
Service Layer functions
The service layer provides value-added services and operation support functions. The components of the
service layer are:
• Service control functions including service user profile functions; and
• Application support functions and service support functions.
1.3.3.1 Service control functions
The service control functions include resource control, registration, and authentication and authorization
functions at the service level for both mediated and non-mediated services. They can also include
functions for controlling media resources, i.e., specialized resources and gateways at the service-signaling
level.
The service control functions accommodate service user profiles that represent the combination of user
information and other control data into a single user profile function in the service stratum, in the form of
functional databases.
1.3.3.2 Application support functions and service support functions
This sub layer includes functions such as the gateway, registration, authentication and authorization
functions at the application level. These functions are available to the "applications" and "end-user"
functional groups. The application support functions and service support functions work in conjunction
with the service control functions to provide end-users and applications with the NGN services they
request.
1.3.4
End-user functions
End-users functions include diverse types of interfaces and equipments that users can use to access the
NGN network. Y.2012 Recommendation does not made assumptions about the diverse end-user
interfaces and end-user networks that may be connected to the NGN access network.
Bibliography
[1] ITU-T Y.2001 (12/2004) – Next Generation Networks - Frameworks and functional architecture
models, available in http://www.itu.int.
[2] ITU-T Y.2011 (10/2004) - General principles and general reference model for Next Generation
Networks, available in http://www.itu.int.
[3] ITU-T Series Y, Supplement 1 (07/2006) – NGN release 1 scope, available in http://www.itu.int.
[4] ITU-T Y.2012 (09/2006) – Functional requirements and architecture of the NGN release 1, available
in http://www.itu.int.
[5] ITU-T Y.2006 (02/2008) – Description of capability set 1 of NGN release 1, available in
http://www.itu.int.
[6] Rosenber, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. e
Schooler, E.: SIP: Session Initiation Protocol – RFC 3261, Internet Engineering Task Force, June 2002.
19
533576827
02.10.09
04.03.11
[Ref: P1!T-1796_i.doc; 2009-09]
2
NGN SERVICE CAPABILITIES
2.1 ITU-T NGN Service Architecture
The ITU-T NGN service architecture supports the Application Network Interface:
Provides an abstraction of network capabilities (i.e., the interface is network agnostic).
Provides access to such functions as authentication, authorization, and security to ensure that
third-party service providers can make use of network capabilities.
Applications
ANI
SNI
Application Support Functions
and Service Support Functions
IdM
Functions
Service Control and Content Delivery Functions
Management Functions
Service User
Profiles
Service
Control Functions
Functions
from other
Service
Providers
Content Delivery Functions
Service Stratum
Network Attachment
and Control Functions
Transport User
Profiles
Mobility
Management
and Control
Functions
Resource
and
Admission
control
Functions
Functions
from
Other
Networks
Transport Control Functions
End-User
Functions
Transport Functions
UNI
NNI
Transport Stratum
Control
Management
Media
IdM
Figure 6 - NGN Architecture Overview
[Source: ITU-T Rec Y.2012]
•
•
•
Rec. Y.2201 (NGN Requirements and capabilities for ITU-T NGN) supports Service
Creation Environments as defined by Parlay/Parlay X, OMA, IMS, and IN
Rec. Y.2234 (Open service environment capabilities for NGN) defines the interface between
the network resources and 3rd party applications. The OMA Service Environment (OSE),
Parlay/OSA APIs, Parlay X Web Service APIs, OASIS, OMG, and W3C and are referenced
as resources for developing Rec Y.2234.
Rec. Y.2232 (NGN convergence model and scenario using web services) defines a Web
Services deployment model and Web Services based convergence service scenarios for NGN
The NGN service architecture supports the Application Network Interface:
20
533576827
02.10.09
04.03.11
-
Web Services is one of the appropriate solutions for service access.
Use of Web Services is expanding rapidly as the need for application-to-application
communication and interoperability grows.
In order for an application to take advantage of web services, three behaviours must take place: the
publication of service descriptions, the finding and retrieval of service descriptions, and the binding or
invoking of services based on the service description. These behaviours can occur singly or iteratively,
with any cardinality between the roles. In detail, these operations are:
OI
execution (binding or invoking) of services based on the service description
OF
finding and retrieval of service descriptions
OP
publication of service descriptions
[Ref: P1!T-2021_i.doc; 2010-10]
21
533576827
02.10.09
04.03.11
Figure 7 - Conceptual NGN Web Services Architecture
[Source: ITU-T Rec Y.2232]
2.2 Open Programmability Environment Standards
The open programmability environment (OPE) provides application programming interfaces (APIs) and
integration tools necessary to create and deliver new application services. The OPE must be based on
open standards so that it can be extended and adapted easily as required.
RMI
The Remote Method Invocation (RMI) is a Java protocol that allows methods on an object that exists in
another address space to be invoked remotely. RMI is used between the MGC and the application servers.
XML
The extended Markup Language is a subset of the Standard Generalized Markup Language (SGML)
defined in ISO 8879. XML is used between components of the OPE as well as user/programmer servers
and the OPE.
APIs
Application Programming Interfaces (APIs) are open interfaces for distributed system execution through
the system. Two consortia have been developing specifications for APIs:
JAIN (Java API for Integrated Networks)
JAIN has created a set of integrated network APIs for the Java platform that provides a framework to
build and integrate services that span across packets (e.g., IP or ATM), wireless and PSTN networks. The
Java adaptors allow the OPE to inter-work with a wide variety of communication technologies such as email systems, voice mail systems, fax servers, video servers, and web servers.
2.2.1
Parlay
The Parlay group was formed in April 1998 with the mandate of producing an API to enable access to and
control of a wide range of network capabilities from a common framework that need not to be part of the
network. The Parlay group is not a standards group itself, but it sees itself as a facilitator of needed
interfaces. The Parlay APIs are said to complement and encourage the use of the Advanced Intelligent
Networks (AIN) protocols.
2.2.1.1
Parlay Specifications
Parlay Version 5.1 Specifications
(The Parlay v5.1 Specifications were jointly published by Parlay & ETSI in 2006)
Part 1
Part 2
Part 3
Part 4.1
Part 4.2
Part 4.3
Part 4.4
Part 4.5
Part 5
Overview
Common Data Definition
Framework
Call Control – Common Call Control
Definitions
Multi-Party Call Control SCF
Multi-Media Call Control SCF
Conference Call Control SCF
User Interaction SCF
ES 203 915-1
ES 203 915-2
ES 203 915-3
ES 203 915-4-1
ES 203 915-4-2
ES 203 915-4-3
ES 203 915-4-4
ES 203 915-4-5
ES 203 915-7
22
533576827
02.10.09
04.03.11
Part 6
Part 7
Part 8
Part 9
Part 10
Part 11
Part 12
Part 13
Part 14
Part 15
Mobility SCF
Terminal Capabilities SCF
Data Session Control SCF
Generic Messaging SCF
Connectvity Manager SCF
Account Manager SCF
Charging SCF
Presence and Availability Management SCF
Policy Management SCF
Multi-Media Messaging SCF
ES 203 915-6
ES 203 915-7
ES 203 915-8
ES 203 915-9
ES 203 915-10
ES 203 915-11
ES 203 915-12
ES 203 915-13
ES 203 915-14
ES 203 915-15
23
533576827
02.10.09
04.03.11
Parlay X Version 3.0 API Specifications
(ETSI ES 202-504 series)
2.2.2
•
Third Party Call
•
Address List Management
•
Call Notification
•
Presence
•
Short Messaging
•
Message Broadcast
•
Multimedia Messaging
•
Geocoding
•
Payment
•
Application-driven QoS
•
Account Management
•
•
Terminal Status
Device Capabilities and
Configuration
•
Terminal Location
•
Multimedia Streaming Control
•
Call Handling
•
•
Audio Call
Multimedia Multicast Session
Management
•
Multimedia conference
Open Mobile Alliance (OMA) Service Environment
[Source: OMA-TP -2007-0499]
OMA Service Environment (OSE)
• OSE describes the logical interactions to, from and among OMA enablers and a logical
architecture for OMA enabler implementations
• It is a conceptual environment that provides interfaces to applications, interfaces to Service
Providers' Execution Environment, and the interfaces to invoke and use underlying network
capabilities and resources for enabler implementations
OMA Service Enablers:
Access to Content
Personal Communications
•
Mobile Broadcast (BCAST)
•
Push-to-talk over Cellular (PoC)
•
Dynamic
(DCD)
•
Multimedia Messaging Svc (MMS)
•
Converged IP Messaging (CPM)
•
Digital Rights Mgmt (DRM)
•
Mobile Email (MEM)
•
Mobile Advertising (MobAd)
•
Converged Address Book (CAB)
•
Data Synchronization
•
•
Smart Card Web Server (SCWS)
Instant Messaging Presence Svc
(IMPS)
•
Rich Media Environment
•
Browser
•
Multimodal Multi-device
Content
Delivery
24
533576827
02.10.09
04.03.11
•
Game Services
Common
Devices
•
Location
•
Device Management
•
Presence
•
Device Profiles Evolution
•
Policy, Evaluation, Enforcement,
Mgmt (PEEM)
•
Look and Feel Customization
•
Security
•
Charging
•
SIP Push
•
Categorization Based Content
Screening (CBCS)
•
Global Permissions Mgmt
(GPM)
•
General Service Subscription
Mgmt (GSSM)
XML Doc. Mgmt (XDM)
•
[Ref: P1!T-1278_i.doc; 2008-03]
2.3 IPTV
2.3.1 ATIS IPTV Interoperability Forum (IIF)
The ATIS IIF standards development has been defined in three phases:
• Phase 1: Implementation of a standard TV service experience over IP networks.
Phase 1 is complete
• Specifications focus on basic attachment and access to “Linear” Broadcast IPTV over an
NGN network, whether IMS or Non-IMS
– Network Attachment
– Service Provider Discovery and Attachment
– Service Discovery and Attachment
– Device Management
– Authentication
– Definition of all protocols used
• Open Security Framework
– Supports differentiated security solutions
– Enables open-market devices
• IPTV Ordering Framework
• QoS Framework
•
Phase 2:
– Distributed Content On Demand (CoD) architecture and data access
– Internet-sourced content
– Pay-Per-View
– Push Content Delivery (background delivery to consumer's client)
– Interactive Program Guide (Client/Server guide query)
25
533576827
02.10.09
04.03.11
–
–
–
–
–
–
•
Phase 3: Interactive TV services, including consumer originated video.
–
–
–
–
–
–
–
–
–
•

Fast channel change (aligning with DVB)
Targeted ad insertion
Open security framework
QoE validation standard
Stereoscopic 3D video
Also considering impacts to existing work due to IPV6
Linear broadcast with trick mode
Interactive TV
Consumer-originated video
Games
Pictures
Directory and direct mail advertising
Advertising message logging
Other advertising services
Other 3rd party content services
Task Forces
– Architecture
– IPTV Security Solutions
– Quality of Service Metrics
– Metadata and Transaction Delivery
– Testing and Interoperability
Completed Standards
– ATIS-0800001, IPTV DRM Interoperability Requirements
– ATIS-0800002, IPTV Architecture Requirements
– ATIS-0800003, IPTV Architecture Roadmap
– ATIS-0800004, A Framework for QoS Metrics and Measurements Supporting IPTV
Services
– ATIS-0800005, IPTV Packet Loss Issue Report
– ATIS-0800006, IIF Default Scrambling Algorithm
– ATIS-0800007, IPTV High Level Architecture
– ATIS-0800008, QoS Metrics for Linear Broadcast IPTV
– ATIS-080009, Remote Management of Devices in the Consumer Domain for IPTV
Services
– ATIS-0800010, Emergency Alert Provisioning Specification
– ATIS-0800011, QoS Metrics for Public Services
– ATIS-0800012, IPTV Emergency Alert System Metadata Specification
– ATIS-0800013, Media Formats and Protocols for IPTV Services
– ATIS-0800014, Secure Download and Messaging Interoperability Specification
– ATIS-0800015, Certificate Trust Management Hierarchy Interoperability Specification
– ATIS-0800016, Standard PKI Certificate Format Interoperability Specification
– ATIS-0800017, Network Attachment and Initialization of Devices and Client Discovery
of IPTV Services
– ATIS-0800018, IPTV Linear TV Service
– ATIS-0800019, Multicast Network Service Specification
– ATIS-0800020, IPTV Electronic Program Guide Metadata Specification
– ATIS-0800021, EPSNR Trial-Use Standard
26
533576827
02.10.09
04.03.11
–
–
–
–
–
–
–
–
–
–
–
–
–
–
ATIS-0800022, IPTV Consumer Domain Device Configuration Metadata
ATIS-0800024, Security Robustness Rules Interoperability Specification
ATIS-0800025, Test Plan for Evaluation of Quality Models for IPTV Services
ATIS-0800027, IPTV Glossary
ATIS-0800028, Fault Codes for IPTV
ATIS-0800029, IPTV Terminal Metadata Specification
ATIS-0800030, Technical Report on IPTV Advertising
ATIS-0800032, Metadata for IPTV Fault Codes
ATIS-0800033 [trial-use], A-POD: An IPTV Separable Security Interface Specification
ATIS-0800035, Technical Report on a Validation Process for IPTV Perceptual Quality
Measurements
ATIS-0800036, XML Schema for ITF Execution Environment
ATIS-0800039, DRM Server-Side Application Programming Interfaces
ATIS-0800040, IPTV MPEG Transport Stream Monitoring
ATIS-0800041, Implementer's Guide to QoS Metrics
[Ref: P1!T-986_i.doc; 2007-03]
[Ref: P1!T-1621_i.doc; 2009-04]
[Ref: P1!T-2045_i.doc; 2010-11]
*****
2.3.2
ITU-T Standardization
2.3.2.1 IPTV FG Working Groups
The IPTV Focus Group (FG IPTV) was established in 2006. The mission of IPTV Focus Group was to
coordinate and promote the development of global IPTV standards taking into account the existing work
of the ITU-T study groups as well as standards development organizations (SDOs), Fora and Consortia.
The FG IPTV was comprised of six working groups covering all aspects related to IPTV. The first
meeting of the focus group was held from 10 to 14 July 2006 in Geneva and its seventh and the last
meeting was held in Malta in December 2007.
The following provides summary of activities and achievements of the six FG IPTV working groups.
Working group 1: Architecture and Requirements
WG1 activities concentrated on defining and describing IPTV services requirements, IPTV framework
architecture (NGN and non-NGN) and IPTV service scenarios. WG1 specification was driven by a
systemic IPTV service-wise approach, based upon practical experience and global expertise. It prepared
three documents as follows:
IPTV services requirements: The IPTV services requirements document provides a list of requirements
that have been elaborated according to an IPTV service-wise, global and systemic approach. These
requirements have been organized according to a functional taxonomy (e.g. QoS requirements, security
requirements, middleware requirements, etc.), and further classified into required, recommended and
optional requirements.
27
533576827
02.10.09
04.03.11
IPTV architecture: This document describes the IPTV functional architecture intended to support IPTV
services based on the IPTV service requirements and definitions. Starting from a basic description of
IPTV players, roles and services, a high level IPTV functional model is outlined. This model is then
developed into a set of functional architectures which support NGN and non-NGN transport networks, as
well as operation modes with or without IMS.
IPTV service scenarios: The IPTV service scenarios document provides a list of IPTV use cases that are
meant to illustrate how IPTV services can be designed, deployed and operated. From this perspective, use
cases have been classified according to an IPTV service taxonomy that includes (but is not limited to) ondemand services, advertising services and broadcast services
28
533576827
02.10.09
04.03.11
Working group 2: QoS and Performance Aspects
WG2 championed and promoted the development of global QoS and performance standards necessary to
ensure high end-user satisfaction, and hence high end-user acceptance, for IPTV services. WG2 produced
the four following documents:
Quality of experience requirements for IPTV services: This document defines user requirements for
quality of experience for IPTV services. The QoE requirements are defined from an end user perspective
and are agnostic to network deployment architectures and transport protocols. The QoE requirements are
specified as end-to-end and information is provided on how they influence network transport and
application layer behaviour. QoE requirements for video, audio, text, graphics, control functions and
meta-data are provided.
Traffic management mechanisms for the support of IPTV services: This document describes a set of
traffic management mechanisms which are aimed to facilitate the efficient support of IPTV services over
the network infrastructure. Traffic management mechanisms for the home, access, and core networks are
discussed. The network supporting IPTV services will span a number of network domains which may be
designed, deployed and operated by different providers and which may differ in their traffic management
capabilities. Therefore, it is expected that the network provider(s) will implement a subset of these
mechanisms to ensure IPTV service objectives are satisfied efficiently. Furthermore the traffic
management mechanisms also depend on the specific network architectures used for IPTV services as
defined in the IPTV architecture specification. The document further provides mappings of IPTV service
components to the IP network QoS classes defined in ITU-T Y.1541.
Application layer error recovery mechanisms for IPTV services: This document describes specific
mechanisms and the applicability of these mechanisms to IPTV services and network conditions, and
provides recommendations and guidance on their use. It has been determined that with the use of these
mechanisms, consumer television quality can be achieved using the standard Y.1541 QoS classes 0 and 1.
Performance monitoring for IPTV: This document defines monitoring points, monitoring parameters
and monitoring methods for IPTV services. It covers both network and service related performance
monitoring parameters from the physical up to the application layers.
Working group 3: Service Security and Content Protection
WG3 focused on addressing the urgent needs for globally acceptable IPTV security standards as the
market demands. It identified security requirements, defined the security architecture and described
security mechanisms to satisfy the business & security requirements for the IPTV system architecture.
WG3 produced the following document.
IPTV security aspects: This document addresses threats, requirements, architecture, and mechanisms that
pertain to security and protection aspects of IPTV content, services, networks, terminal devices, and
subscriber (end-users).
Working group 4: IPTV Network Control
WG4 focused on specifying detailed functional requirements of network control and multicast capability.
It described various aspects of IPTV network control. It also described functional requirements and
29
533576827
02.10.09
04.03.11
frameworks for supporting multicast capabilities in terms of IPTV network control. Finally identified
protocols relevant to IPTV services and categorized these protocols relative to their specific functions in
relation to IPTV services. WG4 received 178 contributions and produced three documents. WG4
produced the following three documents.
IPTV network control aspects: This document describes various aspects of IPTV network control. It
provides a list of detailed requirements to address control and signalling matters related to authentication
and authorization, content delivery, consumer domain attachment and initialization, quality of service
(QoS), quality of experience (QoE) and security.
IPTV multicast frameworks: This document on IPTV multicast frameworks describes functional
requirements and frameworks for supporting multicast capabilities in terms of IPTV network control.
IPTV related protocols: This document identifies protocols relevant to IPTV services and categorizes
these protocols relative to their specific functions in relation to IPTV services.
Working group 5: End Systems and Interoperability Aspects
WG5 scope included IPTV terminal devices and the home network which would support IPTV services.
It provided terminal device and home network architectures, and identified interfaces and
service/functional requirements in harmonization with other ITU-T study groups and other SDOs. The
home network activities were based most significantly on the HGI work. WG5 progressed particularly in
the area of defining and describing the basic framework and architecture for a home network, as well as
defining and describing the many interfaces between different devices within a home network. WG5
produced the following two documents.
Aspects of IPTV end system – Terminal device: This document outlines functional requirements of the
terminal device, capabilities expected to be supported by the terminal device, and the terminal device
architecture.
Aspects of home network supporting IPTV services: This document addresses the home network
architecture aspects in the context of IPTV.
Working group 6: Middleware, Application and Content Platforms
WG6 identified and defined middleware platforms, including applications, content formats, and their uses
to facilitate effective and interoperable use of an IPTV system for presenting and interacting with IPTV
services. It studied aspects of services which were relevant to discovery, navigation, selection,
acquisition, delivery and presentation including interaction, of content. WG6 produced the following five
documents.
IPTV middleware, applications and content platforms: This document identifies and defines middleware
platforms, including applications, content formats, and their uses, that facilitate effective and
interoperable use of an IPTV system for presenting and interacting with IPTV services. This document is
a general document for IPTV middleware, application and content platforms. It describes content
provisioning, service discovery, channel and content identification and location resolution, and profiling.
This document refers to text on middleware, content coding, metadata, which can be found in other
documents.
30
533576827
02.10.09
04.03.11
Toolbox for content coding: This document addresses the use of video and audio coding in services
delivered over Internet Protocols (IP). It describes the use of H.264/AVC video, VC 1 video, AVS video,
HE AAC v2 audio, HE AAC v2 audio, Extended AMR WB (AMR WB+) audio, and AC-3 and Enhanced
AC-3 audio. In addition, this document describes the use of speech codecs within an IPTV environment
and the specified codecs for this use. This document adopts a "toolbox" approach for the general case of
IPTV applications delivered directly over IP and MPEG2 -TS. This document is not a specification for
the use of Audio and Video Codec’s for use in IPTV Services.
IPTV middleware: This document identifies those aspects of architecture specific to IPTV middleware
and describes the various functions with explanatory definitions where appropriate.
IPTV metadata: This document gives the overview of the metadata for IPTV services and describes its
elements and delivery protocols, identifying relevant standards. The IPTV metadata, the information on
services and contents processed by the service and content delivery infrastructure, provides descriptive
and structural framework for managing IPTV services. Aspects of transport, representation, content
provisioning, and security of metadata are covered.
Standards for IPTV multimedia application platforms: This document identifies and analyzes the
relevant standards for IPTV multimedia application platforms.
FG IPTV documents are available to the public at: http://www.itu.int/ITU-T/IPTV/
2.3.2.2 IPTV Global Standards Initiative (IPTV-GSI)
In accordance with decisions taken at the April 2007 meeting of Study Group 13 the work of the FG
IPTV ended in December 2007 and its deliverables were transferred to the appropriate study groups via
Study Group 13 for further consideration and, when appropriate to develop draft Recommendations based
on the focus group deliverables.
Based on proposals developed by the chairman of Study Group 13 and the chairman of the FG IPTV (and
with the support of all study group chairmen and endorsement by TSAG) the ongoing work will be
carried out under the umbrella of a Global Standards Initiative (the IPTV-GSI). This means that the
ongoing work on the FG IPTV deliverables will be done by the ITU-T study groups (based on allocation
developed by a coordination group, the Joint coordination Activity on IPTV (JCA-IPTV)) with
coordinated planning and through co-located meetings of the involved study groups and/or rapporteur
groups
The first IPTV-GSI event took place in Seoul, Korea, from 15-22 January 2008. Several of FG IPTV
documents became draft Recommendation in this meeting paving the way for speedy progress.
[Ref: P1!T-1227_i.doc; 2008-03]
2.4 Emergency Telecommunications Services
The purpose of emergency telecommunications services is to facilitate communications during emergency
situations as well as to provide emergency response and recovery operations for restoring the community
infrastructure and for returning the population to normal living conditions after serious disasters and
emergency events. As emergency telecommunications covers all communications services, including
voice and non-voice, data, location, etc., a number of challenges and considerations need to be addressed
31
533576827
02.10.09
04.03.11
in defining and establishing the functional capabilities for emergency telecommunications services in
NGN. Many different standards development activities will be involved in the establishment of a global
emergency telecommunications capability.
2.4.1
Emergency Telecommunications Services Types
In a telecommunication network there are four distinct types of generally agreed emergency
communications services which represent the possible combinations of two entities; citizens and
authorities. It is worth noticing that in this context, the use of the term citizen encompasses actual citizens,
people that may not have status of citizen of a given state, and private organizations.
2.4.2
Standardization Activity on Emergency Telecommunications Services
The establishment of a comprehensive family of industry standards for effective emergency
telecommunications services in Next Generation Networks (NGN) is an effort that addresses many issues
in many industry activities. Over the past few years, considerable progress has been made in pursuing the
task of establishing a family of standards for emergency telecommunications services. These activities
have been undertaken at the international, regional and national levels within Standards Development
Organizations (SDO) and other relevant organizations to establish internationally agreed means to operate
systems for public protection and disaster relief on a harmonized and coordinated basis. What follows is a
summary of important standards and relevant activity within the telecommunications sector. It is not
meant to be a comprehensive list, as this is an evolving and dynamic area of activity.
2.4.2.1 ITU Activities
The International Telecommunication Union (ITU) consists of three sectors: ITU-T, ITU-R and ITU-D.
Each sector works on emergency telecommunications services (ETS) and/or telecommunications for
disaster relief (TDR) activities [1], but ITU-T is mainly in charge of these activities. A number of Study
Groups are involved with aspects relating to ETS. Such aspects would involve functional requirements,
telephony call control, backbone signalling, QoS, architecture/framework, customer service management,
emergency services and preference capabilities, multimedia services, security, etc. The following are
some of the ITU-T materials addressing emergency telecommunications:

ITU-T Rec. E.106, “International Emergency Preference Scheme for Disaster Relief Operations
(IEPS)”. IEPS is needed when there is a crisis situation causing an increased demand for
telecommunications when use of the International Telephone Service may be restricted due to
damage, reduced capacity, congestion or faults. In crisis situations there is a requirement for IEPS
users of public telecommunications to have preferential treatment.

ITU-T Rec. E.107, “Emergency Telecommunications Service (ETS) and interconnection framework
for national implementations of ETS”. E.107 provides guidance that will enable telecommunications
between one ETS National Implementation and another one, in addition to providing description of
ETS.

ITU-T Rec. H.246 Amendment 1, “Mapping of user priority level and country/international network
of call origination between H.225 and ISUP".

ITU-T Rec. H.248.44, “Gateway control protocol: Multi-Level Precedence and Pre-emption
Package".

ITU-T Rec. H.460.4, "Call priority designation and country/international network of call origination
identification for H.323 priority calls"
32
533576827
02.10.09
04.03.11

ITU-T Rec. H.460.14, "Support for Multi-Level Precedence and Preemption (MLPP) within H.323
Systems"

ITU-T Rec. H.460.21, "Message Broadcast for H.323 Systems"

ITU-T Rec. J.260, "Requirements for Emergency/Disaster Communications over IPCablecom
Networks"

ITU-T Rec. M.3350, "TMN service management requirements for information interchange across the
TMN X-interface to support provisioning of Emergency Telecommunication Service (ETS)"

Signalling for IEPS support in ISUP: Q.761 Amd.3, Q.762 Amd.3, Q.763 Amd.4, and Q.764 Amd.4

Signalling for IEPS support in BICC: Q1902.1 Amd.2, Q.1902.2 Amd.3, Q.1902.3 Amd.3, and
Q.1902.4 Amd.3

Signalling for IEPS support in CBC: Q.1950 Amd.1 Annex G

Signalling for IEPS support in ATM AAL2: Q.2630.3 Amd.1

Signalling for IEPS support in DSS2: Q.2391 Amd.5

ITU-T Rec. Y.1271, "Framework(s) on network requirements and capabilities to support emergency
communications over evolving circuit-switched and packed-switched networks"

ITU-T Rec. Y.2205, “Next Generation Networks – Emergency telecommunications – Technical
considerations”.

In addition to these Recommendations, there are two non-normative publications:

Supplement 47 to ITU-T Q-Series Recommendations, "Emergency services for IMT-2000 networks
– Requirements for harmonization and convergence"

Supplement 53 to ITU-T Q-Series Recommendations, "Signalling requirements to support the
International Emergency Preferential Scheme (IEPS)".

Supplement 57 to ITU-T Q-Series Recommendations, " Signalling requirements to support the
emergency telecommunications service (ETS) in IP networks”.
2.4.2.2 IETF Activities
The Internet Engineering Task Force (IETF) has developed a number of Internet Drafts (I-Ds) and
published several informational RFCs on emergency services. The Emergency Content Resolution with
Internet Technology (ecrit) working group is currently active in developing requirements for Internet
emergency calling services that require both association of the physical location of the originator with an
appropriate emergency service center. Some of the RFCs that deal with aspects of ETS are:

RFC 3523: “Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology”, April
2003.

RFC 3689: “General Requirements for Emergency Telecommunication Service (ETS)”. February
2004.

RFC 3690: “IP Telephony Requirements for Emergency Telecommunications Service (ETS)”,
Feruary, 2004
33
533576827
02.10.09
04.03.11

RFC 4190: “Framework for Supporting Emergency Telecommunications Service (ETS) in IP
Telephony”, November 2005.

RFC 4375:
“Emergency Telecommunications Services (ETS) Requirements for a Single
Administrative Domain”, Jan 2006.

RFC 4542: “Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services
in the Internet Protocol Suite”, May 2006.

RFC 4958: “A Framework for Supporting Emergency Telecommunications Services (ETS) within a
Single Administrative Domain”, July 2007.
2.4.2.3 ETSI Activities
The Special Group on Emergency Communications (EMTEL) of the European Telecommunications
Standards Institute (ETSI) acts as coordinator in getting requirements on emergency communications,
outside ETSI (i.e., from different stakeholders) and inside ETSI (i.e., ETSI bodies). This group has
published a number of documents on different aspects of emergency telecommunications. The following
is a short list of some of these documents:

TS 102 181: “Requirements for Communications between Authorities/Organizations during
Emergencies”, Dec. 2005.

TS 102 182: “Requirements for Communications from Authorities/Organizations to Individuals,
Groups or the General Public During Emergencies”, Dec. 2006

TR 102 180: “Basis of Requirements for Communication of Individuals with Authorities/
Organizations in Case of Distress (Emergency call handling)”, Feb 2007.

TR 102 299: “Collection of European Regualtory Texts and Orientations”, April 2008.

TR 102 410: “Basis of Requirements for Communication between Individuals and between
Individuals and Authorities whilst Emergencies are in Progress”, Aug 2007.

TR 102 444: “Analysis of the Short Message Service (SMS) and Cell Broadcast Service (CBS) for
Emergency Messaging Applications”, Mar 2006.

TR 102 445: “Overview of Emergency Communications Network Resilience and Preparedness”,
Nov. 2006.

TR 102 476: “Emergency Calls and VoIP Possible Short and Long Term Solutions and
Standarddization Activities”, July 2008.
2.4.2.4 ATIS Activities
The main groups of the Alliance for Telecommunications Industry Solutions (ATIS) that are involved in
emergency telecommunications activities are: the Emergency Services Interconnection Forum (ESIF), the
Wireless Technologies and Systems Committee (WTSC), the Network Performance, Reliability, and
Quality of Service Committee (PRQC) and the Packet Technologies and Systems Committee (PTSC).
ATIS has published a number of documents on different aspects of emergency telecommunications.
Some of these documents are:

ATIS-01000011.2006; “ETS Packet Priority for IP NNI Interfaces – Use of Existing DiffServ Per
Hop Behaviours”,

ATIS-01000010.2006; “Support for ETS in IP Networks”,

ATIS-0100006.2006; “Service Restoration Priority Levels for IP Networks”,
34
533576827
02.10.09
04.03.11

ATIS-0100004.2006; “Availability and Restorability Aspects of ETS”,

ATIS-0100009.2003; “Overview of Standards in Support of ETS”,

ATIS-0500008.2006; “Emergency Services Network Interfaces (ESNI) Framework”,

ATIS-0100003.2006; “User Plane Priority Levels in IP Networks and Services”.
2.4.2.5 Other Fora Activities
At the present time, there are many other SDOs working on different aspects of emergency
telecommunications services or telecommunications for disaster relief/early warning. The efforts of these
organizations and agencies can be divided into international (e.g., Global Standards Collaboration, United
Nation’s Work Group on Emergency Telecommunications), regional (e.g., Asia-Pacific Telecommunity
Standardization Program), and national. In the case of national efforts it is worth mentioning the
following organizations that are active in ETS: Telecommunications Industry Association and the
National Communications System in the USA; ICT Standards Advisory Council of Canada; and the
Telecommunications Technology Committee in Japan.
[Ref: P1!T-1106_i.doc; 2007-09]
2.5 Service Oriented Networks
2.5.1 ATIS SON Forum
ATIS found major disparities in the coverage of standards across the broad landscape of SON. Where
standards are in place, they are often inconsistent, incomplete, or non-interoperable especially across the
Telco, IT, and web domains. A list of work items was identified and it was determined that several of the
work items identified were beyond the scope of activities of existing industry groups. The SON Forum
was launched to facilitate dialogue between the IT space and the Telecom space and create standards
regarding next-generation services. These services include the ability to manage back-end systems to
support services and applications from across domains, develop and bring services to market efficiently,
and to reuse essential sources of information. The SON Forum develops new standards and integrates
existing standards that promote Web 2.0, IMS, and SOA interworking
2.5.2
Objectives
The SON Forum will provide industry leadership toward the vision of an open and flexible standards
based service development environment. The SON Forum will address the following high priority areas
of standardization:
• Service creation
• Common service enabler description including non-functional aspects
• Standardization of WS-* specifications
• Consistency of 3rd-party interfaces
• Service oriented infrastructure standardization
• Packaging of OSS/BSS components as service enablers
• Common policy reference model
In addition, the Forum will identify the way in which Telco services can be enhanced to offer new and
personalized services to the end consumer, based upon service-oriented networks and establish a
common dialogue and advance standardization efforts as needed for ATIS member companies with a
number of SDOs and developer groups including key relationships and collaboration with TMF, OASIS,
OMG, ITU-T, OMA and the Web 2.0 communities.
35
533576827
02.10.09
04.03.11
2.5.3
SON Framework
Figure 8 – SON Framework
2.5.4
SON Forum Task Forces
Three Task Forces (TFs) are established to progress the initial work. Proposed mission statements are
currently under development
2.5.4.1 Policy and Data Models TF
Proposed Issues Under Consideration for Approval:
 Assessment of User Domain Standards Gaps
 Common Data Model Requirements
 Common Name Space Requirements
 Common Reference Model, Syntax and Semantics
2.5.4.2 OSS/BSS and Virtualization TF
Proposed Issues Under Consideration for Approval:
 Packaging of OSS/BSS Components as Service Enablers
 IT Infrastructure Virtualization
2.5.4.3 Service Delivery Creation and Enablers TF
Proposed Issues Under Consideration for Approval:
 Common Product Data Catalog Repository
 Common Service Enabler Description
 Consistency of 3rd Party Interfaces
 Standardization of WS-* Specifications
36
533576827
02.10.09
04.03.11
[Ref: P1!T-1623_i.doc; 2009-05]
2.5.5
SON Standards
ATIS-0200001: Service Enabler (SE) Characterization Technical Report
– Provides a standard format for capturing the SE information
– Can be used by any/all SE providers
– The provider of a particular SE would fill out and publish the SE Characterization XML
document with the details for that SE
– Can be used to help partially automate the search process for a suitable SE
SE Characteristics
a. SE unique name
m. Capacity
b. SE short name
n. Response time
c. Keywords
o. Failure/failover/degradation behavior
d. Lifecycle information
p. Security policy
e. Chargeability
q. User profile dependencies
f. Interface unique name
r. Consuming entity dependencies
g. Interface short name
s. Intermediate systems dependencies
h. URI of the Interface
t.
i.
Description of the functionality
u. Eligibility dependencies
j.
SE performance measurements
v. SE Creator
Test environment
k. Additional SE characteristic
w. SE Provider contact info
l.
x. Terms & Conditions
Planned availability
[Ref: P1!T-2046_i.doc; 2010-11]
2.6 Cloud Computing
2.6.1 ATIS Cloud Services Forum
ATIS’ Service Oriented Networks (SON) Forum has transformed into the Cloud Services Forum (CSF) to
address Cloud Computing services. The CSFwill address ways in which service providers need to
leverage core, network and service attributes to adopt, advance and deliver Cloud Computing services.
To address the initial priority of Cloud-Based Inter-Provider Telepresence: Access Agnostic End to
end service flow, the following areas of focus were identified:

Service Architecture Document;

Cloud Services Network-Network Interconnect, to include service definitions and resource
requirements;

Control Plane Aspects;

Network Authentication, Authorization, and Accounting;

Quality of Service;

Border Security;

Network Policy;

Charging for Cloud Services, to include Service Definition and Resource Requirements;
37
533576827
02.10.09
04.03.11



Service Management;
Logging and auditing; and
Operations Support Systems.
[Ref: P1!T-2213_i.doc; 2011-03]
2.7 Home Networking
The Home Network is the “Network Environment” on the subscriber side of the access network
termination, determined by logical interface(s). It may itself be an access point for services involving
multiple SPs (i.e. cellular SPs, Mobile SPs, etc.). The Home Network can include multiple devices,
representing different transport media, performing many different functions. The Home Network utilizes
different physical media to connect devices or, in some cases, provides the necessary mechanisms to
classify and prioritize different traffic types (i.e., video, voice, data).
Figure 9
2.7.1 ATIS Home Networking (HNET) Forum
The ATIS Home Networking Forum enables the interoperability, interconnection, and implementation of
IP-based home networking systems/services by proactively examining technologies and services and
developing solutions supporting the rollout of these technologies and services when appropriate.
The ATIS HNET Forum was required to overcome a lack of industry cohesion to enable a quality
consumer experience within the home network. ATIS determined that there is no single organization
taking a holistic approach to home networking to ensure cross-technology interoperability/compatibility
38
533576827
02.10.09
04.03.11
of common functions or elements. Aspects of the issues are spread across multiple external industry
groups with each group developing standards from their technology perspective. There is no assurance
that end-to-end specifications can be deployed with reasonable effort, and be easily maintained.
Prior to the creation of the HNET Forum, ATIS:
• Investigated and discussed the issues associated with the deployment of IP-based Services in the
Home Network in order to ensure a cohesive home networking infrastructure exists
• Assessed the technical landscape of the Home Network by developing a High Level Framework
including essential Building Blocks (logical and functional) for IP Home Networking
• Performed an in-depth standards analysis of the industry that revealed 34 different Standards
Development Organizations (SDOs) and Special Interest Groups (SIGs) with study programs
relevant to the elements of a Home Network
• Analyzed how each organization’s standards development activity relates to each of the 8
functional layers of the building blocks
Figure 10
2.7.2
HNET Forum Objectives

SDO Coordination
– Track and assess relevant standardsfor Home Networking from an end-to-end perspective
– Establish relationships with industry-wide forums to enable the dynamic development of
cohesive Home Networking standards

Standards Development
39
533576827
02.10.09
04.03.11
–
–
2.7.3
Continually identify standards gaps in the industry
Develop standards only when deemed necessary to fill gaps on technology solutions in
order to provide an end-to-end home networking product in the industry
HNET Work Plan
The HNET Forum will be addressing these high priority issues in 2Q-4Q 2009:
• Coordination of all HNET standards activities
• Service Provider Remote Management
– Assessment of Industry Standards Work Pertaining to Remote Device Management
• Energy Consumption
– Different Energy Allowances
– Global Coordination of Power Level Requirements
[Ref: P1!T-1622_i.doc; 2009-05]
2.8 SMART GRID
2.8.1
U.S. Smart Grid Program (NIST)
Efforts are well underway in the U.S. to enable Smart Grid technologies., and both public and private
sector stakeholders (including ICT and power/utility companies) are participating in standardization
activities. The National Institute of Standards and Technology (NIST), under the U.S. Department of
Commerce, has created a multifaceted program to define the Smart Grid, identify standards requirements
and identify or develop standards to enable deployment and interoperability of Smart Grid devices and
systems.
2.8.1.1
•
•
•
•
•
•
•
•
Standards Priorities
Demand Response and Consumer Energy Efficiency
Wide Area Situational Awareness
Electric Storage
Electric Transportation
Advanced Metering Infrastructure
Distribution Grid Management
Cyber Security
Network Communications
2.8.2
Smart Grid Interoperability Panel (SGIP)
•
•
•
•
Public-private partnership created in Nov. 2009
Broad range of stakeholders in SGIP developing consensus about standards needed to build a
smarter grid
– Nearly 600 member organizations (with over 50 international organizations) & over 1700
participants from 22 stakeholder categories
Coordinates the development of standards by Standards Development Organizations (SDOs)
– Identifies Requirements
– Prioritizes standards development programs
– Works with over 20 SDOs including IEC, ISO, ITU, IEEE, …
Open, transparent & inclusive process
– SGIP Twiki: http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/SGIP
40
533576827
02.10.09
04.03.11
SGIP ORGANIZATION
PRIORITY ACTION PLANS (PAPs)
#
Priority Action Plan
#
Priority Action Plan
0
Meter Upgradeability Standard
9
Standard DR and DER Signals
1
Role of IP in the Smart Grid
10
Standard Energy Usage Information
2
Wireless Communication for the Smart Grid
11
Common Object
Transportation
3
Common Price Communication Model
12
IEC 61850 Objects/DNP3 Mapping
4
Common Scheduling Mechanism
13
Time Synchronization, IEC 62850 Objects/
IEEE C37.118 Harmonization
5
Standard Meter Data Profiles
14
Transmission and Distribution
Systems Model Mapping
6
Common Semantic Model for Meter Data
tables
15
Harmonize Power Line Carrier Standards for
Appliance Communications in the Home
Models
for
Electric
Power
41
533576827
02.10.09
04.03.11
7
Electric Storage Interconnection Guidelines
16
Wind Plant Communications
8
CIM for Distribution Grid Management
17
Customer Facility Smart Grid Information
•
NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0,
published January 2010
– Smart Grid Vision & Reference Model
– Identified 75 existing standards
•
Guidelines for Smart Grid Cyber Security, pulished August 2010
– Risk assessment guidance for implementers
– Recommended security requirements
– Privacy recommendations
[Ref: P1!T-2234_i.doc; 2011-03]
3
NGN MOBILITY
4
NGN QUALITY OF SERVICE
5
NGN SIGNALING
5.1 Wireline Access
5.1.1 Metallic Access Standards
5.1.1.1 Testing and Maintenance
The transport technologies used to transmit data are Digital Subscriber Line – DSL – families (ex. ADSL,
VDSL2, etc.). DSL signals share the same metallic cable network used by fixed telephony signals.
Originally, this network was projected only for transmission of voice signals, but today xDSL is used for
the transmission of data through the old telephony network. This network normally is very old and
therefore its initial transmission characteristics may have been modified, affecting the performance of the
data transmission.
Before using a metallic cable network for data transmission with xDSL technology, it is necessary to
ensure that the network has been qualified for this purpose. ITU-T Study Group 5 issued, in 2008, a
metallic networks qualifying methodology for use of xDSL technology, before and after its installation in
the access network: Recommendation L.75 - Test, acceptance and maintenance methods of copper
subscriber pairs (05/2008).
42
533576827
02.10.09
04.03.11
5.1.1.1.1
Basic Objective of L.75 Recommendation
Recommendation L.75 describes a qualify methodology of metallic cable network for xDSL signals
transport before and after the installation in the access network. This evaluation process is based on
measurement of transmission rate obtained in the worse case of transmission in the network, i.e., when all
the other pairs are being used for data transmission at the same time. This methodology of evaluation and
qualification is known as Spectral Emulation Method (SEM), and may be applied to older networks
designed to transport telephony services, as well as to new metallic cable networks intended to support
broadband Internet.
SEM Overview
SEM is based on Nyquist and Shannon Theories. The Nyquist Theory establishes that a digitized signal
shall be recovered without distortions only when the sampling frequency is, at least, two times the
maximum frequency of the transmitted signal. The following equation expresses the Nyquist Theory:
C = 2.B.log2n
Where:
B → Bandwidth
C → Channel Capacity
n → number of simbols
Shannon, using the Nyquist Theory, established that the signal-to-noise ratio affects the channel
transmission capacity. The equation below expresses the Shannon Theory:
C = B.log2(1 + S/N)
Where: S/N → Signal-to-noise ratio.
In the SEM, one cable pair is chosen for the measurement of the transmission rate, noise power spectral
density (N-PSD) and signal-to-noise ratio (S/N). This pair is called the victim pair (VP). The other cables
are loaded with controlled xDSL signals, with limited power spectrum density, according to the xDSL
technology under evaluation. This process is repeated, changing the VP, until all pairs have been
measured.
Example of Test Procedure
Before installing any new cable on a network or xDSL signals in an existent network, all pairs should be
tested to prevent detecting possible problems only after the system is installed. It is recommended that
SEM be applied only to groups of up to 600 pairs.
The following test procedure is an example of SEM application to a 50-pair cable:
1. Select one pair as VP. Feed the others pairs, at the near-end side, with non-coherent signals, with
power spectrum density (PSD) limited according to the ITU Recommendation applicable to the
xDSL technology under evaluation. At the other side, these pairs must be properly terminated
with a resistive load, as indicated.
2. Connect one DSLAM port at the near-end side and a modem at the other side of the VP. This will
be the pair under test.
3. Measure the highest TR and S/N in VP.
4. Shut off the DSLAM port and measure the N-PSD at the VP far-end side using a spectrum
analyzer.
43
533576827
02.10.09
04.03.11
5. Repeat the steps above until all pairs have been measured.
Bibliography
[1] ITU-T L.75 (05/2008) – Test, acceptance and maintenance methods of copper subscriber pairs,
available in http://www.itu.int.
[Ref: P1!T-1793_i.doc; 2009-09]
5.1.2
Fiber Access Standards
5.1.3
Power Line Access Standards
5.2 Wireless Access
5.2.1 WLAN (IEEE 802.11) Wi-Fi
5.2.2
Mobile Broadband Wireless Access (IEEE 802.20)
5.3 Satellite
44
533576827
02.10.09
04.03.11
6
SECURITY
To secure information in a network [11] there are three critical components that need to be considered.
Authentication validates the identity of the party or parties participating in the exchange of information.
Confidentiality protects against eavesdropping or monitoring of the information exchange. Integrity
assures that the information has not been altered during transmission. The nature of IP makes it difficult
to verify where the information comes from, and easy for an attacker to take advantage of this weakness
by spoofing the IP address. Spoofing occurs when an attacker changes the source address in the IP packet.
Determining where the attack is coming from is very difficult as the attacker keeps changing the source
address.
The importance of security is recognized by both the IETF and the ITU-T. There is a need to further
understand all of the issues and implications. To address the Security problem, the IEFT created the
Security Area and further subdivided the area into working groups. The ITU-T SG 17 (Data Networks
and Telecommunication Software) has a security study group that targets security issues at all levels. The
role of each organization is somewhat different. The IETF Security Area Advisory Group primary role is
to provide help to IETF working groups on how to provide for security in the protocols they design. On
the other hand, the ITU-T is focusing on the need for a global approach to the dissemination of
information regarding the security of critical network infrastructures and ways to stimulate international
or regional cooperation with respect to critical network infrastructure.
6.1 ITU-T Security Standards
Study Group 17 is the Lead SG for Security
[Editor’s Note: Information from P1!T-1604 will be used to update this section. ]
ITU-T SG 17 work on security
 Q1/17 - Communications systems security project
 Q2/17 - Security architecture and framework
 Q3/17 - Security management
 Q4/17 - Cybersecurity
 Q5/17 - Countering spam by technical means
 Q7/17 - Secure application services
 Q9/17 – Telebiometrics
 Q10/17 – Identity management architecture and mechanisms
6.1.1
Approved ITU-T Security Recommendations
M.3016.0,
1, 2, 3, 4
Security for the management plane: Overview, Security requirements, Security
services, Security mechanism, Profile proforma
X.509
Information technology – Open Systems Interconnection – The Directory: Publickey and attribute certificate frameworks
X.805
Security architecture for systems providing end-to-end communications
X.893
Information technology – Generic applications of ASN.1: Fast infoset security
X.1035
Password-authenticated key exchange (PAK) protocol
45
533576827
02.10.09
04.03.11
X.1051
Information security management system - Requirements for telecommunications
(ISMS-T)
X.1055
Risk management guidelines for telecommunications organizations
X.1056
Security incident management guidelines for telecommunications organizations
X.1081
The telebiometric multimodal model - A framework for the specification of
security and safety aspects of telebiometrics
X.1111
Framework for security technologies for home network
X.1114
Certificate profile for the device in the home network, User authentication
mechanisms for home network service, Authorization framework for home
network
X.1121
Framework of security technologies for mobile end-to-end communications
X.1122
Guideline for implementing secure mobile systems based on PKI
X.1141
Security Assertion Markup Language (SAML 2.0)
X.1142
eXtensible Access Control Markup Language (XACML 2.0)
X.1191
Functional requirements and architecture for IPTV security aspects
X.1205
Overview of cybersecurity
X.1242
Short message service (SMS) spam filtering system
X.1244
Overall aspects of countering spam in IP-based multi-media applications
Y.2270
NGN Identity Management Framework
Y.2701
Security requirements for NGN release 1
X.1250
Requirements for global identity management trust and interoperability
X.1251
Framework for user control of digital identity
Y.2702
Authentication and authorization requirements for NGN release 1
Y.2703
The application of AAA service in NGN
Y.2704
Security mechanisms and procedures for NGN
Y.2720
NGN identity management framework
Y.2721
NGN identity management requirements and use cases
[Ref: P1!T-2021_i.doc; 2010-10]
46
533576827
02.10.09
04.03.11
6.1.2
SG 17 Security Work in progress (selected items)
Draft Rec.
Title or Subject
X.1034
Framework for EAP-based authentication and key management in a data
communication network
X.1205
Guideline on preventing worm spreading in a data communication network
X.1245
Framework for countering IP based multimedia spam
X.1243
Interactive gateway system for countering spam
X.tpp-2
Telebiometrics protection procedures – Part 2: A guideline for data protection
X.1089
Telebiometrics authentication infrastructure
X.tsm-2
Telebiometrics system mechanism – Part 2:Protection profile for client terminals
X.1275
Guideline on protection of personally identifiable information in the application
of RFID technology
[Ref: P1!T-2021_i.doc; 2010-10]
6.1.3
SG 13 security work in progress (Q15/13)
Draft Rec.
Title or Subject
Y.mobSec
Mobility security framework in NGN
Y.NGN Sec risk
Security risk assessment in NGN
Y.NGN Certificate Management
NGN certificate management
Y.2722
NGN identity management mechanisms
Y.SecReqR2
Security requirements for NGN release 2
Y.2740
Security requirements for mobile remote financial transactions in the
next generation network (NGN)
Y.2741
Architecture of secure mobile financial transactions in the next
generation network (NGN)
[Ref: P1!T-2021_i.doc; 2010-10]
47
533576827
02.10.09
04.03.11
6.2 Identity Management
Identity management, a cornerstone of establishing trust in the evolving Information and Communications
Technologies (ICT) infrastructure, is necessary to control access to services and infrastructures, to protect
personal information, to perform online transactions, and to comply with legal and regulatory
requirements. A diverse set of identity management (IdM) solutions existing for specific market
segments and perspectives. Many of these solutions are highly distributed and autonomous, resulting in a
need to establish a trusted, global, and interoperable IdM capability.
This section provides an overview of key concepts associated with identity management and outlines
current activities related to identity management.
6.2.1
Identity Management Concepts
Identity may be viewed as an attribute of a specific entity – a human, an organization, a service provider,
an application, a process, a sensor – in a specific context. While the term “identity” has been used
extensively in international standards documents, it is often never explicitly defined.
The ITU-T has recently initiated an activity related to identity management (see Section 3 for more
details). As part of this effort, one objective is to develop a common understanding of the term “identity”
that can be expressed in one or more ways to meet the needs and expectations of ITU members. Recent
(draft) conclusions of this work indicate that identity, as used in current standards, is a concept that allows
for various kinds of representations of an entity at some point in time and space with some degree of
desired consistency. An ontology of identity is proposed as shown in Figure 1.
48
533576827
02.10.09
04.03.11
Figure 11 - Ontology of Identity
[Reference: ITU-T Correspondence Group Report on the Definition of the Term “Identity”, draft version
0.7, 22 February 2008]
According to this ontology, an entity is a real person, legal person or object – which in turn can consist of
anything physical, network elements, or software or content. Identity is a set of representations that are
either asserted (e.g., an entity saying “this is my identity”) or manifested by an entity. Representations
take some kind of physical or electro-optical form – some of which may consist of digital expressions.
There are four distinct kinds of representations: identifiers, authenticators or credentials, attributes, and
patterns.
Identifiers are universally regarded as “names, numbers, or addresses” which may arise in two different
ways, such as assigned, registered by some authority, or self-issued. Authenticators or credentials are
certificates (e.g., ITU-T X.509 digital certificates) or tokens which may be issued by established authority
or self-issued. Attributes consist of any kind of information with a binding to an identifier or
authenticator that is either registered or captured in conjunction with their use (e.g., geospatial location,
transactional activity, and images). Patterns take the form of either signatures derived from activity or
reputation when asserted by an entity for identity purposes.
Based on this ontology, the ITU-T Correspondence Group Draft Report defines identity as [Reference:
ITU-T Correspondence Group Report on the Definition of the Term “Identity”, draft version 0.7, 22
February 2008]:
Identity- The assertion or manifestation of a structured representation of an entity in the
form of one or more credentials, identifiers, attributes, or patterns. Such representations
can take any physical or electro-optical form or syntax, and have associated implicit or
explicit time-stamp and location specifications.
It should also be noted that at the TSAG meeting December 2007, it was agreed, for ITU-T purposes, that
the identity asserted by an entity represents the uniqueness of that entity in a specific context and is not
intended to indicate positive validation of a person. The recent results of the Correspondence Group
activity will be presented to TSAG for further deliberation. T
The Correspondence Group Draft Report also defined identity management as:
identity management - The diverse arrays of different technical, operational, and legal
systems and practices involving the structured capture, syntactical expression, storage,
tagging, retrieval, and destruction of entity identities.
A large number of industry groups and standards organizations are working on standardizing aspects of
identity management. Generally, different groups develop optimum solutions for specific market
segments and perspectives (e.g., user-centric, application-centric [web services and electronic commerce],
and network-centric perspectives). The result is a variety of identity-based solutions that ultimately
should interoperate with each other.
49
533576827
02.10.09
04.03.11
The ITU-T surveyed many of these initiatives and identified seven groups of common global IdM
requirements, although there were diverse existing capabilities within each group [Reference: ITU-T
Focus Group Identity Management Output: Report on Requirements for Global Interoperable Identity
Management, September 2007]:
1.
A common, structured identity management model and identity management plane.
2.
Provision of core credential, identifier, attribute, and pattern identity services with known
assurance levels to all entities.
3.
Discovery of authoritative identify provider resources, services, and federations.
4.
Interoperability among authorization privilege management platforms, identity providers and
provider federations, including identity bridge providers.
5.
Security and other measures for reduction of identity threats and risks, including protection of
identity resources and personally identifiable information.
6.
Auditing and compliance, including policy enforcement protection of personally identifiable
information.
7.
Usability, scalability, performance, reliability, availability, internationalization, and disaster
recovery.
Identity management therefore provides assurance of identity information that supports secure, trusted
access control. Identity management supports a multitude of identity-based services that includes targeted
advertising, personalized services based on geo-location and interest, and authenticated services to
decrease fraud and identity theft. A trusted, global, interoperable IdM capability is a goal that would help
meet the needs of the evolving, hyper-connected ICT infrastructure and services.
6.2.2
Activities
As previously noted, there are many activities that relate to identity management standardization. A nonexhaustive list of identity management activities is presented below in three categorizes:
•
Standardization bodies and similar organizations: de jure/de facto standards including standard
development organizations such as ITU-T, partnership projects such as 3GPP, and wellestablished open communities such as IETF and Liberty Alliance Project.
•
Research activities: aimed at developing IdM technologies.
•
Other IdM related activities: examples include open source projects and advocacy groups.
IdM-GSI is a grouping of ITU-T Study Group Rapporteurs working on Identity Management (IdM) for
telecommunications. i.e. Joint Rapporteur Group (JRG). The objective is to progress IdM technical work
in the various SG Questions in a well-coordinated/complementary manner and avoid duplication and
conflict. The following is a graphical summary of status of ITU-T work on IdM:
50
533576827
02.10.09
04.03.11
Figure 12 – Status of ITU-T Work on IdM
[Source: GSC-13 Meeting, Document GSC13-PLEN-12]
The ITU-T Focus Group on Identity Management (FG IdM) produced six deliverable reports that
document the work it accomplished in fulfillment of its terms of reference. The FG IdM was chartered by
ITU-T Study Group 17 in December 2006 and worked through September 2007.
The results of the FG IdM work are documented in the following freely available reports which
can be downloaded from its web site.
Report Title
Deliverables from ITU-T IdM Focus Group
Report Contents
FG IdM Report No. 1: Report on
Activities Completed and Proposed
FG IdM Report No. 2: Overview
Report on the Deliverables
FG IdM Report No. 3: Report on
Identity Management
Ecosystem and Lexicon
•
•
•
List of completed activities
List of proposed activities
•
Living List of organizations working on IdM related
subjects.
IdM related terms and definitions in use
Identifies, describes and analyzes IdM gaps,
Documents example use cases illustrating the gaps.
Used to derive the requirements for a generic IdM
framework
Provides a global analysis on IdM requirements and
Identity Management Use Cases
and Gap Analysis
•
•
•
•
FG IdM Report No. 5: Report on
•
FG IdM Report No. 4: Report on
Summarizes the deliverables of the FG IdM and provides an
assessment of the completeness of the deliverables.
51
533576827
02.10.09
04.03.11
Requirements for Global
Interoperable Identity Management
FG IdM Report No. 6: Report on
Identity Management Framework
for Global Interoperability
•
•
capabilities,
Includes requirements for the protection of personally
identifiable information (PII).
Describes an extensible, platform-independent,
identity protocol-independent, IdM Framework to
support existing and new IdM solutions.
[Ref: P1!T-2021_i.doc; 2010-10]
More complete information and pointers to these activities are listed in the document ITU-T Focus Group
Identity Management Output: Report on Identity Management Ecosystem and Lexicon, September 2007.
6.2.2.1 Standards bodies and similar organizations
• 3GPP: Developed specifications related to Subscription Management (SuM);
•
ATIS: Packet Technologies and Systems Committee (PTSC) is studying IdM;
•
ETSI: TIPSAN developed specifications related to Subscription Management (SuM);
•
IETF: Developed many resource/entity identification specifications, including Uniform Resource
Identifier/Name, Internationalized Resource Identifier, Uniform Resource Name, Universally
Unique Identifier, Enhancements for Authenticated Identity Management in the Session Initiation
Protocol, etc.
•
ISO/IEC: ISO/IEC JTC 1/SC 27 (Information Technology – Security Techniques) has approved a
new project on IdM.
•
ITU-T: a number of Study Groups deal with various aspects of Identity Management. The
Telecommunication Standardization Bureau has recently created the Identity Management Global
Standards Initiative (IdM-GSI) to focus on developing the detailed standards necessary for
deployment of IdM capabilities that enables secure and trustworthy assertions about digital
identities used in telecommunications, control networks, and a variety of service offerings. IdMGSI harmonizes, in collaboration with other bodies, different approaches to IdM worldwide.
•
Liberty Alliance Project: Specified an open standard for federated network identity that is
intended to support current and emerging network devices, offering a secure way to control
digital identity information.
•
OASIS (Organization for the Advancement of Structured Information Standards): Developed
identity management platforms including: Security Assertion Markup Language, eXtensible
Access Control Markup Language, Service Provisioning Markup Language, eXtensible Resource
Identifier, and Web Services Security.
•
OECD: Identity management in the online environment is seen as a key enabler for electronic
business and electronic government because it facilitates the expansion of information systems
and network boundaries and increases access points. A workshop was held and brought together
experts from government, industry and civil society to explore the main information security and
privacy issues surrounding digital identity management.
•
Open Mobile Alliance: Developed specifications related to IdM including Identity Management
Framework Requirements document.
•
World Wide Web Consortium (W3C): Developed recommendations for XML aspects of IdM.
52
533576827
02.10.09
04.03.11
6.2.2.2 Research Activities
• Archival Resource Key is naming scheme is designed to facilitate the high-quality and persistent
identification of information objects.
•
The European Union / European Commission supports a number of projects relating to IdM,
including:
o Future of Identity in the Information Society (FIDIS): shaping the requirements for the
future management of identity in the European Information Society and contributing to
the technologies and infrastructures needed;
o GUIDE: conducting research and technological development with the aim of creating
architecture for secure and interoperable e-government electronic identity services and
transactions for Europe
o Privacy and Identity Management for Europe (PRIME): aims to develop a working
prototype of a privacy-enhancing Identity Management System
6.2.2.3 Other Identity Management Related Activities
• Higgins: A framework that will enable users and enterprises to integrate identity, profile, and
relationship information across multiple systems. Using context providers, existing and new
systems such as directories, collaboration spaces, and communications technologies (e.g.
Microsoft/IBM WS-*, LDAP, email, IM, etc.) can be plugged into the Higgins framework.
Applications written to the Higgins API can virtually integrate the identity, profile, and
relationship information across these heterogeneous systems.
•
OpenID: open source community solution for IdM. It is a lightweight method of identifying
individuals that uses the same technology framework that is used to identify websites.
•
Shibboleth: Standards-based, open source middleware software which provides Web Single
SignOn (SSO) across or within organizational boundaries. The Shibboleth software implements
the OASIS SAML specification, providing a federated Single-SignOn and attribute exchange
framework.
This list is only a sample of the many activities underway in the identity management area.
Harmonization of these different approaches, while leveraging research and deployment experiences, is a
key goal for the international community.
[Ref: P1!T-1249_i.doc; 2008-03]
53
533576827
02.10.09
04.03.11
7 CONFORMANCE AND INTEROPERABILITY
7.1 ITU-T Standardization
7.1.1 Joint Coordination Activity – Conformance and Interoperability Testing
Objectives
 Collect and disseminate information about testing activities and testing methodologies
 Provide feedback on collected information as appropriate
 Seek input on the implementation of tasks within WTSA-08 Resolution 76
 Develop a common understanding of Conformance vs. Interoperability testing
 Develop requirements placed on writing Recommendations to accommodate testing
 Provide technical assistance to Rapporteurs and editors writing Recommendations for testing
 Provide technical assistance to Rapporteurs and editors writing test specifications
 Assist in the interpretation of the X.290- and Z.160/170-series of Recommendations
 Provide input towards the evolution of Recommendations that define testing methodology
 Disseminate information about testing across other SDOs, e.g. ISO, ETSI
 Prepare material for tutorials, workshops, conferences and make presentations as appropriate
 Promote of the use of a common terminology and methodology of testing
 Find working methods to co-ordinate activities and improve sharing of results
 Give guidance on testing in NGN, IPTV, Home Networking and other areas
7.1.2
ITU-T Study Group 11
(Lead Study Group for Conformance Testing)
 Q 8/11 Protocol Test Specifications for NGN
 Q 9/11 Monitoring parameters for NGN protocols
 Q 10/11 Service test specification for NGN
 Q 11/11 QoS tests specification for NGN
 Q 12/11 NID and USN test specification
7.1.3
ITU-T Approved Standards on Test Specifications
A partial list includes:

Q.3900 Methods of testing and model network architecture for NGN technical means
testing as applied to public telecommunication networks

Q.3900 Methods of testing and model network architecture for NGN technical means
testing as applied to public telecommunication networks

Q.3901 Distribution of tests and services for NGN technical means testing in the model
and operator networks

Q.3902 Parameters to be monitored in the process of operation when implementing
NGN technical means in public telecommunication networks

Q.3903 Formalized presentation of testing results

Q.3904 The scenarios, list and types of tests for TM local and NUT testing for IMS on
the model networks

Q.3910 Monitoring parameters set for NGN protocols

Q.3911 Monitoring parameters set for voice services in NGN
7.1.4
ITU-T Draft and Completed Standards on Test Specifications
A partial list includes:
 Q.1912.5 Interworking between SIP and BICC or ISUP: Part 5 (Abstract Test Suite and PIXIT)
54
533576827
02.10.09
04.03.11









7.1.5




Q.3930 Performance Testing of distributed systems Concept and Terminology
Q.3931.1 IMS/PES Performance Benchmark: Part 1 (Core Concepts)
Q.3931.2
IMS/PES Performance Benchmark: Part 2 (Subsystem Configurations and
Benchmarks)
Q.3931.2
IMS/PES Performance Benchmark: Part 2 (Subsystem Configurations and
Benchmarks)
Q.3940 NGN Interconnection Testing
Q.3941.1
Network Integration Testing between SIP and ISDN/PSTN network signalling
protocol. Part 1 TSS & TP
Q.3941.2
Network Integration Testing between SIP and ISDN/PSTN network signalling
protocols. Part 2: PIXIT & ATS
Q.3945 Types and list of NGN services testing on the Model networks
Q.3948 VoIP services testing at NGN UNI
ITU-T Interoperability Events
IPTV Interop Event (July 2010; Geneva)
- testing ITU-T’s IPTV suite of standards: H.721 et al
IPTV Interop Event (September 2010; Singapore)
IPTV Interop Event (December 2010; Pune, India)
Future Interop Events may address:
- Home networking
- VDSL 2
- GPON (Gigabit Passive Optical Networks)
[Ref: P1!T-2244_i.doc; 2011-03]
55
533576827
02.10.09
04.03.11
ANNEX 1 - Standards Endorsed by CITEL PCC.I Resolutions
Standard
Resolution
Date
Chapter
Gateway Control Protocol
PCC.I/RES.104 (XIV-01)
March 2001
10.3
Intelligent Networks Capability Set 3
PCC.I/RES.105 (XIV-01)
March 2001
14
Intelligent Networks Capability Set 4
PCC.I/RES.1 (I-02)
Dec 2002
14.1
ITU-T Y.2000-Series Recs for NGN
(SG13)
PCC.I/RES. 25 (III-03)
Sept 2003
9
ANSI-41 Evolved Core Network with
CDMA2000 Access Network
PCC.I/RES. 27 (III-03)
Sept 2003
11.2.2.2
GSM Evolved UMTS Core Network
with UTRAN Access Network
PCC.I/RES. 28 (III-03)
Sept 2003
11.2.2.1
Packet-Based Multimedia
Communications Systems (ITU-T
Rec. H.323)
PCC.I/RES. 44 (IV-04)
March 2004
10.7
Security Architecture for Systems
Providing End-to-End
Communications (ITU-T Rec. X.805)
PCC.I/RES. 45 (IV-04)
March 2004
15.3
Security Architecture for the Internet
Protocol (IPsec)
PCC.I/RES. 46 (IV-04)
March 2004
15.1
Interworking Between SIP and BICC
Protocols or ISUP (Rec. Q.1912.5)
PCC.I/RES. 55 (V-04)
Sept 2004
10.6
56
533576827
02.10.09
04.03.11
SIP: Session Initiation Protocol
PCC.I/RES. 68 (VI-05)
April 2005
10.4
ITU-T Rec. G.993.2, VDSL2: Very
High Speed DSL-2 Transceivers
PCC.I/RES. 98 (IX-06)
Sept 2006
11.1.1
ITU-T Rec. J.122, “SecondGeneration Transmission Systems for
Interactive Cable Television Services
– IP Cable Modems”
PCC.I/RES.99 (IX-06)
Sept 2006
11.1.2
Internet Protocol Version 6 (IPv6)
PCC.I/RES.100 (IX-06)
Sept 2006
17.1
E.164 to Uniform Resource
Identifiers (URI) Dynamic
Delegation Discovery System
(DDDS) Application (ENUM)
PCC.I/Res. 116 (XI-07)
Sept 2007
17.2
ITU-T Rec. E.106, “International
Emergency Preference Scheme for
Disaster Relief Operations”
PCC.I/RES. 130 (XII-08)
March 2008
2.4.2.1
ITU-T Rec. E.107, “Emergency
Telecommunications Service (ETS)
and Interconnection Framework for
National Implementations of ETS”
PCC.I/RES. 131 (XII-08)
March 2008
2.4.2.1
ITU-T Recommendation Y.1910,
“IPTV Functional Architecture”
PCC.I/RES. 145 (XIV-09)
May 2009
2.3.2
ITU-T Recommendation Y.2270,
“NGN Identity Management
Framework”
PCC.I/RES. 146 (XIV-09)
May 2009
6.2
ITU-T Recommendation L.75 ”Test
acepptance and maintenance methods
of copper subscriber pairs “
PCC.I/RES 162 (XVI-10)
May 2010
5.1
57
533576827
02.10.09
04.03.11
ANNEX 2 - NGN Library
8
NGN Introduction
The architecture and implementation of the Next Generation Network (NGN) must be based on open,
standard-based interfaces and protocols. This is essential to achieve multi-vendor interworking and to
accelerate the rate on innovation. It is also well accepted that the NGN must also be based on a distributed
architecture that helps greatly to reduce the implementation costs while giving flexibility in the actual
deployment. The ITU-T Recommendation Y.2001, “General Overview of NGN”, Dec. 2004, provides a
definition of an NGN.
The NGN must be able to support highly customizable services that are easily and rapidly created as well
as deployed economically throughout the network. While it is important to enable new services, it is also
critical to preserve the existing services provided by the legacy network.
8.1 NGN Standards Efforts
NGN standardization is being addressed in a range of international, regional and national standardization
bodies. Work to develop and refine standards for NGNs is ongoing in the ITU-T and other fora such as
ETSI, IETF, ATIS and others. It is worth noticing that considerable collaboration and interaction have
occurred among these SDOs. These new standards are important to ensure that existing networks can be
integrated with the networks that include voice over packet into a single new generation network. Taking
into account the importance of these standards and their potential impact on the region, the Rapporteur
Group on Standards Coordination has been studying these evolving standards and preparing Standards
Coordination Documents (SCD) to highlight and endorse the most significant examples.
8.2 ITU
In early 2002 the ITU began work on NGN standards. Since that time a number of workshops on NGN
have been organized in order to address issues that impact both ITU and other SDOs. Two years later the
ITU established a focus group (FGNGN) to work on both fixed and mobile networks as well as QoS in
DSL, authentication, security, and signalling. Currently, several ITU-T study groups (SG), such as 2, 9,
11, 12, 13, 15, 16 and 17 are involved in NGN standardization work and SG 13 is the Lead SG in NGN.
TheFGNGN completed its work on the first set of standards for NGN in Novemeber 2005. This
specification, known as NGN Release 1, provides a comprehensive framework of services, capabilities
and network functions that constitute an NGN, as described in Y.2001. ITU’s next phase of NGN work,
called the NGN-GSI (Global Standards Initiative), focuses on the detailed protocols required to offer the
wide range of services expected in NGN.
8.3 ETSI
ETSI has been looking at NGN standardization issues since 2001. The TISPAN technical committee has
responsibility for all aspects of standardization for present and future converged networks, including
Voice over IP (VoIP), and NGN. TISPAN selected 3GPP release 6 IMS to be the baseline for the SIP
service machinery in fixed networks.
8.4 ATIS
ATIS has produced an NGN framework that provides high-level requirements and guiding principles. The
first part of this framework deals with NGN definition requirements and architecture of future network
58
533576827
02.10.09
04.03.11
services in new networks to interface seamlessly with communications systems. The second part
documents the phasing and prioritization of network capabilities to ensure the deployment of the NGN
and its services in a coherent manner.
ATIS has been collaborating with the ITU-T, TISPAN, and 3GGP to develop a consistent global view of
the NGN. ATIS advocates the IMS architecture and views it as the appropriate technology of choice to
consistently support new value-added services.
8.5 IETF
The Internet Engineering Task Force is not working on NGN as an individual topic, but its Working
Groups have responsibility for developing or extending existing protocols to meet requirements such as
those agreed for NGN in other standardization bodies. Some of the standardization activities undertaken
by the IETF related to NGN are SIP (session initiation protocol), MEGACO (Media Gateway Control),
SIPPING (Session Initiation Proposal Investigation), NSIS (Next Steps in Signaling), IPv6, MPLS
(Multiprotocol Label Switching), ENUM (Telephone Number Mapping), etc.
In addition to the above mentioned SDOs, there are other industry consortia and fora that actively work
on NGN related standards. Among them we have the Multiservice Switching Forum (MSF), the
Telecommunications Industry Association (TIA), the DSL Forum (DSL-F), the Institute for Electric and
Electronic Engineers (IEEE), Cable Television Laboratories, Inc. (CableLabs), the Telecommunications
Management Forum (TMF), and Parlay/OSA.
The following sections provide an outline of the NGN relevant standards. These standards cover network
aspects such as signaling, access, service creation, management, security, and quality of service.
*****
59
533576827
02.10.09
04.03.11
9
Signaling Standards
This section is based on CITEL contribution PCC.1/doc.957/00 (Evolving Standards for Internet
Telephony) [1, 2]. Some sections of that document have been expanded but others remain as they are in
the original CITEL contribution PCC.I/doc.957/00.
ITU-T Study Groups 11 and 16 have been actively working on IP telephony signaling. SG 16 developed
Recommendation H.323 (Packet-based Multimedia Communications Systems). More recently, Study
Group 11 has developed another approach to supporting telephony over packet networks: namely, that of
introducing a core packet network into existing circuit-switched networks. The protocol developed for
communicating between telephone exchanges in this case is known as the Bearer Independent Call
Control (BICC) protocol. In addition, SG 11 has also been working on SIP related matters and
Recommendation Q.1912.5 defines the signaling interworking between BICC or ISUP protocols and SIP
with its associated Session Description Protocol (SDP) at an Interworking Unit (IWU).
Internet Engineering Task Force (IETF) working groups such as iptel (IP-telephony), pint (PSTNInternet), sigtran (signaling transport), megaco (Media Gateway Control) and mmusic (Multiparty
Multimedia Session Control) have also been working on various Internet Telephony related protocols
such as Session Initiation Protocol (SIP), Session Initiation Protocol for Telephony (SIP-T), Stream
Control Transport Protocol (SCTP), and Media Gateway Control (Megaco) protocol. It is worthwhile to
notice that the H.248/Megaco protocol, used for coordinating media gateways from a media gateway
controller, has been developed jointly by the ITU-T Study Group 16 and the IETF Megaco working
group.
9.1 SIGTRAN (SIGnaling TRANsport)
The mandate of the IETF Sigtran working group was to develop protocols that address the transport of
packet-based PSTN signaling over IP Networks, taking into account functional and performance
requirements of the PSTN signaling. These protocols support communications between the Media
Gateway Controller and the Signaling Gateway.
The sigtran working group specified SCTP (Stream Control Transmission Protocol), RFC 4960 (proposed
standard), and several adaptation layers for transmission of SS7 over IP-based networks. Some adaptation
layers are:
 SS7 MTP2 - User Adaptation Layer, RFC 3331 (proposed standard), which transports MTP2 user
signaling information between the SG and the MGC;
 SS7 MTP3 - User Adaptation Layer, RFC 4666 (proposed standard), which transports ISUP and
SCCP messages between the SG and the MGC.
 ISDN Q.921-User Adaptation Layer, RFC 5133 (proposed standard), which defines a protocol for
backhauling of ISDN Q.921 User messages over IP using SCTP.
 V5.2 - User Application Layer (V5UA), RFC 3807 (proposed standard), which defines a mechanism
for backhauling of V5.2 messages over IP using SCTP.
RFC 2719 (informational) provides the architectural framework for signaling transport and RFC 3257
(informational) describes the applicability of the Stream Control Transmission Protocol. RFC 3868
(proposed standard) defines a protocol for the transport of any Signaling Connection Control Part-User
signaling over IP using SCTP.
60
533576827
02.10.09
04.03.11
9.2 BICC
The Bearer Independent Call Control (BICC) protocol, being developed by ITU-T Study Group 11,
provides a means for existing operators of the PSTN, based upon circuit switched technology, to evolve
their networks towards support for Voice over Packet services with minimal impact on their operations.
Although there exists some overlap in functionality between SG 11’s BICC and SG 16’s H.323, the
H.323 specification is focused on small and new telecommunications carriers while the BICC
specification is focused on the needs of large, incumbent network operators who have installed ISUP
networks and want to delay their migration to SIP / SIP-T.
The BICC protocol is based on the CCS7 ISDN User Part (ISUP) protocol and is specified in ITU-T
Recommendation Q.1901. The BICC is transported using the Application Transport Mechanism (APM).
The BICC protocol is an application of the ISUP protocol definition, but it is not peer to peer compatible
with ISUP. This protocol used to be referred to as ISUP+.
BICC Capability Set one (CS1), which supports communications between Media Gateway Controllers,
was decided (approved) by SG 11 on June 15th, 2000. BICC CS2 (ITU-T Recommendation Q.1902)
focuses on other bearer networks including IP networks. It addresses interface and interactions between
the Media Gateway Controller and the Media Gateway. BICC CS2 was approved in July 2001. BICC
CS3, currently under development, adds support mechanisms for end-to-end QoS and interworking with
SIP.
9.3 Megaco/H.248
The IETF Megaco (MEdia GAteway COntrol) working group and ITU-T Study Group 16 jointly worked
on defining the Megaco/H.248 protocol. The work originated in the IETF Megaco working group, and
most technical discussion and issues closure took place in that environment.
The Megaco/H.248 is a broadly applicable gateway control protocol. It can be used for a wide range of
gateway applications moving information streams from IP networks to PSTN, ATM, and others. The
standard employs a master-slave model in which the source terminal and/or the gateway is a slave of the
media gateway controller.
ITU-T approved Recommendation H.248 June 15, 2000 and the IETF issued a Megaco protocol RFC
2885 shortly after. RFC 2886 (Errata) records the errors found in the Megaco/H.248 protocol document
[RFC 2885], along with the changes proposed in the text of that document to resolve them. RFC 3015
(proposed standard) is the result of applying the changes in RFC 2886 to the text of RFC 2885. RFC
3015 obsoletes RFC 2885 and RFC 2886. The ITU-T H.248 Packages Guide Release 1 summarizes
packages that have been standardized in the time frame from 06/2000 to 06/2001.
RFC 3525 - Gateway Control Protocol Version 1 replaces RFC 3015. RFC 3525 incorporates the original
text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list. H.248
version 2 was completed at the SG 16 meeting of Feb. 2002. RFC 3525/H.248v2 includes correction
updates to RFC 3015/H.248v1 which were in the Implementors’ Guide plus other changes such as:
Deprecation of the Modem Descriptor; Clarification of Audit text, and addition of directed
audits; Enhancement of Digit Collection; and Addition of Nx64 multiplexing to the Multiplex Descriptor.
RFC 5125 onsoletes RFC 3525,
H.248 was renumbered when revised on 2002-03-29. H.248 main body, Annexes A to E and Appendix I
were included in H.248.1 - “Gateway Control Protocol Version 1”. Subsequent annexes were sequentially
numbered in the series, e.g. H.248 Annex F became H.248.2.
61
533576827
02.10.09
04.03.11
In May 22, 2002, H.248.1 – “Gateway Control Protocol Version 2” was approved. Version 2 include
several enhancements to Version 1, such as individual property, signal, event and statistic auditing;
improved multiplex handling; topology for streams; improved description of profiles; and ServiceChange
capability change. Currently the last Annex added is H.248.78 (“Bearer-level application level gateway”).
H.248.1 – Gateway Control Protocol Version 3” was approved in September 2010. Version 3 includes
several enhancements, clarifications and corrections.
9.4 SIP
The Session Initiation Protocol (SIP), [3], developed by the IETF Multiparty Multimedia Session Control
(MMUSIC) working group and currently specified as a Proposed Standard (RFC 3261), builds on a
simple text-based request-response architecture similar to other Internet protocols such as HTTP. The
proposed standard was published in June 2002. The SIP work drew enough attention to create a separate
SIP working group to continue the development. Since its publication, it has been recognized that SIP
needs extensions in order to offer carrier-grade telephony applications. The SIP working group is
considering proposals to achieve this. These proposals add new functionality to the base SIP protocol,
such as the use of MCUs for multiparty conferences; call transfer functionality, reliable provisional
responses ("Call proceeding") and pre-call media cut-through.
The Session Description Protocol (SDP), RFC 4566 (proposed standard), is used in SIP to convey session
parameters such as media encoding. The MMUSIC group is working to enhance the functionality of SDP.
PacketCable, a project conducted by CableLabs and its members, is the most significant early adopter of
SIP. In the PacketCable initiative it was also recognized that SIP has to be extended to offer carrier-grade
services. This resulted in the PacketCable Distributed Call Signaling (DCS) specification. Some of the
ideas put forward in the DCS specification have been published as Internet Drafts. The PacketCable Call
Management Server to CMS protocol uses the Session Initiation Protocol 2.0 (SIP) specification with
extensions and usage rules that support commonly available local and CLASS services. This protocol is
referred to as the Call Management Server Signaling (CMSS) protocol.
SIP is a peer-to-peer signaling control protocol for creating, modifying and terminating sessions (e.g.,
conferences, telephone calls and multimedia distribution) with one or more participants. These sessions
include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members
in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions, which allow participants to agree on a
set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the
user's current location. Users can register their current location. SIP is not tied to any particular
conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and
can be extended with additional capabilities.
RFC 3261 covers basic functionality and there are several related Internet drafts covering services. SIP
has rapidly growing industry momentum at the system and device level. There have been several bakeoffs with different vendors demonstrating interoperability of basic calls. Currently there are several
proposals for extensions waiting for discussion in the working group.
9.4.1
SIP Operation
Callers and callees are identified by SIP addresses. The "objects" addressed by SIP are users at hosts,
identified by a SIP URL. The SIP URL takes a form similar to a mailto or telnet URL, i.e., user@host.
The user part is a user name or a telephone number. The host part is either a domain name or a numeric
network address.
62
533576827
02.10.09
04.03.11
When making a SIP call, a caller first locates the appropriate server (A) and then sends a SIP request (B).
The most common SIP operation is the invitation (C). Instead of directly reaching the intended callee, a
SIP request may be redirected or may trigger a chain of new SIP requests by proxies (D). Users can
register their location(s) with SIP servers (E).
A.
Locating a SIP Server
When a client wishes to send a request, the client either sends it to a locally configured SIP proxy server
(as in HTTP), or sends it to the IP address and port corresponding to the Request-URI.
B.
SIP Request
Once the host part has been resolved to a SIP server, the client sends one or more SIP requests to that
server and receives one or more responses from the server. A request (and its retransmissions) together
with the responses triggered by that request make up a SIP transaction. All responses to a request contain
the same values in the Call-ID, CSeq, To, and From fields. This allows responses to be matched with
requests. The ACK request following an INVITE is not part of the transaction since it may traverse a
different set of hosts.
C.
SIP INVITE
A successful SIP invitation consists of two requests, INVITE followed by ACK. The INVITE request
asks the callee to join a particular conference or establish a two-party conversation. After the callee has
agreed to participate in the call, the caller confirms that it has received that response by sending an ACK
request. If the caller no longer wants to participate in the call, it sends a BYE request instead of an ACK.
D.
Locating a User
A callee may move between a number of different end systems over time. The locations of these can be
dynamically registered with the SIP server. A location server may use a multicast-based protocol to
actively determine the end system where a user might be reachable. If a proxy server forwards a SIP
request, it must add itself to the beginning of the list of forwarders noted in the headers. The RecordRoute
option ensures that replies can take the same path back, ensuring correct operation through compliant
firewalls and avoiding request loops.
E.
REGISTER
A client uses the REGISTER method to register the address listed in the To header field with a SIP server.
A user agent may register with a local server on startup by sending a REGISTER request to the wellknown "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75), depending on what is
implemented in the network. SIP user agents may listen to that address and use it to become aware of the
location of other local users; however, they do not respond to the request. A user agent MAY also be
configured with the address of a registrar server to which it sends a REGISTER request upon startup.
Note: As SIP is implemented within the various networks of the Americas, rigorous test specifications
are being performed. For example, Brazil (utilizing ETSI TS 102 027-2 V4.1.1 (2006-07), Conformance
Test Specification for SIP) has reported that modifications were required to accommodate the realities of
implementation. The Standards Coordination Group has encouraged contributions regarding experiences
in implementation of standards, creation of test specifications, and recommendations for modifications to
standards.
9.5 SIP-T
The IETF Session Initiation Protocol Project INvestiGation (SIPPING) working group is chartered to
document the use of SIP for several applications related to telephony and multimedia, and to develop
63
533576827
02.10.09
04.03.11
requirements for any extensions to SIP needed for those applications. One of those extensions is to
support call/session control. SIP-T (SIP-Telephony) formerly known as SIP-BCP-T (SIP Best Current
Practice for Telephony interworking) is a mechanism that uses SIP to facilitate the interconnection of the
PSTN with SIP networks. SIP-T is more of an interface agreement on a collection of standards as opposed
to a separate protocol. SIP-T messages carry further sub-messages, such as the complete PSTN User Part
message for signaling information and SDP (Session Description Protocol) messages for conveying
connectivity end-point information and media-path characteristics.
As with SIP, SIP-T directly negotiates a media connection between gateways. Endpoint information is
carried in SDP from which can describe both IP and ATM endpoints. SIP-T is still a work in progress in
the IETF. RFC 3372 (best current practice) provides a description of the uses of PSTN-SIP gateways,
uses cases, and identifies mechanisms necessary for interworking. RFC 3398 (proposed standard)
describes a way to perform the mapping between the Session Initiation Protocol (SIP) and the ISDN User
Part (ISUP) of Signaling System No. 7 (SS7). In addition, RFC 3578 (proposed standard) describes a way
to map ISUP overlap signaling to Session Initiation Protocol (SIP).
9.6 Q.1912.5
ITU-T Recommendation Q.1912.5 (Interworking between Session Initiation Protocol (SIP) and Bearer
Independent Call Control or ISDN User Part) defines the signalling interworking between BICC or ISUP
protocols and SIP with its associated Session Description Protocol (SDP) at an Interworking Unit (IWU).
TRQ.2815 (Requirements for Interworking BICC/ISUP Network with Originating/Destination Networks
based on SIP and SDP) specifies the set of common capabilities required to interwork between SIP and
BICC.ISUP for three different profiles.
Profile A was defined to satisfy the demand represented by 3GPP in TA 24.229 V5.1.0 (2002-06). The
work on this protocol was driven by mobile operators and vendors. Profile B complements Profile A, and
both of them are intended to support traffic that terminates within the SIP network. Profile C supports the
trunking of traffic via transit SIP networks using MIME encoded encapsulated ISUP (SIP-I). Figure 3
describes the main scope of each profile defined in TRQ.2815.
An agreement between the IETF and ITU-T on how to align these efforts (SIP-T and Q.1912.5) has not
been reached. Q.1912.5 was approved on March 2004.
Use of SIP/SIP-I Interworking
64
533576827
02.10.09
04.03.11
9.7 H.323
ITU-T Recommendation H.323 (Packet-based Multimedia Communications Systems), [4], addresses how
PC telephones or existing telephones via adaptors can be connected to packet networks and inter-work
with circuit-switched public telephony networks through gateways. H.323 is part of a larger series of
standards that enable videoconferencing across a range of networks. Known as H.32X, this series includes
H.320 for narrowband ISDN (N-ISDN), H.321 for broadband ISDN (B-ISDN) and H.324 for General
Switched Telephone Network (GSTN) communications. The following diagram illustrates the H.323
protocol stack.
Audio
Video
G.711
G.722
G.723
G.728
G.729
H.261
H.263
Data
System Control User Interface
H.225
T.120
Call
Control
RAS
H.245
Control
RTP/RTCP
UDP or TCP
UDP
IP
Lower Layers Vary
H.323 Protocol Stack
Communications under H.323 are a mix of audio, video, data and control signals. H.323 includes:






H.245 for control,
H.225.0 for connection establishment,
H.332 for large conferences,
H.450.1, H450.2 and H.450.3 for supplementary services,
H.235 for security, and
H.246 for interoperability with circuit-switched services.
Audio capabilities, RTP/RTCP media transport, call setup, Registration, Admission and Status (RAS)
control and H.245 signaling are required components; all other capabilities, including video and data are
optional.
The H.323 standard employs a peer-to-peer model in which the source terminal and/or the gateway is a
peer of the destination terminal and/or gateway. It optionally requires a gatekeeper function analogous to
a connection manager. H.323 is most applicable for implementation in end-points that have integrated
65
533576827
02.10.09
04.03.11
processing power. These include PC-based Internet Telephony clients and VoIP gateways integrated with
PBX and key systems with inherent call-processing power. H.323 is the most widely employed standard
among first-generation Internet Telephony solutions.
H.323 is a relatively mature set of standards. The first version was approved in 1996 by the ITU-T Study
Group 16. Version 2 was approved in January 1998 and version 3 in September 1999. SG 16 approved
version 4 in November 2000, Version 5, in July 2003 and Version 6 in June 2006. Version 7 was
approved in December 2009. The Implementer’s Guide for H.323 Systems document contains a
compilation of reported defects identified in the versions of ITU-T Recommendation H.323 and its related
Recommendations currently in force.
One of the advantages of using a more mature protocol such as H.323 is that there has been significant
interoperability testing leading to multi-vendor interworking. The International Multimedia
Teleconferencing Consortium (IMTC) holds several H.323 interoperability events each year since
October 1996. These vendor-only events allow developers to do pair-wise testing with other vendors and
lead to multi-vendor inter-working as well help to fix inconsistencies in the standard. More than 50
vendors have participated in these events. One of the biggest advantages of H.323 is the maturity and the
large degree of multi-vendor interoperability.
Further enhancing the domain of H.323, both the IMTC and iNOW! Working Group have been
developing profiles of the H.323 standard for specific applications. Interoperability testing of iNOW!
profiles is currently being included in the IMTC interoperability events.
Note: As H.323 is implemented within the various networks of the Americas, rigorous test specifications
are being performed. For example, Brazil (utilizing ETSI TS 101 804-2 V2.1.1 (2004-11) –
Conformance Test Specification for ITU-T H.225.0 (Terminal, Gatekeeper and Gateway) has reported
that modifications were required to accommodate the realities of implementation. The Standards
Coordination Group has encouraged contributions regarding experiences in implementation of standards,
creation of test specifications, and recommendations for modifications to standards.
*****
66
533576827
02.10.09
04.03.11
10 Access Standards
A proliferation of access technologies has emerged to address the need for higher bandwidth and to
provide competitive carriers with a means to directly reach customers. Among the different wired
infrastructure technologies we have Cable, xDSL, fiber and power lines. In the wireless infrastructure
space we have satellite, wireless LAN, IMT-2000 and Fixed Wireless.
Within the ITU-T, the study and development of Recommendations related to access networks standards
is being carried out in a number of different Study Groups, e.g., SG 9, 13, 15, 19. Moreover, ITU-R (SG 8
and 9) and other standards bodies, forums and consortia are also active in this area.
10.1 Wired Access Standards
10.1.1 Digital Subscriber Line (DSL) Access Standards
DSL services [10] of various types (HDSL, SDSL, ADSL, and VDSL) can be provided via the NGN by
developing corresponding cards in the access gateways. High Data Rate DSL (HDSL) is an alternative
form of T1, using more advanced techniques than the original T12, extending the range to 12,000 feet.
However, it requires two copper pairs. HDSL is not well suited for residential broadband access
application. HDSL is sometimes deployed for PBX access, and within the feeder network for aggregation
of ISDN BRI lines. Single Line DSL (SDSL) is the single line version of HDSL. SDSL is somewhat more
suitable for residential usage since it only requires one copper pair. However, since much higher
downstream rates can be achieved by ADSL, it is unlikely that SDSL will be used for residential access.
Asymmetric DSL (ADSL) is the technology most suitable for residential access, with rates of up to 6
Mbit/s for downstream and up to 640 kbit/s for upstream, depending on distance and configuration
options. ADSL operates in a frequency band above POTS, leaving POTS service independent and
undisturbed; even if a premise’s ADSL modem fails. Most ADSL systems are still centralized around
central offices, where Asymmetric Digital Subscriber Line Access Mulitplexors (ADSLAMs) are
installed. The use of remote ADSLAMs would allow higher penetration of DSL systems into rural areas.
However, the length of the line is not the only consideration or impediment to ADSL provisioning.
Another consideration is the number of pairs used for ADSL in a given cable due to interference
considerations. Thus, larger pair cables do not necessarily carry larger number of DSL circuits. The
following distance limits are typical under favorable circumstances: 1.5 Mbit/s up to 18,000 feet and six
Mbit/s up to 9,000 feet.
The requirements for ADSL systems are specified in ANSI T1.413-1998 -Network and Customer
Installation Interfaces – Asymmetric Digital Subscriber Line (ADSL) Metallic Interface. ITU-T
Recommendations G.992 appears to be the most suitable for residential broadband access. It is expected
that G.992.2 will be the standard of choice for the immediate future, being the simplest solution capable
of meeting the 1.5 Mbit/s near term requirement. It is understood that the ITU-T recommendations G.992
are compatible with ANSI T1.413-1998.
VDSL (Very high speed DSL) standards have been developed in various standards bodies. ITU-T
Recommendation G.993.1 (approved in June 2004), known as VDSL or VDSL1, supports up to 26 Mb/s
over distances up to 50 meters on short loop such as from fiber to the curb. VDSL is currently being
introduced to deliver video services over existing phone lines.
2
T1 operates at 1.544 Mbit/s and requires repeaters every mile or so.
67
533576827
02.10.09
04.03.11
VDSL2 (an enhancement to G.993.1) is specified by ITU-T Recommendation G.993.2 (approved in Feb.
2006). This standard specifies 8 profiles that address a range of applications including up to 100 Mb/s
symmetric transmission loops about 100 meters long, and asymmetric operation with downstream rates in
the range of 10 – 40 MB/s on loop of lengths ranging from 3 km to 1 km.
VDSL2 will allow operators to offer services such as high-definition TV (HDTV), video-on-demand,
videoconferencing, high speed Internet access and advanced voice services like VoIP, over standard
copper telephone lines.
The DSL Forum has produced a number of Technical Reports (TR), containing requirements for ADSL
and support for IP access over DSL. Conformance requirements for both ANSI T1.413 and G.992.2 are
specified in TR-026 and TR-033 respectively. Testing requirements are specified in TR-023, TR-029, and
TR-031.
10.1.1.1 ATM over ADSL
The recommendations for the ATM capabilities are described in DSL Forum TR-017. TR-017 addresses
the control and management planes as well as the ATM user (data) plane. It includes ATM PVC support,
signaling for SVC support and operations and maintenance functionality to support ATM over DSL.
Note: According to information obtained from the DSL Forum, most deployments of DSL using ATM
use PVCs with Unspecified Bit Rate (UBR). SVCs with specific QoS are expected to be widely deployed.
The scope of TR-017 is to provide a specification for the transport of ATM over ADSL that is consistent
with the ADSL PHY Recommendations ANSI T1.413, ITU-T G.992.1, and ITU-T G.992.2.
10.1.1.2 AAL5 over ATM
ATM Adaptation Layer 5 (AAL5) is defined in I.363.5, Type 5 AAL, and provides a frame based
transport mechanism.
10.1.1.3 Protocol ‘x” over AAL5
RFC 2684 (Proposed Standard), Multi-protocol Encapsulation over AAL5, is the standard for
encapsulating protocols over AAL5.
Note: When PPP is to be carried over ATM, RFC 2364 applies (see section 10.1.2.1.2).
10.1.2 IP Access Requirements
TR-043, Protocols at the U Interface for Accessing data Networks using ATM/DSL, describes five
different protocol stacks for access. These are shown in Figure 5 below.
68
533576827
02.10.09
04.03.11
PPPoA
IP/ Eth
PPPoE
IP/AAL5
L2TPoA
IP
PPP
PPP
PPPoA
Ethernet
PPPoE
PPP
Ethernet
L2TP
LLC or VC Mux
AAL5
ATM
DSL
Protocol stacks for Access to IP networks
All five stacks utilize AAL5 over ATM over DSL. Using ATM over the DSL segment has the advantage
of being compatible with ATM networks. Thus, in some cases the DSL portion of the access may feed
into an ATM network for connection to an ISPs point-of-presence. In other cases, the ISPs POP may be
connected to the DSL termination point, either directly or indirectly without the use of an intervening
ATM network.
Three of the stacks make use of PPP (Point-to-Point Protocol). Once ATM layer connectivity is
established between the customer premises and the service provider network, the session setup and
release phases at the link level and network level can be established using PPP.
Two of the stacks encapsulate Ethernet over AAL5, allowing the Ethernet used within the end-customer
premises to be bridged on to the access network.
DSL Forum Technical Report TR-044 specifies procedures for auto-configuration.
As far as IP is concerned, in three cases it is carried over PPP. In one case, it is carried over Ethernet, and
in the other, it is carried directly over AAL5.
As far as ATM is concerned the requirements are as specified by the ATM Forum. The ATM service may
be SVC or PVC. For ATM SVC service, use of UNI 3.1 (ATM Forum af-uni-0010.002, 1994) is
mandatory and UNI 4.0 (ATM Forum af-sig-0061.000, July 1996) may be required and it is strongly
recommended.
Notes:
69
533576827
02.10.09
04.03.11
(1)
(2)
At the user’s premises some modems may include options to accommodate various stacks, and
yet deliver at the T interface a simple IP over Ethernet interface. Network Interface Cards (NICs)
may also be inserted directly into PCs. The precise arrangements vary not only from network to
network but also on the packaging of transmission and protocol functionalities, among the
modem, router, and/or PC components.
At the concentration point, ADSL Access Multiplexors (ADSLAMs or just called DSLAMs) will
be used. Again, the bundling or packaging of transmission and protocol functions may vary, and
this may affect the nature of third party peering arrangements.
10.1.2.1 PPP (Point-to-Point Protocol)
PPP allows specific sessions to be set up and torn down. This means that a session does not have to be
permanently “on” and PPP provides mean for security, and authentication, authorization and accounting.
It is particularly useful for “dial up” connections, and in this case for ATM SVCs, but it can also be used
in other situations.
PPP is specified in RFC 1661 (Standard). RFC 2153 – PPP Vendor Extensions, provides updates to RFC
1661
10.1.2.1.1
IP Considerations
The PPP protocol suite offers a number of IP “helper” functions as outlined above.
Other considerations include address allocation/resolution. The Dynamic Host Configuration Protocol
(DHCP) specified in RFC 2131 (Draft Standard) is commonly employed for address configuration.
In systems where DHCP is not used, manual allocation and configuration may be necessary. In some
cases the Address Resolution Protocol defined in RFC 826 (Standard) may be required. RFC 3396 Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4), provides updates to
RFC 826.
Note: PPP may become the protocol of choice because of its session related capabilities.
10.1.2.1.2
PPP over AAL5
This is specified in RFC 2364 (Proposed Standard), PPP over AAL5. This approach is used when the
ATM network is used as a point-to-point link and PPP functions are required.
The DSL Forum requires the null encapsulation (VC multiplexing) form to be the default.
10.1.2.1.3
PPP over Ethernet
This is specified in RFC 2516 (Informational), Method for Transmitting PPP Over Ethernet (PPPoE).
PPPoE allows session features of PPP to be used (see 10.1.2.1).
10.1.2.1.4
IP over AAL5
IP can be encapsulated directly over AAL5 without an intervening Ethernet or PPP, as specified in RFC
2684. There is no session demarcation in this case.
70
533576827
02.10.09
04.03.11
10.1.2.1.5
IP over Ethernet
This is a well-established solution, and is specified in RFC 1042 (Standard), “Standard for the
transmission of IP datagrams over IEEE 802 networks”.
10.1.2.1.6
Layer 2 Tunneling Protocol (L2TP)
RFC 2661 (Proposed Standard) defines a Layer 2 Tunneling Protocol (L2TP). This protocol allows an
L2TP Access Concentrator (LAC) to be inserted between the user and the network server for the carriage
of PPP.
10.1.3 Cable Access Standards
The CableLabs PacketCable initiative is aimed at developing interoperable interface specifications for
delivering real-time multimedia services over two-way cable plants. Built on top of cable modem
infrastructure, PacketCable networks will use IP technology to enable a wide range of multimedia
services, such as IP telephony, multimedia conferencing, interactive gaming, and general multimedia
applications.
CableLabs has taken the approach for defining specifications relating to the entire VoIP architecture
where the only type of line access considered is via Cable HFC. These specifications are undergoing
some maintenance but are relatively stable. Data Over Cable Service Interface Specification (DOCSIS)
was developed by CableLabs to define the access network between the head end or cable-modem
termination system (CMTS) and the home modem interface. Three successive DOCSIS versions have
been issued:
DOCSIS 1.0 (High Speed Internet Access) and 1.1 (Voice, Gaming, Streaming) can deliver up to 40Mbps
downstream and 10Mbps per channel upstream (shared bandwidth). ). This version was ratified as ITU-T
Rec. J.112 in 1998.
DOCSIS 2.0 (Capacity for Symmetric Services) supports a peak upstream rate of 30Mbps. This
specification was approved by the ITU-T as J.122 in 2007.
DOCSIS 3.0 (Management over IPv6 and channel bonding) supports a peak upstream rate of 30Mbps.
This specification was approved by the ITU-T as J.222 in 2007.
10.2 Wireless Access Standards
The main areas of ITU standards activities on IMT-2000 are distributed in Telecommunications
Standardization (ITU-T), the Radiocommunication (ITU-R) and the Telecommunications Development
(ITU-D) Sectors. The ITU-T Study Group 13 "Future networks including mobility and NGN", among its
responsibilities, includes
responsibility for studies related to network aspects of mobile
telecommunications networks, including International Mobile Telecommunications, wireless Internet,
convergence of mobile and fixed networks, mobility management, mobile multimedia network functions,
internetworking, interoperability and enhancements to existing ITU-T Recommendations on IMT.
In order to obtain Global Roaming, the IMT-2000 project formed two groups for the standardization of
terrestrial networks: 1) 3GPP (3rd Generation Partnership Project) to develop the evolution of the Global
System for Mobile Communications (GSM) towards the Universal Mobile Telecommunications System
(UMTS) and 2) 3GPP2 to develop the evolution of the Interim Standard 95 (IS-95) towards the Code
Division Multiplex Access 2000 (CDMA 2000).
71
533576827
02.10.09
04.03.11
Another wireless access standard is IEEE.802.16, nicknamed WiMAX and also called now “World
Interoperability for Microwave Access”. This standard enables broadband speeds over wireless networks.
The ITU-R has recently approved Recommendation F.1763 on "Radio interface standards for broadband
wireless access systems in the fixed service operating below 66 GHz" which recommends IEEE Std
802.16-2004.
10.2.1 Broadband Wireless Access (IEEE 802.16) WiMAX
There is a tremendous growth in wireless applications and services and the world is witnessing increasing
demand for multimedia and broadband applications. Networks are moving towards packet-based services
and are becoming IP centric and worldwide convergence is taking place in which wireless medium plays
a critical role. In this respect the boundaries between 3G and Broadband Wireless Access (BWA) are
rapidly being blurred and that these solutions can complement each other very effectively.
The IEEE 802.16e Task Group (Mobile WirelessMan) released on February 2006 its standard “Air
Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and
Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands”.
The first IEEE 802.16 standard was approved in December 2001 and was followed by three
amendments – 802.16a, 802.16b and 802.16c to address issues of radio spectrum, quality of
service and inter-operability, respectively. Another amendment, 802.16e addressing mobility was
finalized in 2005. Although the 802.16 family of standards is officially called WirelessMAN, it
has been dubbed WiMAX by an industry group called The WiMax Forum. The mission of the
Forum is to promote and certify compatibility and interoperability of broadband wireless
products. Now the acronym WiMAX expands to "Worldwide Interoperability for Microwave
Access".
WiMAX is a wireless broadband technology, which supports point to multi-point (PMP) broadband
wireless access over long distances with high throughput. WiMAX works in a very different way than
Wi-Fi (IEEE Wireless LAN standard 802.11). WiFi uses contention access through its Media Access
Controller (MAC), meaning that all subscriber stations compete for access points on a random basis,
which can cause that distant nodes maybe interrupted more than closer nodes, reducing their throughput
and for that not very suitable for services such as VoIP, IPTV, etc. WiMAX instead, uses a scheduling
MAC, meaning that subscriber stations only compete once for the initial entry into the network. Once
they enter, they are allocated a time slot by the base station. This time slot is not always the same length
but it remains assigned to the subscriber station, not being able to be used by others. The scheduling
mechanism allows the base station to control the Quality of Service (QoS).
The ITU-R approved on April 2006 Recommendation ITU-R F.1763 on "Radio interface standards for
broadband wireless access systems in the fixed service operating below 66 GHz." This standard,
developed by ITU-R Study Group 5, recommends IEEE Std 802.16-2004 as well as the compatible ETSI
BRAN HIPERMAN standard.
10.2.2 IMT-2000 (3GPP, 3GPP2)
10.2.2.1 3GPP
The 3GPP is an organization formed by several partners. These are: the Association of Radio Industries
and Businesses (ARIB) and the Telecommunication Technology Committee (TTC) of Japan; the
72
533576827
02.10.09
04.03.11
European Telecommunications Standards Institute (ETSI); the Alliance for Telecommunications Industry
Solutions (ATIS) of USA and the Telecommunications Technology Association (TTA) of Korea.
As mentioned above, 3GPP is developing the evolution of GSM towards UMTS.
GSM uses Time Division Multiplexing (TDMA) to allocate the different voice and signaling
channels and it has digital call quality on both types of channels, which means that it is considered
a second generation (2G) mobile phone system. GSM is an open standard developed by the 3rd
Generation Partnership Project (3GPP). Most GSM networks operate in the 900 MHz or 1800 MHz
bands.
UMTS represents an evolution in terms of capacity, data speeds and new service capabilities from
second generation mobile networks. UMTS is a key member of the global family of third
generation (3G) mobile technologies. 3G/UMTS offers mobile operators significant capacity and
broadband capabilities to support greater number of voice and data customers plus higher data rates
at lower incremental cost than 2G.
3G/UMTS has been specified as an integrated solution for mobile voice and data with wide area
coverage. 3G/UMTS uses WCDMA (Wideband Code Division Multiple Access) as the radio
access technology. This technology is based on a radio technique with a wideband spread-spectrum
proposed by ETSI Alpha group and its specification was finalized in 1999.While using an
automatic international roaming, 3G/UMTS ads integral security and billing functions, allowing
operators to migrate easily from 2G to 3G.
10.2.2.2 3GPP2
GPP2 is also an organization formed by several partners. They are: the Telecommunications Industry
Association (TIA) of US, the ARIB/TTC of Japan, the TTA of Korea and the China Wireless
Telecommunication Standard Group (CWTS). As also mentioned before, 3GPP2 is developing the
evolution of IS-95 towards CDMA 2000.
IS-95 (Interim Standard 95) is the first Code Division Multiplex Access (CDMA) based digital
cellular standard pioneered by Qualcomm. IS-95 is also known as TIA-EIA-95. [3]
It is a 2G mobile telecommunications standard that uses CDMA a multiple access scheme for
digital radio to send voice, data and signaling data (such as a dialed telephone number) between
mobile phones and cell sites. The transmission is done in streams of bits. CDMA permits several
radios to share the same frequencies and unlike TDMA (Time Division Multiple Access), a
competing system used in GSM, all radios can be active all the time, because network capacity
does not directly limit the number of active radios. Since larger numbers of phones can be served
by smaller numbers of cell-sites, CDMA-based standards have a significant economic advantage
over TDMA-based standards, or the oldest cellular standards that used frequency division
multiplexing.
IS-95 is now being supplanted by IS-2000 (CDMA2000), a later CDMA-based standard. It is
used in the USA, South Korea, Canada, Mexico, India, Israel, Australia, Venezuela and China.
CDMA2000 has already been implemented to several networks and is fully backwards
compatible with IS-95B. CDMA2000 is not constrained to only the IMT-2000 band, but operators
can also overlay a CDMA2000 1x system, which supports 144 kbps now and data rates up to 307
kbps in the future, on top of their existing previous versions of CDMA networks.
73
533576827
02.10.09
04.03.11
The evolution of CDMA2000 1x is labeled CDMA2000 1xEV. 1xEV will be implemented in
steps: 1xEV-DO and 1xEV-DV. 1xEV-DO stands for "1x Evolution Data Only". 1xEV-DV
stands for "1x Evolution Data and Voice". Both 1xEV CDMA2000 evolution steps will use a
standard 1.25 MHz carrier. 1xEV-DO probably will be available for CDMA2000 operators during
2002 and 1xEV-DV solutions will be available approximately late 2003 or early 2004.
CDMA2000 1x EV-DO and CDMA2000 3x are ITU-approved, IMT-2000 (3G) standards.
CDMA2000 3x is part of what the ITU has termed IMT-2000 CDMA MC (Multi Carrier). It uses
less that 5 MHz spectrum (3x 1.25 MHz channels) to give speeds of over 2 Mbps. CDMA2000 1x
with lower data speed is considered to be a 2.5G technology.
3GPP updates a new release of the UMTS standard almost each year, the first one was R99 and then there
were: Rel4, Rel 5, Rel 6, Rel 7, Rel 8, Rel 9 and now is currently working on Rel 10. 3GPP is now
working on Long Term Evolution (LTE), which will build on UMTS, as the industry looks beyond 3G.
ITU-T Recommendation Q.1741.6 “IMT-2000 References to Release 8 of GSM evolved UMTS Core
Network” was prepared by ITU-T SG 19 but uses parts of the 3GPP organization standards.
The Core Network for this IMT-2000 family member referred to as “3GPP Release 6” is based on
evolved Core Network from the 3rd generation release 1999. This core network supports both 2nd and 3rd
generation radio access networks as options.
This Recommendation identifies a release of the IMT-2000 Family Member, “GSM evolved UMTS Core
Network”. This release of the Family Member is known to the Standards Development Organizations
(i.e., ARIB, CCSA, ETSI, ATIS, TTA, and TTC) as the “3GPP Release 6”. Earlier releases, known as
“3GPP Release 99”, “3GPP Release 4”, “3GPP Release 5”, “3GPP Release 6”, “3GPP Release 7” of this
Family Member are specified in the Recommendation Q.1741.1, Q.1741.2, Q.1741.3, Q.1741.4, and
Q.1741.5, respectively, while other IMT-2000 Family Members are specified in other Recommendations
in the Q.174x series.
Previous versions of this Recommendation were called “GSM evolved UMTS Core Network with
UTRAN Access Network” where UTRAN stands for UMTS Terrestrial Radio Access Network.
UTRAN is a wireless access network that can carry many traffic types including Circuit Switched
and IP Packet Switched data flows. UTRAN allows connectivity between the UE (user
equipment) and the core network. As explained above, UMTS uses code division multiple access
(CDMA).
The UTRAN contains the base stations, which are called Node Bs and Radio Network Controllers
(RNC). Nodes Bs are base transceiver stations which uses WCDMA as air transport technology.
The RNC provides control functionalities for one or more Node Bs. A Node B and an RNC can
be the same device, although typical implementations have a separate RNC located in a central
office serving multiple Node B's. Despite the fact that they do not have to be physically separated,
there is a logical interface between them known as the Iub. The RNC and its corresponding Node
Bs are called the Radio Network Subsystem (RNS). There can be more than one RNS present in
an UTRAN.
ITU-T Draft new Recommendation Q.1742.8: IMT-2000 References to ANSI-41 (approved January 31,
2010) evolved Core Network with cdma2000 Access Network has been submitted for consent by ITU-T
SG 13 in July 2010. This Recommendation identifies the IMT-2000 Family Member; “ANSI-41 evolved
74
533576827
02.10.09
04.03.11
Core Network with cdma2000 Access Network.” This set of referenced specifications includes those
3GPP2 specifications that were approved as of 31 January 2010.
The Core Network interfaces identified in this recommendation and the radio interfaces and radio access
network interfaces identified in ITU-R Recommendation M.1457, Specifications of the radio interfaces of
International Mobile Telecommunications-2000 (IMT-2000), constitute a complete system specification
for the 3rd generation mobile system for terrestrial usage of this IMT-2000 Family Member. In the event
that a referenced specification also includes material that specifies any of the radio aspects of this IMT2000 family member, ITU-R Recommendation M.1457, shall take precedence.
*****
75
533576827
02.10.09
04.03.11
11 Transport Standards
Next Generation Networks (NGN) are IP-based networks that are able to provide a wide variety of
services, which can be carried over multiple broadband transport technologies. The main characteristic in
the architecture of NGN is that service-related functions are independent from underlying transportrelated technologies by separating them into two distinct strata: 1) the service stratum and 2) the transport
stratum, as it is explained in ITU-T Recommendation Y.2011, General principles and general reference
model for NGN [1].
11.1 Requirements for Transport Functions
Transport networks should be able to carry any service over IP, whatever technology they are based on.
They provide connectivity for all components and physically separated functions within the NGN.
Transport functions include access network functions, edge functions, core transport functions and
gateway functions. These functions are defined and described in ITU-T Recommendation Y.2012,
Functional Requirements and Architecture of the NGN [2].
1)
2)
3)
4)
The access network functions provide end users’ access to the networks and also collect and
aggregate traffic from/to end users to/from the core network.
The edge functions aggregate traffic coming from different access networks and merge them into
the core transport network. These functions are also present between core transport networks.
The core transport functions should provide QoS mechanisms on user traffic within the core
network.
The gateway functions should provide capabilities to interwork with end-user functions and/or
other networks.
Transport Technologies and their evolution
The services provided by an NGN, can be carried over multiple broadband transport technologies.
IP is a layer 3 technology in the OSI model. It can be transported over layer 2 technologies, such as
Ethernet (MAC layer), MPLS, etc., and these can be carried over layer 1 (physical layer) technologies,
such as Ethernet-PHY, SDH, OTN. IP can also be carried directly over SONET/SDH and OTN, but in
this case, as in the case of MPLS, the transport network will need the help of frame delineating protocols,
such as the Generic Framing Procedure (GFP) [3] or Point-to-Point Protocol (PPP) [4].
11.2 Circuit-switched technologies
Traditional SONET/SDH and OTN (Optical Transport Networks) are L1 (physical) circuit switched
technologies, however, at present these technologies are provided with packet capabilities at the edge of
the circuit transport network.
11.2.1 SONET/SDH
SONET (Synchronous Optical Network) was specified by North American standards bodies in the late
1980s. It was submitted to the international standards bodies as a proposed international standard. After
some negotiation, SDH (Synchronous Digital Hierarchy) emerged as the international standard, of which
SONET can be considered a subset.
The main reason for developing the SONET/SDH standards [5], was to allow the deployment of multivendor optical networks. SONET/SDH has also more comprehensive network management features.
76
533576827
02.10.09
04.03.11
SONET/SDH has been later adapted to transport packet protocols such as IP. The protocol that allows the
transport of packets over SONET/SDH is called Packet over SONET/SDH (PoS); it is highly scalable and
provides legacy support, by interworking with existing SONET/SDH architectures.
11.2.2 Optical Transport Network (OTN)
The Optical Transport Network (OTN), or digital wrapper, is defined and specified in ITU-T
Recommendations G.709 [6] and G.798 [7]. It provides an efficient way to multiplex services onto optical
light paths. OTN can transport side-by-side, synchronous services with different clock sources, and it can
also mix both synchronous and asynchronous signal types on a common wavelength. But, the main
advantage claimed by OTN enthusiasts of OTN over SONET/SDH networks, is service transparency and
multiple monitoring levels. SONET/SDH has only two monitoring levels (at the section and multiplex
levels). NGN are multi-service networks. When they are transported over SONET/SDH, they cannot
access SONET/SDH overhead bytes or the DCC (Data Control Channel) that carries all the management
bytes. A traditional SONET/SDH network, strips out these bytes and breaks the end to end
communication and topology discovery. OTN, instead, has its own separate overhead for performance
monitoring and fault signalling. It also has a General Communication Channel (GCC) for remote
management, software downloads and other control functions.
11.3 Packet-switched technologies
In packet switching technologies such as Ethernet, ATM, MPLS, etc, many users share common physical
resources, so that the infrastructure provided by a carrier can be more efficiently utilized.
11.3.1 Ethernet as NGN transport technology
Ethernet has been the technology of choice for private and enterprise LANs and now multi-protocol
Ethernet services are being offered over public transport networks.
Public Ethernet services, the transport of Ethernet frames and implementation agreements are being
debated in ITU-T, MEF, IEEE and other standards organizations. Specifically, the ITU-T SG15 is focused
on developing Recommendations related to the support and definition of Ethernet services over traditional
telecommunications transport, such as PDH, SDH, and OTN.
11.3.2 Ethernet network topologies
Ethernet network topologies should be in support of the provided services. Ethernet services are being
categorized in three types:



Line services (E-line), which are point-to-point and include Ethernet private and virtual lines.
These services are now being called “Duplex Ethernet”.
LAN services (E-LAN), which are multi-point-to-multi-point (such as virtual LAN services).
Access services (E-tree) are of hub-and-spoke nature and enable single ISP/ASP to serve
multiple, distinct, customers.
The Metro Ethernet Forum (MEF) has been modeling Ethernet service instances called Ethernet Virtual
Circuits (EVCs). The services can be provided with different QoSs. A circuit switched technology, like
SDH, provides always a guaranteed bit rate service, while a packet switched technology, like MPLS, can
provide various service qualities from best effort traffic to a guaranteed bit rate service. Ethernet services
can be provided for the Ethernet MAC layer (L2) or Ethernet physical layer (L1).
77
533576827
02.10.09
04.03.11
The Ethernet MAC layer provides end-to-end transmission of Ethernet MAC frames between Ethernet
end-points of individual services, identified by their MAC addresses. Ethernet MAC layer services can be
provided as Line, LAN and Access services over circuit switched technologies.
11.3.3 Evolution to "Carrier-class" Ethernet
Although Ethernet was originally designed to be used in a LAN environment, it has become widely used
in network operator's backbone or metro area networks. In addition, Ethernet can easily realize
multipoint to multipoint connectivity.
Carrier-class Ethernet is defined by five main attributes:
1) Standardized Services:

E-LINE (Private line, Virtual Private Line); E-LAN (Private LAN and Virtual Private
LAN); E-TREE (Hub and Spoke, work in progress in MEF).

A ubiquitous service providing globally & locally via standardized equipment.

Requires no changes to customer LAN equipment or networks and accommodates existing
network connectivity including time-sensitive, TDM traffic and signaling.
2) Quality of Service

Options of granularity of bandwidth and quality of service.

Meeting requirements of Service Level Agreements (SLAs) for voice, video and data over
converged business and residential networks.

In alignment with SLAs, provide end-to-end performance based on the Committed
Information Rate (CIR), frame loss, delay and delay variation characteristics.
3) Service Management

Provides the ability to monitor, diagnose and centrally manage the network, using
standards-based vendor independent implementations.

Carrier-class OAM

Rapid service provisioning
4) Scalability

The possibility for network service usage by millions since carrier-class Ethernet can
provide for a wide variety of business, information, communications and entertainment
applications with voice, video and data.

Being able to be transported by a wide variety of physical infrastructures implemented by a
wide range of Service Providers.

Scalability of bandwidth from 1 Mbps to 10 Gbps and beyond, in granular increments.
5) Reliability

The ability for the network to detect & recover from faults without impacting users.

Recovery time as low as 50 msecs.
Some of the enhancements that “carrier-class” Ethernet has introduced to Ethernet are:
1) High bit rate and long reach interfaces
Ethernet interfaces up to 10 Gbps and up to 40 km have been standardized by IEEE 802.3
working group (WG). Also, LAN-PHY (10GBASE-R) and WAN-PHY (10GBASE-W) have
been standardized. WAN-PHY can be connected to SONET/SDH interfaces.
2) Ethernet-based access networks
Ethernet capabilities as access networks have been enhanced by IEEE 802.3 WG (IEEE 802.3ah,
defining point-to-point and point-to-multipoint optical transmission methods and link level
Ethernet OAM.
3) Enhancement of scalability
78
533576827
02.10.09
04.03.11
VLAN technology is widely used to provide customers with logically independent networks,
while sharing network resource physically. The use of two VLAN IDs in a frame allows the
network to provide up to 4094 Service VLANs, each of which can accommodate up to 4094
Customer VLANs.
11.3.4 Issues that need to be completed in a “Carrier-class” Ethernet
1) Number of MAC addresses to be learned by bridges
Bridges in a network automatically learn the source MAC addresses of incoming frames, but
when there are many stations, in order to avoid consuming lots of resources of each bridge by the
MAC learning, IEEE 802.1ah [8], Backbone Provider Bridges, is standardizing a method which
encapsulates MAC addresses of user stations by backbone MAC addresses. In this way, bridges
inside the backbone network do not learn MAC addresses of user stations.
2) Network Level OAM
Network level OAM functions are being standardized in question 5 of ITU-T SG 13 and in IEEE
802.1ag [9] in close cooperation, in order to enable network operators manage their networks by
detecting, localizing and, when possible, correcting faults and measuring their network
performance.
3) Fast protection switching
Fast protection switching (ITU-T Recommendation G.8031, [10] was standardized in question 9
of ITU-G SG 15. This survivability technology is added to the existing Link Aggregation and
Rapid Spanning Tree protocol [11].
4) QoS traffic control / traffic conditioning
QoS, traffic control and traffic conditioning issues are being studied by ITU-T (SG12), IEEE
802.3 and the Metro Ethernet Forum (MEF).
11.3.5 Present standards activities on Ethernet
In ITU-T:
ITU-T SG 15 approved the following Recommendations in June, 2006:
1)
2)
3)
G.8001/Y.1354,Terms and definitions for Ethernet frames over Transport (EoT) [12].
G.8031/Y.1342, Ethernet Protection Switching [13].
G.8601/Y.1391, Architecture of service management in multi bearer, multi-carrier environment
[14].
ITU-T SG 13 approved Recommendation Y.1731, OAM Functions and Mechanisms for Ethernet based
networks in May 2006 [15]. Multiple Domain Management is work in progress to be included in next
version of Y.1731.
In IETF:
IETF published RFC 4448, Encapsulation Methods for Transport of Ethernet over MPLS Networks in
April 2006 [16]. This RFC has been discussed in PWE3 Working Group.
IETF L2VPN Working Group is discussing several drafts on Virtual Private LAN Service (VPLS)
In IEEE:
There are two Working and Technical Advisory Groups:
802.1 is the High Level Interface Working Group that standardizes higher layers above the MAC
(including Network level Ethernet OAM) mechanisms, Provider bridges and Provider Backbone bridges).
79
533576827
02.10.09
04.03.11
802.1ag is working on Service OAM flows at multiple levels.
802.3 is the CSMA/CD Working Group that standardizes the MAC and the Physical layer Ethernet,
including Ethernet in the First Mile (this one was completed in 2004).
In MEF:
MEF has defined the different Ethernet services, is working on definition of E-TREE type of service (as
seen above) and also on Multiple Domain Management for Ethernet.
MEF is working on carrier-class Ethernet in its phase 2, MEF services, providing QoS models for
multipoint and definitions of availability.
11.3.6 Similarities and differences between IP and “Carrier-class” Ethernet
Ethernet is a L2 and IP is a L3 technology, however both of them are packet switched technologies, they
scale globally, they both use dynamic topology protocols and both can provide protection, QoS and traffic
engineering. But the differences between them are:
1) Connectivity

IP can provide global any to any connectivity.

Carrier-class Ethernet can provide global connectivity between provisioned sets of network
interfaces.
2) Type of technology

IP is a global network technology.

Carrier-class Ethernet is a global Virtual Private Ethernet multiplexing technology. Each
Virtual Private Ethernet is provisioned by the carrier.
3) Transport networks

In the Enterprise, IP runs over Ethernet networks.

In the Metro, IP will run over carrier-class Ethernet Virtual Private networks.
11.4 Transport MPLS (T-MPLS)
MPLS was originally developed by IETF [17], [18], in order to address core IP router performance
issues, however it has been used widely in carriers' converged IP/MPLS core networks, and as a platform
for services such as IP-VPN.
Transport MPLS (T-MPLS) is being standardized by ITU-T, which has adapted MPLS in order to obtain
a “carrier-class” network. T-MPLS is purely connection-oriented packet transport network based on
MPLS. It provides managed point to point connections to different client layer networks. It does not
support connectionless packet technologies.
T-MPLS is packet-based transport technology but it follows the same architectural, management and
operational models than the classical circuit-based transport networks. T-MPLS is intended to provide an
optimum evolution path for many carriers in their metro and access networks, as they transition to a
packet-based future.
T-MPLS is being offered as a possible solution to carriers concerns about strategy development for NGN
evolution and PSTN replacements. It also considers scalability and management and reduction of OPEX.
T-MPLS supports point-to-point and multi-point to multi-point Ethernet services. Discussions on TMPLS are taking place in ITU-T, MEF, IEEE and IETF.
80
533576827
02.10.09
04.03.11
11.4.1 Standards landscape for MPLS-T
In ITU-T
MPLS-T is being developed in SG 15:
ITU-T Recommendation G.8101/Y.1355, Terms and Definitions for Transport MPLS [19], was approved
in December 2006, and Recommendation G.8131, Protection switching for Transport MPLS networks
[20], has just been approved in February 2007.
ITU-T Recommendations G.8110.1/Y.1370.1, Architecture of Transport MPLS (T-MPLS) Layer Network
[21] was approved in November 2006; G.8112/Y.1371, Interfaces for the Transport MPLS (T-MPLS)
Hierarchy [22], in October 2006, and G.8121, Characteristics of multi-protocol label switched (MPLS)
equipment functional blocks [23]; was approved in March 2006.
In IETF:
The T-MPLS concept was first developed in PWE3 working group. This concept is known as
pseudowires in IETF. RFC 3985, The Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture [24]
was approved in March 2005.
All T-MPLS related work is being carried out at the PWE3 working group.
CONCLUSIONS
At present the preferred NGN transport technology seems to be Carrier-Grade Ethernet, however, it is not
yet possible to consider it as the technology of choice to transport NGN services, as the Management of
Ethernet networks and services is still under development. The management of networks and services is
key to provide NGN services as these ones are mainly distinguished based on their QoS.
T-MPLS is still under development but, so far, this technology does not seem to offer any special benefit,
as it is mainly focused on the transport of Ethernet services. This means that if T-MPLS is used as a
transport network, Ethernet will need to run over it to transport NGN services.
SONET/SDH, OTN and/or Physical layer Ethernet will be the physical layer technologies over which any
chosen transport technology for NGN, will be transported.
REFERENCES
[1] ITU-T Recommendation Y.2011, General principles and general reference model for Next
Generation Networks (2004).
[2] ITU-T Draft Recommendation Y.2012, Functional Requirements and Architecture of the NGN
(formerly Y.NGN-FRA) version 0.8, July 2006.
[3] ITU-T Recommendation G.7041, Generic Framing Procedure (GFP), Aug. 2005.
[4] IETF RFC 1661, Point-to-Point Protocol, July 1994.
[5] ITU-T Recommendation G.707, Network Node Interface for the Synchronous Digital Hierarchy
(SDH), December, 2003.
[6] ITU-T Recommendation G.709, Interfaces for the Optical Transport Network (OTN), March, 2003.
[7] ITU-T Recommendation G.798, Characteristics of Optical Transport Network Hierarchy
Equipment Functional Blocks, June 2004.
[8] IEEE PAR approved, draft 3.3 of standard 802.1ah, Provider Backbone Bridges, Dec 2006.
[9] IEEE PAR approved, draft 7.1 of standard 802.1ag, Connectivity Fault Management, Dec. 2006.
[10] ITU-T Recommendation G.8031, Ethernet Protection Switching, pre-published, June 2006.
81
533576827
02.10.09
04.03.11
[11] IEEE supplement 802.1w, Rapid Reconfiguration of Spanning Tree, incorporated to 802.1D, MAC
Bridges, 2004.
[12] ITU-T Recommendation G.8001/Y.1354, Terms and definitions for Ethernet frames over Transport
(EoT), June 2006
[13] ITU-T Recommendation G.8031/Y.1342, Ethernet Protection Switching, June 2006.
[14] ITU-T Recommendation G.8601/Y.1391, Architecture of service management in multi bearer,
multi-carrier environment, June 2006
[15] ITU-T Recommendation Y.1731, OAM Functions and Mechanisms for Ethernet based networks,
May 2006.
[16] IETF RFC 4448, Encapsulation Methods for Transport of Ethernet over MPLS Networks, April
2006.
[17] IETF RFC 3031, Multiprotocol Label Switching Architecture, January 2001.
[18] IETF RFC 3032, MPLS Label Stack Encoding, January 2001.
[19] ITU-T Recommendation G.8101/Y.1355,Terms and Definitions for Transport MPLS, Dec. 2006.
[20] ITU-T Recommendation G.8131/Y.1382, Linear protection switching for Transport MPLS (TMPLS) networks, Feb. 2007.
[21] ITU-T Recommendations G.8110.1/Y.1370.1, Architecture of Transport MPLS (T-MPLS) Layer
Network, November 2006.
[22] ITU-T Recommendation G.8112/Y.1371, Interfaces for the Transport MPLS (T-MPLS) Hierarchy,
October 2006.
[23] ITU-T Recommendation G.8121/Y.1381, Characteristics of multi-protocol label switched (MPLS)
equipment functional blocks, March 2006.
[24] IETF RFC 3985, The Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture, March 2005.
[Ref: P1!T-966_i.doc; 2007-03]
82
533576827
02.10.09
04.03.11
12 Management Standards
12.1 ITU-T SG 4
ITU-T SG 4 has published a roadmap identifying NGN management specifications. This roadmap
provides an insight into how NGN management will differ from the management of traditional
telecommunication. The NGN Management Specification Roadmap is an output of the NGN
Management Focus Group, a group sponsored by ITU-T SG 4.
The document identifies the various existing, or work-in-progress specifications relevant to NGN
management. These specifications are not only ITU-T Recommendations, but also they come from other
standards development bodies with expertise in defining management interfaces. For example, the
roadmap tags the 3GPP (3rd Generation Partnership Project) specs for mobile telephony relevant to the
IMS (IP Multimedia Subsystem) management. An additional and important feature of the document is
that it provides gap analysis, identifying areas where standards are still needed, and also identifies
overlapping specifications requiring harmonization.
As NGN is expected to provide a wide variety of services with different QoS, it is essential for these
networks to have effective Network Management for networks and services. Network Management
includes:

Operation and Management (OAM) mechanisms.
These mechanisms allow to diagnose, monitor and measure impairments and the performance of
networks and network elements (NEs) by using “horizontal” or East-West (between NEs)
management information that follows the same path as the traffic information. This information
results from specific OAM requirements.

NGN Management related to FCAPS interfaces.
FCAPS is the abbreviation for Fault, Configuration, Accounting, Performance and Security and,
although in ITU-T terminology, FCAPS interfaces generally mean the “vertical” or North-South
interfaces (NE to OS interfaces), and the interfaces between Operation Systems (OSs). This name
is somehow misleading as the OAM functionality also provides information that is related to
FCAPS. On the other hand, outside ITU-T the acronym FCAPS has different meanings. As a
consequence, ITU-T has agreed, in its document called Terms of Reference v4.0 [1] of the NGN
Management Focus Group, to call “management interfaces” to the ones that go from the Network
Element (NE) to the Operation System (OS) or between different OSs.
12.1.1 NGN Network Management Focus Group
The NGNMFG establishment was confirmed by SG 4 in February 2005 and re-confirmed in September
2005 and in May 2006. NGNMFG completed its activities in May 2008. The NGNMFG activities are
part of the ITU-T NGN-GSI (NGN Global Standards Initiative).
The general objective of the NGNMFG was to develop a solution for the management of NGN services
and networks. This solution is a set of interoperable specifications, defining the management interface
capabilities needed to support the ITU-T (including NGN-GSI) objectives for NGN Release 1. The
solution is documented in the NGN Management Specification Roadmap [2].
[1] NGN Management Focus Group, Terms of Reference v.4.0.
[2] NGN Management Focus Group, NGN Management Specification Roadmap v2.1, May 2006.
83
533576827
02.10.09
04.03.11
12.2 IETF
12.2.1 Simple Network Management Protocol (SNMP)
The Simple Network Management Protocol (SNMP) consists of a simply composed set of network
communication specifications that cover all the basics of network management in a method that poses
little stress on an existing network.
The largest advantage of using SNMP is that its design is simple, hence it is easy to implement on +a
large network, for it neither takes a long time to set up nor poses a lot of stress on the network. SNMP
provides for effective monitoring and control of heterogeneous devices on both local and wide area
networks. The protocol is composed of 3 elements: the MIB, the manager, and the agent. IETF RFC 3410
(Informational) describes the SNMPv3.
12.2.2 NETCONF Configuration Protocol
The IETF Network Configuration (netconf) Working Group is developing the NETCONF configuration
protocol that provides mechanisms to install, manipulate, and delete the configuration of network devices.
It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as
the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote
Procedure Call (RPC) layer.
*****
84
533576827
02.10.09
04.03.11
13 Service Creation Standards
13.1 Intelligent Network Capability Set (IN CS-4)
The ITU-T IN Capability Set 4 (IN CS-4), [5] represents an evolution from IN CS-3 (1997) and IN CS-3
(2000). The ITU-T IN CS- 4 Recommendations (Q.124x series) were frozen in December 2000 and got
consent approval (second stage of the approval under the traditional approval process) in May 2001.
IN CS-4 specifically related recommendations are:
 Q.1241, Introduction to Intelligent Network Capability Set-4;
 Q.1244, Distributed functional plane for intelligent network capability set-4; and
 Q.1248, Interface Specifications for Capability Set-4.
Key features identified for IN CS-4 include enhancements to IN CS-2 and IN CS-3 capabilities, multiple
points of control, feature interaction, IN-ISDN interworking (including supplementary services), number
portability, support for operator services (e.g., prepaid, freephone), support for mobility (e.g., Virtual
Home Environment), interworking with private networks, and support for IP networks.
In particular, IN CS-4 support for IP networks includes many aspects of interworking between IP network
services/applications and Intelligent Network services/ features. This includes full support for accessing
IN from a SIP Proxy for implementing services that do not require explicit handling of the call
configuration, full support for inter-working IN with Call Servers, based on the H.248 architecture for all
types of services, and minimal support for accessing IN from H.323 Gatekeepers/SIP Proxy Server for
implementing services that do not require explicit handling of the call configuration.
Draft Recommendation Q.1244 describes in detail the distributed functional architecture for IN CS-4.
The functional model for IN CS-4 is an extension of the IN CS-2 model, supporting the benchmark
services discussed above. A large portion of Q.1244 addresses IN/IP interworking scenarios for a variety
of systems including SIP systems, H.323 systems, PINT-based systems, SPIRITS-based systems.
Distributed Service Logic Servers are also supported via standard API-based platforms (e.g., CORBA,
JAIN). For each set of interworking scenarios functional entities are defined, functional models are
created, requirements are listed, and issues affecting implementation are discussed.
As an example of these scenarios, the functional architecture defined for IN/IP interworking to support
SIP (Session Initiation Protocol) systems is shown below:
85
533576827
02.10.09
04.03.11
Intelligent Network
IP Network
SDF
Signalling
Transport
Gateway
Service/Application
Layer
SCF
IF4
Intelligent
SIP Proxy and
Bearer Controller
IF7
SRF
SSF
CCF
IF5
SSF
IF13
IF10
Call/Bearer
Layer
SIP
SM
CCF
SIP
TE UA
IF12
MG
RTP/RTCP
Media Gateway
Legend:
IF4: INAP
Signalling
Service Control
Bearer
IF5: ISUP/BICC/SIP
IF7: Extended INAP
IF10: ISUP User Plane
IF13: H.ISUP Use plane
IF12: H.248/H.225 (ffs)
A SIP based call control configuration using an intelligent SIP Proxy and Bearer Control
Function
Each interface between an IN network and IP-based network functional entity is defined with specific
properties. Once these generic relationships are defined, specific services interworking between networks
can be defined.
To illustrate service interworking, it is instructive to look at the PINT and SPIRITS model. Functional
entities are introduced to support PSTN/IN Interworking (PINT) and for a Service in the PSTN/IN
Requesting InTernet Service (SPIRITS). The IETF PINT Working Group has developed a set of protocol
extensions based on the Session Initiation and Session Description Protocols (SIP and SDP).
A PINT server accepts PINT requests from PINT clients. It processes the requests and returns responses
to the clients. Additionally, this function transfers data between IP-networks and the IN, and associates
IP-network entities with the related entities in the gateway function. This function is situated at the edge
of the IP-network domain, where the Application Association with the PINT Client/Server is the subject
of standardization of the IETF and the Application Association with SCF in the IN domain is the subject
of standardization in the ITU-T.
The IETF SPIRITS Working Group defines services originating in the PSTN and requiring interactions
between the PSTN and an IP network. This work is closely associated with PINT. To support these
services (e.g., Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding), the
following functional model was created:
86
533576827
02.10.09
04.03.11
Intelligent Network
IP Network
SDF
IF17
SPIRITS
Proxy
IF16
SPIRITS
Client
Service/Application
Layer
IF1
IF15
SPIRITS
Server
PINT
Client
PINT
Server
PINT
Gateway
IF3
SCF
IF2
IF4
SRF
Call/Bearer
Layer
SSF
CCF
Legend:
Management
Signalling
Bearer
PINT/SPIRITS Example Configuration
Support for third-party application development is a key component of next-generation networks and an
important aspect of IN CS-4. Support for distributed logic servers requires the creation of the Service
Application Gateway Function. This allows inter-working:
(1)
(2)
between the service control layer in Intelligent and Distributed Service Logic applications.
[These are Application Programming Interface (API)-based functions], and
between the Call Manager Function and Distributed Service Logic.
For IN CS-4, on the application level, the types of API based functionality may include: CORBA
platforms, JAVA platforms, JAIN platforms, and other API based platforms. Additionally this
functionality may provide protocol mapping/service mediation. Given the Interface between the “API for
accessing Service Provider Applications” and the IP call control the following network architecture
depicts the distribution of network intelligence.
The Gateway Function (GF) will provide
firewall/security functions necessary for the distributed service logic platform.
87
533576827
02.10.09
04.03.11
Intelligent Network
IP Network
IF9
SA GF
GF
Distributed
Service Logic
IF8
Service/Application
Layer
IF9
SCF
SA GF
SSF
Call/Bearer
Layer
Legend:
CCF
CCF
Management
Signalling
Bearer
SA-GF implementation for distributed service logic support
*****
88
533576827
02.10.09
04.03.11
14 Security Standards
To secure information in a network [11] there are three critical components that need to be considered.
Authentication validates the identity of the party or parties participating in the exchange of information.
Confidentiality protects against eavesdropping or monitoring of the information exchange. Integrity
assures that the information has not been altered during transmission. The nature of IP makes it difficult
to verify where the information comes from, and easy for an attacker to take advantage of this weakness
by spoofing the IP address. Spoofing occurs when an attacker changes the source address in the IP packet.
Determining where the attack is coming from is very difficult as the attacker keeps changing the source
address.
The importance of security is recognized by both the IETF and the ITU-T. There is a need to further
understand all of the issues and implications. To address the Security problem, the IEFT created the
Security Area and further subdivided the area into working groups. The ITU-T SG 17 (Data Networks
and Telecommunication Software) has a security study group that targets security issues at all levels. The
role of each organization is somewhat different. The IETF Security Area Advisory Group primary role is
to provide help to IETF working groups on how to provide for security in the protocols they design. On
the other hand, the ITU-T is focusing on the need for a global approach to the dissemination of
information regarding the security of critical network infrastructures and ways to stimulate international
or regional cooperation with respect to critical network infrastructure.
14.1 IP Security (IPSec)
IPSec refers to a suite of IETF security protocols, RFC 4301 (Proposed Standard), that protect Internet
communications through encryption, authentication, confidentiality, data integrity, anti-replay protection,
and protection against traffic flow analysis. IPSec supports popular encryption methods at the network
layer—such as Diffie-Hellman, DES, 3DES, MD5, and SHA1—and can adapt to new algorithms and
standards as they emerge. The protocol suite provides the five components described below.
14.1.1 Security Associations (SAs)
The function of the SAs is to provide a method for two parties to exchange secure data while both parties
need to agree on the security parameters. "SAs" are defined for one-way traffic only, therefore for bidirectional traffic requires two "SAs" to be defined. The IPSec SA specifies the following parameters:
 AH authentication mode (Algorithm and Keys)
 ESP Encryption Algorithm
 How to exchange Keys
 How often the Keys are changed
 SA Lifetime
 SA source address
14.1.2 Authentication Header (AH)
AH, defined in IEFT RFC 2402 (Proposed Standard) lets parties communicating using IP to verify that
the data was not modified during transmission and that it comes from the original source of the
information. The AH provides connectionless data integrity, data authentication and protects against
replay attacks. The AH adds a block of code to the data packet that is the result of a “hash” function
applied to the entire packet. There are 2 fields in the AH header that are important:

Security parameter Index (SPI) specifies to the receiving device what group of security protocols the
sender is using.
89
533576827
02.10.09
04.03.11

Sequence Number is used to prevent replay attacks by preventing the reprocessing of a packet
multiple times.
The Authenticator Field on the AH is only 96-bits long. The “sender” runs the “hash” functions, truncates
the resulting number to fit in to the AH Authenticator field, and sends it off. On the other side, the
receiver runs the same “hash” algorithm (as specified in the SPI) on the packet and truncates the resulting
number accordingly. The receiver then compares both numbers. If they match it means that the number
in the packet, has not being altered. The 2 most widely used AH “hash” algorithms are, Message Digest 5
(MD5) defined by IETF RFC 2403 (Proposed Standard) produces a 128-bit authenticator and Secure
Hashing Algorithm (SHA-1) defined by RFC 2404 (Standard) produces a 160-bit authenticator. The AH
does not keep the data confidential, and is meant for occasions when “ONLY” authentication is needed.
14.1.3 Encapsulation Security Payload (ESP)
ESP, defined in IETF RFC 4303 (Proposed Standard), encrypts the information to prevent monitoring by
a non-trusted entity. ESP can also be used for authentication. The ESP authentication field contains the
cryptographic checksum that is computed over the remaining part of the ESP (minus the ESP
authentication field itself). AH authentication differs from the ESP’s version in that the ESP
authentication does not protect the IP header that precedes the ESP header.
The ESP authentication can be used instead of the AH to reduce the packet processing as it performs one
“transform” operation instead of two steps. It also prevents replay attacks by keeping track of the
sequence number much like AH does, however this would compromise the validity of the header. There
are two types of tunnel mode in both, the original IP header information is encrypted; the down side is
that this does not work across NAT (Network Address Translation). In the transport mode the original IP
header is not encrypted and it may work across NAT.
ESP most widely used encryption schemes are:
 Data-Encryption Standard (DES) uses a 56-bit encryption IETF RFC 2405 (Proposed Standard)
 Triple DES (3DES) uses 168-bit encryption by passing the data through the DES algorithm 3 times
IETF RFC 2405
14.1.4 Key Management
The two most commonly used methods for key exchange are manual keying, which is suitable for a small
number of sites; and Key Exchange by a protocol defined by IETF RFC 4306 (Proposed Standard)
“Internet Key Exchange (IKE)”. “IKE” is the combination of “ISAKMP” and “Oakley”, the “Internet
Security Association and Key Management Protocol (ISAKMP)” defined by IETF RFC 4306 (Proposed
Standard) provides the framework for authentication and key exchange, and the Oakley protocol defined
by IETF RFC 2412 (Informational) describes various modes of key exchange.
14.1.5 Manual Key Exchange
Manual exchange is the easiest form of key management for a small number of sites. Both side of the
IPSec tunnel must be configured manually with the appropriate keys. However there are many
disadvantages with manual keying:
 Manual intervention is needed to update or change the keys.
 Since manual changing of keys is normally infrequent, the attacker has more time to crack the key and
to decrypt data.
 There is a chance of error in configuration since the same key needs to be configured on the two
different endpoints of the IPSec tunnel.
90
533576827
02.10.09
04.03.11


If the person with access to the keys leaves or becomes untrustworthy, lengthy configuration changes
need to take place.
The keys in the configuration need to be protected in some manner from outside attack.
14.2 Internet Key Exchange (IKE)
“IKE” is defined in IETF RFC 4306 (Proposed Standard), and designed to provide four basic capabilities.
 A method for parties to agree on which protocols, algorithms and which keys to use,
 Assurances from the beginning of the exchange of the identity of the parties,
 Management of the keys,
 Assurance that key exchange is handled safely.
“IKE” operates in two phases; in phase one, peers establish secure channels for performing key
operations and negotiate general purpose “SAs” in phase two. There are three modes of exchanging
keying information. The “Main Mode” establishes a secure channel with identity protection in phase one;
the “Aggressive Mode” establishes a secure channel without identity protection in phase one; and the
“Quick Mode” just negotiates general purpose “SAs” in phase two.
14.2.1 Main Mode
The “Main Mode” provides a method for establishing the first phase of “IKE SA” which is used to
negotiate future communication, in the first exchange the two parties agree on basic algorithm and hashes,
in the second they exchange public keys for a “Diffie-Hellman” exchange and pass each other “nonce”.
Nonce is a random number used by either party for verification purposes, or for adding randomness to a
cryptographic key exchange. In “IKE” exchanges, one communicating party sends a “nonce” to the other
party, which must be signed off with a digital signature by the other communicating party and send back
to verify their identity.
14.2.2 Aggressive Mode
In “Aggressive Mode” the proposing party generates a “Diffie-Hellman” pair at the beginning of the
exchange proposing an “SA” and passing the “Diffie-Hellman” public value, then sending a “nonce” for
the other party to sign, and sending an ID packet which the responder can use to check the identity with a
third party. The responder then sends back all the information needed to complete the exchange. The end
result is that it accomplishes the same as the main mode but with out identity protection for the
communicating parties.
14.2.3 Quick Mode
“Quick Mode” is used once the two communicating parties have established an “IKE SA” using
“Aggressive Mode” or “Main Mode”. The main purpose of “Quick Mode” is to negotiate general-purpose
“IPSec” services and the generation of fresh keys. “Quick Mode” works inside a secure tunnel and is less
complex because all packets are encrypted starting with a hash payload composed of an agreed PRF
(Pseudo Random Function) and the derived authentication key for the “IKE SA”. The hash payload is
used to authenticate the rest of the packet. Key refreshing can be done by exchanging “nonces” through
the secure channel and use it to hash the new keys; or to request an additional “Diffie-Hellman” exchange
through the existing secure channel (SA) and change the key over the newly created secure channel.
14.3 Security Architecture for Systems Providing End-to-End Communications
ITU-T Recommendation X.805, “Security Architecture for Systems Providing End-to-End
Communications”, defines a network security architecture for providing end-to-end network security.
This architecture can be applied to various kinds of networks where the end-to-end security is a concern
91
533576827
02.10.09
04.03.11
and is independent of the network’s underlying technology. This Recommendation defines the general
security-related architectural elements that are necessary for providing end-to-end security. The objective
of this Recommendation is to serve as a foundation for developing more detailed recommendations for
the end-to-end network security.
This security architecture was created to address the global security challenges of service providers,
enterprises, and consumers and is applicable to wireless, optical and wire-line voice, data and converged
networks. The architecture addresses security concerns for the management, control, and use of network
infrastructure, services and applications. It provides a comprehensive, top-down, end-to-end perspective
of network security and can be applied to network elements, services, and applications in order to detect,
predict, and correct security vulnerabilities.
The security architecture logically divides a complex set of end-to-end network security-related features
into separate architectural components. This separation allows for a systematic approach to end-to-end
security that can be used for planning of new security solutions as well as for assessing the security of the
existing networks. Three architectural components are addressed: security dimensions, security layers
and security planes.
14.3.1 Security Dimensions
A security dimension is a set of security measures designed to address a particular aspect of the network
security. This Recommendation X.805 identifies eight such sets that protect against all major security
threats. The security dimensions are:
1. Access control
2. Authentication
3. Non-repudiation
4. Data confidentiality
5. Communication security
6. Data integrity
7. Availability
8. Privacy
14.3.2 Security Layers
In order to provide an end-to-end security solution, the security dimensions must be applied to a hierarchy
of network equipment and facility groupings, which are referred to as security layers. Recommendation
X.805 defines three security layers:
1. Infrastructure Security Layer
2. Services Security Layer
3. Applications Security Layer
The security layers are a series of enablers for secure network solutions: the infrastructure layer enables
the services layer and the services layer enables the applications layer. The security layers identify where
security must be addressed in products and solutions by providing a sequential perspective of network
security.
14.3.3 Security Planes
A security plane is a certain type of network activity protected by security dimensions. Recommendation
X.805 defines three security planes to represent the three types of protected activities that take place on a
network. The security planes are:
92
533576827
02.10.09
04.03.11
1. Management Plane
2. Control Plane
3. End-User Plane
These security planes address specific security needs associated with network management activities,
network control or signaling activities, and end-user activities correspondingly.
Rec. X.805 summarizes the dimensions of the security architecture with the following figure:
End-user plane
Control plane
THREATS
Privacy
Destruction
Availability
Data integrity
Communication security
Infrastructure security
Non-repudiation
VULNERABILITIES
Data confidentiality
Access control
Services security
Authentication
Security layers
Applications security
Corruption
Removal
Disclosure
Interruption
ATTACKS
8 Security dimensions
Management plane
X.805_F3
X.805 – Security architecture for end-to-end network security
The security architecture described in Rec. X.805 can be used to guide the development of comprehensive
security policy definitions, incident response and recovery plans, and technology architectures by taking
into account each security dimension at each security layer and plane during the definition and planning
phase. The security architecture can also be used as the basis of a security assessment that would examine
how the implementation of the security program addresses the security dimensions, layers and planes as
policies and procedures are rolled out and technology is deployed.
*****
93
533576827
02.10.09
04.03.11
15 QoS and Performance Standards
One of the biggest challenges for a Next Generation Network (NGN) is to provide a system or technique
for Voice over IP (VoIP) that provides performance and quality of service (QoS) that are better than those
provided by the present “best-effort” IP-based networks. For VoIP, the target is to provide service
quality, which is equivalent to that of the current Public Switched Telephone Network (PSTN).
NGNs have two flavours; one is ATM-centric while the other is IP-centric. Although both impose needs
on a core network, the particular focus of this contribution is on the IP offering for NGNs. It is possible
(and likely) that ultimately both flavours will converge at some future point in time, especially with
respect to the core network.
The IP-based architecture of NGNs can be sub-divided into a number of domains. This segmentation
facilitates QoS conceptualization, strategic planning, and functional partitioning that networks are
typically built upon. The following domains are part of an NGN IP architecture:

Centralized Control:
this contains the Media Gateway Controller along with some centralized (for maintenance
reasons) service nodes and OAM elements;

Media Gateway / Endpoints / Access:
this contains the various gateways used to access the IP network;

IP Aggregation:
this contains the devices used to combine flows and physical interfaces into a manageable number
of interfaces or nodes along with any partitioning or boundary (i.e. firewalling, central-office
LAN support);

IP Core Network / Interconnection:
this contains devices used to carry IP traffic across the network and along with interconnection of
domains / networks.
An NGN IP solution contains basically two offers; one that contains "line side" subscribers and one that
contains "trunking only" clients. From a core IP network perspective, there is relatively little difference
between the two. However, from the perspective of end-to-end QoS, it is important to maintain an
awareness of the differing requirements that the two offerings place on the network and its individual
components.
It should be noted that this section focuses on same-service-operator domains only. Interworking across
multiple domains (i.e., involving different operators) at an IP level is not being addressed at this time –
and so border (or boundary) nodes are not considered. It is likely that such nodes would have some
special requirements with respect to QoS, and the matter should be deferred for future study. Moreover,
this section is intended to describe QoS options for IP-centric NGNs. Other options for achieving Quality
of Service in data networks do exist, most notably based on ATM; however, consideration of such
alternative solutions is left for future study.
15.1 QoS in IP-based Networks
15.1.1 Achieving Traditional PSTN Service Quality in IP Networks
First, it should be noted that the PSTN is a network that effectively carries a variety of services in addition
to a simple “voice” service. Indeed, the traditional PSTN provides not only the basic service that
everyone uses for basic voice communication with another human but also a set of "in-band" ancillary
services that are typically used for non-human communication (e.g., FAX, dial-access modems, digital
tones, etc). Most of these "in-band" services rely heavily on the inherent basic voice characteristics of the
94
533576827
02.10.09
04.03.11
Time-Division-Multiplexed PSTN to achieve a successful quality of service. These characteristics
typically relate to bandwidth, frequency, propagation, modulation techniques and harmonics among other
things.
When providing voice over an IP transport network, operators can use high-rate codecs (e.g., ITU-T
G.711) provided there is limited delay and jitter within and around the connecting IP network – in order
to ensure that customers will receive PSTN-equivalent quality.
However, because the chances of achieving comparable delay and jitter conditions over the general IP
network (i.e., Internet) are quite small, various standards and alternative mechanisms have been proposed
to better accommodate these types of services when a number of voice and data services are being carried
together. Typically, these mechanisms involve using selected lower-rate voice codecs together with
techniques for converting bit/bytes to equivalent ASCII information streams and sending the converted
information as "out-band" or parallel IP data flows. For instance, FAX transmissions are converted at
gateways and sent as ASCII data streams over an IP network to the far end gateway which converts the
information back to FAX modem tones for final reception by the end terminal FAX modem. Other
similar techniques have been proposed for various tones (e.g., DTMF, MF) that normally traverse the
TDM PSTN utilizing the "voice band" of the voice service. It is likely that an NGN IP will need to
support both "in-band" and "out of band" techniques.
15.1.2 VoIP Service Characteristics and Expectations
In general, the VoIP service can be broken down into three components of data flows:
 the bearer/voice packets (normally carried as RTP packets),
 signalling/control (these may include H.323, H.248, SIP, SIP-T, BICC), and
 OAM (these include among others, SNMP, TFTP, COPS).
Note that RTCP packet flows are currently not used but need consideration in future evolutionary work.
When dealing with QoS for voice service, the focus tends to be on the bearer stream since this is
typically, what will directly impact a subscriber (and more specifically his perception of the voice
quality). The other components are equally important with respect to the overall QoS of the service.
Without adequate QoS for signalling/control, calls may fail to setup or take significant time to setup.
Similarly, from an operational point of view, without QoS for OAM, provisioning may fail or be
significantly delayed, network failures may go undetected, proactive maintenance may not be possible,
etc. All of these could ultimately be reflected in the subscriber's perception of the quality of the service
being offered.
Moreover, not all of these service components have the same QoS requirements and thus it is likely that
each has a different data service need. This would appear to fit nicely into the "Differentiated Services"
paradigm as laid out by the IP Diff-Serv framework, IETF RFC 2475 (Informational). Thus, the
recommended approach is to understand the key characteristics of each component and to determine in
quantitative terms the performance levels that can be provided by the underlying IP Diff-Serv framework.
However, to complicate this a bit, end-user "expectations" (more precisely, the "changing expectations"
of users) blur things so that the characteristics are not necessarily static or readily quantifiable for all users
and service providers. Unlike the ubiquitous and mature PSTN voice service, which in general offers a
constant (and somewhat singular) quality of service, the IP network and resulting VoIP service
fortunately has the capability of being more flexibly managed.
95
533576827
02.10.09
04.03.11
In addition, performance regulations play an important role, insofar as they express the “ultimate public
expectation” or formal user requirements. Some of them that ultimately relate to quality of the voice
service, including signaling aspects, are listed below. Additional targets can be derived or have been
recommended by various standards/regulatory bodies.
- Dial Tone Delay: no more than 1.5% of calls (during busy hour) shall receive dial tone delay
longer than 3 seconds
- Echo Return Loss (line): greater than 20 dB
- Loss: 3.0 dB at subscriber line (0 dB transmission level)
- Noise: less than 20 dBrnC (trunk level) and less than 23 dBrnC (95% of lines)
- Delay:
- for national - less than 150 ms one way,
- for international involving satellite connection - less than 400 ms one way,
- for submarine cable - less than 170 ms one-way.
- Post Dial Delay: nominally,
- for local calls - less than 3 s,
- for toll calls - less than 5 s,
- for international calls - less than 8 s
- Blocking/Matching Loss: network - 2% during average busy hour
- Service Availability:: 99.999%
Note: the above contain "thumb nail" views of some targets and are included here simply as an
illustration. Details in specific situations should be obtained from the various applicable standards.
By looking at the above targets, it can be seen that QoS attributes for each of the "components" are not
always specifically identified. However, they can be derived or implied. For instance, the Post Dial
Delay (i.e., time passed since the receipt of the last dialed digit until the far end party is notified) provides
for a timing limit by which control messages are processed and propagated through a network to set up a
connection between parties. Thus, this is an implied limit on the delay QoS that control messages can be
expected to encounter as they traverse the IP network. Note that this is not an absolute value that is
totally reflected in the QoS of the IP transport network, because it also includes processing times at
various end points and nodes along the way.
Similar interpretations exist for those targets that impact the characteristics of the bearer traffic. The EModel (ITU-T Recommendation G.107) is used to characterize the voice bearer packet "interpretations".
In general, voice characteristics (what you hear on your phone) are impacted by a number of influences
when a packet network is involved in the speech "path". The figure below provides a view of these
impairments for a DSL access network example.
96
533576827
02.10.09
04.03.11
Voice Impairments in an IP network
From the above figure, it can be seen that determining the expected voice quality of a VoIP call can be
quite difficult from inspection of specific, individual values. In addition, other influences outside of the
IP domain also have an impact. Hence, the E-model serves as an analytical role for being able to combine
all these and produce expected results of theoretical quality of the voice speech. When compared with
existing PSTN instantiations, one is able to determine a relative level of quality.
15.1.3 Strategy for QoS in IP-based Networks
The basic strategy for addressing QoS in next-generation IP-based networks must be simple and
consistent and yet be able to meet the needs of a wide range of services and business models.
However, even the relatively simple voice service is a complex service that contains or needs various
supporting data components to be successful. In addition to the bearer data (based on Real Time Protocol
(RTP) packets); there are signalling / control packets (e.g., H.248, SIP-T) and OAM flows / packets. If all
of these parameters are marked and treated the same way, it is likely that they would "conspire" amongst
themselves to cause a conflict such that the VoIP service quality would not be acceptable.
Similarly, if they are not melded together to form a managed functional service, a similar outcome is
probable to happen (i.e., unacceptable service quality). In addition to these "internal service conflicts",
there is the need for the VoIP service to co-exist with other services that are supported by the same
unified managed IP network. The IETF has proposed that QoS be supported by an IP Traffic Engineering
(IP TE) system. This system enables all services and the managed network to operate and exist together.
General guidelines for an IP TE system have been produced by the IETF Internet Traffic Engineering
(tewg) working group.
15.1.4 Technologies supporting QoS in IP Networks
15.1.4.1 Integrated Services (Int-Serv)
Int-Serv, IETF RFC 1633 (Informational), provides a signaling method and network soft states for
reservation of network resources. It can potentially provide hard QoS guarantees through the reservation
97
533576827
02.10.09
04.03.11
of resources. In Int-Serv, the applications explicitly signal their QoS requirements for a flow using the
Resource Reservation Signalling Protocol (RSVP). Each Router along the route reviews this request and
provides a pinned downed end-to-end path for that transaction (flow); routers along this path check the
RSVP QoS request against the applicable policy and available network resources. If the request is within
policy and resources are available, the request is granted; resources are then reserved by intervening
nodes for the duration of the transaction.
Though quite mature in terms of its specification, Int-Serv has never been deployed on a wide scale due to
perceived drawbacks in a number of areas: scalability, overhead, route pinning, and host orientation.
15.1.4.2 Differentiated Services (Diff-Serv)
Diff-Serv, (IETF RFC 2474 (Proposed Standard) and RFC 2475 (Informational), takes a more pragmatic
approach and provides only soft guarantees by marking packets or flows for relative forwarding priority.
Scalability problems are resolved by avoiding any form of resource reservation in the network.
In addition, the Diff-Serv method is further premised on the fact that the underlying IP network is routed
as this recommendations deal primarily with layer 3 of the communications protocol model. To
complement this capability, the overall QoS strategy may be re-enforced with layer 2 capabilities (e.g.,
IEEE 802.1p, DOCSIS 1.0 / 1.1) that may apply to sub-network domains within the greater NGN IP
network.
In the Diff-Serv method, complicated functionality is moved to the edge of the network and simple
functionality in the core operates on traffic aggregates. Edge devices classify and mark packets in the DS
field of packet header (based on policy information provided by policy management), and core devices
forward packets with certain Per Hop Behaviour (PHB) in accordance with packet marking. Properly
selected combinations of PHB and policy rules result in an IP service with appreciable quality
improvements as viewed by the end user – achieving significantly better performance than that achieved
in existing best-effort networks.
Diff-Serv includes three key components: Policy/Network management, edge device functionality and
core device functionality. The IETF has been addressing a minimum set of PHBs, RFC 3246 (Proposed
Standard) and RFC 3247 (Informational) and boundary mechanisms associated with the edge and core
devices. Policy and network management aspects are left to individual network providers.
The policy server provides a centralized point for the management of Diff-Serv policies, which determine
the traffic profile and class of traffic into which traffic flows will be grouped. The Diff-Serv policies will
be distributed by the policy server to individual edge devices and border routers so that these devices can
police the flows and “tag” the packets with a “codepoint” which represents the per-hop behavior to be
applied at the current node and every downstream node.
15.1.4.3 Quality-of-Service Policy
QoS Policies define the service levels of different user groups for customer cost control, billing of service
provider customers, and network traffic control purposes. For example, users can purchase policies from
service providers that guarantee their priority and time-of-day service levels and control their service
costs.
The QoS policy could also include admission policy and service / network management policy since both
have potential impact on the service QoS. Within this scope, a QoS Policy Server (QPS) would manage
the quality of service policies and maintain logical maps for associating specific policies to routers,
98
533576827
02.10.09
04.03.11
gateways, controllers, and service management agents. QoS policies, implemented as data packet filters
are downloaded to the applicable routers and gateways.
When communicating to routers, it is expected that the QoS Policy server uses the IETF-standard
Common Open Policy Service (COPS) protocol, IETF RFC 2748 (Proposed Standard). The QoS Policy
server will likely use an ASCII command line interface (CLI) to communicate policy information to other
routers. With other policies (admission, management), COPS is usually recommended but other
interfaces are possible.
15.1.4.4 Multi-Protocol Label Switching (MPLS)
MPLS, IETF RFC 3031 (Proposed Standard), is a simple way to forward information through networks
by installing and then examining short, fixed-length ID markings called labels in packets. By relying on
labels to forward information, MPLS usually does not use a packet’s IP header unless it is entering or
leaving MPLS. To the IP stream passing through an MPLS network, the entire network looks like a
single hop – MPLS in effect sets up a tunnel through the network where the route is pre-planned and
mechanistically traversed.
MPLS can be used to create paths whereby QoS parameters such as delay, loss and jitter have been
‘engineered’ and the MPLS path can guarantee these QoS parameters just like in a traffic-engineered
ATM virtual circuit.
MPLS can be used in conjunction with Diff-Serv to provide traffic-engineered paths for critical services.
Diff-Serv still provides the overall end-to-end QoS architecture. The advantage of only using Dif-Serv is
its simplicity. In a normally operating network, Diff-Serv provides consistent QoS behaviors across the
network but cannot provide guarantees, i.e., it provides good QoS most of the time but cannot provide any
guarantees. MPLS, on the other hand, can be used to engineer certain paths in order to achieve explicit
guarantees – similar to that what it can be achieved in ATM networks or with any type of “connectionoriented” networking technology.
Work to develop and define standards for Performance and Quality of Service (QoS) in Next Generation
Networks (NGNs) is ongoing in the ITU-T, the IETF, and other fora. These new and enhanced standards
are important to ensure that NGNs can support a large variety of evolving QoS-enabled (broadband and
narrowband) services which include Voice over IP (VoIP) as well as multimedia services involving
various combinations of voice, video and data.
15.2 Network Performance Objectives
It is important that service providers work together to provide end-to-end communications and that each
provider understands its fair allocation of the end-to-end performance objectives. Those allocations must
be both adequate for the service being offered and feasible based on the available networking
technologies. To satisfy QoS considerations for all transaction and customer types, a service provider
needs to carefully examine and plan for the QoS requirements and customer expectations in a manageable
number of unique and well-defined classes. These classes represent the desired performance QoS
parameters for various types of telecommunications transactions [12].
15.2.1 Y.1540
ITU-T Recommendation Y.1540 “Internet protocol data communication service - IP packet transfer and
availability performance parameters” was first approved and published as I.380, and then renumbered as
Y.1540 on 2000-03-10 without further modification. Y.1540 defines parameters that may be used in
99
533576827
02.10.09
04.03.11
specifying and assessing the performance of the speed, accuracy, dependability, and availability of IP
packet transfer of international Internet Protocol (IP) data communication service.
The defined parameters apply to end-to-end, point-to-point IP service and to the network portions that
provide, or contribute to the provision of, such service. Y.1540 defines the following IP packet transfer
performance parameters:
 IP packet transfer delay (IPTD):
This is the delay for an IP datagram between two reference points. Typically, an end-to-end delay or
a delay within one network.
 Mean IP packet transfer delay:
The arithmetic average of IP packet transfer delays for a population of interest.
 IP packet delay variation (IPDV):
The variations in IP packet transfer delay.
 IP packet error ratio (IPER):
This is the ratio of errored packets of all received packets.
 IP packet loss ratio (IPLR):
The ratio of lost packets from all packets transmitted in population of interest.
 IP packet reordered ratio (IPRR)
The ratio of of the total reordered packet outcomes to the total of successful IP packet transfer
outcomes in a population of interest.
 IP packet severe loss block ratio (IPSLBR)
The ratio of the IP packet severe loss block outcomes to total blocks in a population of interest.
 IP packet duplicate ratio (IPDR
The ratio of total duplicate IP packet outcomes to the total of successful IP packet transfer outcomes
minus the duplicate IP packet outcomes in a population of interest.
 Replicated IP packet ratio (RIPR)T
The ratio of total replicated IP packet outcomes to the total of successful IP packet transfer outcomes
minus the duplicate IP packet outcomes in a population of interest.
 Spurious IP packet rate (SPR):
The total number of spurious IP packets observed at that egress measurement point during a specified
time interval divided by the time interval duration.
 Percent IP service unavailability (PIU):
The percentage of total scheduled IP service time that is categorized as unavailable using the IP
service availability function. The basis for the IP service availability function is a threshold on the
IPLR performance.
15.2.2 Y.1541
ITU-T recommendation Y.1541, “Network Performance Objectives for IP-Based Services” was originally
approved by ITU- SG 12 on May 2002 and its last revision was approved on February 2006. Y.1541
proposes grouping IP telecommunications transactions into six unique network QoS classes defined
according to the desired performance QoS objectives. These classes serve as a basis for agreements
between end-users and service providers, and between service providers. They support a wide range of
traffic applications including point-to-point telephony, data transfer, and multimedia conferencing –
applications whose performance needs are more demanding than others (future applications may require
new or revised classification). The limited number of classes supports the requirement for feasible
implementation, particularly with respect to scale in global networks.
According to this recommendation, “a packet flow is the traffic associated with a given connection or
connectionless stream having the same source host, destination host, class of service, and session
100
533576827
02.10.09
04.03.11
identification”. Thus a service provider and an end-user will have agreed upon the maximum capacity
required to support the class of service requirements of the packet flow as defined by one of these six
classes. The QoS objectives are applicable when access link speeds are at the T1 or E1 rate and higher.
Brief comments on each class are provided here:
 Class 0: Real-time, highly interactive applications, sensitive to jitter
Mean delay upper bound is 100 ms, delay variation is less than 50 ms, and loss ratio is less than 10-3.
Application examples include Voice over IP (VoIP), Video Teleconference (VTC).
 Class 1: Real-time, interactive applications, sensitive to jitter
Mean delay upper bound is 400 ms, delay variation is less than 50 ms, and loss ratio is less than 10-3.
Application examples include VoIP, VTC.
 Class 2: Highly interactive transaction data
Mean delay upper bound is 100 ms, delay variation is unspecified, and loss ratio is less than 10-3.
Application examples include signaling.
 Class 3: Interactive transaction data
Mean delay upper bound is 400 ms, delay variation is unspecified, and loss ratio is less than 10-3.
 Class 4: Low Loss Only applications
Mean delay upper bound is 1 s, delay variation is unspecified, and loss ratio is less than 10-3.
Application examples include Short Transactions, Bulk Data, and Video Streaming.
 Class 5: Traditional applications of default IP networks
Applications with unspecified mean delay, delay variation, and loss ratio. Class 5: Traditional
applications of default IP networks
These six classes enable Service Level Agreements (SLA) to be struck between customers and network
service providers with respect to QoS parameter requirements. The service provider then needs to ensure
that the class of service requirements, for each customer are recognized and receive appropriate treatment
across network layers.
*****
101
533576827
02.10.09
04.03.11
16 Evolutionary Standards
16.1 Internet Protocol version 6 (IPv6)
Internet Protocol version 6 (IPv6), [6], started standardization as a replacement of the current IP version 4
(IPv4), described in RFC 791 (Standard), due to the depletion of the limited number of IPv4 addresses
foreseen already in the 1990's. Up until present time, various techniques such as Classless Inter-Domain
Routing (CIDR), Network Address Translation (NAT), and Multi Protocol Label switching (MPLS) have
managed to delay this depletion. The IETF Internet next Generation (IPNG) working group developed
IPv6, RFC 2460 (Draft Standard).
The current Internet Protocol IPv4, supports up to 4 billion addresses with 32-bit address space. While 4
billion is a lot bigger than the currently estimated 2.5 billion addresses in use by several hundred million
Internet users, in practice IPv4 supports a much lower number. That is because addresses are not used
efficiently. They are allocated in regional blocks, and there is over supply in some areas of the world and
other areas (e.g., Asian, Europe and Latin America) are close to running out. At the current rate of 60%
efficiency, IP addresses will run out some time in the future.IPv6 128-bit address format allows for
340,232,366,920,938,463,374,607,431,768,211,456 IP addresses (340 duodecillion), enough to award one
to every grain of sand on earth. Figure 11 depicts the IPv6 header format.
4 bytes (32 bits)
Ver
Traffic Class
Flow Label
Next Header
Payload Length
Hop Limit
Basic
Header
128-bit source address
128-bit destination address
Payload (includes optional headers & data portion)
IPv6 Header Format
Besides a 128-bit wide address range, the TCP-UDP/IPv6 protocol suite provides additional features such
as mandatory security and mobility, ease of administration and auto-configuration features, built-in QoS,
and more scaleable routing and robustness to mention a few. Many of these have been retrofitted in IPv4
with various limitations and decreased functionality.
Wireless will have the greatest impact on IP; the forthcoming 3G will make much greater use of IP than
the previous generations of cellular radio. Until now IP has been used as an add-on to cellular networks,
in the not too distant future cellular will be data oriented, as voice will be treated as another IP session
within the network. The development of new radio protocols such as 802.11B (Wireless Ethernet) plus
new wired serial interfaces such as IEEE 1394 (Firewire) will provide the opportunity for consumer
products to require an IP address to connect to the net.
16.1.1 IPv4 Workarounds
The Internet industry has been able to stretch the addressing space IPv4, by using a combination of the
techniques listed below:
102
533576827
02.10.09
04.03.11
 DHCP - Dynamic Host Configuration Protocol, RFC 2131 (Draft Standard)
DHCP allows IP addresses to be assigned in three ways:
1. Manual Allocation: The network administrator keeps complete control over addresses by
specifically assigning them to clients. The DHCP server uses this database to assign an IP
address, which was assigned to a particular MAC (Media Access Control) address.
2. Automatic Allocation: The DHCP server permanently assigns an address from a pool of
addresses. The administrator does not get involved in the details of assigning a client an address.
3. Dynamic Allocation: The DHCP server assigns an address to a DHCP client for a limited period
of time. The server automatically reclaims the address after the lease expires or when the client
disconnects.

NAT - Network Address Translator, RFC 2663 (Informational)
NAT is a method by which IP addresses are mapped from one realm to another, in an attempt to provide
transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm
with private unregistered addresses to an external realm with globally unique registered addresses.
If a service provider owns a limited number of valid (registered) IP addresses, the provider will allocate
private IP addresses to the user of the network via DHP to allow navigation within the network or within
a VPN (Virtual Private Network). Once the user needs to access resources that are outside the provider’s
network or VPN the egress device will NAT to a valid (registered) IP address so that the datagram is able
to reach the final destination.
NAT has also been considered as one of the methods to transition from IPv4 to IPv6, RFC 2766
(Proposed Standard). This could be done by performing Network Address Translation in an edge device
located between an IPv6 domain and an IPv4 domain; the edge device would map IP addresses from one
realm IPv4 network to an IPv6 network and vise-versa, as an attempt to provide transparent routing
between the two.

MPLS - Multiprotocol Label Switching Architecture, RFC 3031 (Proposed Standard)
As a packet of a connectionless network layer protocol travels from one router to the next, each router
makes an independent forwarding decision for that packet. That is, each router analyzes the packet's
header, and each router runs a network layer routing algorithm. Each router independently chooses a next
hop for the packet, based on its analysis of the packet's header and the results of running the routing
algorithm. Packet headers contain considerably more information than is needed simply to choose the
next hop. Choosing the next hop can therefore be thought of as the composition of two functions. The first
function partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes
(FECs)". The second maps each FEC to a next hop. Insofar as the forwarding decision is concerned,
different packets, which get mapped into the same FEC, are indistinguishable. All packets which belong
to a particular FEC and which travel from a particular node will follow the same path (or if certain kinds
of multi-path routing are in use, they will all follow one of a set of paths associated with the FEC).
In conventional IP forwarding, a particular router will typically consider two packets to be in the same
FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for
each packet's destination address. As the packet traverses the network, each hop in turn reexamines the
packet and assigns it to a FEC. In MPLS, the assignment of a particular packet to a particular FEC is done
just once, as the packet enters the network. The FEC to which the packet is assigned is encoded as a short
fixed length value known as a "label". When a packet is forwarded to its next hop, the label is sent along
with it; that is, the packets are "labeled" before they are forwarded. At subsequent hops, there is no further
103
533576827
02.10.09
04.03.11
analysis of the packet's network layer header. Rather, the label is used as an index into a table, which
specifies the next hop, and a new label. The old label is replaced with the new label, and the packet is
forwarded to its next hop.
In the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done
by subsequent routers; the labels drive all forwarding. This has a number of advantages over conventional
network layer forwarding. By using local labels instead of IP addresses, it reduces the number of
addresses that can be used.
16.1.2 Location Tracking
VLR (Visitor Location Register) is a key technology used by the cellular network to route calls to and
from a mobile user. In the current 2G cellular networks, calls to a mobile user are made possible by
tracking their current whereabouts in a database called the VLR. When someone dials a number the
information in the VLR is used to route the call through to the base-station closest to the caller’s current
location and then to the mobile phone. This is a complicated procedure and simply keeping the VLR up to
date places great load on the cellular network.
With IPv6, it will be possible to assign not only an IP address to every device but to every device
potential location. Giving each potential location its own address simplifies the tracking and routing of the
calls. A call would be handle the same way a telephone a number is handled today, except that instead of
using a phone number the network would be using IP addresses. A portion of the IP address would be
constantly changing according to the mobile devices whereabouts.
The Internet industry has been able to cope with changing locations by using Mobile IP, RFC 2794
(Proposed Standard), as an IPv4 workaround. Mobile IP specifies protocol enhancements that allow
transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always
identified by its home address, regardless of its current point of attachment to the Internet. While situated
away from its home, a mobile node is also associated with a care-of address, which provides information
about its current point of attachment to the Internet. The protocol provides for registering the care-of
address with a home agent. The home agent sends datagrams destined for the mobile node through a
tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to
the mobile node.
However the above mentioned workaround has problems, especially for applications that required that the
user or end-point use a valid IP address and mobile users as Mobile IP will not be able to cope with the
increased demand.
16.1.3 IPv6 Addressing
The IPv6 addressing architecture is described in IETF RFC 2373 (Proposed Standard), “IP Version 6
Addressing Architecture”. The most obvious difference between IPv4 and IPv6 is their length, IPv4 is 32bit addresses and IPv6 is 128-bit addresses. While addresses in IPv4 can only be divided into two or three
variable parts (the network identifier, the node identifier and sometimes the subnet identifier), in IPv6 the
addresses are large enough to support fields within the address.
16.1.4 IPv6 Address Representation
There are three conventional forms for representing IPv6 addresses as text strings. The preferred form is
x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address,
however certain styles of IPv6 addresses may contain long strings of zero bits that can be represented by
104
533576827
02.10.09
04.03.11
"::". The third alternative is a mixed environment of IPv4 and IPv6 such as x: x:x:x:x:x:d.d.d.d, where the
'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the
decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation).
16.1.5 IPv6 Address types
There are three types of addresses in IPv6: Unicast (an identifier for a single interface), Anycast (an
identifier for a set of interfaces; typically belonging to different nodes) and Multicast (an identifier for a
set of interfaces; typically belonging to different nodes).
16.1.6 IPv6 Unicast Addresses
Unicast addresses specify a single IPv6 interface. A node can have more than one IPv6 network interface.
Unicast addresses can be viewed as 128-bit field that identifies one particular interface. However, the data
in the address field can be parsed out into smaller pieces of information, although all that information
when put together will result in a 128-bit field that identifies a node’s interface.
An IPv6 unicast address may be viewed as a two-field entity, with one field for the network and the other
for an identifier of the node’s interface on that network.
There are several forms of unicast address assignment in IPv6, including the global aggregatable global
unicast address, the NSAP address, the IPX hierarchical address, the site-local address, the link-local
address, and the IPv4-capable host address. Additional address types can be defined in the future. IPv6
nodes may have considerable or little knowledge of the internal structure of the IPv6 address, depending
on the role the node plays (for instance, host versus router).
Still more sophisticated hosts may be aware of other hierarchical boundaries in the unicast address.
Though a very simple router may have no knowledge of the internal structure of IPv6 unicast addresses,
routers will more generally have knowledge of one or more of the hierarchical boundaries for the
operation of routing protocols. The known boundaries will differ from router to router, depending on
what positions the router holds in the routing hierarchy.
16.1.7 IPv6 Anycast Addresses
RFC 2373 defines an "anycast" address as an IPv6 address that is assigned to one or more network
interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast
address is routed to the "nearest" interface having that address, according to the routing protocols'
measure of distance. Multiple nodes may be sharing the same anycast address, like a multicast address.
However only one of those nodes can expect to receive a datagram sent to the anycast address.
Anycast is useful for providing certain types of services, in particular, services that do not require a
particular relationship between the client and the server. For example a domain name server and a time
server. The nearest name server can provide the same service as the furthest name server; however the
nearest time server provides a more accurate time stamp than the one further away.. Anycast addresses are
allocated out of the normal IPv6 unicast address space. Because anycast addresses cannot be
differentiated in their own form from a unicast address, members of the anycast address must each be
explicitly configured to recognize that address as an anycast address.
IETF RFC 2526 (Proposed Standard) “Reserved IPv6 Subnet Anycast Addresses” defines a set of
reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved
subnet anycast addresses. Another IETF RFC 3068 (Proposed Standard) “An Anycast Prefix for 6to4
105
533576827
02.10.09
04.03.11
Relay Routers” introduces an "IPv6 to IPv4 anycast address" in order to simplify the configuration of
IPv6 to IPv4 routers. It also defines how this address will be used by IPv6 to IPv4 relay routers, how the
corresponding "IPv6 to IPv4 anycast prefix" will be advertised in the IGP and in the EGP. The address
assignment is based in IETF RFC 3056 (Proposed Standard) “Connection of IPv6 Domains via IPv4
Clouds”, in particular the definition of a 6to4 router and a 6to4 Relay Router. It adds the definition of the
6to4 Relay anycast prefix, 6to4 Relay anycast address, 6to4 IPv6 relay anycast address, and Equivalent
IPv4 unicast address.
16.1.8 Multicast Addresses
Like broadcast addresses, multicast addresses are used in local networks like Ethernet, where all nodes
can sense all transmissions on wire. However, IP multicast is more complicated because all packets are
not forwarded to all nodes in the network, instead they are only forward to members of the multicast
group. When a node subscribes to a multicast address, it announces that it wants to become a member and
any local router will subscribe on behalf of that node.
Multicast addresses must not be used as source addresses in IPv6 packets or appear in any routing header.
Pre-Defined Multicast Addresses are found in IETF RFC 2375 (Informational) “IPv6 Multicast Address
Assignments”. Additional work continues on IETF RFC 3019 (Proposed Standard), “IP Version 6
Management Information Base for The Multicast”; IETF RFC 2908 (Informational), “The Internet
Multicast Address Allocation Architecture”; and IETF RFC 3307 (Proposed Standard), “Allocation
Guidelines for IPv6 Multicast Addresses”.
16.2 Electronic Numbering (ENUM)
The ENUM protocol developed by the Internet Engineering Task Force (IETF) unifies traditional
telephony and next-generation IP networks, and provides a critical framework for mapping and
processing diverse network addresses. ENUM maps the E.164 telephone number—the most basic and
commonly-used communications address—into a Universal Resource Identifier (URI) that can be used
across many different devices and IP based applications (voice, fax, mobile, email, text messaging,
location-based services and the Internet).
The ENUM protocol, published in the Internet Engineering Task Force (IETF) standard document RFC
3761, is used for mapping ITU-T Recommendation E.164 telephone numbers into the Domain Name
System (DNS).
The ENUM protocol uses what are called naming authority pointer (NAPTR) DNS resource records to
identify the available methods or services for contacting a specific network node identified through a
Recommendation E.164 number. The ENUM protocol defines and uses a specific type of NAPTR service
with the mnemonic "E2U" (E.164 to URI resolution).
The result of an ENUM query can be one or more Uniform Resource Identifiers (URIs) with their order of
processing and preference indicated by values in the naming authority pointer (NAPTR) records. These
URIs are then used to reference resources or services associated with the E.164 number. Possible
examples of resources or services include fax number, mobile number, e-mail address, GPS coordinates,
phone redirection services, unified messaging services, voice mail and public key for asymmetric
encryption applications.
[Ref: P1!T-1039r3_i.doc; 2007-03]
*****
106
533576827
02.10.09
04.03.11
107
533576827
02.10.09
04.03.11
Resolutions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
PCC.I/RES.104 (XIV-01), Gateway Control Protocol
PCC.I/RES.105 (XIV-01), Intelligent Networks Capability Set 3
PCC.I/RES.155 (XVI-02), Network Performance objectives for IP-based Services
PCC.I/RES.1 (I-02), Intelligent Networks Capability Set 4
PCC.I/RES. 25 (III-03), ITU-T Y.2000-Series Recs for NGN (SG13)
PCC.I/RES.027 (III-03), ANSI-41 Evolved Core Network with CDMA2000 Access Network
PCC.I/RES.028 (III-03), GSM Evolved Core Network with UTRAN Access Network
PCC.I/RES.044 (IV-04), Packet-based Multimedia Communications Systems
PCC.I/RES.045 (IV-04), CSD for ITU-T Recommendation X.805, “Security Architecture for
Systems Providing End-to-End Communications
PCC.I/RES.046 (IV-04), Security Architecture for the Internet Protocol
PCC.I/RES.055 (V-04), CSD FOR Q.1912.5 – Interworking between Session Initiation Protocol
(SIP) and Bearer Independent Call Control protocol or ISDN User Part
PCC.I/RES.68 (VI-05), Session Initiation Protocol
PCC.I/RES. 98 (IX-06), ITU-T Rec. G.993.2, VDSL2: Very High Speed DSL-2 Transceivers
PCC.I/RES.99 (IX-06), ITU-T Rec. J.122, “Second-Generation Transmission Systems for
Interactive Cable Television Services – IP Cable Modems”
PCC.I/RES.100 (IX-06), Internet Protocol Version 6 (IPv6)
PCC.I/Res. 116 (XI-07), E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)
PCC.I/RES. 130 (XII-08), ITU-T Rec. E.106, “International Emergency Preference Scheme for
Disaster Relief Operations”
PCC.I/RES. 131 (XII-08), ITU-T Rec. E.107, “Emergency Telecommunications Service (ETS) and
Interconnection Framework for National Implementations of ETS”
PCC.I/RES. 145 (XIV-09), ITU-T Recommendation Y.1910, “IPTV Functional Architecture”
PCC.I/RES. 146 (XIV-09), ITU-T Recommendation Y.2270, “NGN Identity Management
Framework”
PCC.I/RES. 162 (XVI-10), ITU-T Recommendation L.75, ”Test acepptance and maintenance
methods of copper subscriber pairs ”
*****
108
533576827
02.10.09
04.03.11
References
1. PCC.I/doc.957/00, “Evolving Standards for Internet Telephony”
2. PPC.I/doc.1107/00, “Updates to Contribution PCCI/doc.957/00”
3. PCC.I/doc.1112/01, “A brief explanation of SIP”
4. PCC.I/doc.1111/01, “Next Generation Voice Networks and Protocols”
5. PCC.I/doc.1258/01, “IN CS-4 Overview”
6. PCC.I/doc.1262/01, “The Protocol labelled IPv6”
7. PCC.I-TEL/doc.0776/06, “Next Generation Networks - Standards Overview (May 2006)”
8. PCC.I/doc.1344/01, “Next Generation Networks – Performance/QoS Standards”
9. PCC.I/doc.1382/01, “IPv6 Addressing”
10. PCC.1/doc.1472/02,”Standards Roadmap – Asymmetric Digital Subscriber Line System (ADSL)
11. PCC.I/doc.1518/02, “Security in the Internet”
12. PCC.1/doc.1477/02, “Network Performance Objectives in Next Generation Networks”
13. PCC.1/doc.0497/04, “Next Generation Networks: IP Multimedia Subsystem”
14. P1!T-1227_i.doc; 2008-03, “IPTV Standardization Activities in ITU-T”
15. P1!T-1249_i.doc; 2008-03, “Identity Management”
16. P1!T-1273_i.doc; 2008-03, “Security and Critical Infrastructure Protection Standards”
17. P1!T-1278_i.doc; 2008-03, “Generation Networks Application and Service Standards”
*****
109
533576827
02.10.09
04.03.11
Acronyms and Abbreviations
3GPP Third Generation Partnership Project
3GPP2 Third Generation Partnership Project 2
ADSL Asymmetric Digital Subscriber Line
ADSLAM
Asymmetric Digital Subscriber Line Access Multiplexor
API
Application Programming Interface
APM Application Transport Mechanism
ATM Asynchronous Transfer Mode
BICC Bearer Independent Call Control
B-ISDN
Broadband ISDN
CCS7 Common Channel Signaling #7
CPE Customer Premises Equipment
CS1 Capability Set One
Diff-Serv
Differentiated Services
DOCSIS
Data Over Cable Service Interface Specification
DQoS Dynamic Quality of Service
DSL Digital Subscriber Line
GSTN General Switched Telephone Network
HDSL High-bit-rate DSL
HFC Hybrid Fiber-Coax Cable
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
IKE
Internet Key Exchange
IP
Internet Protocol
IPSec IP Security protocol
IPv6 IP Version 6 protocol
ISDN Integrated Service Digital Network
ISUP ISDN User Part
ITU
International Telecommunications Union
JAIN Java API for Integrated Networks
MEGACO
Media Gateway Control Protocol
MIME Multipurpose Internet Mail Extensions
MGC Media Gateway Controller, also know as Softswitch, Call Agent, or Call Server
MPLS Multi-Protocol Label Switching
MTP Message Transfer Part
NGN Next Generation Network
OPE Open Programmability Environment
PSTN Public-Switched Telephone Network
QoS Quality of Service
RFC Request For Comments
RMI Remote Method Invocation
RSVP Resource Reservation Setup Protocol
RTP Real-time Transport Protocol
RTCP Real-time Control Protocol
SCTP Stream Control Transmission Protocol
SDO Standards Development Organization
SDP Session Description Protocol
SDSL Single-line Digital Subscriber Line
SGML Standard Generalized Markup Language
110
533576827
02.10.09
04.03.11
SIP
SIP-T
SIP-I
SNMP
VDSL
VoIP
xDSL
XML
Session Initiation Protocol
SIP-Telephony
SIP with the MIME encoding of ISUP
Simple Network Management Protocol
Very high speed DSL
Voice over IP
Placeholder for any one of a family of Digital Subscriber Line Technologies
Extended Markup Language
*****
111
533576827
02.10.09
04.03.11