2008 Whitepaper Migrations To Ngn-Ims

Migrations to NGN/IMS
Devoteam white paper

CONNECTING BUSINESS & TECHNOLOGY
Devoteam Knowledge Communities October 2008

Devoteam
Migrations to NGN/IMS white paper
MIGRATION TO NGN/IMS
DEVOTEAM WHITE PAPER
OCTOBER 2008
2 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Table of contents
Table of contents ...............................................................................................................................................................3 List of figures.....................................................................................................................................................................5 1. Introduction ..........................................................................................................................................................6 1.1. Purpose of the document....................................................................................................................................6 1.2. How to read this White Paper .............................................................................................................................6 1.3. About Devoteam...................................................................................................................................................7 1.4. About the authors ................................................................................................................................................7 2. Driving forces in the Telecoms industry in Europe........................................................................................10 2.1. Markets insights and trends ............................................................................................................................. 11 2.1.1. A gradually eroding European fixed revenue ....................................................................................................... 11 2.1.2. Near saturation on mobile markets has spurred competition ..............................................................................12 2.2. Future of technology and usages in the Telecoms industry .........................................................................13 2.2.1. Changing end-user expectations, behaviours and usage patterns......................................................................13 2.2.2. Advanced technological tools, telecom and media convergence ........................................................................13 2.2.3. Transformation of Telco players positioning and business models......................................................................14 2.2.4. Globalisation transitions .......................................................................................................................................14 3. Regulatory intervention in NGN .......................................................................................................................15 3.1. A market view on regulatory approach............................................................................................................15 3.2. Acting on control points....................................................................................................................................15 3.3. Possible regulatory implications of the technical differences between circuit switching and IP.............17 3.4. Evolutions of charging models ........................................................................................................................20 3.4.1. Charging principles ..............................................................................................................................................20 3.4.2. Charging options for IP-interconnection ..............................................................................................................21 4. Regulatory evolutions in Europe .....................................................................................................................22 4.1. A short history of EU regulation in telecommunications ..............................................................................22 4.2. Current regulatory framework ..........................................................................................................................23 4.3. Current rules.......................................................................................................................................................24 4.4. Regulatory evolutions proposed by the EU ....................................................................................................25 5. Trends in architectures and migration strategies ..........................................................................................29 5.1. Reminder of PLMN migration milestones .......................................................................................................29 5.2. Trends in architectures .....................................................................................................................................32 5.3. Trends in session control protocols ................................................................................................................34 6. Core network migrations...................................................................................................................................37 6.1. Overall strategies ...............................................................................................................................................37 6.2. MSC-Server evolutions towards NGN interconnections................................................................................41 7. Service migration ...............................................................................................................................................44 7.1. Legacy services continuity with IM-SSF .........................................................................................................44 7.1.1. Migration of PSTN/ISDN/Mobile Supplementary Services ..................................................................................45 7.1.2. Migration of IN services using OSA/Parlay ..........................................................................................................48 7.1.3. Interactions between Legacy Services and OSA/SIP applications......................................................................49 7.1.4. IM-SCF: Smooth migration towards SIP applications ..........................................................................................52 7.2. Mobility and voice call continuity.....................................................................................................................52 7.3. IMS service example: the emergency call service..........................................................................................55 7.4. Service enablers: the presence server use case............................................................................................57 7.4.1. Background and concepts ...................................................................................................................................57 7.4.2. PIDF/RPID protocols............................................................................................................................................59 7.4.3. XCAP protocol......................................................................................................................................................60 7.4.4. Example of service improvement with presence: call filtering .............................................................................61 7.4.5. Migration for legacy user to the IMS service........................................................................................................62 3 Devoteam CONNECTING BUSINESS & TECHNOLOGY

7.4.6. 8. 8.1. 8.2. 8.3. 8.3.1. 8.3.2. 8.3.3. 8.3.4. 8.3.5. 8.3.6. 9. 9.1. 9.1.1. 9.1.2. 9.1.3. 9.1.4. 9.2. 9.3. 9.3.1. 9.3.2. 9.4. 9.4.1. 9.4.2. 10. 10.1. 10.2. 10.3. 10.4. 10.5. 11. 11.1. 11.2. 11.3. References...........................................................................................................................................................63 Fixed-Mobile Convergence and access migrations .......................................................................................64 Overview of Fixed-Mobile Convergence technologies ..................................................................................64 A FMC experience: BT Fusion ..........................................................................................................................67 Access migration procedures ..........................................................................................................................67 Architecture & Design ..........................................................................................................................................69 Migration Preparation...........................................................................................................................................70 Lab Verification of Migration Strategy ..................................................................................................................71 Pilot site migration................................................................................................................................................71 Migration procedure (D Day)................................................................................................................................72 Post migration ......................................................................................................................................................73 Messaging, transport and service access migrations ...................................................................................74 Messaging evolutions .......................................................................................................................................74 Sending messages...............................................................................................................................................74 Receiving messages ............................................................................................................................................74 Legacy mobile messaging interworking (SMS & MMS).......................................................................................75 Specific SIP based messaging.............................................................................................................................76 Signalling transport ...........................................................................................................................................78 Access to Legacy services from NGN network ..............................................................................................80 Optimized routing with non migrated MNP database ..........................................................................................81 Further applications of the SIP <-> INAP interworking ........................................................................................83 Access to NGN services from legacy network ...............................................................................................84 Optimized routing with migrated NP database.....................................................................................................84 Access to Diameter based NGN online charging system ....................................................................................86 An operator migration use case: BT21C's network transformation .............................................................88 BT21C network goals.........................................................................................................................................88 BT21C network evolution in UK .......................................................................................................................88 BT21C architecture ............................................................................................................................................89 Network migration strategy ..............................................................................................................................91 Customer Premises Equipment compatibility testing strategy ....................................................................91 IMS simulation and test tools developed by Devoteam.................................................................................92 IMSLoader...........................................................................................................................................................92 SITT tool..............................................................................................................................................................94 Conclusion (comparison IMSLoader / SITT tools)..........................................................................................97

List of figures
Figure 1 PLMN migration from GSM to GPRS Figure 2 PLMN migration from GPRS to UMTS Release 99 / Release 4 Figure 3 PLMN migration from UMTS Release 4 to UMTS Releases 5/6 Figure 4 Core Network architecture evolution timeline Figure 5 Session Control Evolution (interconnection) Figure 6 - Migration to NGN (first step of a 2-stage evolution strategy) Figure 7 - Integration of IMS after NGN migration (second step of a 2-stage evolution strategy) Figure 8 Interconnection between MSC-C and SIP TPO Figure 9 Interconnection between MSC-C and SIP-I TPO Figure 10 Interconnection between MSC-C and SIP-I TPO in BCS architecture Figure 11 IM-SSF role in the network Figure 12 Network elements impacted by service migration Figure 13 AGCF role in the network Figure 14 - Smooth evolution to IN Figure 15 - Fixed-Mobile convergent services in OSA architecture Figure 16 Service components in IMS Architecture Figure 17 - SCIM integration in the network Figure 18 - SCIM as Single Point of Orchestration in IMS architecture Figure 19 SDP usage in both 2G and IMS architecture Figure 20 - VCC: Routing MT call from CS to IM CN Figure 21 Voice Call Continuity scenarios Figure 22 - General Architecture for Emergency Call Figure 23 - Emergency call setup Figure 24 Presence server concepts Figure 25 Enhanced call filtering with presence awareness Figure 26 Legacy user migration to IMS presence service Figure 27 Universal Mobile Access architecture Figure 28 Devoteam OnePhone FMC solution Figure 29 - Access migration concept Figure 30 - Example of migration methodology phases Figure 31 - SGW usage Figure 32 - SS7 / SIGTRAN Protocol Family Figure 33 - SIGTRAN protocol usage in Voip environment Figure 34 IMS PSTN interworking without early NP access Figure 35 - IMS PSTN interworking with early NP access via originating S-CSCF trigger point Figure 36 - IMS PSTN interworking with early NP access via ENUM (DNS) Figure 37 - Legacy 0800 service accessed from IMS Figure 38 - PSTN IMS interworking without early ENUM access Figure 39 - PSTN IMS interworking with early ENUM access Figure 40 - Camel Diameter IW for online charging Figure 41 - BT's UK network before 21CN Figure 42 - BT's 21CN domains Figure 43 - BT's 21CN protocols used between domains Figure 44 - IMSLoader architecture Figure 45 - SITT architecture Figure 46 - SITT GUI 30 31 32 33 34 38 39 42 43 43 44 45 46 48 49 50 50 51 52 54 55 56 56 58 62 63 65 66 68 69 78 79 79 81 82 83 84 85 86 87 89 90 90 93 94 96 5 Devoteam CONNECTING BUSINESS & TECHNOLOGY

1. Introduction
1.1. Purpose of the document

The migration to next generation networks will be a change with many challenges. The existing blue print scenarios will never cover all the expected migration environments. There are many combinations possible between legacy networks and all-IP networks. Also, the motivations and functionality requirements often differ in every project. Devoteam has build up experience in many migration scenarios and is able to help customers from the initial phase with requirements, concepts and solution selection towards realization and validation afterwards. Within this white paper, the landscape in which migration scenarios will take place is described. Also the involved technology and standardization is explained more in detail. The detailed information on migration paths and test strategies show the competence and value Devoteam can offer to customers. With several study cases, the hands-on experience is explained in more detail.
1.2. How to read this White Paper

The document's ambition is to lead a reader who has knowledge of the existing circuit-switched telephony networks through their migration to NGN and IMS-based architectures. As such, its scope is very wide and ambitious, as it attempts to describe the various challenges the industry has to overcome with overall the circuit packet paradigm shift, ranging from the technological issues to evolutions in business models and including regulatory changes. The first sections (2, 3, and 4) describe the overall landscape evolutions caused by the circuit the telecoms industry from a business and regulatory perspective. Section 5 presents the general trends in telecommunications architectures and protocols. Sections 6 to 10 cover the migration strategies in various domains (core, access, services, messaging, transport, service access between legacy and NGN networks), a detailed migration procedure (access migration), and an operator use case. Section 11 describes some of the test tools developed within Devoteam group to test NGN / IMS networks. packet paradigm shift in

1.3. About Devoteam
13 years after its creation in 1995, Devoteam Group has become the number one consultancy and engineering company in information technologies in Europe, specializing in information system infrastructures. Combining consulting and technology solutions offers enables Devoteam to provide its customers with independent advice and effective solutions that meet their strategic objectives (IT performance and optimization) in complementary areas: networks, systems infrastructure, security and e-business applications. Devoteam achieved a turnover of 370 million in 2007, up 39% over the period, with a 29.2 million operational margin, up 40%, amounting to 8.3% of turnover. The group counts 4,000 employees through over 20 countries in Europe, Middle East and Africa. Listed on the Euronext Eurolist B compartment since October 1999, it is part of the NextEconomy, CAC SMALL 90, IT CAC 50, SBF 250 indexes of Euronext Paris. In 2008, following the acquisition of the international divisions of auSystems formerly owned by Teleca, Devoteams telecom business unit counts 500 consultants in France alone, and over 1000 in Europe. Telecoms now represent 33% of the groups activity.
1.4. About the authors

Devoteam provides an efficient global knowledge management environment (knowledge communities, forums, document databases, workgroup collaboration tools, continuous education including e-learning courses, etc), allowing consultants to share their experience. The NGN/IMS work group was formed on an international basis by the Telecom, Networks & Media Knowledge Community and globally coordinated by the community leader, Franois Mouillaud. Its purpose was to leverage the experience of Devoteams telecom community into a state-of-the-art study that can address the operators' issues related to NGN migrations.

Franois Mouillaud (francois.mouillaud@devoteam.com) has 18 years experience in the telecom industry and joined Devoteam Solutions in 2000. His assignments in the telecom services area include Sigtran M3UA introduction in a service platform providers portfolio, support of SMS services in production and introduction of the Color Ring Back Tone IN service for a mobile operator, specification of a major evolution of the pre-paid IN service and MVNO offer for a leading manufacturer, validation of Push To Talk services in IMS environment, and specification of Full IP interconnection architectures between operators. An active member of the Telecom Knowledge Community, he created and contributed to several Devoteam University courses and is currently the Community Leader. Since 2006, he is based in Lannion, a Brittany-based Telecom BU division that bears telecom integration and development offers for operators and equipment providers. He was recently on assignment studying Full IP architecture evolutions for a global operator. Patrice Crutel (patrice.crutel@devoteam.com) has 22 years experience in the Telecom industry and joined Devoteam Solutions in 2007. He has been member on behalf of Ericsson of the ETSI group responsible of the INAP protocol specification during 8 years; He was at the same time one of the Product Managers of the SSF Functional Entity within the Ericsson Switch AXE10, contributing to the creation of the Ericsson INAP CS1+ protocol. He has been then member of the OSA group in ETSI contributing to the MPCC API. He is responsible within the Business Unit Telecom of Devoteam of a department of architects and experts in the Core Network and Service Network layer for both 2G and 3G (IMS). He is one of the creators of the product developed in partnership with Teligent group called Service Interaction Manager and its evolution towards IM-SSF, IM-SCF and/or SCIM and was recently responsible for all development and integration activities of IN, OSA/Parlay, Parlay X and SIP applications for both network operators and Application Servers providers. Frdric Martelli (frederic.martelli@devoteam.com) participated to the implementation of the SIEMENS OMA push-to-talk service platform and studied for French operator many IMS service implementations (telephony, SMS, MMS, Video Sharing and Instant Messaging) based on the ETSI NGN TIPSAN architecture. Maarten Verlinden (maarten.verlinden@devoteam.com) has 10 years experience in the telecom industry and joined Devoteam Telecom & Media in 2007. His expertise lies in the core signaling network area, both legacy SS7 and interworking towards IMS/NGN. Practical experience includes development, system/solution architecture and technical sales in the area of GSM & Telephony Signalling protocols (SS7 MAP/INAP/TCAP/SCCP/MTP ), STP/SRP/ R4 CMN (signaling routing), SMS based security, Mobile Number Portability, EIR, SIGTRAN, Online Charging (DIAMETER), IN SIP interworking, SMS SIP /SMPP interworking.
Dirk Raeymaekers (dirk.raeymaekers@devoteam.com) has 20 years experience in the telecom industry and joined Devoteam Telecom & Media in 2007. His expertise lie in the areas of GSM & Telephony networks and architecture, GSM protocols and routing, GSM rating & billing, Mobile Data access via WAP & WAP GWs, Enabling services with OMA 8 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Presence and Messaging technologies like SMS /MMS/ Mobile IM (IMPS) / OMA IM in 2G & 3G networks and interworking between legacy & IP based services.
Tom Van Pelt (tom.van.pelt@devoteam.com) has 9 years experience in the telecom industry and joined Devoteam Telecom & Media in 2007. His area of expertise lie in the voice services on access devices, Cellular Data access control and session handling, Messaging technologies like SMS, MMS and OMA IMPS (Wireless Village), OMA IMS enabling services like Presence and Group Management and IMS applications like PoC, OMA SIMPLE IM, GSMA Video Share and Image Share. He has also had a strong focus on the interworking between messaging services using different technologies and on the packaging of several services in an integrated offering.
Ludovic Bourdin (ludovic.bourdin@devoteam.com) has been working for 4 years in the field of value-added services (Voice mail, SMS, MMS, chat) in various levels: tendering management on IN services, technical project management on a prepaid billing platform and lately marketing studies (benchmark of communication suites and Content business analysis) for mobile operators..
Sylvain Weyl (sylvain.weyl@devoteam.com) has 20 years experience in the telecom industry. He has worked successively for TRT/Philips, Lucent Technologies, Siemens, and joined Devoteam Solutions in 2005. His telecom expertise lies in the areas of equipments for transmission and telecom network management as well as in telephony & GSM/UMTS architectures and NGN/IMS evolutions.
Thierry Hardy (thierry.hardy@devoteam.com) has 10 years experience in telecom industry and joined Devoteam Solutions in 2005. He has built an expertise in GSM, PSTN, intelligent network, and on IMS network and architecture, especially on services and charging domain.
Damien Boutoille (damien.boutoille@devoteam.com) has 10 years experience in the telecom industry. He worked for major manufacturers in the ATM, H.323, video over IP, SIP, IMS, including presence service. In parallel he is teaching VoIP in several French engineering universities ("Grandes coles").

2. Driving forces in the Telecoms industry in Europe
The telecom & media market has radically evolved during recent years, as far as infrastructure, services and contents are concerned. Convergence has linked elderly-dissociated segments like fixed telephony, mobile and broadband and competition has increased between different players.
Content majors Broadcasting groups
Web players
Telecom actors
Multi services convergence
Electronic manufacturers
Network sphere
IT sphere
This world is likely to go on changing in the next years, driven by the competition dynamics as well as exogenous factors, which can be gathered in 3 categories: End user expectations, behaviours and usage patterns Technological progresses Globalisation, regulation and public policy At the end of an investment cycle and at the beginning of a new era, IMS is likely to be presented as the universal underlying tool for service design and implementation.

2.1. Markets insights and trends
Over the past decade, growth of the European telecom services market has gradually eroded from 2-digit growth rate at the end of the 90s, to 3% estimated in 2006. It is due to the conjunction of two main factors: The decrease of fixed voice revenues (still 1/3 of the total telecom service revenues), which have fallen by an average 2% per year since 2001, whereas the wireline data services (including Internet Access) dont compensate the decline of fixed voice. A slower growth rate in the mobile sector (2/3 of the total telecom service revenues), coming from a near saturation of the market and a reduction of ARPU.
2.1.1. A gradually eroding European fixed revenue

Within Europe-top5 (France, UK, Spain, Italy, and Germany), the fixed voice market has declined 5.9% in value between 2001 and 2005, resulting from: Pricing pressure, due to the arrival of alternative operators since the early 2000s. The lower usage costs were not compensated by the rise in subscription costs. Access line losses, through a dial-up to broadband migration and an increased number of households having only a mobile phone access. Fixed line usage decline. This decline was exclusively driven by the decline in dial-up Internet usage while fixed telephony usage has been fairly stable.
This strong attrition of the fixed voice market is unfortunately not compensated by the strong growth in broadband. Between 2001 and 2005, Internet revenues in EU-25 more than doubled, 95% of which generated in EU-15 markets. The expansion of the broadband subscriber base has fuelled the increase in revenues. Its impact on revenues has been partly limited by the parallel decrease in dial-up Internet revenues (subscriptions and communications). The fall in tariffs, through enriched bundles, price reductions and promotions, has indeed permitted to create a mass-market. Along with customer base expansion, the broadband market has seen a swift development in service availability and quality. In many Western European countries, DSL is already available to over 90% of households Incumbents' market share on broadband has steadily declined in recent years, with less than 1 subscriber out of 2 (in retail). Broadband accesses are shared between DSL and cable: 11 Devoteam CONNECTING BUSINESS & TECHNOLOGY

The DSL still counts for 80% of the whole broadband access. Broadband access through wholesale or unbundled lines are growing at a fast pace. The situation on cable depends widely on the country. Some cable operators are unable to provide a competing broadband offer (due to infrastructure upgrade costs) while other already reach a high market share. The consolidation on this market is likely to reinforce the role of cable in the future.
2.1.2. Near saturation on mobile markets has spurred competition

With an equipment rate in Western Europe now averaging 100%, competition between operators to acquire and retain customers has increased. Generally, new 3G operators havent dramatically changed the landscape. MVNOs have grabbed a noticeable share too (12% in 2007), but only on the mobile market due to them being unable to sign commercial agreements with network operators. At last, the mobile number portability has had a major impact on competition, when the duration and complexity of the procedure wasnt prohibitive. With a mobile penetration now close to 100% (and even above in western E-U countries), the customer base wont grow much more. Operator will soon have to rely on usage and tariffs trends to increase their profits. But even so usage continues to increase at a good pace (+5% per year between 2001 and 2005), operators competition and reinforced regulation have made prices drop. As a result, the ARPU, after peaking in 2004, is slowly decreasing.
Estimation of mobile ARPU in Western Europe Indicators 2006 2012 Active mobile subscribers penetration 101,6% 120,1% ARPU voice communications 24,4 22,6 Share of ARPU voice communications 80,7% 67,6% ARPU data 5,8 10,8 Share of ARPU data 19,3% 32,4% Total ARPU 30,3 33,4 Source: Analysys
As a potential source of increased profit, the launch of 3G services hasnt come up with the operators expectations. Despite significant progress, the 3G market is growing slowly, and the base of 3G customers barely reaches 11% in Europe (mid 2008). In the next years, the competition is expected to take place more on the data market than on the voice market.

2.2. Future of technology and usages in the Telecoms industry
This section briefly goes through the multiple forces that will shape the future of the market.
2.2.1. Changing end-user expectations, behaviours and usage patterns

Telco operators will have to adapt their offer to meet the needs of different kinds of users. On one hand, younger people, more tech savvy, have a wide appetite for innovation but arent loyal to a definite brand and easily switch from a service to another. They dont like the all-in-one packages for communicating and prefer a do-it-yourself approach, mixing different (cheap) services that best suit their changing lifestyle. On another hand, the ageing population, afraid by tech-complexity, is more interested in plug-and-play products, even at higher price. Communication is becoming more and more personal. Where some years ago the household communication was exclusively bound to the fix phone, it relies today on personal devices (mobile phones) or accounts (Internet). Users now make personal choices about their own consumption, expecting the best possible personalized services. Thus, Telco will need to adjust their model to potentially address hundreds of niches. With more and more time spent away from home or from office, nomadism and hyper mobility will become the new norm. Telecommunication will have to adapt and develop as much as possible the mobility market, allowing clients to call, browse, watch TV and keep in touch with their community at every moment.
2.2.2. Advanced technological tools, telecom and media convergence

Progresses in processing and storage capacity, as well as miniaturization, pave the way for a proliferation of connected edge devices. Emerging technologies like nanotechnologies and energy management shall play a major role in tomorrows communication services.The IP protocol, originally confined to the Internet world, is now spreading over all communication technologies and is becoming the new norm. IP-based networks offer an opportunity to carry numerous and different services over a single network, sharing the same bandwidth. This implies that the cost of distribution of a service or an application can be mutualised and therefore significantly reduced. In addition, network and wireless technologies are becoming more efficient, allowing an ever increasing bandwidth, thus accelerating the rise of new technologies and services. The development of optical multiplexing is even expected to boost this bandwidth to very high values. Telco operators next challenge is to get ready to monetize abundance (rather than price capacity scarcity), with further massive price drops.

With digitalization of contents, a new era of media consumption has arrived. It is the end of the one device, one application paradigm, with customer able to read a content on different devices and able to read several contents on the same device (e.g. mobile phone). The digital information marginal costs are almost nil, and technology progresses allow a reduction of the application/service production costs. Concerning the TV, new technologies have made it possible to broadcast high-def TV (larger and better picture and better sound), with large impacts on the telecom/internet/media area: development of pay-TV, replacement of home equipment and a growing need in bandwidth. TV on mobile is slowly emerging and is going to be a major market in the short to medium term.
2.2.3. Transformation of Telco players positioning and business models

Technology, regulatory and globalisation disruptions are weighing on carriers' traditional revenue model based on distance and/or duration pricing of a scarce resource (network capacity). These pressures and the severe pricing dynamics observed call for an evolution of carriers' revenue model along multiple possible dimensions: New pricing schemes for existing services: transition to fixed or flat rate (e.g. for VoIP), additional services for free More value for money. Larger service and content offering with new end-user services, even outside the telecom business (e.g. m-payment). Expanded wholesale strategies to rely on 3rd parties to resell (e.g. unbundlers) or use (e.g. application providers) enriched connectivity. Developing new funding mechanisms for services. Advertising has attracted the attention of almost every player from the extended Telco world. Online advertising is on the rise: from 9% in 2006, its share in the European advertising market is expected to reach 18% in 2012. Meanwhile, the global amount of advertisement expenses should double from 7.5 billion dollar in 2006 to 16 billion dollars in 2012.
2.2.4. Globalisation transitions

In the coming years, the reshuffle in regional balances will produce new industrial giants both in telecom services and equipment (the prominence of Chinese equipment vendors already being a reality). For the moment, mobile carriers in emerging countries rather address their domestic market (where they find plenty of growth opportunities), but they could soon address the Western markets where the average ARPU is much higher. These globalisation transitions will influence future technology standards, as industrial giants eager to push a home-made technology may weight a lot on the international normalisation process. Devoteam CONNECTING BUSINESS & TECHNOLOGY 14

3. Regulatory intervention in NGN
3.1. A market view on regulatory approach
The rationale for regulatory intervention during the transition from monopoly to competition ensures a level playing field for all market participants by regulating the main control points passed forward from the monopoly era residual market power and network bottlenecks. Learning from these experiences, regulators may view their job in the NGN marketplace as something similar: identifying control points and applying the appropriate regulation. They have to distinguishing between potential control points that promote normal competitive activity, and those that may harm competitive activity, and must be cautious when putting in place ex-ante measures, ex post tools being seen by a large part of the industry as sufficient in a mature market. Ex ante tools include regulations put in place in anticipation of a problem, such as those to ensure cost-based, nondiscriminatory access to the incumbents bottleneck facilities by competitors, and the blocking of alliances seen as anticompetitive. Ex ante tools could be interesting in an NGN environment as competition law has proven to be too slow. Ex post tools are mainly antitrust remedies under competition law applied after an abuse of market power is alleged or demonstrated. Regulators should be careful of not regulating too early and the long-term risk and reward aspect must be taken into account. Players should be allowed a certain level of freedom when building services and gaining market. In a mature market, competition law (ex post) is seen by many as sufficient although it is recognized that operators need to be careful in such an environment. Ex post tools could represent a financial risk to players in a fast moving market like NGN where a significant part of an operators revenue could be put at risk if a dominant or abusive position is alleged or proved.
3.2. Acting on control points

The NGN environment includes a wide range of facilities that in theory could have open interfaces and/or could be provided competitively. Each could be seen as candidates for being considered as relevant markets, but most would normally be subject to competitive pressures without a need for regulatory intervention. Only where there are significant bottlenecks or control points that threaten to block the development of the market can ex ante regulation be justified as a means to achieve fair competition. The real challenge posed by NGN is to understand where these can appear in an environment that will be quite different from the PSTN and mobile environments, which are familiar to regulators. They could well be related not to the transmission layer but to some other aspects of service 15 Devoteam CONNECTING BUSINESS & TECHNOLOGY

creation. The potential control point need not be owned by the operator, and could equally well be a critical software platform controlled by a software vendor. There is no consensus in the market that such control points will emerge with NGN, nor a common understanding of what the potentially harmful control points would be. It would be important for regulators to understand where to look for those control points that can become sustainable and/or irreversible sources of dominance and which would lead to market failure unless addressed by ex ante regulations. Such control points would involve ownership of elements necessary to provide certain services and that could not easily be replicated. The local loop is a classic example of such an element. In an IP setting, there could be other elements equally critical for the provision of a certain set of services. They would probably be strongly related to individual customers. Control points could also take the form of market power that would enable an operator to impose bundling and/or interoperability limitations reducing customer choice and competitive alternatives. Below are a number of examples of functions that are expected to play important parts of the NGN environment and which therefore could provide basis for control points. Network capabilities. What can be done with the infrastructure and how can dominant operators limit infrastructure capabilities for competition? Elementary Services and NGN capabilities. What services can be built and how can a dominant operator restrain competitive service alternatives? Accessing services and content. What services can a user access and how can operators and service providers limit his choice? User information. What can providers know about a user which facilitates service provision? If dominance over a given control point is achieved, a next step for the regulator is to consider whether some type of ex ante action is necessary. Under the new regulatory framework, such action can only be contemplated after having followed the procedure for definition of a new relevant market. The European Commission plays a strong role in this process through its recommendations on relevant markets, as well as its power to veto markets defined at the national level. Leaving the procedural issues aside, the assessment of whether to introduce an ex ante regulatory requirement can be extremely difficult because of the complexity of the NGN environment and because the consequences of regulatory action cannot be entirely foreseen. This is the basic challenge for regulators in the NGN environment where there are risks associated with any course of regulatory action or indeed inaction. There are several good reasons why regulators should be reluctant to step in: 16 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Search for success is a natural business objective that may lead to a strong but not necessarily dominant market position warranting regulatory action. Inappropriate Intervention would alter the risk and reward calculations that drive investments and could create the impression that success will be punished by regulators. This could chill investment in the NGN sector and delay NGN development The control point could be part of a new service which, in principle, should not be regulated The business models of the service environment may not yet be stable and regulatory intervention could freeze market structures that are not efficient or viable in the longer term Inappropriate regulatory requirements may in effect mean the regulator would pick winners and losers The importance of the control point could fade away over time with new technology or other service alternatives. This means that consequences of regulatory inaction over time could be less important than they appear at the outset There is thus significant risk that regulatory intervention could be counter-productive in the sense that the regulator would in effect be micro-managing the market instead of letting the market find its own solutions. Furthermore, the potential negative consequences of inaction could be remedied in time by other mitigating market developments. All of this suggests that regulators should avoid the temptation to intervene unless significant negative consequences of inaction are clearly foreseen. On the other hand, it cannot be ruled out that dominance over certain control points could lead to serious barriers to market entry and thus justify ex ante regulation. In extreme cases, lack of regulation could actually hamper development of the information society and the associated benefits. Ideally, there should be competition in as many domains as possible and market capture of a critical control point that can limit a range of competitive alternatives will require serious consideration.
3.3. Possible regulatory implications of the technical differences between circuit switching and IP
IP differs from Circuit Switching (CS) in a number of ways that have regulatory implications. Some of the major differences between CS and IP as communications networks are summarized below, along with the implications these differences may have for regulation. SS7 signaling vs. IP addressing The provision of advanced services in a CS network is based on an Intelligent Network framework, which is reached through the SS7 signaling network. Services in an IP network are based on servers 17 Devoteam CONNECTING BUSINESS & TECHNOLOGY

which are accessible through normal IP addressing. There are more opportunities for open interfaces in IP networks. This provides a potential for wider participation and more competition in advanced communications services. Interoperability and open interfaces will become important issues as there will be many more forms of interconnection and access than in the CS environment. There is a potential for more geographic independence as a server can be located anywhere in the global IP network, whereas in the SS7 network only interconnected operators can have access. Network centric service creation vs. network independent service creation The creation of network services in a CS network is largely under the control of operators of the CS network. In an IP environment services can be created by integrating service components from various independent service providers distributed across networks and geography independently of the underlying network infrastructure Physical presence can no longer be used to determine where a service is located in terms of networks and geography. It may be difficult to determine the country in which a service originates and thus to identify the applicable national law. Regulators have to assess whether open interfaces to service components are necessary or if interoperability can be implemented through gateways that perform conversion between interfaces. Switching vs. routing Basic components of a CS network are the switches that perform service and management related functions, in addition to establishing the transmission path from caller to receiver. The basic components in the IP environment are routers, which forward packets toward their destination, and servers which perform service functions. Servers can be addressable units in the network and communicate using the same protocols as user terminal equipment. There is a potential for clearer separation between the transmission / control layers and the service creation layer, as functions in these layers are carried out by different equipment types. In open IP networks, there is the potential for more geographic independence between the user location and service creation. This could lead to more international competition for communications services, for example, through sophisticated forms for call-back services capable of dynamic optimization based on real-time tariffs and currency rates.

Clear vs. blurred boundaries In CS networks, there is a distinction between the network and the user equipment attached to it. Functions carried out in user equipment are normally not covered by telecommunications regulations beyond technical compliance requirements. CS networks provide a clear boundary between network and user terminal equipment, and intelligence is mainly centralized. The boundary between network and terminal equipment is less clear in the IP environment, and intelligence is distributed between end-points and control devices within or at the edge of the network. New criteria may be required for determining whether a given function belongs to the network, and therefore may or may not be covered by its regulations. Connection-oriented vs. connection-less CS is connection oriented, meaning that a signaling phase takes place before the communication starts in order to trigger preparatory actions at the receiver end as well as along the transmission path. Signaling can also occur during the communication to adjust parameters, and occurs at the end of the communication to release resources. In the lower layers, IP operates in a connection-less manner meaning that packets are sent out and received without any prior warning or preparation. Connection-less communications don't have clearly defined start or end times. One consequence is that time-based tariffs become unsuitable where cost orientation is a regulatory requirement. Dedicated circuits vs. different routes CS is based on the set-up of a dedicated circuit for the duration of a call, while IP will transmit packets using several different routes and infrastructure for a single communication In CS, time can be related directly to network usage while in IP networks this is not possible. Time based tariffs become unsuitable where cost orientation is a regulatory requirement. Numbering vs. names and addresses The CS numbering system is based on ITU Recommendation E.164 numbers. The numbering system is controlled jointly by ITU and national authorities. The IP addressing system is based on IPv4 or IPv6 addresses in combination with domain names. It is controlled by ICANN, which is a non-governmental international organization. With the transition to IP, control over numbering resources is being transferred from governmental to nongovernmental organizations.

3.4. Evolutions of charging models
3.4.1. Charging principles
Charging principles can be based on different measurements: Element Based Charging (EBC): the interconnection rates depend on the number of network elements as well as distance. Capacity Based Charging (CBC): the central feature distinguishing CBC from EBC is that, under CBC, system bandwidth is bought in advance by competitors. This leads to a more adequate risk sharing between incumbent and competitors Distance Independent Charging Charges based on grades of service Charging principles in telephony networks or IP networks can be seen from two levels, retail and wholesale. At the retail level, there are generally two methods of payment: Calling Party Pays (CPP): the calling party pays for the call. Receiving Party Pays (RPP): the calling party and the called party share the cost of the call. CPP is the most common charging principle for charging voice calls, while RPP is used both for the retail billing in the Internet and in the mobile market in North America. At the wholesale level, three billing models exist: Calling Party Network Pays (CPNP): the network of the sender pays to send. Bill and Keep (B&K): each network bears the costs of terminating traffic coming from other carriers. There is no interconnection charge. Receiving Party Network Pays (RPNP): the network of the receiver pays to receive. CPNP applies to both the calls in the PSTN and the European mobile sector, while B&K applies to both the Internet traffic and the mobile sector in the USA. CPNP might cause termination monopoly (arbitrage problem). B&K, on the other hand, makes operators have an incentive to hand over their traffic into another network for termination as close as possible to the point of origination ("Hot potato" problem). It also provides less incentives for operators to monitor inbound traffic for assuring a guaranteed level of QoS, as no payments are made for carrying this traffic. One feasible solution for the "Hot potato" problem is to require a minimum number and location of POIs. 20 Devoteam CONNECTING BUSINESS & TECHNOLOGY

3.4.2. Charging options for IP-interconnection
As charging principles used in the telephony networks are different from those used in the IP networks, charging issues arise when interconnecting PSTN and IP networks. While conceiving the charging principle for IP interconnection, two cases should be distinguished: the all-IP world and the transition phase. Key factors to be considered are: Termination monopoly at the wholesale level Familiarity of end-users with CPP and RPP Relationship between wholesale and retail pricing Compatibility with retail tariff schemes Network and usage externalities In the all-IP world, three variants of dual regime using different principles in accordance with the type of networks, the services or the network levels have been conceived: Different regimes for different types of networks: B&K for the IP network and EBC/CBC for the PSTN. Different regimes for different services: differentiation according to services or QoS classes. Different regimes for different network levels: B&K on the access/backhaul level (between customer and POI), and EBC/CBC for transit in the core network. The first type of dual regime is not viable in the long run, as VoIP calls give rise to arbitrage opportunity. The second type requires clear distinction between different services and that the usage of services be measurable. The third one helps minimizing the "hot potato" problem. For this type, determining the number of POIs at the access/backhaul level is crucial. The options for managing the transition phase towards all-IP infrastructures are considered in two conditions: When "Pure" B&K is the long-run target regime, options to soften the transition process include the following (either way, it is preferable to keep the period where PSTN and IP networks run in parallel as short as possible): o o o o IP-based networks simply substitute for the PSTN, preferable if the transition to all-IP networks comes quickly. The interconnection regime is adapted to B&K for the PSTN. Elements of these regimes are present in transit agreements. The assurance of QoS might increase the willingness to pay for network usage. When EBC/CBC is the long-run target regime:

4. Regulatory evolutions in Europe
4.1. A short history of EU regulation in telecommunications
Over the past two decades the European telecommunications sector has moved from a tradition of strong public service monopolies, often twinned with national postal services, to one of increasing privatisation and competition. EU policy has evolved with the sector supporting common development, promoting competition and harmonisation. Since 1987 a policy phase saw liberalisation as the main focus and culminated with the liberalisation of all telecommunications services and networks by 1 January 1998. The 1998 framework was reviewed in 2002, when growing convergence between telecoms, broadcasting and information technology meant the rules had to be adapted. Today, with the EUs emphasis on Growth, Competitiveness and Employment telecommunications policy is at the heart of Union policy. The revision launched in 2007 seeks to bring the framework up to date for the fast-developing telecoms sector in a Union which now has 27 Member States. The regulatory process for telecommunications reflects the wider process of economic integration in Europe. The main policy theme has been the move towards a single market for telecommunications services and equipment that progressively removes barriers to pan-European operation and supply. This policy has seen an evolving interaction between four elements: liberalization, harmonization, competition and public service. Three instruments have been used to liberalise the sector in Europe: progressive liberalisation of former monopolies, accompanying harmonization measures, and competition rules The main mechanisms to promote liberalization were directives which abolished the special rights of certain public enterprises to produce or supply telecommunications equipment or services, which then breached competition and internal market rules. These Directives required Member States to allow competition in the market for telecommunication services, but did not require the privatization of national public services. To complement the liberalization directives, a series of harmonizing measures were also adopted. The 1990 Framework Directive established the principle of Open Network Provision: essentially harmonized open access to public telecoms networks. This directive was developed in the mid-1990s to adapt to the evolving competitive environment and together with further Directives on Interconnection and Licensing made up the 1998 package of legislation which established the basis for the full opening of EU telecoms markets on 1 January 1998. The legislative package was accompanied by comprehensive guidelines on the application of EC competition law in this new business environment.

The 1998 package was primarily designed to manage the transition from monopoly to competition. With rapidly changing technology, convergence and the new challenges of truly liberalized markets a single, coherent framework of regulation covering all electronic communication, including broadcasting networks, was agreed and applied from 2003. The 2003 policy framework largely replaced the 1998 package catering for a dynamic and potentially unpredictable market involving more players and a more complex multi-faceted telecommunications market environment. The review of the 2003 framework launched in November 2007 seeks to build on the gains that consumers have already realised in the telecoms market. Competition has grown strongly in some cases, less so in others. Prices have fallen in many sectors, and EU initiatives such as the Roaming Regulation have helped bring them down in others. But the market is still largely fragmented, with few operators offering services across several Member States. The revised rules will focus regulation on those market sectors where competition is still lacking, and develop stronger EU-level regulation to foster the development of the internal market. Since the last regulatory package was adopted in 2002, new developments in the telecoms sector have left the current regulatory framework in need of updating. To take account of the changed sectoral landscape, the Commission launched a review of the current regulatory rules in November 2007. The Commission's proposals for reform have yet to be discussed and approved by the EU's decisional process.
4.2. Current regulatory framework

The European Unions new framework for regulation of electronic communications services became applicable in July 2003. Its purpose is to encourage competition, to improve the functioning of the internal market and to guarantee public and user interests in the electronic communications sector. This regulatory framework consists of one general Directive, Directive 2002/21/EC of the European Parliament and of the Council of 7 March 2002 on a common regulatory framework for electronic communications networks and services (Framework Directive) and four specific Directives: Directive 2002/20/EC: Authorization Directive, Directive 2002/19/EC: Access Directive, Directive 2002/22/EC: Universal Service Directive, Directive 2002/58/EC: Directive on privacy and electronic communications sector. The Access Directive contains detailed rights and obligations for operators and undertakings seeking interconnection 23 Devoteam CONNECTING BUSINESS & TECHNOLOGY

and/or access to their networks or associated facilities, and the Universal Service Directive describes the minimum scope of universal service obligations and rules for its costing and financing. The Framework Directive provides the overall structure for the new regulatory regime and sets out regulatory principles that NRAs must follow. European Regulators Group (ERG) In order to assist the European Commission and facilitate the implementation of the new regulatory framework, new committees and working groups have been created: the Communications Committee, the Radio Spectrum Committee, the Radio Spectrum Policy Group and the European Regulators Group (ERG). The ERG has been set up by Decision 2002/627/EC. It aims to provide suitable mechanisms for encouraging cooperation and coordination between National Regulatory Authorities (NRAs) and the Commission, in order to promote the development of the internal market for electronic communications networks and services, and to achieve consistent application of the Directives of the new regulatory framework in all Member States. Independent Regulators Group (IRG) The Independent Regulators Group (IRG) is a group of European NRAs established in 1997. Its objective is to share experiences and points of views among its members on issues of common interest such as interconnection, prices, universal service, and other important issues related to regulation and development of the European telecommunications market. At present, the IRG includes NRAs of 33 countries, including France, Germany, Poland, Spain and the United Kingdom. National Regulatory Authorities (NRAs) National telecommunications Regulatory Authorities are the national regulatory institutions responsible for issues such as licenses, price control, dispute resolving. The NRAs shall carry out the regulatory tasks specified by the five Directives.
4.3. Current rules

The EU legal framework for regulating telecoms services has been developed with the aim of developing a betterfunctioning internal market for telecommunications networks and services. Last revised in 2002, this framework is currently being updated, to take account of developments in this fast-moving field. In the Information Society, boundaries between telephone, internet, television broadcast and mobile phone services are becoming blurred, even irrelevant. Indeed, frontiers between Member States have also lost much of their significance when it comes to these services. The regulatory approach to the different services has also to converge. In 2002, the European Union adopted a new regulatory framework for electronic communications networks and services, covering all forms of fixed and wireless telecoms, data 24 Devoteam CONNECTING BUSINESS & TECHNOLOGY

transmission and broadcasting. The regulation of the content carried by such services is, however, dealt with under separate rules. In the internal market, telecoms operators and service providers have the right to set up and offer their services throughout the EU. Encouraging and enabling them to take advantage of those rights boosts the overall quality of telecoms services for consumers, and reduces the prices they have to pay for them. The EUs regulatory framework aims to promote fair competition, which will boost Europes economy by supporting activities which relies on telecoms, create a strong telecoms industry in Europe, and make consumers the ultimate beneficiaries.
4.4. Regulatory evolutions proposed by the EU
The current rules which govern the telecoms sector in the EU were agreed in 2002. In this fast-developing sector, the regulatory framework needs to be revised, to ensure it continues to serve the best interests of consumers and industry in todays marketplace. The Commissions review proposals, adopted in November 2007, will bring the EUs rules up to date. In economic terms, the telecoms sector is one of Europes most important, with annual turnover of around 290 billion, and around 4% of the jobs in the Union. More widely, the prices charged by the telecoms sector represent a direct cost of doing business in Europe. Liberalisation in the telecoms sector in the EU, launched in the mid 1980s, has brought significant benefits for consumers. The price of telecoms services have fallen, on average, by around 30% in the past decade. Moreover, the introduction of competition has raised standards of service all round, making former monopolies much more respondent to the needs of consumers. Although EU action has brought major benefits, there is still work to be done to create an effective internal market in telecoms, which would bring even greater benefits to consumers and businesses alike. Today there are only a few operators providing pan-European services, and one of the reasons is the different ways in which national regulators have implemented the EU framework. The internal market is fragmented, with the result that operators have to package their services in different ways in different Member States, and satisfy different regulatory requirements each time. That fragmentation is hindering effective cross-border consolidation, and often blocking or delaying the entry of new competitors to the market. One aspect of the Commissions proposals is to review the regulatory approach, to ensure that national regulators have the appropriate tools and powers to ensure fair competition. The successful introduction of the Roaming Regulation in summer 2007 demonstrates that action at EU level can be effective in securing benefits for consumers. The Commission is therefore proposing to create an EU-level telecom market body to complement the national regulators. 25 Devoteam CONNECTING BUSINESS & TECHNOLOGY

The European Telecom Market Authority will build on the existing collaboration between national regulators in the ERGhttp://www.erg.eu.int/, providing the power to act centrally when required. A new EU-level authority will make it easier to coordinate action across the internal market. The new authority will also act as a European centre of excellence for network and information security, helping the Commission to step up the fight against spam, and taking over the tasks of the European Network and Information Security Agency (ENISA). A Chief Network Security Officer in the new authority will have responsibility for this important task. Whilst the reform will tackle some areas where the current rules have still not opened up the market to competition notably where former incumbents continue to dominate the Commission recognizes that the rules have worked in others. Therefore, it proposes to remove the requirements for ex ante regulation in major parts of the telecoms sector. In these markets, ex post regulation will become the norm, i.e. operators will have to seek redress for any problems through application to the competition authority and/or through the courts. In the future, therefore, regulatory action will focus on those sectors of the telecoms market where competition has so far been most restricted. That is not to say that we will allow the achievements in improving services and reducing costs to consumers in those markets where regulation will become lighter to be reversed. Regulators will still monitor those sectors, and take action if necessary and the picture will vary from Member State to Member State. By focusing regulatory efforts and resources on the sectors where it is most needed, the Commission aims to win the greatest benefits for consumers, in the shortest possible time. The Commissions proposals for the review of the telecoms framework, adopted on 13 November 2007, are the result of two years of consultations with stakeholders, with national regulators and with users of telecoms services. They will be debated in the European Parliament, and by Member State governments in the Council. Once adopted at EU level, the revised rules have to be incorporated into national law before taking effect. The Commission expects the new framework to be in place from 2010. The proposals focus on four key areas. More competition Competition in the telecoms sector brought more choice to the markets. However, we need more competition for Europe's telecoms sector to achieve more investment, greater innovation and lower prices. The Commission will maintain ex-ante regulation in those markets where competition is not yet effective, and keep a close eye on those markets which are crucial for Europe's competitiveness (such as broadband). The reform will also give national regulators the possibility to introduce functional separation when necessary. That means that an operator would have to split up its services division from the division managing the infrastructure, although both would stay under the same ownership. This will ensure that competing operators have access to infrastructure without discrimination. 26 Devoteam CONNECTING BUSINESS & TECHNOLOGY

From country to country there are major differences in how the current rules are implemented. That is why the proposed new rules give the Commission the power to oversee remedies proposed by national regulators, to help ensure a more consistent, efficient and speedy application of these across the EU. Better regulation At the heart of all Commission action, the better regulation initiative means that regulatory action should only be taken when justified, and should be proportionate. In the telecoms sector, the Commission proposes to remove ex-ante regulation from 11 of the 18 markets within the telecoms sector, including both retail (from operators to consumers) and wholesale (between telecoms operators) markets. In particular, retail regulation is not necessary where there is already effective wholesale regulation, allowing new entrants to find acceptable terms for access. In future, regulators will focus their resources on market sectors in which the dominance of incumbents has been least challenged. In those markets, regulators need to continue their efforts to create conditions in which new entrants can effectively stimulate competition, improve services and lower costs for consumers. The Commissions proposals also seek to enable the telecoms sector to make better use of radio spectrum. Management of radio spectrum will be made more flexible and market oriented, to make sure those industries dependent on spectrum can reap the maximum economic benefits of this vital and scarce resource. Furthermore, the digital dividend the valuable part of the spectrum released through the introduction of digital television broadcasting and resultant analogue switch-off will be available for new uses. To take full advantage of this opportunity, the Commission proposes these frequencies to be used more flexibly, so that service providers themselves decide on the value to be placed on the different services that could use it. Strengthening the internal market The telecoms sector in Europe today is still largely fragmented on national lines. Few operators are active throughout the internal market, and even fewer offer pan-European services. Regulatory inconsistency through different interpretations and applications of EU rules is a major reason why the internal market in telecoms has not developed more strongly. Operators seek certainty in the regulatory approach throughout the Union, and so the lack of consistency has been a major barrier to their investment outside their home Member States. National markets are all distinct, and the Commission underlines the necessity of independent national regulators who each know their own market taking responsibility in each Member State, but coordination and consistency across the Union needs to be improved. The ERG created under the current regulatory framework has encouraged national regulators to work together, and with the Commission, to seek EU-level solutions to common problems. Indeed, the ERG has been central to initiatives such as reducing the costs of roaming to mobile phone users. But achieving consensus in a body with representatives of 27 Member States is no easy task, and the ERG has no power to implement its agreements across the Union. The 27 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Commission is therefore proposing to create a European Telecom Market Authority, building on the coordination efforts already established amongst regulators. National regulators will be at the heart of the new bodys work, but it will have the power to act across the EU. Protecting consumers better The fast developing telecoms market has brought major benefits to consumers, and the EU has already legislated to ensure all citizens have a basic set of rights, including access to a telephone/internet connection and protection of personal data, as well as specific rights for people with disabilities to be able to gain access to telecoms services. The Commission proposes to build on these existing rights, to ensure that consumers benefit from the development of competition in the telecoms market. In particular, operators will be obliged to publish information on prices so that consumers can more easily compare the different offers on the market. Operators will also be obliged to facilitate transfer of customers from one service provider to another, so that they can effectively take advantage of better prices and conditions. Member States must improve access to telecoms services for people with a disability, including access to the single European emergency number, 112. Security and privacy have become critical in the development of the Information Society, and therefore of the telecoms services which provide its backbone. Consumers are becoming more and more concerned about possible misuse of their data, including information which could be used to track their movements. In particular, consumers worry about criminal misuse of their financial information, and so the Commission proposes that telecoms operators must inform customers in the event that their personal data becomes compromised. Spam, spyware and related malicious uses of the telecoms system threaten to stunt the growth of the Information Society, and the proposals would step up EU efforts to combat them, in particular the creation of a Chief Network Security Officer within the European Telecom Market Authority to work with telecoms regulators to identify and lead the response to all threats to European telecoms networks.

5. Trends in architectures and migration strategies
This chapter deals with general migration trends and strategies for various functional entities in the network. More detailed migration procedures relative to a specific domain such as access, core network, messaging, or services will be addressed specifically later in the document. In general, a migration strategy involves a choice between options such as: An "island" solution involving overlay between a TDM component and an NGN component (each one serving different purposes and the NGN one being dedicated to limited load or functionality, for example NGN-specific features such as new services) General overlay between a TDM component and an NGN component (each one serving the same purposes, with load sharing between the two) and gradual migration towards the NGN component following usage adoption Complete replacement of the TDM component by an NGN component, with possible fallback upon failure This approach is made complex by the fact that there is generally not a complete functional overlap between "equivalent" components in the TDM and NGN architectures (the NGN adds new features and may cause the loss of legacy features which need to be emulated or simulated), and by the interdependency between functional domains (e.g. the core network and the service architecture). Nevertheless, the migration is usually dealt with by functional domains. This is the approach retained in this chapter, which we introduce by a reminder of PLMN migrations between GSM and UMTS architectures.
5.1. Reminder of PLMN migration milestones

From GSM 2G to 2.5G GPRS The GSM standard has been built with the same focus as the PSTN network: it is a circuit-switched network, primarily aimed at providing telephony services, with the added functionality of the radio access and of mobility. As in the case of PSTN networks, data sessions have been made possible, but with the constraints of a circuit-switched network, e.g. poor utilisation of the bandwidth utilisation from the operator's perspective and low data rates. GPRS services have been launched from mid-2001 and provide a more efficient way of handling data traffic. As illustrated in the figure below, the innovation of GPRS is to introduce a packet-switched core network in the mobile operator's network, enabling the activation of packet-based "always on" data sessions. 29 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Figure 1 PLMN migration from GSM to GPRS From 2.5G GPRS to UMTS release 99 and UMTS release 4 In the first release of UMTS, UMTS release 99, the core network principles remain the same: it uses a circuit-switched core network for voice service and a packet-switched core network for data services. The main change lies in the radio access part, called UMTS Terrestrial Radio Access Network (UTRAN), enabling higher data rates, as shown in the figure below. Release 4 offers further services and features such as Virtual Home Environment (VHE) and Open Service Architecture (OSA). Release 4 also fully supports Location Services.
Figure 2 PLMN migration from GPRS to UMTS Release 99 / Release 4
From UMTS release 4 to UMTS release 5 and release 6. UMTS release 5 introduces a major change in the core network: the circuit-switched core network disappears and the architecture becomes all-IP. Voice calls can be carried on the converged IP network, using SIP as the signalling protocol for call set-up, as has been specified by 3GPP, and IPv6 as the version of the IP protocol. The access network and the packet-switched network remain the same, but UMTS release 5 introduces the concept of IP Multimedia Subsystem (IMS). The IMS includes all new control and signalling functions for the management of multimedia sessions, including voice calls and data sessions. It is functionally separated from the packet-switched core network, which provides the transport functionality.
Figure 3 PLMN migration from UMTS Release 4 to UMTS Releases 5/6
5.2. Trends in architectures

Circuit-switched architectures are today deployed with circuits and signalling managed by monolithic switches. ISUP signalling and TDM links are used to carry voice calls between exchanges, which would be SSP in the fixed or transit domain, and MSC in the mobile domain. This situation has been quickly evolving in the last years, and the evolution from Circuit Switched into IMS architecture can be depicted on an indicative timeline as follows.

Circuit Switched
Cl4 transit SSP
NGN
Cl4 transit NGN CS
IMS
Transit
Fixed
Cl5 subs SSP
Cl5 subs NGN CS IMS
Mobile
R99 MSC
R4 MSC
Arrival Date * > 2010
< 2005
2005-2010
Figure 4 Core Network architecture evolution timeline
In NGN/soft switch architecture, circuits and signalling links are split and managed separately. Call Servers manage the signalling and voice is transported via Gateways on packet backbone. NGN Call Servers control Gateways using Masterslave protocols such as H.248 or MGCP. In most cases, the internal call control logic of NGN Call Servers is ISUP-based and products are in most cases evolutions of corresponding circuit-switched architecture products. NGN Call Servers usually reproduce the network experience of those legacy products. Typical NGN solutions are: NGN call servers (and associated Gateways) in the international backbone for transit domain VoIP call servers introduced on broadband lines in fixed domain MSC R4 introduce NGN architecture in the mobile core network (air interface remaining TDM oriented) IMS is a global, access-independent and standard-based IP connectivity and service control architecture that enables various types of multimedia services to end-users using common Internet-based protocols. As such, it can meet all the needs of fixed, mobile and interconnection models and describes a functional architecture, which means that several physical implementations of IMS are possible.

5.3. Trends in session control protocols
Call control protocols play a key role in telephony system and the signaling interworking strategy is crucial for VoIP interconnections. It has to closely follow the quickly-evolving interworking standardization. The current industry trends can be described like this: Circuit switched networks are widely deployed and ISUP (or variants) are still used today (TDM interworking will be key in the signaling architecture) BICC is today promoted by the mobile community for MSC R4 architecture H323, designed by ITU-T to support VoIP technology, is progressively replaced on the access network by IETF SIP IMS promotes SIP and other IMS-based protocols SIP-I is currently implemented in NGN soft switches and is beginning to be present in MSC R4
Domain
Mobile Fixed Transit
Circuit Switched
NGN
IMS
BICC
ISUP SIP H323 SIP-I

< 2005 2005-2010
SIP-IMS
Arrival Date
> 2010
Figure 5 Session Control Evolution (interconnection)
For mobile operators, BICC is the current session protocol Standardized in 3GPP R4 architecture. This protocol is used and supported by all MSC R4 providers. But BICC is closely focused on GSM/UMTS and is not open to be extended to NGN and IMS. BICC is not the target IP interconnection protocol but it is unavoidable in the context of MSC R4 interconnection. Fixed and Transit networks are more SIP oriented but a transition will be mandatory to migrate from ISUP to SIP. This transition could be supported by ISUP encapsulation in SIP (SIP-I). A common solution to support the PSTN/SDN services between two NGNs is to develop a SIP-I specification based on ITU-T Q.1912.5, and address issues such as security, SIP protocol profile and operator's specific ISUP variant. 34 Devoteam CONNECTING BUSINESS & TECHNOLOGY

If the fixed-mobile convergence based on IMS is the target, SIP should become the protocol for fixed, mobile and transit networks. But many efforts to standardize are yet to provide before they can use this protocol. Indeed, a number of SIP profiles and SIP-I variants for interconnection have been proposed by different standardization bodies. In ITU-T TRQ.2815 defines the common capabilities supported by the interworking between SIP and BICC/ISUP for three SIP profiles: Profiles A, B and C. Profile A makes reference to 3GPP TS 24.229 and was designed for use by 3GPP IMS networks. Profile C, also called SIP-I refers to the use of SIP with a message body that encapsulates ISUP information. Q.3401 defines a SIP profile for NNI (Network-to-Network Interface) between two NGN operators, in order to support voice service, e.g. VoIP (audio, text ), DTMF, T.38 fax, etc.. It contains a service-level signalling profile (i.e. SIP/SDP profile) and a transport-level profile (media transport, e.g. RTP profile; signalling transport, e.g. TCP/UDP/SCCP). This signalling profile can be used on the interface interworking with H.323 networks. There are several differences between Q.3401 and TRQ.2815. Q.3401 it specifies not only SIP/SDP profile (servicelevel profile) but also transport-level profile. This signalling profile is specified to support the interoperability of voice services between NGNs. The interworking with BICC/ISUP network is not the major concern of this specification (could be supported by SIP messages containing MIME encapsulated ISUP), while it is fully included in TRQ.2815. Finally, TRQ.2815 has no specific consideration for the interworking with H.323 networks Q.1912.5 specifies the interworking between ITU-T BICC/ISUP and the three SIP profiles defined in TRQ.2815. It defines the signalling interworking between SS7 BICC/ISUP and SIP at an IWU (Inter-Working Unit) to support services that can be commonly supported by BICC or ISUP and SIP based network domains. In 3GPP TS 24.229 defines a call control protocol based on SIP/SDP for the communication between 3GPP IMS CN subsystem entities: UE, CSCF, MGCF, MRGF, BGCF, AS, etc... (TRQ.2815's Profile A). While IETF SIP specification (RFC 3261) defines two general roles, User Agent (UA) and Proxy, this specification introduces supplementary roles defined to support IMS specific functions. TS 29.163 specifies the interworking between BICC/ISUP based networks and 3GPP IMS. It is the 3GPP variant of Profile A described in ITU-T Q.1912.5. In ETSI TISPAN ES 283 003 defines an IM call control protocol based on SIP for TISPAN NGN. It is the ETSI endorsement of 3GPP TS 24 229. The interface between CSCF and IBCF is added to the applicability of the specification. EN 383 001 specifies the interworking between ETSI ISUP and the three SIP profiles defined in ITU-T TRQ.2815. It is the ETSI endorsement of ITU-T Q.1912.5. Interworking procedures (message mapping, parameter values) between 35 Devoteam CONNECTING BUSINESS & TECHNOLOGY

SIP networks and PSTN/ISDN are modified in accordance with the modifications to PSTN/ISDN protocols made by ETSI. ES 283 027 specifies the interworking between ETSI ISUP and the SIP profile defined in ES 283 003. It is the ETSI endorsement of 3GPP TS 29.163 for SIP ISUP interworking and ISUP supplementary services. TS 129 163 specifies the interworking between BICC/ISUP and H.245 based networks and 3GPP IMS. It is a new version (V7.6.0) of 3GPP TS 29.163. Compared with 3GPP TS 29.163 V7.5.0, it covers not only the interworking of IM basic voice calls, but also the interworking of multimedia services between 3GPP IM CN subsystem and BICC/ISUPbased legacy circuit networks. In particular, it adds the specification for the interworking between 3GPP SIP profile and in-band control protocol for multimedia communication specified in ITU-T H.245. In IETF SIP-T is defined by IETF for the interworking between SIP and ISUP, by encapsulating ISUP message into SIP message body. The protocol suite contains RFC3372, RFC3398. RFC 3372 is the general description which specifies basic principles and possible interworking architectures with PSTN. RFC3398 details the interworking of SIP-T gateways, i.e. the mapping and encapsulation between SIP and ISUP. SIP-T and SIP-I (Q.1912.5 Profile C) compared In SIP-T, only basic call functionality interconnection is specified. ISUP supplementary services should also be supported, but are not yet defined in the specifications. On the contrary, SIP-I specifies not only signalling interconnection (basic call interconnection, BICC/ISUP supplementary services), but also Resource reservation, media information conversion, etc. Compared with SIP-I, SIP-T is incomplete and incompatible with 3GPP/TISPAN, while SIP-I has been endorsed by 3GPP/TISPAN, and has integrated new SIP extensions (e.g. 3GPP extension P-Asserted-ID, SIP precondition, etc.). As for message mapping/encapsulation, SIP-T considers ISUP information as additional information. Consequently, the information contained in SIP headers takes precedence over the information contained in the encapsulated ISUP. SIP-I, however, considers the support of ISUP information as fundamental. The encapsulated ISUP information takes precedence over the information contained in SIP headers.

6. Core network migrations
6.1. Overall strategies
Operators can define strategies at different levels for the improvement of their traditional TDM network (PSTN or R99 PLMN). Evolution alternatives can be based on economic obligations (e.g. foreseen OPEX profits in the end) and technologic considerations, e.g. choice between NGN and/or evolution toward IMS. Network migration can proceed in stages (evolution to NGN in a first stage and then in a second step, introduction of IMS) or operators can decide a technology break (direct introduction of IMS solution that is also mostly suitable to new operators). Note that migration to NGN infrastructure itself can follow different scenarios/strategies, for instance: Progressive mutation of a traditional operator network e.g. Telecom Italia who had decided in a first time only to replace its national/international transit infrastructure and so has introduced a full IP transit infrastructure for fix and mobile, More radical/complete evolution e.g. BT 21 Century Network project with complete lost of interest in their traditional network and deployment of a fully new IP network for both voice and data with end to end NGN soft switch solutions (BT 21C is presented in further details in this document).
st
IN SCP
MNP
Billing System
Mobile CS Network
SS7 MGCP TDM/SDH
Softswitch
MSC
Fix Network
MGW
TDM/SDH
IP Network
Network Management
Switch
PRI
MSAN
POTS Enterprise access
Internet
POTS
DSL
AT A
DSL
POTS IP Phone PC
IP Phone
Figure 6 - Migration to NGN (first step of a 2-stage evolution strategy)
As shown in the figure above, NGN configurations preserve an infrastructure specially dedicated to voice services based on the use of equipments like soft switches and media gateways (MGW). NGN configuration has the advantage in reducing the number of commutation equipments (soft switch) but MGW are always distributed in the whole network (same points of presence as in traditional network architectures).

AS IN
IM S
MNP SCP
Billing System
in fra st ru ct ur Mobile PS Network e
HSS
SIP
MSC
CSCF
SIP
Mobile CS Network
SS7 MGCP TDM/SDH
Softswitch
MSC
MGW
TDM/SDH
Fix Network
IP Network
Network Management
Switch
PRI
MSAN
POTS Enterprise access
Internet
POTS
DSL
AT A POTS
DSL
IP Phone IP Phone
PC
Figure 7 - Integration of IMS after NGN migration (second step of a 2-stage evolution strategy) In IMS architecture, the control function is generally extremely centralized and concerns voice/data services: that allows combining voice and data in a same session. As shown in the figure above, NGN and IMS infrastructures can/will coexist in an operator network at the same time, particularly when a two stages progressive evolution has been decided. Operators must be aware that migration toward NGN introduces new technical difficulties (e.g. problems with QoS) which didnt exist in a TDM traditional environment. Two examples among many: End to end QoS when IP backbone is overloaded, Voice quality in case of network interconnections since all operators doesnt use the same protocols and sets of codecs in their respective network. That can lead, for instance in case of international calls, to multiple and successive transcodings which decrease very significantly the quality of received voice at end-user side.

Preparation of migration The preparation of migration from a traditional TDM network toward a NGN/IMS infrastructure can be foreseen following the 3 mains steps described in the (not exhaustive) list of tasks below: Assessment for traditional Core network resulting in high level design for NGN/IMS (or NGN + IMS): Analyzing existing or proposed network infrastructure and services Network design Connectivity, protocols (SIP, H323, MGCP) Network applications (VOIP, internet, triple play) Security, performance, reliability, availability aspects
Determining the new network infrastructure according to: Reducing costs by ensuring that the existing equipment will be used as much as possible Balancing the customer requirements and their applications with equipment provider's business objectives Selecting the appropriate products Considering performance, reliability, availability and security needs Creating network design alternatives.
Preparing and presenting the new network infrastructure to the customer before their decision on the final design. Access/Core Network detailed design of NGN/IMS evolution Defining the needed infrastructure (equipment, inter-connections, protocols, etc.) Defining needed capacity, dimensioning infrastructure Considering constraints (e.g.. Budget, QoS, security) Specifying control + media plane architectures Specifying service architectures (Conference, prepaid) Considering layer 1-3 (Switching / Routing level) as well as layer 4-7 (Application level) aspects
Functional integration of the network elements into the customer network Retrieving the required database parameters, 40 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Analyzing data (quality, consistency, etc.) Editing and generation of the new database or generation of delta scripts and performing the necessary quality checks with the help of software tools. Development of specific tools might be needed to feed NGN/IMS network elements with acceptable data (in addition to e.g. Planet, Isar) Delivery and documentation of the database. Supporting the customers service personnel concerning database questions.
6.2. MSC-Server evolutions towards NGN interconnections

Several architecture schemas can enable a mobile operator to use its MSC-Servers (MSC-S) for the interconnection with an IP-based Third Party Operator (TPO), depending on the functions available in the MSC-S. The MSC-C should support at least MGCF and MGCF roles, and use BICC for the interconnection with CS domain and SIP for the interconnection with SIP entities. The connection can be direct to the TPO, or pass through an interworking fixed network, but in most cases an I-SBC is used to interconnect with the MSC-C for security reasons and additional features that may be required, such as SIP header manipulations. This section presents several non limitative MSC-S evolution scenarios to interwork with operators supporting SIP or SIP-I protocols. The H.323 interworking scenario can also be supported, e.g. with an IWF between SIP and H.323 (a feature supported by I-SBC vendors), with interworking schemas similar to the ones below. These scenarios illustrate the evolutions that switch vendors could implement in their roadmap to support a Full IP interworking between mobile and fixed operators. The architecture used for the interconnection with a SIP TPO is shown below.
SIP
SIP
SIP
MSC-S
I-SBC
BGCF
SIP
IBCF
MGCF
BICC
H.248
TPO SIP
MGW
IBGF
Figure 8 Interconnection between MSC-C and SIP TPO
For the interconnection with a TPO using SIP-I, many scenarios apply depending on the entities used in the mobile network and the functions available. An interconnection function is always necessary for the interconnection with a SIP-I protocol, and can be located in several entities. Assuming the MSC-Server has a SIP-I interface instead of BICC (a possibility still in discussion in the standards, but not in 3GPP Release 4), the architecture would be like the one below. Alternatively, the I-SBC or other equipment (Call server) could perform SIP to SIP-I interworking (IWF function).
SIP-I
SIP-I
SIP-I
SIP-I
MSC-S
I-SBC Transparent messages
MGCF
IBCF
H.248
TPO SIP-I
SIP-I
MGW
IBGF
Figure 9 Interconnection between MSC-C and SIP-I TPO The MSC-C may also act as a BCS, and include IBCF and IWF functions. The architecture used for the interconnection with a SIP TPO in that case shown below. Notice that the integration of the IBCF function in the MSC-C removes the need to place an I-SBC at the interconnection point.
SIP MSC-S
SIP
IWF
SIP
BGCF
SIP
IBCF
MGCF
BICC
TPO SIP
MGW
IBGF
Figure 10 Interconnection between MSC-C and SIP-I TPO in BCS architecture 43 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Service migration
6.3. Legacy services continuity with IM-SSF
Legacy services are the existing IN/Camel service(s) provided today to Fixed and/or Mobile subscribers (such as for example Pre-Paid Service (PPS), Color Ring Back Tone (CRBT), Number Portability). While implementing IMS, it is relevant for the operators to preserve and leverage their existing infrastructure investments. The IM-SSF facilitates the use of current IN services to IMS users, without any change to the IN service logic or platform (SCP). This allows users to continue using their trusted and familiar services when changing to new IMS devices. It also enables operators to get a head-start on launching IMS, extending the time in which new IMS services can be tested and proven mature enough for IMS users. This functionality is critical for the rollout of new, converged offerings, while continuing high-value service to customers. To perform the migration smoothly, the interface towards HSS allows retrieving the Camel specific information to be included in operations towards SCP.
SCP
IN/Camel service
SCP
IN/Camel service
INAP/CAP IM-SSF IMSIM INAP/CAP
HSS MAP Cx
Enablers & Framework ISC
ISC
SIP
I-CSCF
Home Access Network
S-CSCF
GGSN
P-CSCF
Figure 11 IM-SSF role in the network

6.3.1. Migration of PSTN/ISDN/Mobile Supplementary Services
With the evolution of the traditional networks (SSPs, MSCs) to Telephony soft switches and/or IMS Core entities such as the S-CSCF, the current PSTN, ISDN and/or Mobile Supplementary Services have to be migrated to SIP or OSA-based applications. The migration implies impacts in various elements of the IMS Core and Service Network layer and correspondences can be found between the legacy and IMS network elements and roles, as follows:
SCP
AS
IN/Camel service
SIP appl. appl.
SCP
INAP/CAP
ISC
HSS SCIM
Diameter ISC
HLR
IN/Camel service
MAP
INAP/CAP
S-CSCF iFC
ISC ISC
SSP SS
DSS1
SSF CCF
ISUP DSS1
AGCF AGW
SSP also implies GSMC
Figure 12 Network elements impacted by service migration The main IMS requirements with regard to PSTN/ISDN Emulation architecture are: All PSTN/ISDN services shall remain available and identical (i.e. with the same ergonomics); such that end users are unaware that they are not connected to a TDM-based PSTN/ISDN. End to End ISDN feature transparency shall be ensured for call transiting through the PSTN/ISDN Emulation subsystem. In order to achieve those requirements, the main impacts on IMS Requires new entities (residential/access gateways, access gateway controller) with H.248 interfaces. This entity is called Access Gateway Control Function (AGCF). 45 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Requires SIP with encapsulated ISUP. Most IMS entities re-used unchanged (transparent to the ISUP bodies) or with minor changes (e.g. removal of ISUP body, based on destination). ISDN/PSTN service logic / call model shifted to Application Servers (AS).
Other applications Network Attachment Subsystem

PSTN/ISDN supplementary services and IN services logic) Application Servers
Ig S1 D1 D9
D5
HSS
D4
D6
Charging Funct ions

Ib
D3
IWF
Ic
Ia
SLF
If D10
D2
S-CSCF
S8 S6
I-CSCF BGCF
S5 S9 S7 Ig
S2
IBCF
SIP-I
S3 S4
Other IP Networks
AGCF
H1 D8
Ie
MRFC
H3
MGCF
H2
SGW PSTN/ISDN
Id
!"
H.248 Resource and Admission Control Subsystem
S/T
A-BGF
MRFP
T-MGF I-BGF
Z MG
IP Transport (Access and Core)
Figure 13 AGCF role in the network
SCIM would take over the interaction issues of the PSTN/ISDN Supplementary Services previously handled in Local Exchanges. This could be for example the handling of the Flash option as RE-Invite procedure. It would also be responsible for the interaction of the existing non-migrated legacy services and the new SIP applications. Note that a set of PSTN/ISDN Supplementary Services has been subject to standardization as part of the PST/ISDN Emulation Subsystem (PES). The list of PSTN/ISDN Simulation Services includes CDIV, CONF, MWI, OIP/OIR, TIP/TIR, HOLD, ACR, AoC, CCBS/CCNR, MCID, ECT These services are specified in TISPAN as detailed in the list below.

Doc. Nb. TS 183 016 Ver. 1.1.1 Ref. DTS/TISPAN-03036-NGN-R1 Technical Body: TISPAN 03 Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Malicious Communication Identification (MCID); Protocol specification NGN MCID
Doc. Nb. TS 183 011 Ver. 1.1.1 Ref. DTS/TISPAN-03029-NGN-R1 Technical Body: TISPAN 03
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Anonymous Communication Rejection (ACR) and Communication Barring (CB); Protocol specification NGN ACR & CB
Doc. Nb. TS 183 010 Ver. 1.2.1 Ref. RTS/TISPAN-03069-NGN-R1 Technical Body: TISPAN 03
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Signalling Control Protocol; Communication HOLD (HOLD); PSTN/ISDN simulation services NGN HOLD
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Signalling Control Protocol; Communication Hold (HOLD) PSTN/ISDN simulation services NGN HOLD
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR); Protocol specification NGN TIP/TIR
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification NGN OIP/OIR
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Message Waiting Indication (MWI): Protocol specification NGN MWI
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Conference (CONF); Protocol specification NGN CONF
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification NGN Cdiv

6.3.2. Migration of IN services using OSA/Parlay
The PARLAY-OSA APIs were designed to work on multiple types of network: Fixed IN networks Mobile networks using CAMEL Next Generation IP-based Networks. As such, OSA AS can be seen as a Next Generation IN, opening the development of applications to 3 parties (Telco and IT developers). The following figure illustrates how the OSA layer may allow the coexistence of legacy and IMS services in a common platform, through the OSA gateway.
Service Network Application Servers
SAs SA
rd
Web Portal
OSA API
OSA/Parlay Gateway
MMS Parlay 5.x
Framework
MPCC
UI
MMSC Internet SMSC GGSN
S CP
SSP PSTN MGW
Softswitch NGN ADSL
GMSC HLR PLMN
SGSN GPRS
OLE SIP Phone
INAP SIP MAP
Figure 14 - Smooth evolution to IN The advantage of such approach is an easy integration into IMS architecture. Development of Fixed-Mobile convergent services is also facilitated, as the OSA SCS is responsible to map the OSA APIs into either INAP or CAP protocols.
Application Layer Application Servers

SAs SA
Web Portal
OSA API
OSA/Parlay Gateway
Framework MPCC UI MMS Parlay 5.x
MMSC INAP SIP SIP
SMSC IMS HSS S-CSCF SSP PSTN MGW ADSL OLE SIP Phone MGC I-CSCF MRF WiFi AP MGW WiFi SIP Phone P-CSCF MSC Server SGSN
GGSN
IP
Figure 15 - Fixed-Mobile convergent services in OSA architecture
6.3.3. Interactions between Legacy Services and OSA/SIP applications

There might also interaction between new SIP / OSA applications developed in SIP/OSA AS and existing Legacy Services (INAP/Camel). For that reason, the SCIM or service broker should be the Functional Entity invoked by the S-CSCF and should be able to handle interaction between SIP applications (interface towards the SIP ASs via the ISC protocol) and the Legacy Services (interface towards the IM-SSF via the ISC protocol). The Service Capability Interaction Manager (SCIM) was introduced in 3GPP TS 23.002, Figure 6a: Functional architecture for the provision of service in the IMS as a function within the "SIP Application Server" domain of the IMS architecture. The SCIM is not yet fully standardized and this entity's role is quite different from vendors' point of view. Although there is only a small amount of text in the 3GPP Release 6 specifications describing this function, it is clear that it is intended to be a placeholder for an obviously necessary but vendor-defined solution to a common problem: orchestration of interaction between "Capabilities" in the larger network which are represented as SIP Application Server instances. SCIM allows SS7-based IN/Camel service platforms to coexist and interact with SIP-based platforms to deliver unified services across virtually any network type. 49 Devoteam CONNECTING BUSINESS & TECHNOLOGY

The overall architecture would then appear as follows:
Web Portal
Parlay X AS OSA AS
Service Layer
CSE/SCP CSE/SCP CSE/SCP
OSA AS SIP AS SIP AS SIP AS
ISC
OSA
OSA
CAP/INAP
HSS
Service Broker
ISC
P-CSCF
I-CSCF
S-CSCF
MRF
MGCF
MGW
Figure 16 Service components in IMS Architecture
In this architecture, the SCIM acts as a central point that can handle service primitives coming from various connectivities, and handle them transparently whether they come from an Intelligent Network, SIP, or OSA/Parlay network interfaces.
Service Layer
CSE/SCP
OSA API
OSA SCS
CAP/INAP
IM-SSF IM-
ISC
ISC
ISC
HSS
SCIM
S-CSCF
P-CSCF
I-CSCF
MRF
MGCF
MGW
Figure 17 - SCIM integration in the network 50 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Since both SCIM and IM-SSF have the responsibility of handling the interaction between either SIP applications and IN/Camel services, the two functionality could be merged into one Functional Entity referred in the below figure as SCIM.
SCP
IN/Camel service
SIP AS
SIP appl. appl.
INAP/CAP SCIM
SIM INAP/CAP
ISC
HSS Cx Cx
SIP
Enablers & Framework SIP
ISC
SIP
I-CSCF
Home Access Network
S-CSCF
GGSN
P-CSCF
SCIM allows SS7-based IN/Camel service platforms to coexist and interact with SIP-based platforms to deliver unified services across virtually any network type. It could also include the OSA SCS feature and in that case become the Single Point of Orchestration (SPO) of the various types of applications (SIP, OSA, Parlay X / Web, INAP/Camel) as follows:
Web Portal
Parlay X AS OSA AS
Service Layer
CSE/SCP CSE/SCP CSE/SCP
ISC
OSA
OSA
CAP/INAP
HSS
Service Broker
ISC
P-CSCF
I-CSCF
S-CSCF
MRF
MGCF
MGW
Figure 18 - SCIM as Single Point of Orchestration in IMS architecture Devoteam CONNECTING BUSINESS & TECHNOLOGY
51
6.3.4. IM-SCF: Smooth migration towards SIP applications

The migration towards IMS-Core Network is not achieved in one shot. Operators do have mixed networks where both 2G and IMS Core Networks do co-exist. For that reason, it is relevant for the operators to be able to allocate the new developed SIP and/or Parlay X applications to existing PSTN/ISDN and/or GSM users.
Operational Support Systems
sdk
...
SDP INAP/CAP MM7

Service Broker IM-SCF IMIM-SSF IM-
SCP
IN/Camel service
BSS
Ro/Rf SIP
SIP appl. appl.
Parlay X appl. appl.
MMC SMSC
Cx
ISC
SMPP
PS
HSS
Cx Cx
SCIM
INAP/CAP ISC
VMSC MSC
Home Access Network
GGSN
I-CSCF
SIP
S-CSCF
SIP
PSTN Network SSP
P-CSCF SIP
MRF
Figure 19 SDP usage in both 2G and IMS architecture
The IM-SCF performs the mapping of the SIP messages into INAP and/or CAP and/or MAP operations, allowing the SIP applications to be used in the 2G network.
6.4. Mobility and voice call continuity

Mobility is one of the main feature on which the IMS-NGN will be judged. Its one of the reasons given by operators to move to IMS. Mobility handles several concepts: 52 Devoteam CONNECTING BUSINESS & TECHNOLOGY

mobility between networks, as considered by VCC (and UMA) applicative mobility total or partial mobility Mobility could also be seen as an access internal mobility, out of the scope of this document (inter WIFI cell). The first real application provided about mobility was the VCC (Voice Call Continuity), mirror of the UMA solution for FMC (Fix and Mobile convergence). Its a solution to follow (seamlessly) a voice call between GSM and WIFI-IMS domains thanks to an anchoring mechanism on IMS. Voice Call Continuity (VCC) has been added in 3GPP standards in R7 release. VCC allows subscribers to call (and be called) from two different domains, Circuit Switch (CS) and IMS (IM). It allows the continuity of the call from one domain to another one in case of the access coverage conditions of the first domain are not guaranteed (handover). VCC is based on Anchoring call method; as the call shall be anchored in the IMS domain in a so-called VCC application (i.e. SIP AS). Different new definition numbers have been added for VCC: IMRN: IP Multimedia Routeing Number CSRN: CS Domain Routeing Number VDI: VCC Domain Transfer URI VDN: VCC Domain Transfer Number Different Anchoring types exist: Originating/Terminating call in CS CN subsystem; Originating/Terminating call in IM CN subsystem. The following highlights the use of the IM-SSF for the invocation of the IN/Camel service(s) together with VCC:
VCCCS
SCP
Generate an IMRN
Get an IMRN
IN VCC-IM PPS
SCP SIP-AS
HLR
Triggering based on T-CSI Prefix removal Use of Tel URI
HSS
M AP
IM-SSF
ISC
M AP ISUP
CAP Cx Cx ISUP SIP SIP
GMSC
MGCF
I-CSCF
S-CSCF
SIP
H248 PCM (TDM)
H248 Media (TDM)
M-MGW
IM-MGW
Media (RTP)
Triggering based on iFC
Figure 20 - VCC: Routing MT call from CS to IM CN
As the VCC-CS IN Service Logic is to be invoked as a Camel service, it removes the possibility to invoke existing IN services such as CRBT (Colour Ring Back Tone) or IN PPS (Pre Paid Service). A possible alternative is that the IM-SSF would take care of the invocation of the existing IN/Camel services such as Ring Back Tone (RBT), Pre-Paid Service (PPS), and their interaction issues. VCC was not really successful on the market, due to limitations (single call, only voice, not IP-to-IP mobility ). This IP technical solution does not introduce real enrichment of the UMA (GSM only) architecture for the operator. VCC needs naturally to be enhanced with multimedia and between different IP domains, accesses or devices. Its the work proposed by the 3GPP MMSC (Multi-Media Session continuity) study (3GPP TR 23.893).
UE-2
UE-2 Voice A IP Network B E D PS IP Video Text
Voice Video
IP Network
CS
UE-1
UE-3
UE-1
UE-4
Figure 21 Voice Call Continuity scenarios This study was firstly divided into a new specification (TS 23.237 about service continuity (stage 2 available for now, and stage 3 targeted for end of 2008). Due to R8 end of specifications, only some of the propositions of the MMSC were renewed. The real mobility (or service continuity) with media division on several devices, different accesses will be a R9 contribution. The real mobility targeted by IMS-NGN will include: Predictive mind: The intelligence will be assigned to different parts: The device, particularly for domain mobility An AS (enhanced VCC functionalities) that will handled the SIP legs associations and media mobilities References [1] - 3GPP TS 23.206 - Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2. [2] - 3GPP TS 24.206 - Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 3. [3] - 3GPP TR 23.893 - Feasibility study on multimedia session continuity [4] - 3GPP TS 23.237 - IP Multimedia Subsystem (IMS) service continuity; stage 2.
6.5. IMS service example: the emergency call service

The PES subscribers (analog subscribers migrated from PSTN to IMS environment) have to be able to call any emergency centre (Police, Fire fighter, Life Safety) in the same way as in PSTN environment. New functional entities have been added in IMS in order to route the emergency calls towards the correct emergency centre or PSAP (Public Safety Answering Point) based on the subscriber location information. The following figure shows a summarized architecture of 55 Devoteam CONNECTING BUSINESS & TECHNOLOGY
UE-3
UE-4

an IMS environment including the new entities related to emergency calls.
LRF
CS
MGCF
SIP SIP ISUP
PSAP
AGCF
S_CSCF/ E CSCF
H248 TDM
UE
Analog access AGW
IP Backbone
Figure 22 - General Architecture for Emergency Call The new entities are the E-CSCF: Emergency-CSCF and the LRF: Location Retrieval Function It is assumed in this chapter that the LRF entity is provisioned with the subscriber Location Information (or zone area belonging to the AGCF) to be able to make a relationship between the subscriber end user and a given PSAP. The following figure shows an emergency call setup:
AGCF
1. Setup EC(112)
E-CSCF
LRF
MGCF
2. Invite(112@ec.com) 3. Routing Information Retrieval based on P-Asserted-Identity and 112@ec.com 4. Invite(R-URI: Police Tel URI)
5. IAM(CgPN=UE, CdPN=Police Tel num)
Figure 23 - Emergency call setu 56 Devoteam CONNECTING BUSINESS & TECHNOLOGY
1. A subscriber makes an emergency call by dialling the corresponding short number (e.g. 112) 2. The AGCF recognizes that the call type is an emergency one, then it routes the call to E-CSCF (which could be also a part of S-CSCF) 3. The E-CSCF requests to LRF a PSAP routing information based on the identity of the subscriber (e.g. PAsserted-Identity) and the request URI (e.g. 112@EC.com) then the LRF returns back a routable address towards emergency centre. 4. The E-CSCF routes the call towards the MGCF The MGCF, based on the received called party number in the Tel URI, routes the call towards the correct emergency centre (or PSAP).
6.6. Service enablers: the presence server use case

6.6.1. Background and concepts
Presence feature had been introduced with Instant Messaging functionalities as an internet feature. Proprietary implementations had been developed by Instant Messaging providers such as AOL, Microsoft, etc. The IETF SIP work group created the new SIMPLE work group to establish a presence service standard. A presence server: Provides Presentity (any uniquely identifiable entity that is capable of providing presence information) to the Presence Service; Allows watcher(s) to request presence information from the Presence Service; Allows sending Instant Messaging. As shown in the figure, the presence concept is very flexible. It is composed of presentities that publish presence information and of watchers that receive the information. The presentities can be real user but also computers that generate all kind of information such as weather, the traffic jam, the next trains at the nearest station, etc. In the same manner, the watcher can be a user that subscribed to the presence of someone or to the information published by a service, but can also be a service that uses a subscriber's presence information to execute actions on its status. Hopefully, the user can set rules to control the rights to access to the published presence information by configuring XML documents in the XCAP server. 57 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Presence Server
XCAP Server Pres-rules Pidf manipulatio n Resource Lists
Core
PUBLISH
NOTIFY
Presentity
Watcher
Figure 24 Presence server concepts

6.6.2. PIDF/RPID protocols
PIDF and RPID are XML documents that are carried in the body of PUBLISH and NOTIFY SIP messages. PIDF stands for Presence Information Data Format, and RPID stands for Rich Presence Extensions to the Presence Information Data Format. RPID is an addendum to the PIDF document to add some new information. The following tables show what kind of information PIDF and RPID can carry. Tag presence tuple status basic Meaning Presence information of a presentity Segmentation unit of the presence information can represent a device, a particular application Represent the status of a tuple, the status can be the reach ability, the location The basic status open or close. Its meaning depends on the type of information carried by the status tag contact note timestamp URL of the contact address that the presence information refers to Human readable note, can be provided in several languages Contains a timestamp of the tuple modification Contains Tuple, note, extension Status, contact, note, timestamp, extension Basic, extension
The previous table shows the PIDF information is quite limited, but it allows the availability of different kind of communication means can be described for each user's device. For instance, a user can be contacted by phone or SMS on his mobile, by phone, visiophone, Instant Messaging on his computer, but cant be contacted on his home fixed phone. Unfortunately, the tuple information is too generic for presentity to clearly group the information. A data model had been added to clarify what type of group can be done. At the same level of tuple, two new tags had been added: person and device. So the tuple represents a service such as Instant Messaging, telephony, etc The person represents the user (his availability, his mood, his location), and the device represents the terminals the user owns and where he can be contacted by which kind of media.

As mentioned, PIDF is extendable and RPID increases the information that is imbedded in the presence document as shown in the following table. Tag Activities Class deviceID Mood Place-is Place-type Privacy Meaning What a person is actually doing (e.g. Meeting, meal, travel, etc.) Groups similar persons, tuples or devices elements Represent the device that provide a particular service (tuple) Represents the mood of a person (sleepy, calm, hungry, etc.) Describes the property of the place the person is currently at (noisy, quiet, etc.) Describes the location type (airport, classroom, theatre, etc.) Indicates which types of communication third parties in the vicinity of the presentity are unlikely to be able to intercept accidentally or intentionally Relationship Service-class Sphere Status-icon Time-offset User-input Designates the type of relationship an alternate contact has with the presentity Designates the type of service offered (e.g. electronic, postal, etc.) Designates the current state and role that the person plays (home, work, etc.) URI pointing to an image representing the current status of the person or service describes the offset from UTC at the person's current location Records the user-input or usage state of the service or device, based on human user input, e.g., keyboard, pointing device, or voice. Note Note Note Note Note Note Contains Note, activity
6.6.3. XCAP protocol

XCAP is a protocol based on HTTP to synchronize a document. This protocol is used to upload and update lists and rules related to the presence on the XCAP server. Three main XML files are synchronized between the customer and the server: Pres-rules describe the rules to be followed by the server to allow published presence information to be forwarded to particular subscriber

Pidf manipulation represents the permanent information related to the presentity (since presence informations are published from several presence user agents and have a lifetime, there are cases where no presence information is available) Resource lists represent the list of contacts and services the user refers to in the other documents, for instance the list of his friends, the list of his family members, etc.
6.6.4. Example of service improvement with presence: call filtering

Description of a call filtering in the legacy network Typically, the filtering service is available on the legacy network. The user can define a while list and a black list to divert calls or not to an announcement. This service is mainly used to filter unwanted solicitation or malicious calls. The calls that hide the caller number can be filtered except if it is listed in the white list. In all cases, the numbers in the black list are diverted. Description of an enhanced call filtering with presence awareness The filtering service can be enhanced to take care about the presence information to prevent a call that will be lost or rejected. According to the presence of the subscriber and the identity of the caller the call can be presented or diverted to a voice mail box. For example if the subscriber is in meeting and he had declared that his friends cant contact him in this case, if a colleague try to call him the telephone will ring, but if a friend try to call him, he will be diverted to his voice mail. This service can be easily implemented in an application server. The service will act as a watcher for the presence information of the subscriber, and will verify when someone call in which list the caller belongs to by retrieving the customer contact list in the XCAP server.
Colleague Applications server Voice mail server
Friend
Presence server
Subscriber in meeting
Figure 25 Enhanced call filtering with presence awareness
6.6.5. Migration for legacy user to the IMS service

This terminating service can be offered to IMS customer since the incoming calls can be intercepted by the IMS applications server. Legacy users can also subscribe to such service if we add a IN-SCF that emulate an SCP and can transfer the call control to an IMS application server. This solution can be used as long as the legacy customer is not migrated to the PES subsystem.
AS
Presence server
IN-SCF
caller
switch
Legacy user
Figure 26 Legacy user migration to IMS presence service
6.6.6. References
RFC 2778: A Model for Presence and Instant Messaging RFC 3863: Presence Information Data Format (PIDF) RFC 4479: A Data Model for Presence RFC 4480: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) RFC 4825: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) RFC 4826: Extensible Markup Language (XML) Formats for Representing Resource Lists RFC 4827: An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents RFC 5025: Presence Authorization Rules
7. Fixed-Mobile Convergence and access migrations

7.1. Overview of Fixed-Mobile Convergence technologies
CTP (Cordless Telephony Profile) comes from Bluetooth technology and is one of its profiles. CTP allows a mobile terminal to be connected to a Bluetooth access point connected to the external telephone line indoor, and act as a mobile terminal outdoor. This technology seduced some operators eager to launch a quick offer, as it requires no network evolution, but is relatively old and not in the roadmaps anymore. Today's main alternatives are UMA and IMS. UMA (initially Unlicensed Mobile Access, now Universal Mobile Access), was a standard developed by an independent consortium established end 2003, and is now integrated in 3GPP Release 6 where it follows the standard's evolutions (under the name of GAN or Generic Access Network). For example, UMA integrates 3G since beginning of 2008. UMA provides an access to VoIP and other services through independent networks from a GSM/WIFI bi-mode terminal. The UMA is designed to provide seamless and transparent coverage to the user of IP services, including voice, whether in mobile or WIFI coverage (home area, hot spot). The UMA architecture is based on the UNC (UMA Network Controller), which plays the role of a BSC in the mobile network, while being attached to the WIFI access points by an IP broadband network. When placing a call near one of these bases, the UMA client on the mobile encapsulates all signals (voice, data) on the IP link. The UNC then delivers data for the core mobile network as a classical communication, while informing the network of the location of the customer, enabling handover management.
Figure 27 Universal Mobile Access architecture Another option is based on IMS architecture. The IMS is the solution adopted by the convergence forum 3GPP and TISPAN. By unifying the procedures for establishing sessions, it allows the use of the network by the full range of access modes (xDSL, mobile, fiber, cable, etc...). The IMS replaces the concept of circuit-switched call with the concept of multimedia session between users allowed by SIP. Each access, integrating SIP, can be part of a multimedia session with voice, data or video, and the notion of handover becomes almost natural. It is carried out by IMS service VCC (Voice Call Continuity), which allows switching between a network circuit GSM / UMTS and the IMS and whose arrival is planned for 2009/2010. Unlike UMA, which is driven by mobile operators, IMS may tempt of fixed networks operators willing to invest at long term in these all-IP networks where the very notion of switching has disappeared. Above all, unifying the network for all types of access, IMS technology is the golden path for integrated operators who will find a natural solution convergence for all types of imaginable media flows, while UMA is focused on voice. Finally, femtocell technology recently appeared, based on the principle of a mini base station radio with a very low capacity (a few simultaneous calls) present at the customer's premises, and connected to the mobile network via the Internet. One of its strengths is that it does not require adapted terminal, and manages itself switching between mobile network and IP access. It presents a very interesting alternative in terms of quality because it is based on frequency ranges optimized 65 Devoteam CONNECTING BUSINESS & TECHNOLOGY
for voice; particularly with respect to WIFI whose ability to restitute voice seamlessly requires a rigorous development, and even more with respect to Bluetooth. Presented in the form of an adapter or included in a box, the femtocell is a proprietary solution that strengthens customer "locking" while avoiding some of WIFI's drawbacks (autonomy, cannibalization of access points). If this is a way forward, it could happen later on the market, its marketing being affected by cost and technological development (management of radio interference) issues. Note that Devoteam Italy has developed an integrated convergent solution called OnePhone, which offers high value-added services and features, including GSM/UMTS WiFi handover, video calls, IPBX mobile extension. The main OnePhone features are presented in the figure below, and more information is available from Devoteam.
Voip Provider
Asterisk VoIP Server
OnePhone
OnePhone OnePhone OnePhone
Figure 28 Devoteam OnePhone FMC solution
7.2. A FMC experience: BT Fusion

BT has no mobile presence, having sold off BT Cellnet (now known as O2) back in 2001 in an effort to pay off debts. As a consequence, BT had to rely on broadband and IT services in recent years to drive growth, amid declining voice revenues. The UK carrier launched its converged fixed/mobile phone service, BT Fusion back in June 2005. In 2007 TMobile USA launched a similar converged service, joining France Telecom's Unik service. In essence, the Fusion handset uses Bluetooth to connect to a base station within the house to switch calls over a BT broadband link (VoIP over broadband). Once outside the house, the Fusion handset operates as a mobile phone, piggy backing on Vodafone's mobile network or BT's WIFI hotspots. But barely two-and-a-half years after its launch, BT stopped marketing Fusion even if it continues to market Fusion to small businesses and corporate customers. Nowadays, mobile operators are considering indoor 3G base stations, known as femtocells. BT has sold only 45,000 Fusion phones since its launch back in 2005 to the consumer market, a far cry from the millions of customers it was hoping for when it was launched. Several reasons may explain why it failed. It was too complex for consumers; it was only available to BT broadband users; only three phones could be used, and only one at launch; for the most part sales had no retail presence since the sell off of mobile stores to O2; an old-fashioned fixed-line company is not the obvious first stop for a wireless phone; and the logic of a system that required incoming calls to go through a mobile network was questionable. This "historical" use case shows telecommunications remain a mass market and must be understood as such: even if a technical solution makes sense for an operator, it may be less easy to apprehend by the customer, especially when the operator is not positioned as a global operator and does not have a direct market channel to the end-user.
7.3. Access migration procedures

Migration procedures are generally highly dependant on the element functionality, network architecture, vendor-specific and product-specific operational processes. This section attempts to describe a real-life migration through two examples: An access migration seen from a network operator / equipment vendor An access migration as presented by the network operator to the end user (the consumer) The following figure shows the overall scheme of a typical migration project, which is discussed through this section. It deals with an access migration from a circuit-switched architecture (based on Remote Switching Units or RSU) to IP67 Devoteam CONNECTING BUSINESS & TECHNOLOGY
based architecture based on MSAN (Multi-purpose Service Access Node), as depicted in the figure below. A soft switch allows connecting the PSTN and the VoIP network.
Soft Switch
Figure 29 - Access migration concept A migration project includes 3 phases: preparation, migration and post migration. Critical success factors for the migration project include cost efficiency, respected deadlines, and minimum service interruption for customers, connected operators and Internet service providers. These conditions can be met with the combination of the following: a proven migration strategy, overall coordination of all actors, proven migration procedures with minimum service interruption, automatic tools for managing the conversion process, experienced project management for coordinating the entire process, including all participating suppliers and subcontractors, agreed communication strategy, availability of qualified staff. The migration strategy includes the high-level architecture of the migration project, the implementation planning, migration procedures, migration steps, involvement of partners and coordination with competitors. The migration methodology can be structured into the phases outlined in the figure below.
Figure 30 - Example of migration methodology phases
7.3.1. Architecture & Design

Agreements must be reached between operator and supplier in order to: Provide common clarification of technical requirements and procedures Provide clarification of migration processes, their interactions and coordination Define the target architecture Define the coordination responsibility for the entire project Define services and support services required of participating partners The following points must be clarified in detail: Customer deactivation / activation Fallback scenarios 69 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Disabling of PSTN systems Workflow processes for everyday activities Error management Quality assurance (e.g. definition of Quality Gates, KPIs, etc.) Agreement of project organization Coordination of tools for monitoring and supporting the migration process Definition of a migration plan taking account of the following criteria: Time-optimized processes for ensuring minimum disruption to service Stability of the network in every interim state of migration Definition of migration areas Coordination with standard processes, such as maintenance, updates, error management, etc. The result of this series of workshops is a complete description of the migration concept, including the relevant work packages, which will allow work instructions to be produced for trained employees.
7.3.2. Migration Preparation

The migration preparation phase provides a blueprint of the complete migration, including: Site survey with drawing showing where modifications occur Detailing and review of the project plan Staff call-out planning & training Introduction of operating processes during implementation and following migration Adaptation of migration procedures and tools Detailed network planning and monitoring 70 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Logistical agreements Migration error management according to existing procedures
7.3.3. Lab Verification of Migration Strategy

Following conclusion of the preparatory phase, a series of checks and tests should be performed on reference systems. The entire migration procedure will be released for pilot use as a result. The following activities and tests should be performed: Testing of data conversion and migration tools Testing of fallback solution Performance tests (estimation of duration of specific parts of the migration; temporary media gateways, etc. required; used to verify the schedule planning) Training of staff for performance of migration on test systems Optimization of processes and procedures based on test results
7.3.4. Pilot site migration

A pilot phase may start in an initial region before the comprehensive rollout, This phase allows field verification of: New operational processes Individual migration processes and procedures Response of the new solution in a real environment under real traffic conditions By the end of this phase, the solution, operational processes and migration equipment will provide evidence for the field rollout (Ready for Rollout). The project organization for the comprehensive rollout will be set up during the pilot phase and all project plans will be updated.
Pilot Preparation in the existing PSTN Preparatory measures are required in the operational network prior to migration in the first pilot region: Extension of the trunk capacity at transit exchanges for IP Network integration. Traffic measurements and creation of detailed traffic matrixes. Updating and verification of the network documentation. First pilot region (friendly user) The entire migration process is performed in the operational network with a limited number of selected friendly users from the operator with live traffic. The migration is performed in the following steps: Downloading of subscriber-related data from the PSTN or inventory data systems and conversion Preparation of management systems (OSS, Element Management Systems) and the corresponding subscribers / network documentation. Switchover to MDF (Main Distribution Frame) Disabling of the old port, enabling of the new port. Synchronization of management systems (OSS, Element Management Systems). Updating of subscribers / network documentation or data in the BSS system. Verification of migration. Following successful migration of friendly users, the migration is performed in a small area with live traffic. Any possible effects of migration errors can be reduced to a minimum in this way.
7.3.5. Migration procedure (D Day)

Wiring migration consists in blocking up the origin connecting blocks (RSU), and unblocking up the new ones (MSAN). Update routing in parallel with the wiring migration involves the operator, in order to perform: Software cancellation of the subscribers belonging to the migrated RSU Software activation of the subscribers in the Soft switch 72 Devoteam CONNECTING BUSINESS & TECHNOLOGY
7.3.6. Post migration

This task involves: Information Systems update Removal and recycling of existing equipment (cabling, RSU migrated Status monitoring of the migrated equipment must be available in real time (with diagnostic analysis tools and predefined actions upon each problem encountered).
8. Messaging, transport and service access migrations

8.1. Messaging evolutions
The messaging evolution in NGN/IMS context will have different aspects to cover. The known messaging user experience must be kept in the IMS domain and the migrated service must remain interoperable with non-migrated users (see Legacy messaging Interworking section below). On top, new messaging services will be introduced like group chat. These services are only possible in the IMS domain. These services are not subject to a migration since they do not exist in the non-IP domain. For IMPS based messaging services (IP based but not in IMS domain) interworking can be realized. Different interworking solutions can be worked out, although this no longer specified in the OMA standardization. The migration must keep from the end user the known service experience in focus and the link with the community should not be broken.
8.1.1. Sending messages

If a user migrates to become an NGN/IMS user all of his contacts have to remain reachable via the existing addressing format. The end user will expect that he can continue to do basic text messaging by selecting contacts from his address book. The non migrated contacts are still presented via an E164 based number. The network must be able to realize the messaging service with these number formats. Therefore, TEL URI support is essential for messaging service continuity. One issue which must be considered in the detail is how far TEL URIs in local number format (not E.164 international format +CC) are allowed.
8.1.2. Receiving messages

Within the network, the necessary functionality is required to capture incoming messages so that they can be delivered via the IMS network over an IP-bearer. From a migration perspective, the registration of the user in the IMS has to trigger the activation of this functionality which will route receiving messaging towards the IMS network. This will allow a smooth change without noticeable differences to the end user for receiving messages from the non migrated contacts. Messages from contacts that are already migrated will remain in the IMS domain.
8.1.3. Legacy mobile messaging interworking (SMS & MMS)

3GPP specifies how messages from the SMS can be delivered to an IMS based client. This is meant as the final path for the delivery, meaning that the most of the SMS infrastructure like SMSCs stays in place and that, based on network configuration, it is decided to deliver the message by means of the IMS. Two specifications exist: 3GPP TS 23.204 standardizing SMS over IP in 3GPP Release 7 3GPP TS 23.811: standardizing SMS interworking with OMA SIMPLE IM in 3GPP Release 8 In both cases, the SMS is delivered by means of a SIP MESSAGE request. The main difference is in the content conveyed in this request: when SMS over IP (3GPP TS 23.204) is used, the message is simply a wrapper around the SMS, meaning the client should still be SMS aware and SIP is mainly used as a transport mechanism. 3GPP TS 23.811, on the other hand, provides a real interworking: the SMS is converted to an OMA SIMPLE IM message in the network. This means that the client side can entirely rely on protocols and content that is rooted in an IP environment rather than to be aware of the legacy messaging standards. The disadvantage of this interworking is that special SMS features and usages like flash messages, delivery of settings, delivery reports etc. might be broken. The difference in approach by these specifications is caused by their origin. The SMS over IP specification was intended for mobile devices roaming into WLAN environments. The interworking specification was initiated by OMA with the intention to provide SMS connectivity to OMA SIMPLE IM clients. From that point of view it is clear to see why the assumption of SMS capabilities on the client was a valid one in the environment SMS over IP was intended for. On a technical level the SIMPLE IM interworking specification makes use of parts of the SMS over IP specification. For each user they are mutually exclusive though: it must be fixed in the network for each user whether to deliver the message as SMS over IP or as OMA SIMPLE IM message. More advanced use cases like delivering the message both as SMS and as IM can be achieved as well. For those there are some technical difficulties however which require proprietary solutions. These difficulties include the handling of the delivery report, delivery of subsequent messages if a client is not online, etc. For MMS evolution to an IMS environment, no specifications are available yet. Proprietary solutions providing interworking to for instance OMA SIMPLE IM large message mode might be a possible solution for MMS interworking, but that needs to be investigated on a case by case basis. For interworking to IMPS, a track was started within OMA CPM (see further). Due to lack of interest though, this was 75 Devoteam CONNECTING BUSINESS & TECHNOLOGY
stopped. This means that no standardization is available providing interworking between IMPS and IMS based messaging services. In a proprietary way solutions are possible. Depending on the level of interworking required this may not be straightforward as the IMPS world makes use of different presence documents, subscription models and group models compared to the instant messaging services that are commonly proposed for IMS environments.
8.1.4. Specific SIP based messaging

Several mechanisms exist for messaging on the IMS. Please note though that in most cases those should be considered as instant messaging, because most clients augment these messaging functions with presence on the client. IETF based The IETF has standardized the SIP MESSAGE request in RfC 3428. This has traditionally been used by IMS client instant messaging implementations. However since that specification only specifies the transport, there could still be interworking problems between clients implementing it since for instance they could treat binary content in a different way. The IETF has also standardized the MSRP (Message Session Relay Protocol) in RfC4975 which allows to offload the actual content transfer from the signaling infrastructure (in this case the IMS). This mechanism makes use of session control mechanisms on the signaling layer for the setup of a direct TCP connection between the parties that are about to exchange messages. The protocol used over this connection to ensure encapsulation of the messages and delivery confirmations is MSRP. Given the evolutions within OMA around messaging, it is more likely that messaging on the IMS will make use of OMA SIMPLE IM implementations rather than using plain IETF MSRP based implementations (this could also be true for fixed environments). The OMA specifications try to take every messaging-related aspect into account rather than leaving it up to the implementations to assemble their own set of supported specifications that is not guaranteed to be compatible with the set selected by another implementation. As a side note, MSRP is not only used for plain messaging. For instance the GSMAs IR.79 specifying how to do image sharing during a voice call also makes use of MSRP. OMA based OMA is working on two messaging specifications that can be IMS based. One is SIMPLE IM that was already mentioned, the other one is CPM (Converged IP Messaging) that is much wider in its scope and will replace the functionality that was offered by SIMPLE IM when it is released. Next to the IM functionality, it also tries to include aspects like interworking with legacy messaging (SMS, MMS and SIMPLE IM for instance), the address book, synchronization, etc. Even though standardization of CPM has been ongoing for quite some time already, it should still be considered as being 76 Devoteam CONNECTING BUSINESS & TECHNOLOGY
in the early stages of standardization which is due to its very broad scope. For some functions it doesnt go yet beyond the requirements and for now, none the exact details of the signaling have been fixed yet. So CPM based products can not be expected in the near future. SIMPLE IM, on the other hand, has reached a stable status already. Even though it is not final yet, the effort spend on it mostly consists of bug fixes and some compatibility improvements. A reduced set of the functionality offered by SIMPLE IM forms the basis of the messaging component of the RCS initiative. SIMPLE IM defines several different messaging modes: Pager mode messaging Large message mode messaging One-to-one session mode Group session mode File transfer For the first two, there is no concept of a conversation in the network. This can be called One-shot messaging. Those messages can be sent to one other user, to a list of users that is sent along or stored in the network or to an active group. The difference between both of them is that pager mode is used for small messages and when the message is larger than 1300 bytes large message mode should be used based on MSRP. Next to the One-shot messaging there are the two session modes. For those, there exists the concept of a conversation in the network since a session is setup at the start of the conversation and this session is torn down when the conversation is over. These sessions rely on MSRP for the actual transfer of the messages. The difference between both modes is that for one-to-one conversations, no dispatching functionality needs to be included in the flow that allows distributing the sent messages to multiple recipients. Simply relaying the messages to the other party can be sufficient. In group conversations however such functionality is necessary. Hence it is always included. Two types of groups are supported: ad-hoc group in which the list of participants is provided by the client to the network and pre-defined groups where the group definition is stored in advance in the network and can be reused several times. For group sessions there are also possibilities to add additional participants, to leave a session and rejoin afterwards, to throw someone out of an ongoing conversation and to send private messages to one of the other participants. Next to those modes there is also a separate file transfer mode that allows sending files to one or many other users. OMA SIMPLE IM also specifies how to do delivery reports and provides functionality for storing conversation histories and messages that are sent to a recipient that is offline. Those can be delivered then using both push and pull-mechanism.
8.2. Signalling transport

Transport replacement (such as from TDM to SIGTRAN) usually makes signalling interworking necessary, as the transport for signalling may also need to be changed, in which case a Signalling Gateway (SGW) is used
SIP on IP
S-CS CF
MG CF
Legacy signalling on IP
MGW GGSN
IP Stream
Transcoding
TDM Stream
IP Stream
SGW
Legacy signalling on SS7
GSM/UMTS CS Network
PSTN PLMN
Internet In ternet IP networks n etw orks
Figure 31 - SGW usage
The first baby step in a migration is usually the replacement of the TDM transport network by an IP based packet network. This is done mostly out of a cost saving motivation of existing functionality, rather than the enabling of new application technology. Nevertheless, it can still be seen as an important migration stepping stone as it enables the early use of the foundations of the new network. In this transport replacement step, the actual network, call control and application signalling messages (Green and orange blocks in Figure 32 : SS7 ISUP, BICC, INAP (TCAP), MAP (TCAP),.. ) remain unchanged from end to end and therefore dont impact call control or application logic. Its only the lower level TDM transport protocols (MTP L1 and L2) which are replaced by an SCTP / IP stack. This makes this first migration step a relatively smooth, non intrusive one.
TCAP (INAP, CAP, MAP, ) MTP User (SCCP, ISUP, ...) MTP-3
(Q.704) SUA
(RFC 3868)
MTP-3b (Q.2210)
MTP-3
(Q.704)
(RFC 4666)
M3UA
SCTP
(RFC 4960
MTP-2
(Q.703)
(Q.703 Annex A)
MTP-2
SAAL (Q.2140, Q.2110)
(RFC 4165)
M2PA
(RFC 4960)
SCTP
MTP-1
(Q.702)
AAL5 (I.363.5) ATM (I.361) STM1 G.804 HSL
(RFC 4960)
SCTP
IP (RFC 791)
(RFC 1483)
(G.704, G.703) Narrowband (TDM)
E1/DS1
(G.707 .. G.709) (G.703)
E1/DS1 (G.704, G.703)
IEEE 802.3 (SS7 over IP)
Ethernet
(ITU-T)
HSL
Broadband
(ATM)
(GR-2878-CORE)
SIGTRAN
Figure 32 - SS7 / SIGTRAN Protocol Family
Of course most legacy nodes are not SIGTRAN enabled, i.e. dont have a means to communicate over SCTP / IP network. This is where the Signaling Gateway (SGW) comes in, which is situated between TDM legacy nodes and SIGTRAN enabled Legacy nodes or IMS / NGN call control functions (e.g. MGCF, MSC-S). The SGW terminates the lower level TDM protocols on one side and the SIGTRAN protocols (M3UA, SUA, M2PA, over SCTP/IP) on the other side, while performing an interworking function transparent to the end nodes. This is illustrated below (Figure 33) as one can see that the SGW function performs a transport translation function between the MGCF and legacy PSTN switches.
M2PA
SGW M3UA M2UA

SS7
MGC
BICC M2PA
MGC M3UA
SGW
M2UA MGCP SS7 MGW Trunks TEX LE
LE
TEX
Trunks
MGW
MGCP IP Data Stream
PSTN
PSTN
IP Network
Figure 33 - SIGTRAN protocol usage in Voip environment 79 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Due to the lower level interworking and routing functionality, SGWs are usually implemented as extensions on existing SS7 Signaling Transfer Point (STP) nodes. STP nodes are centrally placed in the signaling network and perform a hub functionality facilitating the interconnection of the signaling end points. This centralized position, through which all core signalling passes, makes it an ideal place to implement other migration facilitating functionality since it minimizes the number of nodes impacted, as opposed to adapting the much more abundantly present signaling end points. This is why many vendors have evolved their Signaling Gateway functions to a higher level application layer gateway, which enables NGN service access from legacy networks and visa versa. Among others the following come into mind legacy services accessible from NGN such as Number Portability and NGN service accessible from Legacy networks. Please refer to paragraphs 8.3, 8.4 for an illustration.
8.3. Access to Legacy services from NGN network

Telecom operators are forced to transform their legacy Core Signaling Networks into an access-agnostic, converged, IP based network generically called the Next Generation (telecommunications) Network. Sure enough, in the short run, the main incentive of this push is to decrease operational and investment costs due to consolidation of existing signaling gear and a cheaper common transport network. In the long run however it will enable the expansion of the feature set and will enrich the telecommunication experience. The first step has been taken by most operators as we speak, by transforming their signaling transport infrastructure from TDM / ATM into an IP-based SIGTRAN network. This transformation is the easy compared to what has to come, i.e. transforming the application layer and therefore complete end to end signaling. The operators can not do this overnight and will have to take a stepwise migration approach implying that both legacy and NGN world will have to coexist side by side , interact with each other , and both be managed simultaneously. However, this being said there is still a long road to travel. A transitional step by step migration approach will be taken in which the legacy and next generation networks will live peacefully and cooperatively for another ten years to come. During this time, an operator will want to deliver not only the IMS to service its new trendy IMS users but also increase the service and revenue of its existing legacy users. For this reason one will need access somehow from the legacy network to the IMS services. The other way around after investing loads of money into traditional equipment as SCPs which still work fine and are used intensively the operator will want to leverage this as it is still a strong an strategic advantage and prolong the return on investment of these legacy products. For this access from the IMS to the traditional equipment will be necessary. One more major concern will be to manage both networks simultaneously. For instance the routing databases both in the legacy and new networks will contain information about the same subscriber, and it can quickly turn into a nightmare to keep this data consistent with each other. 80 Devoteam CONNECTING BUSINESS & TECHNOLOGY
This chapter and the next gives examples of some real life situations, illustrating the transient hybrid situation during the Legacy to IMS network migration.
8.3.1. Optimized routing with non migrated MNP database

This section describes the transient hybrid situation in which an operator already has new IMS/NGN subscribers, but not all of the core network equipment, since in our example the Mobile Number Portability (MNP) database is not migrated yet. When a call is setup from an IP phone in a next generation network to a PSTN/ISDN subscriber which has ported to another network then the call will still be switched via the donor network (= range holder network in this case). The donor network will therefore operate as a transit network and will for this reason demand interconnection fees. This situation is depicted in Figure 34 below.
!
)$ / 0 " &'()*(+', +($ / 0 " &'()*(+',++$ / 0 " &'()*(+', +8$ / 0 " &'()*(+',+-
"
SS7 NP
)-$ . " % &'()*(+', +))$ " % &'( ()*(+',+-
1 2 "
*$ " '$ "5 6 6 )8*7 % 67 95 1 5 "
Service Switching Point
1 :)"
3 4
; 3#(-<+-; --
#$ " % &'()*(+',+-
)($ " % &'( ()*(+', +-
. 4
.
Figure 34 IMS PSTN interworking without early NP access
A solution would be to find out if the subscriber is ported before switching the call via the Range Holder network. This requires that the NP database must be accessible from the S-CSCF and must fit in the standardized session initiation signaling flows. This is possible if we treat it as an Application Server to which the SIP Invites are forwarded, in which case the S-CSCF handles as a SIP proxy server. The forwarding should be done for all SIP invites which fulfill certain filter criteria administrated per user in the HSS . This can be for instance all invites which have a destination addressed via a Tel: URL. Please note that if the destination was a SIP phone addressed via a TEL URL, than the preceding ENUM query would have translated the TEL:URL to a SIP URL so no NP query is necessary. The following figure depicts the proposed solution.
1
SS7 NP
SS7 NP
Figure 35 - IMS
PSTN interworking with early NP access via originating S-CSCF trigger point
The same optimized routing can be achieved via an alternative mechanism, in which the S-CSCF function does not need to be loaded with an additional SIP query. By making the legacy number portability accessible via ENUM than the 1 These filter criteria which are stored in the HSS are transferred to S-CSCF during the registration process of the user initiating the call/session (not shown in the diagrams). If multiple Application Servers can be queried than the order is followed 82 Devoteam CONNECTING BUSINESS & TECHNOLOGY
portability status of the called party can be determined beforehand. The blue dialogue shown in Figure 35 will then in detail look like in Figure 36.
S-CSCF
IW
SS7 NP Db
TCAP: Begin , OTID = 100 IDP: CDPN = +3214253850
I-CSCF Mobistar
DNS Querie Name: 0.5.8.3.5.2.4.1.2.3.e164.arpa Type: NAPTR (Naming authority pointer) Class: IN (0x0001) DNS Answers Name: 6.5.4.3.2.1.4.1.2.3.e164.arpa Type: NAPTR (Naming authority pointer) Class: IN (0x0001) Time to live: 0 Data : 10 100 "u" "E2U+sip:sip""!^.*$!sip:+32C214253850@mobistar.be!"
TCAP: END , DTID = 100 IDP: CDPN = +32C214253850
INVITE <sip:+32AB14253850@mobistar.be> Contact:<sip:bert@bertpc.proximus.be> From: Bert<sip:+3214654321@proximus.be> To: Ernie <sip:+3214253850@proximus.be> Call -ID:9001@bertpc.proximus.be
Figure 36 - IMS
PSTN interworking with early NP access via ENUM (DNS)
8.3.2. Further applications of the SIP <-> INAP interworking

The interworking logic illustrated in the previous chapters should easily be adaptable for enabling other traditional SS7 nodes from an IMS environment. Once the previous investment has been made by an operator to enable the NP server in a IMS network, then it will be relatively easy to use this technology for other number translation services. The following figure illustrates for example how the 0800 service implemented on a legacy SCP can be accessed from IMS.
2!
8$ . % -,--)('*+8
5 5
. 4
/ ; 5
SCP
$ % )*(+',+-
+$ / 0 " &-,--)('*+8
SS7 NP
,$ / 0 " &)*(+',+)$ / 0 " &-,--)('*+ ($ / 0 " &-,--)('*+ #$ / 0 " &)*(+',+-
1 2 "
*$ '$ "5 6 6 )8*7 % 67 95 )-$ / 0 " &)*(+',+))$ " % )*(+',+-
1
3 4
Figure 37 - Legacy 0800 service accessed from IMS
8.4. Access to NGN services from legacy network
8.4.1. Optimized routing with migrated NP database

The previous paragraph depicted the transient situation, in which the NP database of the operator has not been migrated yet and is still implemented as an SS7 IN SCP, while new IMS subscribers need to access this data. Of course we can also have the situation in which the inverse is true i.e., the number portability data has been
migrated to an IMS node2 while the legacy subscribers need access to it. If there is one ideal candidate for storing the portability information in IMS than this would be the ENUM database. This database, traditionally used for e164 to end-user URI translation, is now widely being accepted as the central number translation database for IMS. It will be accessed in each call to destinations addressed by e164 number3 and is therefore ideally placed to implement the Number Portability in IMS. The following figure illustrates the non optimal call flow when the ENUM database is accessed late in the call setup from the IMS network.
@ 5 " 0
)$ " % &'()*(+',+Service Switching Point
!
($ " % &'()*(+',++$ % 7 "
"
/ A = 7=
1 :)"
"
'$ 95 -7+7,7'7+7(7*7)7(7'7 )8*7 %
SS7 NP
; 3#(-<+-; --
*$ 7 "
7=
3 4
.
5= "
4
>? % /
. $
Figure 38 - PSTN
IMS interworking without early ENUM access
Analogue as in the previous chapter 8.3.1, but now in the direction from PSTN to IMS it pays to access this database as soon as possible in the call setup path to optimize the call. This implies that the ENUM database is
2 The situation in which data is present in two databases simultaneously should be avoided to avoid synchronization nightmares. 3 This does not have to be Tel URI, but can also be a SIP URI carrying a e164 number e.g. sip::3214253850@siemens.be Devoteam CONNECTING BUSINESS & TECHNOLOGY
85
accessed from the legacy IN network. An interworking unit must be placed in between to perform the interworking from INAP/MAP to ENUM and back. This interworking logic is preferably implemented on a NP server to make the fact that the NP database has been migrated as transparent as possible. From the legacy network point of view it still looks like a traditional INAP SCP is handling the NP query, and therefore does not impact other legacy nodes. The following figure illustrates how this could take place, and how the call setup is optimized as a result.
@ 5 " 0
)$ " % &'()*(+',+Service Switching Point
"
8$ " % & )'()*(+',+-
$
2 "
/ " A
3 4
($ .
" % C&'()*(+,'++$ ? !5 > = % @ 7= $ % ! > )$ %

SS7 NP
% > C& )'()*(+,'+-
=
95 $
7=
5= 95
; 3#(-<+-/
'$ B5 -7+7,7'7+7(7*7)7(7'7 )8*7 %
3 4
.
1 :)"
5= "
4
*$ 7 "
7=
>? % /
. $
Figure 39 - PSTN
IMS interworking with early ENUM access
8.4.2. Access to Diameter based NGN online charging system

In traditional SS7 networks, online charging (e.g. for prepaid SMS) was usually implemented on a CAMEL SCP, which is interrogated for a credit check prior to setting up a call or sending an SMS. This interrogation is initiated from the attached VMSC, or in many cases on the fly from a central STP through which the initial signaling messages are routed. 86 Devoteam CONNECTING BUSINESS & TECHNOLOGY
In IMS or other NGN architectures, a DIAMETER based Credit Control Server will take over the responsibility of the CAMEL SCP. Many operators are therefore already investing in these Next Generation CC Servers while still operating a traditional SS7 Mobile network. These operators of course want to see a quick return on investment and use this DIAMETER from inside their SS7 network. To achieve this, with a minimal (preferably none) of impact to existing SS7 nodes , a central interworking unit must be introduced, transparently translating the CAMEL requests to Diameter Requests, and visa versa translating the Diameter Answers to CAMEL responses. The following figure illustrates the use case of an online credit check for a prepaid subscriber sending an SMS.
VMSC A sub
Interworking unit (charging gateway)

MAP : MO_Forward_SM
(inter-) national PLMN

1 Diameter CC server 2
SMS Chargi ng (NP) SRF MATF
CAMEL
Diameter : CCR
HPLMN
VMSC
HLR
B sub
MAP : MO_Forward_SM
SMSC
Figure 40 - Camel
Diameter IW for online charging
9. An operator migration use case: BT21C' network transformation s

The present section described a prominent use case in the industry: the complete transformation of BT' network into an s NGN-based network. The description is based on public information available from BT Web site.
9.1. BT21C network goals

21CN is BTs global, software driven customer network that introduces a new, simpler portfolio of next generation services. It is the foundation for BTs transformation into a global, software-driven communications business. It is an advanced broadband network based on intelligent systems, Internet Protocol (IP), Session Initiation Protocol (SIP) and MultiProtocol Label Switching (MPLS). IP is key to 21CN because it has the potential to act as a common transport protocol for all types of communication and applications. SIP allows the service provider to control the communications activity to meet a customers requirements, and MPLS enables the efficient designation and routing of IP traffic flows.
9.2. BT21C network evolution in UK

Today, BTs UK network comprises some 16 discrete but related network platforms, each designed to support a service and reflecting numerous technology waves. As new technologies and product opportunities emerged, it was usually more straightforward to deploy a new platform or overlay. It comprises tens of thousands of network elements, including switches, routers, concentrators, and transmission terminals. Maintaining this type of network, with the associated services, support and training it requires, is expensive and a significant part of BTs operating costs. As an end-to-end Internet Protocol (IP)-based network, 21CN will consolidate BTs 17 separate network platforms into one. It will replace the complex network and systems infrastructure with a physically simpler and more reliable network.
Figure 41 - BT' UK network before 21CN s In the UK, 21CN transformation involves huge investment, logistical and regulatory challenges to replace the equipment infrastructure in telephone exchanges across the country.
9.3. BT21C architecture
21CN counts five strategic domains, namely: Access domain - the edge of 21CN linking to BT' existing access network. Multi-service access nodes s (MSANs) aggregate the voice, data and video services from end users on to the 21CN core IP-based network. They replace service-specific equipments of the legacy network - for example System X and AXE10 concentrators for PSTN and ISDN and DSLAMs for broadband. Approximately 5,500 BT sites in the UK will house copper and fiber MSANs Metro node - provides the IP routing, Ethernet switching, SDH switching and gateways to existing networks for the unified 21CN network for voice, data and video. There will be approximately 100 metro nodes in the UK including Provider edge IP routers; Ethernet switches; media servers; trunk media gateways and session border controllers. Core node - the high capacity, large scale routers providing cost efficient connectivity between metro nodes. There will be approximately 20 core nodes in the UK with MPLS routers. I-Node - this is where the service execution functionality is located that controls services. It includes soft switches, network intelligence and bandwidth management capabilities. There will be approximately 10 i-Nodes in the UK for the control of voice services which includes call servers; application servers and signalling gateways. 89 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Transmission - this includes the optical fibre transport infrastructure that connects all nodes in 21CN but also the electronics that convert the signals carried at high capacity over the cables connecting the MSANs, metro and core nodes. Much of the optical fibre infrastructure is already in place with WDM and high bit-rate SDH cross connects. The following figures show simplified domain architecture and the protocols used between the domains.
Figure 42 - BT' 21CN domains s
Figure 43 - BT' 21CN protocols used between domains s 90 Devoteam CONNECTING BUSINESS & TECHNOLOGY
Notice that media and signalling flows do not traverse the same equipments in the NGN architecture.
9.4. Network migration strategy
BT believes it is the only operator in the world to commit to a planned national rollout of a next generation network including customers in remote parts of the country. In the UK, BT prioritizes the delivery of new services, such as Ethernet and next generation broadband, ahead of migrating existing services. This ensures that the new services become available as quickly as possible. After windows for voluntary migration on an exchange by exchange basis, a period of planned migration will follow allowing BTs legacy networks to be switched off.
9.5. Customer Premises Equipment compatibility testing strategy

BT has first completed testing on a representative sample of the following types of equipment with positive results: corded telephones, cordless telephones, answering machines and separate caller display devices fax machines Sky set top boxes analogue PBXs (one proved not to be compatible) Game consoles that provide an online gaming facility, via either a wireless or an Ethernet connection, do not require compatibility testing as they do not contain an ADSL modem. BT then focused on the following equipment types: Broadband modems Telemetry devices ,Security and fire alarms Tele-care and Tele-health equipment Point of sale and cash point machines The next customer apparatus testing focus will include various kinds of ISDN equipment.
10. IMS simulation and test tools developed by Devoteam

This section briefly presents and compares two of the main test tools developed within Devoteam for testing NGN/IMS networks. IMSLoader has been elaborated in Lannion (Brittany), and SITT was designed in Norway.
10.1.
IMSLoader
Before migrating real subscribers to NGN/IMS infrastructure or activating a new service/ configuration in the new network, it is primordial to be able to verify evolutions are well working since NGN/IMS/TISPAN infrastructures are less reliable than the classic PSTN network. The Devoteam IMSLoader allows detecting and suppressing any robustness problem of the infrastructure: the earlier these errors are detected, the less important the impact on the service is, guaranteeing a better acceptance of new services by the general public. Devoteam has developed the IMSLoader J2SE Application that allows to: Simulate several protocols such as SIP, RTP, Diameter, SOAP, TCP/UDP, SCTP... Be used as a test tool or an interface simulator (test of interface protocol, functional tests, automatization of non regression and load tests...), Simulate all the IMS Core Network nodes, IMS UAs or IMS AS. IMSLoader is a very flexible solution since scenarios are based on XML scripts and so is easy to adapt to specific customer needs. It offers basic scenario functions (Pause, Semaphore, Goto, If/Then/Else, Do/While, ..) and more complex possibilities based on protocol stacks capabilities. Devoteam IMSLoader can also support SQL queries when application is combined via a Jdbc driver with a SQL Database. In such a combined configuration, IMSLoader can simulate an IMS application server which behavior is also determined by the XML scripts described above.
IMSLoader provides a friendly graphical user interface helping the tests case tuning. Command line launching is also possible. Tests can be launched in individual, sequential or load modes. IMSLoader also supports errors tracing and multiple logs reports (where each test case has its own log directory => easy results analysis), and statistics (nb success, nb errors, nb transaction/s, average response time ).
Devoteam IMSLoader is written in pure Java and so is supported under Windows XP and Linux. As shown in the figure below, it is based on an open architecture that allows adding new XML operations without rewriting the tool core. No performance limitations are introduced in software: the only limits are those of the protocol stack used.
IMS Loader
GUI
Command Line IMS Loader Core
Scenarii XML
XML grammar Enablers
Scenarios management XML Parsing Logs management Statistic counters management
HTTP reports Logs
Test datas Diamet er Radius SCTP JDBC HTTP TCP/ UDP RTP SIP
System Under Test
Figure 44 - IMSLoader architecture
IMSLoader tool is based on Devoteams experience of 9 years in VoIP protocols and SIP stacks, and partnerships with several constructors, editors and operators leaders in the IMS and SIP services domain (Siemens/NSN, Ericsson, France Telecom, Ubiquity ): Development for Siemens of a Push-To-Talk application in accordance with 3GPP IMS and OMA, Development for Siemens of a SIP Application Server in accordance with 3GPP IMS and with JSR 116 (SIP Servlet API) Prototype of IMS services for France Telecom R&D, Study and IMS network engineering for France Telecom R&D IMSLoader scripts for service validation and automated non-regression tests for Ericsson IMS platform introduced in France Telecom network. This last example particularly shows that IMSLoader tool applies to operators/constructors needs in context of migration toward NGN/IMS networks in terms of functional tests (call-flows validation), non-regression tests, lasting tests and performance tests with traffic generation.
10.2.
SITT tool
SITT is a scalable SIP traffic generator, for load, stability and capacity testing of IMS core network elements. For load test of IMS Core, the SITT-IMS tool supports Gm interface with both signaling traffic (Gm-C) and payload media handling (GmU), and the Ut interface for buddy-list creation/deletion. The tool can be used for capacity testing as well as for background load.
Figure 45 - SITT architecture 94 Devoteam CONNECTING BUSINESS & TECHNOLOGY
SITT-IMS allows the customer to load-test IMS Core with up to 500.000 registered SIP subscribers at a rate of up to 4000 simulated SIP half calls/s. SITT configuration is highly scalable: the traffic load is increased simply by adding SITT-IMS units SITT-IMS focuses on normal case load and stability testing, and it does not need test scripting / programming to function. SITT-IMS is easy to use and does not need any specially trained operator for test and verification management. The following IMS procedures and services are supported by SITT-IMS: Registration / de-registration (3GPP TS 24.229), Event handling including subscription/notification (3GPP TS 24.229), Ad-hoc on demand PoC Session call setup with SDP/XML body describing PoC settings / termination of sessions (3GPP TS 24.229), POC traffic scenarios (3GPP TS 23.979), Support for presence; Publish presence status, for registered state and when presence-state changes. Subscribe to presence event and watcher info, Watchers receive NOTIFY, Support for both TEL and SIP URI, Support for temporary Id during registration, (USIM), Unconfirmed and confirmed mode, Digest authentication, TBCP, TCP/UDP, Media support (RTP/RTCP), XCAP Support for buddy list creation and deletion. Notify content control for presence NB: SITT is not aiming for supporting all procedures and all variants of all procedures that are standardized within 3GPP/OMA/IETF. The approach is rather to implement the normal traffic procedures in order for these to generate background traffic load. When a SITT-IMS load test is executing, the vast majority of subscribers (called the load subscribers) are acting according to the configured traffic model. The traffic model describes which procedures the load subscribers are performing and the rate of execution of these procedures. As opposed to load subscribers, the Interactive Subscribers concept enables the user to execute and trace the results of selected events (from the SITT GUI) for specific subscribers in parallel with the background traffic load in order to trace results of specific events (detection/analysis of erroneous network conditions under high traffic load). The idea is that 95 Devoteam CONNECTING BUSINESS & TECHNOLOGY
while background load from load subscribers are running, the interactive subscribers can run easily traceable and measurable procedures "in the foreground".
There are two ways of configuring and operating SITT-IMS: SITT-IMS GUI and CLI commands. During operation of a SITT-IMS load test, several read-only output windows are visible to the user: - The status window displaying current values/graphics of selected essential statistical counters, - The alarm, event and debug logs, Latency, measure duration of signaling procedures.
Figure 46 - SITT GUI
In context of migration toward IMS network, the main benefits of SITT-IMS are: The tool helps to proportion the IMS core network from real practice point of view (particularly when core network nodes are not delivered by the same constructor), It also helps to ensure risk-free introduction of new hardware/software (particularly when existing customer traffic is migrated to new nodes e.g. from RTC to NGN/IMS nodes), Using SITT-IMS reduces time to market by project testing time and associated costs.
10.3.
Conclusion (comparison IMSLoader / SITT tools)
IMSLoader and SITT tools are really complementary in a migration toward NGN/IMS scenario:
IMSLoader - Functional tests (call-flows and service configuration validation), - Non-regression tests, - The tool can act as Client or as Server. - XML Scripting needed - Almost all interfaces defined in the IMS core -Protocols: SIP, Diameter/Radius, RTP / RTCP, TCP / UDP / SCTP, HTTP / SOAP, IPv4 - Runs on any hardware supporting: Windows XP, Linux, Unix - A simple laptop is enough to run and use IMSLoader.
SITT-IMS
- Load tests and background load - Traffic model tests - The tool acts as Client. - No scripting needed - Allow interactive subscriber to connect during a load test - Gm-C/Gm-U/Ut interfaces - Protocols: SIP, RTP / RTCP, TCP / UDP, HTTP, XCAP, IPv4
- SITT delivered on a standard hardware platform running Linux. All SITT-IMS software comes preinstalled and tested. - SITT-IMS hardware is equipped with 6 gigabit Ethernet ports, 1 for Gm/Ut, and 1 for LAN. The last four are for future extensions.
Protocol Type test Flow Trans/s SIP Uac=> 405 Uas SIP UacUas 142 => proxy AAA Uac=> 777 uas UDP Uac=> 1499* uas HTTP** Uac=> 456 uas
Response CAPS Time 0.411 134 0.674 0.097 47
0.001
Benchmark conditions: uPADM Athlon 64 X2 Dual Core processor 3800+ 2Ghz, 2Gb RAM, Windows XP (office configuration), JRE: 1.5.0_12, IMSLoader: V3.3.4
73, rue Anatole France 92300 Levallois-Perret Tl. : +33 (0)1 41 49 48 48 - Email : info@devoteam.com www.devoteam.com

2008 Whitepaper Migrations To Ngn-Ims

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2008 Whitepaper Migrations To Ngn-Ims

Uploaded by

Copyright:

Available Formats

Migrations to NGN/IMS

Devoteam white paper

Devoteam Knowledge Communities October 2008

Migrations to NGN/IMS white paper

2 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

4 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

1.1. Purpose of the document

1.2. How to read this White Paper

6 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

1.4. About the authors

7 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

9 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

Multi services convergence

10 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

2.1.1. A gradually eroding European fixed revenue

Migrations to NGN/IMS white paper

2.1.2. Near saturation on mobile markets has spurred competition

12 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

2.2.1. Changing end-user expectations, behaviours and usage patterns

2.2.2. Advanced technological tools, telecom and media convergence

13 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

2.2.3. Transformation of Telco players positioning and business models

2.2.4. Globalisation transitions

Migrations to NGN/IMS white paper

3.2. Acting on control points

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

18 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

19 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

21 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

22 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

4.2. Current regulatory framework

Migrations to NGN/IMS white paper

4.3. Current rules

Migrations to NGN/IMS white paper

4.4. Regulatory evolutions proposed by the EU

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

Migrations to NGN/IMS white paper

28 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

5.1. Reminder of PLMN migration milestones

Migrations to NGN/IMS white paper

30 Devoteam CONNECTING BUSINESS & TECHNOLOGY

Migrations to NGN/IMS white paper

Figure 2 PLMN migration from GPRS to UMTS Release 99 / Release 4