IMS Network Signaling Peering: Challenges and Proposal

8/14/2019 IMS Network Signaling Peering: Challenges and Proposal

1/17

IMS Network Signaling Peering:Challenges and Proposal

Jean-Philippe Joseph

IP Multimedia Subsystem (IMS) network peering is a key enabler that willhelp accelerate deployment of next-generation IMS-based networks. Todays

early deployments of dispersed IMS networks require public switched

telephone network (PSTN)/public land mobile network (PLMN) bridges for

network interconnection between IMS islands. The PSTN/PLMN bridging

arrangement is inefficient, however, in that it results in unnecessary

settlements for the carriers. It further impedes the implementation of rich

multimedia and Voice over IP (VoIP)-related services that require end-to-end

Internet Protocol (IP) connectivity. Last, it perpetuates the reliance on the

existing PSTN/PLMN network for voice calls among subscribers served by

different IMS-based carriers. This paper analyzes in detail the IMS peering

challenges from the perspective of Session Initiation Protocol (SIP) signaling

peering. It discusses issues related to the routing of SIP messages, and

addressing, address resolution, and discovery of peering points for IMS

signaling peering. It further establishes that a new routing algorithm is

needed that will allow signaling peering points to dynamically discover the

best transit network among others for reaching a destination. In closing,

it presents a high-level IMS signaling routing process that includes, among

other benefits, support for number portability as a key function for

inter-carrier IMS peering. 2008 Alcatel-Lucent.

voice, IMS networks essentially rely on the PSTN to

route voice calls among the IMS islands. That is, calls

among IMS subscribers served by different SPs are

most likely routed through the PSTN, resulting in less

efficient routing, an inability to support end-to-end

VoIP related services (e.g., wideband voice), unnec-

essary settlements, and the undesirable impact of

perpetuating the PSTN.

Various standards organizations have recently

begun to tackle crucial aspects of IMS peering,

including policy, signaling, network, and security

peering. The International Telecommunication Union,

Introduction

Globally, many service providers (SP), wireline

and wireless alike, are planning or already starting

to deploy next-generation IP Multimedia Subsystem

(IMS) [1] networks to evolve from the embedded

base public switched telephone network (PSTN). The

IMS networks will, among other things, support rich

and robust multimedia services including Voice over

Internet Protocol (VoIP) and, hence, enhance user

experience.

These initial IMS networks, however, are being

deployed in islands with no direct interconnections

among themselves. For instance, for narrowband

Bell Labs Technical Journal 12(4), 3348 (2008) 2008 Alcatel-Lucent. Published by Wiley Periodicals, Inc. Publishedonline in Wiley InterScience (www.interscience.wiley.com) DOI: 10.1002/bltj.20265


2/17

34 Bell Labs Technical Journal DOI: 10.1002/bltj

Telecommunication Standardization Sector (ITU-T)

next-generation network (NGN) defined resourceand admission control functions (RACF) require-

ments [15] for effective resource management in the

transport layer. The Internet Engineering Task Force

(IETF) recently created the Session Peering for

Multimedia Interworking (SPEERMINT) working

group to define a framework for layer 5 peering

[18, 20]. The 3rd Generation Partnership Project

(3GPP*) defines in Release 7 (R7) a new signalingpeering entity: the interworking border control func-

tion (IBCF) [2]. The GSM Association (GSMA) defined

guidelines for IMS roaming and interworking [10].

The European Telecommunications Standards Institute

(ETSI) addressed issues related to interconnection

and routing, and their implications on numbering,

Panel 1. Abbreviations,Acronyms, and Terms

3GPP3rd Generation Partnership ProjectAAAAuthentication, authorization and

accountingBGCFBreakout gateway control functionBGPBorder Gateway Protocol

CdPCalled partyCSCFCall session control functionDDDSDynamic delegation discovery systemDNSDomain name systemE2UE.164 to URI ResolutionENUMElectronic number mappingGPRSGeneral packet radio serviceGRXGPRS roaming exchangeGSMGlobal System for Mobile

CommunicationsHSSHome subscriber serverIBCFInterworking border control functionI-CSCFInterrogating CSCF

IETFInternet Engineering Task ForceIMSIP Multimedia SubsystemINIntelligent networkIPInternet ProtocolISDNIntegrated services digital networkISPInternet service providerISUPISDN user partITUInternational Telecommunication UnionITU-TITU Telecommunication Standardization

SectorLDLong distanceLERGLocal exchange routing guide

LFLocation functionLIALocation-info-answerLIRLocation-info-requestLRNLocation routing numberMGCFMedia gateway control functionNAINetwork access identifierNAPTRNaming authority pointerNGNext-generationNGNNext-generation network

NPNumber portabilityNPANumbering plan areaNPDBNumber portability databaseOPEXOperational expendituresPbUIPublic user identity

P-CSCFProxy CSCFPDAPersonal digital assistantPFPolicy functionPLMNPublic land mobile networkPPPeering pointPrUIPrivate user identityPSTNPublic switched telephone networkQoSQuality of serviceRACFResource and admission control functionRFCRequest for commentsS-CSCFServing CSCFSCTPStream Control Transmission ProtocolSFSignaling function

SIPSession Initiation ProtocolSLAService level agreementsSLFSubscriber location functionSMSession managerSPService providerSPEERMINTSession Peering for Multimedia

InterworkingSPNPService provider number portabilitySRVService recordSS7Signaling System 7TASTelephony application serverTCPTransport Control ProtocolTELTelephoneTHIGTopology hiding interface gatewayTLSTransport layer securityUAUser agentUDPUser Datagram ProtocolURIUniform resource identifierVoIPVoice over IPVPNVirtual private network


3/17

DOI: 10.1002/bltj Bell Labs Technical Journal 35

naming, and addressing for NGN Telecommunication

and Internet Converged Services and Protocols for

Advanced Networks (TISPAN) [6]. The content of this

paper reflects the work conducted, thus far, by these

organizations.

This paper analyzes in detail the IMS peering

challenges from the perspective of Session InitiationProtocol (SIP) signaling peering. It focuses primarily

on voice applications and delves into other critical

networking issues that further complicate the discov-

ery of signaling peering points for inter-carrier rout-

ing. Finally, it presents a high-level signaling routing

process for IMS signaling routing that includes sup-

port for number portability as a key function for inter-

carrier IMS peering, and identifies key areas for

further investigation.

The paper is organized as follows: We first pro-

vide background material on why the PSTN is usedtoday for IMS network interconnection and the

impacts of PSTN bridging. Next, we describe a generic

case of IMS peering to discuss the critical issues

related to address resolution and discovery of peer-

ing points. We follow by presenting other factors

such as inter-domain IP infrastructure, identification,

and address formatthat impact IMS peering. We

describe a proposal for a signaling routing process for

IMS peering, summarize our conclusions, and outline

key areas for further investigation.

Background

Today, when placing a Voice over IP call to reach

a destination endpoint served by a different VoIP

operator, most likely, the call is routed through the

PSTN. In some cases, even calls between two VoIP

subscribers served by the same SP are hairpinned over

the PSTN. The next section examines why it is so.

Why Are IMS-to-IMS Calls Routed Through the

PSTN Today?

One of the key issues that impede direct peering

among IMS networks is address resolution in supportof routing of SIP signaling messages, particularly dur-

ing session/call establishment or setup. In the PSTN

network, call routing is based on global addressing

using ITU-T E.164 [13] numbers (e.g., NPA-NXX-

XXXX in North America) to uniquely identify the

users, and on point codes to identify switching points.

In addition, the entire process is supported by com-

mon databases that are shared among carriers, such

as the local exchange routing guide (LERG), and by

pre-defined routing tables that associate switches with

telephone numbers.

Call routing in IMS, however, is completely

different from that in the PSTN. First, the currentIMS systems have not deployed a routing capability

that is fully equivalent to that of the existing PSTN.

Second, routing in IMS is based on a different entity:

SIP uniform resource identifiers (URI) [23]. SIP URIs

are used to identify IMS users and resources (e.g.,

servers and databases) and have a format similar to

an email address with a user name and a domain name

(e.g., sip:[email protected]). The domain por-

tion identifies the host responsible for handling the

request for the user. For instance, the domain portion

may identify the IMS operator serving the particularuser. Hence, during call processing, SIP URIs need to

be resolved using domain name system (DNS) proce-

dures, described in [5], in order to determine the

IP address and port number of the corresponding

domain name server for the domain portion of the

SIP URI.

In the particular case where an E.164 telephone

number is used to establish a call, IMS invokes tele-

phone number mapping (ENUM) [7], an application

of the DNS, to perform the translation of the E.164

number into a SIP URI. The ENUM protocol uses aspecific naming authority pointer (NAPTR) DNS

resource record, the E.164-to-URI resolution (E2U),

as defined in [19], to identify and map the E.164

number with associated communications services

and resources (e.g., call server, email). This mecha-

nism allows a user to reach a destination by dialing

a telephone number, regardless of the device (e.g.,

phone, PDA) the destination party might happen to

be using. In short, in IMS, ENUM/DNS provides an

essential location functionequivalent to the LERG

in PSTNfor reaching a user identified with anE.164 number.

This location function in IMS is at the heart of

the problem that forces routing through the PSTN for

IMS-to-IMS calls. Currently, there are several pro-

posals for ENUM/DNS implementation in support of

address resolution in IMS networks. However, there is


4/17


no agreement in the industry on a definitive solution.

These proposals are as follows:

Global (public) ENUM is dedicated to making

ENUM data publicly accessible through the

E164.arpa domain at the public DNS root.

Private ENUMis owned and controlled by a single

SP, which determines whether it wants to shareany information with another SP.

Infrastructure ENUM, also known as carrier ENUM,

allows a group of carriers to share routing data

among themselves and to look-up the destina-

tion addresses of one anothers customers.

Note that both the private and the infrastructure

ENUM solutions are outside the scope of global ENUM

in that they do not use the E164.arpa domain.

However, they do share the same technological basis

and conventions as global ENUM.

Meanwhile, current implementations of IMSnetworks by early adopters leverage private ENUM

solutions for the most part. That is, the private

ENUM database is mainly populated with NAPTR

records about the SPs own subscribers. Hence, for

voice applications, if the called party (CdP) belongs to

a different IMS SP domain for which there is no

associated NAPTR record in the DNS server of the

originating network, the SIP URI address resolution

process results in an ENUM failure indicating that the

IMS domain does not know how to locate and route

the call to its destination. Today, when such a situa-tion occurs, by default, the IMS network simply

routes the call to the PSTN. This default routing ends

up creating a PSTN bridge in between two IMS

islands, particularly when the destination party is an

IP endpoint.

The technical challenges associated with IMS sig-

naling peering are explored in more detail in subse-

quent sections. For now, suffice it to say that the PSTN

bridging model is not financially sustainable over the

long term, and it is not a technically viable option for

non-VoIP-only applications. The next section providesan assessment of the impacts of PSTN bridging.

Impacts of PSTN Bridging

PSTN bridging in support of next-generation

applications will have serious financial implications

for IMS carriers in terms of both lost revenue oppor-

tunities and the opportunity to reduce operational

expenditures (OPEX) by retiring the PSTN more

quickly.

First, many IP and multimedia services (e.g., active

phone book, video telephony) requiring end-to-end

IP connectivity will not work over the PSTN. As a

result, an SP might be able to offer a particular serv-

ice to its own subscriber base; however, it will not beable to guarantee that the service will work if the

other endpoint belongs to a different SP to which it is

only connected via the PSTN. Hence, there is a poten-

tial for lost revenue for the SPs. For instance, a VoIP

call initiated with a non-E.164 address (e.g., SIP URI)

to another IP endpoint will not work over the PSTN.

Support for such a service will require the initial SIP

INVITE message containing the destination SIP URI

to be encapsulated in ISDN user part (ISUP) and car-

ried over to the destination IMS domain via the SS7

network. SIP message encapsulation in ISUP messagesis not supported today and would require further

development in the PSTN, which is unlikely to occur.

In general, applications requiring end-to-end IP

fall into these categories:

Peer-to-peer applications initiated with non-E.164

identifiers (e.g., initiating a voice call with the email

address of the called party).

Applications requiring SIP signaling.

Client/server applications that require end-to-end

IP connectivity (e.g., multiparty gaming).

Applications requiring broadband access andhigher bandwidth than the 64 Kbps narrowband

used in the PSTN (e.g., video telephony).

Second, keeping a call between two IP endpoints

in the IP domain will help SPs avoid unnecessary set-

tlements and reduce charges associated with PSTN in-

terconnections. Moreover, relying on the PSTN to

support calls among IP endpoints ends up deferring

the decision to retire the PSTN more quickly, and de-

lays the opportunity for SPs to start realizing OpEx

savings for managing one packet network.

Last, PSTN bridging results in quality of service(QoS) degradation caused by the cascading effect of

bearer conversions at the edges of the network. That

is, the bearer signal needs to be converted per ITU-T

G.711 specifications, thus incurring additional pro-

cessing delays in the media gateways placed on both

the ingress and egress sides of the PSTN.


5/17


Need and Scope

As SPs continue to deploy IMS networks and

introduce next-generation (NG) applications to enh-

ance the end user experience, the need for peering

among IMS networks and across SP boundaries will

become critical.

As shown in Figure 1, IMS peering will occur

at different layers including network, policy, sig-

naling, and security. Layer 3 peering is well under-

stoodIP networks are interconnected today and

protocols such as Border Gateway Protocol (BGP)

are well defined to support layer 3 peering. Much

work has been done in the RACF area, which de-

fines a framework for policy peering in support of

QoS [15].

However, peering at the session/signaling layer

(or layer 5) is not yet standardized. IETF SPEERMINT

recently defined a peering architecture [21] between

two SIP SPs, as depicted in Figure 2. The architec-

ture identifies the following logical functions:

Managed IPcore

PSTN/PLMN

DNS/ENUM

DNS/ENUM

IMSapplication

IMS domain A IMS domain B

IMSapplication

L5 peering

PEP

PEPMG

P/I/S-CSCFOther

core IMSelements

RACF

Managed IPcore PEPPEP

RACF

P/I/S-CSCFOther

core IMSelements

PEP

Wirelineaccess network

Wirelessaccess network

IMS peeringscope

Application

Call/sessioncontrol

Media/access

CSCFCall session control function

DNSDomain name system

ENUMElectronic number mappingIMSIP Multimedia Subsystem

IPInternet Protocol

L5Layer 5

MGMedia gateway

PEPPolicy enforcement point

P/I/S-CSCFProxy/interrogating/serving CSCFPLMNPublic land mobile network

PSTNPublic switched telephone networkRACFResource and admission control function

Figure 1.IMS peering scope.


6/17


1. Location function (LF) provides the routing data for

the purpose of the discovery of the signaling and

policy functions, and reaching the end user. The

LF, in fact, uses the ENUM/DNS infrastructure to

support the peering process.

2. Policy function (PF) provides a framework for

authentication and the exchange of policy param-

eters to be used by the signaling function.

3. Signaling function (SF) handles the routing of SIP

messages and assists in the discovery of param-

eters to be used by the media function.4. Media function (MF) performs media-related func-

tions including media transcoding between two

SIP-based SPs networks.

The scope of our work, in what follows, is lim-

ited to the LF and SF, as described above.

IMS-to-IMS Signaling Peering for a Basic

Voice Call

In general, the inter-carrier signaling routing

process in IMS can be divided into the following

major phases:1. Initialization and address analysis and resolution,

2. Determination of a peering point in the orig-

inating network,

3. Discovery of a peering point in the terminating

network, and

4. Routing in the terminating domain.

The next section discusses in detail the steps

associated with these phases.

Signaling Steps

In this example, each carrier implements a pri-

vate ENUM/DNS solution in its network, and domain

A and domain B are the home networks for useragent A (UAa) and user agent B (UAb), respectively.

For simplicity, the registration and authentication

steps, which would involve the use of an authentica-

tion, authorization, and accounting (AAA) server, and

the home subscriber server (HSS) are not shown. We

further assume that each domain contains only one

HSS server, and therefore the subscriber location

function (SLF) is not required. We also combine the

three call session control functionsinterrogating

CSCF (I-CSCF), serving CSCF (S-CSCF), and proxy

CSCF (P-CSCF)into a session manager (SM). Further-more, we do not represent any element at the appli-

cation layer (e.g., a telephony application server or

TAS) that might be invoked during the call setup. Last,

we do not show the breakout gateway control func-

tion (BGCF) and media gateway control function

(MGCF) components, which would be invoked if the

call were destined for the PSTN/PLMN.

The signaling routing steps for a voice call between

UAa and UAb, shown in Figure 3, are as follows:

1. UAa initiates a SIP INVITE with UAbs telephone

number, as the called party. The CdP number ismapped into the request URI of the SIP INVITE.

2. Upon receiving the SIP INVITE, SMa queries the

ENUM server on the CdP: UAb.

3. Two cases might occur:

a. If the ENUM server does not contain a NAPTR

record for the CdP, and the carrier-of-record

associated with the CdP cannot be found or

reached via SIP peering, then the call is routed,

by default, to the PSTN. This case is not shown

on Figure 3.

b. Otherwise, the ENUM server returns a NAPTRrecord to SMa with the domain name asso-

ciated with Uab.

4. SMa requests support from a local policy infra-

structure (Pa) to determine the peering point in

domain A (PPa) where it should forward the SIP

INVITE. PPa is an IBCF, which provides, among

OriginatingSPs

network

LF

PF

SF

MF

LF

PF

SF

MF

LF

ReceivingSPs

network

IETFInternet Engineering Task Force

LFLocation functionMFMedia function

PFPolicy function

SFSignaling function

SPService providerSPEERMINTSession Peering for Multimedia Interworking

Figure 2.IETF SPEERMINT reference architecture.


7/17


other things, firewall functions for signaling,

policing of signaling, and topology hiding.

5. Pa applies its local policy rules to determine the

appropriate peering point to handle the call, and

then forwards the SIP INVITE to SMa with the

URI associated with PPa.

6. SMa queries the DNS server in domain A to

retrieve the IP address for PPa.7. The DNS server in domain A returns the PPas IP

address to SMa.

8. SMa sends the SIP INVITE toPPa with the domain

name servingUAb.

9. PPa queries the DNS in domain A to resolve the

address of a peering point in domain B (PPb). At

this stage, resolving the address of UAb results in

finding the IP address, port number, and transport

protocol for PPb.

10. DNS server returns the IP address of PPb to PPa.

11. PPa , as a gateway to external networks, mayencrypt part of the SIP message to perform the

topology hiding interface gateway (THIG)

function and forward the SIP INVITE to PPb.

12. PPb, upon determining that the domain associated

withthe request URI isdomainB,needs toforward

the SIP INVITE to SMb. The following steps, not

shown on the diagram, might occur in order to

locate SMb. If the SIP INVITE message does not

contain a route header field that points directly to

SMb, PPb sends a location-info-request (LIR) over

theCxinterfaceto the HSSto locatethe appropriate

SM. HSS replies with a location-info-answer (LIA)

command that indicates the SIP URI of the server,

in thiscaseSMb,thatservesUAb.13. PPb queries the DNS server in domain B to

obtain the IP address for SMb.

14. PPb forwards the SIP INVITE request to SMb.

15. SMb may invoke a TAS to apply further call logic

and forwards the SIP INVITE request to UAb.

16. UAb accepts the call and replies with a 200 OK

message toUAa, also not shown.

Issues Related to the Signaling Routing Steps

In this section, we analyze the signaling routing

steps discussed above to identify the salient rout-ing issues that might occur in IMS network implemen-

tations. We group these issues under three categories

and discuss them separately.

CdP address resolution. As indicated in step 2, the

CdP address resolution is performed using the ENUM

service offered on the DNS server. In the example we

UAa PPa PPb SMbSMa UAb

E D D E

PbPa

IMSdomain A 7

8

13

IMSdomain B

1

2 6

11

12

14 15

1039

45

DDNS server

DNSDomain name systemEENUM server

ENUMElectronic number mapping

IMSIP Multimedia Subsystem

IPInternet ProtocolPPolicy

PPPeering point

SMSession managerUAUser agent

Peering IPnetwork

Figure 3.Signaling routing steps.


8/17


presented, the SP uses a private ENUM infrastructure,

which might not contain a NAPTR record for the CdP.

This might happen if a different SP serves the CdP. In

this case, the decision to route to the PSTN upon an

ENUM failure response, as described in step 3a, cre-

ates a routing dilemma because the CdP could be an

IP endpoint in domain B, and not a PSTN user. Therouting decision is based on not having the capability

to map the CdP telephone number with a SIP URI in

domain A, but does not take into consideration the

fundamental question as to whether the CdP is an IP

or a PSTN endpoint. In the latter case, it is appropri-

ate to route to the PSTN. In the former case, how-

ever, the call should simply be maintained in the IP

domain.

Finally, we believe that private ENUM implemen-

tation will not satisfy the long term need to remain

in the IP domain for an inter-domain call served bydifferent SPs. A long term solution should be based

on a common directory of telephone numbers and

associated domain names that are restricted to the SPs

use and not accessible by public Internet users. Such

a common directory can cover many SPs across a

geographic area (e.g., regions in country) and be

administered by a trusted third party on behalf of the

SPs. This solution is conceptually similar to existing

administrative domains and database infrastructures

available in the PSTN, such as the telephone number-

ing plan or LERG.Determining peering point in originating domain. In

step 4, we discussed another important aspect of the

signaling routing process: selection of a peering point

in the originating IMS domain. The originating IMS

network will need to make intelligent decisions in the

selection of its own signaling peering point in support

of call setup, as it will likely have multiple signaling

peering points to interconnect with other networks.

This decision is dynamic in nature and varies with the

target destination network of the CdP. SPs may employ

caching methods to minimize call setup delays of sub-sequent calls in the selection of a peering point.

However, several other conditions in the originating

IMS network might influence such a selection as well.

For instance, the choice of a peering point can be

made based on quality of service policies (e.g., call

setup delay) defined to meet peering and user service

level agreements (SLA). Engineering factors such as

call rate, and current utilization of the proxy server

performing the peering function can lead to a distri-

bution of the calls among the available peering points

in support of load balancing requirements. Last, this is

an area that requires further investigation and would

most likely require support from a policy infrastructure.We will discuss further aspects of this selection process

later in the paper.

Discovering peering point in terminating domain.

Step 10 discusses a DNS-based mechanism for the peer-

ing point in the originating network, which allows the

discovery of a peering point in the terminating net-

work. The IETF has addressed in detail the discovery

process of a proxy server (i.e., the peering point in our

context) in a different domain in RFC 3263 [22]. In

essence, the peering point in the originating network

makes use of DNS procedures, using both servicerecord (SRV) [11] and NAPTR records, to determine

the IP address, port, and transport protocol (e.g.,

Transport Control Protocol (TCP), User Datagram

Protocol (UDP), Stream Control Transmission Protocol

(SCTP), Transport Layer Security (TLS)), for the peer-

ing point in the terminating network. Additionally, RFC

3263 describes the procedures to allow the peering

point in the terminating network to discover a backup

peering point in the originating network, in case the

latter fails in the middle of the call setup transaction.

In short, the originating network will find all requiredinformation to establish a call on IP to the terminating

network, including the border elements of the termi-

nating network.

The premise of RFC 3263, however, is based on a

global address resolution scheme that is accessible

through the E164.arpa domain at the public DNS root.

That is, SPs will have to publish SIP URIs of their peer-

ing points in the public DNS so that they know where

to signal one another. While such architecture works

reasonably well today for handling email services over

the Internet, its implementation in SP networks willend up exposing their critical signaling resources to

Internet users. Thus, we believe that SPs deploying

IMS networks will be reluctant to embrace this solu-

tion until they can be assured that great concerns

about security risks or attacks on key signaling assets

are fully addressed.


9/17


Meanwhile, a way forward is for SPs to create fed-

erations and use infrastructure ENUM/DNS for peering

point discovery within a federation. A federation is a

group of SPs that agree to accept calls from one another

via SIP, according to a set of administrative rules and

contractual financial terms established for such calls. In

the next section, we analyze other networking condi-tions that impact the peering process as well.

Other Factors Influencing Signaling Peering

In addition to the issues identified in the signaling

steps, there are other important factors that will

influence the signaling peering process. In general,

these factors are related to the nature of the peering

infrastructure between the originating and terminat-

ing domain, as well as the handling of the CdP address

format and translation at the peering points.

Inter-Domain IP Infrastructure for SignalingThe inter-domain IP infrastructure between the

IMS originated and terminated networks can be one

of the following cases:

1. The public Internet.

2. Direct connections over leased lines, IP-virtual

private network (VPN) or tunneling over the

public IP network, among the SPs peering points

to create a fully meshed interconnect signaling

network.

3. A managed IP network commonly owned by the

SPs for the purpose of transferring IMS signaling-related traffic among the different SP networks.

This case is similar to the proposed GPRS roaming

exchange (GRX) [9] of the GSM Association for

PLMN network interconnections.

4. A third-party-managed IP network similar to an

existing VoIP clearinghouse, an SP that offers

termination, financial services, and enhanced

applications to other SPs (e.g., Internet service

provider (ISP), VoIP) but serving the IMS SPs

signaling interconnection needs.

The inter-domain IP infrastructure need not bean IMS network, but should ensure that key require-

mentssuch as QoS, reliability, security, and address

resolutionare met. Issues related to IPv4-to-IPv6

interworking are outside the scope of this document.

In what follows, we evaluate each inter-domain archi-

tecture alternative and its impacts on the signaling

peering process between the originating and termi-

nating IMS domains. We evaluate these alternatives

from the points of view of address resolution and

discovery of the peering point in the terminating

network.

The public Internet. This scenario, as shown

in Figure 4, leverages an open interconnection

architecture where the SPs peering points addresses

are public IP addresses and are directly accessible by

Internet users. This also implies that inter-carrier IMS

signaling messages are routed over the public Internetwithout any guarantee that the signaling require-

ments (e.g., delay, priority of traffic) will be met. This

scenario has some key advantages. It potentially offers

a more open solution to the peering issue and enables

ad-hoc peering among SPs who do not have an

explicit peering agreement.

However, this scenario requires support from a

global ENUM/DNS system with global mapping of

E.164 numbers to DNS NAPTRs containing the SIP

URIs of all the SP peering points. For the reasons dis-

cussed earlier and related to universal connectivitythrough global DNS, we do not believe this scenario

will address the SPs security concerns, and hence it is

not recommended.

Fully meshed interconnect network. This scenario

provides direct links among the SPs signaling peering

points and results in an n2 problem, where n is the

PublicENUM/

DNS

Domain A Internet Domain B

Domain Z

DNSDomain name systemENUMElectronic number mapping

Figure 4.Peering via public Internet.


10/17


number of peering points, as illustrated in Figure 5.

SPs may use public IP addresses for their peering

points; however such addresses are not accessible

by public Internet users. The supporting DNS system

resolves the terminating peering point address into an IPaddress that is routed over a particular link. In general,

this solution may prove not to be scalable for a large

number of peering points. However, SPs might decide to

selectively implement it to support high volume traffic

in between large communities of interests.

Common managed IP network. In this scenario,

depicted in Figure 6, the common managed IP net-

work is a private network. It may use public IP

addresses to route SIP requests to the SPs peering

points; however, these IP addresses are not accessible

by public Internet users.In addition, this scenario requires an infrastruc-

ture ENUM/DNS system that is used only to resolve

SIP URIs associated with SP peering points, which are

attached to the common managed IP network. In

order to peer with a public domain (i.e., one not

attached to the managed IP network), the SP would

use a public Internet DNS for address resolution.

Hence, the public Internet DNS system is used to resolve

the domain names of all destinations not served

by the common managed IP network.

Finally, for traffic among the SPs served by the com-mon managed IP network, the discovery of the ter-

minating peering point always results in finding the IP

address of an access server in the common managed

IP network. Once a SIP URI request is sent to the

common managed IP network, the infrastructure

ENUM/DNS server resolves the associated domain

name into the IP address of the terminating peering

point.

Clearinghouse model. This scenario, also shown in

Figure 6, is functionally the same as the one depicted

for the common managed IP network, except that a

clearinghouse provides the administration of the

inter-domain IP infrastructure. A variant of this caseis that the clearinghouse is only used as a trusted third

party registry administering the infrastructure ENUM/

DNS hierarchy and providing SPs with the routing

information needed for address resolution.

In summary, the nature of the inter-domain IP

infrastructure impacts the address resolution process

for the discovery of the terminating peering point. It

further determines what network knowledge is requi-

red to reach the terminating domain. For instance, in

the first scenario, a global directory ENUM/DNS is

required, whereas in the second case, static routingtables might be sufficient to reach the terminating

network. Hence, the call processing algorithm for SIP

peering should take the inter-domain infrastructure

into consideration.

Transit network/federation. In the absence of a

global directory ENUM/DNS, SPs will likely group

Carrier

ENUM/DNS

PublicENUM/

DNS

Domain AManaged IP

networkDomain B

Domain Z

Domain X


IPInternet Protocol

Figure 6.Peering via managed IP network.

Domain A Domain B

Domain Z

Fully meshed

Figure 5.Peering via fully meshed network.


11/17


themselves into federations to satisfy their intercon-nection needs. Figure 7 illustrates a multi-federation

arrangement among four SP networks. Moreover, it

shows that the relationship with a federation might

not be exclusive. An SP might belong to more than

one federation for various financial and technical rea-

sons. For instance, domain A belongs to federations

1 and 3. Furthermore, an SP which belongs to multi-

ple federations might offer to become a transit SP for

other SPs. In our example, domains B and X can be

such transits for domains A and Z. Likewise, domains

A and Z can be used as transits for traffic between do-mains X and B. As a result, domain A can use either

domain X or domain B to reach domain Z. Therefore,

a key question a routing algorithm needs to address is

which federation to use to reach a target destination.

In addition, [16] and [12] discuss the need for fed-

erations to use fully qualified domain names as their

identifiers, and that members of a federation might

need to publish federation membership as domain

attributes. In other words, to route a call to its destina-

tion, the originating network might need to retrieve the

set of federations to which the terminating networkbelongs. If there is a shared federation, which can be

determined through the domain policy dynamic

delegation discovery system (DDDS) application as spec-

ified in [17], it is used to support the call. Otherwise, the

originating network might route the call to a transit SP.

Thus, matching a common federation or selecting the

right transit network to use to reach a destinationbecomes a critical part of the signaling peering routing

process and must be taken into consideration by the

routing algorithm during call processing.

Identification and Address Format

IMS, as for any type of network, provides mecha-

nisms to uniquely identify users so that calls can be

appropriately routed to them. IMS uses public user

identities (PbUI) and private user identities (PrUI) to

identify its users. PbUI are SIP URIs or TEL URIs [24]

and are used to route SIP signaling in IMS. As discussedearlier, SIP URIs are in the form of sip:user@oper-

ator.com, where the user part can be an E.164 tele-

phone number. A TEL URI, however, is in the form of:

tel:1-NPA-NXX-XXXX, to represent, for example, a

telephone number in the North America Numbering

Plan. The TEL URI is used when the domain of own-

ership of the phone number is unknown. SIP, how-

ever, requires that the URI under registration be a SIP

URI [3]. Hence, it is not possible to explicitly register a

TEL URI in SIP. However, PrUIs do not use SIP URI

or TEL URI formats. Instead, they use a network accessidentifier (NAI) in the form [email protected].

They are exclusively used for subscription identifica-

tion and authentication purposes [3].

The rest of the paper focuses on analyzing the SIP

URI-based PbUI formats and their impacts on IMS

signaling peering.

Domain X

AXZ

ABZ

Domain A Domain BFederation 1 Federation 2

Fed

eration3 Federation

4

Domain Z

Figure 7.Peering via transit.


12/17


SIP URI formats for the PbUI. IMS users will use a

variety of devices (e.g., PDA, IP phone) to trigger NG

services and to initiate calls to other users. Likewise,

SPs may assign more than one PbUI to their customers

so they can be reached through a variety of means

(e.g., email, business phone). As a result, SIP URIs as-

sociated with PbUIs can take various forms, as de-scribed in [6], including the following:

1. sip:E.164@service provider;user phone

2. sip:user@service provider

3. sip:user@domain name

4. sip:ip address

Impacts on address resolution for SIP peering. The

format of the SIP URIs, as presented above, might in

some cases render impossible the resolution of the

destination address of the CdP. For instance,

user@domain name (case 3) might be impos-

sible to resolve if used to initiate a call. First, assumingthe domain name can be resolved to an associated

SP domain, as discussed above, user@service

provider might not be unique in the SP domain.

Second, different users belonging to a domain name

might be served by different SPs. For example, johndoe

@alcatel-lucent.com might be served by a different SP

than [email protected]. Therefore, the res-

olution of a user@domain name SIP URI

should identify the specific SP serving each particular

user. That is, the domain name server might need

to be a redirect server pointing to the carrier-of-recordthat serves the user. This can be an implementation

nightmare in that all domain names will be required

to support the redirect function. Last, considerations

should be given to the additional delay such a process

will introduce on key performance parameters such as

call setup time.

In summary, the format of the SIP URI used to

initiate a call will impact the signaling routing process

in the originating domain as well as in any transit net-

work that might be used to support the call. In addi-

tion, some formats might be impossible to resolve insupport of inter-carrier communications.

Proposed Signaling Peering Process

In order to define an appropriate peering and

routing approach for a given scenario, one needs to

consider and evaluate the end-to-end process. In light

of the routing steps and issues discussed above, we pro-

pose a high level signaling peering process, which

provides a comprehensive approach to signaling

peering and takes into account multiple constructs

(e.g., IP networks, federations, and transits) that might

exist between the originating and terminating domains.

Moreover, the proposed signaling peering processaddresses the need to perform address translation in

support of service portability as an essential step for

inter-carrier communications. A key assumption, in

this regard, is that all call query, a method by which

a number portability query is performed on all origi-

nating calls as described in [8], is used as the service

portability implementation option.

Signaling Process for IMS Peering

Figure 8 illustrates the signaling peering process

for a basic voice call initiated with an E.164 number,which we describe as follows:

1. The calling party initiates the call with a dial

string, which the originating network converts

into a fully qualified E.164 number.

2. Map the CdPs E.164 number into SIP headers

(e.g., request URI, To ) and send the app-

ropriate INVITE request to the session manager

in the originating network.

3. Analyze the CdP address for service portability

(e.g., SP portability).

4. If the CdP is not ported, proceed with 6.5. If the CdP is ported:

Perform the portability database lookup to

retrieve the location routing number (LRN)

associated with the CdP. Note that this paper

does not specify an infrastructure for perfor-

ming a number portability (NP) database (DB)

query. Options range from reusing existing

NPDBs in the intelligent network (IN) to ret-

rieving a NAPTR record from an ENUM/DNS

query pointing to the LRN.

Append the npdi yes field to the requestURI header in the subsequent SIP URI request

created with the LRN.

6. Perform address resolution of the CdP or LRN

through the ENUM/DNS infrastructure to de-

termine which destination network the CdP

belongs to. The output of this step results in a


13/17


ID mapping

CdP addressanalysis

Perform NP lookup andaddress translation

PerformNPDB?

CdP inPSTN

Terminatingdomain

Address resolution

Invoke BGCF Peering scenario

Discover peering point

Resolve PP address

Translate CdP

Route to next domain

Route to PSTN

Select MGCF/MGW

Perform SIP/ISUPconversion

ENUM/DNS withlocal policies

SIP address translationand mapping

Determine S-CSCF servingCdP and route to CdP

Route SIP invite to CdPin terminating domain

IP endpoint

PSTN endpoint

BGCFBreakout gateway control functionCdPCalled party

CSCFCall session control function


IAMInitial address message

IDIdentifierIMIP Multimedia

IPInternet Protocol

ISDNIntegrated services digital networkISUPISDN user part

LERGLocal exchange routing guide

MGCFMedia gateway control function

MGWMedia gateway

NAPTRNaming authority pointerNPNumber portability

NPANumbering plan area

NPDBNumber portability databasePPPeering point

PSTNPublic switched telephone network

RFCRequest for commentsS-CSCFServing CSCF

SSFService switching function

SIPSession Initiation ProtocolSPService provider

TELTelephone

URIUniform resource identifier

RFC 3261Request URI

PbUl:SIP URI orTEL URI

Y

Y

Y

N

N

NWhats the domain name of CdP SP?Is CdP served by initiating domain?

obtain ENUM/DNS NAPTR

Invoke policy peering function forestablishing the nature of peeringnetwork (e.g., federation, transit)

How to determine that theCdP belongs to the PSTN?

Selection basedon NPA-NXX andlocal policy rules

ENUM/DNS queries for NP orquery NPDB via IM-SSF

Identifier CdP

All call queryIs CdP open to portability?

Obtain PSTN routingdata (e.g., from LERG)

Generate ISUP IAM

Is RFC 3263 sufficient?Determining/locating PP?(originating/terminating)

Figure 8.Proposed signaling peering process.


14/17


SIP URI that represents an address of record for

the CdP.

7. If the call is destined to the PSTN, invoke the

BGCF to determine which MGCF to provide

the ISDN user part and SIP interworking func-

tion, as defined in [4], and then route the call to

the PSTN.8. Otherwise, determine whether a common fed-

eration exists between the originating and ter-

minating domains:

If so, consult the policy peering infrastructure

and apply common federation rules to dis-

cover the peering point in the terminating

network.

If not, determine a transit network to support

the call and apply corresponding federation

rules for the transit.

9. Determine the peering point in the originatingnetwork according to the local policy infrastruc-

ture and procedures defined in RFC 3263 [22].

10. Perform the SIP header translation at the

peering point and according to the SIP URI

format used, if necessary.

11. Route the SIP INVITE to the next hop (e.g.,

proxy/access server in federation) towards the

destination

12. When the terminating domain is reached,

determine the serving CSCF for the CdP, locate

the CdP, and route the INVITE to the CdP.13. Establish the session and transfer of media.

Proposal Benefits

The end-to-end signaling peering process

described above introduces new decision points and

routing steps during call setup for inter-carrier com-

munications. The benefits of such a process include:

1) support for number portability, 2) more efficient

routing among IP endpoints, and 3) avoidance of

unnecessary delays during call setup. The following

discusses these benefits.Support for number portability. In many countries,

number portability (NP) is a regulatory requirement

that SPs must comply with. As presented in step 4

and step 5 in the section above, support for NP

requires SPs to perform user identification translation

for the CdP. The outcome of the translation process

helps determine which network to route a call to for

inter-carrier communications. Various options are im-

plemented for NP. For instance, in the United States,

SPs implement the all call query option for service

provider number portability (SPNP), which allows a

user to change the SP while keeping the same

telephone number. SPNP leaves the responsibility forperforming the NPDB query to the penultimate net-

work. This decision is somewhat straightforward

in the PSTN in that for a long distance (LD) call, the

carrier of record for LD services is the penultimate

network, and, hence, it performs the query. For a toll

local call, the local SP is the penultimate network and,

as such, does the query.

IMS, however, introduces new challenges in sup-

porting NP. First, as discussed above, the CdP identifi-

cation might not be an E.164 number. Obviously, in

such cases, existing E.164-based NP databases cannotbe leveraged. Therefore, translation between SIP URIs,

and IP addresses via DNS in support of NP, becomes a

critical function in determining the next domain/

network towards a destination.

Moreover, the decision as to which SP should per-

form the NPDB becomes more complex in IMS, if we

ought to follow the penultimate model discussed

above. How to determine which network is next to

the last before performing address translation of the

CdP? In todays deployment of VoIP networks, these

demarcation lines are not clearly defined. As a case inpoint, VoIP service offerings assume mobility of end-

points. For instance, one can be living in California

and may get assigned a phone number with a New

Jersey numbering plan area (NPA) (e.g., 732). This

proposal simplifies the decision process by recom-

mending that the originating network always perform

the appropriate translation of the CdP address on all

calls, once it determines that such an address is open

to portability.

Determining the nature of CdP endpoint. Another

important decision point during call processing,summarized in step 7 and step 8 above, is for the

originating network to determine whether the CdP

is a PSTN or IP endpoint, so the call is handled appro-

priately. Otherwise, SPs will continue to use PSTN

bridging for IP-to-IP inter-carrier calls. At this point, it

is not clear whether the mechanism to identify the


15/17


nature of an endpoint (i.e., PSTN or IP) would exist

outside the ENUM framework. Hence, as discussed

earlier, we recommend that a common directory of

telephone numbers and associated domain names

(e.g., carrier ENUM) be in place to support that

decision point. Such an infrastructure should be

restricted to SP use and would be inaccessible topublic Internet users.

This proposal takes advantage of the recom-

mended common infrastructure to help determine

whether a call terminates in the PSTN or in another

IMS domain and to route it accordingly.

Avoiding additional call setup delay. A net benefit of

determining the nature of the CdP endpoint is to avoid

the additional call setup delay, as defined in ITU-T

E.127 [14], which might occur in the PSTN when

bridging two IMS islands. For instance, for calls in the

PSTN, E.127 recommends an average call setup delayof no more than 3 seconds and 5 seconds, respectively,

for local and toll calls. The 95th percentiles are

6 seconds and 8 seconds, respectively.

Conclusions and Areas for Further Investigations

IMS network signaling peering is a very complex pro-

blem to tackle for the deployment of next-generation

IMS networks. Unlike the embedded base PSTN/PLMN,

where common databases and established routing prin-

ciples allow SPs to securely share call routing data and

identify one anothers signaling points, there are newchallenges facing the IMS SPs. First, SPs need to per-

form address resolution of users identifiers (e.g., SIP

URI) and other resources (e.g., call servers) at almost

every step during call setup. Second, the format of the

identifiers may vary depending on what service is being

initiated. Accordingly, the address resolution process

requires different mechanisms to identify the users and

their serving domains. Third, the nature of the infra-

structure between two SP networks impacts the peer-

ing process in that it influences the discovery of the

peering points for a given call. Last, SPs will create fed-erations and transit networks for network intercon-

nect, as achieving universal connectivity is an

unrealistic goal. Hence, the selection of what federa-

tion/transit network to use to reach a destination be-

comes an integral part of the signaling peering decision

process.

This paper discusses these new challenges and

proposes a high-level signaling process that identifies

key peering decision points and provides a compre-

hensive approach to solving them. Such an approach

is necessary for accelerating the deployment of IMS

networks and reducing the reliance on PSTN/PLMN

network for inter-carrier communications among IPendpoints.

Finally, it is clear that more detailed work is

needed to address some specific technical challenges

identified in this paper. However, in priority order,

the following areas are critical for further investiga-

tions. First, more work is needed to define the re-

quirements for a policy peering infrastructure in

support of intelligent selection of peering points in an

SP IMS network. This will invoke the PF in both the

originating and terminating IMS networks and apply

policy rules for the selection of the peering points.Second, a new routing algorithm for the selection of

federation/transit in a multi-transit/federation sce-

nario is needed. This will invoke the LF and PF in

both originating and terminating networks.

Acknowledgments

The author would like to acknowledge several

colleagues for sharing their insights on various aspects

of this work. In particular, he is grateful to Deirdre

Doherty, Mohamed El-Sayed, Igor Faynberg, Paul

Gagen, Vijay Gurbani, Volker Hilt, Markus Hofmann,

Vanita Katkar, Eunyoung Kim, Lyle Kipp, Humberto

La Roche, Tom Morawski, Bob Moul, Morgan Stern

and Carlos Urrutia-Valds.

*Trademarks

3GPP is a trademark of the European Telecommunica-

tions Standards Institute.

References[1] 3rd Generation Partnership Project,

Architectural Requirements, 3GPP TS 23.221,

June 2004,http://www.3gpp.org/ftp/

Specs/html-info/23221.htm.[2] 3rd Generation Partnership Project, IP

Multimedia Subsystem (IMS), Stage 2 (Release

7), 3GPP TS 23.228, v7.2.0, Dec. 2005,

http://www.3gpp.org/ftp/Specs/html-

info/23228.htm.

[3] G. Camarillo and M. A. Garcia-Martin, The 3G

IP Multimedia Subsystem (IMS): Merging the


16/17


Internet and the Cellular Worlds, 2nd ed., John

Wiley and Sons, Chichester, England, Hoboken,

NJ, 2006.

[4] G. Camarillo, A. B. Roach, J. Peterson, and

L. Ong, Integrated Services Digital Network

(ISDN) User Part (ISUP) to Session Initiation

Protocol (SIP) Mapping, IETF RFC 3398,

Dec. 2002,

http://www.apps.ietf.org/rfc/rfc3398.txt.

[5] R. Daniel and M. Mealling, Resolution of

Uniform Resource Identifiers Using the Domain

Name System, IETF RFC 2168, June 1997,


[6] European Telecommunications Standards

Institute, Interconnect and Routing Issues

Related to Numbering Naming and Addressing

(NN&A) for Next Generation Networks (NGNs),

DTR/TISPAN-04006-Tech, ETSI TR 184 006,

v0.0.6, Feb. 2006, http://www.etsi.org.

[7] P. Faltstrom and M. Mealling, The E.164 to

Uniform Resource Identifiers (URI) DynamicDelegation Discovery System (DDDS) Application

(ENUM), IETF RFC 3761, Apr. 2004,


[8] M. Foster, T. McGarry, and J. Yu, Number

Portability in the Global Switched Telephone

Network (GSTN): An Overview, IETF RFC

3482, Feb. 2003, http://www.apps.ietf.org/

rfc/rfc3482.txt.

[9] GSM Association, Inter-PLMN Backbone

Guidelines, Doc. IR.34, Revision 3.7, Apr. 2006.

[10] GSM Association, IMS Roaming and

Interworking Guidelines, Doc. IR.65, Revision

3.5, Aug. 2006.[11] A. Gulbrandsen, P. Vixie, and L. Esibov, A DNS

RR for Specifying the Location of Services

(DNS SRV), IETF RFC 2782, Feb. 2000,


[12] M. Haberler, M. Hammer, and O. Lendl, A

Federation Based VoIP Peering Architecture,

IETF Internet Draft, Sept. 2006,

http://www.ietf.org.

[13] International Telecommunication Union,

Telecommunication Standardization Sector,

The International Public Telecommunication

Numbering Plan, ITU-T Rec. E.164, May 1997,

http://www.itu.int.



Network Grade of Service Parameters and

Target Values for Circuit-Switched Services in

the Evolving ISDN, ITU-T Rec. E.721, May

1999, http://www.itu.int.



Resource and Admission Control Functions in

Next Generation Networks, ITU-T Rec. Y.2111,

Sept. 2006,http://www.itu.int.

[16] O. Lendl, Publishing SIP Peering Policy,

IETF Internet Draft, Dec. 2005,

http://www.ietf.org

.[17] O. Lendl, The Domain Policy DDDS

Application, IETF Internet Draft, Feb. 2006,


[18] R. Mahy, A Minimalist Approach to Direct

Peering, IETF Internet Draft, June 2006,


[19] M. Mealling, Dynamic Delegation Discovery

System (DDDS) Part Three: The Domain

Name System (DNS) Database, IETF RFC 3403,

Oct. 2002,http://www.apps.ietf.org/

rfc/rfc3403.txt.

[20] J.-F. Mule, SPEERMINT Requirements for SIP-

Based VoIP Interconnection, IETF InternetDraft, June 2006,http://www.ietf.org.

[21] R. Penno (ed.), SPEERMINT Peering

Architecture, IETF Internet Draft, Aug. 2006,


[22] J. Rosenberg and H. Schulzrinne, Session

Initiation Protocol (SIP): Locating SIP Servers,

IETF RFC 3263, June 2002, http://www.apps.

ietf.org/rfc/rfc3263.txt.

[23] J. Rosenberg, H. Schulzrinne, G. Camarillo,

A. Johnston, J. Peterson, R. Sparks, M. Handley,

and E. Schooler, SIP: Session Initiation

Protocol, IETF RFC 3261, June 2002,

http://www.apps.ietf.org/rfc/rfc3261.txt.[24] H. Schulzrinne, The tel URI for Telephone

Numbers, IETF RFC 3966, Dec. 2004,


(Manuscript approved August 2007)

JEAN-PHILIPPE JOSEPH is a member of technical staff in

the Advanced Network Planning and

Modeling group at Alcatel-Lucent in Murray

Hill, New Jersey. He holds a B.S. in

electronics engineering from La Facult des

Sciences de lUniversit dEtat dHati in

Port-au-Prince, and an M.S. degree in electrical

engineering from Polytechnic University of New York in

New York City. Mr. Josephs current research interests

include IMS-based architectures and solutions for

network evolution and service integration, IMS

signaling peering, network modeling, and

optimization.


17/17

Date post:	30-May-2018
Category:	Documents
Upload:	ol001
View:	221 times
Download:	0 times

IMS Network Signaling Peering: Challenges and Proposal

Documents