Patent Description:
Currently, the Emergency Response Services in USA and Europe are in transition from legacy PSTN systems to the Next Generation <NUM> (NG911) based on the Internet Protocol (IP). The advantage of the NG911 is that it allows the support of different communication technologies such as wireless phones, text and picture messaging, video chat, social media, and Voice over Internet Protocol (VoIP) devices.

In this scenario, there are many opportunities for Internet of Things (IoT) implementations. Connected homes and enterprises as well as transportation utilities are becoming a reality with the large development of IoT sensors and monitoring devices. These devices can notify emergency situations, providing a bunch of data including the exact location of the incident.

However, to connect these private locations to the NG911 is a challenge. Each IoT device vendor develops its own communication protocol. To converge many devices in a single platform some IoT communication frameworks are available but nevertheless, these frameworks need to be enhanced with respect to each new vendor in the market.

The document <CIT> relates to an i3 proxy module. An i3 proxy module is provided within a <NUM> service provider network (e.g., at the VoIP positioning center) to respond to a VoIP i2 SIP INVITE destined for a PSAP having i3 architecture. The i3 proxy module responds to the VoIP i2 SIP INVITE by generating a VoIP i3 SIP INVITE with PIDF-LO and routing the same to the i3 emergency services routing proxy (ESRP) within the i3 network. Thus, an i3 SIP INVITE with PIDF-LO is sent from an i3 proxy module associated with an i2-based VoIP positioning center (VPC). Thus, legacy originating service provider (OSP) carrier networks are now enabled to route an emergency call to a PSAP having an i3 ESInet architecture.

The document <NPL> presents an EMYNOS project which aims to the design and implementation of a Next Generation platform capable of accommodating rich-media emergency calls that combine voice, text, and video, thus constituting a tool for coordinating communication among citizens, call centers and first responders.

The document <NPL> describes how NG9-<NUM>-<NUM> works after transition, including ongoing interworking requirements for IP-based and TDM-based PSAPs and origination networks.

Besides that, the emergency response services also would need a dedicated system to handle such information.

Therefore, the present invention is based on the object to provide a method for providing an emergency response service and an emergency response service system according to which more precise emergency data may be provided in the event of an emergency.

The object is solved by a method for providing an emergency response service having the features according to claim <NUM>, and an emergency response service system having the features according to <NUM>. Preferred embodiments of the invention are defined in the respective dependent claims.

Accordingly, a method for providing an emergency response service based on the Internet Protocol, IP, is provided according to the present invention, wherein an emergency call initiated by a subscriber due to an emergency situation is received by a SIP server together with location information, and wherein the SIP server associates the location information with the subscriber that initiated the emergency call, wherein the method comprises the steps of connecting at least one Internet of Things IoT device belonging to the subscriber to the SIP server; associating, in the SIP servers, the at least one IoT device to the location information; receiving at the SIP server, from the at least one IoT device, real time data associated with the emergency situation; and transmitting the real time data associated with the emergency situation to an emergency service routing proxy ESRP of an emergency IP network solution EsiNet.

By the inventive method, by integrating data of IoT devices into the emergency call and response process, more precise data may be provided as to the emergency situation. For example, an IoT device as a camera located in the branch office at a location where a fire broke out, is able to provide additional information on the emergency situation, as how severe the fire is, and where it is located exactly. Thus, the handling of an emergency may be improved significantly.

Also, according to the inventive method, an innovative solution is provided so as to unify the information provided by the IoT devices in order to integrate both NG911 systems and security monitoring and measurement devices from a location served by the emergency services.

Preferably, the SIP server is a SIP Proxy, a SIP Session Border Controller, an IP PBX or any other SIP entity.

Preferably, the IoT devices are security monitoring and measurement devices located in or close to a branch office of the subscriber. However, it is also possible that the IoT devices are located somewhere else, i.e., not within the branch office itself.

It is also advantageous, if the method further comprises a step of associating the location information to the subscriber.

According to a preferred embodiment of the invention, the location information is associated to the subscriber by assigning it to a single Destination Number DN or a range of DNs, a single IP number of an IP subnet, or to a physical port.

Also, the method may further comprise a step of associating the subscriber and the at least one IoT device.

Preferably, the at least one IoT device is a sensor and/or a monitoring device.

Moreover, according to another preferred embodiment, the method further includes a step of extending Presence Information Data Format PIDF for transporting data received from the at least one IoT device to the ESRP.

According to still another preferred embodiment of the invention, the PIDF-LO is used for transporting the location information of the at least one IoT device to the ESRP.

Preferably, the method further includes a step of automatically generating an emergency call from an IoT device event.

Further, the PIDF may comprise a contact element, in particular, an URL of the contact address indicating how a person or entity of at least one IoT device can be reached.

The PIDF may further comprise a timestamp element that designates the time at which the PIDF document was created.

Preferably, the PDIF document is an XML document.

Moreover, according to the present invention, an emergency response service system is provided, comprising at least one branch office connected to a VoIP network by a SIP server, the branch office being served by an Emergency IP Network Solution EsiNet, wherein the system is adapted to carry out the method specified above.

According to a preferred embodiment of the invention, at least one IoT device is connected to the SIP server, the at least one IoT device being connected to an IoT management system or to an IoT gateway.

The invention and embodiments thereof will be described below in further detail in connection with the drawing.

<FIG> schematically shows a branch office <NUM> connected to the VoIP network <NUM> by a SIP Server, in this case a SIP Proxy <NUM>. The SIP Proxy <NUM> is connected to Session Initiation Protocol (SIP) Service Provider that provides the access to the Public Switched Telephone Network (PSTN). All IoT devices <NUM>, which in the embodiment shown here are security monitoring and measurement devices <NUM> are connected to a local management system <NUM> via an IoT network <NUM>.

This location is served by the NG911 service, i.e., an Emergency IP Network Solution <NUM> (EsiNet). The EsiNet <NUM> is composed by the Border Control Function <NUM> (BCF) and the Emergency Service Routing Proxy <NUM> (ESRP).

SIP Proxies <NUM> are elements that route SIP requests to user agent servers (UAS) and SIP responses to user agent clients. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order.

An emergency call can be recognized by a SIP Proxy <NUM> by comparing the R-URI to pre-defined list of emergency numbers. A call to a number in this list triggers the server <NUM> to establish an outgoing call to the PSTN. SIP Proxies <NUM> may support the conveyance of location information, i.e., the Geo-location header field and the Presence Information Data Format Location Object (PIDF-LO) according to the RFC5491. This information can be transparently forwarded or included by the server in the SIP INVITE message sent to the PSTN.

The SIP proxy <NUM> is able to associate a location information to the subscribers under it in many ways: the location information may be assigned to a single Destination Number (DN) or range of DNs, single IP number or IP subnet, or for physical ports in case of analog subscribers. The location information may be configured in the SIP Proxy <NUM> database in terms of civic location or other representation described in the RFC5491.

In case an emergency situation occurs, for example, a subscriber A (not shown in the figure), in this office <NUM>, will generate an emergency call. Once the SIP Proxy <NUM> determines that it is an emergency call, the server checks if the Presence Information Data Format Location Object (PIDF-LO) was received or must be included in the SIP INVITE message body and sends this message via the SIP trunk in order to reach the Emergency Service of the EsiNet <NUM>.

However, a plurality of devices <NUM> are connected in this branch office <NUM>. Thus, according to the embodiment illustrated in this scenario, the private IoT network <NUM> is connected to the SIP network via a SIP proxy <NUM> in order to take advantage of the IoT devices <NUM> in a branch office <NUM> in case of emergency situations. This includes:.

<FIG> illustrate two approaches to connect the IoT devices <NUM> to the SIP proxy according to an embodiment of the invention, whereby in <FIG>, the IoT management system <NUM> shown in <FIG>, here, is replaced by an IoT gateway <NUM> connected to the SIP proxy <NUM>. The communication between them can be achieved using SIP, Websocket, or any other communication protocol over IP. In <FIG>, the IoT devices <NUM> are connected directly to the SIP proxy <NUM>. In this case, the SIP proxy <NUM> is enhanced with any one of the available frameworks to communicate with the security monitoring and measurement devices <NUM>.

In both approaches, the SIP proxy <NUM> has access to the IoT devices <NUM> connected to it. By a unique identifier, for instance, the IP address, the SIP proxy <NUM> may associate IoT devices <NUM> to location information as it is also done for the subscribers. The location of the IoT devices <NUM> may be also received from the IoT Gateway <NUM>.

<FIG> illustrates how subscribers and IoT devices <NUM> are associated in a SIP proxy <NUM> (see <FIG>). The Presence Information Data Format (PIDF) defined by RFC3863 can be extended to transport IoT devices data to the EsiNet (for example EsiNet <NUM> shown in <FIG>). The PIDF-LO used to transport the geo-location information is an example of extended PIDF. The PIDF format provides an unlimited number of tuple, device or person elements. Each IoT device <NUM> can be identified as a "device" element. Each device element is identified by a unique ID.

The PIDF optionally contains a "contact" element that is the URL of the contact address that shows how a person or entity responsible for this device can be reached. It is noted that in the emergency services context, some situations require callback to the emergency call originator. The PIDF optionally contains a "timestamp" element that designates the time at the PIDF document was created giving some idea of when the IoT device data was collected.

Each tuple, device or person element contains a single status element. The RFC3863 defines the status element as extensible, i.e., this element may contain any number of extension elements that can be defined to inform the status of each IoT device <NUM> according to their specificities. By categorizing the security monitoring and measurement devices, a set of relevant data can be defined in terms of status elements such as temperature, smoke presence, distance, alarm detected, etc. The PIDF document is an XML document; this extension may be defined in terms of the XML schema. For example:
<IMG>.

A single PIDF document may provide the information on the location of subscribers and IoT devices <NUM> by the PIDF-LO as well as the status of these devices using this new PIDF extension. The same information may also be sent in multiple PIDF documents.

Considering the PIDF-LO is already supported by the NG911 services, the usage of the PIDF extension may easily integrate emergency services and IoT devices <NUM> for the following reasons. First of all, the EsiNet does not have to implement a dedicated service to support different protocols, message flows or data format used by the IoT devices <NUM>. On the other hand, the call containing the monitoring data may be routed inside the EsiNet as a common emergency call. Besides the SIP protocol, the PIDF document may be sent in the body of any protocol capable to carry an XML document.

<FIG> illustrates a scenario according to another embodiment of the invention, whereby a method of enhanced emergency calls with extended PIDF is implemented. Here, the subscriber A is considered as being the originator <NUM> of the emergency call. Its IP address is within emergency subnet <NUM>. <NUM> previously configured. To this subnet two IoT devices <NUM> are associated: a smoke detector, IP address <NUM>. <NUM> and a smart locker, IP address <NUM>. Both devices <NUM> are in the same subnet <NUM>. <NUM> and in this case, they have the same geo-location A of the subscriber A. Besides the location of the IoT devices <NUM>, the SIP proxy <NUM> may consult relevant data provided by them. With this data, it creates an enhanced PIDF document, including the geo-location of subscriber originator <NUM> of the emergency call, the current snapshot data of IoT monitoring devices <NUM> associated to that subscriber, as indicated below.

Thus, this PIDF document is included in the SIP INVITE message sent to the EsiNet <NUM> via the SIP Service Provider. Once arrived in the EsiNet <NUM>, this call can be routed as any other call with PIDF-LO.

<FIG> schematically illustrates another scenario for automatic emergency calls based on an IoT event using the extended PIDF providing callback contact information according to an embodiment of the invention. Here, once a critical event is notified by any of the security monitoring and measurement devices <NUM> in the branch office, the SIP proxy <NUM> calls a predefined destination that may be or not the emergency service, in order to provide information on the situation.

Considering, for example, the smoke detector, IP address <NUM>. <NUM>, in the <FIG>, which is one of the security monitoring and measurement devices <NUM>, this sensor is located within the subnet <NUM>. <NUM> with geo-location A, indicated by reference numeral <NUM>. This sensor is also associated to the subscriber B, with geo-location B, indicated by reference numeral <NUM>. Once the sensor detects some smoke, the SIP proxy <NUM> is notified and automatically calls the predefined destination, in this case the emergency service. The SIP INVITE message sent by the SIP proxy <NUM> includes the location (PIDF-LO) and data (new extended PIDF) of the smoke detector as well as the subscriber B contact as being responsible for this device.

When the call is answered, an Interactive Voice Response (IVR; not shown), the media server or other system application capable to play a voice message can be used to play an announcement to the called party. Alternatively, a text message can be sent via the Message Session Relay Protocol (MSRP). The EsiNet <NUM> already supports the MSRP.

With the PIDF data included in the SIP INVITE or other SIP method, the called party is able to callback subscriber B to provide additional assistance.

<FIG> illustrates schematically another embodiment for a scenario to provide emergency video calls. Here, the SIP proxy <NUM> may also send IoT device data via payload. This is especially applicable when it is intended to share real time data provided by devices such as cameras. Currently, security and monitoring systems send an alarm message to a central monitoring station. Even the emergency calls enhanced with the extended PIDF where additional information from the IoT devices <NUM> is included cannot be visually confirmed. Besides that, an emergency situation in which, for example, medical assistance is required, the possibility to see the situation in in real-time may help the responder to provide better assistance.

Thus, when the emergency call is generated by a device that is able to provide video calls such as cellphones, PC with webcams, etc, the video stream <NUM> may be transmitted to the emergency responder <NUM>. Considering the Subscriber A in <FIG>, indicated by reference numeral <NUM>, the latter may generate an emergency call in order to obtain medical assistance. Subscriber A is an analog device and does not have any camera, however, in that room there is a surveillance IoT camera <NUM>', <NUM>' connected to the SIP proxy <NUM>. The SIP proxy <NUM> knows that subscriber A and the IoT camera <NUM>', <NUM>' are associated; internally, the SIP proxy <NUM> creates a bridge between the audio stream <NUM> from the susbcriber A and the video stream <NUM> provided by the IoT camera <NUM>', <NUM>' generating a single media stream to the EsiNet <NUM> for which this is a common video call, routed normally inside the network.

The call enhanced with video can also be applied to the emergency callback calls where the call is originated outside the branch office to a device in the branch office.

Claim 1:
Method for providing an emergency response service based on the Internet Protocol, IP, wherein an emergency call initiated by a subscriber (<NUM>) due to an emergency situation is received by a Session Initiation Protocol, SIP, server (<NUM>) together with location information, and wherein the SIP server (<NUM>) associates the location information with the subscriber (<NUM>) that initiated the emergency call, wherein the method comprises the steps of
- connecting at least one Internet of Things, IoT, device (<NUM>) belonging to the subscriber (<NUM>) to the SIP server (<NUM>);
- associating, in the SIP server (<NUM>), the at least one IoT device (<NUM>) to the location information;
- receiving at the SIP server (<NUM>), from the at least one IoT device (<NUM>), real time data associated with the emergency situation; and
- transmitting the real time data associated with the emergency situation to an emergency service routing proxy, ESRP, of an emergency IP network solution, EsiNet. (<NUM>)