NANC Change Order 400

1. NANC Change Order 400 Joint FoN/LNPA WG Meeting April 14, 2005 Tom McGarry NeuStar, Inc. tom.mcgarry@neustar.biz

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 it’s 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 NANC’s 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: “NANCshould 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 A Carrier C Carrier D • A customer on Carrier C’s network sends an MMS message • to an MVNO customer on Carrier A’s 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 “approximation”method was used to route this message • it would go directly to Carrier A’s MMSC rather than through • the MVNO’s MMSC. Carrier E

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 provider’s 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 • buddy’s presence server based on the TN. • Then it will send a “Subscribe” message to the buddy’s 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

18. Acronym List