Presentation on theme: "NANC Change Order 400 Joint FoN/LNPA WG Meeting April 14, 2005 Tom McGarry NeuStar, Inc."— Presentation transcript:
NANC Change Order 400 Joint FoN/LNPA WG Meeting April 14, 2005 Tom McGarry NeuStar, Inc.
2 Overview LNP Regulatory Framework LNP Background Need for URI Routing Data for LNP NANC 400 Considerations Summary Acronym List
3 LNP Regulatory Framework In its policies and regulations the FCC has authorized NANC/LNPA WG to approve all NPAC changes and the LLC to manage implementation of these changes –In the Second LNP Order the FCC adopted NANCs recommendation that NANC/LNPA WG be authorized: to approve or disapprove all [NPAC/SMS] changes, and that each respective regional LLC manage implementation of these changes with its respective [LNPA]. –The FCC also said: each LLC is the entity with the greatest expertise regarding the structure and operation of the database for its region and that, without LLC oversight of database system enhancements and other modifications, the LLCs expertise would be wasted, running, the risk that necessary modifications to the database system may be delayed.
4 LNP Regulatory Framework NANC 400 is consistent with the FCC mandated role of the NPAC –The First LNP Order defines service provider portability as: the ability of users of telecommunications services to retain, at the same location, existing telecommunications numbers without impairment of quality,reliability, or convenience when switching from one telecommunications carrier to another. –And goes on to say that the NANC (LNPA WG) should determine the information necessary to provide number portability: NANC should determine the specific information necessary to provide number portability. –In the Second LNP Order the FCC says that NPAC users must be carriers or their agents providing billing, routing and/or rating functions and: The above criteria limits NPAC access to those with an operational need for NPAC service in order to provide local number portability.
5 LNP Background Examples of fields used to perform routing, rating, and billing functions: Location Routing Number (LRN) –Address of a terminating end office switch used to route calls to ported and pooled TNs –LRN was a new way to perform routing for geographic telephone numbers when it was implemented in the late-90s Destination Point Code / Subsystem Number (DPC/SSN) –Address for an SS7 node and application –When LNP was implemented the DPC/SSN for CLASS, CNAM, LIDB, and ISVM were added for all ported (and eventually pooled) TNs –Prior to initiating one of these SS7 transactions (e.g., CNAM dip) the SS7 network performed an LNP dip to find the correct DPC/SSN –The industry could have decided to use the LRN or SPID of the TN to approximate the DPC/SSNs for these services, but they chose not to –Provisioning the DPC/SSN for each ported TN provides greater flexibility, granularity and more accuracy because the serving service provider is provisioning the information rather than the originating service provider approximating the information
6 LRN Routing Architecture
7 DPC/SSN Routing Architecture - CNAM
8 Need for URI Routing Data for LNP Short Message Service (SMS) DPC/SSN –In 1999 SMS DPC/SSN was implemented in the NPAC in preparation for WNP –Between 1999 and 2003 when WNP was implemented most wireless SPs had evolved to an IP-based SMS solution –When WNP was introduced the industry had to develop a workaround whereby they approximate the IP-based address (URI) using NPAC data (SPID) –This workaround is also being used today as Multimedia Messaging Service (MMS) is being deployed –This workaround will not work as MVNOs and MVNEs deploy their own infrastructure, i.e., the SPID of the TN will designate the facility-based service provider not the MVNO/MVNE
9 Approximating a URI Service providers use the SPID in the TN record to approximate the URI, e.g., this SPID always = this URI
10 MVNO/MVNE Example Carrier B Carrier E Carrier D Carrier C Carrier A A customer on Carrier Cs network sends an MMS message to an MVNO customer on Carrier As network. The MVNO has implemented their own MMSC so that they can perform billing and customer service functions for their customer as well as provide enhanced services. If the approximationmethod was used to route this message it would go directly to Carrier As MMSC rather than through the MVNOs MMSC.
11 NANC 400 NANC 400 adds four address fields to the TN record for Voice URI, MMS URI, Push to Talk over Cellular (PoC) URI and Presence URI (a URI is an address for Internet- based services) All of these services are impacted by number portability, i.e., the service will fail if the recipient service providers address is not used These fields are directly analogous to DPC/SSN fields –DPC/SSNs are addresses in the SS7 protocol –URIs are addresses in the Internet Protocol Deploying NANC 400 will allow carriers to provision addresses directly through the NPAC rather than relying on workarounds similar to the SMS approximation NANC 400 is limited to ported and pooled numbers. For a complete solution, service providers will have to exchange default routing addresses, i.e., URIs associated with the NPA-NXX. –Two methods of exchanging default data are through; 1) a third party such as a peering or routing provider or 2) bi-lateral agreements such as those that exist for roaming, peering, and interconnection –Managing lists of default data is a relatively simple task - once set up they are only modified as NXXs are added or entire NXXs are cut over to IP
12 Voice URI Architecture The originating VoIP switch dips its routing database to find the address for the dialed number. The switch will then use the address to establish a voice session with the terminating VoIP switch.
13 Presence URI Architecture When a wireless user attempts to add a buddy to their buddy list they will input the TN of the new buddy through their phone. The presence server will query a routing database to find the URI for the buddys presence server based on the TN. Then it will send a Subscribe message to the buddys presence server and the buddy will be added to the buddy list. The presence server will receive Notification messages on a regular basis that describes the presence of the buddy
14 PoC URI Architecture PoC works hand in hand with presence. When a user sees that a person they want to PoC with is available they select the buddy to start a PoC session. The PoC server will dip the routing database to find the address of the PoC server based on the TN. When the user wants to talk they will press the PoC button which then sets up a PoC session.
15 MMS URI Architecture
16 Considerations To the extent that carriers are relying on methods other than the NPAC to exchange or approximate data associated with ported and pooled TNs they must consider: –Synchronization with the PSTN –Open versus proprietary solutions –Who has the authority for provisioning/modifying records –Ability to support current needs as well as meet evolving needs –Neutrality of vendor –Fair and impartial access to data –Flexibility –Accuracy –Granularity
17 Summary NANC 400 adds 4 new routing fields to ported and pooled TNs These fields are directly analogous to existing DPC/SSN routing fields There are no changes to any NPAC business rules These fields do not require companies that are not currently users of the NPAC to become users No new portability is created by adding these fields, i.e. this is still service provider portability These fields do not constitute a new routing service These fields are within the scope of the NPAC Implementation of these fields is consistent with the regulatory framework for local number portability administration The change order process should continue