ANSI ATIS 0500002-2008 Emergency Services Messaging Interface (ESMI).pdf

《ANSI ATIS 0500002-2008 Emergency Services Messaging Interface (ESMI).pdf》由会员分享，可在线阅读，更多相关《ANSI ATIS 0500002-2008 Emergency Services Messaging Interface (ESMI).pdf（106页珍藏版）》请在麦多课文档分享上搜索。

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-0500002.2008(R2013) Emergency Services Messaging Interface (ESMI) As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing business priorities. Thro

2、ugh 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 fast-track development lifecycle fro

3、m 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 Organizational Partner for the 3rd G

4、eneration 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). For more information, visit. AMERI

5、CAN 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 ANSI Board of Standards Review, su

6、bstantial 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 effort be made towards their resolutio

7、n. 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 conforming to the standards. The Americ

8、an 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 name of the American National Sta

9、ndards 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 American National Standards Institute

10、 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 a TIA/EIA/J-STD-036-A network el

11、ement shown here as a specific example of the EPES logical entity.ESNE Emergency Services Network Entity; a TIA/EIA/J-STD-036-A network element shown here as a specific example of the Emergency Request Sources logical entity.InterfacesA1 Emergency Services Messaging Interface (ESMI)A2 Emergency Info

12、rmation Services Interface (EISI)A3 ESNet to ESNet Interface (ENEN)Remarks- Interfaces depicted as dotted lines linking entities are defined elsewhere- The (1:n) notation means “one or more”instances- A1,A2 and A3 interfaces have cardinality 1:1 ESNet instance(1:n)PSAP Other(s) ESMEEntities Providin

13、gEmergency Services(EPES)A1A1ESNECESE(1:n)RG(1:n)RG(1:n)A3A2A1A2ESNet instance(1:n)A1Emergency RequestSourcesRG(1:n)CESE(1:n)Network Reference ModelPSAPCESE(1:n)PSAP, OthersECES(1:n)A2Figure 2: Network Reference Model Logical Entities Conforming Emergency Services Entity (CESE): o The client side of

14、 the Emergency Services Messaging Interface. o It is thought of as residing on the premises of an agency such as a PSAP or participating organization. The design of a CESE is beyond the scope of this specification. Response Gateway (RG): o The server side of the Emergency Services Messaging Interfac

15、e. o The RG does not host ESNet services itself, but operates as a proxy to “back net” functions provided by the Emergency Services Network. For example, the RG may provide interworking to an ALI database to retrieve ALI. The design of the RG and “back net” functions is beyond the scope of this spec

16、ification. Emergency Services Network Entity (ESNE): o A network element defined in TIA/EIA/J-STD-036-A. ATIS-0500002.2008 8o The ESNE routes and processes the voice band portion of the emergency call. This is composed of selective routers (also known as Routing, Bridging and Transfer switches). The

17、 structure of the Emergency Services Network is beyond the scope of this standard. Emergency Services Message Entity (ESME): o A network element defined in TIA/EIA/J-STD-036-A. o The ESME routes and processes the out-of-band messages related to emergency calls. This may be incorporated into Automati

18、c Location Identification (ALI) database engines. The structure of the ESME is beyond the scope of this standard. Entities Providing Emergency Services (EPES): o A generic term representing a functional entity that provides data and/or services in support of Emergency Events. o For the purposes of t

19、he ESMI protocol, a specific EPES is a service that is coordinated via ESMI by either being invoked or otherwise made available to one or more CESEs. o Specific EPES may be invoked and deliver services in ways beyond the scope of the ESMI. Entities Consuming Emergency Services (ECES): o A generic te

20、rm representing a functional entity that consumes data and/or services in support of emergency services. o For the purposes of the EISI protocol, a specific ECES accesses services that are not mediated (i.e., via RG), but are invoked or otherwise made available from one or more EPESs. Enhanced Servi

21、ce: o A generic term representing a functional entity that provisions a service that is ancillary or complementary to Emergency Information Services. o For the purpose of the ESMI protocol, Enhanced Services are handled similarly to Emergency Information Services. 6.1 Example Scenarios The following

22、 scenarios illustrate the use of the Emergency Services Messaging Interface. They are not intended to be an all inclusive set of services and functionalities. 6.1.1 CESE Registration/Authentication The CESE will authenticate as needed prior to utilizing services. Additional authentication may be req

23、uired based on the specific services being invoked. The CESE must register and initialize with the ESNet. This occurs either the first time the CESE connects to the RG or on a re-initialization after a complete communication failure. The CESE sends a connection initialization message to the RG. This

24、 initialization message contains but is not limited to the CESE entity identifier, authorization credentials, and message set version number. ATIS-0500002.2008 9Once the CESE is authenticated, a communication channel is established between the CESE and the RG. The message exchange sequence between t

25、he CESE and RG is specified in the Stage 2 and Stage 3 sections of this document. 6.1.2 CESE Initiated Services Once initialized, the CESE may request services from the ESNet. The CESE may also initiate and manage services through the RG. 6.1.3 Emergency Event An Emergency Event is one example of a

26、CESE initiated service. An Emergency Event is defined as an emergency request being received by the CESE, querying for Emergency Event information, and terminating the request after handling has been completed. Emergency Event scenarios describe the various types of emergency call handling events (w

27、ireline, wireless, etc.) in the ESNet context. Referring to Figure 2, a 9-1-1 call comes into the ESNE and routes to the PSAP and the CESE. The incoming call typically includes both voice and ANI. Once the CESE receives the call, it issues an Emergency Event to the RG across interface A1 (the ESMI).

28、 The RG, in cooperation with other elements in the ESNet, retrieves information to be returned to the CESE. For example, the RG may obtain ALI information from the ALI database. Or it might interrogate other networks e.g., an MPC/GMLC in a wireless network or other Entities Providing Emergency Servi

29、ces (EPES). As the RG obtains information, it sends the information to the CESE across interface A1. Information for an Emergency Event may be segmented where some information is available immediately, other information is delayed for a small period of time, and yet additional information becomes av

30、ailable later during the Emergency Event. Therefore, it is useful for the Emergency Services Messaging Interface to support multiple responses to a single CESE Emergency Event request. For example, with Wireless Phase 2 data, the ESNet could make the Shell ALI record available immediately and provid

31、e the latitude and longitude at a later (perhaps several seconds) time. Queries for various types of emergency calls (e.g., wireline vs. wireless) require different response times. Therefore, the Emergency Services Messaging Interface must support the overlapping of queries and responses for multipl

32、e Emergency Events. For example, responses from a wireless Phase 2 query may take longer to respond than queries for wireline information. The ESMI must create context for a given Emergency Event. The ESNet assigns an Emergency Event Identifier (EEID) that will be unique to this Emergency Event acro

33、ss the ESNet and will be delivered in all messages from the ESNet (via the RG) to the CESE for the given Emergency Event. As mentioned, an Emergency Event is bracketed by the origination of an emergency request and the termination of processing at the CESE. The CESE notifies the RG via an ESMI messa

34、ge when the CESEs participation in the Emergency Event is complete. The Emergency Event Complete message signifies to the RG and ESNet that no additional information is to be sent to the CESE regarding this Emergency Event and related services for this emergency Event with respect to this particular

35、 CESE are to be completed. ATIS-0500002.2008 106.1.4 CESE Emergency Event Bridging Emergency Events are sometimes bridged from one CESE to another. The CESE may notify the RG and/or an Emergency Information Service of a bridge. At any time during the Emergency Event, local notes entered by the Call

36、Taker from the originating CESE may be sent to the ESNet for future access when the bridged-to CESE queries for information. 6.1.5 CESE Information Discrepancy Initiation An information discrepancy occurs when what is received at the CESE is different than what is learned from the caller. This capab

37、ility allows a CESE 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 simple o

38、peration. Similar concepts may handle misroute instances and other information inconsistencies. 6.1.6 ESNet Initiated Services Authorized agencies on the ESNet may initiate some services via the RG to the CESE. These services may be directed to a single CESE, a group of registered CESEs, or all CESE

39、s depending upon the service. 6.1.7 Notification Messages to CESE Authorized agencies may send unsolicited notification messages to one or more CESEs or end users. The agency may provide an enhanced service, national emergency service, or some other notification services. The authorized agencies may

40、 obtain a list of currently registered users from a CESE 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). 6.1.8 Reports & Status Because the CESE and RG both play an important role i

41、n managing and handling Emergency Events, it is useful for the Emergency Services Messaging Interface to support capabilities that allow one entity to interrogate the other regarding status information. Such information may play a role in troubleshooting problems or providing reports and statistical

42、 information. 6.1.9 CESE Emergency Event Status The Emergency Services Messaging Interface allows the RG to query Emergency Event status information from a given CESE. This allows the ESNet to properly coordinate applications that depend on Emergency Event processing status and to manage ESNet resou

43、rces that are allocated on a per Emergency Event basis. Emergency Event monitoring allows the RG to query a CESE and request ATIS-0500002.2008 11current Emergency Event activity at the given CESE. The provider may then reconcile active Emergency Events status within the ESNet. 6.1.10 ESNet Emergency

44、 Event Status The Emergency Services Messaging Interface should allow the CESE to query Emergency Event status information from a RG. This allows the CESE to obtain pertinent data that resides within the ESNet. 6.1.11 Managing & Monitoring the Emergency Services Messaging Interface The interface bet

45、ween CESE and ESNet is monitored for availability at both the physical and application level protocol. This allows the CESE and RG to report communication failures including the inability for either entity to properly communicate and respond to application level messages. 6.1.12 Communications Integ

46、rity The integrity of the communications between the CESE and RG must be maintained at all levels of the protocol. At the application level, this may be through communications checks such as keep alive messages or other such mechanisms. 6.1.13 Component Management The communicating nodes (CESE and R

47、G) must be able to go out of service and return to service in a graceful manner. Therefore, in a connection oriented model, if a node is going to go out of service it should notify each node with which it is communicating. If it is the RG that is going out of service, then the CESE should reestablis

48、h communications to another RG as discussed in 6.1.1 6.1.14 Exercising Component Connections It is a good practice for communicating nodes to exercise the routes between them periodically. This allows early detection of problems e.g., transport service provider being down. Long-lived TCP connections

49、 become “stale”. When they become “stale”, it is usually not noticed by either communicating party until someone is trying to send a message. At that time, the client could react by attempting to reconnect, but there is a loss of efficiency, since the client was busy trying to send the message out in the first place. Now it is forced to wait until the connection is re-established. Meanwhile there could be new messages that the client would somehow need to buffer. To sum up, it is recommended to roll connections in a controlled fashion. Therefore, the CESE