Home

Technical Committee - VoIP/Packet

The Voice over Internet Protocol (VoIP)/Packet Committee’s   goal is to identify and solve technical issues relating to call delivery from VoIP sources and migrate existing 9-1-1 technologies into a packet environment for both voice and data.  Identified technical issues are handled via Working Groups that are formed to accomplish specific goals, which usually result in some type of official NENA documentation.

      Scroll Down or Click to Go To:

The current VoIP/Packet Working Groups are:

  • Long Term Definition (LTD)
  • Migratory Definition (VMWG)
  • Location (VLWG)

Any NENA member interested in joining any VoIP/Packet Working Groups, please review the Scopes & Goals at the bottom of the page and then contact the Committee Chair or Vice Chair to be added to a specific working group.

Chair
Nate Wilcox
802-673-2048

Nate Wilcox began his career in 9-1-1 in 1991 and has extensive experience in product requirements, assists in technical development work, evaluates existing solutions and provides engineering support on large scale IP-based 9-1-1 deployments. He has end to end knowledge of all current 9-1-1 systems procedures and practices (former call taker, PSAP admin, state 9-1-1 administrator(?) and product installation/design/support manager), and assisted in engineering and maintaining the first SS7/ISDN multi PSAP deployment in the nation.

He also designed the network and assisted in designing the CPE applications for the first multi-PSAP IP based 9-1-1 system in the nation. Nate is heavily involved in NG9-1-1(?) services on both the national and international level and is a recognized speaker on topics involving 9-1-1 before the FCC, VON coalition and other industry bodies. He has several years of Public Safety 9-1-1 experience, including systems administrator of the Vermont Enhanced 9-1-1 Board. In addition to chairing the NENA VoIP/Packet Technical Committee, Nate has also held leadership roles in several other organizations.

Vice-Chair
Roger Marshall
TeleCommunication Systems (TCS)
206.792.2424

Roger Marshall, a Senior Member of the Technical Staff at TeleCommunication Systems (TCS), is based out of Seattle, Washington.  Roger’s focus has been, and continues to be on Next Generation Emergency Service Standards & Technology development.  Some of his primary responsibilities include working with external industry forums along with internal development resources to help define future E9-1-1 TCS technology as it relates to IP-based E9-1-1 and commercial Location-based systems and services. 

Roger’s interests are geared toward creating and adapting strategic technology initiatives that support the development and deployment of available VoIP technology, as well as positioning for the next generation global emergency standards.  Within the existing NENA VoIP/Packet Technical Committee, he is an active participant and contributor to the Location, Migratory, and Long-Term Definition working groups.  Roger has been  active within other standards development organizations, including the IETF ECRIT work group.   Roger has a diverse engineering & technical background including research, systems, & network design and analysis for various Information, Scientific, and Manufacturing companies.  Roger, along with his wife Tina, and five children (yes, 5!) enjoy the rural farm life just outside the Seattle area.

 

                                                                                                                    Return to Top

DocumentSize
20110114_VTC-Scope-Goal-Direction-Status.pdf170.5 KB
NENA Technical Standards & Documents
  • 00-001 v16 Master Glossary

    The NENA Master Glossary is a guide for readers of NENA publications and a tool for members of the NENA committees that prepare them. It defines the terms, acronyms and definitions associated with the 9-1-1 industry. Intended users of this document are any person needing NENA’s definition/description of a 9-1-1 related term.

  • 01-001 v4.1 Organization & Document Approval Processes

    This document is written for NENA Technical Committee leadership and members. A requirement for participating in the Technical Committee process is to adhere to all procedures outlined in this document.

  • 08-001 v2 Interim VoIP Architecture (i2)

    Voice over Internet Protocol (VoIP) is poised to become the predominant technology used in the telecommunications industry. As the public adopts VoIP, E9-1-1 calls will increasingly originate from VoIP users. Some VoIP telecommunications service provider networks, however, are not natively compatible with the existing E9-1-1 infrastructure. This document was developed to outline an interim architecture to connect callers in the IP domain with Public Safety Answering Points (PSAPs) supported by the existing E9-1-1 Service Provider network.

  • 08-002 v1 Functional & Interface Standards for NG9-1-1 (i3)

    Major changes in the existing emergency services architecture are being driven by the rapid evolution of the types of devices and services that can be used to call for help. Also there is an increasing volume and diversity of information that can be made available to assist PSAPs and responders in an emergency. NENA recognizes this is a fundamental update to the North American 9-1-1 system, and is addressing the challenge with a system design called “Next Generation 9-1-1(?)” (NG9-1-1(?)). NG9-1-1 is the evolution of Enhanced 9-1-1 to an all-IP-based emergency communications system. This technical specification, commonly referred to as i3, is the first version of the NG9-1-1 system design.

  • 08-003 v1 NENA i3 Solution

    This specification builds upon prior NENA publications including i3 requirements and architecture documents. Familiarity with the concepts, terminology and functional elements described in these documents is a prerequisite. While the requirements and architecture documents describe high level concepts, the present document describes only the detailed functional and external interfaces to those functional elements. If there are descrepencies between the requirements or architecture documents and this document, this document takes precedence. This document provides a baseline to other NG9-1-1(?) related specifications.

     

  • 08-501 v1 Network Interface to IP Capable PSAP

    This “NENA Technical Information Document on the Network Interface to IP Capable PSAP” document provides technical information to guide manufacturers of network equipment and Public Safety answering Point (PSAP)(?) Customer Premises Equipment (CPE) in the development of Internet Protocol based interfaces between the network and PSAP CPE and to assist E9-1-1 Network Service Providers and PSAP’s in implementing such interfaces. It defines a service description for the capabilities that will need to be supported by the VoIP signaling on the interface, as well as the necessary network and CPE elements needed in the supporting architecture. The Appendices to this TID include specific assumptions/issues for individual candidate Voice over Internet Protocol (VoIP) signaling protocols, that will need to be considered in the specification of (separate) technical reference document(s) that provide signaling requirements for the individual VoIP protocol alternatives identified.

  • 08-502 v1 E9-1-1 Requirements

    This document is intended to provide a resource that describes the features and functions of the E9-1-1 system that is currently deployed in the United States. These features and functions are a compilation of different regional networks and some may not be present in any particular E9-1-1 network.

  • 08-503 v1 VoIP Characteristics

    The purpose of this document is to procure, create and publish a VoIP primer document to be used by individuals not familiar with VoIP technology.

  • 08-504 v1 VoIP Standards Development Organizations (SDOs)

    This “NENA VoIP Standards Development Organizations” is a reference for NENA technical committees to use for determining the various standards setting bodies involved in the implementation and on going development of VoIP protocols and procedures as they relate to emergency calling.

  • 08-505 v1 Location Determination: IP-Based Emergency Services

    This document is the first edition of what will be a comprehensive document addressing many access network configurations. This edition has a narrow solutions focus and will address only the automated mechanisms for the residential broadband market, manually configured location mechanisms for end-points are not discussed. User-provided location information is beyond the scope of this document. Revised editions of this document will add new sections to address enterprise, hosted and mobile access configurations.

  • 08-751 v1 i3 Requirements (Long Term Definition)

    This “NENA i3 Technical Requirements Document” is intended to specify the requirements the i3 (Long Term Definition) Standard should meet.  This document is issued to guide the development of the i3 Standard.

  • 08-752 v1 Location Information to Support IP-Based Emergency Services

    This Technical Reference document provides the NENA requirements for providing location information to support emergency calling. It also provides example scenarios and use cases that need to be supported. This is being provided to support organizations that are defining solutions for determining, acquiring and conveying location information to support emergency calling.

  • 08-DRAFT Emergency Services IP Network Design for NG9-1-1

    NOTE: NENA 08-XXX, Version 1, is continuing to be developed by the ESIND WG.

    Many 9-1-1 Entities have built, are building, or will build in the near future an Emergency Services network to connect the PSAPs in their region. The effort and expense required to build these regional facilities is significant. What steps can be taken today to ensure that these regional IP networks will be able to transport traffic for NG9-1-1(?) functions (i.e. ECRF, ESRP, etc.) when those services become more readily available? What are some of the major design considerations that should be taken into account? What are some of the caveats, limitations, and advantages of the various technologies? The purpose of this document is to provide the 9-1-1 Entities with the tools (i.e. design methodologies, best practices, templates for ESInet RFI and RFP, etc.) that will enable them to design and deploy networks today that will be capable of meeting the requirements of an NG9-1-1 system.

     

  • 73-501 Non-Voice-Centric Emergency Services

    The Emergency Services community has a desire to have multimedia emergency services supported with the same general characteristics as emergency voice calls. As a result, there is a need to communicate with emergency services using mechanisms that are not primarily voice.

    Non-Voice -Centric (NVC) Emergency Services are intended to support (human) end user to authority communication. NVC Emergency Services may support the following examples of non-verbal communications to an emergency services network:

    1. Text communication between end users and emergency services
    2. Multi-media (e.g., pictures, video clips) transfer to emergency services during a voice or NVC session with emergency services.
    3. Real-time video session with emergency services
    4. Text communication with supplementary media (such as background audio and/or video)

    NVC Emergency Services as defined in this document focuses on Next Generation Network (NGN) technology and does not include legacy messaging services, such as Short Messaging Service (SMS) . In addition, NVC Emergency Services does not include support of calls from non-human initiated devices (e.g., fire alarms).

    There will be significant impacts to the entire emergency services system resulting from the changes in networks and devices as described in this document. It is expected that end user devices and origination networks will ultimately evolve, and that the next generation emergency services solution will allow this evolution to take place over time. Many systems in the emergency services network must eventually change. New end-to-end messaging relationships must be established.

    In addition to supporting the general public, this capability facilitates emergency communications by individuals with disabilities (e.g., persons who are deaf, deaf-blind, hard of hearing, or have a speech disability).