U.S. patent application number 16/799157 was filed with the patent office on 2022-05-12 for normalization of data originating from endpoints within low power wide area networks (lpwans).
The applicant listed for this patent is CABLE TELEVISION LABORATORIES, INC.. Invention is credited to STEVE JOHNSON, ROBERT M. LUND, DARYL MALAS, BRANDON SCHAFFER.
Application Number | 20220150825 16/799157 |
Document ID | / |
Family ID | 1000006300424 |
Filed Date | 2022-05-12 |
United States Patent
Application |
20220150825 |
Kind Code |
A9 |
MALAS; DARYL ; et
al. |
May 12, 2022 |
NORMALIZATION OF DATA ORIGINATING FROM ENDPOINTS WITHIN LOW POWER
WIDE AREA NETWORKS (LPWANs)
Abstract
The normalization of data originating from endpoints within low
power wide area networks (LPWANs) is contemplated. The
normalization may be beneficial to facilitate 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.
Inventors: |
MALAS; DARYL; (Broomfield,
CO) ; LUND; ROBERT M.; (Boulder, CO) ;
SCHAFFER; BRANDON; (Loveland, CO) ; JOHNSON;
STEVE; (Boulder, CO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
CABLE TELEVISION LABORATORIES, INC. |
Louisville |
CO |
US |
|
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20200196238 A1 |
June 18, 2020 |
|
|
Family ID: |
1000006300424 |
Appl. No.: |
16/799157 |
Filed: |
February 24, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15844087 |
Dec 15, 2017 |
10575250 |
|
|
16799157 |
|
|
|
|
62434610 |
Dec 15, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 69/18 20130101;
H04L 67/565 20220501; H04L 67/125 20130101; H04L 69/08 20130101;
Y02D 30/70 20200801; H04L 67/12 20130101; H04L 69/06 20130101; H04W
52/0216 20130101 |
International
Class: |
H04W 52/02 20060101
H04W052/02; H04L 29/06 20060101 H04L029/06; H04L 29/08 20060101
H04L029/08 |
Claims
1. A method for normalizing data for one or more endpoints
associated with one or more low power wide area networks (LPWANs),
the method comprising: receiving data originating from one or more
of the endpoints (dataE); normalizing the dataE to data having a
common data format (dataC); and forwarding the dataC to an
application for processing.
2. The method of claim 1 further comprising receiving the dataE,
normalizing the dataE and forwarding the dataC with an LPWAN
abstraction layer (LPWAL).
3. The method claim 2 further comprising normalizing the dataE
according to translation information provided to the LPWAL from an
application vendor associated with the application.
4. The method claim 3 further comprising determining mapping
instructions from the translation information, the mapping
instructions being sufficient to map a language-dependent format of
the dataE to a language-independent format of the dataC.
5. The method claim 3 further comprising determining mapping
instructions from the translation information, the mapping
instructions being sufficient to map a non-JavaScript Object
Notation (JSON) format of the dataE to a JSON format of the
dataC.
6. The method of claim 3 further comprising receiving the dataE
with the LPWAN following communication from at least one gateway
and at least one network server, the least one gateway and the
least one network server being associated with a first LPWAN of the
one or more LPWANs, the at least one gateway operating
independently of the least one network server to facilitate
forwarding the dataE to the at least one network server following
receipt from the first endpoint.
7. The method of claim 1 further comprising normalizing the dataE
by mapping raw data included therein to predefined, text-based
syntax of the dataC.
8. The method of claim 7 further comprising forwarding the raw data
to the application such that the application independently receives
both of the dataC and the raw data.
9. A method for normalizing data for a plurality of endpoints
associated with one or more low power wide area networks (LPWANs),
the method comprising: receiving a plurality of application global
identifiers (appEUI) for a plurality of applications; generating a
plurality of application identifiers (appIDs) for the plurality of
applications as a function of the appEUIs, each of the appIDs being
different than the appEUI; receiving translation information
associated with each of the plurality of appIDs, the translation
information including instructions sufficient for mapping data
originating from the endpoints (dataE) having dissimilar formats to
data having a common data format (dataC) utilized by one or more of
the plurality of applications associated therewith; receiving a
first message from a first endpoint of the plurality of endpoints,
the first message including dataE and a first appEUI of the
plurality of appEUIs; determining first translation information of
the translation information to be associated with a first appID of
the plurality of appIDs, the first appID being associated with the
first appEUI; and transmitting a second message to a first
application of the plurality of applications, the first application
being associated with the first appEUI, the second message
including the first appID and dataC derived from normalizing the
dataE within the first message according to the first translation
information.
10. The method of claim 9 further comprising: receiving a third
message from a second endpoint of the plurality of endpoints, the
third message including dataE and the first appEUI; and
transmitting a fourth message to the first application, the fourth
message including the first appID and dataC derived from
normalizing the dataE within the second message according to the
first translation information.
11. The method of claim 9 further comprising: receiving a plurality
of device identifiers (deviceIDs) for the plurality of endpoints;
associating the translation information with the plurality of
deviceIDs; receiving a third message from the first endpoint, the
third message including dataE and the first appEUI; determining the
first translation information to be additionally associated with a
first deviceID of the plurality of device identifiers, the first
deviceID being associated with the first endpoint; and transmitting
a fourth message to the first application, the fourth message
including the first appID and dataC derived from normalizing the
dataE within the third message according to the first translation
information.
12. The method claim 11 further comprising: receiving a fifth
message from a second endpoint of the plurality of endpoints, the
fifth message including dataE and the first appEUI; determining
second translation information of the translation information to be
associated with a second deviceID and the first appID, the second
deviceID being associated with the second endpoint, the second
translation information being different from the first translation
information such that the second translation information maps dataE
to dataC differently than the first translation information; and
transmitting a sixth message to the first application, the sixth
message including the first appID and dataC derived from
normalizing the dataE within the fifth message according to the
second translation information, the dataC of the second message and
the sixth message being identically formatted.
13. The method of claim 12 further comprising: receiving a seventh
message from the first endpoint, the seventh message including
dataE and a second appEUI of the plurality of appEUIs; determining
third translation information of the translation information to be
associated with the first deviceID and a second appID of the
plurality of appIDs, the second appID being associated with the
second appEUI; and transmitting an eighth message to a second
application of the plurality of applications, the second
application being associated with the second appEUI, the seventh
message including the second appID and dataC derived from
normalizing the dataE within the seventh message according to the
third translation information.
14. The method of claim 13 further comprising: receiving a ninth
message from the second endpoint, the ninth message including dataE
and the second appEUI; determining the third translation
information of the translation information to be associated with
the second deviceID and the second appID; and transmitting a tenth
message to the second application, the ninth message including the
second appID and dataC derived from normalizing the dataE within
the ninth message according to the third translation
information.
15. A low power wide area network abstraction layer (LPWAL)
comprising: a low power wide area network (LPWAN) interface
interfacing with a plurality of LPWANs, each of the plurality of
LPWANs including: i) at least one network server; ii) at least one
gateway; iii) a plurality of endpoints, the plurality of endpoints
being solely battery-operated devices; and iv) wherein the at least
one network server interfaces with the LPWAN interface and the at
least one gateway, the plurality of endpoints interface with one or
more of the at least one gateway; an application interface
interfacing with at least one application connected thereto via the
Internet or other communication network; and a message handler
interfacing messages between the LPWAN interface and the
application interface, the message handler normalizing data carried
within the messages received at the LPWAN interface such that
disparate data formats employed therewith are normalized to a
common format prior to being interfaced to the at least one
application via the application interface.
16. The LPWAL of claim 15 further comprising a processor and
non-transitory computer-readable medium having a plurality of
non-transitory instructions executable with the processor, the
plurality of non-transitory instructions being sufficient to
facilitate: receiving a plurality of translation instructions from
the plurality of applications, the plurality of translations
instructions being sufficient for normalizing the data carried
within the messages received at the LPWAN interface according to
formatting characteristics of the plurality of endpoints and the
LPWAN associated therewith; controlling the message handler on a
message-by-message basis to lookup one or more of the plurality of
translation instructions for each message received at the LPWAN
interface, and based thereon, normalize the data included therewith
prior being interfaced to the at least one application; collecting
accounting information for each of the plurality of LPWANs, the
accounting information including a volume of data traffic for each
of the LPWANs; and transmitting an accounting report to each
operator associated with the plurality of LPWANs, the accounting
report including the accounting information.
17. The LPWAL of claim 16 wherein the plurality of non-transitory
instructions are sufficient to facilitate an endpoint registration
process for each of the plurality of endpoints, the endpoint
registration process including: receiving a plurality of
application global identifiers (appEUI) from vendors associated
with each of the plurality of applications, the plurality of
appEUIs globally and uniquely identifying one of the plurality of
applications; receiving a plurality of device identifiers
(deviceIDs) for the plurality of endpoints, the plurality of device
identifiers globally and uniquely identifying one of the plurality
of endpoints; generating a plurality of application identifiers
(appIDs) for the plurality of applications as a function of the
appEUIs, each of the appIDs being different than the appEUI; and
generating a plurality of application keys (appKeys) for the
plurality of appIDs, each of the appKeys uniquely encrypting
messaging for the application associated with each of the plurality
of appIDs.
18. The LPWAL of claim 16 wherein at least a plurality of the
translation instructions normalize the data carried within the
messages received at the LPWAN interface such that the data is
translated from a non-JavaScript Object Notation (JSON) format to a
JSON format.
19. The LPWAL of claim 16 wherein the plurality of endpoints:
operate according to a messaging strategy whereby a radio interface
or other wireless communication mechanisms associated therewith to
communicate with the gateways is shutdown or turned off during
non-data intervals such that the endpoints are unable to receive
downstream transmission or otherwise wirelessly communicate during
non-data intervals; and the radio interface or other wireless
communication mechanisms are woken up during data intervals to
consume battery energy for purposes of transmitting data upstream
to the gateways.
20. The LPWAL of claim 19 wherein radio interface or other wireless
communication mechanisms are kept temporarily operational during
the data intervals following upstream transmission of the data to
facilitate receipt of downstream communications from one or more
the gateways.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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.
TECHNICAL FIELD
[0002] 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.
BACKGROUND
[0003] 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.
[0004] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 illustrates a system for normalizing data
communications in accordance with one non-limiting aspect of the
present invention.
[0006] FIG. 2 illustrates a flowchart for a method of normalizing
data in accordance with one non-limiting aspect of the present
invention.
DETAILED DESCRIPTION
[0007] 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.
[0008] 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.
The present invention, however, 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.
[0009] 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, for example, 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.
[0010] 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.
[0011] The spatial diversity created by multiple gateways 20
receiving a single transmission from one or more of the endpoints
14 may be beneficial in facilitating error correction and other
signal processing techniques. When multiple gateways 20 receive the
same transmission, 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.
[0012] 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.
[0013] 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. 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.
[0014] 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 deployed applications 26 and new applications 26 to make use of
the data due to the disparate processes, protocols, architectures,
properties, etc. being independently used by the endpoints 14 for
structuring, formatting and communicating the data. Requiring the
applications 26 to not only identify each of the disparate
characteristics of the endpoints and/or the LPWANs 16, 18 but also
to include capabilities sufficient for making use of the attendant
data may be particularly problematic when one application is faced
with processing sensor data from a great number of disparate
endpoints 14. When an application 26 desires temperature readings,
for example, the corresponding 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 the LPWAL 12, would require the
application 26 to include procedures for addressing each manner
that the raw temperature values are being communicated. It could
become untenable for a single application 26 to handle thousands
and thousands of sensors when disparately generating such raw
temperature values. 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.
[0015] 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
[0016] 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, however, 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, which
may in some instances be the same as the application 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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:
TABLE-US-00001 { "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" }
[0022] 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. In this manner, 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.
[0023] 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. 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 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. 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 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.
[0024] 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. Prior to deployment, 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. Once endpoints 14 are deployed, 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.
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.
[0025] 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, regardless of endpoint limitations, 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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). While the
present invention fully contemplates the LPWAL 12 facilitating
signaling with endpoints 14 for purposes of the provisioning
process, 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.
[0033] 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.
[0034] 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.
[0035] 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. In the event
the LPWAL lacks suitable translation instructions or an error
occurs, the raw data may be transmitted to the application either
in conjunction with the converted data or instead of the converted
data.
[0036] 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. Following transmission of the
an endpoint normalization message 60 or at any other desire point
in time, 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.
[0037] 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.
* * * * *