906 - Everything Over IP - Dynamics of The Strategic Changes in Voice and Data Networks

A PROJECT REPORT ON
Everything Over IP Dynamics of the Strategic Changes in Voice and Data Networks
TOWARDS PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE AWARD OF MASTER IN BUSINESS ADMINISTRATION IN TELECOM MANAGEMENT
SUBMITTED BY
CHIRANJIB DHAR ANSHUMAN SEN ABHISHEK SINGH NEHA AGRAWAL JITENDER SINGH ROMI RAJE GUPTA Symbiosis Institute of Telecom Management
Constituent of Symbiosis International University Pune 411 042 MBA - TM I Batch 2009-11
CERTIFICATE
This is to certify that research project titled
Everything Over IP Dynamics of the Strategic Changes in Voice and Data Networks
Is a bonafide work carried out by
CHIRANJIB DHAR ANSHUMAN SEN ABHISHEK SINGH NEHA AGRAWAL JITENDER SINGH ROMI RAJE GUPTA Under the guidance of Mr. Yatin Jog Faculty IT, SITM
Towards the partial fulfillment of Master of Business Administration in Telecom Management (MBA TM)
__________________ Research Project Guide
__________________ Director
Symbiosis Institute of Telecom Management Research Project Report
ACKNOWLEDGEMENT
The Research Project on Everything over IP Dynamics of the Strategic Changes in Voice and Data offered us both a learning experience, as well as, a glimpse into the IP communication business. During the tenure of this project, we were fortunate to have interacted with people, who in their own capacities have encouraged and guided us. For his unstinted and invaluable guidance, we wish to express our heartfelt gratitude to my mentor Mr. Yatin Jog, without whom this project could not have been realized. We are grateful to our Institute Director Mr. Sunil Patil, Deputy Director Mr. P. Kulkarni and our Chairperson Placements, Prof. Sujata Joshi for their excellent coordination with the industry for the Research project and thus giving us an opportunity to enhance our management & technical skills in the sense of organizational activity. We would also like to express our sincere thanks to the alumni in the industry for their expert guidance and constant cooperation. It was a privilege working with them and we sincerely thank them for advising us whenever the road map seemed blocked, despite of their busy schedule. Finally, we would like to express our deepest gratitude towards our institute Symbiosis Institute of Telecom Management in which apart from the summer projects you get an opportunity to continuously work on the research projects and explore the trends in the industry.
Everything Over IP - Dynamics of the Strategic Changes in Voice and Data Networks | 3
Abstract
This project will review the viability of EoIP networks. The Internet, underscored by IP, has not only affected every business, information systems department and software publisher, but it has changed world communications forever. The IP telephony, VoIP, IP Multimedia Subsystem, IP network, Internet, TCP/IP, dumb network, infranet etc are systems that are spearheading a dynamic change in the way we communicate. The IP protocol is not only the protocol of the Internet, but it has become the default protocol for local networks in almost every enterprise. This project will study changes that are taking place in the telecommunications industry ranging from a discussion about the companies installing massive global IP networks to the emergence of novel routing technologies, e.g. multi-protocol label switching (MPLS) and terabit router technologies. The advantages of conversion to IP network like Reduced Transport cost, Abundant IP interfaces meeting requirements of different networks and evolution, Launching new services quickly, Saving maintenance and management cost, Fully complying with evolution to All IP network etc will also be discussed.
In a Nutshell
To study the technologies and protocols involved in all IP network To learn synchronization of legacy network with IP architecture To review the Indian regulatory concept of EoIP and policies adopted in other parts of the world To study the compatibility issues of emerging/existing backhaul technologies Business analysis of EoIP
1. 2. 3.
Table of Contents Executive Summary ........................................................................................................ 12 Introduction ..................................................................................................................... 13 A Basic Architecture for a EoIP Network ....................................................................... 14 3.1 3.2 3.2.1 3.2.1 3.2.1 3.2.1 3.3 3.4 INTRODUCTION........................................................................................................ 14 IMS (IP Multimedia Subsystem)............................................................................... 16 A Layered Approach ............................................................................................. 18 Architecture ................................................................................................... 21 Architectural Elements ................................................................................. 25 IMS Benefits .................................................................................................. 30
NGN Services ........................................................................................................... 31 NGN Models .............................................................................................................. 33
3.4.1 Scenario 1: Network Consolidation .................................................................. 34 3.2.1 3.2.1 Scenario 2: Deployment of overlay packet based network ........................ 35 Scenario 3. Replacement of legacy TDM equipment .................................. 36
4. EoIP protocols .................................................................................................................... 38 4.1 Introduction ................................................................................................................... 38 4.2 SIP.................................................................................................................................. 40 4.2.1 4.3 Call Flow ........................................................................................................ 41
Migration from IPv4 to IPv6 ..................................................................................... 41 Problems faced by IPv4 ................................................................................ 41 Phases of IPv6 migration in NGN ................................................................. 42
4.3.1 4.3.2 5
Service aspects: Interoperability of services and networks in NGN ........................... 47 5.1 PSTN/ISDN evolution to NGN .................................................................................. 47 Aspects to consider when evolving to NGN ............................................... 47 Service requirements by national regulatory bodies.................................. 52 Emergency telecommunications in NGN..................................................... 52 Security aspects of evolution....................................................................... 53 Examples of network evolution scenarios .................................................. 53
5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2
PSTN/ISDN emulation and simulation .................................................................... 64 Interfaces ....................................................................................................... 66
5.2.1
5.2.2 5.3 5.4
Adaptations ................................................................................................... 67
Call server-based PSTN/ISDN emulation ................................................................ 68 ENUM ........................................................................................................................ 68
5.4.1 Types of E-NUM .................................................................................................. 68 7. Services ........................................................................................................................... 74 7.1. 8 Specific Services for next generation networks .................................................... 76
Generalized Mobility ....................................................................................................... 80 8.1 8.2 Introduction .............................................................................................................. 80 Considerations for mobility management in NGN ................................................. 80 Network environments.................................................................................. 80 General mobility management features ...................................................... 81 Considerations on user part......................................................................... 83 Mobility management functionalities ........................................................... 84
8.2.1 8.2.2 8.2.3 8.2.4 8.3
Classification of mobility management .................................................................. 85 Intra-CN MM ................................................................................................... 86 Intra-Network MM (Inter-CN MM) .................................................................. 87
8.3.1 8.3.2 8.4
Requirements for mobility management ................................................................ 87 General requirements ................................................................................... 88 Requirements for Inter-CNs MM ................................................................... 90 Requirements for Inter-ANs MM ................................................................... 91
8.4.1 8.4.2 8.4.3 8.5 9.
Classification of mobility based on network topology .......................................... 93
Quality of Service Parameters for Next Generation Networks ..................................... 95 9.1 9.2 9.3 The role of voice in next generation networks ....................................................... 95 Quality of Service requirements for Voice over IP ................................................. 96 QoS solutions for VoIP .......................................................................................... 100 Integrated Services (Intserv) .......................................................................100 Differentiated Services (Diffserv) ................................................................101 MPLS Traffic Engineering (MPLS-TE) .........................................................103
9.3.1 9.3.2 9.3.3 9.4 9.5
A solution framework for VoIP Quality of Service ............................................... 103 Interface descriptions ............................................................................................ 106 Interface IF-1.................................................................................................106
9.5.1
9.5.2 9.5.3 9.5.4 9.5.5 9.5.6 9.6 9.7 9.8
Interface IF-2.................................................................................................106 Interface IF-3.................................................................................................107 Interface IF-4.................................................................................................107 Interface IF-5.................................................................................................108 Interface IF-6.................................................................................................109
Call setup for VoIP ................................................................................................. 109 Currently Defined Solutions for VoIP QoS ........................................................... 112 Quality Control Models for NGN............................................................................ 113 3GPP IMS ......................................................................................................113 ITU-T NGN-GSI .............................................................................................119 ETSI TISPAN .................................................................................................121 PCMM ............................................................................................................122 MSF ...............................................................................................................123
9.8.1 9.8.2 9.8.3 9.8.4 9.8.5 9.9 10. 10.1 10.1 10.1 10.1 10.1
NGN Comparison ................................................................................................... 124 NGN security .............................................................................................................. 128 Objective of NGN security ..................................................................................... 128 Objectives for security across multiple network provider domains ................... 128 Threats to the NGN ................................................................................................ 129 Areas of consideration and action for security policy as the five As ................ 133 Security Trust Models ............................................................................................ 135 Single network trust model .........................................................................135 Peering network trust model .......................................................................137
10.5.1 10.5.2 10.1 10.1 11. 11.1 11.2
Standard Security policies .................................................................................... 138 Technical aspects concerning security ................................................................ 141 Business case............................................................................................................ 143 Introduction ............................................................................................................ 143 Case Study: BT....................................................................................................... 144
BTs Objectives: .........................................................................................................144 NGN implementation: .................................................................................................145 Financial benefits: ......................................................................................................147 Advanced Services Offered: ......................................................................................148
Laying the Foundation for the Digital Home ............................................................148 Launching Next-Generation IP Television ................................................................150 End-to-End Service Assurance .................................................................................150 Fusionthe worlds first seamless fixed-mobile phone service ............................151 Concerns ........................................................................................................................... 151 Conclusion ........................................................................................................................ 153 12. References ................................................................................................................. 154
List of Figures
Figure 1 : Logical Representation of the network .................................................................. 15 Figure 2: Layered Architecture ............................................................................................. 18 Figure 3: NGN Architecture using Soft switch ....................................................................... 21 Figure 4: IMS and its Environment ....................................................................................... 23 Figure 5: : Relationship of session control entities to NGN Core networks ........................... 24 Figure 6: 3GPP IMS Architectural Overview ......................................................................... 25 Figure 7:Architectural Elements............................................................................................ 28 Figure 8: Multiservice access systems ................................................................................. 34 Figure 9: Scenario 2 ............................................................................................................. 35 Figure 10 Scenario 3 ............................................................................................................ 37 Figure 11: : Protocol Stack for NGN ..................................................................................... 38 Figure 12: SIP Call flow ........................................................................................................ 40 Figure 13: Phase 0-Complete IPv4 based NGN ................................................................... 42 Figure 14:Phase 1-Connecting IPv6-based NGNs across IPv4-based NGN......................... 43 Figure 15: Phase 2-Connecting IPv6-based NGNs IPv4-based NGNs across dual-stack ..... 44 Figure 16: Phase 3-IPv4 Islands with IPv6-based NGN........................................................ 45 Figure 17: Phase 4-Completed IPv6-based NGN ................................................................. 46 Figure 18: 1Preparation for evolution to NGN ....................................................................... 55 Figure 19:Realization of scenario 1 ...................................................................................... 56 Figure 20: Realization of scenario 2 ..................................................................................... 58 Figure 21:Realization of scenario 3 ...................................................................................... 59 Figure 22:IMS-based PSTN/ISDN evolution to NGN ............................................................ 60 Figure 23:Evolution of xDSL access to NGN ........................................................................ 62 Figure 24:Realization of signalling evolution scenario .......................................................... 63 Figure 25:Billing system evolution scenarios ........................................................................ 64 Figure 26:Emulation, simulation, interoperability and interworking with NGN ....................... 66 Figure 27:ENUM .................................................................................................................. 70 Figure 28:ENUM infra........................................................................................................... 71 Figure 29:Example NGN Service Drivers ............................................................................. 77 Figure 30: Envisioned network environment of NGN ............................................................ 81 Figure 31: Mobility classifications according to service quality .............................................. 82 Figure 32: User network configuration .................................................................................. 84 Figure 33:Classification of MM ............................................................................................. 86 Figure 34:Example of levels of mobility ................................................................................ 93 Figure 35: VoIP .................................................................................................................... 97 Figure 36:VoIP QoS Architecture ........................................................................................104 Figure 37: Interconnect via transit network ..........................................................................109 Figure 38:Call setup for VoIP ..............................................................................................111
Figure 39:Positioning Of elements in Next Generation Networks.........................................115 Figure 40:Pull QoS Authorization flow (3GPP2 model) ........................................................118 Figure 41:NGN QoS Roles ..................................................................................................125 Figure 42: Security ..............................................................................................................131 Figure 43: Five As ..............................................................................................................133 Figure 44:A single network trust model................................................................................135 Figure 45:A Peering network trust model.............................................................................138 Figure 46: BT ......................................................................................................................145 Figure 47:Single IP architecture ..........................................................................................146 Figure 48:PSTN Migration ...................................................................................................147
Title of Project
Everything Over IP Dynamics of the Strategic Changes in Voice and Data Networks and a Business Plan
Project Objectives

Comparative analysis of all the technologies and protocols with respect to various parameters New services offered and technical up gradation required Best practices for efficient regulatory framework Backhaul support analysis A business case for EoIP services
1.
Executive Summary
"I think there is a world market for about five computers" Remark attributed to Thomas J. Watson (Chairman of the Board of International Business Machines), 1943 to more than 350 million personal computers being sold in a year in USA alone and over 150 million smart-phones being sold in a year worldwide. People want to control their home appliances, security systems, know about the exact location of their loved ones and much more while on the move. People want to seamlessly move from one device to another. They want to be connected and reachable on multiple devices through the same address. More and more people are using devices to connect to their workstations or access their work folders stored on their work servers while on the move. A feat which will require a network which will let all devices connect through the same interface, a Ubiquitous network which will allow communication between machine and machine and a man and machine. The requirement is for a network that will allow any user to connect through any device to access any other device from any part of the world. It can be a wired device or a wireless device. The world is moving towards IP V6, a move that will accommodate all the devices. An IP based network will allow every device to connect to each other. A migration to an IP will also help in standardisation of interfaces.
2. Introduction
Everything over Internet Protocol (EoIP) network is a packet-based network able to provide services including telecommunications services and able to make use of multiple broadband, Quality of Service (QoS) enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It offers unfettered access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users. FEATURES: Packet-based transfer Separation of control functions among bearer capabilities, call/session, and application/ service Decoupling of service provision from transport, and provision of open interfaces Support for a wide range of services, applications and mechanisms based on service building blocks (including real time/ streaming/ non-real time services and multi-media) Broadband capabilities with end-to-end QoS (Quality of Service). Interworking with legacy networks via open interfaces Generalized mobility Unfettered access by users to different service providers A variety of identification schemes Unified service characteristics for the same service as perceived by the user Converged services between Fixed/Mobile Independence of service-related functions from underlying transport technologies Support of multiple last mile technologies Compliant with all Regulatory requirements, for example concerning emergency communications, security, privacy etc.
3.
3.1
A Basic Architecture for a EoIP Network

INTRODUCTION
A EoIP network is a packet-based network which can provide services including Telecommunication Services and able to make use of multiple broadband, Quality of Service-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. The EoIP functional architecture shall incorporate the following principles. 1. Support for multiple access technologies: The NGN functional architecture shall offer the configuration flexibility needed to support multiple access technologies. 2. Distributed control: This will enable adaptation to the distributed processing nature of IP networks and support location transparency for distributed computing. 3. Open control: The network control interface should be open to support service creation, service updating, and incorporation of service logic provision by third parties. 4. Independent service provisioning: The service provision process should be separated from network operation by using the above-mentioned distributed, open control mechanism. This is intended to promote a competitive environment for NGN development in order to speed up the provision of diversified value-added services. 5. Support for services in a converged network: This is needed to generate flexible, easy-to-use multimedia services, by tapping the technical potential of the converged, fixed-mobile functional architecture of the NGN. 6. Enhanced security and protection: This is the basic principle of an open architecture. It is imperative to protect the network infrastructure by providing mechanisms for security and survivability in the relevant layers. 7. Functional entity characteristics: Functional entities should incorporate the following principles: Functional entities may not be distributed over multiple physical units but may have multiple instances.
Functional entities have no direct relationship with the layered architecture. However, similar entities may be located in different logical layers. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.
Figure 1 : Logical Representation of the network
EoIP or also known as NGN involves three main architectural changes that need to be looked at separately:
In the core network, NGN implies a consolidation of several (dedicated or overlay) transport networks each historically built for a different service into one core transport network (often based on IP and Ethernet). It implies amongst others the migration of voice from a circuit-switched architecture (PSTN) to VoIP, and also migration of legacy services such as X.25, Frame Relay (either commercial migration of the customer to a new service like IP VPN, or technical emigration by emulation of the "legacy service" on the NGN). In the wired access network, NGN implies the migration from the dual system of legacy voice next to xDSL setup in local exchanges to a converged setup in which the DSLAMs integrate voice ports or VoIP, making it possible to remove the voice switching infrastructure from the exchange. In the cable access network, NGN convergence implies migration of constant bit rate voice to CableLabs PacketCable standards that provide VoIP and SIP services. Both services ride over DOCSIS as the cable data layer standard. Next Generation Networks are based on Internet technologies including Internet Protocol (IP) and Multiprotocol Label Switching (MPLS). At the
application level, Session Initiation Protocol (SIP) seems to be taking over from ITU-T H.323. For voice applications one of the most important devices in NGN is a Softswitch - a programmable device that controls Voice over IP (VoIP) calls. It enables correct integration of different protocols within NGN. The most important function of the Soft switch is creating the interface to the existing telephone network, PSTN, through Signaling Gateways and Media Gateways. Hotheyver, the Soft switch as a term may be defined differently by the different equipment manufacturers and have somewhat different functions. The NGN is characterized by the following fundamental aspects:
Packet-based transfer Separation of control functions among bearer capabilities, call/session, and
application/service Decoupling of service provision from transport, and provision of open interfaces Support for a wide range of services, applications and mechanisms based on service building blocks (including real time/streaming/non-real time services and multi-media) Broadband capabilities with end-to-end QoS and transparency Interworking with legacy networks via open interfaces Generalized mobility Unfettered access by users to different service providers A variety of identification schemes which can be resolved to IP addresses for the purposes of routing in IP networks Unified service characteristics for the same service as perceived by the user Converged services between Fixed and Mobile networks Independence of service-related functions from underlying transport technologies Support of multiple last mile technologies Compliant with all Regulatory requirements, for example concerning emergency communications and security/privacy, etc.
3.2
IMS (IP Multimedia Subsystem)
The IP Multimedia Subsystem (IMS) is an architectural framework for delivering internet protocol (IP) multimedia to mobile users. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), and is part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS. This vision
was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line. Effectively, IMS provides a unified architecture that supports a wide range of IP-based services over both packet- and circuit-switched networks, employing a range of different wireless and fixed access technologies. A user could, for example, pay for and download a video clip to a chosen mobile or fixed device and subsequently use some of this material to create a multimedia message for delivery to friends on many different networks. A single IMS presence-and-availability engine could track a user's presence and availability across mobile, fixed, and broadband networks, or a user could maintain a single integrated contact list for all types of communications.
IMS History
IMS was originally defined by an industry forum called 3G.IP, formed in 1999. 3G.IP developed the initial IMS architecture, which was brought to the 3rd Generation Partnership Project (3GPP), as part of their standardization work for 3G mobile phone systems in UMTS networks. It first appeared in release 5 (evolution from 2G to 3G networks), when SIP-based multimedia was added. Support for the older GSM and GPRS networks was also provided. 3GPP2 (a different organization) based their CDMA2000 Multimedia Domain (MMD) on 3GPP IMS, adding support for CDMA2000. 3GPP release 6 added interworking with WLAN. 3GPP release 7 added support for fixed networks, by working together with TISPAN release R1.1. The Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) is a standardization body of ETSI, specializing in fixed networks and Internet convergence. It was formed in 2003 from the amalgamation of the ETSI bodies Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) and Services and Protocols for Advanced Networks (SPAN).
3.2.1 A Layered Approach IP Multimedia Subsystem is standardized reference architecture. IMS consists of session control, connection control and an applications services framework along with subscriber and services data. It enables new converged voice and data services, while allowing for the interoperability of these converged services between internet and cellular subscribers. IMS uses open standard IP protocols. So users will be able to execute all their services when roaming as well as from their home networks. So, a multimedia session between two IMS users, between an IMS user and a user on the Internet, and between two users on the Internet is established using exactly the same protocol. The 3GPP architecture is split into three main planes or layers, each of which is described by a number of equivalent names: Service or Application Plane, Control or Signaling Plane, and User or Transport Plane.
Figure 2: Layered Architecture
Application Plane The application plane provides an infrastructure for the provision and management of services, and defines standard interfaces to common functionality including

configuration storage, identity management, user status (such as presence and location), which is held by the Home Subscriber Server (HSS) billing services, provided by a Charging Gateway Function (CGF) control of voice and video calls and messaging, provided by the control plane.
Control Plane The control plane sits between the application and transport planes. It routes the call signaling, tells the transport plane what traffic to allow, and generates billing information for the use of the network. At the core of this plane is the Call Session Control Function (CSCF), which comprises the following functions.
The Proxy-CSCF (P-CSCF) is the first point of contact for users with the IMS. The P-CSCF is responsible for security of the messages between the network and the user and allocating resources for the media flows. The Interrogating-CSCF (I-CSCF) is the first point of contact from peered networks. The I-CSCF is responsible for querying the HSS to determine the SCSCF for a user and may also hide the operator's topology from peer networks (Topology Hiding Inter-network Gateway, or THIG). The Serving-CSCF (S-CSCF) is the central brain. The S-CSCF is responsible for processing registrations to record the location of each user, user authentication, and call processing (including routing of calls to applications). The operation of the S-CSCF is controlled by policy stored in the HSS. This distributed architecture provides an extremely flexible and scalable solution. For example, any of the CSCF functions can generate billing information for each operation.
The Control Plane also controls User Plane traffic through the Resource and Admission Control Subsystem (RACS). This consists of the Policy Decision Function (PDF), which implements local policy on resource usage, for example to prevent overload of particular access links, and Access-RAC Function (A-RACF), which controls QoS within the access network. User Plane The User plane provides a core QoS-enabled IPv6 network with access from User Equipment (UE) over mobile, WiFi and broadband networks. This infrastructure is designed to provide a wide range of IP multimedia server-based and P2P services. Access into the core network is through Border Gateways (GGSN/PDG/BAS). These enforce policy provided by the IMS core, controlling traffic flows between the access and core networks. Within the User Plane

the Interconnect Border Control Function (I-BCF) controls transport level security and tells the RACS what resources are required for a call the I-BGF, A-BGF Border Gateway Functions provide media relay for hiding endpoint addresses with managed pinholes to prevent bandwidth theft, and implement NAPT and NAT/Firewall traversal for media flows.
3.2.1
Architecture
The IMS architecture which is deployed using a softswitch can be divided into layers as follows:
Figure 3: NGN Architecture using Soft switch
A softswitch is a central device in a telecommunications network which connects telephone calls from one phone line to another, entirely by means of software running on a computer system. This work was formerly carried out by hardware, with physical switchboards to route the calls.
A softswitch is typically used to control connections at the junction point between circuit and packet networks. A single device containing both the switching logic and the switching fabric can be used for this purpose; however, modern technology has led to a preference for decomposing this device into a Call Agent and a Media Gateway. The Call Agent takes care of functions including billing, call routing, signalling, call services and so on and is the 'brains' of the outfit. A Call Agent may control several different Media Gateways in geographically dispersed areas over a TCP/IP link. The Media Gateway connects different types of digital media stream together to create an end-to-end path for the media (voice and data) in the call. It may have interfaces to connect to traditional PSTN networks like DS1 or DS3 ports (E1 or STM1 in the case of non-US networks), it may have interfaces to connect to ATM and IP networks and in the modern system will have Ethernet interfaces to connect VoIP calls. The call agent will instruct the media gateway to connect media streams between these interfaces to connect the call - all transparently to the end-users.
Figure 4: IMS and its Environment
The softswitch generally resides in a building owned by the telephone company called a central office. The central office will have telephone trunks to carry calls to other offices owned by the telecommunication company and to other telecommunication companies (aka the Public Switched Telephone Network or PSTN). Looking towards the end users from the switch, the Media Gateway may be connected to several access devices. These access devices can range from small Analog Telephone Adaptors (ATA) which provide just one RJ11 telephone jack to an Integrated Access Device (IAD) or PBX which may provide several hundred telephone connections. Typically the larger access devices will be located in a building owned by the telecommunication company near to the customers they serve. Each end user can be connected to the IAD by a simple pair of copper wires.
The medium sized devices and PBXs will typically be used in a business premises and the single line devices would probably be found in residential premises. At the turn of the 21st century with IP Multimedia Subsystem or IMS), the Softswitch element is represented by the Media Gateway Controller (MGC) element, and the term "Softswitch" is rarely used in the IMS context, rather it is called AGCF (Access Gateway Control Function).
Figure 5: : Relationship of session control entities to NGN Core networks
Figure 6: 3GPP IMS Architectural Overview
3.2.1 Architectural Elements

a) Access Gateway Control Function (AGCF) This functional entity is the first point of contact for residential and access media gateways. This entity is specific to the IMS based PSTN/ISDN emulation component. It performs the following functions: Act as an MGC for controlling media gateways functions located in residential and access gateways. Interact with the resource and admission control function (RACF). Interact with the network attachment Control Function (NACF) to retrieve line profile information. Perform signaling inter-working between SIP (including any ISUP information that may be encapsulated) and analog signaling (through H.248 signals and events). Manage SIP registration procedures on behalf of legacy terminals connected behind the media gateways. Moreover, the AGCF shall provide basic feature logic for placing, holding and transferring of calls; determining end of dialling; reporting the state of a terminal (e.g. parking, out of order, on service, offhook, on-session, etc.) via SIP. supporting the collection and reporting of events to AS via SIP for example basic call events, service activation, service deactivation, service interrogation and mid-call events. From the service points of view they are transparent to AGCF. delivering several dial tone patterns selected by the application server; The AGCF does not hold any user profile but shall be made aware if user equipment can handle several simultaneous calls. b) Multimedia Resource Function Controller (MRFC) The behavior of the MRFC is identical in the IMS based PSTN/ISDN Emulation service component and in the IMS. c) Media Gateway Control Function (MGCF)
The role of the MGCF is identical in the IMS based PSTN/ISDN Emulation service component and in the IMS. Signaling procedures for inter-working with ISUP signaling are slightly different due to the presence of encapsulated ISUP information inside the IMS-PES and the need to ensure full ISDN transparency in case of ISDN calls transiting through the IMS-PES.
d) Call Session Control Protocol (CSCF) Several roles of Session Initiation Protocol (SIP) servers or proxies, collectively called Call Session Control Function (CSCF), are used to process SIP signaling packets in the IMS. i) Proxy Call Session Control Function (P-CSCF) The behavior of the P-CSCF is identical in the IMS based PSTN/ISDN Emulation service component and in the IMS. However, the P-CSCF is not used in configurations where an AGCF is required to control residential or access media gateways, using H.248. ii) Service Call Session Control Function (S-CSCF) The behavior of the S-CSCF is identical in the IMS based PSTN/ISDN Emulation service component and in the IMS, except that, as an option, the presence of encapsulated ISUP information may be used as a potential Service Point Trigger (SPT) in SIP signaling. iii) Interrogating Call Session Control Function (I-CSCF) The behavior of the I-CSCF is identical in the IMS based PSTN/ISDN Emulation service component and in the IMS. e) Application servers Application servers host and execute services and interface with the S-CSCF using Session Initiation Protocol (SIP). An Application Server Function (ASF) offers value added services and resides either in the user's home network or in a third party location. The third party could be a network or simply a standalone AS. Application Server Functions may provide standalone services or value added services on top of a basic session. For resource control purposes, the first
category of Application Server Functions (ASF Type 1) may interact with the RACS, while the second category (ASF Type 2) relies on the control subsystem that provide the basic session over which the valued added service is built. Examples of Application Server Functions are SIP Application Servers and OSA Application Servers.
f) Breakout Gateway Control Function (BGCF) The behavior of the BGCF is identical in the IMS based PSTN/ISDN Emulation service component and in the IMS. A BGCF (Breakout Gateway Control Function) is a SIP server that includes routing functionality based on telephone numbers. It is only used when calling from the IMS to a phone in a circuit switched network, such as the Public Switched Telephone Network (PSTN) or the Public land mobile network (PLMN).
Figure 7:Architectural Elements
g) User Profile Server Function (UPSF)

The User Profile Server Function (UPSF) is responsible for holding the following user related information: Service-level user identification, numbering and addressing information. Service-level user security information, access control information for authentication and authorization. Service-level user location information at inter-system level, the UPSF supports the user registration, and stores inter-system location information, etc. Service-level user profile information. The UPSF may store user profile information related to one or more service control subsystems and applications. The UPSF does not contain profile information related to IP connectivity subscriptions. Such information is hold in the Network Attachment Subsystem (NASS). However, where it makes sense in the context of a particular business model, the UPSF may be co-located with the data base function of the NASS. (The subset of the UPSF hosting IMS-related data is equivalent to the subset of the HSS entity defined in 3GPP TS 123 002 for cellular systems, excluding the HLR/AUC functionality.) h) Subscription Locator Function The Subscription Locator Function (SLF) is a functional entity that can be accessed by service control subsystems and Application Server Functions to retrieve the identity of the UPSF containing the service-level user profile of a particular subscriber. i) Charging and Data Collection Functions Charging and Data Collection functions include data collection functions and mediation functions to the billing systems (for supporting both on-line and offline charging) or other management applications that may use the same data. The specification of a generic architecture of the charging and data collection functions is outside the scope of TISPAN NGN Release 1. j) Interworking Function (IWF) The Interworking Function (IWF) performs the interworking between protocols used within TISPAN NGN service control subsystems and other IP-based protocols (e.g. between the SIP profile used in the IMS and other SIP profiles or IP-based protocols such as the H.323 protocol). k) The Interconnection Border Control Function (IBCF)
The Interconnection Border Control Function (IBCF) controls the boundary between two operators' domains. The functionality of the IBCF encompasses: interaction with transport resources, through the resource and admission control subsystem, including NAPT (Network Address and Protocol Translation) and firewall functions; insertion of the IWF in the signalling route when appropriate; screening of signalling information based on source/destination, beyond what is already performed inside each of the subsystems (e.g. by the THIG functionality of the I-CSCF for the IMS core subsystem) l) PSTN Gateways A PSTN/CS gateway interfaces with PSTN circuit switched (CS) networks. For signaling, CS networks use ISDN User Part (ISUP) (or BICC) over Message Transfer Part (MTP), while IMS uses Session Initiation Protocol (SIP) over IP. For media, CS networks use Pulse-code modulation (PCM), while IMS uses Real-time Transport Protocol (RTP). A Signaling Gateway (SGW) interfaces with the signaling plane of the CS. It transforms lower layer protocols as Stream Control Transmission Protocol (SCTP, an Internet Protocol (IP) protocol) into Message Transfer Part (MTP, an Signaling System 7 (SS7) protocol), to pass ISDN User Part (ISUP) from the MGCF to the CS network.
3.2.1 IMS Benefits Benefits to the user: Single sign on Application bundling in realtime (e.g. simultaneous usage of voice and data applications) Realtime messaging without store & foreward Multiparty communication services (e.g. chatting, conferencing) Enrichment and personalization (e.g. realtime multimedia, buddy lists, presence, push services, subscriber self administration) Anywhere service access from various access networks Benefits for the operator:
3.3
Fast and flexible service creation (1 SIP client) Innovative realtime multimedia service offers Full control of services by operator Service differentiation by flexible bandwidth allocation and guaranteed QoS Fixed / mobile convergence Common service control infrastructure for PS domain for cost optimization and easy service introduction Longterm CS migration by shifting voice traffic towards PS domain NGN Services
Most traditional services relate to basic access/transport/routing/switching services, basic connectivity/resource and session control services, and various value-added services. NGNs will likely enable a much broader array of service types, including: Specialized resource services (e.g., provision and management of transcoders, multimedia multipoint conferencing bridges, media conversion units, voice recognition units, etc.) Processing and storage services (e.g., provision and management of information storage units for messaging, file servers, terminal servers, OS platforms, etc.) Middleware services (e.g., naming, brokering, security, licensing, transactions, etc.) Application-specific services(e.g., business applications, e-Commerce applications, Supply-chain management applications, interactive video games, etc.) Content provision services that provide or broker information content (e.g., electronic training, information push services, etc.) Interworking services for interactions with other types of applications, services, networks, protocols, or formats (e.g., EDI translation) Management services to maintain, operate, and manage communications computing networks and services. Voice Telephony NGNs will likely need to support various existing voice telephony services (e.g., Call Waiting, Call Forwarding, 3-Way Calling, various AIN features, various Centrex features, and various CLASS features). Note, however, that NGNs are not trying to duplicate each and every traditional voice telephony service currently
offered. Rather, they will likely attempt to support only a small percentage of these traditional services, with an initial focus on the most marketable voice telephony features and the features required from a regulatory perspective. Data (Connectivity) Services Allows for the real-time establishment of connectivity between endpoints, along with various value-added features (e.g., bandwidth-ondemand, connection reliability/resilient Switched Virtual Connections [SVCs], and bandwidth management/call admission control). Multimedia Services Allows multiple parties to interact using voice, video, and/or data. This allows customers to converse with each other while displaying visual information. It also allows for collaborative computing and groupware. Virtual Private Networks (VPNs) Voice VPNs improve the interlocation networking capabilities of businesses by allowing large, geographically dispersed organizations to combine their existing private networks with portions of the PSTN, thus providing subscribers with uniform dialing capabilities. Data VPNs provide added security and networking features that allow customers to use a shared IP network as a VPN. Public Network Computing (PNC) Provides public network-based computing services for businesses and consumers. For example, the public network provider could provide generic processing and storage capabilities (e.g., to host a web page, store/maintain/backup data files, or run a computing application). The public network provider would charge users for the raw processing and storage used, but would have no knowledge of the specific content/application. Alternatively, the public network provider could provide specific business applications (e.g., Enterprise Resource Planning [ERP], time reporting, vouchers, etc.) or consumer applications (e.g., TaxCut, kitchen remodeling program, etc.), with all or part of the processing/storage happening in the network. The public network provider could charge based on an hourly, daily, weekly, etc. licensing fee for the service (e.g., rent-an-app). Unified Messaging Supports the delivery of voice mail, email, fax mail, and pages through common interfaces. Through such interfaces, users will access, as well as be notified of, various message types (voice mail, email, fax mail, etc.), independent of the means of access (i.e., wireline or mobile phone, computer, or wireless data device). Information Brokering Involves advertising, finding, and providing information to
match consumers with providers. For example, consumers could receive information based on pre-specified criteria or based on personal preferences and behavior patterns. E-Commerce Allows consumers to purchase goods and services electronically over the network. This could include processing the transactions, verifying payment information, providing security, and possibly trading (i.e., matching buyers and sellers who negotiate trades for goods or services). Home banking and home shopping fall into this category of services. This also includes business-to-business applications (e.g., supply-chain management and knowledge management applications). Call Center Services A subscriber could place a call to a call center agent by clicking on a Web page. The call could be routed to an appropriate agent, who could be located anywhere, even at home (i.e., virtual call centers). Voice calls and e-mail messages could be queued uniformly for the agents. Agents would have electronic access to customer, catalog, stock, and ordering information, which could be transmitted back and forth between the customer and the agent. Interactive gaming Offers consumers a way to meet online and establish interactive gaming sessions (e.g., video games). Distributed Virtual Reality Refers to technologically generated representations of real world events, people, places, experiences, etc., in which the participants in and providers of the virtual experience are physically distributed. These services require sophisticated coordination of multiple, diverse resources. Home Manager With the advent of in-home networking and intelligent appliances, these services could monitor and control home security systems, energy systems, home entertainment systems, and other home appliances. Imagine youre watching television and the doorbell rings no problem you just use the TVs remote to get a view of your front entrance to see whos there. Or imagine monitoring your house while youre away on a trip, or your in-house nanny watching your children while youre at work.
3.4
NGN Models
Scenario 1. Network consolidation Scenario 2. Deployment of overlay packet based network Scenario 3. Technology replacement 3.4.1 Scenario 1: Network Consolidation a) Maximum utilisation of the installed capacities in the TDM switches: optimal utilisation of the already installed DLEs expansion of their service area replacement of analogue exchanges with subscriber capacities, served by DLEs optimisation of the connectivity on regional level, reducing the number of nodal service areas b) Limited deployment of multiservice access systems provision of POTS, ISDN BA, ISDN PA, digital LL (n x 64 k), xDSL (ADSL, HDSL), served by MSANs and xDSLs by DSLAMs splitting the dial up Internet traffic from the PSTN and routing it to the data network
Figure 8: Multiservice access systems
Major Advantages
Optimal utilisation of the existing TDM equipment, thus reducing the analogue part of the network, network infrastructure optimisation. Significant CAPEX and OPEX reducement, due to the expansion of existing DLEs, decreasing the number of analogue exchanges in operation.
Major Disadvantages IP Network development delay Limited number of services to be offered Possible PSTN overload, due to the prevailing dial up Internet access and limited deployment of MSANs and DSLAMs 3.2.1 Scenario 2: Deployment of overlay packet based network Ongoing network consolidation (as for scenario 1 - optimal utilisation of the already installed TDM equipment) Deployment of IP-based overlay network Deployment of Multiservice access systems and DSLAMs for broadband services provision Initial (limited) deployment of VoIP services for enterprise and business customers
Figure 9: Scenario 2
Major Advantages
Optimal utilisation and Capitalisation on the existing TDM equipment The IP overlay network, combined with the Multiservice access systems initial step towards the future common packet based network Better services portfolio, especially for business and enterprise customers Reduced OPEX in the TDM part of the network Future save investments
Major Disadvantages Increased Opex Increased Capex
3.2.1 Scenario 3. Replacement of legacy TDM equipment Starting point of: Replacement of the existing PSTN equipment with packet based one Building up a common packet based network for voice, data and video Accelerated deployment of multiservice access systems Offering voice services via softswitch with local exchange functionality
Figure 10 Scenario 3
Major advantages Deployment of an unified packet based network for voice, data and video Investments are in a prospective technology Rich services portfolio, including multimedia services
Major disadvantages Part of the NGN equipment is still under research and development, IP based equipment is deployed mainly in enterprise networks major concerns about QoS CPEs require significant investments, if mass deployed
4. EoIP protocols
4.1 Introduction NGN is considered as converged network aggregating different functionalities of existing network with common IP/MPLS backbone. NGN network offers interoperability using multiple protocols. The main feature of NGN architecture is separation of service, transport and control layers, which are interconnected by open interfaces and use standards protocols as below:
Figure 11: : Protocol Stack for NGN
MEGACO/H.248 It is protocol which is sponsored from IETF and ITU. It is used inside one MGC (media gateway controller) for controlling media gateways (MG-s). This protocol allows the GC to tell to the MG-s when to send and receive information towards/from different addresses. This protocol also is useful for sending all information to the MGC from MG-s regarding with detected events such is: on hook, off hook etc. The equivalent protocol of MEGACO according to ITU is H248. SIP Session Initiation protocol is protocol that resides into application layer and is signaling protocol. SIP plays a very important role for session creation for audio/video conferences, interactive games and for call orientation towards IP network. SIP is IETF standard which supports traditional telephony services within IP domain such are: routing, identification, call establishment and other services. H.323 protocol This protocol is for multimedia conferences, including here: voice, video and data in packet switched networks. H323 standard can be applied in networks that which offers different services: IP telephony, networks for offering voice and data, video and data etc. The main components of H323 protocol are: terminals, Multipoint Control Units (MCUs), Gateways, Gatekeeper, Border Elements / Peer Elements. Real time protocol This protocol offers end-to-end voice transmission in real time. Whereas H323 is used for data transmission in IP based networks, the RTP protocol is used for data transmission in User Datagram Protocol (UDP). RTP together with UDP offers functionality to the transport protocol. The RTP protocol identifies the type of load, enumerates sequences, measures time etc. Real Time Control protocol (RTCP) It is a copy of RTP which offers control services. The main function of RTCP is identification of transport level for one RTP source
4.2 SIP The Session Initiation Protocol (SIP) is a signaling protocol for initiating, managing and terminating voice and video sessions across packet networks. SIP sessions involve one or more participants and can use unicast or multicast communication. Borrowing from ubiquitous Internet protocols, such as HTTP and SMTP, SIP is textencoded and highly extensible. SIP may be extended to accommodate features and services such as call control services, mobility, interoperability with existing telephony systems, and more. SIP is being developed by the SIP Working Group, within the Internet Engineering Task Force (IETF). The protocol is published as IETF RFC 2543 and currently has the status of a proposed standard.
Figure 12: SIP Call flow
4.2.1 Call Flow
Session Establishment: 1. The calling User Agent Client sends an INVITE message to Bobs SIP address: sip:bob@acme.com. This message also contains an SDP packet describing the media capabilities of the calling terminal. 2. The UAS receives the request and immediately responds with a 100-Trying response message. 3. The UAS starts ringing to inform Bob of the new call. Simultaneously a 180 (Ringing) message is sent to the UAC. 4. The UAS sends a 182 (Queued) call status message to report that the call is behind two other calls in the queue. 5. The UAS sends a 182 (Queued) call status message to report that the call is behind one other call in the queue. 6. Bob picks up the call and the UAS sends a 200 (OK) message to the calling UA. This message also contains an SDP packet describing the media capabilities of Bobs terminal. 7. The calling UAC sends an ACK request to confirm the 200 (OK) response was received. Session Termination The session termination call flow proceeds as follows: 1. The caller decides to end the call and hangs-up. This results in a BYE request being sent to Bobs UAS at SIP address sip:bob@lab.acme.com 2. Bobs UAS responds with 200 (OK) message and notifies Bob that the conversation has ended.
4.3 Migration from IPv4 to IPv6

4.3.1 Problems faced by IPv4 Non equal geographical distribution (>50% USA) Exhaustive use not achievable New technologies and features (mobile computing, multicast, security, QoS, Real-Time Services, etc.) Too complicated (e.g. Routing) Virtually impossible to reach 100% network utilization efficiency
4.3.2
Phases of IPv6 migration in NGN
The subsistent NGN are based on IPv4. Also, all subsistent user access requirements are based on IPv4. In the near future these networks would be replaced by IPv6-based NGN. However, giving the enormous scale of the current Internet, the migration period from the legacy IPv4-based NGN to all IPv6-based NGN is expected to be long. Hence, a prudent approach is to deploy IPv6 incrementally while keeping IPv4 access available. During the transition period, IPv6 migration would start from relevant small areas first, then, stretch into the core of the Internet; and at the same time, IPv4 network will become smaller and smaller, till vanish at the end. In this clause, migration period is divided into three phases. In each phase, NGN operators would structure their networks differently from IPv4/IPv6 point of view. This document also provides recommendations on how NGN operators should strategize their IPv6 migration in different phases. Phase 0: NGN with IPv6 The subsistent NGN is IPv4-based. IPv4 plays an essential role. There has no IPv6 networks deployed. In this phase, there is no IPv6 services provided at all. Correspondently, operator networks do not adopt any IPv6 functions.
Figure 13: Phase 0-Complete IPv4 based NGN

In this phase, IPv6 may be deployed in some customer networks locally. IPv6-based NGN islands may also be linked to each other through IPv6-over-IPv4 tunneling or protocol translation technologies. However, since operators networks do not provide IPv6 connectivity services, these IPv6 islands are totally isolated from NGN operators' perspectives. The NGN is still completely IPv4-based. Phase 1: Connecting IPv6-based NGNs across IPv4-based NGN At the early stages of IPv6 co-exists with native IPv4 environment, there would be only a few and isolated IPv6-based NGN, like islands, floating around IPv4-based ocean, as shown in Figure. The initial focus of this phase is on the migration and transition techniques, rather than dealing with traffic volume. In this phase, the most important IPv6 functional requirement for operators networks is to support IPv6 tunnels in IPv4 network. There may be limited number of IPv6-only hosts, but they should be able to communicate with legacy IPv4-only hosts, and also with each other through IPv4-based NGN, e.g., with 6PE support across IPv4-MPLS backbone.
Figure 14:Phase 1-Connecting IPv6-based NGNs across IPv4-based NGN
Phase 2: Connecting IPv6-based NGNs stack NGN
and IPv4-based NGNs across dual-
With increased IPv6 adoption, backbone routers would be upgraded to dual stack routers and form IPv4 and IPv6 logical dual-plane, where there exists a separate operation for IPv4 and IPv6, respectively, in data plane, control plane and management plane, and IPv4 and IPv6 run in the same physical network. In this phase, as shown in Figure, IPv4 and IPv6 logical planes are isolated from each other mutually. However, the same NGN devices may be used for both IPv4 and IPv6 logical planes. According to traffic situation, resources may be dynamically adjusted between IPv4 and IPv6 logical planes.
Figure 15: Phase 2-Connecting IPv6-based NGNs and IPv4-based NGNs across dualstack
Phase 3: Connecting IPv4-based NGNs with IPv6-based NGN The IPv4 address exhaustion will eventually result large scale adoption of IPv6 and thus IPv6-only NGN, as shown in Figure. In this phase, vast majority of business applications have moved to IPv6 network. Core backbone only supports IPv6. Sporadic small-size IPv4-based NGN may distribute around the large IPv6-based NGN. IPv4-over-IPv6 tunnels are required to support IPv4/IPv4 communication through IPv6-based NGN. Protocol translation would still be needed to allow IPv4 hosts access to IPv6 services.
Figure 16: Phase 3-IPv4 Islands with IPv6-based NGN
Phase 4: Completed IPv6-based NGN Finally, as shown in Figure , IPv6 will replace IPv4 totally. NGN will become pure IPv6-based.
Figure 17: Phase 4-Completed IPv6-based NGN
In this phase, there is no IPv4 connectivity service provided by NGN operators. Correspondently, operator networks do not adopt any IPv4 functions. In this phase, IPv4 may still exist in some customer network locally. IPv4-based NGN may also be linked to each other through IPv4-over-IPv6 tunnels or protocol translation mechanisms. However, since operators networks do not provide IPv4 connectivity service, these IPv4 islands are totally isolated from the NGN operators perspective. The NGN is completely IPv6-based.
Service aspects: Interoperability of services and networks in NGN

PSTN/ISDN evolution to NGN
5.1
A public switched telephone network or integrated services digital network (PSTN/ISDN) being one of the networks in telecommunication is considered to be a prime candidate for evolution to the next generation network. Because of the widespread deployment and the use of PSTN/ISDN, evolution to NGN should be considered as a step-wise approach. In PSTN/ISDN, most of the functionalities are located in a single exchange and may use proprietary protocols. However, in the NGN, functionalities may be distributed amongst several elements. The following clauses provide detailed steps for evolution of PSTN/ISDN to NGN.
5.1.1 Aspects to consider when evolving to NGN Transport Transport is an important part of any network. It encompasses functions related to: User premises equipments (e.g., terminals, PBXs, routers); The access network equipments (e.g., line terminating modules, remote or local concentrators, multiplexers); and The core network equipments (e.g., local exchanges, transmission facilities, transit and international exchanges). All transport-related aspects, which may be affected by evolution to NGN, should be considered.
Signalling and control PSTN/ISDN uses signalling systems such as analogue line signalling, channel associated signalling (CAS) like signalling systems R1, R2 and common channel signalling (CCS), like SS7 or DSS1. All these signalling systems are for the circuit switched networks. Since NGN transport is packet-based (and call and bearer are decoupled), other suitable types of signalling (e.g., BICC (Bearer Independent call
Control), SIP-I etc.) may be required. Also, the signalling function and call control function may reside in more than one NGN element. Since the NGN has to work with the PSTN/ISDN and other networks, interworking between NGN signalling systems and the legacy network signalling systems is required. Signalling aspects within the next generation corporate network shall remain independent from NGN access or core network signalling. It is further anticipated that signalling aspects for access and core networks be independent in order to provide the possibility for a step-wise approach for evolution to NGN. Management PSTN/ISDN management is comprised of activities from a core exchange network, access network, intelligent network and the operations support system (OSS). An NGN management system is comprised of three planes, namely the network management plane, the network control plane and the service management plane. Each of the three planes implements corresponding management functions to each layer in the NGN layered model. Standard interfaces between these planes need to be defined and are beyond the scope of this Recommendation. Evolution of PSTN/ISDN management (i.e., operations, administration and management) systems requires the ability to support the transition of PSTN/ISDN through intermediate stages towards NGN. More information may be available in documents related to NGN management. Services PSTN/ISDN services which are traditionally provided by PSTN/ISDN exchanges may be provided by application servers (ASs) in NGN. Some services may also be implemented on the call server (CS). It is expected that some or all of the legacy services will be provided by NGN. However, there is no guarantee that all services will be provided when PSTN/ISDN is simulated. Use of legacy terminals via adaptation to the NGN is expected in order to support existing services. Cooperation between ASs and CSs is required in order to provide certain services. In case of a concatenation of NGNs, it should be possible to access services from the remote NGN.
Bearer services While evolving from PSTN/ISDN to NGN, continuity of bearer services should be provided. PSTN/ISDN simulation provides functionality that is similar but not identical to existing N-ISDN bearer services. PSTN/ISDN emulation shall be capable of providing all bearer services offered by PSTN/ISDN. However, there is no requirement for NGN to support all N-ISDN bearer services. Use of NGN to connect PSTNs/ISDNs shall be transparent for all bearer services. NGN should provide same or better QoS for PSTN/ISDN bearer services.
Supplementary services While evolving from PSTN/ISDN to NGN, continuity of supplementary services should be provided to the extent practical. PSTN/ISDN emulation shall provide support for all supplementary services offered by PSTN/ISDN. PSTN/ISDN simulation provides functionality that is similar but not identical to existing PSTN/ISDN services. The NGN need not support all ISDN supplementary services. NGN shall appear transparent when used to connect supplementary services between PSTNs/ISDNs. Operation, administration and maintenance (OAM) OAM functionality is used to verify network performance, and to reduce operational expenses by minimizing service interruptions, service degradation and operational downtimes. As a minimum, when performing PSTN/ISDN evolution to NGN, the ability to detect faults, defects and failures such as lost, errored or misinserted packets, should be provided. Additionally, there should be mechanisms to indicate connectivity status and provide support for performance monitoring. Since multiple networks are involved in network evolution, it is necessary to identify and report which network or service provider is responsible for the defect so that proper action and remedy can be provided. Naming, numbering and addressing The NGN naming, numbering and addressing schemes, shall be able to interwork with the existing E.164 numbering scheme. During PSTN/ISDN evolution to NGN process, it should be ensured that the sovereignty of ITU Member States, with regard to country code numbering, naming, addressing and identification plans, is fully
maintained. Also, as a minimum, support should exist for Internet IP addressing schemes including E.164 Telephone uniform resource identifiers (TEL URIs), e.g., tel: +98 765 4321 and/or SIP Uniform Resource Identifiers (SIP URIs), e.g., sip:my.name@company.org. All this should be accomplished without affecting the services provided to end-users. Accounting, charging and billing It is generally accepted that the introduction of NGN will result in changes to the existing "accounting, charging and billing" procedures. However, these changes will not be immediate. During the transition period, maintaining the existing procedures, to the extent practical, may be required. Evolution from existing networks to NGN will also imply replacement of the existing sources of the accounting data generation. New business models for NGN services may increase number of business roles involved in charging. Thus, the following accounting aspects may be affected: a) Information content; b) Interfaces to other systems; c) Data format; d) Data security, i.e., data protection, transmission security and confidentiality. Considerations The NGN shall support both offline and online charging. For evolution to NGN, the following factors shall be considered. However, this does not constitute a comprehensive list. Information content the information contained in the call detail records (CDRs) shall be consistent with the information already provided in PSTN/ISDN. In particular, the following data should be provided: Calling and/or called user identification; Date and time of the event; Type of the service or event; Call duration or session duration. It is also necessary to provide new NGN specific information such as: Bandwidth; QoS; Media type. Data sources: Call server;
Media server; Access gateway; Trunking media gateway; Application server. Data format requirements: Optimal encoding complexity; Convenience of data collection and record construction; Optimal data size; Efficient data storage. Interfaces to other systems: For real time and bulk methods of collecting accounting data; For on-line and off-line charging; For other services such as advice of charge and credit limit.
. Interworking Interworking is used to express interactions between networks, between endsystems, or between parts thereof, with the aim of providing a functional entity capable of supporting an end-to-end telecommunication. PSTN/ISDN evolution to NGN should take the following into consideration: Ability to interwork with IMS-based or non-IMS-based networks such as other PSTN/ISDN, public IP networks (e.g., NGN, Internet); Ability for inter-domain, inter-area or internetwork interworking; Support for authentication and authorization; Ability to perform call admission control; Capability to support network performance parameters Support for accounting, charging and billing. NOTE The above list is not exhaustive. Call routing When an NGN coexists with PSTN/ISDN, the routing scheme should allow the carriers to control where their traffic enters and leaves the NGN. This will make it possible for the carrier to optimise use of their network resources and to avoid multiple points of interworking between NGN and PSTN/ISDN along the media path.
5.1.2 Service requirements by national regulatory bodies Where required by national/regional regulation or law, an NGN service provider shall provide: the basic telephone service with the same or better quality and availability as the existing PSTN/ISDN; the capability for accurate charging and accounting; capabilities to support number portability; capability for the user to select the carrier for local and long-distance calls; the availability of a directory inquiry service for PSTN/ISDN and the NGN users; support of emergency telecommunications as stated in clause 9; support for disaster recovery capabilities and procedures; support for all users, including the disabled. Support should provide at least the same capabilities as the existing PSTN/ISDN. NGN offers the opportunity for more advanced support, e.g., network capabilities for text to speech; privacy of the users and their information; mechanisms to support lawful interception and monitoring of various media types of telecommunications such as voice, data, video, e-mail, messaging, etc. Such a mechanism may be required of a network provider for providing access to content of telecommunication (CT) and intercept-related information (IRI) by law enforcement agencies (LEA), to satisfy the requirements of administrations and international treaties; interoperability between an NGN and other networks e.g., PSTN/ISDN and PLMN. The list of required services in public telecommunications systems in each country is based on national regulation. This Recommendation does not address detailed national regulatory requirements. 5.1.3 Emergency telecommunications in NGN It is desirable that NGN provides: capability to support priority mechanisms for emergency telecommunications in multimedia services (e.g., voice, data, and video). Emergency telecommunications include: a) individual-to-individual telecommunications; b) individual-to-authority telecommunications, i.e., calls to emergency service providers; c) authority-to-authority telecommunications. Telecommunications for disaster relief(TDR); and d) authority-to-individual telecommunications;
support for calls to emergency service providers which may be free of charge for the calling user. Such calls should include information on how to enable emergency services to call back the calling user, and including at least the accurate location information about the calling user at the time of call initiation, e.g., to be provided to the emergency response centres, routing of the call to the public safety answering point (PSAP), regardless of whether the user is fixed, mobile or nomadic. Accurate location may be such information as postal address, geographic coordinates or other information like cell indicators. Both network and user location information shall be provided, if available; capability to ensure that calling line identification presentation (or the equivalent information in IMS) is not ruled out on a per call, per line or per identity basis for calls to the emergency call number; network integrity, as far as possible, in order to support critical telecommunications such as TDR support in a crisis situation.
5.1.4 Security aspects of evolution The NGN shall provide at least the same security level as for the existing PSTN/ISDN. As PSTN/ISDN is transitioning to NGN, new concerns and threats, unknown in PSTN/ISDN, may be encountered. Therefore, additional measures may be required to guarantee at least the current security level. Different security dimensions, depending on the access method, shall be taken into account to fulfil this demand: Authentication; Non-repudiation; Data confidentiality; Telecommunication security; Data integrity; Availability; Privacy. The NGN security means may be used to secure PSTN/ISDN simulation and emulation scenarios.
5.1.5 Examples of network evolution scenarios All the NGN evolution scenarios rely upon the separation of functionalities of transport, control, service and management aspects.
The evolution scenarios imply one or more steps, depending on the extent to which these separations are implemented. Possible scenarios for evolution of the PSTN/ISDN are presented in the following subclauses. Core network evolution to NGN CS-based evolution to NGN General The CS is the core element for PSTN/ISDN emulation. It is responsible for call control, gateway control, media resource control, routing, user profile and subscriber authentication, authorization and accounting. The call server may provide PSTN/ISDN basic service and supplementary services, and may provide value-added services through service interaction with an external service control point (SCP) and/or AS in the service/application layer. A fully compliant call server implementation need only implement some of the components identified here, although it is possible to combine multiple functions in a single entity. A call server may function in one or more of the following roles: access call server (ACS) to implement access gateway control and media resource control functions, thus providing PSTN/ISDN basic service and supplementary services; breakout call server (BCS) to implement interworking functions to enable interconnection with PSTN/ISDN networks; IMS call server (ICS) to provide interoperability between PSTN/ISDN emulation components and IP multimedia components within a single NGN domain; gateway call server (GCS) to provide interoperability between different NGN domains from different service providers; routing call server (RCS) to provide the routing function between call servers. Consolidation of local and remote exchanges for evolution to NGN In order to prepare the PSTN/ISDN for the evolution to a packet switched network (PSN), and as an initial step, some of the LEs can be removed and all their functionalities such as control, accounting, etc. transferred to those remaining LEs. The affected UAMs, PBXs, and ANs are connected to the remaining LEs. Further consolidation occurs when UAMs become RUAMs, which are connected to the remaining LEs. Figure 18 shows this preparatory step.
Figure 18: 1Preparation for evolution to NGN
Scenario 1 PSTN/ISDN and PSN initially co-exist In the most likely initial approach for evolution of PSTN/ISDN to the PSN, the PSTN/ISDN will co-exist with the PSN during a transition period, as shown in Figure There are two steps in this scenario as explained below. Step 1 In this step, some of the LEs are replaced by AGs. Functions originally provided by the removed LEs are now provided by the AGs and the CS. In addition, some of the access elements such as UAMs, RUAMs, and PBXs, which were originally connected to the removed LEs, are now directly connected to AGs. Additional AGs may also be deployed to support new subscribers that directly connect to them. The TMGs and SGs are deployed for interconnection between the PSN and the TEs of the legacy network as well as other operators' PSTNs/ISDNs. The AGs and TMGs are all controlled by the CS. Step 2 In this step, the remaining LEs are replaced by the AGs, and the TEs are removed and their control functions are performed by CS. The TMGs and SGs are deployed for
interconnection between PSN and other operators' PSTNs/ISDNs. The AGs and TMGs are all controlled by the CS.
Figure 19:Realization of scenario 1
Scenario 2 Immediate use of PSN, initially via SGs and TMGs In this scenario, the PSTN/ISDN is immediately replaced by the PSN. As a first step, the LEs are connected to SGs and TMGs, while later on they are eliminated. The two steps are shown in Figure 5.3 and explained below.
Step 1 In this step, PSTN/ISDN is replaced by PSN and the TE functions are performed by the TMGs and the SGs under the control of the CS. The LEs are connected to the PSN via TMGs and SGs. The TMGs and SGs are also deployed for interconnection between PSN and other operators' PSTNs/ISDNs. Step 2 In this step, the LEs and some of the access elements such as UAMs and RUAMs are removed and their functions are provided by the AGs and CS. The PBXs are directly connected to the AGs. The ANs are either replaced by the AGs or are connected to the AGs. The TMGs and SGs are deployed for interconnection between PSN and other operators' PSTNs/ISDNs. The AGs and TMGs are all controlled by CS.
Figure 20: Realization of scenario 2
Scenario 3 The one-step approach In this scenario, the PSTN/ISDN is replaced with PSN in only one step as shown in Figure 21 The LEs are replaced by AGs and their functions are divided between the AGs and the CS. Specifically, the call control and accounting functions are all transferred to the CS. All access elements such as UAMs, RUAMs, and PBXs are connected to AGs. The ANs are either replaced by the AGs or are connected to PSN through the AGs. The TMGs under the control of the CS, and the SGs, are deployed to replace the TE functions and provide interconnection between PSN and other operators' PSTNs/ISDNs.
Figure 21:Realization of scenario 3
IMS-based evolution to NGN Figure 22 (below) shows a scenario where PSTN/ISDN evolves directly to a PSN based on the IMS core network architecture. The end-users access the network using NGN user equipment or legacy user equipment connected via an AG. The TMGs and SGs are deployed for interconnection between the NGN and other operators' PSTNs/ISDNs.
Figure 22:IMS-based PSTN/ISDN evolution to NGN
Concurrent CS-based and IMS-based networks Concurrent CS-based and IMS-based implementations can occur when an existing service provider deploys a separate IMS-based network for new services and supports the remainder of the services using a CS-based approach. These two types of network implementations need to interoperate. Interoperation is possible if SIP is used. Access network evolution Evolution of xDSL access network to NGN Evolution of access network (AN) is shown in three possible steps.
Step 1 Traditional AN/UAM interfaces include: POTS, ISDN. Such interfaces connect subscribers to the core PSTN/ISDN via LE. Legacy voice users may also have access to broadband services for example via xDSL. In this case, the customer-located equipment is an xDSL modem and the service provider equipment is a digital subscriber line access multiplexer (DSLAM). Since xDSL interfaces enable users to connect to the Internet, these interfaces may be utilized to connect such users to NGNs. AN, for another user domain with V5.x interface can be left as it is shown in Figure 3.6 or it can be completely replaced by AG connected to NGN directly. Step 2 The xDSL modem supports legacy subscribers and may enable them broadband access to NGN. An IP user may also use xDSL interface as the transport medium to an NGN. Protocol for xDSL interface may be Ethernet which enables broadband data flows and services, e.g., VoD, IPTV, VoIP and Internet. Step 3 In this step, the legacy end systems are replaced by NGN end systems and twisted copper lines are replaced by optical fibre, either fibre-to-the-curb (FTTC) or fibre-tothe-home (FTTH) to increase transmission speed. Protocol for this transmission medium may be Ethernet.
Figure 23:Evolution of xDSL access to NGN
Signalling and control scenarios A possible scenario for evolution of signalling in the core network consists of three steps: Step 1 In this step, signalling functions are transferred from the TEs to the independent units creating an STP mesh network (partial or complete).
Step 2 In this step, STPs are upgraded to the SGs and are placed on the edge between PSTN/ISDN and NGN. In this case, both the legacy network and NGN co-exist with each other. Step 3 In this step, all LEs and TEs are replaced by NGN.
Figure 24:Realization of signalling evolution scenario
Management scenarios Evolution of a PSTN/ISDN management system could be done in several possible ways. In one scenario, PSTN/ISDN is evolved to NGN but the PSTN/ISDN management system will be used to manage the newly evolved NGN. In another scenario, an NGN management system managing an NGN would also manage a PSTN/ISDN. This is not the extensive list of possible scenarios.
Billing system evolution scenarios The following three scenarios (see Figure 3.8) are considered when evolving to NGN. The timing or preference for selection of these scenarios is service provider dependent. Mediation (MED) is an entity which allows transfer and processing of call detail records (CDRs) from the PSTN/ISDN to the NGN billing system or from the NGN to the PSTN/ISDN billing system. Scenario 1 For this scenario, an NGN billing system is considered to handle both the PSTN/ISDN and the NGN. For this case, all accounting aspects are affected. Scenario 2 For this scenario, a new billing system is developed for the NGN, while keeping the existing PSTN/ISDN billing system. For this case, all accounting aspects are to be considered for NGN. Scenario 3 For this scenario, a legacy billing system is considered to handle both the PSTN/ISDN and the NGN. For this case, all accounting aspects are affected.
Figure 25:Billing system evolution scenarios
5.2
PSTN/ISDN emulation and simulation
PSTN/ISDN emulation provides most of the existing PSTN/ISDN service capabilities and interfaces using adaptation to an IP infrastructure. Although PSTN/ISDN emulation supports all PSTN/ISDN supplementary services, individual carriers may choose to deploy PSTN/ISDN emulation with support for only a sub-set of PSTN/ISDN supplementary services.
PSTN/ISDN simulation could also provide PSTN/ISDN-like service capabilities that potentially fulfil the same end-user need as existing PSTN/ISDN services. However, there is no guarantee that PSTN/ISDN simulation would provide all features that have been available to the PSTN/ISDN user. In addition, simulated PSTN/ISDN may provide additional new features and capabilities that have not been available to the users of PSTN/ISDN. Figure 1.9 provides a high-level presentation of how emulation and simulation is performed and the relationship between different networks and NGN. As shown in Figure 3.9, there are several ways that user equipment can be connected to an NGN providing either emulation or simulation of PSTN/ISDN. Pattern 1: In this case, the legacy user equipment is connected to an NGN through an adaptation function (e.g., ADF2) at the network side of the user-network interface (UNI). This configuration is used to emulate PSTN/ISDN. In this case the legacy user equipment continues to be used. Pattern 2: In this case, the legacy user equipment is connected to an NGN through an adaptation function (e.g., ADF1) at the user side of the UNI. This configuration is used when there is a desire to use legacy user equipment while PSTN/ISDN is being simulated. In this case, the legacy user equipment continues to be used. Pattern 3: In this case, the NGN user equipment directly connects to NGN.
Figure 26:Emulation, simulation, interoperability and interworking with NGN
5.2.1 Interfaces In discussing PSTN/ISDN emulation and simulation, several different networks are considered to accommodate both IMS-based and non-IMS-based scenarios. Two interfaces are to be dealt with. These are the user-network interface (UNI) and the network-network interface (NNI). The following provides details for these interfaces. Interface type 1, IF1: This interface is between the user equipment and a network element in NGN or non-NGN networks which may also contain an adaptation function. This is a user-network interface (UNI). It can be: between an NGN user equipment and the NGN; between an IP user equipment and the public IP network;
analogue telephone interface between the legacy user equipment and PSTN/ISDN; access networks using access nodes (e.g., multiplexer, concentrator) with V5 signalling, PSTN interface provided according to national mappings, V5.1 and V5.2 interfaces for support of access network (AN); national variants of the above.
Interface type 2, IF2: This is a network-network interface (NNI). It can be between: NGNs; an NGN and the PSTN/ISDN; an NGN and a public IP network; an NGN and public land mobile network (PLMN). 5.2.2 Adaptations The adaptation function may be implemented in the access gateway or the residential gateway. This function interfaces to IP multimedia component using SIP and to PSTN/ISDN terminals, and provides PSTN/ISDN emulation and simulation services. This function contains both a media gateway function and a media gateway controller function and supports the provision of voice-based services to analogue lines and ISDN lines. The function is "call control aware" (due to the termination of SIP) as opposed to "call control agnostic" H.248-based access media gateways. Adaptation function type 1 (ADF1): ADF1 allows the NGN to provide a full NGN account, including user and service profiles, to the user equipment. From an NGN perspective, the user is receiving a normal NGN service that is essentially indistinguishable from any other NGN service. (As is the case with all NGN services, in practical implementations it is still subject to limitations of the user equipment). ADF1 is typically implemented in a residential gateway. Adaptation function type 2 (ADF2): ADF2 allows the user equipment to receive a standard PSTN/ISDN service, which is essentially indistinguishable from the PSTN/ISDN service provided by legacy technologies. From an NGN perspective, a "PSTN/ISDN emulation" service is being provided. In general, user and service profiles will not be associated with this account. ADF2 is typically implemented in access gateway.
5.3
Call server-based PSTN/ISDN emulation
The term "call server-based" indicates that service control logic and service execution environment is primarily located in a call/session control server (CSCS; briefly call server (CS)). The CS is therefore the responsible network entity for service delivery (often also called as "anchor point of services"). This function relates to the service switching function (SSF) in PSTN/ISDN. Completely opposite to the CS-based service control concept is the IMS-based approach, because the application server (AS) houses the service control logic and service execution environment behind CSCS entities.
5.4
ENUM
It comprises a set of standard and mechanisms for transforming public telephone numbers into unique domain names to be used in NGN, enabling providers and users to continue to use telephone numbers which is beneficial for the shift from the existing public switched telecommunication environment to an Internet Protocol based environment and for the integration of new IP multimedia services. Telephone numbers in their standard format are not supported in the core NGN networks based on IP, where generally the URI format or other IP-based identifiers are used. For users as well as for providers, being able to continue to use telephone numbers is considered crucial for the shift from the classic telephone service to Internet telephony and for the integration of new IP multimedia services. User ENUM, a standard developed by the IETF is conceived for this purpose; it offers a mechanism for transforming public telephone numbers into unique domain names. 5.4.1 Types of E-NUM User ENUM, also referred to as public ENUM, has the aim to give the end user (the holder of a telephone number) control over his communications. It allows end users to opt-in with their existing telephone numbers to provide other users with the capability to look up contact details that the user has linked to his number on the Internet. User ENUM was conceived as the global, public directory-like database marrying the telephone numbering system with the Internet.
Infrastructure ENUM or Carrier ENUM: It supports routing and interconnection of call. It is used between carriers with the purpose of sharing subscriber information in peering relationships. In this case the carriers themselves control subscriber information. These implementations are also referred to as private ENUM when carriers or VoIP providers use ENUM only in their own network. User ENUM is the concept of a global, public directory-like database, with subscriber opt-in capabilities and delegation at the national level in a national Internet domain zone (the e164.arpa domain). User ENUM is mainly referred to as public ENUM. The mirror of the telephone number, detached from its original PSTN function, has the attributes of a domain name. A feature of ENUM called NAPTR (Naming Authority Pointer records) is the association of data to the ENUM domain name. NAPTR can be used to specify all data necessary to identify available services connected to the individual ENUM domain. The NAPTRs containing service preferences can easily be queried from the public Internet in order to start communication sessions according to the preferences found in the additional data. NAPTR records can be stored on the registry level or on a lower level at the registrar level enabling decentralized architecture with distributed ENUM databases. User ENUM is being deployed on a national basis and case by case following the instructions as agreed between the Internet Architecture Board (IAB) and ITU. Since 2002 approximately 45 national registries have successfully applied for the delegation of the User ENUM zone of their country. Despite the large number of deluges, only 8 registries are in production phase and less than 1 million telephone numbers are now entered in User ENUM, which is still very low compared to more than 4.5 billion allocated telephone numbers worldwide.
Figure 27:ENUM
Carrier ENUM as a technology however, detached from its original user centric approach, has been embraced by many parties involved in managing VoIP calls (with the exception of webbased peertopeer VoIP calls), whether purely IP, such as VoIP providers building new all-IP networks, whether the legacy networks and the mobile world. Common to all these deployments of the ENUM mechanism is the fact that carriers (network operators and providers) will be in control and populate their databases with the call termination preferences related to their subscribers telephone numbers. The use of the ENUM mechanism as a means to enable intelligent routing and termination of calls between networks between carriers and providers has been taken up in several ways. While efforts take place to standardize ENUM for carriers, called Infrastructure ENUM many private forms are being deployed today in the market place, called Carrier ENUM or Operator ENUM. In general Carrier ENUM or Operator ENUM is also referred to as private ENUM when a carrier, VOIP operator or ISP uses ENUM techniques within its own networks.
Figure 28:ENUM infra
Impact on telephone numbering policy The increased use of ENUM mechanisms accelerated developments in numbering already triggered by the uptake of IP and convergence. The telephone number is the anchor point within the ENUM mechanism and it is the entry leading to various services preferences. Thus, besides linking telephone numbers to IP telephone addresses such as SIP, which is now the main application area, the ENUM mechanism could also be used for unified messaging like applications, diverting calls to mobile phone numbers, e-mail addresses and voice-mail systems and, as the ENUM mechanism is set up technology neutral, it could be used for services beyond the communication remit, such as linking the telephone number to web pages or GPS coordinates. Number detachment On the one hand numbers are getting more detached from their original narrow purpose, while on the other hand the importance of the number increases as an identifier for the user or subscriber rather than the service. ENUM the detachment from the original voice service applies, meanwhile enforcing the subscribers relation through the telephone number. Similar to number detachment is the still early development of the telephone number evolving into a meta identifier. Increasingly
end user equipment is able to communicate through various channels and protocols, such as GSM, Bluetooth, Skype, MSN, etc. Metaclient applications incorporated in these multifunctional devices could support various communication services with different identifiers, but they need one overarching meta-identifier, by which the end users service preferences can be traced. A natural candidate for a meta identifier is the main telephone number, and service preferences could be set up in private or public ENUM databases. Number detachment also reinforces the users perception of the number being his number and his need to maintain the number regardless of the service or provider attached. Thus, as the ENUM mechanism takes root, the linkage between telephone number and service and service provider will be under attack and the telephone number will evolve more into a personal identifier. While it still has to be assessed which challenges these developments will pose for regulators, they will in any case increase the pressure on regulators to broaden the uses for existing numbers, to extend the possibilities of direct allocation to end users and to allow portability between PSTN-based and IP-based services. The introduction of service portability between dissimilar services is a more complex issue involving operators and consumers interests and the regulatory environment. The life cycle of telephone numbers A seamless transition to NGN, while keeping the huge installed base of subscribers using telephone numbers at the edges of their networks untouched, is in the interest of carriers. Numbering changes have historically been costly and impacting carriers as well as end users. Provided the national telephone numbering schemes keep updated according to the changing markets needs, and the role of telecommunication regulators as neutral allocation bodies is not subject to discussion and maintained, as is now generally the case, it is expected that telephone numbers will stay key identifiers for telecommunication services for the foreseeable future, even despite the use of IP and the surge of new address schemes in NGN. The ENUM mechanism integrates telephone numbers in the new IP environment and may make them interoperable with other identifiers. As the ENUM mechanism anchors telephone numbers in NGN it could even be a factor for expanding the lifespan of the E164 telephone numbering scheme. Number Portability The use of the ENUM mechanism leads to the creation of many private ENUM databases in the control layer of networks, providing the combination telephone number hosting provider. These lists, although used in a private setting, are essentially fulfilling the same function for VoIP as the LNP databases (Local Number
Portability) have for the PSTN wire line and wireless voice. They support the lookup function for providers in order to route VoIP calls to their proper destination at another network. Local Number Portability databases do not provide a viable alternative as these databases do not manage alternative addresses besides telephone numbers. Most currently deployed LNP databases are also not designed or equipped to integrate IP/DNS based queries. The ENUM mechanism in combination with DNS database technology associating data with numbers, such as call routing preferences and tariffs, is therefore the natural candidate for next generation number portability platforms. New GSMA IPX service model is planning to roll out the private ENUM domain e164enum.net and the corresponding ENUM databases linked to the domain will eventually cover their 3 billion mobile subscribers, containing the call termination preferences related to their telephone numbers.
7. Services
Although it is difficult to predict what the next killer applications will be, we can infer the types of service characteristics and capabilities that will be important in the NGN environment by examining current service-related industry trends. It is certainly true that we are moving from Time Division Multiplex (TDM)-based, circuit switched networks to packet-, cell-, and frame based networks. However, these changes in the transport networks are merely enablers for the dramatic changes we will see at the service level. The major thrust of traditional network service providers has been to offer the mass market basic transport of information between end users, with various value-added capabilities. These services tended to involve narrowband voice calls, with a single point-to-point connection per call. However, this view of services is rapidly changing as the worlds economies are becoming increasingly reliant on information as a basic resource. While existing services will remain part of service providers offerings, customers expectations will migrate towards more advanced broadband multimedia and information intensive services. End users will interact with the network via sophisticated CPE, and be able to select from a wide range of Quality-of-Service (QoS) and bandwidth. In the future, network intelligence will not just relate to the creative routing of connections based on simple database look-ups, but may take on a much broader meaning (e.g., multimedia session management, coordination of multi technology connections, intelligent management/operations, advanced security, true user agents, user-installable scripts/applets, on-line directory services, and proxy agents). The current evolution of telecommunication services points to a world where service providers will have the flexibility to focus on micro-marketing (as opposed to mass-marketing). Decisions about their service offerings may have as much to do with packaging (e.g., pricing, bundling, marketing, and convenience), as they will with the actual services offered. As multiple carriers, service providers, equipment vendors, and other business entities all become involved in providing services to end users, federated network and business systems will become increasingly important. The primary goal will be to enable users to get the information content they want, in any media/format, over any facilities, anytime, anywhere, and in any volume. Based
on the abovementioned trends, the following is a summary of several service characteristics likely to be important in an NGN environment: Ubiquitous, real-time, multi-media communications - The only hope for dramatically increased fidelity, akin to communicating in person, is high-speed access and transport for any medium, anytime, anywhere, and in any volume. More personal intelligence distributed throughout the network - This includes applications that can access users personal profiles (e.g., subscription information and personal preferences), learn from their behaviour patterns, and perform specific functions on behalf of them (e.g., intelligent agents that notify them of specific events or that search for, sort, and filter specific content). More network intelligence distributed throughout the network - This includes applications that know about, allow access to, and control network services, content, and resources. It can also perform specific functions on behalf of a service or network provider (e.g., management agents that monitor network resources, collect usage data, provide troubleshooting, or broker new services/content from other providers). More simplicity for users - This shields users from the complexity of information gathering, processing, customization, and transportation. It allows them to more easily access and use network services/content, including user interfaces that allows for natural interactions between users and the network. It involves providing context-sensitive options/help/information, transparently managing interactions among multiple services, providing different menus for novices vs. experienced users, and providing a unified environment for all forms of communication. Personal service customization and management - This involves the users ability to manage their personal profiles, self-provision network services, monitor usage and billing information, customize their user interfaces and the presentation and behaviour of their applications, and create and provision new applications. Intelligent information management - This helps users manage information overload by giving them the ability to search for, sort, and filter content, manage messages or data of any medium, and manage personal information (e.g., calendar, contact list, etc.).
7.1.
Specific Services for next generation networks
Although we have a feel for the types of service characteristics that will be important in an NGN environment, no one really knows what the killer applications will be. Fortunately, the Next Generation Service Architecture will enable a number of key features that can be particularly beneficial to a wide array of potential services. A variety of services, some already available, others still at the conceptual stage, have been linked to NGN initiatives and considered likely candidates for NGN implementations. While some of these services can be offered on existing platforms, others benefit from the advanced control, management, and signalling capabilities of NGNs. Although emerging and new services are likely to be the strongest drivers for NGNs, most of the initial NGNs profits may actually result from the bundling of traditional services. Thus, bundled traditional services will pay for the network, whereas emerging services will fuel the growth. Most traditional services relate to basic access/transport/routing/switching services, basic connectivity/resource and session control services, and various value-added services. NGNs will likely enable a much broader array of service types, including: Specialized resource services (e.g., provision and management of transponders, multimedia multipoint conferencing bridges, media conversion units, voice recognition units, etc.) Processing and storage services (e.g., provision and management of information storage units for messaging, file servers, terminal servers, OS platforms, etc.) Middleware services (e.g., naming, brokering, security, licensing, transactions, etc.) Application-specific services (e.g., business applications, e-Commerce applications, supply-chain management applications, interactive video games, etc.) Content provision services that provide or broker information content (e.g., electronic training, information push services, etc.) Interworking services for interactions with other types of applications, services, networks, protocols, or formats (e.g., EDI translation) Management services to maintain, operate, and manage communications/computing networks and services. Figure 29. below and the following text give a brief description of several services that we currently believe will be important drivers in the NGN environment (e.g., in terms
of how pervasive they will be, how much profit margins they are likely to generate, how much they will benefit from an NGN type of environment, and/or how glamorous they are). We intentionally included a broad range of services (e.g., from basic voice telephony to more futuristic services such as Distributed Virtual Reality) to emphasize that the Next Generation Service Architecture will support a wide variety of services.
Figure 29:Example NGN Service Drivers
Voice Telephony NGNs will likely need to support various existing voice telephony services (e.g., Call Waiting, Call Forwarding, 3-Way Calling, various AIN features, various Centrex features, and various CLASS features). Note, however, that NGNs are not trying to duplicate each and every traditional voice telephony service currently offered. Rather, they will likely attempt to support only a small percentage of these traditional services, with an initial focus on the most marketable voice telephony feature and the features required from a regulatory perspective. Data (Connectivity) Services Allows for the real-time establishment of connectivity between endpoints, along with various value-added features (e.g.,
bandwidth-on-demand, connection reliability/resilient Switched Virtual Connections [SVCs], and bandwidth management/call admission control). Multimedia Services Allows multiple parties to interact using voice, video, and/or data. This allows customers to converse with each other while displaying visual information. It also allows for collaborative computing and groupware. Virtual Private Networks (VPNs) Voice VPNs improve the inter location networking capabilities of businesses by allowing large, geographically dispersed organizations to combine their existing private networks with portions of the PSTN, thus providing subscribers with uniform dialling capabilities. Data VPNs provide added security and networking features that allow customers to use a shared IP network as a VPN. Public Network Computing (PNC) Provides public network-based computing services for businesses and consumers. For example, the public network provider could provide generic processing and storage capabilities (e.g., to host a web page, store/maintain/backup data files, or run a computing application). The public network provider would charge users for the raw processing and storage used, but would have no knowledge of the specific content/application. Alternatively, the public network provider could provide specific business applications (e.g., Enterprise Resource Planning [ERP], time reporting, vouchers, etc.) or consumer applications (e.g., Tax Cut, kitchen remodelling program, etc.), with all or part of the processing/storage happening in the network. The public network provider could charge based on an hourly, daily, weekly, etc. licensing fee for the service (e.g., rent-an-app). Unified Messaging Supports the delivery of voice mail, email, fax mail, and pages through common interfaces. Through such interfaces, users will access, as well as be notified of, various message types (voice mail, email, fax mail, etc.), independent of the means of access (i.e., wire line or mobile phone, computer, or wireless data device). Information Brokering Involves advertising, finding, and providing information to match consumers with providers. For example, consumers could receive information based on pre-specified criteria or based on personal preferences and behaviour patterns. E-Commerce Allows consumers to purchase goods and services electronically over the network. This could include processing the transactions, verifying payment information, providing security, and possibly trading (i.e., matching buyers and sellers who negotiate trades for goods or services).
Home banking and home shopping fall into this category of services. This also includes business-to-business applications (e.g., supply-chain management and knowledge management applications). Call Centre Services A subscriber could place a call to a call centre agent by clicking on a Web page. The call could be routed to an appropriate agent, who could be located anywhere, even at home (i.e., virtual call centres). Voice calls and e-mail messages could be queued uniformly for the agents. Agents would have electronic access to customer, catalogue, stock, and ordering information, which could be transmitted back and forth between the customer and the agent. Interactive gaming Offers consumers a way to meet online and establish interactive gaming sessions (e.g., video games). Distributed Virtual Reality Refers to technologically generated representations of real world events, people, places, experiences, etc., in which the participants in and providers of the virtual experience are physically distributed. These services require sophisticated coordination of multiple, diverse resources. Home Manager With the advent of in-home networking and intelligent appliances, these services could monitor and control home security systems, energy systems, home entertainment systems, and other home appliances. Imagine youre watching television and the doorbell rings no problem you just use the TVs remote to get a view of your front entrance to see whos there. Or imagine monitoring your house while youre away on a trip, or your in-house nanny watching your children while youre at work.
8 Generalized Mobility
8.1
Introduction
NGN continues to evolve towards the convergence of fixed networks and wireless mobile networks, and thus there is a crucial need to identify the requirements for mobility management to provide mobility for the users and services in the NGN environment. The rationale behind NGN is the convergence of fixed and wireless networks and ultimately migration to interoperable and harmonized network architectures. This trend has caused an industry need to provide seamless services transparently to the users across different access network (AN) arrangements.
Mobility management is an essential requirement for NGN users to communicate anytime and from anywhere. This could be facilitated through the use of various wireline or wireless access technologies to enable users to communicate over heterogeneous network environments. In particular, with the massive growth in the number of users and the continuing deployment of heterogeneous systems, the demand to provide seamless services to the NGN users gets stronger with time, and such pursuits present new challenges and requirements for new types of MM that could provide seamless services across heterogeneous networks. A promising solution for the new type of MM in NGN should take into account the long-term trends for future networks, the need for a smooth evolution of the infrastructure, and also the issue of backward compatibility with existing networks.
8.2
Considerations for mobility management in NGN
This clause describes the generic features and considerations associated with mobility management so as to facilitate the identification of MM requirements and protocols for NGN. 8.2.1 Network environments
In the NGN, it is expected that a variety of the existing and new wired/wireless access network technologies are supported, such as WLAN, xDSL and 2G/3G mobile networks etc., as shown in Figure 30. Each of the access networks is connected to the NGN core network (CN), to provide the same set of services for users, preferably independently of the access network type.
Figure 30: Envisioned network environment of NGN
8.2.2
General mobility management features
Mobility has been used a little differently according to its application areas. However, the general feature of the mobility could be described as follows: Moving object
Mobility management can be classified as follows according to what moves: Terminal mobility This is the mobility for those scenarios where the same terminal equipment is moving or is used at different locations. The ability of a terminal to access telecommunication services from different locations and while in motion, and the capability of the network to identify and locate that terminal.
Network mobility The ability of a network, where a set of fixed or mobile nodes are networked to each other, to change, as a unit, its point of attachment to the corresponding network upon the network's movement itself. Personal mobility This is the mobility for those scenarios where the user changes the terminal used for network access at different locations. The ability of a user to access telecommunication services at any terminal on the basis of a personal identifier, and the capability of the network to provide those services delineated in the user's service profile. Service mobility This is the mobility, applied for a specific service, i.e., the ability of a moving object to use the particular (subscribed) service irrespective of the location of the user and the terminal that is used for that purpose.
Features by service continuity
Mobility also could be classified as shown in Figure 4.11 according to service continuity.
Figure 31: Mobility classifications according to service quality Service continuity The ability for a moving object to maintain ongoing service over including current states, such as user's network environment and session for a service. This category includes Seamless Handover and Handover.
Seamless handover: It is a special case of mobility with service continuity since it preserves the ability to provide services without any impact on their service level agreements to a moving object during and after movement. Handover: The ability to provide services with some impact on their service level agreements to a moving object during and after movement.
Service discontinuity The ability to provide services irrespective of environment changes of a moving object, but not to be able to maintain ongoing service. This category includes Nomadism and Portability. Nomadism: Ability of the users to change their network access point on moving. When changing the network access point, the user's service session is completely stopped and then started again, i.e., there is no service continuity or hand-over used. It is assumed that normal usage pattern is that users shut down their service session before attaching to a different access point. Portability: Ability of a user identifier or address to be allocated to different systems when the user moves from one location to another.
Mobility layer
The layer concept is used to classify mobility management. Horizontal mobility Mobility on the same layer. Generally, it is referred to as the mobility within the same access technology. Vertical mobility Mobility between different layers. Generally, it is referred to as the mobility between different access technologies.
8.2.3
Considerations on user part
NGN needs to consider more general types of user parts, i.e., user network, as well as simple forms like user terminals as depicted in Figure 4.12 below. It shows a user network with multiple Service Platforms and each Service Platform may run multiple Service Applications. In such user networks, multiple users may associate themselves with one or more service
applications, by providing one of their user identifiers to the application. For example, this might typically be a SIP URL. The service application is bound to a TCP/IP socket of the Service Platform Interface. The SPI binds itself to an access network-specific Network Termination via the user's connectivity network. Finally, the network termination is bound to the Network Attachment Point of the access network.
Figure 32: User network configuration
Only one Network Termination is shown in the user network, but multi-homing may be considered. In this user network scenario there is a many-to-one relation between the different types of endpoints. A mobile terminal may represent a limit case where there is a one-to-one relation between the user and the service application, the service application and the service platform interface, and between the service platform interface and the network termination.
8.2.4
Mobility management functionalities
MM in NGN will be realized by using basic mobility-related functionalities plus associated functionalities. The basic functionalities are concerned directly with mobility management for mobile users and terminals, whereas the associated functionalities are used for supporting
MM or for exchanging related information for overall control and management purposes. The basic MM functionalities include location and handover management. Location management Location management is performed to identify the current network location of a Mobile Terminal (MT) and to keep track of it as it moves. Location management is used for the control of calls and sessions terminated at the MT. Location information is given to the call or session manager for establishing a session. With the help of location management, the correspondent node is able to locate the MT and establish a session via appropriate signalling. Location management consists of two basic functions: location registration and call delivery/paging. The location registration is the procedure to register the current location when MTs change the attachment point to the network. Call delivery is to deliver packets to the destined MTs and paging is used to search the MTs in dormant mode.
Handover management Handover management is used to provide MTs with session continuity whenever they move into different network regions and change their point of attachment to the network during a session. The main objective of seamless handover is to minimize service disruption due to data loss and delay during the handover. Most MM protocols perform handover management together with an appropriate location management scheme. According to the handover areas concerned, the handover types can be classified into "handover within an AN", where the MT moves within a region covered by the same AN in NGN, and "handover between different ANs or CNs", where the MT changes its concerned access system for ongoing sessions.
8.3
Classification of mobility management
Various types of mobility exist in NGN environments. Mobility management requirements also are different according to mobility types. This Recommendation only considers the classifications illustrated in Figure 4.13. In Figure 4.13, the MM issues for NGN are classified into Intra-Network MM and Inter-Network MM. Intra-Network MM is further subdivided into Intra-AN MM and Inter-AN MM.
Figure 33:Classification of MM
8.3.1
Intra-CN MM
"Intra-CN" MM addresses MM issues within a network. It can be subdivided into "Intra-AN" MM and "Inter-AN" MM. Intra-AN MM "Intra-AN" MM addresses MM issues within an AN. In Figure 4.13, for example, MM within AN1 of CN1 can be classified as Intra-AN MM, marked as '3' in the figure. Inter-AN MM "Inter-AN" MM addresses MM issues between different ANs within the CN. Inter-AN MM can be further classified into the following two sub-types: 1) MM between the same type of ANs (e.g., MM between two AN1s within the CN1, marked as 2a in Figure 4.13); and
2) MM between different types of ANs (e.g., MM between AN1 and AN3 within CN1, marked as 2b in Figure 4.13).
8.3.2
Intra-Network MM (Inter-CN MM)
Inter-Network MM will always accompany the MM issues between two ANs, i.e., Inter-AN MM. In addition to those, Inter-Network MM must handle the MM issues that occur with MT handovers across different core networks (i.e., Network-to-Network Interface (NNI)), such as user authorization and Service Level Agreement (SLA) negotiation. In Figure 4.13, for example, the MM between CN1 and CN3 is Inter-Network MM, marked as '3' in the figure.
8.4
Requirements for mobility management
The MM requirements could be given differently according to MM types such as Inter-CNs, Inter-ANs, and Intra-AN. The main differences of MM requirements are summarized in the following table.
Administration
Access Technology
Inter-CN MM Different Same/Different a) Inter-AN MM Same Same/Different Intra-AN MM Same Same a) For the case of Network Sharing, the same physical core network supports two logical CNs.
Note that the following requirements are only minimum requirements, so better features could be provided in each MM type in practice. Also, this mainly focuses on IP-based new ANs rather than legacy ANs which may already have their own MM solutions.
8.4.1
General requirements
This describes a set of general requirements for MM in NGN regardless of MM types. Harmonization with IP-based networks The NGN is envisaged to be IP-based. Accordingly, the MM protocols for NGN should be IPbased or, at least, well-harmonized with IP technology for its efficient and integrated operation in such future networks. It is also recommended to reuse to the extent possible the existing MM techniques/technologies for the design of the MM protocols for NGN, potentially through cooperation with external forums and SDOs.
Separation of control and transport functions The transport plane should be separated from the control plane for efficient mobility management and scalability. Such separation of control and transport planes provides the architectural flexibility that facilitates the introduction of new technologies and services. Open interfaces between the control plane functions and the transport plane functions are necessary to implement their separation. Provision of a location management function To support the mobility of users/terminals, the location of users/terminals are tracked and maintained by one or more location management functions whenever they move. In harmony with the overall IP-based structure envisaged, location management should be based on an IP-specific approach such as the Mobile IP Home Agent or the SIP registrar. Location management can be expanded to provide location information to service applications. Provision of mechanisms for identification of users/terminals The MM protocols in NGN must specify how the users/terminals are to be identified in the networks or systems for mobility management. This identification functionality will be the first step to be taken in the mobility management process and thus used for authentication, authorization and accounting of users/terminals. QoS support The MM protocols must support QoS, which mobile users require, to support QoS-required services such as VoIP, streaming, and so on as well as convenient Internet best-effort services. However, the required level of QoS could be different according to MM types which are described in Figure 4.13.
Interworking with established AAA and security schemes The MM protocols for NGN must specify how users/terminals are to be authenticated, authorized accounted, and secured for services using standard Authentication, Authorization and Accounting (AAA) and security mechanisms. The result of the AAA functionality will be a yes/no decision on the service request made by a user. As a next step, the access network configuration will be adapted to the mobile/nomadic user such that it satisfies the particular Quality of Service (QoS) level and security association for the requested service. These mechanisms should be based on the user's subscription profile and the technical resource constraints of the respective access networks. Location privacy The location information of particular users should be protected from non-permitted entities. This will entail mutual authentication, security association, and other IP security requirements between the mobile terminal and the location management function. Support of network mobility NGN are envisioned to include moving networks as well as moving terminals. Typical example platforms for moving networks could be bus, train, ship, aeroplane and so on. The MM protocols in NGN need to efficiently support these kinds of moving networks. Support of ad hoc networks The support for ad hoc networks is essential because this kind of network is envisioned as one of the major access technologies in NGN. Resource optimization The provision of the scheme for resource optimization is required to save power consumption in the terminals and signalling overhead in network side. The resource optimization should be provided to the terminals in idle mode as well as in active mode. The support of resource optimization for idle mode terminals is mainly achieved with a paging procedure and this procedure is usually tightly coupled with location management. Support of IPv4/IPv6 and public/private addresses Currently, IPv4 is dominant but IPv6 is being expected to be widely deployed in the near future. Accordingly, the MM protocols must support IPv6 as well as IPv4. In addition, note that users/terminals may use their private address rather than public IP addresses according to the network environment regardless of IP version. Accordingly, MM should allow for the use
of private addresses. In this case, a proxy agent might be needed to support MM-related operations such as location update and paging.
Provision of personal and service mobility To realize diverse applications in NGN, personal and service mobility, which are defined in general mobility management features as well as terminal mobility must be provided. User data accessibility Services and other network functions require some user data in order to be appropriately customized. These can be either "user subscription data" or "network data". Support of several kinds of mobile endpoints In the NGN environment there are different types of mobile endpoints to be considered. The mobile endpoint can be an application in SIP, interface in the Mobile IP, and so on as well as it can be in a core network, an access network, a user-premises network or a service platform. So, each network related to the mobile endpoints should be able to support the mobility of every mobile endpoint.
Maintenance of binding information There are many types of bindings for services as follows: between a user and a service application; between an application and a network interface card; between a Service Platform and a Network Termination; between a Network Termination and a network access point; between two different access networks. In NGN environment, all the above bindings should be maintained to support mobility. Because of this, binding information needs to be maintained in a relevant place.
8.4.2
Requirements for Inter-CNs MM
This subclause describes a set of requirements specific to Inter-CNs MM in NGN.
Independence from network access technologies It is expected that NGN will consist of an IP-based core network with several access networks that may use different access technologies, as shown in Figure 4.11. In this architecture, MM should provide mobility between either homogeneous or heterogeneous types of access networks that belong to the same or different operators. Accordingly, it is required that MM be independent of the underlying access network technologies such as 2/3G Cellular, WLAN, etc. Effective interworking with existing MM protocols Existing ANs are likely to use their own MM instead of new MM. Accordingly, the NGN MM must be able to effectively interwork with the existing MM protocols. 8.4.3 Requirements for Inter-ANs MM
This subclause describes a set of requirements specific to Inter-ANs MM in NGN.
Independence from network access technologies The same requirements apply as those listed for Inter-CN MM under 4.4.2.1.
Provision of mechanisms for context transfer When an MT moves across different networks, the context information of the current session, such as QoS level, security method, AAA mechanism, compression type in use, etc., might be helpful in performing the handover of the session to the new access network (e.g., minimizing the latency involved in handing the session over to new serving entities). The proper use of a context transfer mechanism could substantially reduce the amount of overhead in the servers that are, respectively or in a combined manner, used to support QoS, security, AAA, and so on.
Effective interworking with existing MM protocols Existing ANs are likely to use their own MM instead of new MM. Accordingly, the NGN MM must be able to effectively interwork with existing MM protocols.
Provision of a handover management function for seamless services MM should support handover management for maintaining session continuity during movement. Furthermore, those mechanisms should provide fast handovers to cater for seamless non real-time and real-time service requirements (e.g., VoIP and video streaming). In Inter-ANs MM, the handover might be a vertical handover between ANs with different access technologies because a CN can connect to various kinds of ANs. Support of policy-based and dynamic network selection After detecting the presence of a wireless network, it should be possible for the user to choose to connect to one of the networks to obtain service, based on the following policies driven by the requirements of the service or application to be used, and presented to the user. NOTE If the information is presented to a user, the user should not be expected to have enough technical knowledge about the parameters listed to take an appropriate decision. Rather, these should be looked after by the service's application software, and the options presented to the user should be only those that can support the needs of the service or application to be executed: Quality of Service level needed for a particular service, e.g., bandwidth availability, time delay, packet loss ratio; Cost for the particular service in each network (it is presumed that the networks will provide cost information as part of the options); Security level that the network can provide. Once connected, the terminal should be able to track information of the current network based on the above-mentioned aspects. For example, when a user detects that the QoS level has gone down, it can handover the service to a new network instantly. From the user's point of view, the network switchover is not visible.
Requirements for Intra-AN MM This subclause describes a set of requirements specific to Intra-AN MM in NGN. Provision of mechanisms for context transfer The same requirements apply as listed for Inter-AN MM under 4.4.3.2. Provision of a handover management function for seamless services
MM should support handover management for maintaining session continuity during movement. Furthermore, those mechanisms should provide fast handovers to cater for seamless non real-time and real-time service requirements (e.g., VoIP and video streaming). In Inter-AN MM, the handover means the horizontal handover within an AN. Accordingly, the handover in Intra-AN configurations should provide better performance than for Inter-AN configurations.
8.5
Classification of mobility based on network topology
Figure 8.5 shows an example of multiple levels of mobility for certain access network types and mobility technologies. Other examples for other access network types and mobility technologies are, of course, possible. The figure depicts that mobility supported at lower levels in the architecture may not be visible to higher levels. It also shows that mobility may be handled at levels all the way up to the application.
Figure 34:Example of levels of mobility
Mobility at the service level

Service level mobility is mobility across Circuit-Switched (CS) or Packet-Switched (PS) domains in NGN. This might be within a single NGN or across NGNs. Service level mobility might for example exploit E.164 address to Session Initiation Protocol-Uniform Resource Identifier (SIP-URI) resolution capabilities. Using these capabilities, service level mobility can be provided when a user is roaming between different administrative domains, which would necessitate inter-domain mobility at session control level. Service level mobility between different combinations of CS and PS session is possible for NGN. Mobility at the inter-access network level Inter-access network mobility allows for users to roam across CS or PS domains using various network mobility technologies such as Mobile IP or MAP. Mobility at the intra-access level (Wide area) Intra-access level mobility (wide area) refers to either the PS domain or CS domain in NGN. Mobility is provided by the access network technology. For example, mobility at this level might be provided by GPRS roaming technology for movement between a Serving GPRS Support Node (SGSNs) within a GGSN. Mobility at the intra-access network level (Local area) Intra-access network level mobility (local area) refers to mobility within an access that uses a particular technology, generally within a limited geographic area, but handled above the radio resource control layer. Mobility at the intra-access network radio level Intra-access network radio level mobility refers to the mobility at radio level (e.g., Radio Resource Control (RRC) layer in UMTS or cdma2000, Radio Resource (RR) layer in GPRS). Mobility at the personal level Personal level mobility refers to the mobility at the user level. For example, a user can perform mobility between terminals, such as an IPv4 MS (Mobile Station) and an IPv6 MS.
9. Quality of Service Parameters for Next Generation Networks
9.1 The role of voice in next generation networks The worldwide growth in broadband access has led to an expansion of IP and ATM infrastructure so that it is now possible to envisage converged next generation networks where voice, video and data services are provided over a single network infrastructure. This has led to two major drivers for providing such voice services each of which must be considered when designing end to end next generation voice solutions. PSTN evolution: Existing network operators are looking to migrate their legacy PSTN platforms onto the new networks. This migration is driven by the cost savings offered by integrated voice and data networks, the additional revenue that can be gained from the new services such networks can support, and the impending obsolescence of their installed narrowband switches
Triple play networks: New entrant operators who are looking to provide a compelling package including fast internet and video/TV services also look to provide a PSTN replacement voice service. The need for voice support for such operators is driven partly by the need to offer a service bundle but primarily by the fact that voice services offer excellent margins and return on investment for these operators.
In order to adequately support the requirements of these types of voice deployments a next generation network must be capable of supporting a service that is equivalent to the existing PSTN in terms of availability and reliability. Furthermore these networks must be capable of carrying voice services even under heavy load and in such a way that while the number of voice calls carried may be reduced, the integrity of the voice calls that are carried is maintained, in even the most extreme circumstances.
9.2 Quality of Service requirements for Voice over IP The subject of Quality of Service for IP networks is one that has received a huge amount of attention in recent years. This has led to competing IP QoS solutions being developed. In general any toll quality voice service requires the following performance: a) Once a call has been accepted by call control and resources allocated to it the call should be carried to completion with the required voice quality. b) Established calls must be protected from network disturbances as far as physically possible. One implication of this requirement, when applied to a connectionless IP network, is that stable calls must not be adversely affected by sudden loads caused by the re-routing of traffic from other parts of the network. c) The network must be capable of supporting very high levels of call setup attempts. Existing narrowband exchanges may support millions of busy hour call attempts and a VoIP network must be able to support comparable volumes. d) In the event of focused overload, calls that cannot be carried must be rejected without degrading the call carrying capacity of the network. The PSTN and thus any replacement IP network will occasionally be subjected to very high volumes of calls far beyond that which can be carried (TV and radio phone-in competitions or ticket sales for major events are prime drivers for this sort of overload), any resource reservation mechanisms must be able to deal effectively with this type of event. e) Mechanisms must be available to ensure that emergency calls and high priority calls receive preferential treatment. Emergency calls in particular i.e. 911 and 112 often have specific regulatory requirements for their handling that must be met by the network operator. f) Call setup latency must be comparable to the existing network. The resource reservation mechanisms chosen must not introduce delays that mean the user notices a worse setup time on a packet network than they would on a traditional TDM network. g) The network must be secure from denial of service attacks and spoofing. For example, only the call that has been allocated the resource must be able to use it and when the call is released the resource must again be available to the network.
h) Some networks may require the support for call pre-emption. In certain cases it may be required for a network to de-allocate resources that have been reserved for an existing call and re-allocate them to a new call. The legacy PSTN network supports all of these requirements today using TDM narrowband switches. Additionally some network operators have migrated their TDM voice platforms onto ATM which is a relatively straight forward evolution because ATM is both connection oriented and rich in quality of service features. Where VoIP is considered, however, the underlying network is very different and it poses a number of challenges to operators wishing to support a toll quality voice service; a typical VoIP deployment is shown in figure. 35
Figure 35: VoIP
This network architecture has the following key points: Customer Premises Equipment is deployed at the edge of the network and provides the customers access to the IP network. This equipment may be owned by the network operator but because it exists in insecure premises it is not to be trusted. The edge router acts as the boundary between networks. This router plays a key role in any network since it must police incoming customer flows and provide additional security mechanisms to prevent the misuse of network resources by customers. In terms of security issues the interface between the access network and the core network is of particular concern. The call agent is located in the provider's network and provides call control functions. Network operators in general interconnect at the call control layer, in this case each network operator has at least one call agent and offers a call control interface over the interconnect (e.g. SIP). The MSF does not preclude the support of other types of interconnect (for example interconnection at the transport layer).. Multimedia terminals such as PCs or SIP phones connect directly to the IP network without requiring media adaptation. Existing PSTN customers may be migrated onto the next generation network using line side access gateways (which replace class V exchanges ) or using trunking gateways (which replace class IV exchanges). Subscriber gateways (also known as Residential gateways) may be used where there is a requirement to support legacy black phones over the IP network. The residential gateway provides media adaptation between the analogue phone on the customer side and the packet network on the network side.
In order to understand why VoIP provides such a challenge it is interesting to compare the pure VoIP case, where a call is initiated or terminated on a SIP client with the VoIP access gateway case where a call is initiated or terminated on a narrowband phone.
It is clear that a end-to-end VoIP solution poses many more problems to security and QoS than the alternative solutions such as residential, access or trunking gateways. Therefore it follows that any QoS and security solution that works well for an end-toend VoIP solution can be deployed in a simplified form for the other access solutions. Therefore we have concentrated on providing a QoS solution for an end-to-end VoIP call where a SIP terminal is connected to the network via an edge router. Because we have focused specifically on QoS it is not intended to address the issues of verifying the customer identity or denial of service attacks since these are purely security issues.
9.3 QoS solutions for VoIP There are various mechanisms that can be used to provide quality of service for IP networks and it is not possible to consider every solution here. Therefore it is proposed to examine the most likely candidates for solving the VoIP QoS problem specifically the following solutions need to be considered. 1. Integrated Services (Intserv) 2. Differentiated Services (Diffserv) 3. MPLS Traffic Engineering (MPLS-TE).
9.3.1 Integrated Services (Intserv) The integrated services, or Intserv, method of providing quality of service is to use a protocol for explicitly reserving bandwidth on a per flow basis. This protocol is the internet reservation protocol, or RSVP. The Intserv architecture and the application of RSVP is described in IETF RFC2210. It is important to distinguish between RSVP itself and Intserv. RSVP is a signalling mechanism that is used to realise the intserv architecture. It is possible to use RSVP for other reasons, one example isRSVP-TE where it is used to facilitate traffic engineering for MPLS networks, another example is aggregate RSVP that is proposed for realising dynamic Diffserv service agreements. When used as part of Intserv RSVP provides a method for a user to request a particular quality of service for a session, in effect this reserves the bandwidth throughout the network for the duration of the session. In the case of a voice session the sender of the voice flow (a SIP client) would send an RSVP path message through the network to the user (the intended receiver). Each node along the path identifies that the Path message signifies a new RSVP session and checks its resources before sending on (a possibly modified) path message. Each Intserv capable node along the path is required to store a soft state for the session and RSVP path refreshes must be sent periodically through the network to hold a particular reservation. Once the Path message reaches the user, the traffic parameters contained within the path message are checked and if the user can support such a session, or wishes to modify the session, an RSVP reservation
message is sent back through the network to the sender. Since RSVP reservations are uni-directional this process would have to be carried out in two directions for a bidirectional voice circuit to be established. Although IP networks are connectionless networks, RSVP provides a mechanism to ensure that the reservation message returns by the same route as the path messages, although this route through the network may change over the duration of a session. Each router along the RSVP route checks the RSVP reservation message against its available resources and determines whether it can support the reservation request. If it is able to meet the request then the reservation message is sent onwards towards the sender of the data, otherwise an explict path tear message can be sent clearing the reservation. Once established an Intserv session must be maintained by each router along the path of the session. RSVP Path and Reservation messages must be sent periodically (the IETF recommends once every 30 seconds) along the path of the session (refresh messages) in order to prevent the soft state timing out in the routers. A given session persists until either it is explicitly torn down or until no refresh messages have been received within a given time period in which case the soft state in the routers times out. 9.3.2 Differentiated Services (Diffserv) The Diffserv approach to providing QoS support differs fundamentally from Intserv in that it does not refer to a specific protocol for providing quality of service but rather an architectural frameworkRFC3260. Diffserv proposes that QoS should be provided by the setting and enforcing of policy within a network to provide a set of Service Level Specifications (SLS) between networks (or customers and networks), effectively service level agreements (SLA). The key features of the Diffserv architecture are as follows. The network is divided into one or more Diffserv domains. Sources and sinks of traffic outside of the Diffserv domain are considered customers and would typically have an appropriate Service Level Specification that defined how much traffic and of what type they could pass into, and receive from the Diffserv domain. It is important to note that these sources may not be individual users but could be an entire network.
The edge of the diffserv domain is made up of Diffserv boundary routers. A Diffserv boundary router performs traffic classification and traffic conditioning and policing. It must provide functions for admission control, policy enforcement. In general it is the purpose of the Diffserv boundary router to maintain the integrity of the Diffserv network, to enforce service level specifications and to shape and mark traffic for transport across the remainder of the Diffserv domain. Unlike Intserv, Diffserv QoS functions are not applied to a single flow from a customer. Diffserv classifies traffic into a series of classes (otherwise known as per hop behaviours) and applies the same treatment to all traffic within a class. The core of a diffserv domain is made up of Diffserv core routers. Diffserv core routers are intended to concentrate solely on traffic handling, processing each packet based on how the packet was marked at the Diffserv Boundary. In order to facilitate QoS Diffserv core routers are likely to have a number of traffic queues available corresponding to Diffserv classes. Diffserv defines a mechanism whereby competing services and levels of traffic priority within a particular service are handled by core routers so as to guarantee the Service Level Specifications associated with each service can be met.
Because Diffserv is an architecture rather than a complete solution, supplementary elements must be added to the solution in order for it to be suitable for supporting a voice service. A key aspect of this is admission control and one way of providing it is to deploy bandwidth managers within the network. Within the context of a network a bandwidth manager is considered to be an entity that receives requests for bandwidth from applications, compares requests with the state of the underlying network and either accepts or rejects the requests. Of course a bandwidth manager may be made as simple or as complex as required by a network and may vary in complexity from a device that simply counts sessions to one that understands the underlying network in detail and is capable of reserving and tearing down network resources dynamically. One of the benefits of deploying a bandwidth manager is that it greatly aids network scalability because it acts as a QoS aggregation function, reserving capacity from the underlying network in bulk and then admitting individual flows to that capacity. This is important because it means the bandwidth manager can make an instant decision about a new session without consulting the many routers that will carry the traffic. However care must be taken when defining the role of a bandwidth manager not to
require it to have too detailed a view of network topology or to require all bandwidth requests to be handled by a single entity. The former approach leads to duplication of topology information and the latter approach creates a bottleneck that will limit scalability. 9.3.3 MPLS Traffic Engineering (MPLS-TE) MPLS traffic engineering extends the capabilities of MPLS to incorporate quality of service and as such provides a potentially useful tool to a network operator looking to support voice services. MPLS can be used inside a network to setup label switched paths between ingress and egress points in the network, in effect this creates tunnels down which appropriately tagged traffic flows. By assigning a bandwidth to the label switched path on establishment it is possible to ensure that traffic being carried over a label switched path is guaranteed to be delivered to the egress point provided that the total traffic admitted to the label switched path does not exceed the bandwidth allocated to it. This is a useful tool for IP networks carrying voice as it allows what effectively is an aggregate reservation between two points down which many individual flows can be carried without requiring the explicit reservation of resources for each individual flow. Furthermore this aggregate reservation can be varied with time to allow for fluctuating traffic flows in a network and when combined with MPLS fast re-routing it allows for a resilient network to be created where even significant network failures have very limited impact on the traffic being carried by a particular label switched path. 9.4 A solution framework for VoIP Quality of Service Given the difficulties with respect to scalability and security that any VoIP QoS solution faces and given the currently available tool set for solving such a problem it is possible to draw a number of conclusions. 1. The IETF Intserv architecture is not suitable for the support of large scale VoIP QoS. The high volumes of call attempts that will be required to be supported by any voice network means that the use of Intserv would place an unacceptable burden on the edge and core routers.
2. The Diffserv architecture should be used to provide QoS by deploying Diffserv boundary functions at the edge of the network and providing suitable mechanisms to control the admission of individual flows into the network. 3. Within the core network QoS mechanisms should be provided that guarantee service but that do not require knowledge of individual user flows. There are a number of suitable technologies, of which MPLS-TE is the most promising, however alternative solutions such as aggregated RSVP and ATM may also be applicable in some networks. 4. To enhance scalability and to allow call control functions to be abstracted from the underlying network bandwidth managers should be deployed. Bandwidth managers act as an interface between the call control functions and the network specific bearer functions. 5. In order to support full PSTN equivalence a two stage resource reservation model should be applied with resources being reserved on initial call setup and committed at the point where a bearer is established. These broad conclusions lead to the following solution framework for a pure VoIP call.
Figure 36:VoIP QoS Architecture
A key point to note about this architecture is that the use of the Diffserv QoS mechanisms require the ingress and egress points of voice traffic into the network to be clearly identified by the call agent otherwise no decisions can be made regarding available network capacity. This is a slightly different approach to that taken by the traditional SIP model whereby the call agent does not have any knowledge of the voice path taken and the resources can be reserved using per flow RSVP messages. In order to scale this solution the MSF model provides for interfaces within networks and between networks at the call control layer. This implies that where one network hands off traffic to another two call agents must pass SIP signalling between them and both call agents must make decisions regarding the physical ingress and egress points of the traffic. This approach means that SIP signalling within and between MSF networks in some ways resembles the flows seen in the traditional PSTN with signalling passing through a number of call control functions which then allocate the traffic to the underlying network bearers. The MSF notes that this model is also very similar in behaviour to that chosen by the ITU-T when defining their Bearer Independent Call Control (BICC) solution. The MSF does not preclude inter network communications from taking place entirely at the transport layer but notes that the nature of Erlang means that there are strict limits to the scalability of such an approach. This approach is to a large extent dictated by the nature of Diffserv SLAs and although it departs slightly from the classical SIP end-to-end model it is still able to take advantage of the capabilities of SIP as a multi-media session control protocol. One benefit of defining clear inter-connects between networks and interfacing at the call control layer is that this will allow carriers to re-use their existing PSTN business models and processes while still being able to realise new revenue earning multimedia services. The functions of each of the core network components in providing QoS in this MSF architecture is described below: Call Agent - The call agent is responsible for providing the call control functions and identifying the originating and terminating points within the network. It must also provide secure mechanisms to identify the user. Bandwidth Manager - The bandwidth manager is responsible for providing the required QoS from the network. It is responsible for the setting up and tearing down of bandwidth within the network and for controlling the access of
individual calls to this bandwidth. It is responsible for installing the appropriate policy in edge routers to police the media flows on a per call basis. Within any network there may be a number of bandwidth managers, however each bandwidth manager has sole responsibility for the aggregate bearers that it has created and is the sole arbiter as to whether a call may have access to the reserved bandwidth. Edge router - The edge router provides Diffserv boundary functions and applies the appropriate policy to individual media flows under the direction of the bandwidth manager. The Edge router must contain security functions to ensure that only authorised flows are allowed access to the network resources. Core router - The core routers are responsible for passing traffic through the network in large volumes whilst providing Diffserv core functions. In practice this means supporting a separate internal traffic queue per Diffserv class.
9.5 Interface descriptions One of the key work items that the MSF undertakes is to define implementation agreements for protocols between components of the Multi Service Network. As such it is important to consider each of the interfaces defined in figure 2, to understand the primitives that must flow over the interfaces and to try and identify candidate protocols for the interfaces. It is the role of the MSF technical committee to analyse the interfaces further, chose an appropriate protocol and produce the final implementation agreements. 9.5.1 Interface IF-1 IF-1 between the SIP client and the call server is primarily used for call setup signalling and as such SIP is clearly the appropriate protocol. Bandwidth requirements (and hence QoS requirements) will be passed between client and network as part of the SDP encapsulated within the SIP protocol. 9.5.2 Interface IF-2 IF-2 between the call server and the bandwidth manager is provided to enable the call control functions of the call agent to be decoupled from the specific bandwidth management functions that are closelytied to the underlying network implementation. It is recognised that not all implementations will wish to open this interface. The interface must support the following capabilities.
Allow the call control function to reserve bandwidth between two known end points of the operators network. Enable call control to instruct the bandwidth manager when to commit and release the bandwidth. Allow call control to signal the priority of the request to allow the support of services such as 911 and call pre-emption services. Allow the bandwidth manager to inform call control of bearer termination due to network failure.
There are a number of candidate protocols that could be chosen to provide this functionality including SIP, COPS and H.248. The MSF technical committee will analyse the requirements of IF-2 in detail and identify a suitable protocol. 9.5.3 Interface IF-3 IF-3 between the bandwidth manager and the edge router is provided to allow the bandwidth manager to control the underlying boundary routers on a per call basis. Using this interface the bandwidth manager must reserve, release and commit bandwidth on the edge router and enable/disable access points for individual media flows. The bandwidth manager must be able to control the underlying network element in such a way that only flows that have been authorised by the call control server are allowed access to the network. Currently the most mature protocol in this space is the PacketCable COPS based Gate Control Protocol, however the MSF notes that ETSI TIPHON recommended the use of H.248 for this interface and other protocols may also be considered. The MSF technical committee will determine which protocol should be chosen for IF-3. 9.5.4 Interface IF-4 IF-4 between the bandwidth manager and the underlying network elements is provided to allow the bandwidth manager to set up and tear down aggregate bandwidth reservations across the network. The nature of this interface is highly dependent on the underlying network technology, for example for an MPLS network it might only be required to provide the interface between the bandwidth manager and the edge routers, however if the core network were based on ATM technology then interfaces might be required between the bandwidth manager and all of the switch
routers in the network. Regardless of the network technology the interface must support the following capabilities. The bandwidth manager must be able to reserve bandwidth to a particular destination of a particular Diffserv QoS class. The bandwidth manager must be able to release bandwidth when it is no longer needed. The underlying network elements must be able to inform the bandwidth manager of any changes affecting current reservations. The interface should allow this information to be passed upwards to the bandwidth manager immediately such an event takes place and the information should reach the bandwidth manager with the shortest possible delay.
The exact protocol to be chosen for IF-4 is for further study and a number of candidate protocols will be evaluated to determine which would be most suitable. 9.5.5 Interface IF-5 IF-5 is an inter bandwidth manager interfaces for the cases where it is necessary for two bandwidth managers to communicate directly. There are two cases where bandwidth managers might be required to communicate with each other: Where a particular part of a service providers network is under the sole control of a single bandwidth manager and calls are required to transit through it. In the case of a so called transit network where two VoIP operators, each with call servers are interconnected by a third transport or transit network that has no call server. In this case each of the VoIP operators must reserve the required bandwidth from the transit network operator via IF-5
The following diagram shows an example of VoIP interconnect via a transit network.
Figure 37: Interconnect via transit network
9.5.6 Interface IF-6 IF-6 between call agents is provided to enable peer to peer call control communication. The MSF has currently identified a SIP profile for this interface and the MSF Implementation Agreement is currently undergoing final ballot 9.6 Call setup for VoIP Prior to the call attempt being made the bandwidth manager is assumed to have already allocated bandwidth to the MPLS tunnel between the chosen ingress and egress point. When the initial call attempt is made the following actions are taken: 1. The SIP client sends an invite message containing the session description which describes the bearer characteristics of the call. The call agent analyses the initial invite, verifies the identity of the user and authorises the call attempt. It may generate an authorisation token to verify that the call has been accepted by a valid call server, this is important in shared access networks such as cable or 3GPP networks but not a requirement for networks with dedicated point to point access (metro ethernet and DSL). The call agent determines the ingress point (edge router A) and egress point (edge router B) of the call into and out of the network and forwards the invite to the appropriate call agent in the next network. 2. The neighbouring call agent processes the call and determines that it is in a position to alert the called party. The neighbouring network reserves resources within itself and requests its upstream neighbour to start the reservation process by sending back a 183 Session Progress Message. This behaviour broadly follows that described
in RFC 3312 Integration Of Resource Management And Session Initiation Protocol except that the reservation mechanism is Diffserv based and not RSVP. 3. The call agent requests bandwidth be reserved by the bandwidth manager between the two end points. 4. The bandwidth manager determines the physical network entities that will carry the traffic into and out of the network and requests that edge router A and B reserve capacity to carry the session in both the forwards and backwards direction. 5. The edge routers determine that they have sufficient internal resource to accept the media flows, reserve the resources and inform the bandwidth manager. At this stage although the edge routers and the bandwidth manager have set aside resource to handle the flows this resource can be re-used for best effort traffic. 6. The bandwidth manager informs the call agent that the required resources have been reserved in each direction. 7. The call agent might send the request to reserve resources further back into the access network by passing back the 183 session progress message, however in this case the access network uses other mechanisms for QoS (for example those used by ATM based DSL access networks) and so the access network bandwidth is already guaranteed. The call agent therefore knows that QoS has been setup end-to-end and sends an Update message to its neighbouring call agent confirming this. 8. The adjacent call agent receives the update messages indicating that resources have been reserved, which it acknowledges and then alerts the user, sending a 180 Ringing message back through the network. Sometime later the called party answers the call and a 200 Ok message is passed back. 9. On receiving the 200 Ok message the call agent requests the bandwidth manager commits the resources to the call.
Figure 38:Call setup for VoIP
10. The bandwidth manager instructs routers A and B to open the access points for the forwards and backwards media flows. This commits the resource to the call and means that the users now have a guaranteed path available through the network. 11. The edge routers inform the bandwidth manager that the flows have been granted access to the network. 12. The bandwidth manager informs the call server that the media flows have been granted access to the network the call is considered to be in progress and billing may start. Media streams carried when the call is in progress are marked by the edge routers with the appropriate Diffserv Code point, for voice these flows will in most cases be marked as EF (Expedited Forwarding) traffic. In an MPLS core network, as shown in this example, the media flows are admitted to the appropriate Label Switched Path (LSP) and the bandwidth manager ensures that no more flows are admitted than can be supported by that LSP. If during the course of a call, physical changes in the network cause the bandwidth available to the LSP to be reduced then the bandwidth manager must be informed and it must tear down sufficient calls to ensure the new bandwidth limit for the LSP is not exceeded. If the bandwidth manager is forced to tear down active calls it must inform the call agent that the call has been terminated with the appropriate cause value.
When the call is terminated it follows that the resources that have been allocated to the call must be released and returned to the pool. In order to achieve this, the call agent instructs the bandwidth manager to release call resources on receiving a BYE message (if they have been previously reserved or committed). On receiving this instruction the bandwidth manager must update its state and also instruct the edge routers to release their resources and importantly to close the access points for the media flows. It is important to note that this process not only guarantees QoS for the call but it also provides a number of security features. In particular prior to point 11 in the process the two end users do not have access to any of the reserved capacity and so cannot try to set-up two half calls to avoid paying for the service. In addition by ensuring that access points for media flows are explicitly closed when a call terminates (i.e. when the call control layer and hence billing processes state that it has terminated) it prevents users re-establishing media flows to the same end points whilst bypassing call control and so a toll free call cannot be established. Of course there is nothing preventing the users from creating a best effort connection between the two end points however this will not be allocated any dedicated resource. Because of the nature of SIP, whereby a call can have many complex operations performed on it the approach is only to reserve resources when a call agent is in a position to alert a subscriber, this approach mimics to an extent the solution chosen by feature rich private signaling systems. While this is a simple example, the issue of call setup, resource reservation and SIP interactions is a complex one which requires further investigation. In particular the MSF will consider the interactions with various types of SIP servers and service platforms and also what mechanisms might be provided to prevent unnecessary signaling in the case of severe network congestion. 9.7 Currently Defined Solutions for VoIP QoS A variety of Next Generation Networks are currently being developed throughout the telecommunications industry, each with differing origins and designs. The unifying aim of these networks is to deliver an acceptable end-user experience. To achieve this is a central QoS control point must be provisioned to link, control and thus ensure that the differing strands of communication required to deliver that user experience are handled appropriately. This article reviews how the control entity is implemented and designed within the differing Next Generation Network topologies, and how its roles and functions compare depending on the network model being standardized.
9.8 Quality Control Models for NGN Traditionally control of Quality of Service (QoS) within telecommunications networks has been achieved by a combination of best-effort data delivery, network resources reservation (IntServ) or data packet marking (DiffServ) on data communication paths. However the design of emerging Next Generation Network (NGN) architectures will render this approach no longer viable. A key feature of network topology within the various NGNs is that the signaling required to negotiate a data transfer (the application signaling) may not travel on the same logical path as the actual data transfer itself (the data traffic). Therefore an entity must be inserted to link the application signaling on the "upper" service plane to data traffic on the "lower" transport plane, to allow a means for applications to request QoS to be performed on the traffic plane. To achieve this, the policy entity requires a variety of functions such as QoS authorization, service-to traffic QoS mapping and the means to provision the resultant QoS policy decided. This policy entity should also (ideally) take into account the QoS control end-to-end, i.e. operating across combinations of networks, carriers and service providers which will comprise the future NGNs. However due to the plethora of NGN standards being developed this policy control entity's roles and functions varies considerably. This article will outline the means of QoS control within 6 differing NGN architecture standards:

3GPP IMS 3GPP2 MMD ITU-T NGN-GSI ETSI TISPAN CableLabs PCMM MSF
and examine the similarities and differences between them. 9.8.1 3GPP IMS The 3rd Generation Partnership Project group is an open-standards body founded in December 1998, originally producing Specifications and Technical Reports based on evolved GSM core networks. Currently 3GPP is finalizing standardization of the 3GPP IP Multimedia Subsystem (IMS).
Within IMS the PCRF (Policy and Charging Rules Function) is the policy entity that forms the linkage between the service and transport layers. The PCRF collates subscriber and application data, authorizes QoS resources, and instructs the transport plane on how to proceed with the underlying data traffic. The PCRF is connected on its northbound Rx interface to the Application Function (AF), an element residing on the service plane, which represents applications that require dynamic policy and QoS control over the traffic plane behavior. Within an IMS network, a P-CSCF would commonly fulfill the role of an AF. On the traffic plane, connected to the PCRF via the southbound Gx interface, is the Policy and Charging Enforcement Function (PCEF). The PCEF's role encompasses applicable traffic detection and resultant policy enforcement. This entity is typically located at a Gateway node, which varies by transport layer (e.g. a GGSN, PDG etc.). A Subscriber Policy Register (SPR) node also provides subscriber specific data to the PCRF, to assist in evaluating policy decisions.
Figure 39:Positioning Of elements in Next Generation Networks
QoS control is applied per service data flow in the PCEF, these service data flows can be thought of as a set of packet flows, typically IP flows. The PCEF utilizes PCC (policy and charging control) rules to classify traffic by service data flow. Rules can be pre-defined or dynamically provisioned in the PCEF. Dynamic PCC rules are derived within the PCRF from information supplied by the AF (such as requested bandwidth), PCEF data (such as requested QoS at traffic level by user) and other Subscriber specific data if available. Provisioning of rules via the Gx interface to the PCEF can take place in two ways:
"Pushed" i.e. unsolicited provisioning, where the PCRF may decide to provision PCC rules without obtaining a request from the PCEF, or
"Pulled" i.e. where Provisioning has been solicited by a request from the PCEF.
Each rule uses a series of data flow filters to allow the PCEF to detect the relevant traffic plane packets. The resultant activated PCC rule contains a QoS class identifier and the uplink + downlink bit-rates authorized for the service data flow. As each PCC rule can only be bound to a single data bearer (i.e. for GPRS the data bearer would be the PDP context), this may require a series of rules to be installed to control QoS across multiple underlying traffic bearers. The actual policy enforcement procedures for authorized QoS per PCC Rule is bearer dependent, possible procedures include Packet scheduling, data packet (Diffserv) marking, and packet discarding. Gating control is achieved by opening or closing the gate contained within the current active PCC rule per data flow. Event mechanisms can also be set by the PCRF in the PCC rules to cause the PCEF to inform it of changes in the underlying traffic bearer.
3GPP2 MMD
The 3rd Generation Partnership Project 2 is an open-standards body, founded in late 1998, to produce standards based on the CDMA2000 3G model. 3GPP2 is currently in the process of defining Release B of the all-IP core network Multimedia Domain (MMD), an architecture closely based on the IMS network being standardized by 3GPP. Within the MMD model, control of QoS is part of the Service Based Bearer Control mechanism, the policy decision point here is also termed the Policy and Charging Rules Function (PCRF). This PCRF has a northbound interface (Tx) to an Application Function - AF (e.g. a P-CSCF) that is responsible for application level service decisions, whereas the southbound interface (Ty) connects the PCRF to the Access Gateway - AGW (e.g. a PDSN), that is responsible for bearer resources policy enforcement. Policy based QoS authorization and control can be Service Based, Subscriber Based, and/or and Local Resource Based Policy. Not all authorization and control methods may be used in any one data session, however all must agree in order for the control to be implemented. Regardless of the origin of the policy control, the PCRF always has the last say regarding use of local resources.
i) Service Based: This form of control is essentially the authorization for use of bearer resources in the access network based on negotiation between what the user requests and what the network can support. The QoS control sequence of events depends on whether a "Push" or "Pull" model is applied. In the Pull model, the User (1) exchanges application information (e.g. bandwidth, media type in SDP) with the AF. The AF maps the application-level signalling to service data flows passed to the PCRF(2). At some later point the subscriber makes a request to reserve bearer resources from the AGW (3). The AGW passes the subscriber's binding information to the PCRF (4). The PCRF matches the traffic information to the authorized service data flow, optionally requests more information (5), and then authorizes the packet flow by sending the authorized QoS to the AGW (6). The AGW compares the requested QoS to the authorised QoS and creates a gate for each packet flow. Finally the AGW informs the UE that bearer resources have been granted (7), allowing the traffic to flow. The Push model follows the same principle, except in this model the AGW has already established an association with the PCRF (3), so that the authorized QoS parameters are directly pushed to the AGW upon their receipt from the AF (6), and therefore the AGW does not need to forward the binding information to the PCRF
Figure 40:Pull QoS Authorization flow (3GPP2 model)
2) Subscriber Based: This is the authorization for use of bearer resources in the access network based on a user's subscription; a typical authorizing entity in this model is an AAA server. This form of QoS control is subscriber specific and would typically be applied as part of admission control, or as part of a Local Resource policy. 3) Local Resource Based: This is policy that is applicable to a particular operator or local area. It is enforced within the PCRF as part of its input in sending authorized QoS parameters to the AGW, is only considered during bearer resource authorization and is not communicated to AFs.
9.8.2 ITU-T NGN-GSI The ITU-T, founded in 1992, is the standards body subcommittee of the International Telecommunication Union (ITU). Currently ITU-T is standardizing what it refers to as the Next Generation Network, under the umbrella of the Global Standards Initiative (NGN-GSI). Within the ITU-T NGN Release 1 model, the Resource and Admission Control Functions (RACF), is the linkage entity between the service and traffic planes. In this model, there is a split within the RACF, with a PD-FE handling the upper application specific QoS control, and a TRC-FE making lower transport dependent QoS control decisions.
The PD-FE provides a single northbound contact point (Rs) to the Service Control Functions (SCF) requiring QoS control. It role is to make the final decision on resource and admission control in the network under its control, map the service QoS requested to network QoS parameters, and instruct (Rt) the TRC-FE to detect and determine the required QoS resources along the transport path. The TRC-FE's role is to deal with the diversity of the underlying transport technologies, monitor the availability of resources, and provide resource-based admission control decisions to the PD-FE.
Both the PD-FE and TRC-FE have southbound interfaces to the transport layer, with the PD-FE communicating with the PE-FE (Rw) in the transport layer; to enforce dynamic QoS and resource control, gating, as well as features needed for multidomain QoS, such as NAT traversal and NAPT control. The TRC-FE maps received network QoS parameters to transport (technology dependent) QoS parameters, and gathers information and traffic performance from the underlying transport function (Rc), in order to authorize admission control based on network information. To handle end to end admission and QoS control, the standards allow for multiple TRC-FE and PD-FE nodes within one domain, depending on the operators configuration. For example the PD-FE may contact only one designated TRC-FE instance, and then the respective TRC-FE instances would inter-communicate (Rp) to detect and set the requested QoS from edge to edge in a set network. Multiple PDFEs can be linked (Rd) within a domain to handle large networks, whereas an intraEverything Over IP - Dynamics of the Strategic Changes in Voice and Data Networks | 119
domain interface (Ri) at the PD-FE allows resource and admission control to be requested between domains. Finally, various Network Access Attachment Functions (NACFs) interact (Ru) with the PD-FEs to provide subscriber information to the PDFE. In this architecture, policy rules can either be "Pushed" or "Pulled", depending on the user's QoS negotiation capabilities at the service and transport layers. Three different possibilities can arise:
If the user does not have any specific QoS negotiation capabilities, it first communicates with the SCF. The SCF determines the QoS required and signals this to the RACF, the RACF can then execute a one or two step process to push the gate control, packet marking and bandwidth allocation to the transport functions.
If the user performs QoS negotiation (such as bandwidth) at the service layer, the SCF extracts the received QoS information and again submits this to the RACF, which then can execute a one or two step process of pushing authorization, reservation and commitment of resources to the transport functions. If the user performs QoS negotiation (such as GPRS session management) at the transport layer, then policy rules may be pushed or pulled from the RACF. In the pull case this can occur as a two or three step process, with the transport layer receiving the QoS request and then pulling the policy rules from the RACF.
As the implementation of the TRC-FE is different for various transport technologies, traffic policy enforcement will vary as well. The TRC-FE will typically handle route look-up, link-by-link resource allocation and admission control for each media flow that requires a QoS guarantee.
9.8.3 ETSI TISPAN The TISPAN body (Telecoms & Internet converged Services & Protocols for Advanced Networks), is a standardization entity within ETSI, founded in 2003 and focusing on creating an architecture that serves to create the Next Generation Network. NGN Release 1 was launched by TISPAN in December 2005. In TISPAN the service and traffic plane linkage entity is termed the Resource and Admission Control Sub-systems (RACS). As in ITU-T, there is a split within the RACS, with an 'upper' Service Policy Decision Function (SPDF) providing the AF with a single point of contact via the northbound Gq' interface. The SPDF communicates via the Rq interface with the 'lower' A-RACF. The A-RACF's main functions are to handle admission control requests from the SPDF, and to store access network policies, which are used to validate resource requests received from SPDFs across the inter-domain Rq link. The A-RACF is assisted in its admission control process by the NASS, communicating with this via the e4 interface. The NASS informs the ARACF when a subscriber attaches to the network, providing the low-level network details that can be later matched to high-level service requests from the AF via the SPDF. Both the A-RACF and the SPDF have southbound interfaces to the traffic layer. The A-RACF communicates via the Re interface to the RCEF (Resource Control Enforcement Function) , whereas the SPDF communicates directly via the Ia interface to the BGF (Border Gateway Function). The RCEF resides in the IP-Edge whereas the BGF resides in the core border node - located between an access network and a core network (C-BDG), and/or between two Core Networks (I-BGF). Both elements can police traffic, control gates and mark packets, whereas the BGF can perform additional services such as allocating resources per flow, measure usage and implement NAT handling. Depending on the policy decision made by the SPDF, resource requests may be sent via an A-RACF to the RCEF and/or directly to the BGF. Policy rule provisioning in the TISPAN model is "push" mode only. The typical sequence of operation would first involve the subscriber registering and the NASS pushing his profile to the A-RACF. The A-RACF may then install default traffic policies in the RCEF. At some later stage the user would request a service, at this point the AF would map QoS information received and submit it to the SPDF. The SPDF will map the local policy into a request to be sent to the A-RACF and/or BGF, and then,
depending on the resource model (the RACS can support a single, two or three stage authorize-reserve-commit resource management model), either make resources immediately available via the A-RACF and/or BGF, or make available after reservation and authorization. Dynamic QoS control in TISPAN can be "Guaranteed QoS" or "Relative QoS". Relative QoS is relative per traffic carrier, and is performed in the IP edge, an example would be Diffserv Edge in the RCEF. Guaranteed QoS is service delivery with absolute bounds on some or all of the QoS parameters; this is implemented in the RCEF and may take a variety of generic L2/L3 QoS traffic policies. 9.8.4 PCMM The PacketCable MultiMedia (PCMM) architecture, first issued in June 2003, is a CableLabs-led initiative for delivering QoS enhanced multimedia services to the DOCSIS based access portion of a cable operator's network. In this model the Policy Server (PS) is responsible for making QoS-related policy decisions based on defined policy rules, whereas the enforcement point is in the Cable Modem Termination System (CMTS). The PS is connected on the northbound pkt-mm-3 interface to the Application Manager, and on the southbound pkt-mm-2 interface to the CMTS, which performs admission control on the requested QoS envelope, installs the policy decision and establishes the correct flow. The PCMM architecture identifies 3 different client classes, which differ by QoS requesting abilities and therefore by QoS control signaling: 1) Clients with no specific QoS handling: To handle these type of clients, application service request are sent from the Client to the Application Manager (possibly via the Application Server). The AM then requests QoS setup on behalf of the client. The Policy Server can then initiate a one or two phase model, for authorization, reservation and commitment of QOS resources, by pushing its policy decision to the CMTS and requesting service flow establishment. The CMTS would then establish these flows in the Cable modem. Clients with QoS signaling support but no authorization: These clients have the same initial flow except authorization requests only are conducted via the
2)
AM. These are installed in the push policy decision sent from the Policy Server to the CMTS. Afterwards the Client would initiate a one or two stage reserve/request communication directly with the CMTS, using DOCSIS DSx or RXVP+, to request QoS and provision it on the CM, thus bypassing the AM. 3) Clients with QoS and authorization signaling support: In this case the AM is bypassed completely. The client sends QoS request based on RSVP to the CMTS. As the CMTS has no information about the client it solicits (pulls) a policy authorization decision from the Policy Server. The Policy Server thus installs a policy authorization decision on the CMTS, which the CMTS then provisions on the Cable Modem.
Within the actual traffic plane QoS control is essentially extensions to existing DOCSIS features, these include scheduling algorithms and supporting differing bandwidth types(constant, variable etc.). 9.8.5 MSF The Multiservice Switching Forum (MSF), was established in 1998 to develop and promote interoperable, next generation networks in real-world deployment scenarios. In September 2006 it launched its Release 3 Architecture, incorporating many ETSI TISPAN concepts, and integrating with the 3GPP IMS core architecture. Within the MSF model the Bandwidth Manager (BM) provides a single point of contact for higher layers to establish QoS resources across the Core Transport Network. A variety of entities within the higher layers, can query the Bandwidth Manager via the northbound TC-0 interface (essentially the ETSI Gq' interface) to determine the QoS-controlled bandwidth. The Bandwidth Manager monitors the Core networks and will respond with a message informing the requesting component whether adequate QoS capacity exists across the core transport network to carry that flow. However in this model, the Bandwidth Manager does not perform gate control in MSF R3 architecture, this instead is the responsibility of the respective controlling entity. For example, if the P-CSC (MSF) was informed by the BM that adequate QoS capacity exists to carry the flow in question, it would then communicate policy to be enforced directly to the access side traffic component under its control, such as a
GGSN. Policing (filtering, shaping, marking) is enforced on a per-flow basis at the access side by the traffic plane components. 9.9 NGN Comparison Any comparison between the various NGN QoS control entities must be taken from their origin point. 3GPP and 3GPP2 have developed the IMS/MMD model from a mobile origin, and have only recently (IMS Release 7 and MMD Revision B) begun to include elements from the fixed wireline network. Although both are roughly equivalent, 3GPP IMS Rel7 is at a more advanced stage than 3GPP2 MMD RevB, with the result that it tends to dictate the pace and integration with the other NGN networks. Functionally the two PCRFs are very similar, they occupy the same position and have the same push/pull mode capability, however minor differences exist. The 3GPP2 model is limited in that the PDSN is currently the only defined policy enforcement point. Both models have only begun to addresses at a high level the concept of inter-PCRF communication. Similarly neither directly specifies how they handle NAT traversal, Firewalls and MPLS handling in QoS control, as well as dynamic traffic monitoring in the underlying traffic plane. These issues are being addressed with greater emphasis by the ITU-T and ETSI models, which have wrapped their NGN architectures around the IMS frameworks.
Figure 41:NGN QoS Roles
Both ETSI's TISPAN and ITU-T NGN-GSI initiatives have begun from a wireline prospective, and both have included the IMS model as the nucleus on which to base a fully converged network focusing. They also address the broader network issues that arise in a fully converged network, such as border control (e.g NAT & NAPT traversal and gating). They share the same topology, with a split within the north and southbound linkage function; one entity handling the application and generic transport signaling (ITU-T: PD-FE, ETSI: SPDF), and the other entity (ITU-T: TRC-FR, ETSI: ARACF) communicating and monitoring resources within the specific traffic network. However, significant differences arise:
In ITU-T the TRC-FE monitors the traffic plane and makes resource admission decisions, whereas in ETSI the A-RACF can additionally enforce policy directly in the traffic plane.
ITU-T RACF has handling for both push and pull policy installation, whereas ETSI RACS has push only. This is because the NASS automatically provisions subscriber details within the RACS at the moment of subscriber logon, allowing default policies to be immediately pushed to the traffic enforcement point indicated. However ETSI TISPAN Release 2 is moving towards introducing pull mode.
The RACF addresses QoS end to end, whereas the RACS is currently more focused on access QoS.
The RACF has provisions for end-user with no inherent QoS negotiation abilities, whereas the RACS again relies on the NASS to supply subscriber details, enabling default traffic policies.
In general, the ETSI TISPAN model is somewhat more mature than the ITU-T NGNGSI, whereas the ITU-T model is a broader model. In comparison to the other standards bodies, the PCMM standard is fairly mature and is in global deployment. It differs from the other standards in allowing a range of signaling paths to occur in the negotiation of QoS control. Interoperability with other networks is not directly addressed within the PCMM specification, as the focus is on QoS in the access network or within a single operator's managed IP network. Handling of inter-network features such as NAT traversal and IMS networks is part of the PacketCable 2.0 release, which leverages the QoS mechanism defined within the PCMM. Initial versions of the MSF's architecture were based on the PCMM model, but in the latest Release 3 model the MSF has heavily references ETSI TISPAN concepts and interfaces. The MSF's main emphasis is on interoperability amongst networks and environments of differing types and standards. As a result its bandwidth manager is the only policy control element to not be directly involved in enforcing policy in the traffic plane. Instead the BM relies on collecting accurate traffic measurements for the network in which QoS is being requested, allowing clients the ability to directly
request policy in the traffic plane. This removal of QoS control from the linkage entity reduces the complexity of the BM, yet increases the number of QoS negotiation points throughout the network.
10.
10.1
NGN security
Objective of NGN security NGN security features should be extensible, and flexible enough to satisfy various needs. Security requirements should take the performance, usability, scalability and cost constraints of NGN into account. Security methods should be based on existing and well-understood security standards as appropriate. The NGN security architecture should be globally scalable (within network provider domains, across multiple network provider domains, in security provisioning). The NGN security architecture should respect the logical or physical separation of signaling and control traffic, user traffic, and management traffic. NGN security should be securely provisioned and securely managed. An NGN should provide security from all perspectives: service, network provider and subscriber. Security methods should not generally affect the quality of provided services. Security should provide simple, secure provisioning and configuration for subscribers and providers (plug & play). Appropriate security levels should be maintained even when multicast functionality is used. The service discovery capabilities should support a variety of scoping criteria (e.g., location, cost, etc.) to provide appropriate scaling, with appropriate mechanisms to ensure security and privacy. The address resolution system should be a special system used only by this network, and certain security measures are required to be in place. This system may use databases that are internal or external of a domain. Objectives for security across multiple network provider domains
10.1
The general objective is to provide network-based security for end-to-end communications across multiple provider domains. This is achieved by providing security of the end-to-end communication on a hop-by-hop basis across the different provider's domains. Each network segment has specific security responsibilities within
its security zone to facilitate security and availability of NGN communications across multiple networks. 10.1 Threats to the NGN Unauthorized exploration, such as the remote analysis of the system to determine points of weakness Break-in/device takeover resulting in loss of control of the device, anomalies and errors in the configuration audits Destruction of information and/or other resources Corruption or modification of information Theft, removal or loss of information and/or other resources Disclosure of information Interruption of services and denial of services
Interruption of services and denial of service: Denial of service attacks on network elements are carried out by continuously bombarding the network element with data so that no more resources are available for other NGN users Eavesdropping: This threatens confidentiality by intercepting the line between the sender and the receiver Masquerade: A perpetrator uses masquerading to feign a false identity. For instance, he or she obtains a false identity by spying out the user ID and password, by manipulating the originator field of a message or by manipulating the input/output address within the network Unauthorized access: Access to network entities must be restricted and conform to the security policy in place. If attackers were to get unauthorized access to any of the network entities, various other attacks, like denial of service, eavesdropping or masquerade, could follow Modification of information: In this case, data is corrupted or rendered useless through deliberate manipulation. One consequence of this action is the rejection of authorized accesses to network resources. In principle, it is not possible to prevent users from deliberately manipulating data or destroying a database within the scope of their authorized access rights Repudiation: One or more users involved in a communication are denied participation in all or part of a communication with other users or servers/services in NGN. Possible attack methods include denial of transmission, or of data receipt, or of data access or of data modification. From an operators or service providers point of
view, this type of attack could result in loss of revenue, loss of trust or loss of customers NGNs will have direct or indirect connectivity to un-trusted and trusted networks and terminal equipment, and therefore will be exposed to security risks and threats associated with connectivity to un-secure networks and customer premises equipment. Sources of threat can originate from: Other service providers, and their applications Own network as well as other NGNs Other IP-based networks and NGN transport domains Public switched telephone network (PSTN) Corporate networks User networks Terminal equipment
The requirements are to handle the following issues in a multi-network environment Customers / subscribers must have confidence in the network and in the offered services, including accurate billing. In addition, they are demanding high service availability, fair competition and protection of their privacy Network operators, service providers and access providers all need security to safeguard their operations and business interests and to meet their obligations to their customers and the public Regulatory bodies demand and enforce security by issuing directives and creating legislation to ensure the availability of services, fair competition and privacy While the consolidation of NGN services through the network operator makes services simpler for the end user, the operator faces new complexities. The basic structure of an NGN transaction contains three layersthe identity layer, the services layer, and the network layer. Each of these layers requires a corresponding level of security to ensure a secure, end-to-end transaction. Each NGN provider is responsible for security within its domain. Each NGN provider is responsible for designing and implementing security solutions using network specific policy for trust relations, to meet its own network-specific needs and to support global end-to-end security objectives across multiple network provider domains.
Figure 42: Security
Identity Layer and Security Level 1: This layer is concerned with the management of customer identities and forms the basis for interaction between the network operator and the end user. As the primary gateway, it serves as a mechanism for acceptance or exclusion, i.e., who should be allowed, what devices should be prohibited. When a subscriber logs on to an operators portal, the operator must authenticate the identity of that subscriber. The operator also must help ensure that the device used to connect to the network is free from malware and in compliance with security guidelines for accessing services. The integrity of the code and application that is running on mobile devices is of paramount importance. The operators need to allow only trusted code and applications to be downloaded to the mobile devices. The Identity Layer and S-1 is the first line of defense, so any viruses or worms must be thwarted at this level, as well as strict
controls in the form of device and application security policies enforcement must be exercised. Service Layer and Security Level 2: The Service Layer and its corresponding security level define the content and services allowed based on the subscribers access rights and privacy and preference settings. Instead of asking their customers to trust an assortment of third-party content providers, network operators may instead offer a method of access to a library of content and services (off-portal access) that does not require the subscriber to register with each provider individually. At this layer, the operator would also provide the infrastructure for pay-per-use billing so no additional financial and personal information is requested from the subscriber. When the operator (a known, trusted quantity) acts as the mediator, it protects the privacy and enhances the loyalty of the subscriber, thereby increasing the likelihood that a transaction will not be abandoned. By addressing security and privacy issues, operators are likely to see broader service adoption facilitating new revenue generation and improved customer loyalty. Network Layer and Security Level 3: This layer can also be referred to as the core network. While somewhat less dynamic than the other two layers, the technical interactions between the network operator and the actual delivery of services are determined here. This layer opens up the network to third-party service applications, enabling application developers to develop, deploy, and manage service applications through the use of common open-standard application program interfaces (APIs), which expose the underlying network functionality. While reducing time to launch new services and delivering efficiencies in managing services on an on-going basis, it presents a new set of security challenges. Security at this layer defines the trust relationship between the operators and a variety of third-party content and service providers, ability to accept trusted software content and programs, and helps ensure overall security of the infrastructure that is delivering these services (e.g., location-based services, PTT services and access to gaming sites) by leveraging core network functionality including Operations Support System (OSS) and Billing.
10.1
Areas of consideration and action for security policy as the five As
Figure 43: Five As
Access: The first point of contact with an NGN operator is through the mode of access that a user employs. Not only do different devices have different levels of usability, but the security threats posed by each can be quite unique. Devices support a myriad of applications and variety of protocols and determining the range of devices, applications, and protocols that a network operator will support is a critical piece in the design of firewalls, virus checkers, spam controllers, etc. While managing a single category of devices might be less complex, customers and service providers alike may drive the operator to support a combination of devices. Therefore, decisions about access must reflect both the operators security policies and customers and service providers needs.
Authentication: Authentication is the process of verifying that an entity (i.e., person, device, application, network, or agent) is indeed who they say they are. While decisions regarding the method of authentication are critical, care must also be taken not to discourage legitimate users. The operator will not only have to make important choices regarding the technical protocols employed here, but also concerning many non-technical decisions as to who authenticates, how many times an entity needs to be authenticated, and how many different combinations of authentication technologies are used. These decisions can be quite complex as they encompass various options regarding the type of proofs or credentials presented (i.e., password, codes, digital certificates, biometrics, location-based, GPS, etc.); the number of levels or factors required (i.e., strong or weak, single- or multi-factor verification, etc.); and the party that verifies (i.e., local or federated). Increasingly, the option of federated
authentication, where a trusted third party constructs a trusted network (and entities need not be locally re-verified) is emerging as a viable option. Authentication is critical not only to ensuring content integrity but with increased deployment of Web-services, it will be an important factor in determining what operations will be allowed in the network. Due to an increasing number of phishing and other spurious content, verification of service providers on a dynamic basis (beyond initial trust) is crucial. Authorization: While decisions regarding the previous activities largely focus on who to exclude (or include) and play an important role in layer 1, the authorization to use content, services, and other resources form the backbone of commercial transactions that take place on an NGN platform. Decisions at this level govern security policies, which help ensure that only the right entities have access to particular content. This authorization is granted simultaneously by both the service provider and fiscal entities, such as banks. And while it might be less complex to employ a one-by-one level of authorization, economies of scale often dictate a template or profile approach wherein rule-based or role-based provisioning might result in more manageable security policies, e.g. allowing premium and standard plans with associated privileges. Analytics: It is important to recognize that security policies cannot be static and they need to be constantly updated. Just as usage information is monitored and mined for better customer service, similar information can be obtained and employed for superior security policies. Most commonly, mining usage activities should play a direct role in vulnerability management and deployment of intrusion detection systems, including updating of firewall rules. Other systems, such as intrusion response and spam controllers, are also increasingly adopting analytics, such as Bayesian inference techniques, to dynamically update security policies. It is this type of intelligent infrastructure that can help to increase security in the most dynamic, effective manner by extending threat and vulnerability management to the mobile environment.
Audit: Activities in this dimension have largely been dormant until recently when legislative action was taken regarding privacy protection and process management. Audit is simply an element of accountability, where security policies should reflect the systematic adherence to a set of established criteria. If an NGN operator supports kid friendly services and allows sharing of profiles between its consumers and service providers, its security policy may need to reflect the requirements of the Childrens
Online Privacy Protection Act of 1998 (COPPA). The need for security policies that reflect legislative and consumer demands is critical. Security policies should be equally concerned about internal threats (including an operators own partners) as much as threats from the outside world. 10.1 Security Trust Models
The NGN functional reference architecture defines functional entities (FEs). However, since network security aspects depend heavily on the way that FEs are bundled together, the NGN security architecture is based on physical network elements (NEs), i.e., tangible boxes that contain one or more FEs. The way these FEs are bundled into NEs will vary, depending on the vendor. 10.5.1 Single network trust model It defines three security zones: Trusted Trusted but vulnerable Un-trusted These zones are dependent on operational control, location, and connectivity to other device/network elements.
Figure 44:A single network trust model
A "trusted network security zone" or "trusted zone" is a zone where a NGN provider's network elements and systems reside and never communicate directly with customer equipment or other domains. The common characteristics of NGN network
elements in this zone are that they are under the full control of the NGN provider are located in the NGN provider domain, and they communicate only with elements in the "trusted" zone and with elements in the "trusted-but-vulnerable" zone. It should not be assumed that because it is in a trusted zone it is secure. The "trusted zone" will be protected by a combination of various methods. Some examples are physical security of the NGN network elements, general hardening of the systems, use of secure signaling, security for OAMP messages separate VPN within the (MPLS/)IP network for communication within the "trusted" zone and with NGN network elements in the "trusted-but-vulnerable" zone A "trusted but vulnerable network security zone", or "trusted but vulnerable zone" is a zone where the network elements/devices are operated (provisioned and maintained) by the NGN provider. The equipment may be under the control by either the customer/subscriber or the NGN provider. In addition, the equipment may be located within or outside the NGN provider's premises. They communicate with elements both in the trusted zone and with elements in the un-trusted zone, which is why they are "vulnerable". Their major security function is to protect the NEs in the trusted zone from the security attacks originated in the un-trusted zone. Elements that are located on the NGN provider's domain with connectivity to elements outside the trusted zone are referred to as network border elements (NBEs). Examples of these are the: Network border elements (NBE) at the UNI that interface with the service control or transport elements of the NGN provider in the trusted zone in order to provide the user/subscriber access to the NGN provider's network for services and/or transport. Domain border element (DBE) that is the same kind of equipment with network border element except that it resides at the border of domains. Device configuration & bootstrap NBE (DCB-NBE) that interface with the NGN provider's device configuration system in the trusted zone in order to configure the user's/subscriber's device and NGN provider's equipment in the outside plant. OAMP-NBE interfaces with the NGN provider's OAMP systems in the trusted zone in order to provide and maintain the user's/subscriber's device and NGN provider's equipment in the outside plant.
Application server/web server NBE (AS/WS-NBE) that interfaces with the NGN provider's AS/WS-NBE in the trusted zone in order to provide the user/subscriber access to web-based services. Examples of devices/elements that are operated by an NGN provider but are not located on the NGN provider's premises and that may or may not be under the control of the NGN provider, are: Outside plant equipment in the access network/technology Base station router (BSR), a network element that integrates the base station, radio network controller and router functionalities Optical units (ONUs) within a user/subscriber's residence The "trusted-but-vulnerable" zone, comprised of NBEs, will be protected by a combination of various methods. Some examples are physical security of the NGN network elements, general hardening of the systems, and use of secure signaling for all signaling messages sent to NGN network elements in the "trusted" zone, security for OAMP messages and packet filters and firewalls as appropriate. An "un-trusted zone" includes all network elements of customer networks or possibly peer networks or other NGN provider domains outside of the original domain, which are connected to the NGN provider's network border elements. In the "un-trusted zone", comprised of terminal equipment, equipment may not be under the control of NGN providers and it may be impossible to enforce provider's security policy on user. It is still desirable to try to apply some security measures and, to that end, it is recommended that signaling, media, and OAM&P be secured and the TE-BE located in the "un-trusted zone" be hardened. However, due to the lack of physical security, these measures cannot be considered absolutely safe. 10.5.2 Peering network trust model When an NGN is connected to another network, the trust depends on: Physical interconnection, where the interconnection can range from a direct connection in a secure building to via shared facilities Peering model, where the traffic can be exchanged directly between the two NGN service providers or via one or more NGN transport providers
Business relationships, where there may be penalty clauses in the SLA agreements, and/or a trust in the other NGN provider's security policy
Figure 45:A Peering network trust model
10.1 Standard Security policies Security policy defines the set of rules laid down by the security authority governing the use and provision of security services and facilities. NGN service providers are responsible for defining and implementing these policies to all Network equipments and devices under its control. Hardening and service disablement All NGN elements should be capable of being configured according to the services needed and compatible with NGN infrastructure. Any service or transport layer port that is not required for the correct operation of the NGN element should be disabled on all systems and network elements. In addition, applications are required to run under minimum privileges (e.g., on "UNIX/Linux" platforms applications should not run as root if root privileges are not indispensable). The base operating system (OS) supporting any NGN element should be capable of being specifically configured for security and appropriately hardened. The software access which requires circumvents usual access control mechanisms into any NGN element are usually not permitted to be carried out. In addition to hardening, physical and logical access controls are also put in place to meet industry best-practices. Audit trail, trapping and logging All NGN elements should be capable of creating an audit trail that maintains a record of security related events in accordance with NGN provider's security policy. Mechanisms to prevent unauthorized or undetected modification are
required. The audit trail is capable of being managed and is required to allow old data in the audit trail to be placed on other media, e.g., removable media, for long-term storage. This interface is carried out by an authorized administrator who moves old data out of the audit trail onto removable media. Management of audit trail is to be protected by a specific authorization. SECURITY REQUIREMENTS FOR SECURITY LOGGING AND AUDIT Time stamping and time source The NGN element should be capable to support the use of a trusted time source for both system clock and audit trail item stamping. A trusted time source is referred to time source that can be verified to be resistant to unauthorized modification. Transitive trust is acceptable, i.e., a time source that relies on a trusted time source is itself an acceptable trusted time source. Resource allocation and exception handling Each NGN element should be capable to limit the amount of its own important resources (e.g., memory allocation) it allocates to servicing requests. Such limits help to minimize negative effects of denial of service attacks. Generally, resources used to service requests compete with other resource utilization requests on the system. In addition, each specific NGN application is required to have the ability to limit its own usage of important resources that it allocates for satisfying requests. The purpose of this requirement is to limit the effect of bursts of activity so that they do not affect other service requests. This helps the application and OS capability to signal monitoring systems that the application and/or its platform may be under DoS attack. "Silent discard" feature is included to trap and log the received packet, and discard the received packet while not responding with an indication of the discard (e.g., error response). This enables service provider to limit potential attacks from malicious or incorrect packets. In case, if the resource utilization of the logging operation is so large that it is interfering with other operations of the element, the obvious heuristic to apply is that logging will stop until resource utilization returns to an acceptable level. Code and system integrity and monitoring The network element performs two functions: configuration and monitoring any changes to detect unauthorized changes, both based on the security policy.
Any unauthorized changes are required to create a log entry and cause an alarm to be generated. Monitoring is controlled and it generally does not impact the performance of delay-sensitive real-time communications or unnecessarily cause connections to be torn down. Patches, updates and supplementary code To trust signals generated by NGN provider NGN elements within un-trusted networks, say terminal the software on the system is not compromised the updates are encoded with secure codes. This ensures that Trojans, worms and other viruses are not downloaded onto NGN elements or underlying OS that generate useless traffic or turn systems into "zombies". Such viruses lead to compromise in system integrity, confidentiality and availability of data. NGN provider network elements and systems provide capabilities to verify and audit all their software. The audit results are to be accessible to an OSS. This allows an analysis of the security posture. The Audit log also provides guidance to administrators and providers with respect to where mitigation is necessary. Security patches are obtained from the equipment vendors and installed in a timely fashion, once the NGN provider has certified them. Access to OAMP functions in devices In order to safeguard the OAMP infrastructure, each internal NGN network element is managed through a separate IP address allocated from a separate address block. Each internal NGN network element has a physically or logically separate interface for the exclusive use of this OAMP traffic. When a separate interface is used, the NGN network element silently discard all packets received on the OAMP interface with source addresses other than the OAMP address. The NGN network element also silently discards all packets received over the non-OAMP interface with source addresses assigned to OAMP traffic. Access to OAMP functions is capable of being controlled by authentication. Once a user authenticates into a system, the internal NGN element is track all changes that they make, and provide the opportunity to roll them back. All security relevant use of authorization is logged in the audit trail for a specified time. In particular, all access attempts, successful or not, to the element are required to be logged in the audit trail.
10.1
Technical aspects concerning security
1. Tunneling mechanism Tunneling mechanism should be preferred over instead of source routing. Source routing has the disadvantage of insecurity other than complicated realization and large overhead. An attacker could use a fake care-of address as a media destination address so as to prevent the mobile node from obtaining the useful information. But mobile IPv6 could use routing header to realize source routing safely. 2. Employing IPSec It is an integral part of IPv6 which is backward compatible to IPv4. IPSec is made up of two components, which are IP Authentication Header (AH) and the Encapsulating Security Payload (ESP).AH carry out the functions of authentication of the IP header and integrity checking, non-repudiation and encryption of IP header and payload is carried out by ESP. These mechanisms are algorithm-independent which permits selection of different sets of algorithms without affecting other parts of the implementation. IPSec is a kind of standardized security associations which can provide security guarantee on link layer and transport layer; service providers could implement security strategy according to the service level agreement(SLA) established with users so as to make the management of security associations easier. Moreover, there is only one security association required between the foreign network in which the mobile node is located and the home network; therefore the expansibility of security management is greatly improved. 3. Configuration of firewalls Configuration of firewalls is based upon specific requirements. Firewalls help in protecting the information in private networks against unauthorized visits from illegal nodes. Packet filtering firewall possesses properties like high speed, independency on applications and low-price, but the configuration of this kind of firewall is complicated. And the leakage of mainframes IP address in the private network could not be avoided. Moreover, suspicious behaviors could not be recorded. Application-level firewalls normally use a mainframe connected to a router as a relay mainframe; which can support more sophisticated security strategy and has a simple configuration. Private networks could be shielded by the firewall,
but would suffer lower speed and the possibility of unable to provide connection with legal mobile node. Firewall with secure tunneling could be used to set up VPNs on public networks to enhance the internet level security. Secure tunnel is build with the help of IPSec, which could pass through the Internet, combined with previous firewall; make up a highly secure VPN security system. On the originating end of the secure tunnel, the transmitting node has IP data packets encrypted and encapsulated to be IPSec packets which would subsequently be transmitted through the tunnel to the receiving node, which would decrypt the received IPSec packets and resume them into the original IP packets.
4. Balance between security and complexity Complexity of protocol realization should also be considered along with the improvement of security. It is required by the diversity of services that various security mechanisms be adopted in order to distribute various security level guarantee to different users; but too many security strategies may cause the problem that the management of the system becomes greatly complicated. To simplify the security management, it is feasible to limit mobile nodes from foreign links to visit specific resources. Security could also be strengthened by means of developing Foreign Agents (FA) intelligence level, for instance, adding ACLs (Access Control Lists) which are commonly used to filter IP packets to FA and demand mobile nodes to hold certificates to communicate with FA will lead to highly secure transmission environment.
11. Business case

11.1 Introduction
Presently various telecom services are provided through separate networks. Technological advancements in telecommunications are forcing a trend towards unification of networks & services setting up the stage for the emergence of Next Generation Networks (NGN). In the next generation networks, multiple access networks can connect customers to a core network, which is predominantly based on IP technology. NGN promises to provide number of significant benefits and opportunities both for the service providers and the end-users by providing new innovative services and applications through a common platform.
With the efficient and cheaper IP technology forcing telecommunications networks to migrate to Next Generation Networks, triple play (voice, data and video) would become a basic service. Traffic of different services of data, television and subsequently voice would be simply enclosed in Internet protocol packets, transmitted over these networks. These networks can later support any number of additional value-added services and transmit them also as IP packets. As a matter of fact, a number of telecom operators are already planning to move to such networks. The deployment of NGN would face a number of challenges and obstacles related to evolution of new technologies and services, emergence of disruptive business models, network security risks and competition and level-playing field issues. Unless license conditions and regulations are properly redefined with a light touch regulatory approach, it would be virtually impossible to regulate the emerging NGN technologies smoothly.
Migration to NGN could change the operators business models completely. On one hand, traditional operators would see much greater efficiencies and lower costs as well as possible access to new services, thus boosting revenues and profitability. On the other hand, service independence could create a completely new category of operators i.e. niche service providers who are able to compete effectively with traditional network operators for minimal investment e.g. a IP telephony service providers being able to provide all features of voice service delivered by a traditional fixed operator by investing primarily in only a server. A possible consequence of such new service-only operators directly serving customers is that traditional network operators could become pure access providers where upon all application services (voice, video, broadband and data etc.) are provided by 3rd party service providers.
This could change the business model of the existing operator to the extent that if not managed adroitly, it could prove to be disruptive. Another implication of NGN migration will be that the interconnection regime also would need to change with traditional non-IP interconnection becoming increasingly more expensive and less relevant. It has been commented upon that service providers would need to upgrade to NGN in step with the industry or they may face the risk of lagging behind. Thus the migration to NGNs offers both a huge opportunity to operators as well as poses some serious risks. In this scenario, clear policy direction and enabling regulation could help the industry both reap the benefits of the migration of NGN as well as reduce their investment and commercial risks.
Fixed telecom incumbents world over are looking towards NGN core as a means of significantly reducing their network complexity & operating costs and improving efficiencies of the transmission network.
11.2
Case Study: BT
BT has embarked on its 21CN project to replace all of its core networks, including the PSTN, with a unified NGN. The 21CN project aims to substantially replace all of BTs existing network platforms (PSTN, ISDN, IP, ATM, FR, SHDS (Short Haul Data Service) etc.) with a single unified IP platform. The investment is concentrated in the period 2005 to 2008, and is estimated to be around 3 -5 billion. The primary benefit of 21CN will be cost reduction. BTs fragmented network platform is particularly costly to run, but it also supports a hugely complex legacy product portfolio, with many bespoke products - some that only serve one major customer. BT believes that the rationalisation of this product set should yield very significant cost savings and headcount reductions.
BTs Objectives: In communications, you either innovate and invest..or die - Paul Reynolds, CEO
Figure 46: BT
BT set up Consult21 to create awareness of BTs 21CN project. As a part of the programme BT is talking to regulator, customers, suppliers, and investors. The Consult21 steering board aims to create and manage the framework within which the operators / service providers can agree on interoperability, and consult on the development of next generation products and services (including access and interconnection products with their associated contracts, timeline etc), taking account of Ofcom policy, BT's network capability and industry requirements.
NGN implementation: BT has embarked on its 21CN project to replace all of its core networks, including the PSTN, with a unified NGN. The prime motivation for BT is the cost reduction. BT also set out several key milestones for its programme: Trials of the new technology were to be initiated during 2004-05, with next generation voice services being delivered to 1,000 customers. (It is understood that this phase is implemented as planned) Broadband services will be available to 99.6% of UK homes and businesses by 2005, with growth in broadband services being met by a new Multi-Service Access Node platform i.e. the single access node to provide multiple services like triple play. (It is understood this has also been achieved) The mass migration of PSTN customers is expected to start in 2006, and reach more than 50% by 2008.
Broadband dial tone i.e. conversion of PSTN local loop to Broadband for multiple services access including VOIP is expected to be available to most customers by 2009
Traditional BT network:
Supports hugely complex legacy product portfolio Expensive to run and operate Difficult to manage Separate backbone Difficult to rollout newer services
Figure 47:Single IP architecture
Any service over a single IP transport network Reduced OPEX and operation costs Single backbone Easy to rollout new bandwidth hungry services Reduced planning cycles
Figure 48:PSTN Migration
Financial benefits: BT proved the financial case for NGN, calculating a NPV of $1.1bn and estimating annual opex savings rising to approximately $85m pa. These two outcomes, the roadmap and the business case, gave executives confidence to proceed with one of the largest investments in their history. BT met the clients specific request of providing not just recommendations on what to do, but also how to implement them. Thus, the primary benefit was a highly practical sequence of events that would form the basis of annual planning and budgeting. Additionally, the client was able to decide what projects to start, stop, continue or change, with justifications in their language of choice.
Advanced Services Offered: Over the past several years, BT has transformed itself from a traditional telephony operator into a leading global communications provider with 8.5 billion in revenues in 2005, and 18.3 million customers in the UK and Ireland. The company achieved this transformation by investing in a next-generation network infrastructure that currently brings broadband Internet access to more homes in Britain than have access to water mains. Today, with broadband availability in the UK at almost 100 percent, BT is again evolving its business and expanding its relationships with customers by focusing on a new wave of services designed around the convergence of networks and services, mobile and fixed communications and media. For example, earlier this year, BT Retail, a division within BT Group plc, unveiled its ultra-fast, nationwide 8 Mbps broadband network, designed to support a new portfolio of services such as the groundbreaking BT Vision, which combines broadcast digital TV with on-demand film, TV and music programming. BTs mission is to help its customers easily integrate these new services into their lives, enriching the way they work and play. We dont bring technology, we bring services to the customer, says Stratis Scleparis, chief technology officer of BT Retail. We are committed to providing services that enhance our customers lives, but in order to be successful, they must also be easy and simple to use. That important distinction led BT to Austin, Texas-based Motive, Inc., a leading provider of broadband management software. Motives software allows BT to automate and remotely manage many of the complex tasks required to deploy, configure and support broadband services, ensuring a positive and consistent customer experience. Because BT had planned the release of several new, innovative services this year, working with Motive to simplify the rollout and management of these services was a key strategic goal.
Laying the Foundation for the Digital Home
As part of its efforts to pave the way for more feature-rich services, BT launched BT Total Broadband in July 2006. In addition to increasing download speeds to up to 8 Mbps, the service also offers free Internet voice and video calls, and a suite of security software providing online protection against identity theft, spam email, pop-ups, viruses and hackers all brought together through a residential gateway device called the BT Home Hub. The heart of BTs digital home, BT Home Hub acts as the central delivery mechanism for new broadband services such as wireless networking for all of a familys PCs and laptops, Internet Protocol TV (IPTV), and voice calls over the Internet. The ability to remotely manage the BT
Home Hub is crucial to BTs strategy, as it is the platform from which all of the companys next-generation services to the home will be launched. The company turned to Motive, a strategic partner that BT has worked with for several years, to automate the installation, management and self-help features of its broadband services for both the home and businesses. From its own research, BT knew that customers who were not empowered with Motive solutions for broadband installation and self-help were five times more likely to call customer service for assistance. In fact, over the past year, Motives automated solutions have saved BT more than a million support calls and prompted a quarter of a million text-chat sessions. Customers have told us they prefer self-service whenever possible. If they have to call for help, it is already a negative experience in their minds, says Scleparis. Scleparis says he insists on delivering that same quality customer experience as the company continues to introduce new services. Providing superior customer service remains our top priority. Its what differentiates BT from other providers in the market, he explains. To meet that requirement, BT chose Motive Home Device Manager (HDM) to manage its BT Home Hub offering. With Home Device Manager, BT can remotely manage the Home Hub and deliver service updates. For instance, BT has done firmware upgrades to 500,000 Hubs to bring them in line with the introduction of Microsofts Internet Explorer 7. We were very impressed by Motives proven interoperability with a wide range of routers and devices, and with its commitment to evolving DSL Forum standards, says Scleparis. Their vision of the future in these areas aligns very closely to our own. Motive HDM gives us the flexibility to select our CPE (customer premise equipment) from a wide range of products with the confidence that we will be able to support them, without developing yet another system, says Scleparis. Using Motive HDM, BT is able to activate thousands of BT Home Hubs per month via automated, zero-touch provisioning, and will soon follow suit with its Business Hub service. With sales of more than 500,000 BT Home Hubs to date, the rollout has been most successful. In addition to provisioning the service, customer service representatives also use Motive HDM to get a diagnostic view of the BT Home Hub, including real-time information about alarms and performance issues, and to remotely deploy automated fixes and firmware upgrades. Since we launched Motive HDM, we have derived significant savings from avoiding router firm-ware re-flashes in the warehouse before dispatch, states Scleparis. The companys estimated savings for automated firmware upgrades is about 5 for each CPE over manual upgrades. To date, BT has upgraded about 150,000 CPE through the Motive HDM solution, yielding nearly 750,000 in savings, not including the benefits of faster deployment.
Launching Next-Generation IP Television
With its Home Hub in place, BT has now launched the much anticipated BT Vision, a nextgeneration IPTV service that puts the viewer in control by combining the appeal of TV with the interactivity of broadband. BT Visions extensive library of on-demand content includes movies, music videos, concerts, childrens programming, and recent and classic television programming including drama, comedy and documentaries. To strengthen this offering, BT forged a host of premier content deals with world-class entertainment companies such as BBC Worldwide, Paramount and Warner Music Group. In a unique move, BT requires no subscription or minimum monthly payment for the service. Customers can subscribe to genres of content or pay as they go. This flexible pricing model gives BT customers more control over what they watch, when they watch it and how they pay for it. BT Vision is a cornerstone in our next-generation strategy. It will transform the way our customers see us and the way we behave as a company, requiring even more agility and responsiveness to succeed in the converged world, says Scleparis. BTs customer-focused strategy is evident in its future plans for BT Vision. For example, the company plans to introduce new interactive features based on audience participation, including voting, gaming and communications that enable customers to chat with each other or use video telephony to talk face-to-face while watching programs. With such cutting-edge capabilities, BT expects to have connected hundreds of thousands of customers by the end of 2007 and aims to have two to three million in the next few years.
End-to-End Service Assurance
The convergence of broadband Internet and telephony technologies promises to bring customers a rich variety of new services such as BT Vision. The difficulty lies in managing all of the technology pieces required to deliver those services. The process of configuring the service, and identifying and resolving problems, is not limited to one piece of equipment. Instead, every element in the delivery chain affects the customer experience. Visibility into the set-top box within the home provides only one view of the quality of service the customer is receiving. For BT to guarantee high-quality video-on-demand, the company must not only manage the box, it must also ensure throughput from BTs head-end to the Home Hub at the customers premises. Its important to establish a quality end-to-end link with service guarantees, because when everyone in the neighborhood is connected, throughput can drop, explains
Scleparis. With Motive solutions, we can guarantee the quality of the service. Motives HDM technology will be a key component in our strategy to manage our BT Vision customers endto-end including LAN and router management capability. We are excited by the new possibilities with TR069-compliant devices and the interaction this could give with Motive HDM to enhance the quality and diagnostics of the network. Our strategy is to monitor our services at both the transmission and application layer providing end-to-end assurance capability, he adds. Motive solutions provide a unified, global view of all the service elements in the delivery chain to customer service representatives, so that any disruptions can be proactively managed. Enabling customers with the self-help capabilities to fix simple problems is part of the solution, but we now can fix problems before the customer even knows one exists, says Scleparis. Its a good strategy for a company with the stated goal of providing services on every device the consumer uses to receive digital services, including phones, game consoles, PCs and televisions. BT is already moving ahead with that strategy, and recently received the Communications Solutions Product of the Year Award from the Technology Marketing Corporation (TMC) for BT.
Fusionthe worlds first seamless fixed-mobile phone service
BT Fusion works like a normal mobile phone but switches automatically onto a BT broadband line via a BT Home Hub when a subscriber gets to the home or office. The service offers all the convenience and features of a mobile phone, but with fixed-line prices and quality. Its an exciting time to be part of BT, says Scleparis. We feel confident well win customer loyalty by offering the highest quality, easiest-to-use, and most innovative services. With a strategy that centers on delivering the ultimate customer experience, it appears that BT is already succeeding.
Concerns
Packet losses: a major concern Packet losses are the most important and potentially dangerous aspect of IP networks as far as the security industrys concerned. They can occur at any time and anywhere on the network. Quite often theyre transitory, and dont stay long. Were all used to accessing a web
page which will appear immediately and then if we try again ten minutes later there might be a delay in it appearing on our screen. For error-corrected TCP/IP systems this isnt a problem but, for basic uncorrected DTMF/FSK alarm signals, a VoIP call will almost certainly cause an alert failure on traditional PSTN receivers.
...but 21CN will not be a problem... The major difficulty with these packet loss problems being transitory is that theyll come and go at different times in different places. A full error-corrected TCP/IP security system will identify packet loss and retry using the networks resilient alternate routing mechanism. VoIP will not, though, and the resultant packet loss can be seen by the receiver. This will happen with 21CN, but the real questions are how often is this going to occur and in what circumstances? Moving on to the practical effects of these three potential VoIP problems, theyre manifested in the form of interference and loading. Currently, on a lightly loaded network theyre unlikely to cause problems for security or any other application. Using its mega PR machine, BT is trying hard to tell us all that 21CN will not be a problem, as its designed to cope with packet losses of 10-8. BT would have us believe that a packet loss of one in 10,000,000 is adequate, but this is an average and doesnt take into account peak period problems in any way, shape or form. We need to look beyond this impressive figure. During peak loading, how many calls will BT be maintaining sequentially? Two million? Four million? More? Its likely therell be in excess of 20 million packages per second flying around 21CN. This means we could be losing, on average, three packets per second across the network. That figure could double, treble or increase even more in peak periods. Obviously, some of these will be alarm alerts. Whats acceptable, because these losses and delays associated with VoIP are going to be many times more than weve experienced in the past? Using one of the properly designed and error-corrected TCP/IP security systems will overcome the vagaries of 21CN. Whats even more worrying is that all trials of security equipment carried out by BT have only been conducted on lightly loaded test networks. Even then, some security manufacturers and ARCs have identified problems with legacy equipment.
Conclusion
In light of the above, we understand that BT is already rolling out 21CN in parts of Wales, with 350,000 lines in Cardiff being switched over in 2008 and the rest of the UK following in the years to 2012. BT is giving us assurances that 21CN will not be a problem, but its extremely concerning that there has been no testing of a loaded network in the UK and that participation of the security industry has been minimal. Both BT and the BSIA assure us that theyre currently working together on a test plan that fully reflects the needs of security communications requirements on the 21CN platform. Many hundreds of hours of testing are said to have taken place, identifying concerns that the two organisations are now investigating to produce solutions. The manufacturers of communication products and ARC receiving equipment are reported to be fully engaged in this process to ensure that equipment will work on the 21CN platform, and also to see how the transition to 21CN can minimise the effect on those legacy products that have been installed. End users must be aware of the need for an alternative solution to VoIP. This comes in the shape of dual path IP/GPRS systems. Here, essential data does make it through to the recipient one way or another.
12. References
1. NGN Next Generation Network, MSD conference, Lisbon, October 2005. Stephan Berg, Deutsche Telekom Headquarters 2. The evolution of NGN to an open service platform Regional Workshop on Assistance to the Arab Region for the implementation of Next Generation Networks (NGN) 15-16 December 2009, Cairo, Egypt International Telecommunication Union Marco Carugi ITU-T SG13 Vice-Chairman and Q.3/13 Rapporteur 3. Telecordia technologies, A white paper on NGN services 4. Functional requirement of NGN including overall architecture, Marco Carugi ITU-T SG13 Vice-Chairman and Q.3/13 Rapporteur

906 - Everything Over IP - Dynamics of The Strategic Changes in Voice and Data Networks

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

906 - Everything Over IP - Dynamics of The Strategic Changes in Voice and Data Networks

Uploaded by

Copyright:

Available Formats

A PROJECT REPORT ON

__________________ Research Project Guide

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

NGN Services ........................................................................................................... 31 NGN Models .............................................................................................................. 33

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2

PSTN/ISDN emulation and simulation .................................................................... 64 Interfaces ....................................................................................................... 66

Symbiosis Institute of Telecom Management Research Project Report

5.2.2 5.3 5.4

Call server-based PSTN/ISDN emulation ................................................................ 68 ENUM ........................................................................................................................ 68

8.2.1 8.2.2 8.2.3 8.2.4 8.3

8.3.1 8.3.2 8.4

8.4.1 8.4.2 8.4.3 8.5 9.

Classification of mobility based on network topology .......................................... 93

9.3.1 9.3.2 9.3.3 9.4 9.5

Symbiosis Institute of Telecom Management Research Project Report

9.5.2 9.5.3 9.5.4 9.5.5 9.5.6 9.6 9.7 9.8

10.5.1 10.5.2 10.1 10.1 11. 11.1 11.2

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

A Basic Architecture for a EoIP Network

Symbiosis Institute of Telecom Management Research Project Report

Figure 1 : Logical Representation of the network

Symbiosis Institute of Telecom Management Research Project Report

IMS (IP Multimedia Subsystem)

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Figure 2: Layered Architecture

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Figure 3: NGN Architecture using Soft switch

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Figure 4: IMS and its Environment

Symbiosis Institute of Telecom Management Research Project Report

Figure 5: : Relationship of session control entities to NGN Core networks

Symbiosis Institute of Telecom Management Research Project Report

Figure 6: 3GPP IMS Architectural Overview

3.2.1 Architectural Elements

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Figure 7:Architectural Elements

g) User Profile Server Function (UPSF)

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Figure 8: Multiservice access systems

Symbiosis Institute of Telecom Management Research Project Report

Symbiosis Institute of Telecom Management Research Project Report

Major Disadvantages Increased Opex Increased Capex

Symbiosis Institute of Telecom Management Research Project Report