NENA s 1Q06 Technical Committee Status

1. ESIF 17 Las Vegas March 21, 2006 NENA’s 1Q06 Technical Committee Status Roger Hixson NENA Technical Issues Director

2. Status ReportNetwork Technical Committee Internetworking WG - Jim Winegarden Dormant since publishing tandem-to-tandem direct standard. Need to address transfers of 9-1-1 calls through the PSTN SS7 Landline/VoIP Interconnection Guide WGSelena MacArthur & Dick Dickinson SS7 TID 03-503 published October 2005 In 2006 they will assess any impacts to TID from i2.5

3. Status ReportNetwork Technical Committee Functional Entity WG – Sandra Lott Reviewing impact of VoIP to 9-1-1 Functional Entity Model Voice Circuit Standards WG - Joe Marino Address trunk group sizing guidelines This document will recommend a simple Poisson based method for calculating P.01 and sizing trunk groups accordingly.

4. Status ReportNetwork Technical Committee Network Quality Assurance and Design WGKen Maynard & Jim Winegarden Goal is to publish a NENA Standard detailing Network Quality Assurance & Design, including a section on contingency planning and survivability. Work still focuses on survivability and contingency planning, which is getting greater attention in the wake of Hurricane Katrina Default Call Path WG – Bernard Brabant Goal is to develop a TID identifying various network arrangements for all types of default routing and overflow treatment in landline, VoIP and wireless technologies Work in progress by Bernard

5. Status ReportNetwork Technical Committee Geographic Number Portability WG – vacant Goal is to identify all impacts of GNP on 9-1-1 Paul Stoffels has compiled a preliminary list, but cannot continue to serve as Leader We need a new WG Leader & some interestedvolunteers to complete this important activity

6. Status ReportNetwork Technical Committee Rate Center Consolidation WG (re-opened)Tom Hinkelman WG was idled in 2005 because we thought 1000s-group pooling eased the explosion in area codes and removed the need for anyone to consolidate rate centers. We were wrong! Goal is to publish a TID exposing the potential impacts of RCC to reliable E9-1-1 service if appropriate precautions aren’t taking during the planning stages We welcome participation from those involvedin any pending or recently completed rate center consolidations

7. Status ReportData Technical Committee NENA 02-010 Data Exchange reissue approved 02/25/2006 Established 7 new classes of service for VoIP Added COS “I” for Wireless Phase II - Tells the PSAP the call is from a Phase II capable service, but only phase I information was available. Re-bid ALI for phase II information. Note, re-bid will not guarantee phase II information will be provided. XML Release 4.1 to accommodate I2 standard which was developed by NENA to handle VoIP calls in the current E9-1-1 system. The I2 directory includes schemas used by the I2 web services definitions (WSDLs) as well as the I2 WSDLs. http://www.nena.org/xml_schemas/nena.htm Seven new Class of Service have been identifies for VoIP. With the understanding that most VoIP providers do not have the capability of delivering the specific Class of Service at this time, a default Class of Service has been developed. V = VoIP Services default Class of Service. (preferably with VOIP being displayed at the PSAP) The other new Class of Service one bite characters are: C= VoIP Residential (preferably with VRES being displayed at the PSAP) D= VoIP Business (preferably with VBUS being displayed at the PSAP) E = VoIP Coin/Pay Phone (preferably with VPAY being displayed at the PSAP) F = VoIP Wireless (preferably with VMBL being displayed at the PSAP) J = VoIP Nomadic (preferably with VNOM being displayed at the PSAP) K = VoIP Enterprise Solutions –Centrex & PBX (preferably with VENT being displayed at the PSAP) All VoIP Class of Service are for both static and nomadic services with the exception of J=VoIP Nomadic. This will be used when a customer is moving from one location to another and is unsure of the class of service they should be using at that time, as it is different than their normal/predominant class of service.Seven new Class of Service have been identifies for VoIP. With the understanding that most VoIP providers do not have the capability of delivering the specific Class of Service at this time, a default Class of Service has been developed. V = VoIP Services default Class of Service. (preferably with VOIP being displayed at the PSAP) The other new Class of Service one bite characters are: C= VoIP Residential (preferably with VRES being displayed at the PSAP) D= VoIP Business (preferably with VBUS being displayed at the PSAP) E = VoIP Coin/Pay Phone (preferably with VPAY being displayed at the PSAP) F = VoIP Wireless (preferably with VMBL being displayed at the PSAP) J = VoIP Nomadic (preferably with VNOM being displayed at the PSAP) K = VoIP Enterprise Solutions –Centrex & PBX (preferably with VENT being displayed at the PSAP) All VoIP Class of Service are for both static and nomadic services with the exception of J=VoIP Nomadic. This will be used when a customer is moving from one location to another and is unsure of the class of service they should be using at that time, as it is different than their normal/predominant class of service.

8. NENA 02-011 in review process Section 2.27 FX/DPA/OPX Standard Section 4.15 Jurisdictions access to DBMS Section 6.9 Fictitious Addresses Section 22 General LNP standards The Unlock function code expires after 90 days, at which time the Unlocked TN record in the DBMS and ALI databases will be removed. NPAC/LERG validation Statistical reports identifying by NENA ID stranded unlocks more than 30 days old sent to the 911 database stakeholder NPDI Standards modified to include VoIP LNP Exhibit Flow charts revised

9. NENA 02-502 NENA Company ID Registration Service Technical Information Document (TID) Approved 12/2005

10. Status of Existing Issues VDB/MSAG WG – Delaine Arnold Almost complete with first release of DRAFT NENA 02-013 standard on how the VDB and ERDB should process and interface with today’s MSAG Sources.

11. LNP WG – Judy Graham Developing portability testing scenarios for porting to & from VoIP services. Currently discussing the pros & cons of the Unlock & Migrate FOC codes vs. Delete & Insert GIS WG – Erica Aubut Information being assimilated for GIS data collection and maintenance standard 02-014. Convert GIS data model Version 1.0 to GML

12. XML Data Exchange WG - Kim Leigh Once the industry signs off on a modified ACN (Automatic Collision Notification) format the XML schema will be updated. Convert the WAC (Wireless ALI Content) data field elements to an XML schema. Review and ensure ALI Response data format is correct and in XML schema. XML Namespace naming issues is essentially about agreeing on a standard naming syntax.  eGov Initiatives: The DOJ compliance issue is about reusing DOJ type definitions in NENA schemas (if required).  Additionally there are other initiatives on resource messaging and EDXL At some point we may be asked to use the same field names and definitions – unknown at this time. XML Transport: OBF looking at possible changes to Service Order Formats in the future which will impact our standards. WG monitoring.

13. Wireless ALI Discrepancy Paul Binder/Bill Horn Establishment of data management standards related to Wireless ALI Discrepancies. Joint Data Technical/Operations Quality Assurance WG – Maria Jacques/Ron Bloom Primary focus is the OID document and gathering information for a PSAP Quality Assurance Document.

14. Future Issues for VDB/MSAG WG ALI discrepancy procedures will need to be modified to account for VoIP. Review existing quality measurements and audits to determine what is applicable for VDB/ERDB Operators. End game MSAG format, transaction number, real time updates, AKA, switch issues – V2 interface. Who is responsible for liaising with the SR operators in the area of coverage to assist the SR operators in determining which ESRN values correspond to the ESZ allocations. Waiting on ESQK/ESRN WG to finalize. Reports: Statistical, Log of queries, Worst case busy hour, ERDB Queries that fail, Report of MSAG and Alternates, Mismatches between alternates, postal and MSAG. The ERDB query should be made to the same VDB/ERDB where initial address validation occurred. Processes on how the LIS will interface with VDB.

15. Future Issue for DBM WG Need to develop a new process for distributing 9-1-1 data. Currently being done by NPA/NXX. Doesn’t work for LNP, Static VoIP, or GNP.

16. Future Issues for LNP WG Which NENA ID goes on UNE-P service? Porting of a pilot/main number

17. CPE Technical Committee Status Report Who are we? CPE Vendors PSAP Staff Service Providers Database Providers What do we do? Produce and maintain technical standards documents. Produce Technical Information Documents Participate in joint working groups with other committees Monitor development of related standards in other organizations

18. Update Complete

19. Legacy Interface (Gary Hutchins) Create new standard document Describe ALI communications “states”. Clarify legacy interface operation Timing of interface events Status: Document Complete, Approvals in Process

20. Expertise to be NENA’s authority on security issues Working on enhancing relationships with other committees Ahead: Develop NENA Security Standards Participate in characterizing security aspects of NENA’s next generation network. Status: TID Completed and Published

21. CPE Specifications to support IP data and voice. Status: NENA Standard Document in Development

23. VoIP Technical Committee Status Report Interim Solution (i2) standard completed Long Term (i3) Architecture Document Nearly Complete VLWG work zeroing in on solutions SDO document updated

24. Interim Solution (i2) Standard Standard is entitled Interim 9-1-1 Solution for VoIP Service Providers - NENA 08-001 Was completely ratified in late fall of 2005 Several lingering issues to be addressed by the authoring working group (migratory definition) to be covered under the i2.5 Appendix D and others

25. Updated Interim Solution (i2.5) Delivery of ESQK and CBN to SR (20 digit) Signaling of geodetic info to SR ERDB discovery using geodetic information Root discovery mechanism update ERDB steering mechanism Allowing VDB to return MSAG formatted address to LIS Requirements on Valid Emergency Service Authority (VESA) operator

26. Updated Interim Solution (i2.5) Requirements on ERDB/VDB discovery operator Delivery of Class of Service over V-E2 interface Interface between Call Server and LIS Geodetic location delivery issues Should i2.5 support mobile users? Inclusion of recommended methods for location determination and acquisition from the output of the Location WG Others as submitted (V2, V3, V5, V7?)

27. i3 Architecture The initial i3 requirements document is completed, ready for internal review First Technical Requirements Document completed within NENA Once fully ratified (awaiting complete committee review and admin input), it will be NENA 08-751

28. More i3 Work Mechanisms standard document development is in progress Contributions and liaisons are being considered with several other industry SDO’s

29. VLWG Goals & Milestones Requirements and Evaluation Criteria Defined Example Scenarios and Use Cases Defined Evaluation of Proposed Methods Residential/Mass Market – in progress Wireless Access & Enterprise – next Encourage standards development Recommendations

30. Residential / Mass Market Dynamic Host Control Protocol Option Defined by IETF for [endpoint] clients to acquire location Assumes provisioned wiremap of circuit identifiers to geographic location data (stored in a Location Information Server=LIS) Intended for Ethernet wireline; can also be used to obtain fixed location of wireless access point RFC 3825, DHCP Option for Coordinate-based Location Configuration Information Civil location in final stages

31. Residential / Mass Market DHCP Option – Concerns DHCP not used in major DSL markets in North America Would require significant equipment replacement Technical questions remain on its deployment for mass market/residential Cannot be adapted to obtain location information on-behalf-of endpoints that are not location-capable All DHCP-relay agents will set the giaddr field in the DHCP Discovery message, many will not set the Agent-ID in option-82, but they will set the circuit ID. So what does this mean? Changes are needed to the DHCP proposal from Marc Linsner to adapt the RFC and apply it to actual DSL deployments. As for impact to mass-market it really depends on how DHCP-based DSLAMs operate. if DSLAMs use the giaddr field, then hacking is required at the RANP to get something to deliver to the ISP. The reason for this is that giaddr field is the address that the DHCP server will respond to. If this is set by a DSLAM in the heart of the access network it will almost certainly have a very private the restricted address range, if the DHCP-server must respond to this address, then it must be able to route to it directly, probably not something that an access infrastructure provider would allow another provider to do. If the RANP has some quasi-Relay-Server in the middle, something would be possible, but no specification exists for this. May need to propose DHCP as an enterprise or closed system solution? All DHCP-relay agents will set the giaddr field in the DHCP Discovery message, many will not set the Agent-ID in option-82, but they will set the circuit ID. So what does this mean? Changes are needed to the DHCP proposal from Marc Linsner to adapt the RFC and apply it to actual DSL deployments. As for impact to mass-market it really depends on how DHCP-based DSLAMs operate. if DSLAMs use the giaddr field, then hacking is required at the RANP to get something to deliver to the ISP. The reason for this is that giaddr field is the address that the DHCP server will respond to. If this is set by a DSLAM in the heart of the access network it will almost certainly have a very private the restricted address range, if the DHCP-server must respond to this address, then it must be able to route to it directly, probably not something that an access infrastructure provider would allow another provider to do. If the RANP has some quasi-Relay-Server in the middle, something would be possible, but no specification exists for this. May need to propose DHCP as an enterprise or closed system solution?

32. Next Steps Finalize NENA Requirements Continue to contribute concerns/questions to IETF about proposed solutions Finish TID – Residential/Mass Market Expect to need two solutions for residential / mass market

33. Next Steps Provide NENA requirements to additional standards and industry forums to encourage standards for location determination and acquisition mechanisms for new (and existing) access technologies ESIF 3rd Generation Partnership Project (s) Wi-Fi Alliance DSL Forum IEEE Etc.

35. NENA 9-1-1 Center Operations Committee VoIP E9-1-1 Planning and Implementation document in review Provides info and guidelines to Public Safety Authorities NG9-1-1 Funding Analysis document in final review

37. NENA NG E9-1-1 Partner Program Status Objective is to enable NG9-1-1, via program to identify roadblock/enabling issues 25 partners to date 2005 Program report is out, available on the NENA website (www.nena.org) Identifies results of the 2005 work Covers objectives for 2006 program

38. NENA NG E9-1-1 Partner Program Status Topic Areas for 2006 Program Funding Data and Access Location/`Call’ Routing Requirements/Standards Demos/Trials Education Interoperability Disaster Planning

39. NENA NG E9-1-1 Partners America Online American Association of Poison Control Centers AT&T Cingular COMCARE HBF Group, Inc. Intrado L. Robert Kimball & Associates Level 3 Communications MapInfo MCI Motorola National Academies of Emergency Dispatch

40. NENA NG E9-1-1 Partners NeuStar OnStar Positron Public Safety Systems Rosum Sprint Nextel TCI TeleCommunication Systems T-Mobile Texas 9-1-1 Alliance Texas Commission on State Emergency Communications TruePosition Verizon Vonage