>THIS IS THE WAY

>THIS IS

White Paper

The packet interconnect opportunity for MSOs

Author: Peter Krautle, Senior Advisor, Voice and Multimedia Global MSO Solutions, Nortel

Abstract

Interconnection of the Multiple ServiceOperator (MSO) Voice over InternetProtocol (VoIP) network to other carriers’networks must be well planned andexecuted to ensure both that servicerevenue grows as quickly as possible andthat extraneous costs are driven out ofthe network.

Most cable operators are implementingTime Division Multiplexing (TDM)interconnections from their softswitchesto the Public Switched TelephoneNetwork (PSTN). This approach iswidely deployed and reliable, but hastwo shortcomings:

> Each Packet to TDM hop introducesa minimum of 20 milliseconds ofdelay due to encoding, echo cancella-tion, voice activity, de-jitter and IPdelay overhead. The delay budget for alocal or long-distance call can accom-modate this; however, it can be aproblem for cellular or internationalcalls which need a larger delay budget.

> Every off-network VoIP call drives theneed for capacity on media gateways,representing a significant cost elementfor the MSO.

Some MSOs are planning packet inter-connections into carrier networks foroff-network traffic to the PSTN, deliv-ering both technology advantages aswell as enabling new, cost-effective busi-ness arrangements. Specifically, packet-to-packet interconnection introducesminimal delay to the voice bearer pathconnection and does not require mediagateway capacity. The added advantage

of packet interconnection is the poten-tial to bypass the Inter-eXChange (IXC)network by leveraging the carrier’s IPbackbone to connect directly to localtandems. For some off-network calls,the PSTN can be completely avoidedwhen both an MSO and broadbandservice provider are using packet inter-connections into the same carrier network.In this scenario, the bearer path from aMedia Terminal Adapter (MTA) in anMSO network flows directly to anAnalog Terminal Adapter (ATA) in abroadband service provider network.

2

To be successful with packet intercon-nection, cable operators need solutionswhere:

> The MSO softswitches are capable ofSession Initiation Protocol (SIP) or SIPfor Telephony (SIP-T) inter-workingwith the carrier network

> The SIP/SIP-T standards on MSOsoftswitches aligns with the SIP/SIP-Timplementation on the selectedcarrier’s softswitch

> The selected carrier has good PSTNconnectivity into Rate Center and IXCtandems where cable systems targetedfor VoIP deployment are located

This paper will discuss all these elementsin greater depth and describe a method-ology for planning packet interconnec-tions between MSO and carrier networks.

About the author

Peter Krautle is currently Senior Advisorfor Nortel in New York, providingnetwork architecture support to MSOsglobally for voice and multimedia solu-tions. His 23-year technical and manage-ment career at Nortel and General Motorscovers numerous areas of InformationTechnology, Product Development,Systems Architectures and CustomerTechnology Solutions planning. His firstexposure to MSOs began in 1995 whenmanaging the development of a newcable modem for Nortel’s Cornerstonedata products. Peter holds a Bachelorsand Masters of Computer Science fromthe University of New Brunswick, andan executive MBA from Queen’sUniversity in Kingston, Ontario.

Acknowledgements

Many thanks to John Atkinson, XuewenLi, Brian Lindsay, Rob Wood, ElaineSmiles, Parviz Rashidi, AhsanuddinMohammed, Emily Fung, MauriceRomaniuk, Chuck Coleman, Jim

Cermak, Rick Walczak, Graeme Currie,Bob Cirillo and Jim Gelsomini for yoursupport. Special thanks to Roy Perry andTom Buttermore for your commitment.

Introduction

The traditional way to connect from thepublic PSTN to PacketCable-compliantsoftswitches is via TDM-based inter-machine trunks (IMTs) and TDMsignaling through the SS7 network.TDM handoffs to local and long-distance carriers for voice signaling andbearer path traffic are a mature approach,with well-defined interfaces and hand-offs between softswitches as well aslegacy TDM switches. However, thereare potential shortcomings to theapproach, including:

> Each packet to TDM conversionthrough a media gateway adds approx-imately 20 milliseconds1 of delay. Theadditive effort of these conversions canlead to voice quality issues on sometypes of calls (e.g., cellular, interna-tional long distance).

> Every TDM circuit outbound from a packet network drives the need forcapacity on a media gateway — asignificant element of cost in a soft-switching solution.

> TDM facilities for trunks and SS7signaling must be dedicated, andcannot be shared with other applica-tions. With packet interconnectionsfor voice, IP bandwidth not used byvoice can be leveraged by data applica-tions and improves the facilitiesutilization between MSO and carriernetworks.

> Packet inter-connectivity makes iteasier from a technical and regulatoryperspective for MSOs to hand off voicecalls between each other, bypassing thePSTN and changing the economicsfor interconnection costs.

Today’s early adopters of packet inter-connections are using SIP or SIP-T forcall signaling connectivity between theirown softswitches and application servers(e.g., voice mail server) as well as soft-switches located in carrier networks. Thestandards for SIP and SIP-T are still rela-tively new, and subject to interpretationby design teams. Furthermore, becausesome services do not map transparentlytoday with packet interconnections,there can be some minor behavioraldifferences between VoIP features usingTDM versus SIP signaling.

Although the benefits of packet inter-connection between softswitches andcarrier networks are substantial, imple-menting the solution requires a moti-vated MSO, recognition that upfrontplanning is required to minimize inter-operability issues, flexibility to adjustservice offerings based on current SIPimplementations, and strong collabora-tion between the MSO and vendors.

The planning of packet interconnectionsbetween MSO softswitches and carriernetworks requires the following:

> A motivated MSO who can bring thecarrier and vendors together to workthrough the interoperability problemsand inevitable roadblocks in a timelyfashion

> A certification/test environment toresolve standards interpretation andimplementation issues

This paper first begins by outlininggeneral TDM and packet interconnec-tion models between MSO and carriernetworks for softswitches, and thenaddresses the steps needed to plan forsuccessful packet interconnections.

1 Packet delay is dependent on packetization. If a 10-millisecond packetization rate is used, a minimum of 10-milliseconds encoding delay is introduced. However,other factors contributing to packetization delay such as echo cancellation, voice activity, de-jitter buffers and IP network delay also play a role. For the purposesof this paper, a 20-millisecond average packetization delay will be used for packet-to-TDM conversion.

3

Traditional TDM intercon-nections into the publicPSTN network

Figure 1 provides a simplified view oftraditional TDM connectivity for MSOPacketCable-compliant softswitchescommunicating with the Public SwitchedTelephone Network (PSTN). MSOplanning engineers must first work withtheir marketing groups to identify thecable systems where VoIP service will beoffered. These cable systems are thencorrelated to PSTN rate centers fordetermining local, intra-lata, inter-lata,911 PSAP and operator services tandems.The identified tandems may also beserviced by multiple carriers withdiffering pricing strategies for facilitiesand interconnections — therefore, ananalysis of circuit costs and the avail-ability of facilities is normally undertakento decide on final carriers to be used.Based on subscriber forecasts providedby the MSO’s marketing organization ona per-cable system basis, trunk circuitsare then engineered and ordered forcarrying off-net calls between the soft-switch media gateways and the PSTN.

The SS7 network is used betweensoftswitches and carrier voice switches tosignal incoming/outgoing call informa-tion such as the calling number of the

subscriber and the trunk that the callingswitch has used to reserve the telephonycall. The receiving switch also uses theSS7 network to request services infor-mation such as calling name (CNAM),local number portability (LNP) and toll-free (800/900) data from the PSTN. Atthe early stages of VoIP network deploy-ment, MSOs typically order a pair ofSS7 Access links (A-links) from theirsoftswitch to geographically diverseSignal Transfer Points (STPs) providedby an SS7 carrier.

Key advantages for MSOs using tradi-tional TDM interconnections intocarrier PSTN switches include:

> The TDM interfaces and connectivityinto the PSTN are well-defined fromboth a technical and regulatoryperspective. For example, all majorcarriers in the United States andCanada today have wholesale divisionsservicing facilities-based CompetitiveLocal Exchange Carriers (CLECs).Provided an MSO files as a CLEC,the process of ordering interconnec-tion circuits is straight-forward.

> Telecommunications engineers andoperations personnel are familiar withengineering and operating these typesof interconnections.

> Traditional TDM interconnectionsoffer the best opportunity for seamlessfeature transparency to MSO VoIPsubscribers. Packet interconnectionsbetween networks can introduce minordifferences to the behavior of somefeatures when compared to their usageon TDM switches.

There are also some shortcomings withusing traditional TDM interconnectionsinto carrier switches. From a technicalperspective, every analog-digital conver-sion of the bearer path by media gatewaysadds approximately 20 milliseconds to theend-end one-way delay budget requiredfor toll-quality VoIP conversations (typi-cally in the 150 to 180-millisecondrange). For North American calls thatoriginate and terminate on wirelineTDM telephony endpoints, this addedIP/PSTN conversion delay is normallynot an issue. However, the delay budgetbecomes more problematic with a callforwarded multiple times as well assome cellular and international calls.

From a commercial perspective, thereare PSTN trunk and SS7 facility costs,reciprocal costs for terminating calls,and the cost of intra- and inter-LATAlong distance costs associated with MSOsconnecting their softswitches usingclassical PSTN TDM approaches. TDMtrunks to the PSTN are also dedicatedcircuits, and cannot be shared with othernetwork applications (e.g., high-speedInternet) when the trunks are under-utilized. There are also network servicecosts such as per-call query charges tothe Local Number Portability (LNP) andCalling Name (CNAM) databases. Withmany MSOs entering the market with a bundled VoIP offering that includescalling name display and North Americanlong distance for a fixed monthlycharge, long distance and CNAM querycharges increase significantly as theMSO VoIP subscriber base grows. Thesuccess of MSOs who have launchedresidential VoIP service in attractingsubscribers is driving the need for alter-native connections to PSTN softswitches.

Figure 1. Traditional connectivity to public voice carriers from softswitches

LIDB TollfreeLNPCNAM

SS7SS7

SS7

SS7

SS7

IP voice bearer path

TDM voice bearer path

SS7 inter-switch signaling

MSO network Carrier network

Local tandems(rate centers)

911LD/IXC

OS

SS7

IP

TGCP

ISUP

ISUP

ISUP/MF

ISUP/MF

CMS

MGNCS NCS

MTA MTA

CMTS CMTS

HFC

4

In a rapidly-growing VoIP network usingTDM trunk interconnects, some MSOshave deployed multiple softswitches,each with traditional TDM interconnec-tions into the PSTN (see Figure 2).Because of the lack of early availability ofinter-call server signaling via SIP by somemanufacturers, an MSO ‘on-network’call from an MTA on one softswitch(CMSA) to another softswitch (CMSB)must be hair-pinned through the mediagateway. Depending on the sophisticationand feature richness of the translationsand routing algorithms within the soft-switch, the IP bearer path for this callmay actually traverse a PSTN tandemswitch, incurring potential reciprocal orlong-distance charges. Because thebearer path between this MSO on-netto on-net call traverses two media gate-ways, the end-to-end delay budget forthis call has increased by 40 milliseconds,and may present voice quality issues ifone of the MTAs has forwarded theirVoIP phone to a cell phone for incomingout-of-region cellular or internationalcalls.

Finally, without SIP signaling betweenMSO softswitches enabled, call signalingmust occur through the SS7 network.As the VoIP subscriber base increases,multiple softswitches will be deployed,

with each softswitch requiring redundantSS7 links and linksets. As these SS7costs continue to increase, the MSOmust either move to SIP signalingbetween softswitches, or explore use ofdeploying a standalone Signaling TransferPoint (STP) in their network. The STPaggregates SS7 traffic from MSOsoftswitches onto an external set of T1s with multiple linksets to the publicSS7 network.

The emergence of SIP-basedpacket interconnections onsoftswitches and deploymentmodels

SIP-based packet interconnections havebeen introduced on most manufacturers’softswitches for signaling calls betweencall servers — some as early as 2001.Early adopters of SIP packet intercon-nections were implemented using draftversions of the IETF SIP standards. Theinitial requirement placed upon earlyadopters of SIP packet interconnectionswas to solve the problem of signalingcalls to other softswitches or applicationservers within the MSO network withouthaving the IP bearer path trombonethrough an IP/TDM Media Gateway.As SIP trunk signaling began to maturefor voice, manufacturers with pre-stan-

dards versions of SIP implementedprograms to align with the standardizedversions of SIP, starting with RFC 3261in late 2002. Other softswitch manufac-turers who implemented SIP packetinterconnections later worked directlyfrom the standards-track IETF RFCs.

Public carriers who were early to marketwith SIP line and trunk services alsoimplemented parts of their networkusing pre-standards versions of SIP, andhave been upgrading their solutionthrough a combination of plannedprograms and customer opportunities.

The advantages of SIP-based packetinterconnections on MSO softswitchesare significant:

> Ability for a softswitch to signal callsto another softswitch without requiringthe public SS7 network or using aSignaling Transfer Point (STP). UsingFigure 3, if CMS(A) and CMS(B) areusing SIP signaling between eachother, the bearer path can be kept on-network with an RTP stream beingestablished directly between the twoMTAs without going through themedia gateways and the PSTN.

> Greater flexibility in forming inter-connection agreements with carriersand other MSOs that allows PSTNmedia gateway connectivity to occuroutside the MSO’s initial network.This also facilitates VoIP bearer pathexchange between MSOs, and reducesthe purchase of PSTN services fromcompetitors.

> Ability to manage the end-end delaybudget more effectively as more trafficis kept on-network and not forwardedto the PSTN.

> As MSO VoIP networks grow, SIP-based packet interconnections canhelp reduce the expense in mediagateway ports.

Figure 2. Bearer-path flow for on-net to on-net calls for some MSOs withmultiple softswitches

SS7

IP voice bearer path

TDM voice bearer path

SS7 inter-switch signaling

MSO network Carrier network

Local tandem

IP

CMS(A)NCS NCS

MTA MTA

CMTS CMTS

HFC

MTA MTA

NCS NCS

HFC

CMTS CMTS

CMS(B)

MG-A

MG-B

5

Figure 3 represents the simplest form of SIP packet interconnect programsbetween MSO softswitches which lever-ages the IP core backbone used for high-speed data services. Dedicated bandwidthfor TDM voice trunks between Class 5switches or softswitches that use the SS7network and media gateways to hairpincalls is replaced by an RTP/IP bearerpath stream between MTAs or mediagateways that are controlled by separatesoftswitches. The IP network is engi-neered to prioritize VoIP traffic overhigh-speed data traffic, and unusedVoIP bandwidth can be used by otherlower priority applications.

Softswitches should support both SIPsignaling for packet interconnectionsbetween MSO softswitches as well asSS7 connectivity for calls destined forthe PSTN. In Figure 3, both softswitchesCMS(A) and CMS(B) have SS7 links tothe PSTN as well as SIP signaling tosupport packet interconnections. Thisflexibility allows an MSO to leverage itscore IP network to direct off-net calls tothe nearest media gateway supporting asubscriber within a specific rate center.For example, a subscriber controlled byCMS(B) and located in LATA2 placingan off-net call to a subscriber located inLATA1 can configure its routing andtranslations tables so that the voicebearer path from the subscriber’s MTAcan be directed to media gateway A(MG-A) controlled by CMS(A). Thisapproach allows an MSO to control itslong-distance charges by leveraging itsIP backbone network to bypass theinterconnect exchange carriers (IXCs)and local carriers for a percentage oflong-distance calls and direct these callsdirectly to the local tandems in eachLATA or major rate center.

Figure 4 represents two MSO softswitchesin a local ‘Class 5’ and long-distance‘Class 4’ configuration. In this configu-ration, all local lines serviced from theHFC access network are connected tothe Class 5 softswitch [CMS(A)]. Aswell, connectivity to tandems for local

off-network calls is also supported fromthe Class 5 softswitch. The Class 5routing and translations tables areconfigured to understand which numbersare local or ported in, and which off-network calls can be forwarded to localtandems. All other calls traditionallyconsidered as long-distance are forwardedto the Class 4 softswitch [via SIPsignaling from CMS(A) to CMS(B)] for further treatment.

The MSO should design their VoIPnetwork to place media gateways inmajor LATAs where long distance trafficis being generated and where there isaffordable access to IP transport. Forexample, an MSO may determine thatthere is significant long-distance trafficto Chicago from its cable systems inNashville and that the MSO already hasreliable IP transport for Internet peeringbetween Nashville and Chicago. By

Figure 3. Flow of bearer path for MSO on-net and off-net calls when SIPsignaling is used between softswitches

Figure 4. Softswitches using SIP for inter-CMS communications in a Class 4/5 configuration

SS7

IP voice bearer path on-net to on-netIP voice bearer path on-net to off-netSIP inter-switch signalingSS7 inter-switch signaling

MSO network Carrier network

Local tandemrate center

LATA 1

IP

CMS(A)NCS NCS

MTA MTA

CMTS CMTS

HFC

MTA MTA

NCS NCS

HFC

CMTS CMTS

CMS(B)

MG-A

MG-B

SIP

Local tandemrate center

LATA 2

SS7

IP voice bearer path

SIP inter-switch signaling

SS7 inter-switch signaling

MSO network Carrier network

Intra-LATAtandems

IP

CMS(A)

HFC

MTA MTA

NCS NCS

CMTS CMTS

CMS(B)

Local

Class 5 SIP

Longdistance

Class 4

LD/IXCtandems

Local tandem 1

Local tandem 2

6

placing a media gateway in Chicagoconnected to the Class 4 softswitch, thenetwork can be engineered so that off-netcalls between Nashville VoIP subscribersand Chicago TDM voice subscribers arecarried over its internal IP transportnetwork, therefore bypassing the Inter-exchange Carrier (IXC) and reducinglong-distance charges.

The MSO may also be legislated tooffer their VoIP subscribers a choice oflong-distance providers. In the Class 4/5softswitch configuration, trunks to eachIXC carrier would be connected to theClass 4 softswitch, with the CarrierInterexchange Code (CIC) for thesubscriber specified as part of the lineprofile on the Class 5 softswitch. Boththe Class 4 and 5 softswitches must alsohave translations and routing enginesthat can map CIC codes to lines andthe correct long-distance trunks to theselected Interexchange Carrier.

If the MSO deploys both Class 4 and 5softswitches and develops several agree-ments with long distance providers tocontain costs based on time-of-day use,the Class 4 softswitch with its least-costrouting functionality can be configuredto use the least-cost long-distance trunksbased on call attributes such as time-of-day and class of service.

Some MSOs have implemented or areconsidering a packet interconnect agree-ment with carriers that possess thefollowing attributes:

> The MSO and carrier define a commonmeet-point for the exchange of all on-net to off-net traffic through facilitiesthat are normally physically co-located.

> The MSO softswitch is ordering facili-ties to exactly one location — thecarrier end of the meet-point.

> The carrier is responsible for engineer-ing all trunks from their side of themeet-point to the rate center tandemsfor each cable system serviced by theMSO softswitch. As well, appropriatetrunk group connections to IXC, 911and operator services tandems mustalso be engineered.

> The carrier is also responsible forassigning new telephone numbers(TNs) to the MSO softswitch, andmanaging local number portabilityrequests on the MSO’s behalf.

> In some cases, the MSO does not wishto file CLEC status with the appro-priate regulatory bodies, but ratherdeliver VoIP services under the auspicesof the carrier.

A common name given to the carrier forthis type of interconnect model is theVoice Service Provider (VSP). Figure 5illustrates the TDM-based Voice ServiceProvider for MSOs. The carrier and theMSO agree on the meet-point interface,and then based on the MSO’s VoIPexpected growth in each serving cablesystem, the sizing of the meet-pointfacilities is engineered (e.g., DS-3, OC-3,OC-12, OC-48). These meet-pointfacilities are then connected to mediagateways on the MSO side of thenetwork, and either media gateways orTDM switches in the carrier’s network.The carrier then engineers trunk groupsfrom the meet-point to the local tandemsin each rate center where cable systemsare located. Facilities are also engineeredto IXC tandems for long-distance aswell as operator services and 911 trunks.These facilities are mapped to trunks onthe carrier side and then replicated onthe MSO softswitch in its translationtables.

The advantages of implementing aTDM-based VSP model for MSOsinclude:

> Faster time to market for turning up asoftswitch into deployment, particu-larly if the selected carrier already hasexisting underutilized trunk facilitiesinto tandem PSTN switches. Orderingand turning up trunk facilities intoPSTN tandem facilities can takeconsiderable time.

> Well-defined TDM interfaces betweenthe MSO and carrier network, allowingcarriers to re-use existing infrastructure(people, tools) to operate and trouble-shoot the network.

> The carrier can provide the MSO withadditional interconnection servicessuch as assistance with regulatoryfilings, allocation of new telephonenumbers and Local Number Portability.

Figure 5. TDM-based Voice Service Provider model for MSOs — off-net call

SS7

IP voice bearer path

TDM voice bearer path

SS7 inter-switch signaling

MSO network Carrier network

IP

MSOCMS

HFC

MTA MTA

NCS NCS

CMTS CMTS

MG

Meet-Point

CNAMLIDB

LocalCarrierCMS

IP

HFC

MTA MTA

NCS NCS

CMTS CMTS

Tollfree LNP

LD/IXC

911

OS

7

MSOs have also encountered shortcom-ings in using the TDM-based VoiceService Provider approach in connectingtheir softswitches to the PSTN. Therepeated transition of converting VoIPpackets to TDM and back again adds tothe delay budget, and contributes tooverall voice quality degradation. In theFigure 5 example, the two media gate-ways at either end of the meet-point canadd 40 milliseconds to the delay budget.Re-engineering of trunk group sizes asthe network grows is expensive and isstatically engineered, unlike the IPnetwork where the cost of adding band-width to the network and movingendpoints is lower. Finally, the cost oftrunk ports on the IP/TDM mediagateways is a significant component ofthe overall end-to-end VoIP solution cost.

Figure 6 provides a high-level view of anIP-based Voice Service Provider modelthat is implemented by some MSOs.The major differences between theTDM and IP Voice Service Providerinterconnect models are:

> The elimination of IP/PSTN gatewaysat either end of the interconnectionmeet-point between the carrier andMSO network

> The removal of the SS7 TDM linkbetween the MSO and PSTN SS7network

Signaling of calls between the MSO andcarrier softswitches is now done via SIP,and allows the bearer path for VoIP callsdestined for the PSTN to go directlybetween the MSO MTAs and the MediaGateways controlled by the carriernetwork. The potential signal degrada-tion caused by repeated transitions ofthe voice bearer path between IP andTDM is reduced, and media gatewaycosts are eliminated at either end of theinterconnection meet-point. Because theinterconnection meet-point is IP, the

MSO and carrier can re-use theirexisting IP backbone infrastructure andmanage bandwidth between voice anddata more efficiently. Finally, with theSS7 link no longer required between theMSO softswitch and carrier network, thepublic filing requirements for an MSOoffering VoIP service are diminished. Inessence, the MSO’s softswitch may beviewed as an extension of the carrier’snetwork from a regulatory perspective,with PSTN entities such as telephonenumbers, SS7 point codes and CommonLanguage Location Identifier (CLLI)codes owned by the carrier.2

As carriers and MSOs begin workingwith IP-based Voice Service Providerinterconnection models and SIP signaling,issues such as security, NAT/firewalltraversal, topology hiding, call admissioncontrol handling and endpoint inter-operability must be addressed. Each MSOand carrier solves these issues in a slightlydifferent fashion, including some of thefollowing approaches:

> Introduction of border gateway func-tionality where the softswitch incorpo-rates NAT/firewall and topology hidingcapability for the SIP signaling betweensoftswitches to maintain call control.A separate media portal is deployed todo border control for the RTP bearerpath stream. The softswitch alsoexchanges call state information withthe RTP media portal and gathers callstatistics.

> A session border controller, whichintegrates signaling and bearer pathborder gateway functionality into thesame platform.

> Use of routers, firewalls, intrusiondetection devices and network addresstranslation solutions to protect theedge of the MSO network and resolveconflicts in private address spaces.

Figure 6. IP-based Voice Service Provider model for MSOs — off-net call

2 For completeness, some MSOs have chosen not to operate their own voice switch, but outsource this capability to a carrier — this model is sometimes called ahosted Voice over Telephony solution. The TDM or VoIP traffic from the MSO network is passed to the carrier network, which then operates the voice switchinginfrastructure on behalf of the MSO. In the hosted Voice over Telephony model, a voice switch is either dedicated to an MSO, or shared with multiple MSOs.

SS7

IP voice bearer path

TDM voice bearer path

SS7 inter-switch signaling

MSO network Carrier network

IP

MSOCMS

HFC

MTA MTA

NCS NCS

CMTS CMTSIP Meet-Point

CNAM

LIDB

Local

CarrierCMS

IP

HFC

MTA MTA

NCS NCS

CMTS CMTS

TollfreeLNP

LD/IXC

911

OS

8

Figure 7 illustrates the IP-based VoiceService Provider model with bordercontrol functionality that protects boththe carrier and MSO network. Each ofthe methodologies listed above areappropriate in specific circumstances forsecuring the network edge, translatingIP addresses, hiding network topology,etc. Figure 7 also illustrates the SIPsignaling path from an MSO softswitchto a SIP proxy server in the carriernetwork. Some carriers only permit SIPsignaling into their network via a SIPproxy server that acts as a back-to-backuser agent, and forwards the signaling tothe correct softswitch.

Planning for SIP interconnec-tions and IP peering betweenVoIP networks

Packet interconnections between MSOand carrier softswitches require upfrontplanning and inter-working characteri-zation for some of the following reasons:

> The SIP implementation on soft-switches for packet interconnections isstill early in the technology adoptionphase for most MSOs and carriers.

Interoperability testing is required tocharacterize services and call behaviorsbetween softswitches to ascertainstandards are being interpreted andimplemented in a similar fashion.

> Features work transparently betweenMSO and carrier softswitches.

In the late 1980s, a number of Informa-tion Technology organizations forcorporations who were implementingLAN-based networks tightly restrictedthe use of Ethernet cards as well asTCP/IP drivers to models that had beentested and certified in their interoper-ability labs. Because Ethernet was stillrelatively new and TCP/IP vendorsimplemented slightly different versionsof the standards3, network administra-tors discovered that minor card/protocolstack incompatibilities or behaviorscreated network outages (broadcaststorms, babbling cards, etc.). To mini-mize the number of network troubleincidents, Ethernet cards and driverswere certified in a lab environment toguarantee reliability and availability.Today, the maturity of Ethernet hard-ware and TCP/IP drivers has reached

the point where consumers can purchasethese components commercially, andplug them into public and enterprisenetworks with confidence that they willoperate reliably.

Like the Ethernet market segment in the1980s, performing IP peering betweenMSO and VoIP networks using SIPsignaling is still an emerging intercon-nection model and inherits similar inter-operability issues:

> With a suite of SIP standards nowdefined, softswitch vendors are eitherimplementing or upgrading their SIPsignaling capability between softswitchesand are beginning interoperabilitytesting. During the due diligence andplanning phase for interoperabilityexecution, some softswitch vendorshave implemented different subsets ofthe SIP standards, or are at differentversions for the same standards.

> For PacketCable VoIP functionality,there are minor differences in featurebehavior when using SIP signalingand IP peering between MSO andcarrier networks for VoIP traffic.

> Carrier VoIP softswitches do notadhere to the PacketCable CMSSstandards today for inter-softswitchcommunications. Therefore, earlyadopters of IP peering between MSOand carrier softswitches are adheringto the carriers’ implementation of SIP,and leveraging their breadth of TDMinterconnections into the PSTN.

> Border control to secure MSO andcarrier networks when doing packetinterconnections is also an emergingtechnology solution. Depending onthe type of border control implemen-tation, interoperability testing is alsoneeded to characterize how callsbehave from a service, reliability andavailability perspective.

Figure 7. IP-based Voice Service Provider model with border control —off-net call

3 A typical problem in the 1980s was one TCP/IP vendor implementing IETF standards A, B, C and D, while another TCP/IP vendor implemented standards B,C, D and E.

SS7

IP voice bearer path

SIP inter-switch signaling

SS7 inter-switch signaling

MSO network Carrier network

IP

MSOCMS

HFC

MTA MTA

NCS NCS

CMTS CMTS IP Meet-Point

CNAM

LIDB

Local

CarrierCMS

IP

HFC

MTA MTA

NCS NCS

CMTS CMTS

TollfreeLNP

LD/IXC

911

OS

CarrierSIP proxy

Bordercontrol

Bordercontrol

The first step in planning for packetinterconnections is for an MSO to definetheir scope of planned feature offerings,both today and 12 to 24 months out(Figure 8). This input is important tohelp carriers and softswitch manufacturersmap these capabilities to call flows usingpacket interconnections, identify areaswhere PSTN services are required (e.g.,Calling Name, Calling Cards, T.38 Fax),and map these call flows to the appro-priate SIP standards. As well, the callflows are also important to understandhow specific features will be handledwhen a call traverses between the MSOand carrier softswitch (e.g. T.38).

The MSO will then request that theappropriate softswitch vendors conductan analysis of packet interconnect inter-operability based on the current andfuture features, and report back onpossible feature transparency issues.Some of the questions that arise duringthis analysis include:

> Will native SIP (RFC 3261) or Trans-parent SIP (RFC 3372) be used forcall signaling between softswitches?

> How will operator and 911 services behandled?

> Will the Layer 3 protocol for SIPsignaling be based on a reliable Trans-port Control Protocol (TCP) orUnidirectional Datagram Protocol(UDP)?

The first question addresses the seamlessbehavior of features on an MSO soft-switch versus the same features on aTDM switch, and how advanced networkservices information gets exchangedbetween MSO and carrier softswitches.To understand this point, some briefbackground regarding SS7 high-levelsignaling principals in a TDM world is inorder. There are two primary messagetypes used by SS7 to exchange informa-tion between softswitches:

> ISDN supplemental part (ISUP) —Protocol used in the SS7 network tosignal incoming and outgoing callsbetween switches as well as the trunkused to connect/disconnect the call.

> Transaction Capabilities ApplicationPart (TCAP) — The protocol used inthe SS7 network for sending databasequeries (e.g., CNAM) to a ServiceControl Point (SCP).

In the PacketCable TDM model, if asubscriber on a TDM switch places acall to a VoIP subscriber on an MSOsoftswitch with calling name displayactivated, SS7 ISUP messages will bepassed between the TDM switch andsoftswitch. The SS7 message exchangesignals that there is an incoming call aswell as the trunk that has been reservedfor the bearer path between the two voiceswitches. Before the VoIP subscriber’sphone is notified to activate ringing onthe phone, the MSO softswitch mustfirst issue a TCAP message that queriesthe CNAM database. When the callingname information is returned, the infor-mation is passed to the MTA along withthe signal to activate ringing on thephone for the incoming call.

The decision of whether to use SIP(RFC 3261) versus SIP for Telephony(RFC 3372) for packet interconnectionbetween MSOs and carriers for VoIP isprimarily based on two determinants —the ability of the softswitches to supportone or both protocols, and the degree offeature transparency expected by theMSO (Figure 9). With SIP for Telephony(SIP-T) signaling, the SIP headers are

9

Figure 9. SIP (RFC 3261) versus SIP-T (RFC 3372) signaling betweensoftswitches for packet interconnect

Phase 1Basic residential

features

• Single line VoIP

• Calling Number and Name

• Call forward

• 3-way Calling

• Call Return

• Call Waiting

• Anonymous Call Rejection

• Call Return

• Local Number Portability

• Voicemail

Phase 2Enhanced residential

features

• Multi-line MTA support

• Teen service—Local—Out-of-area

• Call blocking—International—1-900

• Selective Call Acceptance

• Selective Call Rejection

• Long-distance Equal Access

• SIP hard/soft endpoints

• Videophones

• Integrated multimedia

Phase 3Commercial features

• Calling cards

• Prepaid cards

• Very small business—Serviced by cable modem

or Multi-port MTA—Multi-line hunting—Centrex customer groups—T.38 fax support

• Enterprise—Fiber-fed—Centrex/IP

• Business multimedia

SS7

CMS(A)

SIP

CMS(B)

SS7

PacketCableTDM interconnect

Packet interconnectusing SIP

IP

TDM

IP

TDM

ISUP

ISUPTCAP

TCAP

Inter-switch signaling• Call connect/disconnect (ISUP)• SS7 database queries (TCAP)

Packet HDR SIP Header Payload

Inter-switch signaling• Call connect/disconnect (ISUP)• SS7 database queries (TCAP)

Packet HDR SIP Header Payload

SIP — for Telephony (RFC 3372 SIP-T)

SIP — (RFC 3261)

Figure 8. Feature planning example for packet interconnections

10

used only for establishing a signalingsession between the MSO and carriersoftswitch endpoints. The SS7 payloadis encapsulated entirely within a SIPheader when transported between soft-switches, with the receiving softswitchtypically stripping off the SIP headerand passing the SS7 payload untouchedto its SS7 signaling stack. The SS7payload can then be decomposed appro-priately by the receiving softswitch. Theadvantage of this approach is that seam-less feature transparency with traditionalTDM switches can be achieved.

If SIP signaling is used (RFC 3261), theSS7 payload is decomposed by eachsoftswitch and mapped into SIP headers(RFC 3398). Some mappings forspecialized services such as operatorhold, operator ringback and busy lineverification are still in draft status withinthe IETF, with slight differences inimplementation between each softswitchvendor. These operator and 911 servicefeatures are typically supported over MFtrunks — unless the SS7 message formatis reconstructed at the carrier softswitchside exactly, the ability to support thisfunctionality is problematic. Whetherthese operator or 911 features arerequired by today’s modern operatorservices or 911 response centers4 is opento discussion, as the feature set wascreated over 25 years ago when few tele-phones had displays and there was littlecapability for hard or soft call logs. Iffeature transparency for operator servicesand 911 features is a significant issue,the MSO can deploy a media gatewayand direct SS7 connectivity for emer-gency support traffic while using SIPpacket interconnections for all other calls.

The SIP versus SIP-T differences arealso important to understand when aTCAP QUERY is issued to retrievecalling name information from the SS7network. Using the network topologyon the right side of Figure 9, when

CMS(A) receives an off-net call, aTCAP QUERY request is issued toCMS(B) that retrieves the calling nameinformation for the call originator. IfSIP-T signaling is used betweensoftswitches, then the TCAP QUERYinformation from CMS(A) is insertedunchanged within the payload of theSIP signaling packet to CMS(B).CMS(B) receives the TCAP QUERYpayload from CMS(A), forwards therequest to the SS7 network, retrieves theresponse and copies the responseunchanged into the payload of the SIPresponse packet back to CMS(A).CMS(A) then takes the calling nameinformation from the packet payloadand forwards to the called subscriber fordisplay on their phone. In effect, theTCAP QUERY request from CMS(A)(which has no direct connectivity to theSS7 network) is tunneled to CMS(B),who then strips away the SIP headersand forwards to the SS7 network.

Using the same Figure 9 example andSIP signaling (RFC 3261), the TCAPQUERY fields for calling name displayare mapped (via RFC 3398) to the SIPheader by CMS(A) before being

forwarded to CMS(B). CMS(B) mustthen rebuild the TCAP QUERY requestand forward to the SS7 to obtain thecalling name information for the origi-nating subscriber. CMS(B) then mustproxy the calling name information viathe appropriate field in the SIP headerwhen signaling the response back toCMS(A).

As MSOs expand their VoIP productofferings to service business subscribers,there may also be some feature compati-bility issues when native SIP signalingfor packet interconnections (e.g.,Centrex/IP endpoint from an MSOsoftswitch communicating with a SIPendpoint serviced from a feature serverconnected to a carrier softswitch). Byidentifying the features and working thecall flows, many of the potential incom-patibilities can be identified andaddressed during interoperabilitytesting.

Figure 10. PacketCable CMSS in early packet interconnect deployments

SS7

CMSS inter-switch signaling

SIP inter-switch signaling

SS7 signaling

MSO network Carrier network

MSO A

CMS(A)

HFC

MTA MTA

NCS NCS

CMTS CMTS

CNAM

LIDB

Local

CarrierCMS

IP

HFC

MTA MTA

NCS NCS

CMTS CMTS

TollfreeLNP

LD/IXC

911

OS

CMS(B)

MSO B

4 In the United States, 911 response centers are also called Public Service Access Points (PSAPs).

11

Strong commitment by MSOs to imple-ment packet interconnections withcarriers helps bring together allconstituents (MSO, carrier, softswitchvendors) in working through the poten-tial incompatibility issues, building andexecuting a comprehensive interoper-ability test plan, and then deploying thesolution in a production network.

PacketCable CMS to CMS Signaling(CMSS) is a profile of SIP and has beendesigned for intra- and well as inter-MSO signaling between softswitches.CMSS also has awareness of eventmessage and PacketCable Legal Interceptfunctionality. All carrier softswitcheshave their own SIP profiles, and do notsupport PacketCable event messages andLegal Intercept architectures today.Therefore, MSO softswitches will needto support individual carrier SIP imple-mentations short-term in order toimplement packet interconnections withthe PSTN. MSOs with multiplesoftswitches in their network or wishingto use packet interconnections withother MSOs is the expected area whereearly implementations of CMSS will bedeployed (Figure 10).

Conclusions

Packet interconnection between MSOsoftswitches and carriers is an emergingmarket segment, but represents thefuture direction of where voice andmultimedia networks are headed.Although TDM connections to thePSTN will remain in place for manyyears, the MSO movement to packetinterconnections will continue to growin popularity for the following reasons:

> More efficient use of voice and dataapplications that runs on a convergedIP network infrastructure.

> Reducing the frequency of Packet toTDM bearer path conversions (~20milliseconds) through media gatewaysrelieves pressure on the VoIP delaybudget, and improves overall voicequality.

> MSOs launching voice networks maybe able to get to market earlier withpacket interconnections into carriernetworks. The facilities efforts andregulatory skillsets required to turn up a network may be born by thecarrier, allowing MSOs to placegreater attention on growing theirVoIP subscriber base.

> Packet interconnection offers a greateropportunity to avoid PSTN accessand long transit costs — e.g.,bypassing the PSTN for VoIP callsbetween MSO networks.

Like the emerging Ethernet marketsegment of the late 1980s, many of theinteroperability issues associated withpacket interconnections today aretemporal and will become less of aconcern over the next several years asSIP signaling and interoperability withother SIP, NCS, Media Gateway,Integrated Access Devices and analogterminal adapters improves. ThoseMSOs that are committed to usingpacket interconnections, work collabora-tively with carriers and vendors, anddrive for high (but not complete) servicetransparency will be the first to enjoythe benefits.

The short-term issues for early adoptersof packet interconnections with carriersinclude the following:

> Security and IP address managementof MSO networks at the edge needs tobe well thought through. A number ofoptions are available to solve thisproblem including firewalls, intrusiondetection devices and other bordercontrol mechanisms (e.g., sessionborder controller).

> Interoperability of MTAs and otherdevices in the MSO network needs tobe characterized with media gatewaysresident in the carrier network. Itshould also be noted that these mediagateways may not be PacketCable-compliant.

> Other broadband service providersmay also be using packet interconnec-tions with carriers; therefore, thebearer path for their endpoints (e.g.,ATAs) may be communicating directlywith MTAs in the MSO network.This interoperability should be charac-terized.

> There may be minor feature behav-ioral differences versus the TDMswitching environment when usingpacket interconnections betweensoftswitches, particularly for operatorand 911 services. Those MSOs whorequire complete feature transparencyfor operator and 911 services mayelect to deploy a media gateway forthese services while using packet inter-connection for all other traffic.

Finally, the emergence of packet inter-connections between MSO and carriersoftswitches does not eliminate the needfor IP/PSTN media gateways — TDMswitches will continue to operate intoday’s public networks for the foresee-able future. However, the increased useof packet interconnections by MSOswill shift the ownership of media gate-ways from MSO networks and towardscarriers.

Nortel is a recognized leader in delivering communications capabilities that enhance the human experience, ignite and power global commerce, and secure and protect theworld’s most critical information. Serving both service provider and enterprise customers,Nortel delivers innovative technology solutions encompassing end-to-end broadband,Voice over IP, multimedia services and applications, and wireless broadband designed tohelp people solve the world’s greatest challenges. Nortel does business in more than 150countries. For more information, visit Nortel on the Web at www.nortel.com.

For more information, contact your Nortel representative, or call 1-800-4 NORTEL or 1-800-466-7835 from anywhere in North America.

This is the Way. This is Nortel, Nortel, the Nortel logo and the Globemark are trademarksof Nortel Networks. All other trademarks are the property of their owners.

Copyright © 2005 Nortel Networks. All rights reserved. Information in this document issubject to change without notice. Nortel assumes no responsibility for any errors thatmay appear in this document.

N N 1 1 3 8 6 0 - 1 1 2 8 0 5

In the United States:Nortel 35 Davis DriveResearch Triangle Park, NC 27709 USA

In Canada:Nortel 8200 Dixie Road, Suite 100Brampton, Ontario L6T 5P6 Canada

In Caribbean and Latin America:Nortel 1500 Concorde TerraceSunrise, FL 33323 USA

In Europe:Nortel Maidenhead Office Park, Westacott WayMaidenhead Berkshire SL6 3QH UKPhone: 00800 8008 9009 or+44 (0) 870-907-9009

In Asia Pacific:Nortel Nortel Networks Centre1 Innovation DriveMacquarie University Research ParkMacquarie Park NSW 2109 AustraliaTel: +61 2 8870 5000

In Greater China:Nortel Sun Dong An Plaza138 Wang Fu Jing StreetBeijing 100006, ChinaPhone: (86) 10 6510 8000