Académique Documents
Professionnel Documents
Culture Documents
MIGRATION TO NGN/IMS
DEVOTEAM WHITE PAPER
OCTOBER 2008
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
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").
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
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.
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.
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
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.
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
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
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.
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.
NGN
Cl4 transit NGN CS
IMS
Transit
Fixed
Mobile
R99 MSC
R4 MSC
< 2005
2005-2010
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.
Domain
Mobile Fixed Transit
Circuit Switched
NGN
IMS
BICC
SIP-IMS
Arrival Date
> 2010
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
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
Internet
POTS
DSL
AT A
DSL
POTS IP Phone PC
IP Phone
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).
MNP SCP
Billing System
HSS
SIP
MSC
CSCF
SIP
Mobile CS Network
Softswitch
MSC
MGW
TDM/SDH
Fix Network
IP Network
Network Management
Switch
PRI
MSAN
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.
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
SIP
SIP
SIP
MSC-S
I-SBC
BGCF
SIP
IBCF
MGCF
BICC
H.248
TPO SIP
MGW
IBGF
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
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
SCP
IN/Camel service
SCP
IN/Camel service
HSS MAP Cx
ISC
SIP
I-CSCF
Home Access Network
S-CSCF
GGSN
P-CSCF
SCP
AS
IN/Camel service
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
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
D5
HSS
D4
D6
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
!"
S/T
A-BGF
MRFP
T-MGF I-BGF
Z MG
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 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
Doc. Nb. TS 183 010 Ver. 1.1.1 Ref. DTS/TISPAN-03028-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
Doc. Nb. TS 183 008 Ver. 1.1.1 Ref. DTS/TISPAN-03026-NGN-R1 Technical Body: TISPAN 03
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
Doc. Nb. TS 183 007 Ver. 1.1.1 Ref. DTS/TISPAN-03025-NGN-R1 Technical Body: TISPAN 03
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
Doc. Nb. TS 183 006 Ver. 1.1.1 Ref. DTS/TISPAN-03024-NGN-R1 Technical Body: TISPAN 03
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Message Waiting Indication (MWI): Protocol specification NGN MWI
Doc. Nb. TS 183 005 Ver. 1.1.1 Ref. DTS/TISPAN-03023-NGN-R1 Technical Body: TISPAN 03
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Conference (CONF); Protocol specification NGN CONF
Doc. Nb. TS 183 004 Ver. 1.1.1 Ref. DTS/TISPAN-03022-NGN-R1 Technical Body: TISPAN 03
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification NGN Cdiv
rd
Web Portal
OSA API
OSA/Parlay Gateway
MMS Parlay 5.x
Framework
MPCC
UI
S CP
SGSN GPRS
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.
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
Parlay X AS OSA AS
Service Layer
ISC
OSA
OSA
CAP/INAP
HSS
Service Broker
ISC
P-CSCF
I-CSCF
S-CSCF
MRF
MGCF
MGW
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
SIP AS
SIP appl. appl.
INAP/CAP SCIM
SIM INAP/CAP
ISC
HSS Cx Cx
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
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
sdk
...
SCP
IN/Camel service
BSS
Ro/Rf SIP
MMC SMSC
Cx
ISC
SMPP
PS
HSS
Cx Cx
SCIM
INAP/CAP ISC
VMSC MSC
GGSN
I-CSCF
SIP
S-CSCF
SIP
PSTN Network SSP
P-CSCF SIP
MRF
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.
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
GMSC
MGCF
I-CSCF
S-CSCF
SIP
M-MGW
IM-MGW
Media (RTP)
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
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.
UE-3
UE-4
LRF
CS
MGCF
SIP SIP ISUP
PSAP
AGCF
S_CSCF/ E CSCF
H248 TDM
UE
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)
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).
Presence Server
XCAP Server Pres-rules Pidf manipulatio n Resource Lists
Core
PUBLISH
NOTIFY
Presentity
Watcher
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.
Friend
Presence server
Subscriber in meeting
AS
Presence server
IN-SCF
caller
switch
Legacy user
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
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
OnePhone
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.
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.
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.
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.
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.
SIP on IP
S-CS CF
MG CF
Legacy signalling on IP
MGW GGSN
IP Stream
Transcoding
TDM Stream
IP Stream
SGW
GSM/UMTS CS Network
PSTN PLMN
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
(RFC 4165)
M2PA
(RFC 4960)
SCTP
MTP-1
(Q.702)
(RFC 4960)
SCTP
IP (RFC 791)
(RFC 1483)
E1/DS1
Ethernet
(ITU-T)
HSL
Broadband
(ATM)
(GR-2878-CORE)
SIGTRAN
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
MGC
BICC M2PA
MGC M3UA
SGW
LE
TEX
Trunks
MGW
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.
This chapter and the next gives examples of some real life situations, illustrating the transient hybrid situation during the Legacy to IMS network migration.
!
)$ / 0 " &'()*(+', +($ / 0 " &'()*(+',++$ / 0 " &'()*(+', +8$ / 0 " &'()*(+',+-
"
SS7 NP
)-$ . " % &'()*(+', +))$ " % &'( ()*(+',+-
1 2 "
*$ " '$ "5 6 6 )8*7 % 67 95 1 5 "
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!"
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
2!
8$ . % -,--)('*+8
5 5
. 4
/ ; 5
SCP
$ % )*(+',+-
+$ / 0 " &-,--)('*+8
SS7 NP
1 2 "
*$ '$ "5 6 6 )8*7 % 67 95 )-$ / 0 " &)*(+',+))$ " % )*(+',+-
1
Service Switching Point
3 4
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 :)"
"
SS7 NP
; 3#(-<+-; --
*$ 7 "
7=
3 4
.
5= "
4
>? % /
. $
Figure 38 - PSTN
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
"
$
2 "
/ " A
3 4
($ .
=
95 $
7=
5= 95
; 3#(-<+-/
3 4
.
1 :)"
5= "
4
*$ 7 "
7=
>? % /
. $
Figure 39 - PSTN
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
CAMEL
Diameter : CCR
HPLMN
VMSC
HLR
B sub
MAP : MO_Forward_SM
SMSC
Figure 40 - Camel
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.
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 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.
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.
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
Scenarii XML
Test datas Diamet er Radius SCTP JDBC HTTP TCP/ UDP RTP SIP
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.
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.
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.
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
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