DOCSLIB.ORG

08-003 Detailed Functional and Interface Specification NENA I3 Solution

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
08-003 Detailed Functional and Interface Specification NENA I3 Solution Understanding NENA’s i3 Architectural Standard for NG9-1-1 Today, NENA takes a significant step toward achieving the vision of Next Generation 9-1-1 service. As we adopt Version 1.0 of NENA Technical Standard 08-003, Detailed Functional and Interface Specification for the NENA i3 Solution – Stage 3, we consider it important to explain how this standard relates to long-term efforts to modernize our nation’s emergency communications systems. This NENA standard intentionally describes an end-state NG9-1-1 architecture, rather than an immediate “build-to” specification for a complete NG9-1-1 system. Broadly speaking, 9-1-1 systems will reach the end-state envisioned by the i3 Standard only over the long term. In the interim, transitional steps must be taken to maintain support for legacy interfaces from originating service providers such as wireline and cellular telephone carriers, and to accommodate legacy PSAP equipment. At the same time, we recognize that state and local authorities will begin deploying ESInets and other core components of the i3 architecture as those components reach the market. Likewise, originating service providers and access network operators may begin deploying new network elements in support of longer-term NG9-1-1 services. The i3 architecture anticipates the existence of transitional states in origination services, access networks, and 9-1-1 systems and includes specifications for network elements that will be required to support a growing variety of “call” types as deployed systems evolve toward the end-state. Critically, the i3 standard is not, by itself, the same thing as an NG9-1-1 system. The i3 standard describes only the network, components, and interfaces required to establish Next Generation 9-1-1 service. In order to deploy a fully-operational NG9-1-1 system, 9-1-1 authorities, equipment and software vendors, originating service providers, and access network providers will require detailed specifications for technical, operational, and human elements that are not described in the i3 standard. As the leading standards development organization for the 9-1-1 sector, NENA has already developed some of these specifications. Much work remains, however, and NENA is committed to developing the additional consensus standards needed to support fully-mature NG9-1-1 service systems. It also will be necessary for NG9-1-1 systems to interwork with services and networks provided by the broader telecommunications and applications industries. NENA is aware of the evolution of the Internet Multimedia Subsystem (IMS) standard under development by ATIS, and our Technical Committee has designed the i3 architecture to support known characteristics of IMS. We are therefore pleased by the efforts of ATIS and others to develop detailed specifications for an interface between IMS-based originating services and the ESInets on which the i3 architecture operates. Version 1.0 of the i3 standard could not cover all aspects of the interface, however, because those efforts only recently began. Standards convergence in this area will be important to the success of NG9-1-1, and we look forward to more fully addressing the IMS/ESInet interface in concert with ATIS. In addition to technical and operational standards, a detailed policy framework must be created to enable and support the transition to NG9-1-1. Critical policy decisions such as how NG9-1-1 deployments will be funded and how system costs should be allocated are beyond the scope of the i3 technical standard. Those decisions must be made, however, and NENA will support policymakers at all levels of government as they wrestle with these issues. We also wish to emphasize that the i3 standard is not intended to fully address the issues involved in transitioning from legacy 9-1-1 and E9-1-1 systems to end-state NG9-1-1. In 2006, NENA created a working group focused on transitional matters, such as network, data, and operational issues. That group has since completed work on Version 1.0 of a transition plan, covering mostly network issues. That group is now working on Version 2.0, covering data and operational issues. As the group continues its work, we expect that it will soon produce an integrated, consensus-based plan covering all essential elements of the transition to NG9-1-1 with sufficient specificity to allow 9-1-1 system administrators, vendors, access network operators, and originating service providers to confidently deploy capital in support of the transition. Much work remains to be done, but our adoption of the i3 standard establishes a clear vision for the future and a foundation on which successful transitions to Next Generation 9-1-1 service can be built. As work continues, NENA stands ready to lead the cooperative efforts needed to ensure smooth transitions and to achieve the ultimate vision of NG9-1-1 as a service accessible anytime, anywhere, on any device. For the Executive Board, Stephen F. O’Conor, ENP President Detailed Functional and Interface Specification for the NENA i3 Solution – Stage 3 NENA Detailed Functional and Interface Standards for the NENA i3 Solution (TSD) NENA 08-003 v1, June 14, 2011 Standards Advisory Board approval date, February 16, 2011 NENA Executive Board approval date, June 14, 2011 Prepared by: National Emergency Number Association (NENA) Technical Committee Chairs Published by NENA Printed in USA © Copyright 2011 NENA. All rights reserved. Detailed Functional and Interface Specification for the NENA i3 Solution – Stage 3 NENA 08-003 Version 1, June 14, 2011 NENA TECHNICAL STANDARD DOCUMENT NOTICE The National Emergency Number Association (NENA) publishes this document as a guide for the designers and manufacturers of systems to utilize for the purpose of processing emergency calls. It is not intended to provide complete design specifications or to assure the quality of performance of such equipment. NENA reserves the right to revise this TSD for any reason including, but not limited to: conformity with criteria or standards promulgated by various agencies utilization of advances in the state of the technical arts or to reflect changes in the design of equipment or services described herein. It is possible that certain advances in technology will precede these revisions. Therefore, this NENA TSD should not be the only source of information used. NENA recommends that readers contact their Telecommunications Carrier representative to ensure compatibility with the 9-1-1 network. Patents may cover the specifications, techniques, or network interface/system characteristics disclosed herein. No license expressed or implied is hereby granted. This document shall not be construed as a suggestion to any manufacturer to modify or change any of its products, nor does this document represent any commitment by NENA or any affiliate thereof to purchase any product whether or not it provides the described characteristics. This document has been prepared solely for the use of E9-1-1 Service System Providers, network interface and system vendors, participating telephone companies, etc. By using this document, the user agrees that NENA will have no liability for any consequential, incidental, special, or punitive damages arising from use of the document. NENA’s Technical Committee has developed this document. Recommendations for change to this document may be submitted to: National Emergency Number Association 4350 N Fairfax Dr, Suite 750 Arlington, VA 22203-1695 800-332-3911 or: [email protected] Version 1, June 14, 2011 Page 2 of 282 Detailed Functional and Interface Specification for the NENA i3 Solution – Stage 3 NENA 08-003 Version 1, June 14, 2011 Acknowledgments: The National Emergency Number Association (NENA) VoIP/Packet Technical Committee Long Term Definition Working Group developed this document. NENA recognizes the following industry experts and their companies for their contributions in development of this document. Version 1, Approval Date, 06/14/2011 Members Company Brian Rosen –Work Group Leader and NeuStar Technical Editor Nate Wilcox – VoIP/Packet Technical Chair microDATA Richard Atkins Tarrant County 9-1-1 District Delaine Arnold Arnold 9-1-1 Consulting Wayne Ballantyne Motorola Deborah Barclay Alcatel Lucent Marc Berryman DDTI Tom Breen AT&T Gary Brown NENA Utah Chapter Member Pete Eggimann Metropolitan Emergency Services Board Randall Gellens Qualcomm Casimer M (Duke) Kaczmarczyk Verizon Marc Linsner Cisco Roger Marshall TeleCommunication Systems, (TCS) Kathy McMahon-Ruscitto APCO International Theresa Reese Telcordia Greg Schumacher Sprint Robert Sherry Intrado Michael Smith DSS Hannes Tschofenig Nokia Siemens Networks Mike Vislocky Network Orange This committee would also thank Tom Breen, Technical Committee Chair and Roger Hixson, Technical Issues Director for their support and assistance. Version 1, June 14, 2011 Page 3 of 282 Detailed Functional and Interface Specification for the NENA i3 Solution – Stage 3 NENA 08-003 Version 1, June 14, 2011 TABLE OF CONTENTS 1 EXECUTIVE OVERVIEW ............................................................................................................................... 14 2 INTRODUCTION .............................................................................................................................................. 17 2.1 OPERATIONAL IMPACTS SUMMARY .................................................................................................................... 17 2.2 SECURITY IMPACTS SUMMARY ..........................................................................................................................
Load more

Recommended publications
  • Are3na Crabbé Et Al
    ARe3NA Crabbé et al. (2014) AAA for Data and Services (D1.1.2 & D1.2.2): Analysing Standards &Technologies for AAA ISA Action 1.17: A Reusable INSPIRE Reference Platform (ARE3NA) Authentication, Authorization & Accounting for Data and Services in EU Public Administrations D1.1.2 & D1.2.2– Analysing standards and technologies for AAA Ann Crabbé Danny Vandenbroucke Andreas Matheus Dirk Frigne Frank Maes Reijer Copier 0 ARe3NA Crabbé et al. (2014) AAA for Data and Services (D1.1.2 & D1.2.2): Analysing Standards &Technologies for AAA This publication is a Deliverable of Action 1.17 of the Interoperability Solutions for European Public Admin- istrations (ISA) Programme of the European Union, A Reusable INSPIRE Reference Platform (ARE3NA), managed by the Joint Research Centre, the European Commission’s in-house science service. Disclaimer The scientific output expressed does not imply a policy position of the European Commission. Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication. Copyright notice © European Union, 2014. Reuse is authorised, provided the source is acknowledged. The reuse policy of the European Commission is implemented by the Decision on the reuse of Commission documents of 12 December 2011. Bibliographic Information: Ann Crabbé, Danny Vandenbroucke, Andreas Matheus, Dirk Frigne, Frank Maes and Reijer Copier Authenti- cation, Authorization and Accounting for Data and Services in EU Public Administrations: D1.1.2 & D1.2.2 – Analysing standards and technologies for AAA. European Commission; 2014. JRC92555 1 ARe3NA Crabbé et al. (2014) AAA for Data and Services (D1.1.2 & D1.2.2): Analysing Standards &Technologies for AAA Contents 1.
    [Show full text]
  • OASIS Response to NSTC Request for Feedback on Standard Practices
    OASIS RESPONSE TO NSTC REQUEST FOR FEEDBACK ON STANDARDS PRACTICES OASIS (Organization for the Advancement of Structured Information Standards) is pleased to respond to the request from the National Science and Technology Council's Sub-Committee on Standards published at 75 FR 76397 (2010), and extended by 76 FR 3877 (2011), for feedback and observations regarding the effectiveness of Federal agencies' participation in the development and implementation of standards and conformity assessment activities and programs. We have advised our own members about the Federal Register inquiry, in case they wish to respond. Of course, their opinions are their own, and this response does not represent the views of any members, but only the observations of OASIS professional staff. I. RESPONDENT'S BACKGROUND OASIS is one of the largest and oldest global open data standards consortia, founded in 1993 as SGML Open. OASIS has over 5000 active participants representing about 600 member organizations and individual members in over 80 countries. We host widely-used standards in multiple fields including • cybersecurity & access control (such as WS-Security, SAML, XACML, KMIP, DSS & XSPA) [/1], • office documents and smart semantic documents (such as OpenDocument, DITA, DocBook & CMIS) [/2], and • electronic commerce (including SOA and web services, such as BPEL, ebXML, WS-ReliableMessaging & the WS-Transaction standards) [/3] among other areas. Various specific vertical industries also fulfill their open standards requirements by initiating OASIS projects, resulting in mission-specific standards such as • UBL and Business Document Exchange (for e-procurement) [/4], • CAP and EDML (for emergency first-responder notifications) [/5], and • LegalXML (for electronic court filing data)[/6].
    [Show full text]
  • Seguridad En Redes
    Seguridad en Redes Alejandro Corletti Estrada www.darFe.es Seguridad en Redes Madrid, octubre de 2016 Este libro puede ser descargado gratuitamente para emplearse en cualquier tipo de actividad docente, quedando prohibida toda acción y/o actividad comercial o lucrativa, como así también su derivación y/o modificación sin autorización expresa del autor. RPI (Madrid): M-6249/2016 ISBN: 978-84-617-5291-1 Alejandro Corletti Estrada ([email protected] - [email protected]) www.darFe.es Seguridad en Redes Este libro en formato electrónico con extensión “PDF” es el que se encuentra disponible gratuitamente en Internet. La versión impresa del mismo (que sí es de pago) puede ser solicitada por correo electrónico a la cuenta: [email protected] Alejandro Corletti Estrada Página 4 Seguridad en Redes Agradecimientos A todos los que a través del apoyo, reconocimiento y agradecimientos de la obra anterior “Seguridad por Niveles”, me han dado ánimo para seguir reuniendo temas y escribir este nuevo libro. A mi “gran Maestro” Antonio Castro Lechtaler, con el que tuve el placer de iniciarme en la docencia y compartir hermosos años dentro de su Cátedra. A Chema Alonso que con infinita paciencia supo dedicarme algo de su escaso tiempo para escribir uno de los prólogos de este libro. A “Nacho” (José Ignacio Bravo Vicente) y “Paco” (Francisco Martín Vázquez), quienes con su buena onda y enorme conocimiento, logran día a día mantenerme en este ritmo del “cacharreo”, bajándome de las nubes de la teoría de Seguridad y Redes. A un sinnúmero de Operadores de red, gente de Seguridad y de Auditoría de muchos Países (cada uno de ellos sabe bien a quiénes me refiero), que vienen sufriéndome y aguantando desde hace varios años (muchas gracias, de verdad).
    [Show full text]
  • Knihovna Pro Prístup K Federacím Identit
    MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345<yA| Knihovna pro pˇrístup k federacím identit BAKALÁRSKÁˇ PRÁCE Marcel Poul Brno, 2011 Prohlášení Prohlašuji, že tato bakaláˇrskápráce je mým p ˚uvodnímautorským dílem, které jsem vypracoval samostatnˇe.Všechny zdroje, prameny a literaturu, které jsem pˇrivypracování používal nebo z nich ˇcerpal,v práci ˇrádnˇecituji s uvedením úplného odkazu na pˇríslušnýzdroj. Marcel Poul Vedoucí práce: RNDr. Daniel Kouˇril iii Podˇekování Tímto dˇekujivedoucímu mé bakaláˇrsképráce RNDr. Danielu Kouˇriloviza cenné rady a ˇcas,který mi vˇenovalpˇriˇrešenídané problematiky. v Shrnutí Tato práce se vˇenujenávrhu knihovny pro pˇrístupk federacím identit a její implementaci pomocí jakyka C. V práci je pˇredstavenprincip federací iden- tit a popsán návrh a implementace knihovny. vii Klíˇcováslova Federace identit, poskytovatel služeb, poskytovatel identit, SAML, Shibbo- leth ix Obsah 1 Úvod ................................... 3 2 Federace identit ............................. 5 2.1 Struktura federací ......................... 5 2.2 Security Assertion Markup Language (SAML) . 7 2.3 Shibboleth ............................. 7 2.4 Federace eduID.cz ......................... 8 2.5 SWITCHaai ............................ 9 2.6 eduroam .............................. 9 2.7 OpenID ............................... 10 2.8 MojeID ............................... 11 3 Návrh knihovny pro pˇrístupk federacím identit . 13 3.1 Analýza proces ˚upˇripˇrístupuk federacím identit . 13 3.2 Požadavky na ˇrešení
    [Show full text]
  • Best Practices on Public Warning Systems for Climate-Induced
    Best practices on Public Warning Systems for Climate-Induced Natural Hazards Abstract: This study presents an overview of the Public Warning System, focusing on approaches, technical standards and communication systems related to the generation and the public sharing of early warnings. The analysis focuses on the definition of a set of best practices and guidelines to implement an effective public warning system that can be deployed at multiple geographic scales, from local communities up to the national and also transboundary level. Finally, a set of recommendations are provided to support decision makers in upgrading the national Public Warning System and to help policy makers in outlining future directives. Authors: Claudio Rossi Giacomo Falcone Antonella Frisiello Fabrizio Dominici Version: 30 September 2018 Table of Contents List of Figures .................................................................................................................................. 2 List of Tables ................................................................................................................................... 4 Acronyms ........................................................................................................................................ 4 Core Definitions .............................................................................................................................. 7 1. Introduction .........................................................................................................................
    [Show full text]
  • Innovations in Resource Management and Mutual Aid Technology
    Innovations in Resource Management and Mutual Aid Technology July 22, 2021 National Alliance for Public Safety GIS (NAPSG) Foundation napsgfoundation.org | @napsgfoundation napsgfoundation.org | @napsgfoundation 1 Webinar Prep​ • Due to the large attendance, all participants are muted for the duration of the session to prevent background noise.​ • Please use the Q&A functionality within Zoom for questions that are relevant to the whole group.​ • We will address these Q&A at the end of the webinar!​ napsgfoundation.org | @napsgfoundation Today’s Objectives • Learn about FEMA’s National Resource Hub and how to gain access and start using the suite of resource management tools. • Gain insight into how the National Resource Hub can connect and share data with your other incident management systems, situational awareness apps, and other 3rd party systems today and in the future. • Learn what is in development to improve existing and innovate with new resource management and mutual aid technology tools and systems. • Find out what’s new in version 3.0 of the Implementation Guide on Information Sharing Standards and how you can use the guide in informing your agency’s technology selection and acquisition process to ensure interoperability and seamless information sharing. • Gain basic technical knowledge on the latest with the Emergency Data Exchange Language (EDXL) and how it supports building a National – and Global – network of interoperable incident management systems. napsgfoundation.org | @napsgfoundation 3 Agenda 2:00pm Introductions and Overview 2:10pm National Resource Hub - What It’s About - What It Can Do For You and Your Agency 2:25pm What’s Coming in the Job Aid and Technical Guidance for Incident Management Technology 2:35pm Know the Basics on EDXL and Why it Matters 2:55pm Actions & Next Steps 3:00pm Adjourned napsgfoundation.org | @napsgfoundation 4 Hosts and Panelists • Charlotte Abel, Strategic Manager, NAPSG Foundation • Harmon Rowland, Section Chief, FEMA National Integration Center • Rebecca Harned, Vice President, 4 Arrows Consulting, Inc.
    [Show full text]
  • IHE IT Infrastructure Technical Framework White Paper 2006-2007 Cross-Enterprise User Authentication (XUA)
    ACC, HIMSS and RSNA Integrating the Healthcare Enterprise 5 IHE IT Infrastructure Technical Framework White Paper 2006-2007 For Public Comment 10 Cross-Enterprise User Authentication (XUA) 15 IHE ITI Technical Committee Editor: John F. Moehrke 20 Version 2.0 2006-08-15 IHE ITI White Paper Cross-Enterprise User Authentication ______________________________________________________________________________ 25 Contents 1 Introduction............................................................................................................................ 4 2 Background............................................................................................................................ 5 2.1 Identity Enabled Services ................................................................................................ 5 2.2 SAML Assertion.............................................................................................................. 6 30 3 Healthcare Use cases ............................................................................................................. 7 3.1 Assumptions .................................................................................................................... 7 3.2 Use Case Categories......................................................................................................... 8 3.2.1 User Authentication (0a/b/c)............................................................................................................................... 8 3.2.2 HL7 Export/Import (1a)......................................................................................................................................
    [Show full text]
  • Eidas-Node and SAML
    eIDAS-Node and SAML Version 1.0 eIDAS-Node and SAML Version 1.0 Document history Version Date Modification reason Modified by 1.0 06/10/2017 Origination DIGIT Disclaimer This document is for informational purposes only and the Commission cannot be held responsible for any use which may be made of the information contained therein. References to legal acts or documentation of the European Union (EU) cannot be perceived as amending legislation in force or other EU documentation. The document contains a brief overview of technical nature and is not supplementing or amending terms and conditions of any procurement procedure; therefore, no compensation claim can be based on the contents of the present document. Copyright European Commission — DIGIT Page 2 of 59 eIDAS-Node and SAML Version 1.0 Table of contents DOCUMENT HISTORY ...................................................................................... 2 TABLE OF CONTENTS ...................................................................................... 3 LIST OF FIGURES ........................................................................................... 5 LIST OF TABLES ............................................................................................. 6 1. INTRODUCTION ....................................................................................... 7 1.1. Document aims ............................................................................... 7 1.2. Document structure ......................................................................... 7 1.3.
    [Show full text]
  • Emergency Management Standards
    Emergency Management Standards HL7 WGM International Council May 2019 Elysa Jones, Chair OASIS Emergency Management Technical Committee Emergency Interoperability Member Section [email protected] Agenda ▪ What is OASIS ▪ Joint work with HL7 - Tracking emergency patients - Hospital availability 2 Internationally recognized ▪ EU classifies OASIS as “one of the top three ICT consortia”. ▪ EU Regulation 1025/2012 allows OASIS specs to be referenced in public procurement ▪ OASIS is permanent member of EC’s European Multi-Stakeholder Platform on ICT Standardization ▪ OASIS TC Process is ANSI-accredited. 3 Established presence, Current agenda ▪ Nonprofit consortium ▪ Founded 1993 ▪ Global 5,000+ participants 600+ orgs & individuals in 100+ countries ▪ Home of 70+ Technical Committees ▪ Broad portfolio of standards: security, privacy, Cloud, M2M, IoT, content technologies, energy, eGov, legal, emergency management, finance, Big Data, healthcare, + other areas identified by members 4 OASIS → de jure OASIS Standard Also Approved As: Advanced Message Queuing Protocol (AMQP) ISO/IEC 19464 ebXML Collaborative Partner Profile Agreement ISO 15000-1 ebXML Messaging Service Specification ISO 15000-2 ebXML Registry Information Model ISO 15000-3 ebXML Registry Services Specification ISO 15000-4 Security Assertion Markup Language (SAML) ITU-T Rec. X.1141 Extensible Access Control Markup Language (XACML) ITU-T Rec. X.1142 OpenDocument Format (ODF) ISO/IEC 26300 Common Alerting Protocol (CAP) ITU-T Rec. X.1303 Computer Graphics Metafile (WebCGM) W3C WebCGM
    [Show full text]
  • Implementation Experiences on IHE XUA and BPPC1 December 5, 2006
    Implementation Experiences On IHE XUA and BPPC1 December 5, 2006 Tuncay Namlı and Asuman Dogac Software Research and Development Center Middle East Technical University Ankara, Turkey The most up-to-date version of this document is available from http://www.srdc.metu.edu.tr/publications 1 This work is supported in part by the European Commission, eHealth Unit (http://ec.europa.eu/information_society/activities/health/index_en.htm) through the 027074 Saphire Project (http://www.srdc.metu.edu.tr/webpage/projects/saphire/) and by the Scientific and Technical Research Council of Turkey (TUBITAK) through the Project No. EEEAG 105E133. LIST OF FIGURES.......................................................................................................................................2 LIST OF ACRONYMS.................................................................................................................................3 1 OVERVIEW.........................................................................................................................................3 2 EXECUTIVE SUMMARY .................................................................................................................4 3 THE IMPLEMENTATION SCENARIO..........................................................................................5 4 TRUST MODEL..................................................................................................................................7 4.1 TRUST MODEL IN AN AFFINITY DOMAIN.......................................................................................7
    [Show full text]
  • Ebxml Registry Services and Protocols Version
    1 2 ebXML Registry Services and Protocols 3 Version 3.0 4 Committee Draft Specification 02, 15 March, 2005 5 Document identifier: 6 regrep-rs-3.0-cd-02 7 Location: 8 http://www.oasis-open.org/committees/regrep/documents/3.0/specs/regrep-rs-3.0-cd-02.pdf 9 Editors: Name Affiliation Sally Fuger Individual Farrukh Najmi Sun Microsystems Nikola Stojanovic RosettaNet 10 11 Contributors: Name Affiliation Diego Ballve Individual Ivan Bedini France Telecom Kathryn Breininger The Boeing Company Joseph Chiusano Booz Allen Hamilton Peter Kacandes Adobe Systems Paul Macias LMI Government Consulting Carl Mattocks CHECKMi Matthew MacKenzie Adobe Systems Monica Martin Sun Microsystems Richard Martell Galdos Systems Inc Duane Nickull Adobe Systems Goran Zugic ebXMLsoft Inc. 12 13 Abstract: 14 This document defines the services and protocols for an ebXML Registry 15 A separate document, ebXML Registry: Information Model [ebRIM], defines the types of metadata 16 and content that can be stored in an ebXML Registry. 17 Status: 18 This document is an OASIS ebXML Registry Technical Committee Approved Draft Specification. 19 Committee members should send comments on this specification to the [email protected] 20 open.org list. Others should subscribe to and send comments to the [email protected] 21 open.org list. To subscribe, send an email message to [email protected] 22 open.org with the word "subscribe" as the body of the message. 23 For information on whether any patents have been disclosed that may be essential to 24 implementing this specification, and any offers of patent licensing terms, please refer to the 25 Intellectual Property Rights section of the OASIS ebXML Registry TC web page (http://www.oasis- 26 open.org/committees/regrep/).
    [Show full text]
  • Accessible Common Alerting Protocol Radio Data System Demonstration: Gulf Coast States Final Report August 2014 1 TABLE of CONTENTS
    Accessible Common Alerting Protocol Radio Data System Demonstration: Gulf Coast States Final Report August 2014 1 TABLE OF CONTENTS 1 TABLE OF CONTENTS ....................................................................................................................................................................... 2 2 ACKNOWLEDGEMENTS .................................................................................................................................................................... 5 3 EXECUTIVE SUMMARY ..................................................................................................................................................................... 6 4 INTRODUCTION .................................................................................................................................................................................. 8 5 METHODOLOGY.................................................................................................................................................................................. 9 6 TECHNICAL CONFIGURATIONS AND TESTING ..................................................................................................................... 10 6.1 Hardware, Ingest Software (INSO) and Software to Monitor INSO (WATCHINSO) ...................................................... 10 Hardware ................................................................................................................................................................................
    [Show full text]