ANSI ATIS 0500007-2008 Emergancy Information Services Interface (EISI) Implemented with Web Services.pdf

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-0500007.2008(R2013) Emergency Information Services Interfaces (EISI) Implemented with Web Services As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-p

2、ressing business priorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fas

3、t-track development lifecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Org

4、anizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). F

5、or more information, visit. AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the A

6、NSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effor

7、t be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not confor

8、ming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the

9、name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the Amer

10、ican National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer

11、 Pedigo (VA) Electronic and Telecommunications Jidem Mok Embarq Sandra Lott Christina Smith (VA) Ericsson Walter White Tina Diem (VA) Greater Harris County 9-1-1 Mike Hayes Stan Heffernan (VA) Organization Represented Name of Representative HBF Group Jim Shepard John Sines (VA) Intrado Christian Mil

12、iteau Robert Sherry (VA) L. Robert Kimball Joe McCarnley Gordon VanAucken (VA) The Melcher Group, LLC Jim Goerke National Emergency Number Association (NENA) Ron Bloom Roger Hixson (VA) NeuStar Barry Bishop Openwave Mark Drennan Steve Howser (VA) Polaris Wireless Martin Feuerstein Bob Dressler (VA)

13、Qualcomm Jim DeLoach Randy Gellens (VA) Qwest Mike Fargano Steve Chittick (VA) Red Sky Bill Mertka Brian Schwarz (VA) Rural Cellular Association (RCA) Art Prest Tim Raven (VA) Sprint Robert Montgomery Jim Propst (VA) ATIS-0500006.2008 iii Organization Represented Name of Representative Tarrant Count

14、y 9-1-1 District Bill Horne Kevin Kleck (VA) Telecommunication Systems (TCS) Richard Diskinson Roger Marshall (VA) TechnoCom Khaled Dessouky Janice Partyka (VA) Telcordia Anand SkundiEric Arolickl (VA) Texas Commission on State Emergency Communications Paul Mallett T-Mobile USA Jim Nixon Organizatio

15、n Represented Name of Representative TruePosition Gustavo Pavon Matthew Ward (VA) Verizon Maureen Napolitano Verizon Wireless Susan Sherwood Robert Uwaszji (VA) Virginia Information Technologies Agency (VITA) Steve Marzolf Dorothy Spears-Dean (VA) Vonage Martin Hakim Din Washington DC PSAP Susan Nel

16、son Washington State Military Department EMD 9-1-1 Davis Irwin Bob Oenning (VA) Windstream Jackson Mobbs The Next Generation Emergency Services (NGES) Subcommittee was responsible for the development of this document. ATIS-0500007.2008 iv TABLE OF CONTENTS 1 INTRODUCTION/EXECUTIVE SUMMARY. 1 1.1 OVE

17、RCOMING LEGACY SHORTCOMINGS . 1 1.2 EISI AND WEB SERVICES . 2 1.3 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 3 1.4 WEB SERVICE DESCRIPTION LANGUAGE (WSDL) 3 1.5 UNIVERSAL DESCRIPTION, DISCOVERY, INTEGRATION (UDDI) 3 1.6 EISI SERVICE CATEGORIES 3 1.7 EISI CONFORMANCE OVERVIEW 4 2 SCOPE, PURPOSE, 2) a set o

18、f encoding rules for expressing instances of application-defined datatypes; and 3) a convention for representing remote procedure calls and responses. 1.4 Web Service Description Language (WSDL) A WSDL is an XML document that describes the functional characteristics of the services offered. It descr

19、ibes the operations the service has available, the messages the service will accept, and the protocol of the service. 1.5 Universal Description, Discovery, Integration (UDDI) UDDI is the service registry. The UDDI registry contains the information about entities and the services they offer. UDDI spe

20、cifications use XML, are wrapped in a SOAP envelope, and use HTTP as the transport. Collectively these elements make up a web service. These technologies are both platform and programming language independent. 1.6 EISI Service Categories There are three categories of services that may exist on an ES

21、Net. They are: 1) Specified; 2) Un-specified; and 3) Out of Scope. 1. Specified Services: Services are listed in UDDI along with the WSDL A service for which WSDL is defined in the EISI document The service interaction is defined in the EISI document The EISI ALI Service is defined in a separate ANS

22、 document 2. Un-specified Services: Services are listed in UDDI along with the WSDL A service for which WSDL is not defined in the EISI document The service interaction is not defined in the EISI document 3. Out of Scope Services: Services that leverage ESNets robust and secure IP network, but is no

23、t defined in this document This can be proprietary, open, or a standard-based solution Most likely, not a web service ATIS-0500007.2008 The EISI Document is written in a modular form making it straightforward to extract the Service requirements for specified and un-specified services. 1.7 EISI Confo

24、rmance Overview EISI Conformance is about guaranteeing consistent behavior of EISI entities across any ESNet instance. It is also about providing potential implementers precise indications on which EISI features need to be supported and under what conditions. EISI establishes the set of functional f

25、eatures1that service providers and non RG-mediated2service consumers should support in order to guarantee consistent behavior. EISI can be viewed as a contract of sorts. As for any contract, it is desirable to precisely state what “contractual terms similarly for EISI provider entity. From the above

26、 definition, ECES and EPES are EISI entities. Their names, which include “consumer” and “provider” concepts, are representative to the overall expected behavior of those entities. However, this in no way limits their behavior as EISI consumers and/or providers. The diagram below illustrates the EISI

27、 provider and consumer concepts. An EPES instance provides some sample service to an ECES instance. This service happens to be a high-availability service. Figure 5 - Service Provider and Consumer Concepts The Service Registry entity is shown as an EISI provider entity and as such it is subject to E

28、ISI Conformance. Note that required support for the Identity Management feature has been left out to keep the diagram simple. The dashed line labeled “Service-specific interactions” links those parts of EPES and ECES behavior which implement the sample service provider and consumer roles respectivel

29、y. 5 ABBREVIATIONS, ACRONYMS, however, the WSDL is still published in the UDDI. 7.2.3 Service Discovery Service Discovery is dynamic. After an EPES, ECES, or RG (operating as an ECES) publishes to the UDDI, then the service can be discovered dynamically by EPES, ECES, or RG. ECESs, EPES, or RG (oper

30、ating as an ECES) periodically query the UDDI to interrogate for new services offered by an EPES, changes to existing services, and new services offered by new EPESs, ECESs, or RGs. Service Discovery is not limited to ECESs, RGs, and EPES. Any entity inside the ESNet and authorized entities outside

31、of the ESNet may also discover services dynamically. 7.2.4 Emergency Event An Emergency Event is an ECES (to EPES) or RG (operating as an ECES to EPES) initiated service. For mediated services, an Emergency Event is defined as an emergency request being received by the CESE, querying the RG for even

32、t information and terminating the request after handling has been completed. The RG, acting as an ECES, may forward the Emergency Event request to an EPES. For non-mediated services, the ECES initiates the Emergency Event. Emergency Event scenarios describe the various types of emergency call handli

33、ng events (wireline, wireless, etc.) in the ESNet context. A 9-1-1 call comes into the ESNE and routes to the PSAP. The incoming call typically includes both voice and ANI. For mediated services, once the CESE receives the call, it issues an Emergency Event request to the RG across interface A1 (the

34、 ESMI). The RG (operating as an ECES), in turn queries the appropriate EPES using the EISI interface. For non-mediated services, the ECES function at the PSAP issues an Emergency Event request directly to the EPES. Information for an Emergency Event may be segmented where some information is availab

35、le immediately; other information is delayed for a small period of time; and even more additional information becomes available later during the emergency event. Therefore, it is useful for the EISI to ATIS-0500007.2008 16 support multiple responses to a single Emergency Event request. For example w

36、ith Wireless Phase 2 data, the ESNet could make the Phase 1 information available immediately and provide the Phase 2 (latitude and longitude) data at a later (perhaps several seconds) time. Queries for various types of emergency calls (e.g., wireline vs. wireless) require different response times.

37、Therefore, the EISI must support the overlapping of queries and responses for multiple events. For example, responses from a wireless Phase 2 query may take longer to respond than queries for wireline information. The EISI must create context for a given Emergency Event. For mediated services, the R

38、G assigns an Emergency Event Identifier (EEID) that will be unique to this Emergency Event, and will be delivered in all messages from the ESNet (via the RG) to the CESE for the given emergency event or directly to the ECES. 7.2.5 Event Bridging Emergency events are sometimes bridged from one PSAP t

39、o another. The ECES or RG (operating as an ECES) may notify the EPES that is providing an Emergency Information Service of a bridge. 7.2.6 Information Discrepancy Initiation An information discrepancy occurs when what is displayed at the PSAP is different than what is learned from the caller. This c

40、apability allows the PSAP to immediately create an information (e.g., ALI) discrepancy report and forward that report to an entity that will initiate corrective actions. This transactional primitive within the ESNet allows the PSAP CPE vendors to implement an information discrepancy report with a si

41、mple operation. For mediated services the CESE forwards the discrepancy to a RG, and the RG (acting as a ECES) forwards the report to the appropriate EPES. For non-mediated services, the ECES sends the information discrepancy directly to the EPES. Similar concepts may handle misroute instances and o

42、ther information inconsistencies. 7.2.7 ESNet Initiated Services For non-mediated services, EPES in the ESNet may initiate some services directly to the ECES. These services may be directed to a single ECES, a group of registered ECESs, or all ECESs depending upon the service. For mediated services,

43、 EPES in the ESNet may initiate some services via the RG to the CESE. The RG forwards the request to the appropriate CESE(s). These services may be directed to a single CESE, a group of registered CESEs, or all CESEs depending upon the service. 7.2.8 Notification Messages to ECES For non-mediated se

44、rvice, EPES may send unsolicited notification messages to one or more ECES. For mediated services, the EPES may send unsolicited notification messages to one or more RGs. The RG forwards the request to the appropriate CESE(s).The EPES may provide an enhanced service, national emergency service or so

45、me other notification services. The authorized public safety agencies may obtain a list of currently registered users from an ECES and target its messages to an individual user, all users or a group of (administered) users. The message may contain text and/or binary data (e.g., pictures, videos). AT

46、IS-0500007.2008 17 7.2.9 Notification Messages from ECES ECES may send unsolicited notification messages to one or more EPES. ECES may want to forward a notification message to an EPES agency. The ECES may also want to forward a response to a notification message that an EPES had previously sent to

47、update the status of an Emergency Incident. 7.2.10 Reports and Status Because the ECES, RG (operating as an ECES), and EPES all play an important role in managing and handling emergency events, it is useful for the EISI to support capabilities that allow one entity to interrogate the other regarding

48、 status information. Such information may play a role in troubleshooting problems or providing reports and statistical information. 7.2.11 ECES Event Status The EISI allows the EPES to query emergency event status information from a given ECES. This allows the ESNet to properly coordinate applicatio

49、ns that depend on event processing status and to manage ESNet resources that are allocated on a per event basis. Event monitoring allows the EPES to query an ECES and request current event activity at the given ECES. The provider may then reconcile active events status within the ESNet. 7.2.12 ESNet Event Status The EISI should allow the ECES to query event status information from an EPES. This allows the ECES to obtain pertinent data that resides within the ESNet. 7.2.13 ECES Metrics Reporting The ESNet may provide a metrics collectio