Next Generation ESNet Arch Requirements - ATIS

Emergency Services Interconnection Forum (ESIF)Emergency Services Messaging Interface Task Force (“Task Force 34”)Contribution Title: Stage 2 Emergency Services Messaging Interface Analysis andDetailed Functional SpecificationContribution Number: [ESIF Administrator will fill in]Source:3030 WarrenvilleFourth Flr Room 304Lisle Il, 60532Technical Contact(s):Name: Bob SherryName: Mike NelsonPhone: (630) 300-2838 Phone: (720) 864 5157Fax:Fax:Email: rsherry@intrado.comEmail: mnelson@intrado.comAbstract:This contribution is the Stage 2 for ESMI.Recommendation:Copyright Statement:Each contribution or document submitted to an ATIS Forum or Committee is subject to an unlimitedperpetual, non-exclusive, royalty-free, world-wide right and license to ATIS of any copyrights in suchcontribution or document. This license includes the right to copy, publish and distribute thecontribution in any way, and to prepare derivative works that are based on or incorporate all or partof the contribution, the license to such derivative works to be of the same scope as the license of theoriginal contribution. For further information on ATIS Intellectual Property Policy, please see Section10 of the ATIS Operating Procedures (Version 2.0).

7 Stage 2 – Emergency Services Messaging Interface Analysis andDetailed Functional SpecificationThe ESMI includes two distinct interaction models. These interdependent models areimplemented as• Application Messages• Connection Negotiation MessagesApplication messages are those that, singularly or collectively, offer a service between theCESE and the ESNet through the RG.Connection Negotiation messages are used to set up and tear down the applicationconnections over which Emergency Services Messages are handled. ConnectionNegotiation messages allow coordinated manipulation of the persistent TCP/IP connectionbetween a Conforming Emergency Services Entity (CESE) and the ESNet ResponseGateways (RGs). This messaging structure enables application level messagingconnectivity and facilitates the dynamic nature of the Emergency Services Network.7.1 Application MessagesApplication messages can be associated with Emergency Events, management functions,and other services. Application messages occur within an Application Session in analready established application connection between a CESE and RG. Some messagesoccur within the context of an Emergency Event. Other messages (e.g. heartbeat, RGshutdown, broadcast, reports) are not associated with specific emergency events. It isassumed that a CESE has established an application connection as discussed in Section7.2.1 with an RG in the ESNet before any application messages pass between the CESEand the RG.It is expected that the RG provides a message gateway function and acts as an abstractionand point of concentration for messages and services that may originate elsewhere withinor behind the ESNet. After a connection has been successfully established, applicationlevelmessages for multiple events can flow between the CESE and RG until the CESEcloses the session. As noted earlier, the session between the CESE and RG mayrepresent one PSAP call taker position, multiple PSAP call taker positions, or another rolein emergency services management. The appropriate messages for a given role aredetermined by the application semantics and not by a different message set between agiven CESE and RG.2 Version 1 9/23/04

7.1.1 Application Management and Maintenance Messages7.1.1.1 CESE Initialization and CESE HeartbeatAfter a CESE-RG application connection has been established the first message the CESEsends is a heartbeat message to the RG. The RG returns an acknowledgement (ACKmessage) to the CESE (Steps 1 and 2 of Figure 7-1 can be used to illustrate the heartbeatsequence).In addition, at regular intervals, in the absence of other activity, the CESE sends aheartbeat message and receives an acknowledgement (ACK), thus demonstrating thatconnectivity is maintained and both applications are ready. The interval at which heartbeatsare to be sent must be configurable. If a configurable number of heartbeats are missed asobserved by the RG, an error condition is assumed. If an administratively-configurablenumber of heartbeat messages are unacknowledged as observed by the CESE, an errorcondition is assumed.CESE Sends: Heartbeat Message +ceseid+ Authentication Session Identifier (ASI)CESE Receives: Heartbeat ACKErrors:1. RG fails to acknowledge some administratively configurable number ofconsecutive heartbeats.2. RG fails to receive a heartbeat message after the configured interval andaccording to the no activity guidelines.CESERGApplication Session1. Heartbeat Message (includes CESEID and Application Session ID)2.ACKFigure 7-1 HeartbeatNotes: If an error occurs, a new connection must be established. Procedures will differdepending on whether it is the CESE or the RG that first detects the absence of aheartbeat.3 Version 1 9/23/04

1. If the RG detects the failure, then it closes its side of the connection and awaits anew connection attempt from the CESE.2. If the CESE detects the failure, it must close and reinitialize as if it is just cominginto service, per Section 7.2.1. The new application connection will most likely beestablished with a different RG.7.1.1.2 CESE LogoutA CESE sends a Logout message when it will be terminating its connection to the ESNet.The Logout message is intended when there is no other connection in place and there is noprospect of immediately initiating another connection.The Logout message is not usedwhen the CESE is rotating its connection from one RG to another via the acquiescesequence. The CESE sends this message before it closes its current connection to the RG(Shown by Steps 1 and 2 of Figure 7-2).The CESE Logout message does not have a corresponding Login message. If a CESElogs out or terminates its only ESNet connection abnormally and later requests a newconnection with an RG, the CESE is required to go through the initialization set up steps,as defined in Section 7.2.1, to supply the Authorization Session Identifier previouslygenerated by the ESNet.This Logout message allows a CESE to close the application connection withoutgenerating an alarm on the RG side.CESE Sends: Logout Message + ceseid + Authentication Session IdentifierCESE Receives: Logout ACKNotes:1. If the RG fails to acknowledge, the CESE may still shut down.2. The RG will continue to allow the CESE to initiate new events after the CESE hassent a logout message.3. Disconnecting in this way will not raise an alarm. If the CESE connection closesdown without a logout, an error condition is assumed.4. If the CESE connection stays up for some administratively-configurable time periodafter the logout message has been received and acknowledged by the RG, an errorcondition will be assumed.4 Version 1 9/23/04

CESERGApplication Session1. Logout Message (includes CESEID and Application Session ID)2.ACKFigure 7-2 CESE Logout7.1.1.3 RG ShutdownThe RG issues a Shutdown message when it determines that it must shut down the currentconnection. It will make a best effort to send an Acquiesce request (see 7.2.2) before itsends a Shutdown. Steps 1 and 2 of Figure 7-3 can be used to illustrate this scenario.Examples of when an RG will issue a shutdown message include: 1) the RG hasencountered a critical abnormal processing condition and must restart or 2) the RGmaintenance personnel are forcing the RG to take itself out of service for maintenancereasons.CESE Receives: Shutdown MessageCESE Sends: Shutdown ACKErrors: NoneNotes:1. The CESE should immediately acknowledge the shutdown message and enter theacquiesce sequence as discussed in Section 7.2.2 if it has not already done so. Itshould expect the current connection to close soon after receiving this message.2. Open Emergency Events, if not completed before the connection physicallyterminates, will have to be re-established when the CESE re-establishes theconnection with a new RG instance.3. The difference between shutdown and acquiesce is that shutdown means that theRG will shut down whether the CESE has created a new connection or not. Theacquiesce request from the RG asks that the CESE create a new connection andclose the old one but will not force the request if the CESE ignores it.4. Shutdown is intended to be a rare event signaling an urgent condition on the RGside. If the CESE acknowledges and performs the acquiesce protocol5 Version 1 9/23/04

appropriately, no adverse effects should occur related to an RG shutdownsequence.CESERGApplication Session1. Shutdown Message (includes Application Session ID)2.ACKFigure 7-3 RG Shutdown7.1.2 Application Message ExchangeThe ESMI supports a bidirectional message exchange between the CESE and the RG. Forsome services the CESE initiates the exchange as shown in Figure 7-4. Each applicationmessage is specifically acknowledged by the other end point, either CESE or RG.Specifically the message exchange between the CESE and RG is asynchronous. That isthe CESE may request a service (Step 1) and the RG acknowledges the request (Step 2)while processing the request. The RG responds with the information (Step 3) and theCESE acknowledges the response (Step 4). Some services may just require a simplerequest and acknowledgement (Steps 1 and 2).Figure 7-4 CESE Initiated Services6 Version 1 9/23/04

Figure 7-5 illustrates ESNet initiated service request. The message exchange between theCESE and RG follows the same asynchronous behavior when the RG initiates themessage exchange. That is, the RG may request a service (Step 1) and the CESEacknowledges the request (Step 2) while processing the request. The CESE responds withthe information (Step 3) and the RG acknowledges the response (Step 4). Some servicesmay just require a simple request and acknowledgement (Steps 1 and 2).Figure 7-5 ESNet Initiated Services7.1.3 Emergency Event ProcessingWhen the CESE submits a new emergency service request message to the ESNet theremay be multiple sources of information in response to the event. Therefore, for a givenevent, the ESMI supports a dialog between the CESE and RG. The processing to supportEmergency Event management is initiated by the CESE’s Emergency Service RequestMessage as shown in Figure 7-6. First the RG acknowledges the CESE’s emergencyservice request message. The RG can now deliver response messages for the given eventthat contain information related to the event. Each response message from the RG to theCESE is acknowledged by the CESE to the RG. Response messages can continue to bedelivered from the RG to the CESE, as defined by the specific application attributes whichcaused the event, until the CESE sends an event complete message to the RG. When theRG receives an event complete message it will suspend sending any further responsemessages to the CESE related to the specific Emergency Event.7 Version 1 9/23/04

Figure 7-6 Multiple Response Messages7.1.4 Service MessagesThe interaction diagrams below show service messages used in the context of EmergencyEvents. The following are services that are facilitated by ESMI:Emergency Event Request/Response – retrieve location informationInformation Discrepancy – notify service provider of information errorsPSAP Misroute – notify service provider of misrouted callsCESE Transfer – Provide notification and correlation of Emergency Event transfersInstant Messaging – allows CESEs to converse regarding an Emergency Event7.1.4.1 Emergency Event MessagesThis is the simplest and in some ways the archetypal message flow between the RG andthe CESE. Most of the service message sequences follow the pattern that the CESErequests data from the RG using a Key (e.g., TN or ANI, ESRD, ESRK, MDN, etc.),receives location information retrieved with that key from the RG, and then sends an eventcompletion message to the RG. Depending upon the service and information containedwithin the ESNet multiple EEInfo messages may be sent to the CESE. These messagesare illustrated in Figure 7-7.8 Version 1 9/23/04

Figure 7-7: Inclusion of Emergency Event Hang up and Complete1. The CESE issues an Emergency Event.2. The RG ACKs.3. The RG responds with information (e.g. ALI record) in the Emergency EventInformation message.4. The CESE ACKs.5. At some point the caller hangs up and the CESE issues an Emergency Event HangUp notice.6. The RG ACKs the message.7. At some point the Emergency Event completes and the CESE issues anEmergency Event Complete.8. The RG ACKs the message.Notes:1. The EEhangup is issued when the emergency call is completed. The EEcomplete isissued when the Emergency Event is complete. EEcomplete takes precedence inclosing the Emergency Event. If an EEhangup message was not sent, anEEcomplete will imply a corresponding EEhangup. Therefore, an EEhangupmessage is optional, but, an EEcomplete message is required for every EEventmessage.9 Version 1 9/23/04

2. The RG may continue sending application messages specific to an EmergencyEvent after the CESE sends an EEhangup message. The RG is not to send anyfurther application messages for the given Emergency Event, as determined by theEEI, after the CESE has sent an EEcomplete message and the RG has returnedthe corresponding ACK message.7.1.4.2 Emergency Event Information Message with Multiple ResponsesAn Emergency Event Information message is sent from the RG to the corresponding CESEto carry information related to a given service invoked as a result of an EEvent message.There is the potential that some Emergency Events will result in multiple responses fromthe RG to the CESE for a single Emergency Event. That scenario is shown in Figure 7-8.CESERGApplication Session1.EEvent (Key)2.ACK3. EEinfo (EEI,Location Info)4.ACK5.EEInfo (EEI, Location Info)6.ACK…7. EEhangup (Key+ EEI)8. ACK9. EEcomplete (key+ EEI)10.ACKFigure 7-8: Multiple Response Case1. The CESE issues an Emergency Event.2. The RG ACKs.3. The RG provides the information that is immediately available.4. The CESE ACKs.10 Version 1 9/23/04

5. At some time later additional information becomes available and the RG forwards itto the CESE.6. The CESE ACKs the message.7. The caller hangs up the call at the CESE and the CESE notifies the RG.8. The RG acknowledges the hang up9. The CESE completes the event and issues an Emergency Event complete.10. The RG acknowledges the event complete.7.1.4.3 Emergency Event—Information Discrepancy MessageAn Emergency Event Information Discrepancy report can occur for any subscribinginformation source that resulted in an Emergency Event information message to the CESE.The message must identify the service, return the information packet and can provide textindicating the problem or issue identified with the information. This message is only valid ifthe service provider was identified as supporting this feature as indicated by an indicatorflag in the Emergency Event Information message.A particular example related to ALI follows: An Emergency Event is underway and locationdata have been retrieved and displayed at the PSAP call taker position. During theconversation between the PSAP operator and the caller, a discrepancy is detected, e.g.,the location information displayed on the operator’s screen differs from the verbalconfirmation provided by the caller. This scenario is possible during any Emergency Eventor outside the context of an Emergency Event. The message exchange is shown in Figure7-9.CESE Sends: EEinfoDiscrepancy message containing the EEI + incorrect data + ceseid +Authentication Session Identifier + any text entered by the PSAP operatordescribing the problem.CESE Receives: Discrepancy ACKNote: Future versions of the ESMI message set should support a mechanism for theinformation provider to return a change tracking ticket identifier to the CESE to facilitateinquires regarding the status of the information update.11 Version 1 9/23/04

Figure 7-9: Information Discrepancy Scenario1. The CESE issues an Emergency Event.2. The RG ACKs.3. The RG responds with ALI information.4. The CESE ACKs.5. At some point an information discrepancy is detected.6. The CESE issues and Information Discrepancy.7. The RG ACKs the message.7.1.4.4 PSAP Misroute MessageAs above, an Emergency Event is underway and location data has been retrieved.However, during the call, the PSAP operator determines that the Emergency Event hasbeen routed to the wrong PSAP. Again, as in the previous diagram, this scenario ispossible during any Emergency Event or outside the context of an Emergency Event.CESE Sends: EEventMisroute message containing the EEI + ceseid +Authentication Session Identifier + any local notes entered by thePSAP operator describing the problem.CESE Receives: Misroute ACK12 Version 1 9/23/04

7.1.4.5 CESE Transfer MessageThe Transfer message allows the CESE to notify the RG that the CESE is transferring theEmergency Event to another emergency service entity. The transfer Key (e.g. TN) isincluded in the message to the RG. (Note: This message has no effect on the actualtelecommunications conference call setup that occurs. This is a notification andinformational message only.)The Transfer message can contain text (such as PSAP notes) that will be stored by theESNet and displayed to any additional CESEs that submit an Emergency Event for thespecified key while the original CESEs Emergency Event is open.An example follows: An Emergency Event is underway and location data have beenretrieved. A condition is detected requiring the operator to transfer the event to anotherdestination. The originating CESE notifies the RG that it is transferring an event, as shownin Figure 7-10. Note that these events are bracketed by EEvent and EEcomplete messagesto demonstrate a complete Emergency Event context.CESE Sends: EEXFER – Transfer request that includes the header information(e.g., key such as ANI), EEI, any local notes, + ceseid +Authentication Session Identifier.The ESNet will cache this information, along with the ALI, andprovide it to the transferred-to CESE when it queries.CESE Receives: Transfer ACK13 Version 1 9/23/04

CESE1ESNetCESE1RGCESE1 Open Application Session1.EEvent (key)2. ACKkey=ANI, ESRD,ESRK, MDN, etc.3. EEInfo (EEI + ALI record)4. ACK5. EExfer (ceseid + EEI + key)6. ACKCESE2CESE2Transfer request includes key (e.g., ANI),Emergency Event ID, and potentially local notes +ceseid + application session identifier. ESNetcaches this information, along with theALI, and provide it to the transferred-toCESE when it queries.CESE 2 Open Application Session7.EEvent (key)8.ACK9.EEinfo (EEI + ALI record)10.ACKThe RG can offer the CESEs an IM session at thispoint because it has the EEI and both CESE addresses.Transferred-from CESE doesn'thang up until transferred-toCESE picks up the call.11.EEhangup (EEI)12.ACK13.EEcomplete (+ EEI)14.ACK15.EEhangup (+ EEI)16.ACKThe hangup message signalsmerely that the call hasterminated, not that the eventis over. The operator may havemore to do before the event iscompleted.17.EEcomplete (+EEI)18.ACKFigure 7-10 CESE TransferNotes:1. Typically, a transferring-from CESE will not hang up a call until a transferred-to CESEhas answered. However, once the transferred-to CESE picks up the call and gets thelocation information, the transferred-from CESE can hang up and the CESE will send14 Version 1 9/23/04

an EEcomplete message. It is also possible that both operators will elect to remainon the call until the event is completed.2. When the transferred-to CESE makes its information request, the sequence looks justlike the usual Emergency Event scenario except that the RG uses the previouslyassignedEEI .3. Both CESE-RG application connections remain active before, during, and after thetransfer, as each goes on to handle other events.4. A CESE transfer creates the possibility for an instant messaging exchange betweenthe operators.The flow of Figure 7-10 is as follows:.1. CESE 1 issues an Emergency Event2. The RG ACKs.3. The RG returns ALI information.4. The CESE ACKs.5. The CESE operator initiates a transfer of the emergency call and notifies the RG.The message may include local notes.6. The RG ACKs.7. CESE 2 issues an Emergency Event.8. The RG ACKs.9. The RG returns ALI information, the original EEI and local notes.10. THE RG ACKs.11. CESE 1 drops the call and notifies the RG.12. The RG ACKs.13. CESE 1 completes the Emergency Event and notifies the RG.14. The RG ACKs.15. CESE 2 drops the call and notifies the RG.16. The RG ACKs.17. At some point CESE 2 has handled the Emergency Event and issues anEmergency Event Complete.18. The RG ACKs.7.1.4.6 Broadcast Notification MessagesThe ESMI provides the capability to notify entities of emergency situations using BroadcastNotification messages. The Broadcast Notification Message may be issued by a CESE tonotify other CESEs of a global Emergency Event, for example, chemical spill, homelandsecurity notifications, etc. It also may be issued by an authorized agency behind theEmergency Services Network to inform individual users, a group of CESEs (e.g. a PSAP)or all CESEs within the ESNet instance of such an event.15 Version 1 9/23/04

CESE Initiated Broadcast messages:Steps 1 and 2 of Figure 7-4 may be used to illustrate the CESE Initiated BroadcastCESE Sends:CESE Receives:Broadcast MessageACKRG Initiated Broadcast messages:Steps 1 and 2 of Figure 7-5 may be used to illustrate the RG Initiated BroadcastCESE Receives:CESE Sends:Broadcast MessageACK7.1.4.7 Instant Messaging MessagesThe Join, Notify, Send, and Leave messages are in support of instant messaging betweenCESEs. If the ESNet recognized two CESEs as being engaged in the same EmergencyEvent, each RG will notify the corresponding CESE. The CESEs must have both issuedEmergency Event messages for the same key (e.g. ANI) and must both have beenassigned the same Emergency Event Identifier. After the RGs have notified the CESE ofthe conference call situation, the CESEs may now initiate an instant messaging sessionbetween themselves via the RGs. Figure 7-11 shows an example IM session. Thoughthe diagram shows only two CESEs participating, others could join the IM session. Also, inaddition to CESEs that are call taker positions, an administrative position could monitor andjoin an IM session.A hypothetical dialog might go as follows.RG Offers CESE1 an IM Session with CESE2RG offers CESE2 an IM Session with CESE1CESE1 accepts, creates the IM session by joining.CESE2 joins the IM session.The RG notifies CESE1 that CESE2 has joined.CESE1 sends the first message.The RG forwards the message to CESE2.CESE2 sends the second message.The RG forwards the message to CESE1.CESE2 sends a third message.16 Version 1 9/23/04

The RG forwards the message to CESE1.CESE2 leaves the IM sessionThe RG informs CESE1 that CESE2 has left IM.CESE1 leaves the IM session.Notes:1. The IM session may be available regardless of the transferring CESE submitting atransfer notification message to the RG. This message will help the ESNetcorrelate the activities, but, may not be necessary in all situations.2. The RG initiates the IM session and mediates the message exchange because it isin touch with both CESEs and holds state for the Emergency Event (i.e., the EEI.)Thus, the RG is in a position to offer IM capability to participating CESEs as part ofhandling a transfer during the Emergency Event.3. If no CESEs join the offered IM session, it is never created.4. Invited CESEs need not be within the same PSAP.5. CESEs send messages to an IM session managed by the ESNet.6. The RG acknowledges receiving a message and immediately forwards it to all otherCESEs participating in the specific IM session.7. CESEs that have already joined the IM session are notified as each new CESEjoins.8. Newly joining CESEs get a transcript of the IM up to the point they joined.9. Any CESE that has joined the IM session may send a message.10. After the last participant leaves, the RG makes the IM session inactive.11. Though an IM session is tied to a specific Emergency Event, closing the event doesnot explicitly end the IM session.12. The IM session terminates when the last participant leaves.13. If an IM is sent and there are no listeners left, the sender will be informed there isno listener.17 Version 1 9/23/04

CESE1CESE2RGPSAP1 Open Application SessionPSAP 2 Open Application SessionIM Notify (+ EEI + CESE2ID)ACKIM Notify (+EEI + CESE1ID)ACKIMjoin (+EEI)ACKIMJoin (EEI + CESE2ID)ACKIMnotify (EEI + CESE2ID)ACKIMsend (EEI + CESE1ID + Msg1 Text)ACKIMsend (EEI + CESE1ID + Msg1 Text)ACKIMsend (EEI + CESE2ID + Msg2 Text)ACKIMsend (EEI + CESE2ID + Msg2 Text)ACKIMsend (EEI + CESE2ID + Msg3 Text)ACKIMsend (EEI + CESE2ID + Msg3 Text)ACKIMleave (EEI + CESE2ID)ACKIMleave (EEI + CESE2ID)ACKIMleave (EEI + CESE1ID)ACKRG offers CESE1 IM Session with CESE2CESE1 AcknowledgesRG offers CESE2 IM Session with CESE1CESE2 AcknowledgesCESE1 accepts, creates IM SessionRG AcknowledgesCESE2 Joins IM SessionRG AcknowledgesRG notifies CESE1 that CESE2 has joinedCESE1 AcknowledgesCESE1 Sends Msg1RG AcknowledgesRG Forwards Msg1 to CESE2CESE2 AcknowledgesCESE2 Sends Msg2RG AcknowledgesRG Forwards Msg2 to CESE1CESE1 AcknowledgesCESE2 Sends Msg3RG AcknowledgesRG Forwards Msg3 to CESE1CESE2 AcknowledgesCESE2 Leaves IM sessionRG AcknowledgesRG Informs CESE1 that CESE2 has left IMCESE1 AcknowledgesCESE1 Leaves IM sessionRG AcknowledgesFigure 7-11: CESE to CESE IM Session Mediated by the RG18 Version 1 9/23/04

7.1.4.8 Administrative Monitoring of an IM SessionAdministrators with larger jurisdiction than a single PSAP will also be able to monitor or joinan IM session once properly authenticated and authorized.7.1.5 Report and Status MessagesReport and status messages enable the CESE or RG to request various kinds of statusinformation from one another.7.1.5.1 CESE Active Event StatusThe RG requests the list of current active Emergency Events from a CESE (Refer to Figure7-5).CESE Receives: GetActiveEventStatus (+ optional EEI)CESE Sends: ACKCESE Sends: ActiveEventStatus ceseid + Authentication Session Identifier +active event status reportCESE Receives: ACKNotes:1. If no active events, a null indication will be returned.2. In addition to the event status, any IM session attached to it will be included.3. If no specific EEI is attached, all active events are reported, including active IMsessions.4. To obtain PSAP status, the RG will send this message to every CESE in the PSAP.7.1.5.2 RG Active Event StatusThe CESE requests a report of current active events for its PSAP from the RG (Refer toFigure 7-4).CESE Sends: GetActiveEventStatus (+ ceseid + Authentication Session Identifier +optional EEI)CESE Receives: ACKCESE Receives: ActiveEventStatusCESE Sends: ACKNotes:1. This message is intended for an administrative CESE to enable it to ask for PSAPstatus.2. If no active events, a null indication will be returned.3. In addition to the event status, any IM session attached to it will be included.19 Version 1 9/23/04

4. If no specific EEI attached, all active events are reported, including active IMsessions.7.1.5.3 Event Activity ReportThe CESE may request an activity report from the ESNet (Refer to Figure 7-4). This mayinclude events segmented by class of service, events received over a reporting window(day, week, etc), and other such selection criteria. The information returned will includeactive Emergency Events and IM sessions by Emergency Event Identifer. In addition thismessage may return a complete transcript of an IM session up to the time of the request.CESE Sends: GetEventActivity request + report typeDepending on report type, there could also be a date-range fieldCESE Receives: ACKCESE Receives: EventActivityReport ceseid + Authentication Session Identifier +reportCESE Sends: ACKErrors: Data unavailable, range not valid, service unavailableNotes:1. Specific reports will be defined based on customer requirements.2. This is intended as an MIS message to enable an administrative CESE to obtaininformation about a specific PSAP.7.1.5.4 Configuration ReportThe RG may request configuration parameters related to the CESE (Refer to Figure Figure7-5). This may include network connections, number of positions supported by CESE, andother such configuration-related information.CESE Receives: GetConfiguration requestCESE Sends: ACKCESE Sends: Configuration Report ceseid + Authentication Session Identifier +configuration information, format TBDCESE Receives: ACKErrors:Data unavailable, service unavailableNotes:1. This data is intended for use in troubleshooting, e.g., hung connections, resourceexhaustion, etc.20 Version 1 9/23/04

7.2 Connection Negotiation MessagesConnection Negotiation messages facilitate the connection of a given CESE to anappropriate RG. In doing this they facilitate authentication of both the CESE and RG andcreate a relationship between the two that is persistent for some period of time. ConnectionNegotiation messages verify, at the application level, that the CESE and RG are availableand able to submit or service application requests. They also manage the relationshipbetween the CESE and the RG such that the dynamic nature of the Emergency ServicesNetwork can be gracefully accommodated. Specifically, ESNet endpoints may be placedinto service, leave service for maintenance reasons, etc. without impact to the network as awhole and without impacting the service provided to CESEs.7.2.1 Connection Set UpA persistent, managed connection between the CESE and an ESNet gateway (i.e. an RG)is crucial. Accordingly, a CESE will use some resource discovery technique (e.g., DNS)and a connection determination mechanism embedded in the ESNet to find an appropriateResource Gateway to connect to. The CESE negotiates with the Connection Manager,including an exchange of credentials to guarantee that the application session is properlyauthenticated and authorized, for a connection to a Resource Gateway. The CESE andthe RG negotiate appropriate application connection parameters and establish anadministrable time period based persistent connection over a TCP/IP socket. Once theapplication session is established, the CESE and the RG begin exchanging applicationmessages.As a result of the authentication, the ESNet gives the CESE an “Authentication SessionIdentifier” to be included in messages from the CESE to the RG. The AuthenticationSession Identifier is used as a surrogate for the authentication process on a message bymessage basis, but it’s most important role comes when rotating connections, as in theacquiescence scenario discussed below. Instead of the entire re-authentication process,which entails presenting certificates and obtaining further credentials (e.g., some fob value)directly from a PSAP operator, the Authentication Session Identifier can be used to set up anew connection without direct operator intervention. This saves the operator the oneroustask of personal authentication every time a connection is acquiesced.Figure 7-12 illustrates this connectivity.21 Version 1 9/23/04

Figure 7-12 CESE/RG Connection Setup (Conceptual)The interaction sequence of the connection set up is as follows:1. The CESE asks a name resolution service (e.g. DNS) for an ESMI connection to theESNet. This could be accomplished by requesting a connection to a resource name(e.g. ResponseGateway).2. The discovery service resolves the CESE request into an ESNet Connection Managerfunction. This could be an RG itself or some other element that will negotiate aconnection and specify the eventual RG. In either case, the Connection Managermechanism supports the ability to select an appropriate RG based on dynamicparameters, such as RG availability, RG connection load, and RG message setversion supported.3. The CESE connects to the Connection Manager function.4. After parameter negotiation (e.g., exchange of credentials and message set versionssupported) the Connection Manager specifies a connection between an RG and theCESE.5. The CESE establishes an application connection with the specified RG.6. During the life of the application message connection, emergency services messagesflow between the CESE and the specified RG.22 Version 1 9/23/04

7.2.2 Application Connection AcquiesceAcquiesce is the process of rotating CESE to RG connections on a periodic basis tosupport ESNet management and nominal processing goals. There are several reasons fordefining periodic connection rotation:♦ It is a good practice for communicating parties to exercise all of the routes.This is for early detection of problems, e.g., provider being down, etc.Regular exercising of the ability to break down and establish connectionsensures that these functions operate properly and that these functions arelikely to operate properly during recovery processing situations.♦ In order to connection balance a number of RGs, it is desirable for theconnections to be more or less evenly distributed. The periodic rotation ofCESE connections would provide a more even distribution over time. Thiswould add to the overall capacity and availability of ESNet.♦ The ESNet is believed to be a dynamic environment. A new RG may join thenetwork at any time. If connections are periodically rotated, the new RGbecomes part of the pool of available RGs and receives new connections asit becomes a player.♦ Long-lived TCP connections become “stale”. When they become “stale”, it isusually not noticed by either communicating party until an attempt to send amessage. In this situation, if it is the RG sending a message to the CESE,the communication attempt will fail and more elaborate logic will be required.If the CESE is sending a message the attempt will fail and the CESE willneed to establish a new connection and resubmit the message. RotatingCESE and RG connections avoids these scenarios.Conditions under which connection acquiescence are performed include:1. Periodic cycle as defined by administrative settings for the given ESNet CESE toRG connection.2. When a given RG is required to go out of service for any reason.Before leaving the network for any reason, the RG will send an Acquiesce applicationmessage to its CESE Clients as discussed in this section. This is done to trigger the CESEto perform connection acquiescence. It is assumed that the ESNet has correspondinglyadjusted the RG distribution model, via the connection negotiation mechanisms, and nofurther new CESE connections are being established to the given RG.The acquiescence includes a period of connection overlap between the CESE and twoRGs, during which a given CESE is completing active Emergency Events on the oldconnection and opening new Emergency Events on the new connection. This is to ensurethat the new route is functioning and to allow all outstanding Emergency Events initiated onthe first RG connection to complete. After the second connection is established, all newEmergency Events must be initiated on the new RG connection, thereby allowing the firstRG connection to become idle. All messages corresponding to a given Emergency Eventmust occur over the connection which established the Emergency Event.23 Version 1 9/23/04

To achieve this goal, the CESE will continue using the old application connection for allinteractions until it ensures that the new connection has been accepted by some RG withinthe ESNet. At the time that the new application connection has been accepted, the CESEwill begin submitting new Emergency Events on the new connection. The old connectionwill be kept intact until all existing Emergency Events are completed as signaled by anEmergency Event complete message for the given event. Once the CESE has completedall the Emergency Events related to the old connection, the CESE will close the oldapplication connection.Diagram details:Figure 7-13: Acquiesce Message SequenceIn this diagram the RG1 requests the CESE to Acquiesce. The CESE establishes a newapplication connection with RG2 and then terminates the connection with RG1.1. As shown in Figure 7-13, the RG requests an Acquiesce from the CESE Thiscauses the CESE Client to initiate the Acquiesce sequence.24 Version 1 9/23/04

2. The CESE Client ACKs the request.3. The CESE establishes a new Application connection with an RG (RG 2 in thediagram). In establishing this connection network capabilities are used to distributethe connection request among the N+1 RG logical entities.4. The CESE Client stops sending new Emergency Events on the old Applicationconnection and begins sending them across the new application connection.Pending event responses may be received over the old connection.5. When the CESE has received all of the outstanding responses and has issuedEmergency Event Completions for all the Emergency Events that were related tothe old connection, the CESE client tears down the old connection.6. Emergency Service message activity continues on new Application connection.If CESE is unable to set up a new connection in Step 3 of Figure 7-13, it will send anunable to acquiesce message to the RG over the existing connection. This would appearas Steps 1 and 2 in Figure 7-4.CESE Receives: AcquiesceCESE Sends: ACKError ConditionCESE Sends: UnableToAcquiesceCESE Receives: ACKNotes:1. If the RG has not received a connection close within an administrativelyconfigurabletime period, an error condition is assumed.2. If the CESE sends an “unable to acquiesce” message to the RG in responseto the RG request to acquiesce, the RG continues to process the EmergencyEvents, but may log an error event.25 Version 1 9/23/04