US20220150825A9 - NORMALIZATION OF DATA ORIGINATING FROM ENDPOINTS WITHIN LOW POWER WIDE AREA NETWORKS (LPWANs) - Google Patents
NORMALIZATION OF DATA ORIGINATING FROM ENDPOINTS WITHIN LOW POWER WIDE AREA NETWORKS (LPWANs) Download PDFInfo
- Publication number
- US20220150825A9 US20220150825A9 US16/799,157 US202016799157A US2022150825A9 US 20220150825 A9 US20220150825 A9 US 20220150825A9 US 202016799157 A US202016799157 A US 202016799157A US 2022150825 A9 US2022150825 A9 US 2022150825A9
- Authority
- US
- United States
- Prior art keywords
- message
- application
- data
- endpoints
- datae
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
- H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H04L67/2823—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
-
- Y02D70/00—
-
- Y02D70/26—
Definitions
- the present invention relates to normalization of data originating from endpoints within low power wide area networks (LPWANs), such as but not necessary limited to normalizing data when collected and/or communicated according to disparate protocols, languages, formats, syntaxes, structures, etc. of the endpoints and/or the LPWANs so as to enable commonization of the data prior to being interfaced with applications or other entities intending to make use thereof.
- LPWANs low power wide area networks
- the Internet of Things is a growing industry comprised of a massive number of devices that connect to each other to benefit our lives. Examples of these include thermostats, security cameras, voice-commanded personal digital assistants (PDAs) and wearable electronics that may be configured to facilitate any number of operations, such as to enable refrigerators to talk with the Internet to order milk and wearable electronics to tell you when to step more to meet your daily exercise goals.
- PDAs personal digital assistants
- a new area of IoT involves the use of sensors designed for wirelessly transmitting information periodically over long distances for years on a single battery.
- the infrastructure to support these connected devices is commonly referred to as a low power wide area network (LPWAN).
- LPWANs may be designed to cover large geographical areas in a manner intended to minimize the amount of power required for sensors to interact with the network.
- LPWAN network potentially allows IoT devices to run for years on small batteries, occasionally sending out small packets of data, waiting for a short time for response messages, and then closing the connection until more data needs to be sent.
- Devices can also be set up so that they are always listening for messages from their applications, though this requires more power and may be more appropriate for devices that are, plugged in to a wall socket or otherwise operational independently of batteries.
- IoT devices can utilize the LPWAN networks to send small data packets to any number of gateways that may be in a several-kilometer range of a sensor, such as in accordance with the LoRaWAN or other suitable wireless protocol.
- the gateways can then use more traditional communications, such as wired and/or wireless Internet connections, to forward the messages to a network-server that then validates the packets and forwards the application payload to an application-server or other back end processing element.
- One non-limiting aspect of the present invention contemplates normalizing data being communicated over LPWANs or other suitable networks so as to minimize backend or application processing of the data when originating from IoT devices, sensors, endpoints, hardware or other components having different processes, protocols, architectures, properties, etc. for structuring, formatting and communicating the data.
- FIG. 1 illustrates a system for normalizing data communications in accordance with one non-limiting aspect of the present invention.
- FIG. 1 illustrates a system 10 for normalizing data communications in accordance with one non-limiting aspect of the present invention.
- the contemplated normalization may be facilitated with an abstraction layer 12 positioned to facilitate translating, mapping, converting, encoding and/or otherwise manipulating data traversing therethrough for purposes of commonizing the data to an agreed-upon or standardized architecture, format, syntax, protocol, structure, language or other construct.
- the present invention is predominately described for exemplary purposes with respect to normalizing data when originating from a plurality of endpoints 14 in communication with a plurality of low power wide area networks (LPWANs) 16 , 18 , such as to address the above-identified possibility of network operators being tasked with supporting communication of sensor data or other information in the future when the proliferation of the data originating endpoints 14 is expected to reach levels and/or types of traffic flow believed to be best supported with LPWANs 16 , 18 .
- LPWANs low power wide area networks
- the present invention is not necessarily limited to LPWANs 16 , 18 and fully contemplates its use and application in facilitating data normalization within virtually any communication network and/or for data originating from locations other than the endpoints 14 , including normalization of data being transmitted to the endpoints 14 .
- the LPWANs 16 , 18 are generically illustrated with the endpoints 14 communicating with one or more gateways 20 and the gateways 20 in turn communicating with one or more network servers 22 , such as to facilitate upstream communications from the endpoints 14 to the network servers 22 and/or downstream communications from the network servers 22 to the endpoints 14 .
- the endpoints 14 , gateways 20 and servers 22 may optionally be configured in the illustrated manner such that the endpoints 14 wirelessly communicate with the gateways 20 and the gateways 20 in turn wiredly communicate with the network servers 22 .
- One non-limiting aspect of the present invention contemplates the endpoints 14 being configured to wirelessly communicate and/or broadcast, optionally asynchronously, when desiring to transmit their associated data, readings, measurements or other information associated with the use thereof.
- the data being broadcasted from the endpoints 14 may be received at multiple gateways 20 depending on the number of gateways 20 within the vicinity, beamforming parameters and other variables due to the endpoints 14 optionally communicating upstream in a non-mesh or connectionless manner.
- the endpoints 14 may be battery-operated and employ a long range, low power wireless protocol to facilitate communication of the desired data.
- the endpoints 14 may send small data packets to any number of gateways 20 within a several-kilometer range thereof, optionally being limited to 1,000 bytes of data per day or less than 5,000 bits per second.
- the gateways 20 may then use more traditional communications, such as wired Internet connections, to forward the messages to a network-server 22 which validates the packets and forwards as appropriate.
- the endpoints 14 may optionally employ a physical layer that uses chirp spread spectrum (CSS) modulation, such as with a spreading factor (SF) of 7 to 12, to deliver orthogonal transmissions at different data rates.
- the CSS may employ wideband linear frequency modulated chirp pulses to encode information within a sinusoidal signal whose frequency increases or decreases over time, optionally throughout an entire allocated bandwidth, so as to broadcast its data in a manner resistant to channel noise, resistant to multi-path fading when operating at very low power due to a broad band of spectrum use, and with reliance on the linear nature of the chirp pulse to avoid having to add pseudo-random elements to the signal for purposes of distinguishing it from noise on the channel.
- the endpoints 14 may optionally be deployed and begin transmitting data without prior association or synchronization with the gateways 20 , i.e., the endpoints 14 may be pre-configured or otherwise operational when deployed so as to avoid having to expend battery energy to synchronize with the gateways 20 and/or to otherwise exchange signaling with the gateways 20 prior to having data desired for transmission thereto.
- the number of gateways 20 receiving transmissions from any one of the endpoints 14 may be based on the transmission range of the endpoint 14 and the number of gateways 20 positioned within that transmission range by a corresponding LPWAN operator.
- each of the gateways 20 may optionally be configured to forward the corresponding signaling to the network servers 22 whereupon the network servers 22 then verify, authenticate or otherwise process the associated data such that a single packet or single transmission/message is thereafter made available, e.g., such that a single packet or transmission is provided to downstream devices for further processing.
- the ability to push or delay the associated signal processing to the networks servers 22 may be beneficial from an architectural and deployment standpoint as it may permit the corresponding operator to centralize the attendant processing to hubs or data centers, which may ameliorate buildout costs for the corresponding LPWAN 16 , 18 .
- the backend-influenced processing of the signaling at the network servers 22 may also be beneficial in enabling the endpoints 14 to conserve battery energy by not having to continuously or repeatedly synchronize with one or more of the gateways 20 and by alleviating any reliance on the endpoints 14 to facilitate forwarding or processing data for other endpoints.
- the endpoints 14 may optionally operate according to a messaging strategy whereby communications may be essentially asynchronous in so far as the endpoints 14 limiting communications to intervals when having data to transmit.
- the endpoints 14 may conserve battery energy consumed in facilitating communications by waiting for an interval during which data is ready for transmission before consuming battery energy necessary for communication.
- a radio interface or other communication mechanisms of the endpoints 14 maybe shutdown or turned off during the non-data intervals such that the endpoints 14 are unable to receive downstream transmission or otherwise wirelessly communicate during the corresponding intervals.
- the radio interface may be woken up to consume battery energy when data is ready for upstream transmission, and optionally for a limited period of time thereafter, the radio interface may be kept temporarily operational to facilitate receipt of downstream communications.
- the LPWAL 12 , gateways 20 , network server 22 or other network construct may utilize the shortened interval after upstream transmission to facilitate sending acknowledgments and/or other information to the endpoints 14 , such as to facilitate transmitting updates or other configuration information thereto.
- the broadcast nature of the endpoints 14 may be further advantageous in limiting battery consumption and memory storage as the endpoints 14 may broadcast the desired data without having to undergo synchronization or other exchange with the gateways 20 before transmission and without having to look up or otherwise store an address or communication requirement for an intended recipient.
- One non-limiting aspect of the present invention contemplates the abstraction layer 12 being an LPWAN abstraction layer (LPWAL) to facilitate normalizing data broadcasted or otherwise transmitted from the endpoints 14 communicating to an LPWAN 16 , 18 prior to the data being communicated to applications 26 intending to make use thereof.
- the applications 26 may connect with the LPWAL 12 through the Internet or other suitable communication medium to facilitate processing endpoint originating data for any number of reasons, including those particularly suitable to the Internet of things (IoT) where many applications may intend to make use of a vast amount of data collected by battery-operated endpoints of the type suitable for use with LPWANs 16 , 18 and/or other network architectures.
- IoT Internet of things
- the LPWAL 12 is believed to be particularly beneficial in the illustrated configuration to facilitate normalizing data across multiple LPWANs 16 , 18 , which may be serviced by multiple LPWAN operators, so as to facilitate normalizing data when collected and/or communicated according to disparate protocols, languages, formats, syntaxes, structures, etc. of the endpoints 14 and/or the LPWANs 16 , 18 or LPWAN operators, and thereby, enable commonization of the data prior to being interfaced with the applications 26 intending to make use thereof.
- the LPWAL 12 can alleviate the processing constraints on the individual applications 26 by acting as a virtualization layer having a unified interface sufficient to normalize the data from thousands and thousands of endpoints 14 prior to the data reaching the applications 26 .
- the LPWAL 12 may sit above the LPWANs 16 , 18 , which themselves may be employing differing LPWAN technologies, and may be owned by one or more LPWAN operators.
- the LPWAL 12 may provide a unified interface across LPWAN technologies and/or operators sufficient to provide a single interface to the application 26 .
- the LPWAL 12 enables a vendor to deploy LPWAN endpoints 14 across any set of geographic markets without knowing which subset of LPWANs 16 , 18 is used and without knowing the endpoint LPWAN technology being employed by a particular LPWAN operator.
- the LPWAL 12 can provide a common Internet interface (across LPWAN technology and operator) to which the application 26 can connect for communication with the endpoints 14 .
- the LPWAL 12 may provide the following functionality: physical device identifier to application vendor ID mapping; translation of per device and LPWAN operator sensor data encoding to human readable, LPWAN operator and application vendor independent sensor data encoding; creation of virtual endpoint data from physical endpoint data per application ID; interface for vendor data collection (e.g., websocket); collect accounting information about the volume of data traffic per LPWAN; interface for application vendor provisioning and management of devices, hiding which LPWANs are involved; and/or data forking for archival purposes
- An application 26 or a vendor of an application 26 may operate independently of the endpoints 14 , i.e., the application 26 may be un-associated with an endpoint 14 or beyond the control thereof.
- the present invention predominately describes for exemplary purposes that a vendor of the application 26 may be responsible for identifying the endpoints 14 intended to be operable therewith.
- the application vendor derived knowledge of the endpoints 14 may be provided to the LPWAL 12 to enable virtually any application vendor to itself deploy any type of endpoint 14 across any number of disparately operating LPWANs 16 , 18 and/or utilize virtually any type of endpoint 14 already deployed and/or deployed by other vendors or operators across any number of disparately operating LPWANs 16 , 18 .
- the endpoint vendors may deploy the endpoints 14 , e.g. sensors, by subscribing to an LPWAN operator's service.
- a business relationship can be established between the vendors and one or more of the LPWAN operators to permit access to desired services whereafter the corresponding LPWAN operator may be required to maintain the business relationship with the vendor directly, which may be beneficial in allowing the LPWAL 12 to operate independently and without having to store or manage the details or the operational requirements attendant to the various services and access that different LPWAN operators may employ to access their LPWANs 16 , 18 .
- the LPWAL 12 may be a software construct or other logically functioning element operating at a data center or other location sufficient to facilitate interacting with LPWANs 16 , 18 associated with different LPWAN operators, and is described for exemplary non-limiting purposes as being a device with a controller 28 sufficient to facilitate the operations contemplated herein.
- the controller 28 may be associated with a processor and a non-transitory computer-readable medium having a plurality of non-transitory instructions stored thereon and operable/executable with the processor to facilitate the operations and processes described herein.
- the LPWAL 12 and/or the device associated therewith may include additional hardware, elements, circuits and the like to facilitate the operations contemplated herein, including those associated with facilitating wired and/or wireless communications over virtually any type of wireless and/or wired network.
- the LPWAL 12 is shown to include one or more LPWAN interfaces 30 , a message handler 32 and one or more application interfaces 34 to illustratively demarcate functional performances contemplated in accordance with the present invention to facilitate normalizing data for virtually any endpoint 14 without requiring the utilizing application to perform data conversions or otherwise track disparate operating requirements of the data-providing endpoints 14 .
- the application interface 34 may be utilized to facilitate interfacing signaling with the application 26 , which may include enrolling endpoints 14 by generating the following information for each endpoint 14 contemplated for use: a device ID (deviceID); geolocation (expected distribution geographic market) and/or an application identifier (appID) for the application intended to be used therewith.
- the controller 28 may generate a new appID for a new vendor application 26 in the event an appID has not already been provided and/or if the application 26 is desiring to have a separate identifier, which may be beneficial to facilitate use with different sets of translation instructions as described below in more detail.
- the LPWAL 12 may provide the appID to the appropriate vendor for subsequent association with the endpoints 14 desired to be enrolled for use therewith, i.e., to facilitate associating an application 26 intended to make use of data provided from the corresponding endpoints 14 .
- the LPWAL 12 may provide the following information per enrolled endpoint 14 to the vendor via the same interface 34 in response to the enrollment request: deviceID, which may be generated in the form of a globally unique IEEE (DevEUI); and application key (appKey) as an encryption key for joining network; and the appID.
- the application 26 and/or other non-application based vendors may access LPWAL 12 to obtain data originating from the endpoints 14 via a defined websocket interface 34 using reasonable internet defined security mechanisms, such as SSL and TLS over HTTP. This access may be facilitated with one of the application interfaces 34 acting more like a data interface and/or through another interface so as to enable the LPWAL 12 to provide normalized data, such as appID, deviceID and device data.
- the vendor's application 26 can use the data interface 34 to send/receive endpoint messages to/from its endpoints 14 .
- the message format may be standard and independent of the endpoint LPWAN technology and operator.
- Historical endpoint data may be collected in the LPWAL 12 and available over the interface 34 , depending on business agreements between the LPWAN operator, LPWAL 12 and application vendor.
- the LPWAN vendor can provide the LPWAL 12 with endpoint message format information preferred by the application vendor that is to be used for message translation as described in more detail below.
- the LPWAN operator may communicate with and/or provide an interface 30 to the LPWAL 12 for sending/receiving messages (on behalf of the application vendor) to/from that application vendor's endpoints deployed in the LPWAN operator's network 16 , 18 .
- the message format may be specific to the operator's LPWAN 16 , 18 .
- the LPWAL 12 can collect message usage information associated with each application 26 and make that available to the LPWAN operators such that each operator can receive information by the application 26 for the messages traversing its LPWAN 16 , 18 .
- the corresponding information may include: total bytes sent and received by the application per accounting interval; total messages sent and received by the application per accounting interval; and/or total endpoints transmitting per LPWAN 16 , 18 .
- Messages sent by endpoints 14 may be received at the LPWAL 12 from the corresponding LPWAN operator in a LPWAN-specific format. These messages may then be translated with the message handler 32 in accordance with the present invention into a common message format using the translation information previously provided by the application vendor.
- the following provides example output of the LPWAL 12 :
- the foregoing message may then be sent over the appropriate interface 34 to the vendor's application 26 whereby the appropriate interface 34 is determined by mapping endpoint identifiers in the message to the vendor application identifier, which may have been provided by the LPWAN operator when subscribing to the LPWAL 12 .
- Specified subsets of message data sent by endpoints 14 may be archived by the LPWAL 12 based on business agreements between the LPWAL 12 and the application vendor.
- Messages sent by the application 26 to endpoints 14 may be in a common format when received by the LPWAL 12 whereupon they may be translated into the appropriate LPWAN format before being forwarded to the LPWAN operator for transmission to the endpoint 14 .
- Message and byte count information per application vendor and LPWAN operator may be collected and reported by the LPWAL 12 .
- the present invention contemplates the performing or otherwise facilitating performance of the following functions: a vendor registering an application 26 with the LPWAL 12 ; the LPWAL 12 generating a new appID, if new vendor application; a vendor registering the endpoints 14 with the LPWAL 12 ; the LPWAL 12 associating the endpoints 14 to assigned appID; the LPWAL 12 enrolling the endpoints 14 in participating LPWANs 16 , 18 ; the LPWAL 12 associating the LPWAN 16 , 18 assigned AppEUIs with assigned appID; and/or the vendor deploying the endpoints 14 in the LPWAN operators' networks 16 , 18 .
- An endpoint activation may commence with a vendor creating an account (one time) on the LPWAL 12 , which may include agreeing to license terms.
- An application 26 may thereafter be registered under that account with the LPWAL 12 by the vendor providing an IEEE application global identifier (appEUI) and an application secret key (appKey).
- the LPWAL 12 may thereafter create an application ID (appID) which can be provided back to the vendor.
- the appID can be used as an authentication token when the vendor's application 26 communicates with the LPWAL 12 .
- the present invention notes the use of over-the-air activation (OTAA) and activation by personalization (APB) particularly suitable.
- OTAA over-the-air activation
- APIB personalization
- the vendor can register the endpoints 14 with the LPWAL for later OTAA by providing each endpoint's device global identifier (deviceID) over a web interface.
- the web interface URL can contains the vendor's appID to identify which vendor application 26 will be associated with the endpoints 14 .
- the application vendor can provide information required by the LPWAL 12 to translate messages between the endpoint-specific format and the common format used between the LPWAL 12 and the application 26 .
- the LPWAL 12 can provide the common message format in the JaysScript Object Notation (JSON), such as in accordance with, the JSON Data Interchange Syntax specification, ECMA-404, 2nd Edition, December 2017, the disclosure of which is hereby incorporated by reference in its entirety herein.
- JSON JaysScript Object Notation
- the application vendor may be requested to populate the JSON message format to encode/decode that deviceID-specific data.
- the application vendor can provide a web service that the LPWAL 12 can be used to download that JSON encoding information when endpoints 14 are registered. It may be the responsibility of the application vendor to maintain that JSON information, i.e., to ensure the LPWAL 12 has sufficient instructions for automatically normalizing data when received from the endpoints 14 .
- An endpoint deployment may commence with the LPWAL 12 providing an interface identifying participating LPWAN operator that the vendor can then use to deploy its endpoints 14 by contracting for service with a corresponding LPWAN operator participating in the LPWAL 12 .
- each endpoint 14 may be configured by the vendor to include a deviceID, the appKey and the appID.
- the LPWAL 12 can thereafter maintain a relationship between the appKey of the LPWAN operator and the appID and appKey.
- the endpoints 14 may thereafter be activated by going through the over-the-air activation process, defined by the specific LPWAN specification (e.g., LoRa Alliance, 3GPP), with the LPWAN operator's equipment.
- the specific LPWAN specification e.g., LoRa Alliance, 3GPP
- Messages sent by an endpoint 14 with a given appID may be routed through a corresponding one of the LPWANs 16 , 18 for receipt at the LPWAL 12 .
- the LPWAL 12 can then translate the message into a common format, replace the appID with the vendor assigned appEUI, and forward the common format message to the vendor application interface corresponding to that appEUI.
- a vendor's application can send a common format message over an LPWAL interface using an appID to a particular endpoint identified by a deviceID.
- the LPWAL 12 infers the appropriate appKey from the appID, translates the message in a manner appropriate to the LPWAN technology and forwards the message to the appropriate LPWAN operator interface 34 for the deviceID.
- the LPWAL 12 caches the appKey correlated with an endpoint transmission for receive window timeframes.
- the appID correlates the deviceID to the cached appKey for receive transmissions during the prescribed receive window to ensure data is routed correctly.
- the LPWAL 12 may maintain information indicating the number of bytes and messages sent and received per accounting interval, such as according to appKey and LPWAN operator.
- the LPWAL 12 can send per accounting interval data to participating application vendors and LPWAN operators. LPWAN operators may receive the data by application vendor and appKey, and the application vendors may receive the data by LPWAN operator and appKey, which may optionally also be available through the application vendor's LPWAL account.
- FIG. 2 illustrates a flowchart 40 for a method of normalizing data in accordance with one non-limiting aspect of the present invention.
- the method is predominately described with respect to the exemplary description provided above in regards to normalizing data originating from a plurality of endpoints 14 in communication with one or more LPWANs 16 , 18 .
- One aspect of the method relates to performing data normalization at a virtualization layer or LPWAL 12 located upstream from the endpoints 14 so as to facilitate data normalizing without adding processing or energy consumption constraints on the endpoints 14 , which may be helpful for endpoints 14 operating solely on energy provided from a battery and/or those essentially, asynchronously communicating using wireless, broadcast or connectionless communications with LPWANs 16 , 18 .
- the method may be additionally beneficial in normalizing data when collected and/or communicated according to disparate protocols, languages, formats, syntaxes, structures, etc., such as to enable commonization of the data prior to being interfaced with applications or other entities intending to make use thereof.
- An application enrollment request process may commence with a vendor 26 contacting the LPWAL 12 through one of the application interfaces 34 , such as with communication of an enrollment request message 42 .
- the enrollment request message 42 may include a globally, unique appEUI for a particular application 26 the vendor desires for enrollment, and optionally, an appKey to be used in facilitating encryption of data to be used with the application 26 being enrolled.
- the enrollment process may occur after the vendor has established a business relationship with one or more LPWAN operators, e.g., after the vendor has agreed to service terms for data to be communication over one or more of the LPWANs 16 , 18 .
- the nature of the business relationship(s) may be kept or maintained directly between the vendor and the associated LPWAN operators.
- the enrollment request process may optionally include the vendor providing network identifiers, addresses or other information sufficient for identifying the LPWANs 16 , 18 included as part of the business relationship or that the vendor has otherwise secured access to.
- the network identifiers may be included within the enrollment request message or otherwise transmitted to the LPWAL 12 to facilitate associating with the application 26 being enrolled, which may be beneficial in parsing or ignoring data communicated over LPWANs 16 , 18 having network identifiers of failed to match with those enrolled with the LPWAL 12 .
- An application association process may occur when the LPWAL 12 associates an application ID (appID) with the application 26 being enrolled.
- the appID may be a randomly generated series of values or non-globally unique values determined by the LPWAL 12 for cross-referencing with the appEUI and/or appKey provided in the enrollment request message 42 .
- the LPWAL 12 may include a database, a table or a lookup mechanism to facilitate relating the appID with the application being enrolled.
- the appID may be useful in facilitating identification of particular applications 26 enrolled with the LPWAL 12 differently than how those applications 26 would be identified according to the appEUI, which may be beneficial in allowing the LPWAL 12 to enhance security as the appID may be unusable or undecipherable to entities snooping or otherwise tracking data/packets being communicated through the LPWAL 12 whereas the appEUI, particularly when in compliance with a globally known identification standard, may be more readily usable or decipherable by such entities.
- the LPWAL 12 may provide the appID to the requesting vendor within an application ID message 44 , which may optionally be encrypted according to the appKey and/or include a reference or another relation to the previously provided appEUI for use by the vendor in generating its own relationship between appID and appEUI and/or appKey.
- a device enrollment process may occur when the vendor has successfully enrolled a particular application with the LPWAL 12 , i.e., after the vendor has attained an appID.
- the device enrollment process may generally correspond with the vendor notifying the LPWAL 12 of the endpoints 14 intended to be used with a particular application, such as by transmitting a device enrollment message 46 having a device ID of each endpoint 14 and the appID of the application 26 to be associated therewith.
- the vendor may facilitate execution of the device enrollment process at any time to notify the LPWAL 12 of endpoints 14 being newly added for use with the application 26 , to facilitate dynamic or moving endpoints 14 or to otherwise apprise the LPWAL 12 of endpoint association updates.
- the deviceIDs may optionally be updated with each transmission of the device enrollment message 46 to facilitate adding and/or removing devices 14 authorized for use with the associated application/appID, which may be beneficial in preventing normalization of data communicated from endpoints 14 no longer listed within the device enrollment message 46 or otherwise noted within the device enrollment message 46 as lacking rights or entitlements for use with the application 26 .
- a translation enablement process may occur with the vendor providing translation information to the LPWAL 12 .
- the translation information may be transmitted in one or more translation messages 50 and include instructions, scripts, executable code, JavaScript and/or other information necessary to facilitate normalizing disparate data originating from the endpoints to an agreed-upon or standardized architecture, format, syntax, protocol, structure, language or other construct.
- the message handler 32 of the LPWAL 12 may be the functional element utilized for facilitating normalizing, translating, mapping or otherwise encoding/converting data being received from the endpoints 14 to a singular format or form such that the application 26 making use thereof need not compensate for the disparate nature of the data as originating from the endpoints 14 , i.e., the application need only be capable of processing the data according to one type of messaging structure.
- One non-limiting aspect of the present invention contemplates the message handler 32 normalizing the data and/or generating the messages used to carry the data to the applications in accordance with JavaScript Object Notation (JSON) format or other suitable language-independent, human readable or text-based syntax.
- JSON JavaScript Object Notation
- the ability of the LPWAL 12 to automatically normalize data from virtually any endpoint to the JSON format, or other agreed-upon structure, may be particularly beneficial in enabling the present invention to support communication of sensor data or other information without burdening the applications 26 and/or the endpoints 14 with related data conversions.
- the translation information may be provided from the vendors to the LPWAL 12 in a computer-usable format such that the message handler 32 can automatically process the translation information and generate suitable maps, relationships, conversions and other processes necessary to automatically convert data being received from the endpoints 14 to the common format, i.e. JSON or the other agreed-upon format/structure.
- the translation information for a particular application 26 may be identified with the appID associated therewith such that the message handler 32 knows to automatically use the related translation information to facilitate normalization of data included with the messages having related appID therein.
- the translation information may include multiple sets of translation information for a particular appID to address disparate characteristics of the endpoints 14 generating the data, e.g., a set of translation information may be required for each different type of endpoint 14 or type of communication requirement of the endpoint 14 or the associated LPWAN 16 , 18 .
- the deviceID may optionally be used in this regard to facilitate differentiating sets or subsets of the translation information to be used for a particular endpoint with respect to a particular appID with respect to a particular appID, e.g., the appID can be used to identify the appropriate translation information and the deviceID can be used thereafter to determine one or more portions of the translation information to be used.
- One non-limiting aspect of the present invention contemplates relying on the vendors to provide the translation information in order to avoid the LPWAL 12 having to independently determine the translation information on a per endpoint basis. Requiring the vendors to instead generate the translation information, and optionally provide updates or other changes are thereto to the LPWAL 12 , may be beneficial from a commercial implementation standpoint as requiring an entity charged with operating LPWAL 12 to individually map endpoint characteristics for thousands or millions of endpoints may be commercially impracticable.
- Requiring the vendors to generate the translation information may also be beneficial in motivating or ensuring the entity mainly benefiting from the data conversions, or at least the entity capable of passing through the cost for generating the translation information to an end customer, can be held responsible for keeping the translation information relevant/accurate as endpoint operating characteristics change over time and/or as authorized endpoints 14 are added and removed, which may be important in maintaining customer satisfaction and quality of service as the use of IoT and non-IoT endpoints 14 proliferate.
- An endpoint provisioning process may correspond with the vendor providing the deviceID, appID and appKey to each of the endpoints 14 intended to be used with the application being enrolled.
- the endpoint provisioning process may include transmitting the corresponding information to the endpoint 14 within an endpoint provisioning message 52 , such as when the endpoint 14 is activated and/or during one of the brief intervals after an endpoint 14 transmits upstream data during which the endpoint 14 is capable of temporarily receiving downstream data, and/or through technician servicing or other configurating of the endpoint 14 prior to deployment, such as during manufacturing or installation.
- the endpoints 14 may process the deviceID, appID and appKey to facilitate identifying itself (deviceID) within messages used to transmit data along with the application intended for use therewith (appID) and any attendant encryption (appKey).
- the endpoints 14 may optionally be provisioned independently of signaling communicated from or through the LPWAL 12 to avoid corresponding processing and implementation demands on the LPWAL 12 in having to track endpoints individually or to otherwise be aware of endpoint presence/operation.
- the LPWAL 12 may be considered as being reactive to messages received from the endpoints 14 as opposed to being actively involved in configuring or synchronizing endpoints 14 for generating the messages/data being communicated therefrom.
- a normalization process may commence with the endpoint 14 issuing an endpoint message 54 to one or more of the LPWANs 16 , 18 .
- the endpoint message 54 may include data generated by the endpoint (dataE), the appID of the application intended to process the dataE and/or the deviceID associated therewith.
- the dataE may be raw data sensed, tabulated, calculated, monitored or otherwise generated at the endpoint 14 and thereafter intended to be formatted according to requirements of the endpoint 14 and/or the LPWAN 16 , 18 associated therewith, i.e., according to disparate or dissimilar formats than that required by or necessary to work with the vendor/application 26 associated therewith.
- While sharing the appID with the endpoint is contemplated, one non-limiting aspect of the present invention anticipates maximizing security by keeping the appID secret from the endpoints 14 and/or the LPWANs 16 , 18 , i.e., by limiting sharing of the appID to communications between the vendor and the LPWAL 12 .
- the secrecy of the appID may be useful in keeping entities from utilizing the translation instructions provided to the LPWAL 12 to facilitate normalizing the dataE for other applications or uses.
- the LPWAL 12 may process the dataE included within the endpoint message according to the normalization instructions previously associated with the appID and/or the deviceID included within the corresponding endpoint message.
- the normalization process may thereafter continue with the LPWAL transmitting a normalized message 56 having the dataE as normalized or converted to a common data format (dataC), e.g., a JSON format, and the appEUI associated with the appID included in the endpoint message 54 .
- the normalization message 56 may include the dataE being normalized to the dataC according to the translation information previously associated with the corresponding appID and/or device ID.
- the appID may be solely relied upon in situations where the application vendor intends to have the dataE uniformly translated according to a singular set of translation instructions associated with the appID, i.e., when one set of translation instructions associated with the appID is sufficient to facilitate the desired data normalization.
- the deviceID may be utilized in cooperation with the appID to facilitate selecting subsets of translation information associated with a particular appID.
- the LPWAL 12 may select the subset of translation instructions associated with a particular appID based on the LPWAN 16 , 18 of the corresponding endpoint 14 , e.g., a range or grouping of deviceIDs may be associated with translation instructions differentiated within the subsets according to LPWAN 16 , 18 .
- the LPWAL 12 may additionally and/or alternatively select the subset of translation instructions associated with a particular appID based on a per-endpoint basis, e.g., individual deviceIDs may be associated with translation instructions differentiated within the subsets according to deviceID.
- the translation information utilized by the LPWAL may be determined on a message-by-message packet-by-packet basis such that the message handler 32 individually assesses each arriving endpoint message to determine the appropriate translation information to be used in facilitating converting its formatting to JSON or another predefined format operable with the associated vendor/application 26 , which may optionally include converting the incoming messaging to differing formats in the event the application 26 is configured to process multiple data formats.
- the LPWAL 12 may utilize different translation instructions to normalize data intended for the same application, i.e., different translation instructions to convert data to a common format, if communicated from different endpoints 14 when the raw data within the corresponding endpoint messages 54 is formatted differently or otherwise subjected to disparate processing techniques, such as when the endpoints 14 process raw data identically or similarly but format or communicate the data differently due to requirements of the LPWAN 16 , 18 associated therewith and/or when the endpoints 14 are connected to the same LPWAN 16 , 18 , i.e., subjected to the same LPWAN communication requirements, but disparately or dissimilarly encode or otherwise prepare the raw data for transmission.
- the raw data may be transmitted to the application either in conjunction with the converted data or instead of the converted data.
- An endpoint communication process may occur with the vendor and/or application 26 transmitting downstream message 58 in response to receipt of the normalization message 56 , such as to facilitate transmitting an acknowledgment to the corresponding endpoint 14 .
- the downstream message 58 may be timed relative to a brief interval that the endpoint 14 may be kept awake to receive downstream messages following transmission of the endpoint message 54 .
- the LPWAL 12 may translate data (messageC) included in the downstream message, which may be formatted identically to the dataC, to data (messageE) suitable for use with the endpoint, which may be formatted identically to the dataE.
- the LPWAL 12 may facilitate the downstream transmission normalization according to the translation information previously utilized in facilitating authorization of the dataE included in the endpoint message 54 .
- the LPWAL 12 may thereafter transmit an endpoint normalization message 60 to the corresponding endpoint 14 .
- the LPWAL 12 may generate reports or other information regarding statistical analysis of translations and other messaging passing therethrough, such as to apprise vendors in session or LPWAN operators of usage.
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 15/844,087, filed Dec. 15, 2017, which application claims the benefit of U.S. provisional application No. 62/434,610 filed Dec. 15, 2016, the disclosure of which is incorporated in its entirety by reference herein.
- The present invention relates to normalization of data originating from endpoints within low power wide area networks (LPWANs), such as but not necessary limited to normalizing data when collected and/or communicated according to disparate protocols, languages, formats, syntaxes, structures, etc. of the endpoints and/or the LPWANs so as to enable commonization of the data prior to being interfaced with applications or other entities intending to make use thereof.
- The Internet of Things (IoT) is a growing industry comprised of a massive number of devices that connect to each other to benefit our lives. Examples of these include thermostats, security cameras, voice-commanded personal digital assistants (PDAs) and wearable electronics that may be configured to facilitate any number of operations, such as to enable refrigerators to talk with the Internet to order milk and wearable electronics to tell you when to step more to meet your daily exercise goals. A new area of IoT involves the use of sensors designed for wirelessly transmitting information periodically over long distances for years on a single battery. The infrastructure to support these connected devices is commonly referred to as a low power wide area network (LPWAN). LPWANs may be designed to cover large geographical areas in a manner intended to minimize the amount of power required for sensors to interact with the network. The nature of a LPWAN network potentially allows IoT devices to run for years on small batteries, occasionally sending out small packets of data, waiting for a short time for response messages, and then closing the connection until more data needs to be sent. Devices can also be set up so that they are always listening for messages from their applications, though this requires more power and may be more appropriate for devices that are, plugged in to a wall socket or otherwise operational independently of batteries.
- IoT devices can utilize the LPWAN networks to send small data packets to any number of gateways that may be in a several-kilometer range of a sensor, such as in accordance with the LoRaWAN or other suitable wireless protocol. The gateways can then use more traditional communications, such as wired and/or wireless Internet connections, to forward the messages to a network-server that then validates the packets and forwards the application payload to an application-server or other back end processing element. One non-limiting aspect of the present invention contemplates normalizing data being communicated over LPWANs or other suitable networks so as to minimize backend or application processing of the data when originating from IoT devices, sensors, endpoints, hardware or other components having different processes, protocols, architectures, properties, etc. for structuring, formatting and communicating the data.
-
FIG. 1 illustrates a system for normalizing data communications in accordance with one non-limiting aspect of the present invention. -
FIG. 2 illustrates a flowchart for a method of normalizing data in accordance with one non-limiting aspect of the present invention. - As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.
-
FIG. 1 illustrates asystem 10 for normalizing data communications in accordance with one non-limiting aspect of the present invention. The contemplated normalization may be facilitated with anabstraction layer 12 positioned to facilitate translating, mapping, converting, encoding and/or otherwise manipulating data traversing therethrough for purposes of commonizing the data to an agreed-upon or standardized architecture, format, syntax, protocol, structure, language or other construct. The present invention is predominately described for exemplary purposes with respect to normalizing data when originating from a plurality ofendpoints 14 in communication with a plurality of low power wide area networks (LPWANs) 16, 18, such as to address the above-identified possibility of network operators being tasked with supporting communication of sensor data or other information in the future when the proliferation of thedata originating endpoints 14 is expected to reach levels and/or types of traffic flow believed to be best supported withLPWANs endpoints 14, including normalization of data being transmitted to theendpoints 14. - The LPWANs 16, 18 are generically illustrated with the
endpoints 14 communicating with one ormore gateways 20 and thegateways 20 in turn communicating with one ormore network servers 22, such as to facilitate upstream communications from theendpoints 14 to thenetwork servers 22 and/or downstream communications from thenetwork servers 22 to theendpoints 14. Theendpoints 14,gateways 20 andservers 22 may optionally be configured in the illustrated manner such that theendpoints 14 wirelessly communicate with thegateways 20 and thegateways 20 in turn wiredly communicate with thenetwork servers 22. One non-limiting aspect of the present invention contemplates theendpoints 14 being configured to wirelessly communicate and/or broadcast, optionally asynchronously, when desiring to transmit their associated data, readings, measurements or other information associated with the use thereof. The data being broadcasted from theendpoints 14 may be received atmultiple gateways 20 depending on the number ofgateways 20 within the vicinity, beamforming parameters and other variables due to theendpoints 14 optionally communicating upstream in a non-mesh or connectionless manner. Theendpoints 14 may be battery-operated and employ a long range, low power wireless protocol to facilitate communication of the desired data. Theendpoints 14, for example, may send small data packets to any number ofgateways 20 within a several-kilometer range thereof, optionally being limited to 1,000 bytes of data per day or less than 5,000 bits per second. Thegateways 20 may then use more traditional communications, such as wired Internet connections, to forward the messages to a network-server 22 which validates the packets and forwards as appropriate. - The
endpoints 14 may optionally employ a physical layer that uses chirp spread spectrum (CSS) modulation, such as with a spreading factor (SF) of 7 to 12, to deliver orthogonal transmissions at different data rates. The CSS may employ wideband linear frequency modulated chirp pulses to encode information within a sinusoidal signal whose frequency increases or decreases over time, optionally throughout an entire allocated bandwidth, so as to broadcast its data in a manner resistant to channel noise, resistant to multi-path fading when operating at very low power due to a broad band of spectrum use, and with reliance on the linear nature of the chirp pulse to avoid having to add pseudo-random elements to the signal for purposes of distinguishing it from noise on the channel. Theendpoints 14 may optionally be deployed and begin transmitting data without prior association or synchronization with thegateways 20, i.e., theendpoints 14 may be pre-configured or otherwise operational when deployed so as to avoid having to expend battery energy to synchronize with thegateways 20 and/or to otherwise exchange signaling with thegateways 20 prior to having data desired for transmission thereto. The number ofgateways 20 receiving transmissions from any one of theendpoints 14 may be based on the transmission range of theendpoint 14 and the number ofgateways 20 positioned within that transmission range by a corresponding LPWAN operator. - The spatial diversity created by
multiple gateways 20 receiving a single transmission from one or more of theendpoints 14 may be beneficial in facilitating error correction and other signal processing techniques. Whenmultiple gateways 20 receive the same transmission, each of thegateways 20 may optionally be configured to forward the corresponding signaling to thenetwork servers 22 whereupon thenetwork servers 22 then verify, authenticate or otherwise process the associated data such that a single packet or single transmission/message is thereafter made available, e.g., such that a single packet or transmission is provided to downstream devices for further processing. The ability to push or delay the associated signal processing to thenetworks servers 22 may be beneficial from an architectural and deployment standpoint as it may permit the corresponding operator to centralize the attendant processing to hubs or data centers, which may ameliorate buildout costs for thecorresponding LPWAN network servers 22 may also be beneficial in enabling theendpoints 14 to conserve battery energy by not having to continuously or repeatedly synchronize with one or more of thegateways 20 and by alleviating any reliance on theendpoints 14 to facilitate forwarding or processing data for other endpoints. - The
endpoints 14 may optionally operate according to a messaging strategy whereby communications may be essentially asynchronous in so far as theendpoints 14 limiting communications to intervals when having data to transmit. Theendpoints 14 may conserve battery energy consumed in facilitating communications by waiting for an interval during which data is ready for transmission before consuming battery energy necessary for communication. A radio interface or other communication mechanisms of theendpoints 14 maybe shutdown or turned off during the non-data intervals such that theendpoints 14 are unable to receive downstream transmission or otherwise wirelessly communicate during the corresponding intervals. The radio interface may be woken up to consume battery energy when data is ready for upstream transmission, and optionally for a limited period of time thereafter, the radio interface may be kept temporarily operational to facilitate receipt of downstream communications. TheLPWAL 12,gateways 20,network server 22 or other network construct may utilize the shortened interval after upstream transmission to facilitate sending acknowledgments and/or other information to theendpoints 14, such as to facilitate transmitting updates or other configuration information thereto. The broadcast nature of theendpoints 14 may be further advantageous in limiting battery consumption and memory storage as theendpoints 14 may broadcast the desired data without having to undergo synchronization or other exchange with thegateways 20 before transmission and without having to look up or otherwise store an address or communication requirement for an intended recipient. - One non-limiting aspect of the present invention contemplates the
abstraction layer 12 being an LPWAN abstraction layer (LPWAL) to facilitate normalizing data broadcasted or otherwise transmitted from theendpoints 14 communicating to anLPWAN applications 26 intending to make use thereof. Theapplications 26 may connect with theLPWAL 12 through the Internet or other suitable communication medium to facilitate processing endpoint originating data for any number of reasons, including those particularly suitable to the Internet of things (IoT) where many applications may intend to make use of a vast amount of data collected by battery-operated endpoints of the type suitable for use withLPWANs LPWAL 12 is believed to be particularly beneficial in the illustrated configuration to facilitate normalizing data acrossmultiple LPWANs endpoints 14 and/or theLPWANs applications 26 intending to make use thereof. - The future of IoT and other architectures relying on vast amounts of data to be collected from
endpoints 14 across different networks and/or different network operators may present a problem for deployedapplications 26 andnew applications 26 to make use of the data due to the disparate processes, protocols, architectures, properties, etc. being independently used by theendpoints 14 for structuring, formatting and communicating the data. Requiring theapplications 26 to not only identify each of the disparate characteristics of the endpoints and/or theLPWANs disparate endpoints 14. When anapplication 26 desires temperature readings, for example, thecorresponding endpoints 14 may use different protocols, formats, etc. to facilitate communication of the temperature readings or the raw data forming the temperature readings, which in the absence of theLPWAL 12, would require theapplication 26 to include procedures for addressing each manner that the raw temperature values are being communicated. It could become untenable for asingle application 26 to handle thousands and thousands of sensors when disparately generating such raw temperature values. TheLPWAL 12 can alleviate the processing constraints on theindividual applications 26 by acting as a virtualization layer having a unified interface sufficient to normalize the data from thousands and thousands ofendpoints 14 prior to the data reaching theapplications 26. - The LPWAL 12 may sit above the LPWANs 16, 18, which themselves may be employing differing LPWAN technologies, and may be owned by one or more LPWAN operators. The LPWAL 12 may provide a unified interface across LPWAN technologies and/or operators sufficient to provide a single interface to the
application 26. The LPWAL 12 enables a vendor to deploy LPWANendpoints 14 across any set of geographic markets without knowing which subset of LPWANs 16, 18 is used and without knowing the endpoint LPWAN technology being employed by a particular LPWAN operator. The LPWAL 12 can provide a common Internet interface (across LPWAN technology and operator) to which theapplication 26 can connect for communication with theendpoints 14. TheLPWAL 12 may provide the following functionality: physical device identifier to application vendor ID mapping; translation of per device and LPWAN operator sensor data encoding to human readable, LPWAN operator and application vendor independent sensor data encoding; creation of virtual endpoint data from physical endpoint data per application ID; interface for vendor data collection (e.g., websocket); collect accounting information about the volume of data traffic per LPWAN; interface for application vendor provisioning and management of devices, hiding which LPWANs are involved; and/or data forking for archival purposes - An
application 26 or a vendor of anapplication 26 may operate independently of theendpoints 14, i.e., theapplication 26 may be un-associated with anendpoint 14 or beyond the control thereof. The present invention, however, predominately describes for exemplary purposes that a vendor of theapplication 26 may be responsible for identifying theendpoints 14 intended to be operable therewith. The application vendor derived knowledge of theendpoints 14 may be provided to the LPWAL 12 to enable virtually any application vendor to itself deploy any type ofendpoint 14 across any number of disparately operating LPWANs 16, 18 and/or utilize virtually any type ofendpoint 14 already deployed and/or deployed by other vendors or operators across any number of disparately operating LPWANs 16, 18. The endpoint vendors, which may in some instances be the same as the application vendors, may deploy theendpoints 14, e.g. sensors, by subscribing to an LPWAN operator's service. A business relationship can be established between the vendors and one or more of the LPWAN operators to permit access to desired services whereafter the corresponding LPWAN operator may be required to maintain the business relationship with the vendor directly, which may be beneficial in allowing theLPWAL 12 to operate independently and without having to store or manage the details or the operational requirements attendant to the various services and access that different LPWAN operators may employ to access theirLPWANs - The
LPWAL 12 may be a software construct or other logically functioning element operating at a data center or other location sufficient to facilitate interacting withLPWANs controller 28 sufficient to facilitate the operations contemplated herein. Thecontroller 28 may be associated with a processor and a non-transitory computer-readable medium having a plurality of non-transitory instructions stored thereon and operable/executable with the processor to facilitate the operations and processes described herein. TheLPWAL 12 and/or the device associated therewith may include additional hardware, elements, circuits and the like to facilitate the operations contemplated herein, including those associated with facilitating wired and/or wireless communications over virtually any type of wireless and/or wired network. TheLPWAL 12 is shown to include one or more LPWAN interfaces 30, amessage handler 32 and one or more application interfaces 34 to illustratively demarcate functional performances contemplated in accordance with the present invention to facilitate normalizing data for virtually anyendpoint 14 without requiring the utilizing application to perform data conversions or otherwise track disparate operating requirements of the data-providingendpoints 14. - The
application interface 34 may be utilized to facilitate interfacing signaling with theapplication 26, which may include enrollingendpoints 14 by generating the following information for eachendpoint 14 contemplated for use: a device ID (deviceID); geolocation (expected distribution geographic market) and/or an application identifier (appID) for the application intended to be used therewith. Thecontroller 28 may generate a new appID for anew vendor application 26 in the event an appID has not already been provided and/or if theapplication 26 is desiring to have a separate identifier, which may be beneficial to facilitate use with different sets of translation instructions as described below in more detail. TheLPWAL 12 may provide the appID to the appropriate vendor for subsequent association with theendpoints 14 desired to be enrolled for use therewith, i.e., to facilitate associating anapplication 26 intended to make use of data provided from the correspondingendpoints 14. TheLPWAL 12 may provide the following information per enrolledendpoint 14 to the vendor via thesame interface 34 in response to the enrollment request: deviceID, which may be generated in the form of a globally unique IEEE (DevEUI); and application key (appKey) as an encryption key for joining network; and the appID. - The
application 26 and/or other non-application based vendors may access LPWAL 12 to obtain data originating from theendpoints 14 via a definedwebsocket interface 34 using reasonable internet defined security mechanisms, such as SSL and TLS over HTTP. This access may be facilitated with one of the application interfaces 34 acting more like a data interface and/or through another interface so as to enable the LPWAL 12 to provide normalized data, such as appID, deviceID and device data. The vendor'sapplication 26 can use thedata interface 34 to send/receive endpoint messages to/from itsendpoints 14. The message format may be standard and independent of the endpoint LPWAN technology and operator. Historical endpoint data may be collected in theLPWAL 12 and available over theinterface 34, depending on business agreements between the LPWAN operator,LPWAL 12 and application vendor. The LPWAN vendor can provide the LPWAL 12 with endpoint message format information preferred by the application vendor that is to be used for message translation as described in more detail below. - The LPWAN operator may communicate with and/or provide an
interface 30 to the LPWAL 12 for sending/receiving messages (on behalf of the application vendor) to/from that application vendor's endpoints deployed in the LPWAN operator'snetwork LPWAN LPWAL 12 can collect message usage information associated with eachapplication 26 and make that available to the LPWAN operators such that each operator can receive information by theapplication 26 for the messages traversing itsLPWAN LPWAN - Messages sent by
endpoints 14 may be received at theLPWAL 12 from the corresponding LPWAN operator in a LPWAN-specific format. These messages may then be translated with themessage handler 32 in accordance with the present invention into a common message format using the translation information previously provided by the application vendor. The following provides example output of the LPWAL 12: -
{ “DevEUI”: “008000000000C116”, “DevName”: “ExampleAppVendor”, “AppType”: 3, “SeqNum”: 0, “TimeStamp”: 1476811505267, “SensorData”: { “PA”: “86.30”, “TCB”: “18.14”, “HUMB”: “24.3”, “PLV1”: “0.00”, “PLV2”: “0.00”, “PLV3”: “6.43”, “ANE”: “3.20”, “WV”: “2” } - The foregoing message may then be sent over the
appropriate interface 34 to the vendor'sapplication 26 whereby theappropriate interface 34 is determined by mapping endpoint identifiers in the message to the vendor application identifier, which may have been provided by the LPWAN operator when subscribing to theLPWAL 12. Specified subsets of message data sent byendpoints 14 may be archived by theLPWAL 12 based on business agreements between theLPWAL 12 and the application vendor. Messages sent by theapplication 26 toendpoints 14 may be in a common format when received by theLPWAL 12 whereupon they may be translated into the appropriate LPWAN format before being forwarded to the LPWAN operator for transmission to theendpoint 14. Message and byte count information per application vendor and LPWAN operator may be collected and reported by theLPWAL 12. In this manner, the present invention contemplates the performing or otherwise facilitating performance of the following functions: a vendor registering anapplication 26 with theLPWAL 12; theLPWAL 12 generating a new appID, if new vendor application; a vendor registering theendpoints 14 with theLPWAL 12; theLPWAL 12 associating theendpoints 14 to assigned appID; theLPWAL 12 enrolling theendpoints 14 in participatingLPWANs LPWAL 12 associating theLPWAN endpoints 14 in the LPWAN operators'networks - An endpoint activation may commence with a vendor creating an account (one time) on the
LPWAL 12, which may include agreeing to license terms. Anapplication 26 may thereafter be registered under that account with theLPWAL 12 by the vendor providing an IEEE application global identifier (appEUI) and an application secret key (appKey). TheLPWAL 12 may thereafter create an application ID (appID) which can be provided back to the vendor. The appID can be used as an authentication token when the vendor'sapplication 26 communicates with theLPWAL 12. While any particular device activation may be suitable, the present invention notes the use of over-the-air activation (OTAA) and activation by personalization (APB) particularly suitable. The vendor can register theendpoints 14 with the LPWAL for later OTAA by providing each endpoint's device global identifier (deviceID) over a web interface. The web interface URL can contains the vendor's appID to identify whichvendor application 26 will be associated with theendpoints 14. The application vendor can provide information required by theLPWAL 12 to translate messages between the endpoint-specific format and the common format used between theLPWAL 12 and theapplication 26. TheLPWAL 12 can provide the common message format in the JaysScript Object Notation (JSON), such as in accordance with, the JSON Data Interchange Syntax specification, ECMA-404, 2nd Edition, December 2017, the disclosure of which is hereby incorporated by reference in its entirety herein. For each deviceID, the application vendor may be requested to populate the JSON message format to encode/decode that deviceID-specific data. The application vendor can provide a web service that the LPWAL 12 can be used to download that JSON encoding information whenendpoints 14 are registered. It may be the responsibility of the application vendor to maintain that JSON information, i.e., to ensure theLPWAL 12 has sufficient instructions for automatically normalizing data when received from theendpoints 14. - An endpoint deployment may commence with the
LPWAL 12 providing an interface identifying participating LPWAN operator that the vendor can then use to deploy itsendpoints 14 by contracting for service with a corresponding LPWAN operator participating in theLPWAL 12. Prior to deployment, eachendpoint 14 may be configured by the vendor to include a deviceID, the appKey and the appID. TheLPWAL 12 can thereafter maintain a relationship between the appKey of the LPWAN operator and the appID and appKey. Onceendpoints 14 are deployed, theendpoints 14 may thereafter be activated by going through the over-the-air activation process, defined by the specific LPWAN specification (e.g., LoRa Alliance, 3GPP), with the LPWAN operator's equipment. Messages sent by anendpoint 14 with a given appID may be routed through a corresponding one of theLPWANs LPWAL 12. TheLPWAL 12 can then translate the message into a common format, replace the appID with the vendor assigned appEUI, and forward the common format message to the vendor application interface corresponding to that appEUI. A vendor's application can send a common format message over an LPWAL interface using an appID to a particular endpoint identified by a deviceID. TheLPWAL 12 infers the appropriate appKey from the appID, translates the message in a manner appropriate to the LPWAN technology and forwards the message to the appropriateLPWAN operator interface 34 for the deviceID. TheLPWAL 12 caches the appKey correlated with an endpoint transmission for receive window timeframes. The appID correlates the deviceID to the cached appKey for receive transmissions during the prescribed receive window to ensure data is routed correctly. TheLPWAL 12 may maintain information indicating the number of bytes and messages sent and received per accounting interval, such as according to appKey and LPWAN operator. TheLPWAL 12 can send per accounting interval data to participating application vendors and LPWAN operators. LPWAN operators may receive the data by application vendor and appKey, and the application vendors may receive the data by LPWAN operator and appKey, which may optionally also be available through the application vendor's LPWAL account. -
FIG. 2 illustrates aflowchart 40 for a method of normalizing data in accordance with one non-limiting aspect of the present invention. The method is predominately described with respect to the exemplary description provided above in regards to normalizing data originating from a plurality ofendpoints 14 in communication with one or more LPWANs 16, 18. One aspect of the method relates to performing data normalization at a virtualization layer orLPWAL 12 located upstream from theendpoints 14 so as to facilitate data normalizing without adding processing or energy consumption constraints on theendpoints 14, which may be helpful forendpoints 14 operating solely on energy provided from a battery and/or those essentially, asynchronously communicating using wireless, broadcast or connectionless communications withLPWANs - An application enrollment request process may commence with a
vendor 26 contacting theLPWAL 12 through one of the application interfaces 34, such as with communication of anenrollment request message 42. Theenrollment request message 42 may include a globally, unique appEUI for aparticular application 26 the vendor desires for enrollment, and optionally, an appKey to be used in facilitating encryption of data to be used with theapplication 26 being enrolled. The enrollment process may occur after the vendor has established a business relationship with one or more LPWAN operators, e.g., after the vendor has agreed to service terms for data to be communication over one or more of theLPWANs LPWANs LPWAL 12 to facilitate associating with theapplication 26 being enrolled, which may be beneficial in parsing or ignoring data communicated overLPWANs LPWAL 12. - An application association process may occur when the
LPWAL 12 associates an application ID (appID) with theapplication 26 being enrolled. The appID may be a randomly generated series of values or non-globally unique values determined by theLPWAL 12 for cross-referencing with the appEUI and/or appKey provided in theenrollment request message 42. TheLPWAL 12 may include a database, a table or a lookup mechanism to facilitate relating the appID with the application being enrolled. The appID may be useful in facilitating identification ofparticular applications 26 enrolled with theLPWAL 12 differently than how thoseapplications 26 would be identified according to the appEUI, which may be beneficial in allowing theLPWAL 12 to enhance security as the appID may be unusable or undecipherable to entities snooping or otherwise tracking data/packets being communicated through theLPWAL 12 whereas the appEUI, particularly when in compliance with a globally known identification standard, may be more readily usable or decipherable by such entities. TheLPWAL 12 may provide the appID to the requesting vendor within anapplication ID message 44, which may optionally be encrypted according to the appKey and/or include a reference or another relation to the previously provided appEUI for use by the vendor in generating its own relationship between appID and appEUI and/or appKey. - A device enrollment process may occur when the vendor has successfully enrolled a particular application with the
LPWAL 12, i.e., after the vendor has attained an appID. The device enrollment process may generally correspond with the vendor notifying theLPWAL 12 of theendpoints 14 intended to be used with a particular application, such as by transmitting adevice enrollment message 46 having a device ID of eachendpoint 14 and the appID of theapplication 26 to be associated therewith. The vendor may facilitate execution of the device enrollment process at any time to notify the LPWAL 12 ofendpoints 14 being newly added for use with theapplication 26, to facilitate dynamic or movingendpoints 14 or to otherwise apprise the LPWAL 12 of endpoint association updates. The deviceIDs may optionally be updated with each transmission of thedevice enrollment message 46 to facilitate adding and/or removingdevices 14 authorized for use with the associated application/appID, which may be beneficial in preventing normalization of data communicated fromendpoints 14 no longer listed within thedevice enrollment message 46 or otherwise noted within thedevice enrollment message 46 as lacking rights or entitlements for use with theapplication 26. - A translation enablement process may occur with the vendor providing translation information to the
LPWAL 12. The translation information may be transmitted in one ormore translation messages 50 and include instructions, scripts, executable code, JavaScript and/or other information necessary to facilitate normalizing disparate data originating from the endpoints to an agreed-upon or standardized architecture, format, syntax, protocol, structure, language or other construct. Themessage handler 32 of theLPWAL 12 may be the functional element utilized for facilitating normalizing, translating, mapping or otherwise encoding/converting data being received from theendpoints 14 to a singular format or form such that theapplication 26 making use thereof need not compensate for the disparate nature of the data as originating from theendpoints 14, i.e., the application need only be capable of processing the data according to one type of messaging structure. One non-limiting aspect of the present invention contemplates themessage handler 32 normalizing the data and/or generating the messages used to carry the data to the applications in accordance with JavaScript Object Notation (JSON) format or other suitable language-independent, human readable or text-based syntax. - The ability of the
LPWAL 12 to automatically normalize data from virtually any endpoint to the JSON format, or other agreed-upon structure, may be particularly beneficial in enabling the present invention to support communication of sensor data or other information without burdening theapplications 26 and/or theendpoints 14 with related data conversions. The translation information may be provided from the vendors to theLPWAL 12 in a computer-usable format such that themessage handler 32 can automatically process the translation information and generate suitable maps, relationships, conversions and other processes necessary to automatically convert data being received from theendpoints 14 to the common format, i.e. JSON or the other agreed-upon format/structure. The translation information for aparticular application 26 may be identified with the appID associated therewith such that themessage handler 32 knows to automatically use the related translation information to facilitate normalization of data included with the messages having related appID therein. The translation information may include multiple sets of translation information for a particular appID to address disparate characteristics of theendpoints 14 generating the data, e.g., a set of translation information may be required for each different type ofendpoint 14 or type of communication requirement of theendpoint 14 or the associatedLPWAN - One non-limiting aspect of the present invention contemplates relying on the vendors to provide the translation information in order to avoid the LPWAL 12 having to independently determine the translation information on a per endpoint basis. Requiring the vendors to instead generate the translation information, and optionally provide updates or other changes are thereto to the
LPWAL 12, may be beneficial from a commercial implementation standpoint as requiring an entity charged with operating LPWAL 12 to individually map endpoint characteristics for thousands or millions of endpoints may be commercially impracticable. Requiring the vendors to generate the translation information may also be beneficial in motivating or ensuring the entity mainly benefiting from the data conversions, or at least the entity capable of passing through the cost for generating the translation information to an end customer, can be held responsible for keeping the translation information relevant/accurate as endpoint operating characteristics change over time and/or as authorizedendpoints 14 are added and removed, which may be important in maintaining customer satisfaction and quality of service as the use of IoT andnon-IoT endpoints 14 proliferate. - An endpoint provisioning process may correspond with the vendor providing the deviceID, appID and appKey to each of the
endpoints 14 intended to be used with the application being enrolled. The endpoint provisioning process may include transmitting the corresponding information to theendpoint 14 within anendpoint provisioning message 52, such as when theendpoint 14 is activated and/or during one of the brief intervals after anendpoint 14 transmits upstream data during which theendpoint 14 is capable of temporarily receiving downstream data, and/or through technician servicing or other configurating of theendpoint 14 prior to deployment, such as during manufacturing or installation. Theendpoints 14 may process the deviceID, appID and appKey to facilitate identifying itself (deviceID) within messages used to transmit data along with the application intended for use therewith (appID) and any attendant encryption (appKey). While the present invention fully contemplates theLPWAL 12 facilitating signaling withendpoints 14 for purposes of the provisioning process, theendpoints 14 may optionally be provisioned independently of signaling communicated from or through theLPWAL 12 to avoid corresponding processing and implementation demands on theLPWAL 12 in having to track endpoints individually or to otherwise be aware of endpoint presence/operation. TheLPWAL 12 may be considered as being reactive to messages received from theendpoints 14 as opposed to being actively involved in configuring or synchronizingendpoints 14 for generating the messages/data being communicated therefrom. - A normalization process may commence with the
endpoint 14 issuing anendpoint message 54 to one or more of theLPWANs endpoint message 54 may include data generated by the endpoint (dataE), the appID of the application intended to process the dataE and/or the deviceID associated therewith. The dataE may be raw data sensed, tabulated, calculated, monitored or otherwise generated at theendpoint 14 and thereafter intended to be formatted according to requirements of theendpoint 14 and/or theLPWAN application 26 associated therewith. While sharing the appID with the endpoint is contemplated, one non-limiting aspect of the present invention anticipates maximizing security by keeping the appID secret from theendpoints 14 and/or theLPWANs LPWAL 12. The secrecy of the appID may be useful in keeping entities from utilizing the translation instructions provided to theLPWAL 12 to facilitate normalizing the dataE for other applications or uses. TheLPWAL 12 may process the dataE included within the endpoint message according to the normalization instructions previously associated with the appID and/or the deviceID included within the corresponding endpoint message. - The normalization process may thereafter continue with the LPWAL transmitting a normalized
message 56 having the dataE as normalized or converted to a common data format (dataC), e.g., a JSON format, and the appEUI associated with the appID included in theendpoint message 54. Thenormalization message 56 may include the dataE being normalized to the dataC according to the translation information previously associated with the corresponding appID and/or device ID. The appID may be solely relied upon in situations where the application vendor intends to have the dataE uniformly translated according to a singular set of translation instructions associated with the appID, i.e., when one set of translation instructions associated with the appID is sufficient to facilitate the desired data normalization. The deviceID may be utilized in cooperation with the appID to facilitate selecting subsets of translation information associated with a particular appID. TheLPWAL 12 may select the subset of translation instructions associated with a particular appID based on theLPWAN endpoint 14, e.g., a range or grouping of deviceIDs may be associated with translation instructions differentiated within the subsets according to LPWAN 16, 18. TheLPWAL 12 may additionally and/or alternatively select the subset of translation instructions associated with a particular appID based on a per-endpoint basis, e.g., individual deviceIDs may be associated with translation instructions differentiated within the subsets according to deviceID. - The translation information utilized by the LPWAL may be determined on a message-by-message packet-by-packet basis such that the
message handler 32 individually assesses each arriving endpoint message to determine the appropriate translation information to be used in facilitating converting its formatting to JSON or another predefined format operable with the associated vendor/application 26, which may optionally include converting the incoming messaging to differing formats in the event theapplication 26 is configured to process multiple data formats. TheLPWAL 12 may utilize different translation instructions to normalize data intended for the same application, i.e., different translation instructions to convert data to a common format, if communicated fromdifferent endpoints 14 when the raw data within the correspondingendpoint messages 54 is formatted differently or otherwise subjected to disparate processing techniques, such as when theendpoints 14 process raw data identically or similarly but format or communicate the data differently due to requirements of theLPWAN endpoints 14 are connected to thesame LPWAN - An endpoint communication process may occur with the vendor and/or
application 26 transmittingdownstream message 58 in response to receipt of thenormalization message 56, such as to facilitate transmitting an acknowledgment to the correspondingendpoint 14. Thedownstream message 58 may be timed relative to a brief interval that theendpoint 14 may be kept awake to receive downstream messages following transmission of theendpoint message 54. TheLPWAL 12 may translate data (messageC) included in the downstream message, which may be formatted identically to the dataC, to data (messageE) suitable for use with the endpoint, which may be formatted identically to the dataE. TheLPWAL 12 may facilitate the downstream transmission normalization according to the translation information previously utilized in facilitating authorization of the dataE included in theendpoint message 54. TheLPWAL 12 may thereafter transmit anendpoint normalization message 60 to the correspondingendpoint 14. Following transmission of the anendpoint normalization message 60 or at any other desire point in time, theLPWAL 12 may generate reports or other information regarding statistical analysis of translations and other messaging passing therethrough, such as to apprise vendors in session or LPWAN operators of usage. - While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/799,157 US11690010B2 (en) | 2016-12-15 | 2020-02-24 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662434610P | 2016-12-15 | 2016-12-15 | |
US15/844,087 US10575250B2 (en) | 2016-12-15 | 2017-12-15 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
US16/799,157 US11690010B2 (en) | 2016-12-15 | 2020-02-24 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/844,087 Continuation US10575250B2 (en) | 2016-12-15 | 2017-12-15 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
Publications (3)
Publication Number | Publication Date |
---|---|
US20200196238A1 US20200196238A1 (en) | 2020-06-18 |
US20220150825A9 true US20220150825A9 (en) | 2022-05-12 |
US11690010B2 US11690010B2 (en) | 2023-06-27 |
Family
ID=62562320
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/844,087 Active 2037-12-26 US10575250B2 (en) | 2016-12-15 | 2017-12-15 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
US16/799,157 Active 2038-03-14 US11690010B2 (en) | 2016-12-15 | 2020-02-24 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/844,087 Active 2037-12-26 US10575250B2 (en) | 2016-12-15 | 2017-12-15 | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
Country Status (1)
Country | Link |
---|---|
US (2) | US10575250B2 (en) |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10575250B2 (en) * | 2016-12-15 | 2020-02-25 | Cable Television Laboratories, Inc. | Normalization of data originating from endpoints within low power wide area networks (LPWANs) |
EP3566422B1 (en) * | 2017-01-03 | 2022-09-07 | Deutsche Telekom AG | Method for data transmission between, on the one hand, an application server, and, on the other hand, at least one internet-of-things communication device using a mobile communication network, system, program and computer program product |
US10383060B2 (en) * | 2017-08-29 | 2019-08-13 | Comcast Cable Communications, Llc | Systems and methods for using a mobile gateway in a low power wide area network |
US10455640B2 (en) * | 2017-12-30 | 2019-10-22 | Intel Corporation | IoT networking extension with bi-directional packet relay |
WO2020105765A1 (en) * | 2018-11-23 | 2020-05-28 | 전자부품연구원 | Method and system for linking to m2m platform using lora communication |
CN109639696A (en) * | 2018-12-23 | 2019-04-16 | 上海上实龙创智慧能源科技股份有限公司 | A kind of format conversion method applied to internet of things data communication |
US10911533B2 (en) * | 2019-03-21 | 2021-02-02 | Cisco Technology, Inc. | Leveraging goaway messages to dynamically inform connection peers of IoT events |
US10582019B1 (en) * | 2019-07-12 | 2020-03-03 | Coupang Corp. | Systems and methods for interfacing networks using a unified communication scheme |
AU2020104458A4 (en) * | 2019-10-25 | 2021-09-30 | Coupang Corp. | Systems and methods for interfacing networks using a unified communication scheme |
WO2021186351A1 (en) * | 2020-03-18 | 2021-09-23 | Behr Technologies Inc. | Sensor data interpreter/converter methods and apparatus for use in low power wide area networks (lpwans) |
US11645247B2 (en) | 2020-08-21 | 2023-05-09 | Sap Se | Ingestion of master data from multiple applications |
US11726846B2 (en) * | 2020-08-21 | 2023-08-15 | Sap Se | Interface for processing sensor data with hyperscale services |
US11522831B1 (en) | 2021-03-31 | 2022-12-06 | Amazon Technologies, Inc. | Increasing edge device address space while complying with a radio communication protocol |
CN112769962B (en) * | 2021-04-07 | 2021-08-10 | 上海顺舟智能科技股份有限公司 | Parameter distribution method, equipment and storage medium for application of Internet of things |
US20230065780A1 (en) * | 2021-08-27 | 2023-03-02 | International Business Machines Corporation | Message management via a universal interface apparatus |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080129466A1 (en) * | 2006-11-30 | 2008-06-05 | Jae-Hong Ruy | Matching system and method for preventing the loss of data between low-power network and non-low-power network |
US20150347486A1 (en) * | 2014-05-27 | 2015-12-03 | Samsung Electronics Co., Ltd. | Agnostic data broker |
US20170053015A1 (en) * | 2015-08-17 | 2017-02-23 | Accenture Global Solutions Limited | Platform data aggregation and semantic modeling |
US20170093952A1 (en) * | 2015-09-29 | 2017-03-30 | Theatro Labs, Inc. | Observation platform using structured communications with external devices and systems |
US20170329918A1 (en) * | 2016-05-10 | 2017-11-16 | Smartylab Corporation | Internet of things based monitoring and assessment platform |
US20170359417A1 (en) * | 2016-06-13 | 2017-12-14 | Verizon Patent And Licensing Inc. | Generating consumer internet-of-things data products |
US20170374490A1 (en) * | 2016-06-22 | 2017-12-28 | Intel Corporation | Internet of things protocol handler |
US20180007115A1 (en) * | 2016-07-01 | 2018-01-04 | Cisco Technology, Inc. | Fog enabled telemetry embedded in real time multimedia applications |
US20180092151A1 (en) * | 2016-09-27 | 2018-03-29 | Aerohive Networks, Inc. | Iot device management using multi-protocol infrastructure network devices |
US20180176862A1 (en) * | 2016-12-15 | 2018-06-21 | Cable Television Laboratories, Inc. | NORMALIZATION OF DATA ORIGINATING FROM ENDPOINTS WITHIN LOW POWER WIDE AREA NETWORKS (LPWANs) |
US10176435B1 (en) * | 2015-08-01 | 2019-01-08 | Shyam Sundar Sarkar | Method and apparatus for combining techniques of calculus, statistics and data normalization in machine learning for analyzing large volumes of data |
US20220128388A1 (en) * | 2016-07-18 | 2022-04-28 | Vaughn Realty Ventures LLC | Water metering system |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9804767B2 (en) * | 2014-06-27 | 2017-10-31 | Microsoft Technology Licensing, Llc | Light dismiss manager |
US9483329B2 (en) * | 2015-02-09 | 2016-11-01 | Sap Se | Categorizing and modeling integration adapters |
US9878663B1 (en) * | 2016-12-07 | 2018-01-30 | International Business Machines Corporation | Cognitive dialog system for driving safety |
WO2016160626A1 (en) * | 2015-03-27 | 2016-10-06 | Globallogic, Inc. | Determining actions based on imputing meaning to sensed information in a distributed computing environment |
US20160328719A1 (en) * | 2015-05-07 | 2016-11-10 | Ca, Inc. | DATA NORMALIZATION FOR INTERNET OF THINGS (IoT) DEVICES |
CA3128629A1 (en) * | 2015-06-05 | 2016-07-28 | C3.Ai, Inc. | Systems and methods for data processing and enterprise ai applications |
WO2016203455A1 (en) * | 2015-06-18 | 2016-12-22 | Alok Sinha | A system and method for establishing communication between plurality of internet of things devices |
EP3320671B1 (en) * | 2015-07-06 | 2020-09-02 | Convida Wireless, LLC | Wide area service discovery for internet of things |
US11567962B2 (en) * | 2015-07-11 | 2023-01-31 | Taascom Inc. | Computer network controlled data orchestration system and method for data aggregation, normalization, for presentation, analysis and action/decision making |
US9929772B2 (en) * | 2016-02-05 | 2018-03-27 | Apana Inc. | Low power, high resolution automated meter reading and analytics |
US20170237623A1 (en) * | 2016-02-15 | 2017-08-17 | Kilton Patrick Hopkins | Methods and apparatus for unified integration and processing of a variety of information sensors and systems |
US20170264501A1 (en) * | 2016-03-14 | 2017-09-14 | Catalina Labs, Inc. | System and method for generating advice for improving internet and wifi performance in a network using machine-learning techniques |
US20180084085A1 (en) * | 2016-09-20 | 2018-03-22 | Arrayent, Inc. | Cross platform device virtualization for an iot system |
US10976714B2 (en) * | 2016-10-08 | 2021-04-13 | People Power Company | Systems and methods for evaluating sensor data of internet-of-things (IoT) devices and responsively controlling control devices |
US10321397B2 (en) * | 2016-11-09 | 2019-06-11 | Cisco Technology, Inc. | System and method to facilitate power management in a long range radio network environment |
KR102143424B1 (en) * | 2016-12-09 | 2020-10-15 | 한국전자통신연구원 | Method for controlling access based on service level and apparatus for the same |
US10686762B2 (en) * | 2016-12-12 | 2020-06-16 | Cisco Technology, Inc. | Secure data exchange platform |
-
2017
- 2017-12-15 US US15/844,087 patent/US10575250B2/en active Active
-
2020
- 2020-02-24 US US16/799,157 patent/US11690010B2/en active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080129466A1 (en) * | 2006-11-30 | 2008-06-05 | Jae-Hong Ruy | Matching system and method for preventing the loss of data between low-power network and non-low-power network |
US20150347486A1 (en) * | 2014-05-27 | 2015-12-03 | Samsung Electronics Co., Ltd. | Agnostic data broker |
US10176435B1 (en) * | 2015-08-01 | 2019-01-08 | Shyam Sundar Sarkar | Method and apparatus for combining techniques of calculus, statistics and data normalization in machine learning for analyzing large volumes of data |
US20170053015A1 (en) * | 2015-08-17 | 2017-02-23 | Accenture Global Solutions Limited | Platform data aggregation and semantic modeling |
US20170093952A1 (en) * | 2015-09-29 | 2017-03-30 | Theatro Labs, Inc. | Observation platform using structured communications with external devices and systems |
US20170329918A1 (en) * | 2016-05-10 | 2017-11-16 | Smartylab Corporation | Internet of things based monitoring and assessment platform |
US20170359417A1 (en) * | 2016-06-13 | 2017-12-14 | Verizon Patent And Licensing Inc. | Generating consumer internet-of-things data products |
US20170374490A1 (en) * | 2016-06-22 | 2017-12-28 | Intel Corporation | Internet of things protocol handler |
US20180007115A1 (en) * | 2016-07-01 | 2018-01-04 | Cisco Technology, Inc. | Fog enabled telemetry embedded in real time multimedia applications |
US20220128388A1 (en) * | 2016-07-18 | 2022-04-28 | Vaughn Realty Ventures LLC | Water metering system |
US20180092151A1 (en) * | 2016-09-27 | 2018-03-29 | Aerohive Networks, Inc. | Iot device management using multi-protocol infrastructure network devices |
US20180176862A1 (en) * | 2016-12-15 | 2018-06-21 | Cable Television Laboratories, Inc. | NORMALIZATION OF DATA ORIGINATING FROM ENDPOINTS WITHIN LOW POWER WIDE AREA NETWORKS (LPWANs) |
Also Published As
Publication number | Publication date |
---|---|
US20200196238A1 (en) | 2020-06-18 |
US10575250B2 (en) | 2020-02-25 |
US11690010B2 (en) | 2023-06-27 |
US20180176862A1 (en) | 2018-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11690010B2 (en) | Normalization of data originating from endpoints within low power wide area networks (LPWANs) | |
US11159623B2 (en) | Syndicated data system and method enabling enhanced supplier and application independent device information receipt, functionality and services | |
US10506612B2 (en) | Methods and device for authorization between a customer device and connectivity manager | |
JP5670477B2 (en) | Extended service discovery mechanism in wireless communication systems | |
US8397095B2 (en) | Method and apparatus for synchronizing time of day of terminal in convergent network | |
JP6816152B2 (en) | Methods and equipment for configuring M2M devices | |
CN109981668A (en) | Common apparatus Internet of Things communication means based on the extensive agreement of MQTT | |
JP2013527668A (en) | Machine-to-machine communication method | |
Haubro et al. | TSCH‐over‐LoRA: long range and reliable IPv6 multi‐hop networks for the internet of things | |
Florea et al. | Survey of standardized protocols for the Internet of Things | |
CN110462600B (en) | System, method and apparatus for networked media distribution | |
EP4044699B1 (en) | Method and device for delivering time-sensitive networking synchronization information in mobile communication system | |
AU2018441206A1 (en) | A method of and devices for supporting selective forwarding of messages in a network of communicatively coupled communication devices. | |
CN101808014B (en) | Thin AP architecture-based network management scheme and system thereof | |
Yegin et al. | LoRaWAN protocol: specifications, security, and capabilities | |
WO2011116598A1 (en) | Method and system for achieving management of gateway | |
EP2028794A1 (en) | Network discovery protocol | |
US11564187B2 (en) | Method and device for supporting configuration of time synchronization network in mobile communication network | |
US10285177B2 (en) | System and method for automatic monitoring and control of sensors and machines in remote locations | |
TWI611370B (en) | Internet of Things system and physiological data exchange method implemented thereby | |
EP3210360B1 (en) | Distribution of media content identifiers to wireless communication devices | |
WO2011103723A1 (en) | Method for managing sensor nodes and apparatus thereof | |
US11109197B2 (en) | Short message service for internet devices | |
US11665564B2 (en) | System and method for generation of shared signal frequency map for frequency sharing choice | |
US20230421444A1 (en) | System and method for over the air commissioning of devices communicating over a communication network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO SMALL (ORIGINAL EVENT CODE: SMAL); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: CABLE TELEVISION LABORATORIES, INC., COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MALAS, DARYL;LUND, ROBERT M.;SCHAFFER, BRANDON;AND OTHERS;REEL/FRAME:054048/0268 Effective date: 20171218 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
FEPP | Fee payment procedure |
Free format text: PETITION RELATED TO MAINTENANCE FEES GRANTED (ORIGINAL EVENT CODE: PTGR); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |