Source: https://patents.google.com/patent/US9848458B2/en
Timestamp: 2019-10-18 12:41:36
Document Index: 590949387

Matched Legal Cases: ['art 170', 'art 170', 'art 170', 'art 170', 'art 170', 'art 170']

US9848458B2 - Wireless parameter-sensing node and network thereof - Google Patents
Wireless parameter-sensing node and network thereof Download PDF
US9848458B2
US9848458B2 US14/556,469 US201414556469A US9848458B2 US 9848458 B2 US9848458 B2 US 9848458B2 US 201414556469 A US201414556469 A US 201414556469A US 9848458 B2 US9848458 B2 US 9848458B2
US14/556,469
US20160157113A1 (en
II James Thomas Row
Joseph Lawrence Uelk
Faraz H Jafferi
Vincent Charles Graffagnino
Stacy Louise Devino
David Harlow Sin
2014-12-01 Application filed by Oceus Networks Inc filed Critical Oceus Networks Inc
2014-12-01 Priority to US14/556,469 priority Critical patent/US9848458B2/en
2014-12-03 Assigned to Oceus Networks, Inc. reassignment Oceus Networks, Inc. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DEVINO, STACY LOUISE, GRAFFAGNINO, VINCENT CHARLES, HILL, CHRISTOPHER ALLEN, JAFFERI, FARAZ H, LUONG, ERIC, ROW, JAMES THOMAS, II, SIN, DAVID HARLOW, TSENG, DANNY, UELK, JOSEPH LAWRENCE
2016-06-02 Publication of US20160157113A1 publication Critical patent/US20160157113A1/en
2017-12-19 Publication of US9848458B2 publication Critical patent/US9848458B2/en
101800001776 Nuclear inclusion protein B Proteins 0 description 1
230000015654 memory Effects 0 abstract claims description 98
244000045947 parasites Species 0 description 3
A wireless parameter-sensing node in a network thereof, the parameter-sensing node includes: sensors to sample values of parameters, respectively; a memory; a collection engine configured to: selectively collect data representing at least some of the sampled values, respectively; and store the collected data in the memory; an omega engine configured to: retrieve selected portions of the collected data from the memory; and send the selected portions to a remote host; wherein at least one of the collection, the storage, the retrieval and the sending are performable according to one or more reconfigurable collection-control criteria, one or more reconfigurable storage-control criteria, one or more reconfigurable retrieval-control criteria and one or more reconfigurable reporting-control criteria, respectively, stored in the memory. The parameter-sensing node and the remote host relate, e.g., as a taskee-client and a taskor-server, respectively.
Embodiments of the present invention relate to a wireless parameter-sensing node in a network thereof, and more particularly to a parameter-sensing node such as mobile telephone in a mobile-telephony network.
In a wireless communication network, nodes are connected wirelessly to the network. In some wireless networks, the wirelessly-connected nodes are themselves physically mobile, e.g., a conventional mobile-telephony network. While user equipment (UE), e.g., mobile telephones, attached to a conventional mobile-telephony network are themselves physically mobile, their communication is supported by physically stationary infrastructure, namely stationary base stations in different locations that communicate with a remote, stationary mobile-telephone-switching office (MTSO). A given one of the UEs can move from the coverage area of a first base station into the coverage area of a second base station. To facilitate the handoff of a given UE from the first base station to the second base station, some received signal strength data are collected by and received from the given UE by the first base station.
Many locations throughout the world lack such physically-stationary network infrastructures and/or exist under conditions that deter, if not prevent, construction of the same. In a war zone, for example, building stationary network infrastructure is not feasible due, e.g., to the transient nature of military personnel and equipment.
One device that can be used to improve communications in such environments is a mobile cellular network (MCN) communication system. Aside from the UEs, in an MCN, all of the components of a typical cellular network reside in one device (referred to herein as a network-in-a-box (NIB)). The NIB itself is mobile. The MCN provides an example of a wireless network in which not only the wirelessly-connected nodes themselves are physically mobile, but the infrastructure that supports their communication (namely, the NIB) also is physically mobile.
The NIB is self-contained in that it does not need to communicate with other base stations or an MTSO to provide complete cellular network functionality to instances of user equipment (UEs) within its area of coverage. One example of a commercially available NIB is the XIPHOS™ available from OCEUS NETWORKS™.
As an NIB moves, the network coverage (that it provides) moves with it. To increase the range of a MCN, multiple NIBs can be networked together to create a network of MCN communication systems, also referred to herein as a NOM. Among other things, the MCN communication system can perform handover operations when a UE moves from one coverage area to another coverage area within the NOM. Furthermore, if an MCN communication system moves from one location to another, the NOM can allocate affected UEs between the moving MCN communication system and other MCN communication systems in the area.
An aspect of the present invention provides a wireless parameter-sensing node in a network thereof, the parameter-sensing node comprising: sensors to sample values of parameters, respectively; a memory; a collection engine configured to: selectively collect data representing at least some of the sampled values, respectively; and store the collected data in the memory; an omega engine configured to: retrieve selected portions of the collected data from the memory; and send the selected portions to a remote host; wherein at least one of the collection, the storage, the retrieval and the sending are performable according to one or more reconfigurable collection-control criteria, one or more reconfigurable storage-control criteria, one or more reconfigurable retrieval-control criteria and one or more reconfigurable reporting-control criteria, respectively, stored in the memory.
Another aspect of the present invention provides a client-server computer architecture comprising: a first host; and a taskor server executable on the first host and configured to: receive a query from a taskee client for an unspecified one amongst a plurality of tasks; make a selection of a given one from amongst the plurality of tasks; indicate the selected task to the taskee client; and receive a report including execution results for the selected task from the taskee client.
A further aspect of the present invention is to provide a client-server computer architecture comprising: a first host; and a taskee client executable on the first host and configured to: query a taskor server for an unspecified one amongst a plurality of tasks, a consequent selection of a given one from amongst the plurality tasks being performable by the taskor server; receive an indication of the given task from the taskor server; facilitate execution of the given task on the first host; and report execution-results of the given task to the taskor server.
Yet another aspect of the present invention is to provide method of operating at least one wireless parameter-sensing node in a network thereof, the at least one node including sensors to sample values of parameters, respectively, and a memory, the method comprising: selectively collecting data representing at least some of the sampled values, respectively; and storing the collected data in the memory; retrieving selected portions of the collected data from the memory; and sending the selected portions to a remote host; wherein at least one of the collection, the storage, the retrieval and the sending are performable according to one or more reconfigurable collection-control criteria, one or more reconfigurable storage-control criteria, one or more reconfigurable retrieval-control criteria and one or more reconfigurable reporting-control criteria, respectively, stored in the memory.
These and further and other objects and features of the present invention are apparent in the disclosure, which includes the above and ongoing written specification, with the drawings.
FIG. 1A is a block diagram of a network of wireless parameter-sensing nodes, according to an embodiment of the present invention;
FIG. 1B is a more detailed block diagram of one of the UEs and the NIB of FIG. 1A, according to an embodiment of the present invention;
FIG. 1C is a block diagram illustrating examples of criteria that can be stored in the settings repository, according to an embodiment of the present invention;
FIG. 1D is a communication-layer diagram illustrating the path of flow during a communication session between the omega engine of the UE and the alpha engine of the NIB, according to an embodiment of the present invention;
FIG. 2A is an example of a state diagram for the collection engine of the UE, according to an embodiment of the present invention;
FIGS. 2B and 2C are examples of state diagrams for the omega engine of the UE, according to embodiments of the present invention, respectively;
FIG. 3A is a database-schema diagram illustrating an example of possible relationships amongst data collected and then organized into sets thereof by the collection engine of the UE, according to an embodiment of the present invention;
FIGS. 3B and 3C are a flowchart and a corresponding database-schema diagram illustrating an aspect of the operation of the collection engine of the UE, according to an embodiment of the present invention;
FIGS. 3D and 3E are a flowchart and a message-assembly diagram illustrating an aspect of the operation of the omega engine of the UE, according to an embodiment of the present invention;
FIGS. 3F and 3G are a flowchart and a database-schema diagram illustrating an aspect of the operation of the collection engine of the UE, according to an embodiment of the present invention;
FIGS. 3H, 3I and 3J are a database-schema diagram, a flowchart and a database-schema diagram, respectively, illustrating an aspect of the operation of the collection engine, according to an embodiment of the present invention;
FIG. 4 is a flow diagram of interactions that can occur in a taskee-client—taskor-server relationship, according to an embodiment of the present invention;
FIG. 5 is an example of a UML (uniform modeling language) sequence diagram, according to an embodiment of the present invention, that is a counterpart to the flowchart of FIG. 4;
FIG. 6 is an example of a state diagram for a taskee-client (omega engine), according to an embodiment of the present invention; and
FIG. 7 is a block diagram of two instances of node and an alternative remote host, according to an embodiment of the present invention.
Embodiments of wireless parameter-sensing node in a network thereof will now be disclosed in terms of various exemplary embodiments. This specification discloses one or more embodiments that incorporate features of the present invention. The embodiment(s) described, and references in the specification to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment(s) described may include a particular feature, structure, or characteristic. Such phrases are not necessarily referring to the same embodiment. The skilled artisan will appreciate that a particular feature, structure, or characteristic described in connection with one embodiment is not necessarily limited to that embodiment but typically has relevance and applicability to one or more other embodiments.
As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of” “Consisting essentially of,” when used in the claims, shall have its ordinary meaning as used in the field of patent law.
The word “network” is used herein to mean one or more conventional or proprietary networks using an appropriate network data transmission protocol. Examples of such networks include, PSTN, LAN, WAN, WiFi, WiMax, Internet, 35 World Wide Web, Ethernet, other wireless networks, and the like.
In developing embodiments of the present invention, among other things, the inventors thereof:
were mindful that reducing bandwidth consumption is an ongoing design consideration and managing bandwidth consumption is an ongoing management consideration in general for wireless communication networks, in particular for a conventional mobile-telephony network, and yet more particularly for a mobile cellular network (MCN) communication system;
recognized, in the context of a UE-handover in an MCN communication system, that it may be beneficial for a given UE to collect more signal strength data and provide the same to the NIB than is typically collected and received in preparation for a handover in the conventional mobile-telephony network by a base station;
recognized, not only in the circumstance of a UE-handover but in other circumstances in the context of an MCN communication system, that it may be beneficial for a given UE to collect data (and provide the same to the NIB) that is not collected by a conventional UE and/or that is collected by a conventional UE but not received by a base station in the conventional mobile-telephony network;
recognized that the desired amount of data that is collected by a given UE and/or that is retrieved by an NIB varies on a per-UE basis, i.e., varies between different instances of a UE (even under circumstances in which all of the UEs served by the NIB are instances of substantially the same combination of hardware and software);
recognized that the per-UE variation in the desired amount of data that is collected by a given UE and/or that is retrieved by an NIB varies according to multiple factors including (but not limited to):
the location of the given UE relative to the NIB;
the motion of the given UE relative to the NIB;
the time of day (in general);
the mission-requirements of the user on which is borne the given UE (e.g., where the user is a warrior in the context of a war zone, a rescuer in the context of a disaster-response scenario, etc.);
the momentary phase of a multi-phase mission of the user on which is borne the given UE (e.g., where the user is a warrior in the context of a war zone, a rescuer in the context of a disaster-response scenario, etc.); and
the momentary level of danger being encountered by the user on which is borne the given UE (e.g., where the user is a warrior in the contexts of a war zone, a rescuer in the context of a disaster-response scenario, etc.);
recognized that the desired amount of data collection by an NIB relative to a given UE varies depending on the circumstances under which the NIB is operating, e.g., at a given moment, the NIB might be servicing other UEs which are facing more demanding circumstances than the given UE such that the priority-level attributed to collecting data by the other UEs and/or receiving collected data therefrom at that time is higher than the priority-level for the given UE; and
recognized that (1) a UE which has at least one of dynamically reconfigurable data collection capability, dynamically reconfigurable local data storage capability, dynamically reconfigurable local data retrieval capability and dynamically reconfigurable capability of sending collected data to host (e.g., an NIB) and (2) a host (e.g., an NIB) that can dynamically control such reconfigurations can advantageous, e.g., in terms of facilitating the management of bandwidth consumption in general for wireless communication networks, and in particular for an NIB.
One or more embodiments of the present invention provide an MCN communication system that includes such a dynamically reconfigurable UE and a corresponding NIB that can dynamically control such reconfiguration, and corresponding methods of operation.
FIG. 1A is a block diagram of a network 100 of wireless parameter-sensing nodes, according to an embodiment of the present invention.
In FIG. 1A, network 100 includes multiple nodes 102 that communicate wirelessly, i.e., via wireless communication sessions 104, respectively, with a remote host 106. For example, network 100 can be a mobile-telephony network or a mobile cellular network (MCN) communication system such that host 106 is a base station or a network-in-a-box (NIB), respectively, and nodes 102 are instances of user equipment (UE) that can engage in radio telephony with NIB 106. Among other things, NIB 106 includes a wireless interface, e.g., an LTE (Long Term Evolution) modem (not illustrated), a WiFi modem (not illustrated), etc., by which to communicate with nodes 102 via wireless communication sessions 104, respectively.
An instance of node 102 can be any device that includes a wireless interface, e.g., an LTE modem (not illustrated), a WiFi modem (not illustrated), etc., by which to communicate with NIB 106 via a wireless communication session 104. For example, node 102 can be a mobile phone (e.g., a smart mobile phone running the ANDROID™ operating system, a laptop/notebook computer, a tablet computer, a dedicated GPS (Global Positioning System) receiver, a smart sensor, etc.) Additionally, such LTE-modem-equipped devices further include computing components (not illustrated in FIG. 1A), e.g., one or more processor units, one or more communications buses, one or more memories, one or more interfaces (e.g., a man-machine interface), etc. Each UE 102 communicates with NIB 106 via a wireless communication session 104, respectively.
Also included in FIG. 1A is an exploded of one of UEs 102 that illustrates some (but not all) of the operational components of UEs 102. As such, each UE 102 includes: an omega engine 108; dynamically reconfigurable criteria 110 by which the operation of omega engine 108 is controlled; a memory 112 to store collected data locally; a sensor-data collection engine 114; and dynamically reconfigurable criteria 116 by which the operation of collection engine 114 is controlled. Criteria 110 and 116 can be stored in one or more of the noted (above) albeit not-illustrated (in FIG. 1A) memories. Omega engine 108 and collection engine 114 can be implemented, for example, as executable code (e.g., an ANDROID™ background service) stored in one or more of the noted (above) albeit not-illustrated (in FIG. 1A) memories in UE 102 and executed by one or more of the noted (above) albeit not-illustrated (in FIG. 1A) processor units in UE 102, respectively. For ease of illustration, communication session 104 is illustrated as terminating in omega engine 108.
A detailed discussion of the components and operation of UEs 102 and NIB 106 appear below in the discussion of other FIGS. Briefly, however, it should be understood that UE 102 also includes operational components (not illustrated in FIG. 1A) and various sensors (not illustrated in FIG. 1A) which sense parameters (at least some of which are operational parameters of the operational components) and sample the same to thereby generate data representing the sampled values, respectively. According to instances of criteria 116, collection engine 114 selectively collects data representing at least some of the sampled values, respectively, and stores the collected sensor data into memory 112. According to instances of criteria 110, omega engine 106 selectively retrieves portions of the collected data from memory 112 and periodically sends the selected portions to NIB 106 in messages 118 during wireless communication sessions 104, respectively.
In other words, network 102 of FIG. 1A is an example of a mobile cellular network (MCN) communication system that includes: dynamically reconfigurable UEs 102; and a corresponding NIB 106 that can dynamically and selectively control the reconfiguration of UEs 102.
FIG. 1B is a more detailed block diagram of one of UEs 102 and NIB 106, according to an embodiment of the present invention.
As briefly introduced above (in the discussion of FIG. 1A), UE 102 includes various sensors, which can be internal components of UE 102 and/or discrete external components coupled to UE 102. At least some of the internal sensors can be configured to sense at least some of the operational parameters of the operational components of UE 102. Some (but not all) of the various sensors are illustrated in FIG. 1B. Examples of such sensors include: a position sensor 124, e.g., based on a global positioning system (GPS) receiver (not illustrated in FIG. 1B; one or more platform sensors 126; one or more sensors 128 associated with and measuring operating parameters of a radio-telephony system (not illustrated in FIG. 1B), respectively; an orientation sensor 130, e.g., based on a geomagnetic field sensor (not illustrated in FIG. 1B) and one or more accelerometers (not illustrated in FIG. 1B); and one or more sensors 132 associated with and measuring operating parameters of a power system (not illustrated in FIG. 1B), respectively.
Parameters from sensors 124-132 can be grouped into a set of domains. More particularly, parameters associated with sensors 124 and 130 can be included in a location domain. Examples of parameters in the location domain associated with sensor 124 include: a GPS-derived altitude; a GPS-derived latitude; a GPS-derived longitude; a GPS-derived time; a GPS-derived heading; etc. Examples of parameters in the location domain associated with sensor 132 include: a multi-dimensional array including geomagnetic field strength values for each coordinate axis in a standard three-axis coordinate system; a multi-dimensional array including azimuth (yaw), pitch, and roll values, etc.
Parameters associated with the one or more sensors 128 can be included in a telephony domain. Examples of parameters in the telephony domain associated with the one or more sensors 128 include: an Access Point Name (APN); a Channel Quality Indicator (CQI); an Internet Protocol (IP) address; a Public Land Mobile Network (PLMN) identifier; a Reference Signal Received Power (RSRR) indicator; a Reference Signal Received Quality (RSRQ) indicator; a Reference Signal Signal-To-Noise Ratio (RSSNR) indicator; etc.
Parameters associated with the one or more sensors 132 can be included in a power domain. Examples of parameters in the power domain associated with the one or more sensors 132 include: a health index of a battery on the mobile device; a charge level indicating a level of charge remaining in the battery; a plugged state indicator of whether a battery-charger is being charged by a charger; a battery presence indicator of whether a battery is present on the mobile device; a battery status indicator of whether the battery is charging or discharging; a battery temperature; a battery voltage; etc.
Parameters associated with the one or more sensors 126 can be included in a platform domain. Examples of parameters in the platform domain associated with the one or more sensors 126 include: a name of the UE 102; a serial number of UE 102; an elapsed uptime of UE 102; an amount of free memory on UE 102; a total amount of memory on UE 102; an International Mobile Station Equipment Identity (IMEI); an International Mobile Subscriber Identity (IMSI); an indicator of an operating system (OS) on UE 102; a version number of the OS on UE 102; etc.
In FIG. 1B, UE 102 is illustrated as further including an image processor 134 and a camera 136, e.g., a digital camera. A variety of devices (not illustrated) can be mounted to UE 102 by which a given sample of a fluid can be disposed in the optical field of camera 136 and, if needed, illuminated. Such devices are analogous to a stage of a microscope, wherein the stage is configured to receive a sample of fluid pressed between two slides and to dispose the same in the optical field of the microscope. When an image of the given fluid sample is processed by image processor 134 according to appropriate corresponding image-processing software executable thereon (not illustrated), together camera 136 and image processor 134 can function, e.g., as a lens-free digital microscope, which is another type sensor (and is denoted in FIG. 1B as sensor 137). Such a lens-free digital microscope can, for example, analyze: a blood sample to determine red and/or white blood cell counts and/or spot viruses (such as influenza, HIV, etc.); a urine sample to identify indications of dehydration, kidney disease, etc.; a water sample to identify the presence of parasites (e.g., bacteria, etc.), toxic chemicals (e.g., Mercury, etc.), etc.
As noted, UE 102 may include sensors that are discrete external components which are externally coupled to UE 102. For example, UE 102 might be coupled to vital-sign sensors 140 that sense vital signs (e.g., heart rate, respiration rate, blood pressure, body temperature, etc.) of a user (e.g., a warrior, rescuer, etc.) associated with (and on which is borne) UE 102. As a further example, UE 102 might be coupled to one or more sensors 138 that sense conditions to which are exposed UE 102 and the user (e.g., a warrior, rescuer, etc.) associated with (and on which is borne) UE 102, e.g., ambient barometric pressure, ambient temperature, nuclear radiation, chemical agents, electric fields (RF (radio frequency), microwave, etc.), magnetic fields, etc.
The set of domains discussed above can also include domains corresponding to sensors 137-140. More particularly, parameters associated with sensors 137 and 138 can be included in an environment domain. Examples of parameters in the environment domain associated with sensor 124 include: blood red and/or white blood cell counts (relative to a blood sample); flags representing the presence of various viruses, respectively (relative to a blood sample); parameters typically included in a urinalysis (relative to a urine sample); a flag representing the presence of any parasites (relative to a water sample); flags representing the presence of particular parasites (relative to a water sample); etc. Examples of parameters in the environment domain associated with sensor 138 include: ambient temperature; ambient barometric pressure; detected presence of nuclear radiation; cumulative exposure to nuclear radiation, detected presence of one or more chemical agents, detected present of electric fields (RF, microwave, etc.), detected presence of magnetic fields, etc.
Parameters associated with sensor 140 can be included in a user domain. Examples of parameters in the user domain associated with sensor 140 include: a user body temperature; a user pulse rate; a user respiration rate; a user blood oxygen level; a user electrocardiogram (EKG); a user blood cell count; etc.
In FIG. 1B, UE 102 is illustrated as further including: a memory 122 that includes a settings repository. As briefly introduced above (in the discussion of FIG. 1A), according to instances of dynamically reconfigurable criteria 116 and 110, collection engine 114 and omega engine 106 are configured to operate, respectively. Refreshed instances of criteria 110 and 116 (e.g., formatted as one or more XML files) can be included in messages 120. Omega engine 108 is further configured to receive messages 120 during wireless communication sessions 104, respectively, and to store the refreshed instances of reconfigurable criteria 110 and 116 (e.g., formatted as one or more XML files) in settings repository 122. In other words, omega engine 108 is configured to update criteria 110 and 116 with the refreshed instances of criteria 110 and 116.
FIG. 1C is a block diagram illustrating examples of criteria that can be stored in settings repository 122, according to an embodiment of the present invention.
In FIG. 1C, settings repository 122 includes reconfigurable criteria 116 and reconfigurable criteria 110, e.g., represented by one or more XML-formatted files. Criteria 116 can include, e.g., reconfigurable collection-control criteria 142 and reconfigurable storage-control criteria 144. Criteria 110 can include, e.g., reconfigurable retrieval-control criteria 146 and reconfigurable reporting-control criteria 148.
Reconfigurable collection-control criteria 142 can include, e.g., a frequencies-of-collection list 162, alarm criteria 164 and a subject list 166. Reconfigurable storage-control criteria 144 can include, e.g., an overwrite rule 168 and a depth chart 170. Retrieval-control criteria 146 can include, e.g., a withdrawal rule 172. Reporting-control criteria 148 can include, e.g., a frequency-of-initiation setting 174, packaging criteria 176, a recipient setting 178 and emergent criteria 180.
Returning to the discussion of FIG. 1B, as collection engine 114 is configured to operate according to criteria 116, accordingly collection engine 114 is further configured to operate according to collection-control criteria 142 and storage-control criteria 144 (because they are included in criteria 116), which collection engine 114 can read from settings repository 122. If collection engine 114 were to collect data from all of sensors 124-140, the resulting set of data would be a full set of data. Typically, however, collection-control criteria 142 configures collection engine 114 to collect at least some but less than all of the data from sensors 124-140, i.e., a non-empty, proper subset of the full set.
More particularly, subject list 166 (which is included in collection-control criteria 142) defines which ones amongst the various parameters sensed by sensors 124-140 will data representative thereof be collected by collection engine 114. Frequencies-of-collection list 162 (which is included in collection-control criteria 142) defines collection frequencies at which data (representative of parameters sensed by sensors 124-140) is to be collected, respectively, by collection engine 114. In other words, collection engine 114 is further configured to cull such data according to subject list 166 (controls which ones) and frequencies-of-collection list 162 (controls how often).
Subject list 166 can also organize selected ones of the parameters (sensed by sensors 124-140) into groups, respectively. Frequencies-of-collection list 162 indicates the collection frequencies at which data for the groups are to be collected, respectively. Accordingly, collection engine 114, relative to a given one of the groups, is further configured to: cull such data for the selected parameters in the group (as defined by subject list 166) according to the corresponding collection frequency indicated in frequencies-of-collection list 162 so as to produce resulting sets of data for which the data included therein are sampled, e.g., at substantially the same times, respectively.
Memory 112 is of finite storage capacity. If not otherwise constrained, then (over the elapse of a sufficient amount of time) collection engine 114 would be able to accumulate more data, e.g., more instances of each set of data, than could fit in memory 112. To deal with the problem of too much data for too little storage capacity, depth chart 170 and overwrite rule 168 are provided.
Depth chart 170 (which is included in storage-control criteria 144) defines how much data can be accumulated in memory 112 for each of the parameters, respectively. Depth chart 170 can also define how many instances of each set of data can be accumulated in memory 112, the instances of each set being sampled at substantially different times, respectively. According to depth chart 170, collection engine 114 is further configured to accumulate data in memory 112, e.g., instances of each set of data.
Overwrite rule 168 (which is included in storage-control criteria 144) defines how space in memory 112 is to be reused, i.e., how data in memory 112 is to be overwritten. According to overwrite rule 168, collection engine 114 is further configured to overwrite previously-stored instances of data in memory 112 with corresponding newer instances of data. Overwrite rule 168 can be, e.g., FIFO (first in, first out), LIFO (last in, first out), etc.
As also briefly introduced above (in the discussion of FIG. 1A), periodically, omega engine 108 sends the selected portions of collected data in memory 112 to NIB 106. Under unusual circumstances, however, it might be desirable to send data sooner, i.e., to not await elapse of a reporting period. Alternatively, under other unusual circumstances, e.g., it might be desirable to collect more data than is typically collected and/or report more data than is typically reported and/or report the same amount of data that is typically reported albeit at a smaller reporting period.
To facilitate being responsive to such unusual circumstances, alarm criteria 164 can be included in collection-control criteria 142. Examples of alarm criteria include one or more alarm thresholds for the parameters sensed by sensors 124-140, respectively. Collection engine 114 can be further configured to analyze the collected data in memory 112 in terms of alarm criteria 164. If any of alarm criteria 164 are satisfied, then collection engine 114 is further configured to store satisfied ones 165 of alarm criteria 164 in memory 112. According to depth chart 170, collection engine 114 is further configured to accumulate one or more instances of satisfied ones 165 of alarm criteria 164 in memory 112. And according overwrite rule 168, collection engine 114 is further configured to limit, via selective overwriting, previously-stored instances of satisfied ones 165 of alarm criteria 164 that are accumulated in memory 112.
As omega engine 108 is configured to operate according to criteria 110, accordingly omega engine 108 is further configured to operate according to retrieval-control criteria 146 and reporting-control criteria 148 (because they are included in criteria 110), which omega engine 108 can read from settings repository 122.
More particularly, withdrawal rule 172 (which is included in retrieval-control criteria 146) defines which portions of data in memory 112 are to be withdrawn. Withdrawal rule 170 can be, e.g., FIFO (first in, first out), LIFO (last in, first out), etc. Omega engine 108 is further configured to retrieve one or more selected portions 152 of the collected data in memory 112, e.g., one or more of the instances of one or more of the sets of data in memory 112, according to withdrawal rule 172.
As noted, omega engine 106 can send selected portions 152 of the collected data to NIB 106 (via messages 118). Alternatively, the ultimate destination for selected portions 152 of the collected data might not be NIB 106, but instead some other device. For example, where network 100 is an MCN, and the range of network 100 has been extended by networking together NIB 106 and another NIB (not illustrated), then the ultimate destination for selected portions 152 of the collected data might be the other NIB rather than NIB 106. Recipient setting 178 defines which one amongst a plurality of remote hosts (e.g., to continue the example started above, NIB 106 or the other NIB) will receive selected portions 152 of the collected data from omega engine 108.
Frequency-of-initiation setting 174 (which is included in reporting-control criteria 148) defines a frequency at or period over which omega engine 108 should initiate establishing a communications session 104, e.g., for the purpose of performing one or more tasks, at least one of which is reporting portions of collected data. Omega engine 108 is further configured to initiate establishing communications sessions 104 according to frequency-of-initiation setting 174.
Packaging criteria 176 (which are included in reporting-control criteria 148) define, e.g., how selected portions 152 of the collected data in memory 112 are to be included in, e.g., formatted into or packaged into, a given instance of message 118. Omega engine 108 is further configured to configure selected portions 152 of the collected data in memory 112 into a message 118 according to packaging criteria 176.
To further facilitate being responsive to the unusual circumstances discussed above, emergent criteria 180 can be provided. Examples of emergent criteria can include rules (logical constructs) related to alarm thresholds that have been exceeded. For example, an emergent criterion can be a combination of one or more alarm thresholds that were exceeded at substantially the same time, e.g., within a given set of data. For another example, an emergent criterion can be a combination of a given alarm threshold that has been exceed at substantially times, e.g., across different sets of data.
Omega engine 108 can be further configured to read satisfied ones 165 of alarm criteria 164 from memory 112, and analyze the same in terms of emergent criteria 180. If any of emergent criteria 180 are satisfied, then omega engine 108 is further configured to notify NIB 106 appropriately. Such appropriate notification can include, e.g., not awaiting the elapse of a reporting period before attempting to report to NIB 106, sending more portions 152 of collected data than are typically sent to NIB 106, etc.
Again, NIB 106 includes an LTE modem (not illustrated) by which to communicate with UE 102 via a wireless communication session 104. Additionally, NIB 106 further includes computing components (not illustrated), e.g., one or more processor units, one or more communications buses, one or more memories, one or more interfaces, etc.
In FIG. 1B, NIB 106 is illustrated as including an alpha engine 154, a request handler 158 and a memory 160. For ease of illustration, communication session 104 is illustrated as terminating in omega engine 108. Alpha engine 108 and request handler 158 can be implemented, e.g., as executable code stored in one or more of the noted (above) albeit not-illustrated memories in NIB 106 and executed by one or more of the noted (above) albeit not-illustrated processor units of NIB 106.
As NIB 106 can receive selected portions 152 of the collected data from different instances of UE 102, accordingly memory 160 is configured to include multiple collections of UE-specific collected data. Alpha engine 154 is configured: to receive selected portions 152 of the collected data (via messages 118); unpack messages 118; and provide portions 156 of the collected data to request handler 158. Portions 156 can be formatted the same as portions 152, or differently. Request handler 158 is configured to store portions 156 into one of the collections of data in memory 160 that is specific to the corresponding given instance of UE 102.
As the circumstances of network 100 change with the elapse of time, the multiple collections of UE-specific collected data in memory 160 correspondingly will evolve in substantially real time and in reflection of the change in circumstances. Alpha engine 154 or a separate analytical unit (not illustrated in FIG. 1B) can be configured to perform one or more analyses at least upon the data stored in memory 160. Such an analytical unit, for example, could be included in NIB 106 and implemented, e.g., as executable code stored in one or more of the noted (above) albeit not-illustrated (in FIG. 1B) memories in NIB 106 and executed by one or more of the noted (above) albeit not-illustrated (in FIG. 1B) processor units of NIB 106. Relative to the data in memory 160, such analyses can be based upon only the given collection of data that is specific to UE 102, or upon the given collection and one or more ones of other-UE-specific collections of data.
Based upon such analyses, it may be desirable that refreshed instances of criteria 110 and/or 116 be generated, e.g., by alpha engine 154 or the analytical unit. Such instances are described using the adjective “refreshed” because, at the time of their generation, they are newer than the corresponding instances of criteria 110 and/or 116 stored in settings repository 122. In other words, at the time of their generation, refreshed instances of criteria 110 and/or 116 are likely to be better adapted to the circumstances confronting UE 102 than are the corresponding instances of criteria 110 and/or 116 stored in settings repository 122.
Alpha engine 154 is further configured to include the refreshed instances of criteria 110 and/or 116 in messages 120 and then to send messages 120 to UE 102 during wireless communication sessions 104, respectively. Again, omega engine 108 is configured to receive messages 120 and store the refreshed instances of criteria 110 and/or 116 (that were in included in messages 120, respectively) in settings repository 122. As such, UE 102 and the operation thereof are dynamically reconfigurable.
FIG. 1D is a communication-layer diagram illustrating the path of flow during communication session 104 between omega engine 108 of UE 102 and alpha engine 154 of NIB 106, according to an embodiment of the present invention.
As noted, omega engine 108 and collection engine 114 can be implemented, e.g., as executable code stored in one or more of the noted (above) albeit not-illustrated memories in UE 102 and executed by one or more of the noted (above) albeit not-illustrated processor units in UE 102. Alpha engine 108 can be implemented, e.g., as executable code stored in one or more of the noted (above) albeit not-illustrated memories in NIB 106 and executed by one or more of the noted (above) albeit not-illustrated processor units of NIB 106. Such implementations can conform to the communication-layer diagram of FIG. 1D.
More particularly, each of omega engine 108 and alpha engine 154 can have a stack based (in part) on industry-standard layers. The layers illustrated in FIG. 1D represent but one example of combinations of layers that can be included in such stacks, respectively. Such layers, from top to bottom, for example (as illustrated in FIG. 1D), can include: a physical layer; an IP layer; a TCP layer or a UDP layer; an HTTP layer or an HTTPS layer; and a RESTful layer. Alternatively, different combinations of layers could be used in the stack, e.g., a stack that includes as few layers as a physical layer, an IP layer, and a TCP or UDP layer. The RESTful layer is a RESTful web service, where REST is the acronym for representational state transfer. RESTful Webservices are different than REST per se. REST is an architectural approach that can be applied to many things. RESTful web services are a specific approach to web services that utilizes restful aspects of HTTP.
In addition, the stack of each of omega engine 108 and alpha engine 154 can further include another layer on top of the RESTful layer. For example, the additional layer can be a network-specific messaging protocol that is specific to network 100.
FIG. 2A is an example of a state diagram for collection engine 114 according to an embodiment of the present invention.
Collection engine 114 can include sensor objects to capture data from sensors and store the data into memory 112. Illustrated in FIG. 2A are examples of possible states of an exemplary sensor data object as it operates to collect data from sensors 124-140 and store the data in memory 112.
In FIG. 2A, each sensor object begins by executing its internal initialization methods to prepare for sensor data capture. An optional startup phase may be provided during which the sensor object may initialize any hardware sensors for data capture. Upon the next interval for data collection, a check is made to ensure that sufficient space is available in memory 112.
Once new sensor data is captured, a validation method may be used to determine whether the data should be reported. Packaging of the data is performed by each sensor object before it stores the data into memory 112. A common set of methods may be called by each sensor data object for storing the packaged data into memory 112. When a shutdown event occurs, each sensor object must execute any required shutdown methods associated with the gathering of sensor data.
FIGS. 2B and 2C are examples of a state diagrams for omega engine 108 according to embodiments of the present invention, respectively.
Illustrated in FIG. 2B are examples of possible states of omega engine 108 as it operates to retrieve portions 152 of the collected data stored in memory 112 and report portions 152 via messages 118.
Relative to FIG. 2B, FIG. 2C is a more detailed illustration of examples of possible states of omega engine 108 as it operates to retrieve portions 152 of the collected data stored in memory 112 and report portions 152 via messages 118.
Variables mentioned in FIG. 2C include: pendingmsg; last_datetime; msgpending; purgelist; capture_sequence; mycollection; and foundhandlingagent. The variable pendingmsg represents a buffer (not illustrated) that is being used to build message 118 as portions 152 of collected data are concatenated, e.g., because they represent data sampled at substantially the same time. The variable last_datetime is compared against the current capturesequence portion 152 of collected data record to determine if the next portion 152 of collected data was sampled at substantially the same time and thus should be appended as part of message 118.
The variable msgpending is a Boolean flag to indicate that there is a inchoate message 118, i.e., an incomplete message 118 for which the assembly of portions 152 has been started but not completed. The variable purgelist is a list of capture_sequence records that provides details on which device data records (e.g., GPS, Telephony, platform, etc.) should be purged after the pendingmsg (an example of message 118) has been successfully uploaded to NIB 106 from omega engine 108. This list also provides the primary key/id of the capture_sequence records that should be purged from memory 112.
The variable capture_sequence represents the current capture sequence record, i.e., the capture sequence record under consideration. The variable mycollection is a list of all sensor objects, reference to which is made to help facilitate determining which sensor object should be used to decode the UE data record referred by the capture_sequence variable. The variable foundhandlingagent represents the sensor object that is handling the current UE data record.
FIG. 3A is a database-schema diagram illustrating an example of possible relationships amongst data collected and then organized into sets thereof by collection engine 114 according to an embodiment of the present invention.
As explained above, collection engine 114, relative to a given one of the groups, is configured to: cull such data for the selected parameters in the group (as defined by subject list 166) according to the corresponding collection frequency indicated in frequencies-of-collection list 162 so as to produce resulting sets of data for which the data included therein are sampled, e.g., at substantially the same times, respectively. In FIG. 3A, an instance of a set is denoted by a table named capture_sequence.
FIGS. 3B and 3C are a flowchart and a corresponding database-schema diagram illustrating an aspect of the operation of collection engine 114, according to an embodiment of the present invention.
Collection engine 114 can be provided with sensor objects which it uses to collect data from sensors 124-140, respectively. As illustrated in FIG. 3C, for example, such sensor objects include: platform_network( ), platform_device( ), platform_memory( ) and platform_rom( ), which are used to collect data from platform sensor 126; location_gps( ), which is used to collect data from position sensor 124; power_battery( ), which is used to collect data from sensor 132; telephony_4GLTE( ), which is used to collect data from one or more sensors 128.
Illustrated in the flowchart of FIG. 3B are steps that collection engine 114 can execute to select a sensor object corresponding to one of sensors 124-140, respectively, from which data are to be collected.
FIGS. 3D and 3E are a flowchart and a message-assembly diagram illustrating an aspect of the operation of omega engine 108, according to an embodiment of the present invention.
Omega engine 108 is further configured to package portions 152 of collected data into messages 118, e.g., XML-formatted messages. The sensor domains can be provided with corresponding message-component templates (e.g., in XML format, e.g., stored in memory 112), respectively. More particularly, omega engine 108 is further configured to populate such message-component templates with corresponding data from memory 112, and then to combine (e.g., merge) such populated templates. An example of such populating and merging and merging of is illustrated in FIG. 3E. A message-component template includes one or more keywords (variables), e.g., “% colname %”. Among other things, keywords are replaced with the value from the corresponding data field in the corresponding sensor object. Examples of steps that omega engine 108 can execute in correspondence to FIG. 3E are illustrated in FIG. 3D. In FIG. 3D, fields bounded by %, e.g., “% apn %,” are replaced with corresponding domain data.
FIGS. 3F and 3G are a flowchart and a database-schema diagram illustrating an aspect of the operation of collection engine 114, according to an embodiment of the present invention.
Illustrated in the flowchart of FIG. 3F are steps that collection engine 114 can execute to overwrite data in memory 112. FIG. 3G is database-schema diagram counterpart to the steps of FIG. 3F.
FIGS. 3H, 3I and 3J are a database-schema diagram, a flowchart and a database-schema diagram, respectively, illustrating an aspect of the operation of collection engine 114, according to an embodiment of the present invention.
Illustrated in the database-schema diagram of FIG. 3H is the addition of selected data to memory 112. Illustrated in the flowchart of FIG. 3I are steps that collection engine 114 can execute to write such selected data into memory 112. FIG. 33 is database-schema diagram counterpart to the steps of FIG. 3I.
As will be discussed in terms of FIGS. 4-6, omega engine 108 and alpha engine 154 exhibit a client-server relationship. More particularly, omega engine 108 and alpha engine 154 exhibit a specific type of client-server relationship, namely a taskee-client—taskor-server, i.e., they relate as taskee-client and taskor-server, respectively. Omega engine 108 is a client that requests alpha engine 154 to serve tasks to it, i.e., to provide it with tasks which either omega engine 108, collection engine 114 or another component of UE 102 will perform. As such, omega engine 108 is a taskee; hence omega engine 108 is referred to as a taskee-client. As the entity that assigns tasks to another entity, i.e., that is a taskor, alpha engine 154 is referred to as a taskor-server.
As a taskee-client, omega engine 108 is further configured to: query the taskor server (alpha engine 154) for an unspecified one amongst a plurality of predetermined tasks, with a consequent selection of a given one from amongst the plurality tasks being an action performed by the taskor-server (alpha engine 154); receive an indication of the given task from the taskor-server (alpha engine 154); facilitate execution of the given task on UE 102, e.g., via collection engine 114; and report execution-results of the given task to the taskor-server (alpha engine 154).
As a taskor-server, alpha engine 154 is further configured to: receive a query from the taskee-client (omega engine 108) for an unspecified one amongst the plurality of tasks; make a selection of a given one from amongst the plurality of predetermined tasks; indicate the selected task to the taskee-client (omega engine 108); and receive a report including execution results for the selected task from the taskee-client (omega engine 108).
FIG. 4 is a flow diagram of interactions that can occur in a taskee-client—taskor-server relationship, according to an embodiment of the present invention.
In FIG. 4, flow proceeds through four phases: a wait/poll-interval phase 402; a connection phase 404; an identification phase 406; and a task query and delegation phase 408. Beginning with wait/poll-interval phase 402, at block 410, the taskee-client (omega engine 108) waits while a connection interval elapses. Flow proceeds from block 410 to block 412, thereby entering connection phase 404. At block 412, the taskee-client (omega engine 108) initiates and establishes a communication session 104 with the taskor-server (alpha engine 154).
Flow proceeds from block 412 to block 414, thereby entering identification phase 406. At block 414, the taskee-client (omega engine 108) transmits profile information and a current state of UE 102 to the taskor-server (alpha engine 154). Flow proceeds from block 414 to block 416, where the taskor-server (alpha engine 154) receives the profile and current state information regarding taskee-client (omega engine 108), and stores the same in memory, e.g., memory 160. Flow proceeds from block 416 to block 417, where the taskor-server (alpha engine 154) sends a transmission acknowledgment (ACK) to the taskee-client (omega engine 108). Flow proceeds from block 417 to block 418, where the taskee-client (omega engine 108) receives the transmission acknowledgment (ACK) from the taskor-server (alpha engine 154).
Flow proceeds from block 418 to block 420, thereby entering task query and delegation phase 408. At block 418, the taskee-client (omega engine 108) queries the taskor-server (alpha engine 154) for an unspecified one amongst a plurality of predetermined tasks. Flow proceeds from block 420 to block 422, where the taskor-server (alpha engine 154) receives the query. Flow proceeds from block 422 to block 424, where the taskor-server (alpha engine 154) determines what actions should be executed (e.g., are scheduled to be executed and/or are desirable under the current circumstances) by UE 102 at this time. Flow proceeds from block 424 to block 426, where the taskor-server (alpha engine 154) builds an action request message, i.e., a task, and returns (sends) the task to the taskee-client (omega engine 108). Flow proceeds from block 426 to block 428, where the taskee-client (omega engine 108) evaluates the task for which it is the taskee.
Flow proceeds from block 428 to decision block 430, where the taskee-client (omega engine 108) decides if the appropriate action for execution of the task is to do nothing. If the outcome of decision block 430 is yes, then flow proceeds from decision block 430 and loops back to block 410, thereby reentering wait/poll-interval phase 402. But if the outcome of decision block 430 is no, then flow proceeds from decision block 430 to block 432, where the taskee-client (omega engine 108) dispatches one or more requests to one or more amongst a plurality of handling objects on UE 102 that are appropriate for carrying out the execution of the task. Upon completion of the task by the one or more handling objects, the taskee-client (omega engine 108) sends a task-completion message, including a set of results (if any), to the taskor-server (alpha engine 154). Flow proceeds from block 432 to block 434, where the taskor-server (alpha engine 154) receives the task-completion message including the set of results (if any).
Flow proceeds from block 434 to block 435, where the taskor-server (alpha engine 154) sends a transmission acknowledgment (ACK) to the taskee-client (omega engine 108). Flow proceeds from block 434 to block 436, where the taskee-client (omega engine 108) receives the transmission acknowledgment (ACK) from the taskor-server (alpha engine 154). Flow proceeds from block 436 and loops back to block 420.
FIG. 5 is an example of a UML (uniform modeling language) sequence diagram, according to an embodiment of the present invention, that is a counterpart to the flowchart of FIG. 4.
FIG. 6 is an example of a state diagram for a taskee-client (omega engine), according to an embodiment of the present invention.
Illustrated in FIG. 6 are examples of possible states of the taskee-client (omega engine 108) as it operates to request and execute tasks from the taskor-server (alpha engine 154).
FIG. 7 is a block diagram of two instances of node 102, e.g., instances of UE, and an alternative remote host 706, according to an embodiment of the present invention.
Similar to NIB 106 (discussed above), host 706 can be, e.g., a base station or a network-in-a-box (NIB), respectively, that is operational in a wireless communication network, e.g., a mobile-telephony network or a mobile cellular network (MCN) communication system. Among other things, NIB 706 can communicate wirelessly with multiple instances of node 102 via wireless communication sessions 104, respectively. Among other things, NIB 106 includes a wireless interface, e.g., an LTE (Long Term Evolution) modem (not illustrated), a WiFi modem (not illustrated), etc., by which to communicate with nodes 102 via wireless communication sessions 104, respectively.
In contrast to NIB 106, NIB 107 includes an onboard-NIB sensing arrangement 750 that includes components corresponding to those of UE 102, respectively, including: an alpha engine (taskor server) 754; an omega engine 708; dynamically reconfigurable criteria 710 by which the operation of omega engine 708 is controlled; a memory 712 to store collected data locally; a sensor-data collection engine 714; dynamically reconfigurable criteria 116 by which the operation of collection engine 714 is controlled; operational components, various sensors; etc. Such sensors sense parameters (at least some of which are operational parameters of the operational components) and sample the same to thereby generate data representing the sampled values, respectively. As such, alpha engine 754 not only can receive selected portions of collected data from instances of node 102 via wireless communication sessions 104, respectively, but can also selected portions of collected data from its onboard-NIB sensing circuitry 750 via one or more wired connections.
Alternatively, a client-server computer architecture can include: a first host; and a taskor server executable on the first host. The taskor server can be configured to: receive a query from a taskee client for an unspecified one amongst a plurality of tasks; make a selection of a given one from amongst the plurality of tasks; indicate the selected task to the taskee client; and receive a report including execution results for the selected task from the taskee client. For such an architecture, the receiving of the query, the making of the selection, the indicating of the task and the receiving of the report can comprise an executable loop, with the taskor server being further configured to: receive a request to start a session from the taskee client as a precursor to entering the loop; and receive, during the session but after completion of an nth iteration of the loop, another query from the taskee client for another unspecified one amongst the plurality of tasks, thereby invoking an (n+1)th iteration of the loop. Such a taskor server can be further configured to: receive, during the session but after completing the nth iteration of the loop, an end-session request from the taskee client to end the session; and acknowledge the end-session request thereby causing the taskee client to bring about the end of the session. For example, one of the plurality of tasks is an end-session task, and the taskor server is further configured to: select the end-session task thereby causing the taskee client to bring about the end of the session. Such architecture can further comprise a taskee client executable on the first host and configured to: query the taskor server for an unspecified one amongst a plurality of tasks, a consequent selection of a given one from amongst the plurality tasks being performable by the taskor server; receive an indication of the given task from the taskor server; facilitate execution of the given task on the first host; and report execution-results of the given task to the taskor server. The taskee client can be an omega engine; and the architecture can further comprise: an onboard sensing arrangement including sensors to sample values of parameters, respectively; a memory; and a collection engine configured to selectively collect data representing at least some of the sampled values, respectively, and store the collected data in the memory; and an omega engine configured to retrieve selected portions of the collected data from the memory, and send the selected portions to a remote host. At least one of the collection, the storage, the retrieval and the sending are performable according to one or more reconfigurable collection-control criteria, one or more reconfigurable storage-control criteria, one or more reconfigurable retrieval-control criteria and one or more reconfigurable reporting-control criteria, respectively, stored in the memory.
Further in the alternative, a client-server computer architecture can comprise: a first host and a taskee client executable on the first host and configured to: query a taskor server for an unspecified one amongst a plurality of tasks, a consequent selection of a given one from amongst the plurality tasks being performable by the taskor server; receive an indication of the given task from the taskor server; facilitate execution of the given task on the first host; and report execution-results of the given task to the taskor server. The querying for the unspecified task, the receiving the indication, the facilitating of task-execution and the reporting of execution-results can comprise an executable loop, with the taskee client being further configured to: request the taskor server to start a session as a precursor to entering the loop; and query the taskor server, during the session but after completion of an nth iteration of the loop, for another unspecified one amongst the plurality of tasks, thereby invoking an (n+1)th iteration of the loop. The taskee client can be further configured to: transmit to the taskor server, during the session but after completing the nth iteration of the loop, an end-session request for ending the session; receive an acknowledgement of the end-session request from the taskor server; and bring about the end of the session. One of the plurality of tasks can be an end-session task, with the taskee client being further configured to: bring about the end of the session upon receiving the end-session task from the taskor server.
While the present invention has been described in the context of a network 100 of wireless parameter-sensing nodes, those skilled in the art will appreciate that the mechanism of the present invention is capable of being implemented and distributed in the form of a computer-usable medium (in a variety of forms) containing computer-executable instructions, and that the present invention applies equally regardless of the particular type of computer-usable medium which is used to carry out the distribution. An exemplary computer-usable medium is coupled to a computer such the computer can read information including the computer-executable instructions therefrom, and (optionally) write information thereto. Alternatively, the computer-usable medium may be integral to the computer. When the computer-executable instructions are loaded into and executed by the computer, the computer becomes an apparatus for practicing the invention. For example, when the computer-executable instructions are loaded into and executed by a general-purpose computer, the general-purpose computer becomes configured thereby into a special-purpose computer. Examples of suitable computer-usable media include: volatile memory such as random access memory (RAM); nonvolatile, hard-coded or programmable-type media such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs); recordable-type and/or re-recordable media such as floppy disks, hard disk drives, compact discs (CDs), digital versatile discs (DVDs), etc.; and transmission-type media, e.g., digital and/or analog communications links such as those based on electrical-current conductors, light conductors and/or electromagnetic radiation.
1. A wireless parameter-sensing node in a network thereof, the parameter-sensing node comprising:
sensors to sample values of parameters, respectively;
a collection engine configured to:
selectively collect data representing at least some of the sampled values, respectively; and
store the collected data in the memory;
an omega engine configured to:
receive, from a remote host, a data-transfer assignment to send at least some of the collected data;
retrieve, in response to the data-transfer assignment from the remote host, selected portions of the collected data from the memory; and
send, in response to the data-transfer assignment from the remote host, the selected portions to the remote host;
at least one of the collection, the storage, the retrieval and the sending are performable according to one or more reconfigurable collection-control criteria, one or more reconfigurable storage-control criteria, one or more reconfigurable retrieval-control criteria and one or more reconfigurable reporting-control criteria, respectively, stored in the memory;
the collection engine is further configured to store by:
overwriting previously-stored data in the memory with parameter-corresponding new data, respectively, as needed;
the one or more storage-control criteria include at least one of:
a depth-chart defining how much data can be accumulated in the memory for each of the parameters, respectively, and
one or more overwrite rules defining how data for the parameters are to be overwritten in the memory, respectively; and
the collection engine is further configured to:
accumulate and overwrite according to the depth chart and the one or more overwrite rules, respectively.
2. The wireless parameter-sensing node of claim 1, wherein the reconfigurable collection-control criteria include at least one of:
a subject list of which ones amongst the parameters will data representative thereof be collected by the collection engine; and
a frequencies-of-collection list of collection frequencies at which the data are to be collected, respectively, by the collection engine; and
cull data according to the subject list and the frequencies-of-collection list.
3. The wireless parameter-sensing node of claim 2, wherein:
the subject list organizes selected ones of the parameters into groups, respectively;
the frequencies-of-collection list indicates the collection frequencies at which data for the groups are to be collected, respectively;
the collection engine, relative to a given one of the groups, is further configured to:
cull data for the selected parameters in the group according to the corresponding collection frequency indicated in the frequencies-of-collection list so as to produce resulting sets of data for which the data included therein are sampled at substantially the same times, respectively.
4. The wireless parameter-sensing node of claim 3, wherein:
accumulating multiple instances of a given one of the sets of data in the memory, the sets being sampled at substantially different times, respectively;
the reconfigurable retrieval-control criteria include:
a withdrawal rule defining which portions of data are to be withdrawn from the memory; and
the omega engine is further configured to retrieve the selected portions of the collected data by:
withdrawing one or more of the instances of a given one of the sets of data in the memory according to the withdrawal rule.
5. The wireless parameter-sensing node of claim 1, wherein:
the reconfigurable reporting-control criteria include at least one of:
a frequency-of-initiation setting;
one or more packaging criteria; and
a recipient setting defining which one amongst a plurality of remote hosts will receive the selected portions of the collected data; and
the omega engine is further configured to:
initiate a wireless communication session with the remote host according to the frequency-of-initiation setting;
selectively package the collected data according to the one or more packaging criteria; and
transmit the packaged data according to the recipient setting.
6. The wireless parameter-sensing node of claim 1, wherein the omega engine is further configured to:
receive, from the remote host, refreshed versions of at least one of the collection-control criteria, the storage-control criteria, the retrieval-control criteria and the reporting-control criteria, respectively, and
update at least one of the collection-control criteria, the storage-control criteria, the retrieval-control criteria and the reporting-control criteria stored in the memory according to the refreshed versions corresponding thereto, respectively.
7. The wireless parameter-sensing node of claim 1, wherein:
the remote host is a taskor server; and
the omega engine is a corresponding taskee client.
8. The wireless parameter-sensing node of claim 7, wherein the omega engine, as the taskee client, is further configured to:
query the taskor server for an unspecified one amongst a plurality of tasks, a consequent selection of a given one from amongst the plurality tasks being performable by the taskor server;
receive an indication of the given task from the taskor server;
facilitate execution of the given task on the first host; and
report execution-results of the given task to the taskor server;
wherein one of the plurality tasks selectable by the taskor server for the taskee client is the data-transfer assignment.
9. The wireless parameter-sensing node of claim 1, wherein:
the reconfigurable collection-control criteria include:
alarm criteria;
the reporting criteria include:
emergent criteria;
the collection engine is configured to:
analyze the collected data in terms of the alarm criteria, respectively; and
notify the omega engine when one or more of the alarm criteria are satisfied; and
compare the satisfied alarm criteria against the emergent criteria, respectively; and
send an alert to the remote host based on the results of the comparison.
10. The wireless parameter-sensing node of claim 9, wherein the omega engine is further configured to:
receive at least one of refreshed alarm criteria and refreshed emergent criteria; and
update at least one of the alarm criteria and update the emergent criteria stored in the memory according to the refreshed alarm criteria and the refreshed emergent criteria, respectively.
11. The wireless parameter-sensing node of claim 1, wherein:
the remote host is one of a base station and a network-in-a-box in a mobile telephony network; and
the parameter-sensing node is a mobile device connected wirelessly to the remote host.
12. A client-server computer architecture comprising:
a taskor server executable on the first host and configured to:
receive a query from a taskee client for an unspecified one amongst a plurality of tasks;
make a selection of a given one from amongst the plurality of tasks;
indicate the selected task to the taskee client; and
receive a report including execution results for the selected task from the taskee client.
13. The client-server computer architecture of claim 12, wherein:
the taskee client is executable on a second host remote from the first host.
14. The client-server computer architecture of claim 13, wherein:
the first host is a one of a base station and a network in a box device in a mobile telephony network; and
the second host is a mobile device connected wirelessly to the remote host.
15. A client-server computer architecture comprising:
a taskee client executable on the first host and configured to:
query a taskor server for an unspecified one amongst a plurality of tasks, a consequent selection of a given one from amongst the plurality tasks being performable by the taskor server;
report execution-results of the given task to the taskor server.
16. The client-server computer architecture of claim 15, wherein:
the taskor server is executable on a second host remote from the first host.
17. The client-server computer architecture of claim 16, wherein:
the second host is one of a base station and a network-in-a-box in a mobile telephony network; and
the first host is a mobile device connected wirelessly to the remote host.
18. A method of operating at least one wireless parameter-sensing node in a network thereof, the at least one node including sensors to sample values of parameters, respectively, and a memory, the method comprising:
selectively collecting data representing at least some of the sampled values, respectively; and
storing the collected data in the memory;
receiving, from a remote host, a data-transfer assignment to send at least some of the collected data;
retrieving, in response to the data-transfer assignment from the remote host, selected portions of the collected data from the memory;
sending, in response to the data-transfer assignment from the remote host, the selected portions to the remote host;
retrieving, from the memory, at least one of the following:
one or more reconfigurable storage-control criteria;
one or more reconfigurable retrieval-control criteria; and
one or more reconfigurable reporting-control criteria, respectively; and
performing at least one of the collection, the storage, the retrieval and the sending according to the one or more reconfigurable collection-control criteria, one or more reconfigurable storage-control criteria, one or more reconfigurable retrieval-control criteria and one or more reconfigurable reporting-control criteria, respectively, wherein:
a depth-chart defining how much data can be accumulated in the memory for the parameters, respectively; and
the accumulating and the overwriting are performable according to the depth chart and the one or more overwrite rules, respectively.
19. The method of claim 18, wherein the reconfigurable collection-control criteria include at least one of:
the selectively collecting includes:
culling data according to the subject list and the frequencies-of-collection list.
the selectively collecting, relative to a given one of the groups, further includes:
performing the culling of the selected parameters in the group according to the corresponding collection frequency indicated in the frequencies-of-collection list so as to produce resulting sets of data for which the data included therein are sampled at substantially the same times, respectively.
the retrieving of the selected portions includes:
initiating a wireless communication session with the remote host according to the frequency-of-initiation setting;
selectively packaging the collected data according to the one or more packaging criteria; and
transmitting the packaged data according to the recipient setting.
receiving, from the remote host, refreshed versions of at least one of the collection-control criteria, the storage-control criteria, the retrieval-control criteria and the reporting-control criteria, respectively, and
updating at least one of the collection-control criteria, the storage-control criteria, the retrieval-control criteria and the reporting-control criteria stored in the memory according to the refreshed versions corresponding thereto, respectively.
operating the parameter-sensing node as a corresponding taskee client.
25. The method of claim 24, wherein the operating as the taskee client further comprises:
querying the taskor server for an unspecified one amongst a plurality of tasks, a consequent selection of a given one from amongst the plurality tasks being performable by the taskor server;
receiving an indication of the given task from the taskor server;
facilitating execution of the given task on the parameter-sensing node; and
emergent criteria; and
analyzing the collected data in terms of the alarm criteria, respectively;
notifying the omega engine when one or more of the alarm criteria are satisfied; and
comparing the satisfied alarm criteria against the emergent criteria, respectively; and
sending an alert to the remote host based on the results of the comparison.
receiving at least one of refreshed alarm criteria and refreshed emergent criteria; and
updating at least one of the alarm criteria and updating the emergent criteria stored in the memory according to the refreshed alarm criteria and the refreshed emergent criteria, respectively.
operating the parameter-sensing node as a corresponding mobile device connected wirelessly to the remote host.
US14/556,469 2014-12-01 2014-12-01 Wireless parameter-sensing node and network thereof Active 2035-10-16 US9848458B2 (en)
US14/556,469 US9848458B2 (en) 2014-12-01 2014-12-01 Wireless parameter-sensing node and network thereof
US20160157113A1 US20160157113A1 (en) 2016-06-02
US9848458B2 true US9848458B2 (en) 2017-12-19
ID=56080051
US14/556,469 Active 2035-10-16 US9848458B2 (en) 2014-12-01 2014-12-01 Wireless parameter-sensing node and network thereof
US (1) US9848458B2 (en)
US6694156B2 (en) 2000-01-26 2004-02-17 Samsung Electronics Co., Ltd. Apparatus and method for displaying available service time in mobile telephones
US20090073973A1 (en) * 2007-09-13 2009-03-19 Bup-Joong Kim Router having black box function and network system including the same
US7908440B2 (en) 2007-08-09 2011-03-15 Intel Corporation Simultaneous personal sensing and data storage
US20120191476A1 (en) * 2011-01-20 2012-07-26 Reid C Shane Systems and methods for collection, organization and display of ems information
US8325053B2 (en) 2009-03-10 2012-12-04 JCJ Inc. Personal fall protection monitoring system
US20120324111A1 (en) * 2011-06-16 2012-12-20 Ron Barzel Task allocation in a computer network
US20120329439A1 (en) 2011-06-24 2012-12-27 Hon Hai Precision Industry Co., Ltd. Mobile device capable of automatically switching operation profiles and method thereof
US20130027541A1 (en) 2002-07-08 2013-01-31 American Underwater Products, Inc. Dive computer with global positioning system receiver
US20130066951A1 (en) * 2009-11-18 2013-03-14 Yissum Research Development Company Of The Hebrew University Of Jerusalem Communication system and method for managing data transfer through a communication network
US20130255681A1 (en) * 2012-03-30 2013-10-03 Nellcor Puritan Bennett Llc Data collection system and method using parametric-based sampling rates
US20130257650A1 (en) 2012-03-27 2013-10-03 Casio Computer Co., Ltd. Altitude information acquiring device and altitude information acquiring system
US8589089B2 (en) 2010-11-29 2013-11-19 Blackberry Limited System and method for detecting and measuring impacts in handheld devices using an acoustic transducer
WO2014049789A1 (en) 2012-09-27 2014-04-03 株式会社メディキタス Biometric information transmission device
US8798582B2 (en) 2011-12-12 2014-08-05 Sitronix Technology Corp. Mobile device having a protection mechanism for sensitive information
US20140266696A1 (en) * 2013-03-15 2014-09-18 Covidien Lp Systems and methods for identifying a medically monitored patient
2014-12-01 US US14/556,469 patent/US9848458B2/en active Active
US20140074979A1 (en) 2008-09-29 2014-03-13 STMicoelectronics International N.V. Web based smart sensor network tracking and monitoring system
"Altiris™ IT Management Suite 7.1 SP2 from Symantec™ Planning and Implementation Guide," Created Oct. 19, 2011, Updated: Jan. 28, 2013, URL= http://www.symantec.com/docs/DOC4827.
"Improved noncontact optical sensor for detection of glucose concentration and indication of dehydration level," Nisan Ozana et al., Biomedical Optics Express, vol. 5, Issue 6, pp. 1926-1940, 2014, URL=http://dx.doi.org/10.1364/BOE.5.001926 Alternate URL= http://www.opticsinfobase.org/boe/viewmedia.cfm?uri=boe-5-6-1926&seq=0.
"What Tasks "Server" Are you Using?," Michael Linengerger, Created Apr. 26, 2011, Updated Mar. 3, 2014, URL= http://www.michaellinenberger.com/blog/what-tasks-server-are-you-using/.
US20160157113A1 (en) 2016-06-02
JP5989899B2 (en) 2016-09-07 M2M devices and methods for 3GPP and ETSI machine-to-machine (M2M) interconnections
CN104869528B (en) 2018-10-02 Device and method in wireless network for the attachment of network initiation and without registration paging
US10211685B2 (en) 2019-02-19 Systems and methods for real or near real time wireless communications between a wireless power transmitter and a wireless power receiver
ES2687112T3 (en) 2018-10-23 System and method of service interruption compensation in cells in cellular systems
TWI577200B (en) 2017-04-01 For improving the robustness of the call is repeated for an extended period of call cycles
US20130182697A1 (en) 2013-07-18 Method and apparatus for maintaining access point information
EP2507644A1 (en) 2012-10-10 Method and apparatus for on-device positioning using compressed fingerprint archives
CN105075316A (en) 2015-11-18 Wireless local area network (WLAN) traffic load measurement provisioning to wireless cellular networks
US8385226B2 (en) 2013-02-26 Radio fingerprint method in a positioning node for providing geographic region data
TW201448640A (en) 2014-12-16 Access network discovery and selection
TW201242399A (en) 2012-10-16 RSSI-based indoor positioning in the presence of dynamic transmission power control access points
Brouwers et al. 2012 Pogo, a middleware for mobile phone sensing
US9146595B2 (en) 2015-09-29 Systems and methods for remotely monitoring or controlling a battery
WO2013124541A1 (en) 2013-08-29 Method and apparatus for dynamic server|client controlled connectivity logic
US8599767B2 (en) 2013-12-03 Method and apparatus for scanning multi-mode wireless communication environments
Owner name: OCEUS NETWORKS, INC., VIRGINIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROW, JAMES THOMAS, II;UELK, JOSEPH LAWRENCE;JAFFERI, FARAZ H;AND OTHERS;SIGNING DATES FROM 20141021 TO 20141029;REEL/FRAME:034361/0858