DOCSLIB.ORG

NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (I3)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (I3) NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3) NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3) NENA 08-002, Version 1.0, December 18, 2007 Prepared by: National Emergency Number Association (NENA) Technical Committee Chairs Published by NENA Printed in USA NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3) NENA 08-002 Version 1.0, December 18, 2007 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 NENA TECHNICAL STANDARD DOCUMENT (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.0 December 18, 2007 Page 2 of 121 NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3) NENA 08-002 Version 1.0, December 18, 2007 Acknowledgments: This document has been developed by the National Emergency Number Association (NENA) VoIP/Packet Technical Committee Long Term Definition Working Group. NENA recognizes the following industry experts and their companies for their contributions in development of this document. In addition, a larger number of work group members monitored the development of the document and commented occasionally on its contents. Members: Company Brian Rosen –Work Group Leader and NeuStar Technical Editor Nate Wilcox – VoIP/Packet Technical microDATA Chair Nadine B Abbott Telcordia Anand Akundi Telcordia Wayne Ballantyne Motorola Deborah Barclay Alcatel Lucent Marc Berryman Greater Harris County Tom Breen AT&T Guy Caron Bell Canada Pierre Desjardins Positron Brian Dupras Intrado Marc Linsner Cisco Roger Marshall TeleCommunication Systems, (TCS) Patty McCalmont Intrado Theresa Reese Telcordia Guy Roe Mapinfo Robert Sherry Intrado Version 1.0 December 18, 2007 Page 3 of 121 NENA Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3) NENA 08-002 Version 1.0, December 18, 2007 TABLE OF CONTENTS 1 EXECUTIVE OVERVIEW ............................................................................................................................... 8 2 INTRODUCTION .............................................................................................................................................. 9 2.1 OPERATIONAL IMPACTS SUMMARY .................................................................................................................. 9 2.2 DOCUMENT TERMINOLOGY .............................................................................................................................. 9 2.3 REASON FOR ISSUE/REISSUE ............................................................................................................................ 9 2.4 DATE COMPLIANCE ........................................................................................................................................ 10 2.5 ANTICIPATED TIMELINE ................................................................................................................................. 10 2.6 COSTS FACTORS ............................................................................................................................................. 10 2.7 COST RECOVERY CONSIDERATIONS ............................................................................................................... 10 2.8 ACRONYMS/ABBREVIATIONS/DEFINITIONS .................................................................................................... 11 2.9 INTELLECTUAL PROPERTY RIGHTS POLICY .................................................................................................... 14 3 TECHNICAL DESCRIPTION ....................................................................................................................... 15 3.1 SCOPE ............................................................................................................................................................ 17 4 ARCHITECTURE ........................................................................................................................................... 18 4.1 SYSTEM ARCHITECTURE ................................................................................................................................ 18 4.1.1 Assumptions .............................................................................................................................................. 18 4.1.2 Functional architecture ............................................................................................................................ 20 4.1.3 Example of possible physical architecture ............................................................................................... 24 4.1.4 Example Physical Architecture................................................................................................................. 25 4.1.5 Call Architecture ...................................................................................................................................... 26 4.1.5.1 Calls and Incidents .......................................................................................................................................... 26 4.2 RELATIONSHIP OF NENA I3 TO IETF STANDARDS ......................................................................................... 28 4.2.1 Location .................................................................................................................................................... 28 4.2.1.1 Location-by-Value (LbyV) ................................................................................................................... 30 4.2.1.2 Location-by-Reference (LbyR) ............................................................................................................. 30 4.2.2 Call Signaling ........................................................................................................................................... 30 4.2.3 Distinguishing an Emergency Call ........................................................................................................... 32 4.2.4 Routing of IP-based Emergency Calls in a generic IETF SIP originating network ................................. 33 4.2.5 Generic SIP as an Emergency Services IP Network ................................................................................. 35 4.2.5.1 Simple ESInet ................................................................................................................................................. 35 4.2.5.2 Multiple ESRPs in an ESInet Architecture ..................................................................................................... 36 4.2.5.3 Hierarchical ESInet Architectures – “Network of Networks” ......................................................................... 37 4.2.5.4 Internal ESRP functions .................................................................................................................................. 38 4.2.6 End to End generic SIP emergency call architecture ............................................................................... 39 4.3 RELATIONSHIP OF NENA I3 TO IMS STANDARDS WITHIN 3GPP .................................................................... 40 4.3.1 3GPP Functional Entities ......................................................................................................................... 40 4.3.2 Additional Functional Entities in Support of an IMS-based ESInet ......................................................... 41 4.3.3 Emergency Call Routing in an IMS origination network ......................................................................... 42 4.3.4 IMS as an Emergency Services IP Network .............................................................................................
Load more

Recommended publications
  • 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]
  • 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]
  • 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]
  • 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]
  • IPAWS September 2016 Meeting Materials
    STATEWIDE EMERGENCY COMMUNICATIONS BOARD INTEGRATED PUBLIC WARNING AND ALERT SYSTEM COMMITTEE Thursday, September 15, 2016 1:00 p.m. – 3:00 p.m. Chair: Ulie Seal WEBEX connection information below: Meeting number: 746 150 047 Meeting password: password Call-in toll-free number: 1-888-742-5095 Conference Code: 172 933 5103 MEETING AGENDA Call to Order Approval of Today’s Agenda Approval of Previous Meeting’s Minutes • July 2016 Reports of Standing Committees • Policy – du Bois / McDonald Highlights from the Advanced Warning and Response Network (AWARN) The Federal Communications Commission (FCC) tasked Communications, Security, • Reliability, and Interoperability Council (CSRIC) Working Group 3 (WG3) with • recommending best practices for the delivery of Multilingual Emergency Alert System (EAS) and emergency information. • Infrastructure – Dooley Highlight Items that need to be addressed in the next state warning plan Information on the Nationwide EAS test scheduled for 28 September. • • Public• Information – Williams Education and Outreach Workgroup under the SECB Steering Committee Committee Items• Reports Old Business New Business Other Business Announcements • Speaking Engagements Adjourn STATEWIDE EMERGENCY COMMUNICATIONS BOARD INTEGRATED PUBLIC ALERT AND WARNING SYSTEM July 20, 2016 MEETING MINUTES ____________________________________________________________________________________________________________________ ATTENDANCE MEMBERS, REPRESENTING PRESENT (Highlighted): Chair: Ulie Seal, MN Fire Chiefs Association Vice Chair: Michael
    [Show full text]
  • Common Alerting Protocol Alert Origination Tools Technology Guide
    System Assessment and Validation for Emergency Responders (SAVER) Common Alerting Protocol Alert Origination Tools Technology Guide February 2015 Prepared by Space and Naval Warfare Systems Center Atlantic Approved for public release, distribution is unlimited. The Common Alerting Protocol Alert Origination Tools Technology Guide was funded under Interagency Agreement No. HSHQPM-13-X-00024 from the U.S. Department of Homeland Security, Science and Technology Directorate. The views and opinions of authors expressed herein do not necessarily reflect those of the U.S. Government. Reference herein to any specific commercial products, processes, or services by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the U.S. Government. The information and statements contained herein shall not be used for the purposes of advertising, nor to imply the endorsement or recommendation of the U.S. Government. With respect to documentation contained herein, neither the U.S. Government nor any of its employees make any warranty, express or implied, including but not limited to the warranties of merchantability and fitness for a particular purpose. Further, neither the U.S. Government nor any of its employees assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed; nor do they represent that its use would not infringe privately owned rights. The cover photo was provided by
    [Show full text]
  • Introducing Common Alerting Protocol (CAP)
    Common Alerting Protocol (CAP) Presentation Outline 101.1 Opportunity and Challenge 101.2 Alerting Authorities 101.3 Benefits of CAP 101.4 Features of a CAP Message 101.5 CAP-enabled Alerting Systems 101.6 CAP Alert Hubs-- Free, Fast, Reliable, Secure CAP-101 Introducing CAP 2 Warnings Via Commercial Media Commercial TV and radio send warnings as "crawl text" and/or audio What about online media users? CAP-101 Introducing CAP 3 An Opportunity Online media (e.g, Google, the Federation for Internet Alerts...) are using their own capabilities to help alerting authorities send warnings to people using the Internet, at no charge CAP-101 Introducing CAP 4 The Challenge of Alerting All governments have various public alerting systems: • Earthquakes/tsunami by e-mail, news wire, Web sites, pagers, telephone calls ... • Weather by news wire, fax, radio, television, e-mail, SMS text on cell phones ... • Fire, Security, Transportation by television, radio, sirens, police with bullhorns... CAP-101 Introducing CAP 5 Across communities, nations, regions— a “public alerting patchwork” Another City / Province / Country Another City / Province / Country Your City / Province / Country Storm Sirens Earthquake Radio Tsunami Television Fax Fire Cell / SMS Volcano CAP-101 Introducing CAP 6 What is CAP? The Common Alerting Protocol (CAP) is a standard message format designed for All-Media, All-Hazard, communications: – over any and all media (television, radio, telephone, fax, highway signs, e-mail, Web sites, RSS "Blogs", ...) – about any and all kinds of hazard
    [Show full text]
  • D42.21 - Specification Documentation and Deployment of the Prototype and Final Integration Platform
    Driving Innovation in Crisis Management for European Resilience D42.21 - Specification documentation and deployment of the prototype and final integration platform Grant agreement number: 607798 Due date of deliverable: M11 Start date of the project: 2014-05-01 Actual submission date: 2015-06-30 Duration: 54 months Lead Beneficiary: ATOS (Jaime Martín, German Herrero and Ignacio Llamas) Contributing beneficiaries: DLR (Julia Zillies) FRQ (Gerhard Zuba, Thomas Obritzhauser) GMV (Héctor Naranjo, Raúl Valencia) JRC (Daniele Galliano, Francesco Mugnai) TCS (Bruno Quere, Edith Felix, Laurent Dubost) Keywords: Architecture, portfolio of tools, requirements, experiments, integration, interoperability, SOA, Operational environment, interfaces, Common Information Space Dissemination level: PU ☒ PP ☐ RE ☐ CO ☐ D42.21 Specification documentation and deployment of the prototype and final integration platform Release History Version Date Description Release by V0.1 1-May-2015 Initial Version / Table of Contents ATOS V0.2 12-May-2015 Agreed Table of Contents ATOS V0.3 2-June-2015 Content incorporated from ATOS, FRQ and ATOS GMV V0.4 12-June-2015 Some updated in structure and content ATOS V0.5 15-June-2015 Updates in contents from partners ATOS V0.6 22-June-2015 First version ready for review ATOS V1.0 30-June-2015 Final Version ATOS ©DRIVER Consortium 2 June 2015 D42.21 Specification documentation and deployment of the prototype and final integration platform Table of Contents Executive Summary ................................................................................................................................
    [Show full text]
  • Aplikacje Webowe
    Aplikacje webowe Bezpieczeństwo systemów komputerowych semestr zimowy, 2020/21 Przypomnieć - jak ktoś nie rozumie, niech pinguje, bo nie widzę twarzy Directory Traversal - co robić? ● opcja 1: whitelist znaków ([a-ZA-Z0-9]*) ● opcja 2: czy_plik_jest_w_katalogu() ● opcja 3: nie trzymać plików w systemie plików ○ dygresja: inne zalety, np. skalowalność Directory Traversal - co robić? File file = new File(BASE_DIRECTORY, userInput); if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) { ... } https://portswigger.net/web-security/file-path-traversal Rozgrzewka http://bsk2020.kazet.cc:8018/post/1137 Zadanie 6 … if (isset($_GET['manpage'])) { echo(system("man " . $_GET['manpage'])); } … http://bsk2020.kazet.cc:8006/ Gra w banowanie Blacklist nie działa (i to jest dość ogólna zasada security) Command Injection - co robić? ● opcja 0: biblioteka zamiast poleceń shellowych ● opcja 1: własne nazwy plików ● opcja 2: whitelist znaków ([a-ZA-Z0-9]*) ● opcja 3 wbudowane w język programowania mechanizmy zabezpieczeń (typu subprocess.call([‘ls’, …])) opinia (https://portswigger.net/web-security/os-command-injection): “Never attempt to sanitize input by escaping shell metacharacters. In practice, this is just too error-prone and vulnerable to being bypassed by a skilled attacker.” Bazy danych if (isset($_GET['username']) and isset($_GET['password'])) { $username = (string) $_GET['username']; $password = (string) $_GET['password']; $result = mysqli_query( $link, "SELECT * FROM users WHERE username='" . $username . "' AND password='" . $password . "';"); if (mysqli_num_rows($result) > 0) { echo "Logged in successfully. Flag is: (...)"; } } http://bsk2020.kazet.cc:8008/ SQL Injection ● Występuje coraz rzadziej ● Nie trzeba pisać ręcznie zapytań żeby zbudować formularz logowania… ● ...albo dowolny inny kawałek aplikacji webowej ● Ale nadal czasem trzeba napisać skomplikowane, ręcznie zoptymalizowane zapytanie do bazy na kilkadziesiąt linijek - i wtedy już SQLi jest możliwe Te same problemy co przy command injection - nie pisać samemu filtrowania, wykorzystać wbudowane w framework.
    [Show full text]
  • Standardized CAP Messages from GITEWS DSS – How They Are Useful for National and International Warning Message Dissemination
    Standardized CAP Messages from GITEWS DSS – how they are useful for national and international warning message dissemination DEWS Midterm Conference – Potsdam July 2009 Interoperability Issues – System for Interoperable Advisory and Warning Centres T. Steinmetz, U. Raape, T. Riedlinger German Aerospace Center (DLR) Overview Status Quo in Interoperation of GITEWS/InaTEWS How do we use CAP? What messages are needed in the InaTEWS context? Standardization in GITEWS DSS warning dissemination using CAP What is CAP? How does it improve the dissemination process? Proposals for interoperable IOTWS RTWP message exchange InaTEWS Open Architecture to support Integration of Components Sensors Sensor Systems Sensor System X SeisComP3 CGPS Tide Gauges OBU / PACT GPS-Bouys Earth Observation Sensor System Integration Simulation Situation Assessment and Decision Support System Dissemination ITB Systems BMKG 5in1 / 6in1 System Risk- & Vulnerability Geospatial 2wCOM Modelling Data Repository FM RDS System Additional Tsunami Scenarios Additional Analysis / Processing Capabilities, additional Data Sources Message Dissemination CAP Message BMKG Warning BMKG 5-in-1 Recipients Dissemination DSS Message Generation CAP Message FM-RDS 2wCom Warning National Recipients Dissemination CAP Message RTWP RTWP Subscribers Dissemination of Warning Products: dissemination channels DSS has interfaces to different dissemination systems Document server (web accessible) Dissemination system receives 2wcom receiver the warning product from the DSS 2wcom receiver Broadcast antenna
    [Show full text]
  • ITU-T Rec. X.1303 Bis (03/2014) Common Alerting Protocol (CAP 1.2)
    International Telecommunication Union ITU-T X.1303 bis TELECOMMUNICATION (03/2014) STANDARDIZATION SECTOR OF ITU SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY Secure applications and services – Emergency communications Common alerting protocol (CAP 1.2) Recommendation ITU-T X.1303 bis ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY PUBLIC DATA NETWORKS X.1–X.199 OPEN SYSTEMS INTERCONNECTION X.200–X.299 INTERWORKING BETWEEN NETWORKS X.300–X.399 MESSAGE HANDLING SYSTEMS X.400–X.499 DIRECTORY X.500–X.599 OSI NETWORKING AND SYSTEM ASPECTS X.600–X.699 OSI MANAGEMENT X.700–X.799 SECURITY X.800–X.849 OSI APPLICATIONS X.850–X.899 OPEN DISTRIBUTED PROCESSING X.900–X.999 INFORMATION AND NETWORK SECURITY General security aspects X.1000–X.1029 Network security X.1030–X.1049 Security management X.1050–X.1069 Telebiometrics X.1080–X.1099 SECURE APPLICATIONS AND SERVICES Multicast security X.1100–X.1109 Home network security X.1110–X.1119 Mobile security X.1120–X.1139 Web security X.1140–X.1149 Security protocols X.1150–X.1159 Peer-to-peer security X.1160–X.1169 Networked ID security X.1170–X.1179 IPTV security X.1180–X.1199 CYBERSPACE SECURITY Cybersecurity X.1200–X.1229 Countering spam X.1230–X.1249 Identity management X.1250–X.1279 SECURE APPLICATIONS AND SERVICES Emergency communications X.1300–X.1309 Ubiquitous sensor network security X.1310–X.1339 CYBERSECURITY INFORMATION EXCHANGE Overview of cybersecurity X.1500–X.1519 Vulnerability/state exchange X.1520–X.1539 Event/incident/heuristics
    [Show full text]