Method and system for automatic provision of data from multiple sensors within an emergency services network

Abstract

A method at a supplemental data provider within an emergency services network, the method comprising: receiving a message at the supplemental data provider, the message including an identifier and event data; in response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource being associated with the identifier; receiving an access request from the emergency services provider for supplemental data associated with the resource; and in response to receiving the access request, providing a response with the supplemental data.

Description

Technical Field

[0001] The present disclosure relates to emergency services response, and in particular to supplying supplemental data to emergency services providers. Background Art

[0002] Emergency services are typically contacted using emergency numbers such as 911 in North America or 112 in Europe, among other options. However, such services were initially built on heterogeneous and isolated networks such as analog or voice systems, and therefore Next Generation 911 (NG911) or Next Generation 112 (NG112) systems are being introduced. Such next-generation systems allow emergency service IP networks to deliver voice, video, text, and data calls to public safety answering points.

[0003] With the advent of these next-generation services, emergency service providers can benefit from access to supplemental data, such as from Internet of Things (IoT) endpoints, to inform response strategies and execution. However, current NG112 or NG911 emergency platforms do not support access to data related to a specific incident and originating from IoT devices and sensors. To leverage data from such IoT devices and sensors deployed near or related to an incident, emergency service architectures need to be enhanced to efficiently identify and access these data sources. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be better understood with reference to the accompanying drawings, in which:

[0005] Figure 1 is a block diagram from the European Telecommunications Standards Institute (ETSI) showing emergency services teams accessing pre-deployed IoT devices;

[0006] Figure 2 is a block diagram illustrating an example next generation 112 architecture;

[0007] Figure 3 is a block diagram illustrating an example next generation 911 architecture;

[0008] Figure 4 is a block diagram illustrating the role of a clearinghouse in an emergency 911 architecture;

[0009] Figure 5 is a block diagram illustrating an example emergency services architecture model according to an embodiment of the present disclosure;

[0010] Figure 6 is a data flow diagram illustrating the flow of data when a device initiating an emergency call identifies a supplemental data provider;

[0011] Figure 7 is a data flow diagram illustrating the flow of data when an enhanced additional data repository identifies a supplemental data provider;

[0012] Figure 8 is a data flow diagram illustrating the flow of data when an emergency service provider identifies a supplemental data provider;

[0013] Figure 9 is a block diagram of a simplified electronic device that can be used with the methods and systems herein, according to one embodiment; and

[0014] Figure 10 is a block diagram of a mobile device that can be used with the methods and systems herein. DETAILED DESCRIPTION

[0015] The present disclosure provides a method at a supplemental data provider within an emergency services network, the method comprising: receiving a message at the supplemental data provider, the message comprising an identifier and event data; in response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource being associated with the identifier; receiving an access request from the emergency services provider for supplemental data associated with the resource; and in response to receiving the access request, providing a response with the supplemental data.

[0016] The present disclosure also provides a supplementary data provider within an emergency service network, the supplementary data provider comprising: a processor; and a communication subsystem, wherein the supplementary data provider is configured to: receive a message comprising an identifier and event data; in response to receiving the message, create a resource at the supplementary data provider based on the event data, the resource being associated with the identifier; receive an access request for supplementary data associated with the resource from the emergency service provider; and in response to receiving the access request, provide a response with the supplementary data.

[0017] The present disclosure also provides a computer-readable medium for storing instruction codes, which, when executed by a processor of a supplemental data provider within an emergency services network, causes the supplemental data provider to: receive a message comprising an identifier and event data; in response to receiving the message, create a resource at the supplemental data provider based on the event data, the resource being associated with the identifier; receive an access request from the emergency services provider for supplemental data associated with the resource; and in response to receiving the access request, provide a response with the supplemental data.

[0018] Currently, there is no universal or standardized solution for sharing relevant data generated by Internet of Things (IoT) devices or other data sources with emergency services. Such data sources can be connected to public or private communication networks and cloud-based applications, but are not available to emergency platforms such as Next Generation 911 (NG911) or Next Generation 112 (NG112).

[0019] Specifically, ETSI has established a Special Committee (SC) on Emergency Communications (EMTEL), which studies use cases involving IoT devices in the provision of emergency situations. The group published v.1.1.1 of the technical report ETSI EMTELTR 103 582: "Study of use cases and communications involving IoT devices in provision of emergency situations" in July 2019, which includes eight use cases and their derived requirements.

[0020] Many deployed IoT devices, sensors, or actuators are not intended or designed for public safety purposes and do not require dedicated emergency features or connectivity to achieve their primary functionality while operating for consumer-oriented or business-oriented applications in domains such as smart cities or buildings, automotive, transportation, home or industrial IoT, connected to healthcare or agriculture, among other options.

[0021] In one use case, an emergency service team can access pre-deployed IoT device controls or data. According to the present disclosure, an emergency service team includes members who manage and coordinate emergency service operations and can include members of emergency missions in or near the incident area. Examples include first responders, such as firefighters, police, technical and medical personnel, etc. For example, referring now to Figure 1 .exist Figure 1 In an embodiment of the present invention, IoT devices (such as mobile phones 112, alarm systems 114, temperature monitoring systems 116, cameras 118, and other options for IoT devices) can communicate with IoT network 122 through access point 120. In this case, IoT service platform 130 and devices can be pre-deployed to communicate with emergency service decision-makers 140. Therefore, in an emergency, in a private or public building or in an area with a pre-deployed IoT-based security system, IoT devices and building security systems can provide additional useful information to emergency service teams.

[0022] There are various use cases for this pre-deployed equipment. For example, the NG112 system is a European Union framework that aims to aggregate multiple emergency call technologies, Public Safety Answering Point (PSAP) models, routing strategies, and other options through the emergency services network. NG112 is primarily based on the Long Term Definition (LTD) European Emergency Number Association (EENA) architecture.

[0023] An example of NG112 architecture Figure 2 And is shown. Figure 2In the example of FIG, a user equipment (UE) 210 communicates with an access network 212 that supports Voice over Internet Protocol (VoIP). Similarly, UE 220 communicates with a traditional access network 222. As used herein, a UE may be a cellular phone, a landline phone, a mobile device, or any other electronic device with wired and / or wireless communication capabilities.

[0024] The VoIP-enabled access network 212 communicates with a border control function (BCF) 230 to access an emergency services IP network (ESInet) 240. The legacy access network 222 communicates with a legacy network gateway (LNG) 232 to access ESInet 240.

[0025] The UE and access network form part of different originating networks, while the emergency services network including border control function 230 or legacy network gateway 232 forms part of the PSAP domain. The PSAP domain provides a location information server (LIS) interface 234 to a location node 236.

[0026] Emergency services network 240 includes various functional blocks, including a logging and recording (L / R) entity 242, an emergency services routing proxy (ESRP) 244, an emergency call routing function (ECRF) 246, and a plurality of PSAPs (designated PSAP-1 250, PSAP-2 252, and PSAP-N 254). The L / R entity may also provide audit capabilities, for example, for post-event analysis of emergency events.

[0027] Similarly, regarding Figure 3 An example of a next generation 911 system is shown. Figure 3 In the embodiment of FIG. 3 , the originating service environment 310 may access a call information database (CIDB) 312 or a location information service (LIS) 314 . Similarly, the originating service environment 316 may also access the CIDB 312 or the LIS 314 .

[0028] The originating service environment 310 may make an Internet Protocol (IP) call to an NG911 core service network 320. Such a core service network 320 may include access to a legacy E911 selective router 322 and an E911 automatic location information (ALI) database 324.

[0029] exist Figure 3 In an embodiment, various functional elements are shown, including a location verification function (LVF) 330, an emergency services routing proxy / policy routing function (ESRP / PRF) 332, a legacy PSAP gateway (LPG) 334, a legacy network gateway / legacy selective router gateway (LNG / LSRG) 336, an ECRF with a PSAP boundary 338, and a security function 340.

[0030] Additionally, PSAP 350 may include a call receiver system, map display, computer-aided dispatch (CAD), logging and reporting, and other functionality.

[0031] The system may also include a graphical information system (GIS) 352 and an extended emergency network 354. The extended emergency network 354 may include various entities in a particular country. For example, in the United States, these entities may include the Department of Homeland Security, the Federal Emergency Management Agency (FEMA), city halls, etc.

[0032] The core service network 320 may also access other radio networks 360 or wired networks (not shown).

[0033] use Figure 2 or Figure 3 In an environment where emergency services are using additional data from mobile devices, they are currently allowing emergency services to utilize additional data. For example, the National Emergency Numbering Association (NENA) has developed a standard for detailed functional and interface specifications for an IP-based multimedia telecommunications system to support the delivery of emergency calls over emergency service IP networks. This standard was published as NENA-STA-010, "NENA i3 Next Generation 9-1-1 Standard."

[0034] The NENA i3 call interface is a Session Initiation Protocol (SIP) interface and is defined, for example, in Internet Engineering Task Force (IETF) RFC 3261: "SIP Session Initiation Protocol." Using this interface, calls can include one or more forms of media, including but not limited to audio, video, and / or text. SIP can be used to call back 911 callers and is the calling protocol between agents within ESInet.

[0035] The MESSAGE method provides an extension to SIP to allow the transmission of instant messages and is also used to carry Common Alerting Protocol (CAP) messages. The MESSAGE method is used to initiate non-interactive calls. The MESSAGE request carries content in the form of a Multipurpose Internet Mail Extensions (MIME) body part. Using SIP, initiating an emergency call may require header fields in INVITE and MESSAGE. The information in the header fields may include an identity for providing a claim about the calling party's identity, a request Uniform Resource Indicator (URI), "To" and "From the" fields, and other possibilities. As used herein, a URI includes a string that clearly identifies a specific resource and follows a predefined set of grammatical rules, but also maintains scalability through a separately defined hierarchical naming scheme.

[0036] Various call information may also be provided. For example, additional data may be available. Various standards for providing additional data include NENA-STA-012.2-2017 "NENA Standard for NG9-1-1 Additional Data"; APCO NENA 2.105.1-2017 "NG9-1-1 Emergency Incident Data Document (EIDD)"; or IETF RFC 7852 "Additional Data Related to an Emergency Call" and other options. In particular, with the implementation of NG911, in addition to the primary call data from the SIP INVITE and MESSAGE, and the primary street address and / or geodetic location data, telecommunications personnel and emergency responders will obtain various forms of additional data. The additional data is related to three entities typically associated with an emergency call: the caller making the emergency call, the location from which the emergency call is made, and the call itself. The Call-Info header included in the SIP INVITE or MESSAGE method may include a URI pointing to an externally hosted source of referenced additional data, or the data may be included by value in the call. As described below, when additional data is passed "by reference," it is retrieved via a secure hypertext transfer protocol (HTTPS) or hypertext transfer protocol (HTTP) GET operation issued to the referenced additional data repository (ADR) where the additional data is stored. The data collected by the PSAP while processing the call is captured in an Emergency Incident Data Document (EIDD) and passed to other agencies related to the incident.

[0037] In other cases, the call information may include a call identifier. In this case, the emergency call may include a voice call, a video call, a text call, a non-interactive call, and other options. The first entity to handle the call is the NG911 emergency platform, which assigns the call identifier. The call identifier may be in the form of a Uniform Resource Name (URN) formed by the prefix "urn:nena:uid:callid", a unique string containing alphanumeric characters, a ":" character, and an element identifier of the element that first handled the call. For example, this may be "urn:nena:uid:callid:a56e556d871:bcf.state.pa.us". The call identifier is added to the SIP MESSAGE using the Call-Info header field for the purpose of "nena-CallId". For example, such a URN may be defined in IETF RFC 8141: "Uniform Resource Names (URN)".

[0038] The call information may also include an incident tracking identifier. The incident tracking identifier may be generated and assigned locally by the first entity in the NG911 emergency platform that handles the emergency call or announces the incident. The incident identifier is added to the SIP MESSAGE using the Call Information header field with a destination 903 of "nena-IncidentId". The form of the incident tracking identifier is a URN formed by the prefix "urn:nena:uid:incidentid", a unique string containing alpha and / or numeric characters, a ":" character, and an element identifier of the entity that first announced the incident. For example, the URN may be "urn:nena:uid:incidentid:a56e556d924:bcf.state.pa.us". This string is typically unique for each event that an element handles over time. One way to create a unique string is to use a timestamp with a suffix that distinguishes multiple events if they may have been created at the same moment in time.

[0039] Exchange

[0040] As used herein, a clearinghouse is a standards-compliant location information server (LIS) and additional data repository (ADR) that emergency personnel can access through a portal or through integration with a PSAP's existing equipment and software. An example of such a clearinghouse is the RapidSOS Clearinghouse, as described in "RapidSOS Clearinghouse" by Karen Marquez (April 2019).

[0041] Now refer to Figure 4 , Figure 4An example of a switch within the NG911 architecture is shown. Figure 4 In the example of FIG, a device such as a user device 410, a wearable device 412, an IoT device 414, or a connected vehicle 416 can send relevant data to a 911 call recipient and a first responder when a PSAP calls back to a clearinghouse. In particular, such a device can communicate with a location center 420, which can find the location of the device as reported by the device. The location center 420 can provide a Phase 2 Fix to an operator location database 422, which can forward the Phase 2 Fix to a location database 424. The Phase 2 Fix can then be provided to a 911 center 430.

[0042] The device can further communicate with an access point 440 such as a cellular tower, which can use triangulation to determine the location of the device. In the case of a cellular tower, the access point will communicate with the wireless operator 442 and provide the data to a selective router 444.

[0043] Selective router 444 may provide the cell tower address to local location database 424 and establish a voice path with 911 center 430 .

[0044] Location database 424 may forward the cell tower information to 911 center 430 .

[0045] In addition to the information described above, device location and additional emergency data may be provided via a robust, secure IP path to the clearinghouse 460. Device location information may include latitude and longitude coordinates, the address of the building, the floor on which the device is located, a floor plan, contact information, company name, caller profile data, and other such information.

[0046] For example, and depending on the device, other data may be provided, including name, age, gender, member identifier, key health information, or other such information about the device owner. In another example, the additional data may include information about the car that triggered the emergency call. The amount and type of data collected may depend on the privacy regulations of the region or country where the device is located.

[0047] However, from Figure 4 As can be seen, all information provided to the 911 center through the clearinghouse or through other databases is associated with the physical device or calling party that initiated the 911 call.

[0048] Attach a database

[0049] The Additional Data Repository (whether part of or independent of the Clearing House) is a database that holds additional data as a functional element in the i3 NENA NG911 architecture. Similar principles apply to the EENA NG112 architecture.

[0050] An ADR contains information that can be associated with an emergency call or caller and is managed and retrieved from outside of ESInet. A device, the originating network, or the caller can operate an ADR, or it can provide data to a third party that operates an ADR.

[0051] All originating networks and service providers SHOULD provide at least a minimum set of information corresponding to that available to legacy 911 systems, which MUST be populated in the ADR when passing by reference, or provided in the body of the SIP transaction when passing by value. Access networks SHOULD provide the same minimum set of information.

[0052] Some ADRs are referred to as "identity-searchable" ADRs (IS-ADRs) and have an optional feature that allows the repository to be searched by the identity of the caller (e.g., the caller's Uniform Resource Identifier (URI)). This functionality is required when data is stored by an entity that is not in the path of the call or access network. For example, this may occur when personal medical data provided by the caller is stored by an entity that the callee trusts to preserve such data.

[0053] The availability of additional data for a given call can be indicated by various techniques. For example, the first technique can be through the AdditionalDataCallInfo header within the initial message of a SIP transaction. These headers can contain additional data by value or by reference.

[0054] The second technique may be through additional caller data that can be retrieved by querying the IS-ADR.

[0055] A third technique may be through a URI assigned to the additional location data, which may be discovered along with an associated additional data service URN.

[0056] A fourth technique may be to exploit the presence of additional data blocks in an element conveying location information, either by value and / or by reference. This may include the Presence Information Data Format Location Object (PIDF-LO).

[0057] The above techniques can be used alone or in combination with each other. The acquisition of additional data can be performed through various mechanisms.

[0058] In the first mechanism, additional data can be retrieved "by reference." In this case, a Call-Info header can be included in the caller's SIP INVITE or MESSAGE method, including a URI pointing to an externally hosted ADR. The additional data can then be retrieved via an HTTPS GET operation targeting the referenced ADR. Location information in a SIP transaction can also include additional data by reference.

[0059] A second mechanism may include "by value" to obtain additional data. In this mechanism, the Call Information header may contain a "Content ID" URL that points to the SIP transaction content containing the additional data XML document. The location information may also contain additional data by value.

[0060] A third mechanism for obtaining additional data may include a "query" method. In this case, additional data is retrieved by querying a resource using information associated with the call. For example, such information may include an ADR for additional data on the location or an IS-ADR for additional data on the calling party.

[0061] Devices such as those within telematics-equipped vehicles and medical monitoring devices that can place emergency calls may have the ability to respond to ADR queries or publish data to an external ADR that will respond to a dereference request. Service providers such as telematics service providers may provide a reference to an ADR instead of a device. Other devices may also provide an ADR for emergency calls.

[0062] IS-ADR can provide a web service. When queried using the caller's From address or P-Asserted-Identity (retrieved from a SIP header field), IS-ADR can return a response that may include, but is not limited to: an XML document containing additional data about the caller (by value); a URI that can be used to dereference the additional data about the caller; an HTTP 333 response (Iterate Reference) instructing the client to direct the query for additional data to the resource specified in the response; and / or an indication that no data was found for the provided From or P-Asserted-Identity URI.

[0063] In the above, the transaction of dereferencing the additional data URI is typically protected. For example, it may be protected by Transport Layer Security (TLS). The dereferencing entity (which may be an ESRP, PSAP, or responding authority) uses its credentials to dereference the additional data URI. The initiating network or service provider can use any credentials as long as the domain listed in the URI is the domain of the SubjectAltName in the credentials.

[0064] The ADR will typically accept certificates that are traceable to a PSAP Certificate Authority (PCA). In some cases, an ESInet entity may only accept certificates from the ADR that are signed by a Certificate Authority (CA) recognized by common web browsers.

[0065] ADRs can host sensitive data, the disclosure of which may be subject to legal, regulatory, privacy and confidentiality requirements and / or local policies. All ADR queries originating from ESInet typically include authentication via credentials traceable to the PCA. If PCA traceability authentication fails, the ADR may provide less sensitive data. All ADRs typically provide data for any valid query. Call status ADRs may limit the length of time they provide data after the associated emergency call has concluded.

[0066] Authorization Framework

[0067] To provide the above, an authorization framework may exist. For example, the OAuth 2.0 authorization framework is described in IETF RFC6749, "OAuth 2.0 Authorization Framework."

[0068] The OAuth 2.0 authorization framework enables third-party applications to obtain limited access to HTTP services on behalf of resource owners by mediating approval interactions between resource owners or by allowing third-party applications to obtain access permissions on their own behalf.

[0069] An authorization grant is a credential that represents the resource owner's authorization to access a protected resource that is used by the client to obtain an access token. The framework defines four grant types: authorization code; implicit; resource owner password credentials; and client credentials, as well as extensibility mechanisms for defining additional types.

[0070] Client credentials or other forms of client authentication can be used as an authorization grant when the scope of authorization is limited to protected resources under the client's control, or to protected resources previously arranged with an authorization server. Client credentials are typically used as an authorization grant when the client is acting on its own behalf, such as when the client is also the resource owner, or when the client is requesting access to a protected resource based on a grant previously arranged with an authorization server.

[0071] If the client is a confidential entity, the client and the authorization server establish a client authentication mechanism that is appropriate for the authorization server's security requirements. The authorization server may, but is not required to, accept any form of client authentication that meets its security requirements. Confidential clients are typically issued or establish a set of client credentials for authenticating with the authorization server. Examples of such credentials may include a password, a public / private key pair, and other options.

[0072] Supplementing IoT data

[0073] While the above examples provide for the use of additional data with next generation emergency services, none of the above architectures provide any universal or standardized solution for sharing with emergency services relevant data generated by deployed IoT devices or other data sources that are not in the communication path between the device that called the emergency services and the emergency service provider. In particular, there is no universal or standardized way to identify and select data sources other than the device that initiated the emergency call or session and provide the selected data relevant to a particular incident to the emergency services in an efficient manner.

[0074] To leverage data from IoT devices and sensors deployed near or associated with an incident, emergency services architecture needs to be enhanced to efficiently identify and access these data sources. These data sources may belong to or be managed by private companies or authorities, by regional administrations, or by individuals, and may reside on different networks and be outside the emergency call path. Therefore, this document defines the appropriate functional architecture and dedicated procedures to enable access to data sources and the data they produce for emergency purposes, in addition to their primary or regular operations.

[0075] Furthermore, in the embodiments described below, registration, identification, and selection of IoT data sources are provided. Specifically, methods are provided for registering data sources, such as deployed IoT sensors or devices, for use in emergency situations. Such a mechanism allows for the correct identification of characteristics of IoT devices and the functionality of such devices in order to select relevant devices for a particular event. For example, there currently does not exist any common (or standardized) solution that can be used to characterize appropriate information about data sources for a registration discovery process that is available to commercial or emergency infrastructure. Similarly, there is no common (or standardized) solution that allows for the selection of relevant data sources, such as based on querying a server containing data source information.

[0076] Further embodiments are described that allow data originating from selected IoT data sources to be made available to an emergency services platform and allow the platform to access such data.Mechanisms are described for identifying and accessing IoT data relevant to a particular emergency situation.

[0077] In other embodiments, credential management is provided. Specifically, the NENA i3 standard for Next Generation 911 assumes the use of TLS between emergency service operators and ADRs, and will provision long-term credentials. If such credentials are linked to a malicious or unauthorized entity, that entity may be able to access the ADR or other data sources. Therefore, the embodiments described below provide mechanisms for specifying and limiting the scope of access authorization.

[0078] Architecture Model

[0079] Now refer to Figure 5 , Figure 5 An example architecture model for providing additional data to an emergency services platform is shown. Specifically, in emergency situations, including smart cities, smart buildings, or enterprises, data from multiple IoT devices (such as security cameras, thermostats, or other sensors located near emergency callers or associated with signal events) can provide useful information for building a common operating picture (COP) for emergency service operators and first responders, and can improve situational awareness of the incident. As used herein, a COP is a common overview of an incident created by evaluating and fusing information from multiple sources, and shared among appropriate command, control, and coordination groups to support joint decision-making, such as in the context of situational awareness.

[0080] Data sources that may be considered for emergency purposes include, but are not limited to, building sensors such as temperature, air conditioning, water leak detection, power, lighting, etc.; enterprise cameras; factory or industrial control sensors such as cameras, gas detectors, infrared sensors, radio frequency identifiers (RFID), etc.; sensors in IoT networks, using private or commercial IoT platforms, telematics data provided by vehicles or road infrastructure, alarms, embedded sensors, or other devices; nursery or hospital sensors related to patient care (such as biometric devices, etc.), or sensors related to management; consumer sensors such as wearable devices, cameras, microphones, etc.; and / or links to smartphones or other devices. These supplementary data sources that may be used for emergency purposes may use different technologies to connect to different communication networks and may be owned or controlled by different individuals or administrators.

[0081] Therefore, as used in this article, supplementary data (SD) is a data set generated by devices including IoT devices, sensors and other data sources, which may be relevant to a specific event. SD is typically initiated by a source other than the device that initiated the emergency call. The SD source can be located near the scene of the incident and can be associated with the incident in different ways. For example, the sensor can be a water level height sensor along the same flooding river or tributary. The correlation of SD with the incident can be established by different entities of the emergency architecture. For example, the correlation can be established according to the policies disclosed in this article or the criteria determined. SD can be supplemented with additional data originating from the device or user that has initiated the emergency call or session.

[0082] These data sources may be registered or enrolled as described below so that, in addition to their normal operation for commercial applications, they may be further accessed for emergency purposes. Registration of data sources for emergency services does not presuppose that these data sources have the capability to initiate emergency calls or emergency data-only / non-interactive sessions, or are associated with or connected to a device that has the capability to initiate emergency calls, etc.

[0083] Thus, the embodiments described herein provide a framework that enables other data sources not directly involved in an emergency call or incident (such as pre-deployed IoT devices or sensors, telematics or environmental data sources, or other devices located or dispatched near an incident) to share supplemental data deemed relevant to emergency services. Such data, referred to herein as supplemental data (SD), is therefore in addition to the data available to emergency services provided by the calling device or ADR.

[0084] according to Figure 5 In an embodiment, a sufficient set of information characterizing each SD source can be recorded in a repository (referred to herein as the Data Source Information Repository (DSIR)). The DSIR can then be queried by other entities involved in emergency incident handling, including the device initiating the emergency call (DOEC), the enhanced additional data repository (E-ADR), the supplementary data provider (SDP), or the emergency services platform (ESP) to identify, access, and retrieve relevant data when necessary. In this case, the ESP can be the PSAP responsible for incident response via ESInet.

[0085] Therefore, in Figure 5 In the embodiment of the present invention, the DOEC 510 interfaces with the DSIR 520, one or more SDPs 530, and the E-ADR 540.

[0086] DOEC 510 is a device, such as a smartphone or IoT device, that initiates an emergency call or a call to ESP 550, for example, by calling an emergency number based on the operating area or by sending an emergency call message to a URN for a SIP call or alert. The device may be able to derive its location when initiating the call. For example, the emergency location service locally calculates the device's location using techniques such as those defined in ETSIEMTEL TS 103 393, "Advanced Mobile Location for Emergency Calls."

[0087] The DOEC can provide additional information, including location information, to the ADR or E-ADR or to the ESP. The DOEC can also provide address information, such as the URI of the ADR, E-ADR, or SDP, to the ESP in the Call Information header. In some cases, the SDP address can be preconfigured in the DOEC. The DOEC can also provide additional information during a call or during call setup using the SIP INVITE, re-INVITE, SIP UPDATE, or SIP INFO methods. In this case, the SIP re-INVITE is a SIP INVITE sent as part of an existing dialog.

[0088] DOEC 510 communicates with DSIR 520 via the IE3 interface defined below. DISR 520 is an entity that stores and provides information about data sources that can be accessed for emergency services purposes. For example, the DSIR may include the location of IoT devices, the type of data generated by the IoT devices, and information that allows for locating and retrieving data, including the URI of the SDP containing the data (which may be a URI pointing to a data resource in the SDP), as well as other options.

[0089] In some embodiments, DSIR 520 may be a centralized DSIR. In other embodiments, DSIR 520 may be distributed.

[0090] In some cases, the DSIR or one or more of the DSIR distributed components may be part of ESP 550. In other embodiments, DSIR 520 or one or more of the DSIR distributed components may be owned or managed by a government or emergency services administrator or a commercial entity. In some embodiments, the DSIR or one or more of the DSIR distributed components may be owned or managed by a commercial entity, such as a private company.

[0091] In some implementations, access to IoT resource-related data may be subject to specific restrictions based on information confidentiality or privacy. Such restrictions may be documented in the DSIR.

[0092] Because data sources may be outside the emergency infrastructure involved in the incident and may belong to private companies or independent organizations, these data sources may need to be registered with the emergency authorities in order to be listed in the DSIR.

[0093] In some cases, the DSIR 520 can be accessed as a web service via an application programming interface (API). In some cases, the DSIR can be an IoT DSIR. Specifically, in this case, the DSIR can reference an IoT data source. In other cases, the DSIR can be an emergency DSIR, in which case the DSIR can refer to a data service accessible for emergency services. In some cases, the API that allows access to the DSIR can also provide a result code and a message indicating success and / or failure.

[0094] DOEC 510 can further communicate with one or more SDPs 530 via an IE4 interface, as described below. Each SDP is a resource server or web service. The SDP can reside on an IoT platform, server, or gateway in the cloud. The SDP stores SDs that may be related to a particular event. For example, the data may include temperature values ​​obtained from a thermostat located near the event or DOEC. During normal operation, this data can be used for commercial or private purposes. The SDP storing the SDs and related resources related to the event can be identified and located via information records in DSIR 520.

[0095] Therefore, the SD can include data from IoT devices / sensors and can be provided to the ESP by commercial or private applications on the IoT platform. In this framework, the SD can be accessed via the SDP. As used in this article, the SDP is the functional entity that provides the SD to the ESP. The SDP can be an IoT platform, server, gateway, device, web service, or other options.

[0096] The SDP can provide an API to create a resource to provide a SD associated with a specific event for the ESP and later delete the resource. When the SD is no longer needed, the ESP can call the API to delete the resource. Alternatively, the SDP can delete the resource after a certain period of inactivity or after a certain time has passed since its creation. The API that allows access to the SDP can also provide a result code with a message indicating success and / or failure.

[0097] For example, a resource can be created using the HTTPS PUT or POST method and accessed using the HTTPS GET method, as described below. A resource created in an SDP can be uniquely identified by an SD identity. The resource is associated with data related to a specific event. The SDP can determine which data to share with the ESP based on the configured policies when creating the resource, for example, based on regulatory compliance or privacy protection rules to avoid unnecessary data leakage or privacy leakage. The SDP can also request the data source corresponding to the SD (for example, an IoT device or sensor) to provide the latest data so that when the ESP requests access, the SDP can provide the latest information.

[0098] Alternatively, some data resources registered by the DSIR can be accessed without requiring the resource to be created by the client accessing the SDP. In this case, it is assumed that the resource already exists in the SDP, for example as a data record in the SDP, and can be directly accessed using a resource reference, such as a URI provided by the DSIR. In some examples, the resource in question may be created by the SDP administrator when the corresponding data source is registered in the DSIR, or at some other time. As described above, access to the resource can be performed using the HTTPS GET method.

[0099] Furthermore, while the number of (IoT) data sources and IoT networks increases and the amount of relevant data increases, it may not be efficient or practical to aggregate all SDs available for emergency purposes into a single repository. To address this issue, Figure 5 The reference architecture supports multiple SDPs or distributed SDPs. The ESP will access one or more SDPs 530 identified by the DSIR 520.

[0100] Based on the architecture disclosed above, if a resource is created for the ESP to access data, the SDP 530 provides the data to the ESP via the resource. The SD can access the resource via an API targeted at the resource. Alternatively, an explicit resource creation step may not be required, such as if the resource is pre-configured in the SDP at the data source registry in the DSIR.

[0101] The data accessed via the SDP can be limited to a subset of the data held by the SDP. For privacy or other policy reasons, in some cases, only this subset of data may be provided to the ESP.

[0102] As described above, additional data related to the emergency call, location, caller, and other such additional data can be stored in and served by the ADR or E-ADR. Furthermore, the data provided via the SDP includes data from one or more other sources. The ESP uses this data to supplement the data provided by the DOEC, ADR, or E-ADR to supplement the COP for the emergency event.

[0103] DOEC 510 can further communicate with E-ADR 540 via the IE2 interface, as described below. The E-ADR is an ADR that provides enhanced features according to this embodiment. In addition to storing and providing "additional data" characterized as related to the call, location of the emergency call, or the calling party in the conventional ADR described above, the E-ADR can also determine one or more SD sources associated with a specific event by querying DSIR 520. Furthermore, the E-ADR can request a corresponding SDP to create resources for ESP 550 to access the SD. The SDP can provide an API as defined in this disclosure for the creation and subsequent deletion of resources.

[0104] DOEC 510 can further communicate with ESP 550 by IE1 interface, as described below.ESP 550 is for providing services for public safety agencies such as police, fire protection or medical services, and these services can be by dialing special access number (such as, 911 in North America or 112 in Europe) and other such numbers around the world or by sending emergency message to URN such as urn:service:sos to contact. New generation emergency service can be accessed by ESInet usually, and this ESInet comprises call router, such as ECRF, PSAP or emergency call center. In the context of the present disclosure, ESP 550 receives emergency call and accesses one or more SDPs from DOEC 510, and this SDP provides access to the SD relevant to emergency situation to supplement COP, and this COP will be used to provide suitable emergency response.

[0105] In addition, if Figure 5 As shown, one or more of DOEC 510, ESP 550, and E-ADR 540 can communicate with authorization server (AS) 560 using the IE6 interface. AS 560 authorizes access to resources hosted in SDP 530. For example, DOEC and E-ADR request authorization to create resources associated with a specific event in the SDP. ESP 550 requests authorization to access the SD in SDP 530. When ESP 550 determines that the SD is no longer needed, ESP 550 can request authorization from AS 560 to delete the resource.

[0106] Access authorization may be granted before ESP 550 accesses SDP 530 for obtaining data related to a particular event. Security may be enhanced by limiting the scope of resource-specific authorization (ie, the SD to be shared with the ESP) and the duration of the authorization to a short value.

[0107] The authorization server can grant an access token to the ESP 550 to allow the ESP to access the resources corresponding to the SD on the SDP. The scope of the access token is limited to the data resources related to the specific event, which is identified by the SD identity defined above.

[0108] exist Figure 5 In one or more supported embodiments, the DSIR 520 may communicate with the DOEC 510, E-ADR 540, or ESP 550 using an IE3 interface.

[0109] In a similar embodiment, the SDP 530 may communicate with the DOEC 510 or the E-ADR 540 using an IE4 interface, and the ESP 550 may communicate with the E-ADR 540 or the SDP 530 using an IE5 interface.

[0110] These interfaces are described in more detail below.

[0111] based on Figure 5 , various SD sets can be provided to emergency service providers using the architecture and interfaces described herein. Figure 5 architecture, various scenarios can be implemented as different embodiments, depending on the entity that determines the (multiple) SDPs associated with the event, for example, by querying the DSIR, or any other method from pre-configured information according to the scenarios further described below.

[0112] Specifically, in the first scenario, DOEC 510 determines the SDP associated with the event. Figure 6 In a second embodiment, the E-ADR may determine the SDP associated with the event, as shown below: Figure 7 In a third embodiment, ESP 550 queries DSIR 520 and determines SDP. Figure 8 This third embodiment is described.

[0113] In each of the three embodiments, the DSIR stores information about data sources that are registered as available for emergency purposes. These data sources may be owned or managed by one or more data providers.

[0114] For each registered data source, the DSIR contains multiple data service features to enable the DOEC, E-ADR or ESP to perform appropriate query, search and selection when an emergency call is triggered when an incident occurs.

[0115] Furthermore, assuming that the URI stored in the DSIR refers to data or records corresponding to the data source selected in the corresponding SDP, or may refer to the SDP itself, the ESP may store the credentials required to query the SDP. Otherwise, the ESP will request access authorization from the authorization server.

[0116] DOEC determines SDP(s)

[0117] Now refer to Figure 6 .exist Figure 6 In the embodiment of , DOEC 610 determines the SDP associated with the event. In particular, Figure 6 In the embodiment of the present invention, the DOEC 610 can communicate with various entities, including the E-ADR 612, the first SDP 614, the second SDP 615, the DSIR 616 and the ESP 618.

[0118] exist Figure 6 In the embodiment of the present invention, the DSIR 616 includes a set of recorded SDP data source attributes, as shown in block 620.

[0119] Once the emergency is triggered, as indicated by block 622, the process proceeds to block 624, where DOEC 610 assigns an SD identity. The SD identity uniquely identifies the SD associated with the emergency locally. In one embodiment, the SD identity includes a locally determined identifier, such as a URN based on the name or address of the organization to which DOEC 610 belongs, as well as a random value and / or a timestamp. Other identities are possible. This identity also identifies resources created on one or more SDPs for sharing the SD with ESP 618.

[0120] After assigning the SD identity, DOEC 610 sends a SIP INVITE / MESSAGE 630 with call information to ESP 618. The call information includes the SD identifier assigned at block 624, and the address 612 of the E-ADR, or a known SDP 614 or 615. Message 630 thus initiates an emergency call or session to ESP 618. The call information header of the call or session initiation message includes the SD identity and the address of the SDP(s). If the DOEC is pre-configured with knowledge of the URI, the address can be the URI of the associated SDP. Alternatively, the address can be a URI pointing to a resource at the DOEC.

[0121] The ESP 618 uses the SD identity and URI to access the SD. The Call Information Header may also include a URI for accessing additional data in the E-ADR 612, among other options.

[0122] If the DOEC is not pre-configured with the URI of the SDP resource, the DOEC 610 will send a message 632 to the DSIR 616 to determine one or more SDPs associated with the event. The message 632 may carry information including the location of the DOEC and the type of emergency, e.g., police, fire.

[0123] The DSIR 616 may then send a response 634 with a series of information including, for example, the URI of the SD source, the DOEC location and data list, and other information. Figure 6 In the example shown in FIG, two SDPs are identified.

[0124] If the DOEC is pre-configured with the URI of the SDP resource, message 632 and response 634 are optional.

[0125] DOEC 610 then requests the creation of a resource in the SDP of the first identity. The resource is referenced by the SD identity with the first SDP. The ESP can then access the resource to obtain the SD. Event data such as a timestamp, location, or data list can be provided. An example of a data list is provided in the interface description below.

[0126] Before DOEC 610 requests to create a resource in SDP 614, it can establish a secure connection with the AS and request an access token. The access token is scoped to the resource identified by the SD identity (not shown). In some cases, DOEC 610 includes the access token in the request to create the resource. This request is sent from DOEC 610 to SDP 614 as message 640.

[0127] The SDP 614 verifies the access token, and if successfully verified, the SDP creates the resource identified by the SD identity and sends a response 642. The response 642 indicates whether the resource was successfully created or whether the data is not available or other result code.

[0128] Since the response 634 includes two URIs of the SD source, the process of creating the resource can be repeated on the second SD source. Figure 6 In the example of , DOEC 610 sends a message 650 to SDP 615 to create a resource. Message 650 may include an SD identifier, event data such as a location and data list, and any access tokens.

[0129] The SDP 615 may then send a response 652 to indicate whether the resource was successfully created or if the data is unavailable, or other result code.

[0130] ESP 618 may then send a request to DOEC 610 for access to the resource identified by the SD identifier, as shown in message 660. In response, DOEC 610 sends a response 662 with an indication of whether the resource was successfully created, along with the URL of the various SDPs on which the resource was created. If the resource was not created, response 662 may indicate this or include other result codes.

[0131] If DOEC 610 provides SDP information in message 630 , ESP 618 skips message 660 and response 662 .

[0132] ESP 618 can then access the resource identified by the SD identity of the first identified SDP and receive information about the data provided by the first SDP in the created resource. The ESP accesses the data based on this information. Before accessing the first SDP, the ESP can establish a secure channel with the AS to obtain an access token. The scope of the access token is limited to data related to a specific event, which is identified by the SD identity (not shown). The access request 670 from the ESP can include the access token. The SDP 614 verifies the access token and, if successful, sends a response 672 with information about the SD to ESP 618. If the access token is not successfully verified by the SDP 614, the response 672 can indicate this or include another result code.

[0133] Similarly, ESP 618 may send an access request 680 to SDP 615, and SDP 615 may send a response 682 with the URI and the dereferenced data to ESP 618. If the access request is denied by SDP 615, response 682 may indicate this, or include other result codes.

[0134] therefore, Figure 6 The embodiment provides a scenario in which DOEC 610 determines SDP.

[0135] E-ADR determines SDP(s)

[0136] In another embodiment, the E-ADR may determine one or more SDPs associated with the event. Figure 7 .exist Figure 7 In the embodiment of FIG. 7 , DOEC 710 communicates with E-ADR 712. Additionally, two SDPs are shown, namely SDP 714 and SDP 715.

[0137] DSIR 716 and ESP 718 also form part of the emergency network.

[0138] exist Figure 7In an embodiment of the present invention, DSIR 716 includes SD source information 720.

[0139] When DOEC 710 signals an emergency, as indicated by block 722, the process proceeds to block 724, where the DOEC assigns an SD identity. The SD identity uniquely identifies the SD associated with the emergency locally. The SD identity may include a locally determined identifier, such as a URN based on the name or address of the organization to which the DOEC belongs, as well as a random value and / or a timestamp. However, in other embodiments, the SD identity may include other data used to uniquely identify the SD.

[0140] The SD identity also identifies the SD and the resource(s) created in one or more SDPs for sharing the SD with the ESP718.

[0141] The DOEC may then initiate an emergency call or session to the ESP 718, as shown in message 730. The Call Info header of the call or session initiation message includes the SD identity and the address (URI) of the E-ADR 712.

[0142] The DOEC 710 may also provide device additional data to the E-ADR 712 in a message 732. Such additional data may include the DOEC's location information and the SD identity or event identifier.

[0143] Once E-ADR 712 receives message 732, it may initiate a query for discovering a supplemental data source to DSIR 716. Query 734 may provide information such as location, type of emergency, and other options.

[0144] In response to receiving the query 734, the DSIR 716 may send a response 736. The response 736 may include one or more SDP URIs. Figure 7 In the example of , two SDPs are identified. If the query cannot be answered by DSIR 716, response 736 may indicate this, or include other result codes.

[0145] The E-ADR 712 may then create a resource for the identified first SDP. The resource is referenced by the SD identity in the first SDP 714. The resource is created using a message 740 that includes the SD identity, event data such as location and data lists, and other information.

[0146] Additionally, before E-ADR 712 requests the creation of a resource on SDP 714, it may establish a second secure connection with the AS to request an access token. The scope of the access token is limited to data related to a specific event, which is identified by the SD Identity. E-ADR 712 includes the access token in message 740. First SDP 714 verifies the access token and, if verified, creates the resource identified in the SD Identity and sends a response 742. Response 742 may indicate success, data not available, or other result codes.

[0147] Similarly, if two SDPs are identified in message 732, E-ADR 712 may create the resource at SDP 715 as shown in message 750. A response 752 indicating whether the resource was successfully created or that the data is not available may be sent back to E-ADR 712 or contain other result codes.

[0148] ESP 718 may access E-ADR 712 to obtain additional data and receive the URI of the SDP resource using message 760. A response to message 760 is provided as response 762 and includes Figure 7 The URIs of the first SDP and the second SDP in the example.

[0149] ESP 718 can then access the resource identified by the SD identity in the first identified SDP, as shown in access request 770. The ESP accesses the data based on the received information. Before accessing the first SDP, the ESP can establish a secure connection with the AS and obtain an access token. The access token is scoped only to the data resource associated with the specific event, which is identified by the SD identity. The access request from ESP 718 can include the access token.

[0150] The first SDP 714 verifies the access token and responds to the ESP 718 with a response message 772 having information about the data. If the SDP 714 does not verify the access token, the response 772 may indicate this, or contain other result codes.

[0151] Similarly, ESP 718 may access the resource identified by the SD identity in the second identified SDP, as shown by access request message 780 to SDP 715. Again, a token may be used for such an access request.

[0152] In response to message 780, SDP 715 responds with message 782 providing information about the data. If SDP 715 cannot grant access, response 782 may indicate this or contain other result codes.

[0153] Figure 7The embodiments therefore provide a scenario where E-ADR determines SDP.

[0154] ESP determines SDP

[0155] In another embodiment, the ESP may determine one or more SDPs associated with the event. Figure 8 .exist Figure 8 In the embodiment of the present invention, once a given data source has been registered in the DSIR, the corresponding SDP record generally contains valid data and can be used for querying. In this case, the data can be updated asynchronously by the data provider based on, for example, associated devices and other options.

[0156] exist Figure 8 In the embodiment of FIG. 8 , the DOEC 810 communicates with the E-ADR 812 .

[0157] In addition, Figure 8 In the embodiment of FIG, two data sources are shown, namely SDP 814 and SDP 815.

[0158] exist Figure 8 In the embodiment of , the SDP data source information is registered at DSIR 816, as shown in block 820.

[0159] Upon the occurrence of an event as shown at block 822 , the DOEC 810 triggers an emergency call or session to an emergency number or towards an emergency URN. The emergency call process is initiated by the DOEC with a message 830 towards the ESP 818 .

[0160] In this case, the message 830 is a SIP INVITE, or for a non-interactive call, the message 830 may be a SIP MESSAGE. Other methods may be used for the above alternatives. The message header includes additional information by value and / or a reference to the E-ADR.

[0161] DOEC 810 may provide additional data related to the call, such as the location or calling party (e.g., based on the location of the device), to E-ADR 812 in message 832. In an alternative embodiment, this information is provided to a traditional ADR if DOEC is enabled for this feature.

[0162] Furthermore, in some embodiments, message 832 may need to be sent before message 830 if the URI of the data recorded in the E-ADR or ADR is provided by the E-ADR or ADR and is not known to the DOEC when message 830 is sent.

[0163] If the additional data information is included by reference in message 830, ESP 818 can retrieve or dereference the corresponding data by executing an HTTPS GET request 840 or similar message to the E-ADR or ADR for the URI(s) received in the SIP transaction. In response, ESP 818 can receive a response 842 that provides the corresponding dereferenced data. If the E-ADR or ADR cannot provide the corresponding dereferenced data, response 842 can indicate this or include another result code.

[0164] ESP 818 can then query DSIR 816 to determine one or more SDPs associated with the event signaled by the emergency call.Request 850 can include data such as an indication of proximity to the event location (e.g., a maximum distance or a relevant geographic area), and sensor category or data type, and other such information.

[0165] In response to message 850, DSIR 816 sends a response 852 that provides the SDP or URI for the supplemental data. If DSIR 816 cannot provide the requested data, response 852 may indicate this or include other result codes.

[0166] Thereafter, ESP 818 may query the corresponding data by performing an HTTPS GET request 860 or similar message to SDP 814 for the URI(s) received in DSIR response 852 .

[0167] SDP 814 may then provide the URI and dereferenced data in response 862. If SDP 814 cannot provide the URI and dereferenced data, response 862 may indicate this, or include another result code.

[0168] Similarly, ESP 818 may utilize an HTTPS GET request or similar message to SDP 815 at message 870, and receive the URI and dereferenced data in response as message 872. If SDP 815 cannot provide the URI and dereferenced data, response 872 may indicate this, or include other result codes.

[0169] IoT for Emergency (IE) Architecture Interface

[0170] exist Figure 5 In the embodiment, and for Figures 6 to 8 Various entities communicate with other entities using IoT Emergency (IE) interfaces. Figure 5 The interfaces are labeled IE1 to IE6. Each interface is described below.

[0171] IE1 interface

[0172] IE1 interface is from Figure 5 The interface between the DOEC 510 and the ESP 550 is used to signal emergency calls based on protocols such as IMS and ISDN. The SD identity is added to the call header of the SIP INVITE, re-INVITE, INFO, UPDATE, or MESSAGE methods, or as an information element of the DOEC's setup message.

[0173] According to use Figures 6 to 8 In which embodiment, it may be necessary to add an SD identity. In the case of SIP signaling, the SD identity may be added according to one of the following options.

[0174] In a first option, an SD identity can be added as a new header parameter of a SIP transaction. For example, such an SD identity can be added in IETF RFC 3261 "SIP Session Initiation Protocol" for INVITE, or IETF RFC 3428 "SIP Instant Messaging Extensions" for MESSAGE, among other options.

[0175] In a second option, the SD identity may be added as a new parameter in the "Call Info" header, such as defined in IETF RFC 3261. This is shown in bold in Table 1 below, for example.

[0176]

[0177]

[0178] Table 1: Call-Info header parameters in SIP INVITE for SD identities

[0179] In a third option, the SD identity may be added as a new block of "additional data" specified for emergency calls in IETF RFC 7852 "Additional data related to emergency calls." This is shown in bold in the example of Table 2 below, for example.

[0180]

[0181]

[0182] Table 2: New additional data blocks for SD identity

[0183] In a fourth option, the SD identity may be added as new information in one of the "Additional Data" blocks. For example, the SD identity may be added in the "Service Information" block defined in IETF RFC 7852.

[0184] In a fifth option, the SD identity may be added by embedding the CAP message as an additional data block, as described in IETF draft-ietf-ecrit-data-only-ea-20 "Non-interactive emergency calls" for non-interactive emergency calls. In this case, for example, the information may be in the " <incidents>” is transmitted in the CAP element.

[0185] The IE1 interface may also be used to transmit the relevant SDP URI (if known to the DOEC) or other information known to the DOEC that may help the ESP retrieve the SD. Similar options to those described above may be specified to enhance the relevant SIP protocol methods to transmit such information.

[0186] IE2 interface

[0187] The IE2 interface is the interface between the DOEC 510 and the E-ADR 540. It is based on the interface defined in EENA STA-010.3, "NENA i3 Standard for Next Generation 9-1-1." For example, a device enabled for a given E-ADR 540 provides location information to the E-ADR. The DOEC 510 can also provide the E-ADR 540 with its SD identity.

[0188] The IE2 interface enhances the existing interface between the DOEC and the ADR. The existing interface allows the device to provide additional data it possesses to the ESP, such as the caller number and location information. Through the enhanced IE2 interface, the DOEC can provide the SD identity, event description, and the caller number and location information. The additional information enables the E-ADR to determine the SDP by querying the DSIR and requesting the identified SDP to create resources to share the SD with the ESP. The protocol for the interface can be based on HTTPS, Constrained Application Protocol (COAP), or Message Queuing Telemetry Transport (MQTT), among other options. An example of HTTPS with content type JavaScript Object Notation (JSON) is shown below for Table 3.

[0189]

[0190] Table 3: Supplementary data for HTTPS with content type JSON

[0191] IE3 interface

[0192] The IE3 interface is used to query the DSIR 520 for information about the SDP 530 storing data related to a specific event. DOEC, ESP, E-ADR, or SDP can use the IE3 interface to access the DSIR to obtain the URI of the SDP for a specific event.

[0193] The IE3 interface is used to query the DSIR for information about SD sources and / or SDPs that hold data that may be relevant to a particular event. The DOEC, E-ADR, or ESP can access the DSIR to obtain the URI of the SDP and / or the SD resource selected based on criteria provided by the requesting entity.

[0194] Queries to the DSIR can be implemented using different tools, such as RESTful web services / APIs (e.g., HTTP or HTTPS queries or OpenAPI), remote procedure calls (RPC) or GraphQL APIs, Structured Query Language (SQL), or other languages, depending on the DSIR implementation chosen.

[0195] The information stored by the DSIR about registered data sources may include additional data information descriptions according to IETF RFC 7852. The information stored by the DSIR may include more information or extensions for additional parameters that may be required or helpful in determining the relevant data source, including but not limited to DataInfo.SensorFunction indicating temperature, humidity, gas detectors, smoke detectors, and other options.

[0196] When used in a DSIR, geographic information can be encoded according to the Presence Information Data Format Location Object (PIDF-LO) scheme, such as provided in IETF RFC 5491, "GEOPRIV Presence Information Data Format Location Object (PID F-LOL) Usage Classification, Considerations, and Recommendations." This encoding can encode complex shapes. For example, an ESP tool can encode the incident location in an "incident-area.xml" XML file as a geographic shape enclosed by a circle, polygon, etc., through which it can query for SD sources located within that shape. Other encoding methods may be used.

[0197] A pseudocode example for querying a data source under certain criteria is shown with respect to Table 4 below.

[0198]

[0199] Table 4: Example pseudocode representing querying a data source

[0200] The query may return a list of URIs pointing to SDP / data records that match the indicated criteria (if any), or an empty list otherwise. In some embodiments, the DSIR may return the number of identified data sources and / or the number of identified data records corresponding to the query. If any of these numbers exceeds a certain threshold, the DSIR may limit the amount of information returned to the indicated threshold, such as a first list containing a number of elements corresponding to the threshold. In addition, the requester may request more information, such as a second list that is a continuation of a previously obtained list, or refine the query to select fewer data sources.

[0201] The query may return a file, such as an XML file or a JSON object, to provide information about the retrieved data sources stored in the DSIR, including some or all of the information used to register the data sources, so that the requester can further evaluate the relevance of the data sources and, for example, manually or based on a policy, down-select or prioritize the information. In some cases, the prioritization of information may be automated or may be assisted using a graphical display of the sources on the PSAP CAD and other options.

[0202] For example, pseudo code for a strategy for constructing a query may be specified as shown below with respect to Table 5.

[0203]

[0204]

[0205] Table 5: Example pseudocode for a strategy for building a query

[0206] The returned URI corresponding to the SD resource selected by the DSIR can be one of multiple URIs. In a first embodiment, the returned URI can be a URI pointing to a data record that can be further retrieved from the SDP, such as: https: / / api.sdp1.com / directory-1 / data-source-1. In a second embodiment, the returned URI can be a URI pointing to an SDP where the resource should be created before retrieving the data, such as: https: / / api.sdp1.com / sd / .

[0207] In some embodiments, a single (absolute) identity may be used to identify a resource within an SDP. In this case, separate identities may be provided to identify the SDP and the resource location within the SDP. An identity may be a relative name or a local name.

[0208] Embodiment support for returned URIs may depend on the embodiment and implementation choices of the entities involved, and will typically be implemented consistently between ESP and each SDP.

[0209] For the embodiments described above for IE3, it is assumed that the DSIR client maintains appropriate credentials to access a given DSIR.In the case of a distributed DSIR, the same or different set of credentials may be used for each of the multiple DSIR components.

[0210] IE4 interface

[0211] The IE4 interface provides an API for requesting one of the identified SDPs 530 to create a resource for ESP 550 to access data related to a specific event. SDP 530 can store data related to IoT devices for normal business operations. Upon receiving a request to create a resource with an SD identity through IE4, SDP 530 can select a subset of data that can be shared with ESP 550 based on configured policies and make it available through the created resource. This interface can be based on HTTPS or HTTP protocols. In some embodiments, a PUT method or POST method can be used to create a resource.

[0212] Therefore, the main feature of the IE4 interface is to provide an API that enables the client (DOEC, E-ADR, SDP, or ESP) to create a resource within the SDP. The created resource is used to share the SD for a specific event with the ESP. The resource is identified by an SD identity. The request to create a resource can include the SD identity, event data (such as the timestamp of the event), the location of the event, a list of data to be shared via the resource, and an access token. The access token can include an authorization scope limited to the SD identity.

[0213] When the SDP receives the request, it verifies that the access token is correctly signed and that the token is scoped to the SD identity. If the token is successfully verified, the SDP can determine whether data source information is provided. If this information is provided, the SDP can determine whether the data source can be shared with the ESP based on the policy configured in the SDP. If the SDP determines that the data source can be shared, the SDP identifies and stores data asset information, including at least one attribute of the data, for use with the ESP associated with the data source. For example, the data asset information can describe the data type, such as a video stream, integer or character type, the time when the data was captured, and other options.

[0214] The SDP can also request the latest data from the data source corresponding to the data asset (e.g., IoT device or sensor) so that when the ESP requests access, the SDP can provide the latest information. In one embodiment, the data source can subscribe to a command or topic (update request), and the SDP can utilize MQTT or similar protocols to publish the command or topic to refresh the data.

[0215] If no data source information is provided in the request, the SDP may search for and identify a data source to be shared with the ESP based on the location information and timestamp information included in the request. For example, the SDP may find a data source provided by a sensor close to the location information. The validity of the relevant data may be subject to time considerations compared to the indicated timestamp (e.g., the data age does not exceed a timestamp threshold). The SDP determines whether the data source can be shared with the ESP based on the policy configured in the SDP. If the SDP determines that the data source can be shared with the ESP, the SDP identifies and stores the data asset information associated with the data source.

[0216] The protocol for the interface can be based on HTTPS, COAP, MQTT or similar protocols. An example of HTTPS with content type JSON is shown below with respect to Table 6 to create a resource with SD identity equal to 202002101422-12345678.

[0217]

[0218] Table 6: Example HTTPS for creating resources

[0219] IE5 interface

[0220] The IE5 interface provides an API for ESP 550 to access specific resources to obtain the SD related to a specific event from the SDP. In one embodiment, it is based on the HTTPS GET method applied to the resource identified by the SD identity on the SDP 530.

[0221] In some embodiments, IE5 can also provide an API for ESP550 to delete resources based on the HTTPS DELETE method.

[0222] In some embodiments, the interfaces for accessing the SDP 530 and the E-ADR 540 are based on the same IE5 principles and specifications. In other embodiments, different interfaces may be specified for accessing the SDP 530 and the E-ADR 540.

[0223] The primary feature of the IE5 interface is that it enables the ESP to access the SD associated with a specific event from the SDP. The ESP is provided with the address information (e.g., URI) of the SDP by the E-ADR, DSIR, or DOEC, and, depending on the scenario, the SD identity or the SD URI. The ESP can obtain an access token from the AS and include it in a request to access the resource identified by the SD identity in the SDP.

[0224] When the target resource is specified as an SD Identity as shown in the example below in Table 7, the SDP responds with information about the data made available through that resource. The data is based on asset information that the SDP has identified and stored.

[0225] The protocol for the interface can be based on HTTPS, COAP, MQTT, or similar protocols. An example for HTTPS with content type JSON is shown in the example of Table 7 below. In response to a GET message sent to a resource (identified by SD identity 202002101422-12345678), ESP receives hyperlinks to the other two SDPs and the SD description that can be used from the SDP to which the HTTPS GET request is sent. ESP can send subsequent HTTPS GET requests to the other two SDPs and the two specific media assets identified for the SD identity.

[0226]

[0227]

[0228] Table 7: Example HTTPS GET for obtaining supplemental data

[0229] Using the example of Table 7 above, if the target resource is indicated as the URI of the SD in the request, the SDP will provide the SD in the response.

[0230] IE6 interface

[0231] The IE6 interface is an interface for accessing the authorization server 560 by various entities including DOEC 510, E-ADR 540, SDP 530, or ESP 550. In one embodiment, the interface is based on the OAuth 2.0 protocol. However, this is merely an example, and other protocols may be used.

[0232] Through the IE6 interface, a requesting entity can obtain an access token to access resources in a resource server. For example, a DOEC and an E-ADR can request authorization to create resources related to a specific event in an SDP 530. An SDP 530 can also request authorization to create resources in another SDP.

[0233] ESP 550 can request authorization to access the SD shared by the SDP as a resource server. When ESP 550 determines that the SD is no longer needed, ESP 550 can request authorization to delete the resource. The scope of the authorization or access token requested through the OAuth 2.0 protocol can be limited to the resource identified by the SD identity to prevent access to data in the SDP that is not relevant to the event. The type of authorization granted is client credentials as described above.

[0234] Before accessing SDP, the client can obtain an access token. It is assumed that DOEC, E-ADR, SDP and ESP can establish a secure channel with AS.

[0235] Before requesting to create a resource in an SDP, the E-ADR or DOEC can request that the AS issue an access token whose scope is limited to the SD identity and the create operation. For tokens issued with limited scope, the validity period can be set to a short value. The token can be included in the Authorization header of an HTTPS POST or PUT message.

[0236] Before requesting access to the SD through the SDP, the ESP can request the AS to issue an access token whose scope is limited to the SD identity and read operations. For tokens issued with limited scope, the validity period can be set to a short value. The token can be included in the Authorization header of the HTTPS GET message.

[0237] Before requesting the deletion of a resource identified by an SD identity, ESP can request the AS to issue an access token with a scope limited to the SD identity and the delete operation. For tokens issued with a limited scope, the validity period can be set to a short value. The token can be included in the Authorization header of the HTTPS DELETE message.

[0238] Registering a data source with emergency services

[0239] Registration of an ESP, such as ESP 550, for access to supplemental data for emergency purposes typically includes providing a set of information related to the corresponding data source and storing that information in a DSIR, such as DSIR 520. The DSIR can then be further queried to identify a subset of data sources corresponding to one or more search criteria, such as, but not limited to, information about the location of the event, sensors, or types of data of interest.

[0240] Data source registration can be performed according to a process established between the data provider and emergency services or a delegated representation. For example, this may involve public safety / emergency services (or authorized authorities) identifying and agreeing on an SD provider in advance. It may also involve selecting a set of data sources within the provider's network or platform that may be of interest to emergency services. It may further involve providing a list of selected data sources and related information so that the data sources can be recorded in the DSIR (this can be an automated process) and further retrieved according to the above-mentioned embodiments. It may also involve providing sufficient information regarding the encoding format of the data accessible to the ESP. This encoding format can be specified using one of a variety of encoding methods, such as XML, JSON, ASN.1, or other formats. The selected encoding format can be stored as an indication in the DSIR, and this indication can be used when retrieving data. In other embodiments, the selected encoding format can be indicated by the SDP when the data is retrieved (this can allow for more flexible data format adaptation). Depending on the embodiment, the encoding format can be associated with a specific data source, with multiple data sources associated with a given SDP, or with multiple data sources recorded in the DSIR. Other embodiments are possible.

[0241] In some embodiments, a discovery process can be used to automatically find available data sources in the provider's network, thereby facilitating or automating the process of registering data source information into the DSIR. Such a discovery process may require the definition of discovery strategies on both the provider side (e.g., regarding which data sources and which corresponding data can be shared) and on the emergency service side (e.g., regarding how to select which data sources and which corresponding data are of interest for emergency purposes). The discovery process can be based on modeling data sources or data according to different formats (e.g., XML, JSON, ASN.1) or technologies (e.g., in some examples, semantic interoperability technologies using appropriate representations and dictionaries, ontology-based technologies such as oneM2M Smart Device Template (SDT), ETSI Smart Application Reference (SAREF)).

[0242] The registration operation may require authentication of the SD provider to the Emergency Management Platform (e.g., ESP), or mutual authentication between the two parties. This may require a cooperation / interworking agreement between the two parties. The SD provider may be provided with the credentials required to perform the registration of the SD source.

[0243] The information related to the data source stored by the DSIR may include part or all of the additional data information, such as but not limited to the data structure, data block, data element or field specified by IETF RFC 7852, which has possible extensions for supplementary information that can be added.

[0244] Some information, such as data provider information and service information, may be common to a set of data sources. The provision of a subset of information (e.g., data provider ID, data provider contact URI, etc.) may be mandatory for the registration process and / or enforced by the registration process or policy. Whether the provision of information is mandatory may depend on the data source type or other conditions.

[0245] Specific information or process requirements may apply to the registration of consumer devices or data sources that are owned or managed by individuals rather than businesses or organizations. Specific verification processes may be enforced based on user or device-related information (e.g., not allowing anonymous Universal Integrated Circuit Card (UICC) or Subscriber Identity Module (SIM) registration of devices), based on obtaining device type certification, or based on other attributes to ensure a minimum level of trust in the associated data.

[0246] hardware

[0247] The server, IoT device, SDP, and electronic device that perform the above method can be any electronic device or network node. Such electronic device or network node can include any type of computing device, including but not limited to mobile devices such as smart phones or cellular phones. Examples can also include fixed or mobile user devices, such as IoT devices, endpoints, home automation devices, medical devices in hospitals or home environments, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or vehicle devices, fixed electronic devices, etc. Vehicles include motor vehicles (e.g., cars, sedans, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aircraft systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, space shuttles, space capsules, space stations, satellites, etc.), ships (e.g., ships, boats, hovercrafts, submarines, etc.), rail vehicles (e.g., trains and trams, etc.), pedestrians and bicycles, including any combination of any of the above items, whether currently existing or appearing in the future.

[0248] about Figure 9 A simplified diagram of network elements or electronic devices is shown.

[0249] exist Figure 9 In the embodiment, the device 910 includes a processor 920 and a communication subsystem 930, wherein the processor 920 and the communication subsystem 930 cooperate to perform the method of the above embodiment. In some embodiments, the communication subsystem 920 may include multiple subsystems, for example, for different radio and wired technologies.

[0250] Processor 920 is configured to execute programmable logic that may be stored on device 910 along with data and Figure 9 In the example of FIG, , the memory 940 is shown as memory 940. The memory 940 can be any tangible, non-transitory computer-readable storage medium. The computer-readable storage medium can be a tangible or transient / non-transitory medium, such as an optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

[0251] Alternatively or in addition to memory 940 , device 910 may access data or programmable logic from external storage media, such as through communication subsystem 930 .

[0252] The communication subsystem 930 allows the device 910 to communicate with other devices or network elements and may vary based on the type of communication being performed. Additionally, the communication subsystem 930 may include a variety of communication technologies, including any wired or wireless communication technology.

[0253] In one embodiment, communication between the various elements of device 910 may be through internal bus 960. However, other forms of communication are possible.

[0254] In addition, if the electronic device, IoT device, or DOEC has user device capabilities, the following Figure 10 An example electronic device is described.

[0255] The electronic device 1000 may include a two-way wireless communication device with voice or data communication capabilities, or both. The electronic device 1000 may have the ability to communicate with other computer systems. Depending on the exact functionality provided, the electronic device may also be referred to as a data messaging device, a two-way pager, a wireless email device, a smart phone, a cellular phone with data messaging capabilities, a wireless Internet device, a wireless device, a mobile device, an embedded cellular modem, or a data communications device, for example. The electronic device 1000 may also have wired communication capabilities (e.g., USB or Ethernet).

[0256] Where the electronic device 1000 is also capable of two-way communication via cellular, it may incorporate a communication subsystem 1011, including a receiver 1012 and a transmitter 1014, and associated components such as one or more antenna elements 1016 and 1018, a local oscillator (LO) 1013, and a processing module such as a digital signal processor (DSP) 1020. As will be apparent to those skilled in the communications arts, the particular design of the communication subsystem 1011 will depend on the network in which the communication electronic device is intended to operate.

[0257] Network access requirements will also vary depending on the type of network 1019. In some networks, network access is associated with the subscriber or user of the electronic device 1000. The electronic device may require an embedded or removable user identity module (RUIM) or subscriber identity module (SIM) card or UMTS SIM (USIM) in order to operate on the network. The USIM / SIM / UIM interface 1044 is generally similar to a card slot into which a USIM / SIM / RUIM card can be inserted and ejected. The USIM / SIM / UIM card may have memory and store many key configurations 1051, as well as other information 1053 such as identification and subscriber-related information.

[0258] When the required network registration or activation process has been completed, the electronic device 1000 can send and receive communication signals via the network 1019. Figure 10 As shown, network 1019 may include multiple base stations that communicate with mobile devices.

[0259] Signals received by antenna 1016 via communication network 1019 are input to receiver 1012, which can perform common receiver functions such as signal amplification, down-conversion, filtering, and channel selection. Analog-to-digital (A / D) conversion of the received signal allows more complex communication functions such as demodulation and decoding to be performed in DSP 1020. In a similar manner, signals to be transmitted are processed, including modulation and encoding, for example, by DSP 1020, and input to transmitter 1014 for digital-to-analog (D / A) conversion, up-conversion, filtering, amplification, and transmission via antenna 1018 over communication network 1019. DSP 1020 not only processes communication signals but also provides receiver and transmitter control. For example, the gain applied to communication signals in receiver 1012 and transmitter 1014 can be adaptively controlled by an automatic gain control algorithm implemented in DSP 1020.

[0260] The electronic device 1000 typically includes a processor 1038 that controls the overall operation of the device. Communication functions (including data and voice communications) are performed through the communication subsystem 1011. The processor 1038 also interacts with other device subsystems, such as a display 1022, flash memory 1024, random access memory (RAM) 1026, an auxiliary input / output (I / O) subsystem 1028, a serial port 1030, one or more keyboards or keypads 1032, a speaker 1034, a microphone 1036, other communication subsystems 1040 such as a short-range communication subsystem or a DSRC subsystem, and any other device subsystems generally designated 1042. The serial port 1030 may include a USB port, an onboard diagnostic (OBD) port, or other ports known to those skilled in the art.

[0261] Figure 10 Some of the subsystems shown perform communication-related functions, while other subsystems may provide "resident" or on-device functions. Notably, for example, some subsystems (such as keyboard 1032 and display 1022) may be used for both communication-related functions (such as entering a text message for transmission over a communication network), and device-resident functions (such as a calculator or task list).

[0262] Operating system software used by the processor 1038 may be stored in a persistent store such as the flash memory 1024, which may alternatively be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system, specific device applications, or portions thereof, may be temporarily loaded into a volatile store such as the RAM 1026. Received communication signals may also be stored in the RAM 1026.

[0263] As shown, flash memory 1024 can be divided into different areas for both computer programs 1058 and program data storage 1050, 1052, 1054, and 1056. These different storage types indicate that each program can allocate a portion of flash memory 1024 for its own data storage requirements. In addition to its operating system functions, processor 1038 can also enable the execution of software applications on the electronic device. A predetermined set of applications that control basic operations (e.g., including potential data and voice communication applications) will typically be installed on the electronic device 1000 during manufacturing. Other applications can be installed subsequently or dynamically.

[0264] The application and software may be stored on any computer-readable storage medium. A computer-readable storage medium may be tangible or transient / non-transitory media such as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), or other memory known in the art.

[0265] One software application may be a personal information manager (PIM) application that has the ability to organize and manage data items associated with the user of the electronic device, such as, but not limited to, emails, messages, calendar events, voicemails, appointments, and task items. Other applications (including productivity applications, messaging applications, social media applications, games, etc.) may also be loaded onto the electronic device 1000 via the network 1019, auxiliary I / O subsystem 1028, serial port 1030, short-range communication subsystem 1040, or any other suitable subsystem 1042 and installed by the user in RAM 1026 or non-volatile storage (not shown) for execution by the processor 1038. This flexibility in application installation increases the functionality of the device and may provide enhanced on-device functionality, communication-related functionality, or both.

[0266] In the data communication mode, received signals such as text messages or web page downloads will be processed by the communication subsystem 1011 and input to the processor 1038 , which may further process the received signals for output to the display 1022 , or alternatively to the auxiliary I / O device 1028 .

[0267] The user of the electronic device 1000 can also compose data items such as messages, for example, using the keyboard 1032, which can be a full alphanumeric keyboard or a telephone-type keypad (physical or virtual, etc.), in conjunction with the display 1022 and possible auxiliary I / O devices 1028. Such composed items can then be transmitted over the communication network via the communication subsystem 1011.

[0268] Where voice communications are provided, the overall operation of the electronic device 1000 is similar, except that received signals may typically be output to the speaker 1034 and signals for transmission may be generated by the microphone 1036. Alternative voice or audio I / O subsystems (such as a voice message recording subsystem) may also be implemented on the electronic device 1000. While voice or audio signal output is preferably accomplished primarily through the speaker 1034, the display 1022 may also be used to provide, for example, an indication of the identity of the calling party, the duration of the voice call, or other voice call related information.

[0269] Figure 10 The serial port 1030 in the embodiment may be implemented in electronic devices that may need to be synchronized with a user's desktop computer (not shown), but it is an optional device component. Such a port 1030 can enable a user to set preferences through an external device or software application, and can extend the capabilities of the electronic device 1000 by providing information or software downloads to the electronic device 1000 rather than through a wireless or wired communication network. As will be understood by those skilled in the art, the serial port 1030 can also be used to connect the electronic device to a computer to act as a modem or to charge the battery on the electronic device.

[0270] Other communication subsystems 1040 can further provide communication between the electronic device 1000 and different systems or devices, which are not necessarily similar devices. For example, subsystem 1040 can include an infrared device and related circuits and components or a Bluetooth TM or Bluetooth TM Low-energy communication module to provide communication with similarly enabled systems and devices.

[0271] The embodiments described herein are examples of structures, systems or methods with elements corresponding to the elements of the technology of the present application. This written description can enable those skilled in the art to make and use embodiments of alternative elements with elements corresponding to the technology of the present application. Therefore, the intended scope of the technology of the present application includes other structures, systems or methods that are not different from the technology of the present application as described herein, and also includes other structures, systems or methods that are not essentially different from the technology of the present application as described herein.

[0272] Although operations are depicted in a particular order in the accompanying drawings, this should not be construed as requiring that such operations be performed in the particular order shown, or in sequence, or that all illustrated operations be performed to achieve the desired results. In some cases, multitasking and parallel processing may be employed. Furthermore, the separation of various system components in the above-described implementations should not be construed as requiring such separation in all implementations. It should be understood that the described program components and systems may generally be integrated into a single software product or packaged into multiple software products.

[0273] In addition, techniques, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component (whether electrical, mechanical, or other means). Other examples of changes, substitutions, and variations are ascertainable and can be made by those skilled in the art.

[0274] While the above detailed description has shown, described, and pointed out the basic novel features of the present disclosure as applied to various implementations, it should be understood that various omissions, substitutions, and changes in the form and details of the illustrated systems may be made by those skilled in the art. Furthermore, the order of the method steps does not imply the order in which they appear in the claims.

[0275] When sending messages to / from electronic devices, such operations may not be instantaneous or directly from the server. They can be delivered synchronously or asynchronously from a server or other computing system infrastructure that supports the device / method / system described herein. The aforementioned steps may include, in whole or in part, synchronous / asynchronous communication to / from the device / infrastructure. In addition, the communication from the electronic device can be to one or more endpoints on the network. These endpoints can be served by servers, distributed computing systems, stream processors, etc. Content delivery networks (CDNs) can also provide communications to electronic devices. For example, in addition to typical server responses, a server can also provide or indicate data to a content delivery network (CDN) to wait for the electronic device to download at a later time (such as subsequent activity of the electronic device). Therefore, data can be sent directly from a server or other infrastructure (such as a distributed infrastructure or CDN) that is part of the system or separate from the system.

[0276] In general, storage media may include any or some combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical media, such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed across a large system, possibly with multiple nodes. Such (multiple) computer-readable or machine-readable storage media are considered part of an article (or product). An article or product may refer to any manufactured single component or multiple components. One or more storage media may be located in the machine that runs the machine-readable instructions, or at a remote site from which the machine-readable instructions may be downloaded over a network for execution.

[0277] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations of the foregoing details. The appended claims are intended to cover such modifications and variations.< / incidents>

Claims

1. A method at a supplemental data provider within an emergency services network, the method comprising: receiving a message at the supplemental data provider, the supplemental data provider being a resource server or a web server, the message including the supplemental data identity and event data; In response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource being associated with the supplemental data identity; receiving, from an emergency service provider, a request for access to supplemental data associated with the resource, wherein the supplemental data includes data related to the incident and that has been generated by one or more IoT devices, IoT sensors, or other data sources; In response to receiving the access request, providing a response with the supplemental data; and The message also includes an access token from the authorization server, and the access token provides a scope to limit the data resource to the event identified by the supplemental data identity. The method of claim 1 , wherein the message is received from a device initiating an emergency call. The method of claim 1 , wherein the message is received from an enhanced additional data store. The method of claim 2 , wherein the supplemental data identity is created by a device initiating the emergency call. 5 . The method of claim 1 , wherein the access request includes an access token for limiting access to data resources related to the event identified by the supplemental data identity. 6 . The method of claim 1 , wherein each of receiving the message and receiving the access request utilizes one of: a secure hypertext transfer protocol (HTTPS), a constrained application protocol (COAP), or an MQ Telemetry Transport (MQTT) interface. The method of claim 6 , wherein the message is an HTTPS PUT message. The method according to claim 6 , wherein the access request is an HTTPS GET message.

9. A supplementary data provider within an emergency service network, the supplementary data provider being a resource server or a web server, comprising: processor; as well as Communication subsystem, The supplementary data provider is configured to: receiving a message, the message including the supplemental data identity and event data; In response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource being associated with the supplemental data identity; receiving, from an emergency service provider, a request for access to supplemental data associated with the resource, wherein the supplemental data includes data related to the incident and that has been generated by one or more IoT devices, IoT sensors, or other data sources; In response to receipt of the access request, providing a response with the supplemental data; and The message also includes an access token from the authorization server, and the access token provides a scope to limit the data resource to the event identified by the supplemental data identity.

10. The supplemental data provider of claim 9, wherein the message is received from a device initiating an emergency call.

11. The supplemental data provider of claim 9, wherein the message is received from an enhanced additional data repository.

12. The supplemental data provider of claim 10, wherein the supplemental data identity is created by a device that initiates the emergency call.

13. The supplemental data provider of claim 9, wherein the access request includes an access token, the access token being used to restrict access to data resources related to the event identified by the supplemental data identity.

14. The supplemental data provider of claim 11, wherein each of receiving the message and receiving the access request utilizes one of: a secure hypertext transfer protocol (HTTPS), a constrained application protocol (COAP), or an MQ Telemetry Transport (MQTT) interface.

15. The supplemental data provider of claim 14, wherein the message is an HTTPS PUT message.

16. The supplemental data provider of claim 14, wherein the access request is an HTTPS GET message.

17. A computer-readable medium storing instruction codes that, when executed by a processor of a supplemental data provider within an emergency services network, the supplemental data provider being a resource server or a web server, causes the supplemental data provider to: receiving a message, the message including the supplemental data identity and event data; In response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource being associated with the supplemental data identity; receiving, from an emergency service provider, a request for access to supplemental data associated with the resource, wherein the supplemental data includes data related to the incident and that has been generated by one or more IoT devices, IoT sensors, or other data sources; In response to receipt of the access request, providing a response with the supplemental data; and The message also includes an access token from the authorization server, and the access token provides a scope to limit the data resource to the event identified by the supplemental data identity.

Images