WO2017053059A1 - Efficient storage and retrieval for wearable-device data - Google Patents
Efficient storage and retrieval for wearable-device data Download PDFInfo
- Publication number
- WO2017053059A1 WO2017053059A1 PCT/US2016/050445 US2016050445W WO2017053059A1 WO 2017053059 A1 WO2017053059 A1 WO 2017053059A1 US 2016050445 W US2016050445 W US 2016050445W WO 2017053059 A1 WO2017053059 A1 WO 2017053059A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- data
- digital memory
- stored
- list
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2358—Change logging, detection, and notification
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2255—Hash tables
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
Definitions
- Wearable devices such as activity trackers, are becoming increasingly popular. These wearable devices typically include sensors configured to measure quantities from which inferences about a wearer's physical condition and physical activity levels may be made. Some examples of sensors that may be used in wearable devices include
- accelerometers e.g., heart rate monitors (e.g., optical heart rate monitors), thermometers, global positioning system (GPS) locators, bioimpedance sensors, galvanic skin response sensors, ultraviolet (UV) sensors, and optical sensors (e.g., that use light-emitting diodes (LEDs)) that measure blood oxygenation or antioxidant levels.
- heart rate monitors e.g., optical heart rate monitors
- thermometers e.g., optical heart rate monitors
- GPS global positioning system
- bioimpedance sensors e.g., bioimpedance sensors, galvanic skin response sensors, ultraviolet (UV) sensors, and optical sensors (e.g., that use light-emitting diodes (LEDs)) that measure blood oxygenation or antioxidant levels.
- UV ultraviolet
- LEDs light-emitting diodes
- wearable devices It is convenient for these wearable devices to be small so that they can be worn throughout a wide range of activities without unduly impeding the wearer's mobility or comfort. Hence, these wearable devices are often small enough to be worn in a sleeve for the leg, an armband, a chest strap, a belt, a shoe, a clip-on assembly, or a wristband.
- sensors of the wearable device can collect desired measurements at a desired rate.
- the measurements taken during a specific time period may be used to illustrate trends over time.
- measurements may be suitable display in a scatterplot (e.g., of the quantity measured plotted against time). Methods such as regression and interpolation may also be applied to the measurements in order to estimate rates of change and trends over time.
- Various types of analysis may be applied to the measurements in order to estimate desired quantities that may not be immediately measurable using the sensors (e.g., calories burned).
- FIG. 1 illustrates an example of a first level (LI) list of an indexing/hashing structure in accordance with an example
- FIG. 2 illustrates a detailed example of a second-level (L2) list in accordance with an example
- FIGs. 3a-b illustrate an example of how an indexing/hashing structure may be expanded in accordance with an example
- FIGs. 4a-e illustrate an exemplary manner in which an order of LI nodes in an
- LI list may be updated in accordance with an example
- FIGs. 5a-c illustrate states of a hybrid indexing/hashing structure for coordinating data storage between local digital memory and remote digital memory in accordance with an example
- FIG. 6 illustrates functionality for storing data measurements for efficient retrieval in accordance with an example
- FIG. 7 illustrates functionality for retrieving a data measurement from digital memory in accordance with an example
- FIG. 8 illustrates functionality for coordinating storage of data measurements between local digital memory and a remote data store in accordance with an example
- FIG. 9 provides an example illustration of a wireless device in accordance with an example.
- a large number of measurements may be taken by the sensors of a wearable device over the course of several hours, days, or months, especially if the rate at which measurements are taken is relatively high.
- the wearable device's small size may provide limited physical space for physical memory on which the measurements may be stored. Consequently, a wearable device may be configured to cache a small amount of measurement data and transfer other measurement data to another device that has more available physical memory.
- a wearable device may transfer measurement data to another device, such as a user equipment (UE) (e.g., a mobile cellular phone), a computer (e.g., a laptop or a desktop), or a remote data store (e.g., a cloud service for data storage).
- UE user equipment
- a computer e.g., a laptop or a desktop
- a remote data store e.g., a cloud service for data storage
- the measurement data may be transferred wirelessly (e.g., using Bluetooth, WiFi, or 3GPP technology) or via a wired connection (e.g., using a universal serial port (USB) cable or an auxiliary input cable).
- sensors that take measurements of interest may be part of a UE that is not wearable device. In such cases, the transfer of measurement data from sensors to physical memory of the UE may occur through circuitry of the UE itself.
- wearable devices and UEs are not mutually exclusive, but rather, a device may be both a wearable device and a UE.
- a UE and a sensor may be devices that are considered to be part of a system for storing or retrieving
- the senor may serve as the device within the system that takes measurements of a quantity of interest and conveys the measurements to the UE.
- the UE may have an integrated sensor therein and in other examples the sensor device may be a separate and independent device from the UE.
- the measurements taken by the sensor may be conveyed wirelessly or through a wired connection (e.g., an auxiliary cable).
- the UE may serve as a device within the system that includes one or more processors (e.g., application processors or baseband processors) that are configured to apply methods described herein in order to determine where and how to store the measurements in order to facilitate efficient storage and retrieval.
- a system may further include a cloud or other remote data store that can communicate with the UE.
- the system can include a UE with an integrates sensor and a remote data store that can communicate with the UE.
- the system can include a sensor that is capable of communicating with a separate UE, and a remote data store that is capable of communicating with the UE.
- a UE such as a smart phone may store some measurement data
- UEs are typically also relatively small and therefore have relatively limited digital storage space.
- the UE may be used for many other purposes (e.g., making telephone calls, surfing the internet, streaming media, playing video games, etc.) that require use of the UE's limited storage space.
- UEs that store measurement data from sensors may therefore be configured to transfer measurement data via a network connection to a cloud data storage system wherein digital data may be stored across one or more servers.
- Measurement data may even be uploaded continuously through streaming so that little or no measurement data is stored locally at the UE (though this may lead to unnecessary use of battery power and bandwidth resources).
- a single interface may be provided whereby a user can query the measurement data that is stored both locally and remotely.
- separate interfaces may be used for local data retrieval from the UE's digital memory and for remote data retrieval from the cloud storage system, respectively.
- a user may wish to retrieve measurement data from storage for display and inspection on the UE.
- the user may request that measurement data from a certain day, for example, be displayed in a scatterplot so that the user can see activity patterns for that day. If the measurement data for that day is stored on the UE, the measurement data may be retrieved relatively quickly.
- the measurement data for that day has been transferred to a cloud storage system and removed from local memory, it may take an inconvenient amount of time to download the measurement data from the cloud storage system to the UE. In areas where cellular or WiFi coverage is unavailable, the user may be unable to download the measurement data until the UE is moved to a location where coverage is available. Furthermore, if separate interfaces are used to retrieve local data and remote data, the user may be obliged to navigate through both interfaces to download desired portions of the desired measurement data.
- measurement data can be stored locally at the UE.
- measurement data is selected for local storage based on recentness, based on the type of data structure (e.g., queue or stack) used to cache the data locally, and based on the time intervals at which data is uploaded to the cloud storage system.
- the approaches described above provide no solution whereby a UE may preemptively identify and download measurement data from the different time frames. Hence, unless the user happens to conveniently request measurement data from the exact time frame whose measurements are locally stored, the user may have to wait for longer periods of time to access desired measurement data.
- a user is a runner who is trying to identify an optimal rate at which to increase a distance for daily runs without causing an overuse injury (e.g., shin splints).
- the runner wears an activity tracker with various sensors on a daily basis and the activity tracker sends measurement data to the user's smartphone.
- the smartphone stores the most recent data locally in a FIFO scheme and periodically uploads the rest of the
- Systems and methods of the present disclosure provide a more intelligent solution for coordinating the storage of measurement data between a UE and a cloud storage system.
- Invention embodiments provide a hybrid hashing scheme that enables measurement data to be accessed quickly and prioritized for local storage based on user's querying behavior.
- Some embodiments may include an indexing/hashing structure with lists at two levels.
- FIG. 1 illustrates an example of first level (LI) list 100 of an indexing/hashing structure in accordance with an example.
- the LI list 100 may comprise LI nodes 102a-n.
- the nodes 102a-n are described as objects (e.g., in an object-oriented programming language such as Java or C++).
- the LI nodes 102a-n may also be of any composite data type (e.g., Structs in C or records in TurboPascal) that permits the LI nodes 102a-n to be designed as described.
- lower case letters are used for convenience in identifying the three nodes shown, it is to be understood that the LI list 100 may generally include an arbitrary number of LI nodes.
- Each of the LI nodes 102a-n may comprise instance variables such as a priority counter, a size, a node identification (ID) number, and a pointer to a respective second level (L2) list 104a-n associated with the respective node.
- the priority counter, the size, and the node ID may be of one or more primitive numerical data types.
- Each size instance variable may indicate an amount of digital memory used to store measurement data associated with the respective LI node.
- Each priority counter instance variable may indicate a number of times that measurement data in the respective L2 list associated with the respective LI node has been queried or accessed.
- the value of a priority counter instance variable may also be determined based on other types of schemes (e.g., wherein time elapsed since an LI node's L2 list was last accessed is used to determine a weighting and outlier handling is provided).
- the LI nodes 102a-n may be sorted in the LI list 100 according to their respective priority counter instance variables. While a pointer is depicted as an instance variable for each node shown in FIG. 1, it is to be understood that another type of indicator of a digital -memory address (e.g., a reference) may also be used.
- Each of the LI nodes 102a-n may be associated with a respective type of measurement data received from sensors.
- one of the LI nodes 102a-n may be associated with heart rate measurements, while another might be associated with temperature measurements, accelerometer measurements, or another type of measurement.
- different LI nodes might represent subtypes of more general types of measurement data.
- an indexing function may be provided. The indexing function may be used to indicate list indices (e.g., array indices) or node ID numbers of LI nodes in the LI list 100 that are associated with subtypes of a general type.
- the LI nodes 102a-n in the LI list may be sorted according to their respective priority counter instance variable values. Though FIG. 1 illustrates that the LI nodes 102a-n are sorted in descending order from left to right, it is to be understood that the functionality described herein may also be accomplished with trivial adjustments if the LI nodes 102a-n were sorted in ascending order.
- FIG. 2 illustrates a detailed example of an L2 list 200 in accordance with an example.
- the L2 list 200 may be a hash table.
- the L2 list 200 may comprise L2 nodes 202a- k. Each of the L2 nodes 202a-k may correspond to a hash-table bucket of the L2 list 200.
- the L2 nodes 202a-k are described as objects (e.g., in an object-oriented programming language such as Java or C++). However, the L2 nodes 202a-k may also be of any composite data type (e.g., Structs in C or records in TurboPascal) that permits the L2 nodes 202a-k to be designed as described. In addition, while lower case letters are used for convenience in identifying the three nodes shown, it is to be understood that the L2 list 200 may generally include an arbitrary number of L2 nodes.
- Each L2 node 202a-k may comprise instance variables such as a node identification (ID) number (which may also be a binary hash key associated with the respective L2 node), a usage counter, a size, a cloud data availability indicator, and a pointer to a block of digital memory wherein data entries of sensor measurements associated with the respective L2 node may be stored.
- ID node identification
- the blocks of digital memory 204a-k are therefore associated with the L2 nodes 202a-k.
- Each respective block of digital memory associated with a respective L2 node may contain a predefined number of bits or bytes.
- the usage counter, the size, and the node ID number may be of one or more primitive numerical data types.
- the cloud data availability indicator may be of a Boolean data type or a primitive numerical data type.
- Each size instance variable may indicate an amount of digital memory used to store data entries of sensor measurements associated with the respective L2 node.
- the size may be zero, as shown for L2 node 202k, if there are no data entries of sensor measurements currently stored in the L2 node's associated block of digital memory (block of digital memory 204k, in this example). If an L2 node's entire associated block of digital memory is being used to store data entries of sensor measurements, the size variable may be a maximum value.
- Each usage counter instance variable may indicate a number of times that measurement data in the respective block of digital memory associated with the respective L2 node has been queried or accessed.
- the priority counter of an LI node that points to an L2 list may be the sum of the usage counters of L2 nodes in the L2 list. While a pointer is depicted as an instance variable for each L2 node shown in FIG. 2, it is to be understood that another type of indicator of a digital-memory address (e.g., a reference) may also be used.
- a hashing function associated with the L2 list 200 may be designed to be applied to measurement data such that sensor measurements that are stored in the block of digital memory associated with a respective L2 node were taken during a specific period of time.
- the hash function can produce the same hash key so that the sensor measurements are placed in the same bucket.
- measurement data e.g., data entries of sensor
- measurements from a time period can be stored in a single block of digital memory.
- Designing the hashing function in this manner allows spatial locality of sensor measurements in memory to reflect temporal locality of the sensor measurements with regard to when the sensor measurements were taken.
- each L2 node is associated with a respective binary hash key (e.g., as the node ID or hash key of a corresponding bucket)
- a problem may arise if the hash function maps an additional sensor measurement to an L2 node whose associated block of digital memory is full of existing sensor measurements.
- One solution would be to allocate a larger block of memory, copy both the existing sensor measurements and the new sensor measurement over to the larger block, and set the respective L2 node's pointer to the larger block. This approach, though, is relatively inefficient. Furthermore, this might slow the retrieval of sensor measurements from memory in response to queries, since the hash bucket to which the respective L2 node corresponds would hold a larger number of sensor measurement values.
- FIGs. 3a-b illustrate a more efficient approach that may be used when a hash function maps an additional sensor measurement to an L2 node whose associated block of digital memory is full of existing sensor measurements.
- An L2 list 300 may be a hash table that includes L2 nodes 302a-k.
- the L2 nodes 302a-k may include pointers (or other indicators of memory addresses) to the associated digital memory blocks 304a-k,
- Each of the digital memory blocks 304a-k may have a predetermined amount of memory in which up to four sensor measurement data entries may be stored.
- the L2 nodes 302a-k may be associated with four-bit binary hash keys (e.g., 0000, 0001, 0010, and 1 1 1 1, as shown).
- the L2 nodes 302a-k are described as objects (e.g., in an object- oriented programming language such as Java or C++).
- the L2 nodes 302a-k may also be of any composite data type (e.g., Structs in C or records in TurboPascal) that permits the L2 nodes 302a-k to be designed as described.
- the L2 list 300 may generally include an arbitrary number of L2 nodes.
- a sensor measurement data entry 305 may be received for storage or indexing in the L2 list 300.
- a hash function may be applied to the sensor measurement data entry 305 (data entry #9) to determine that the sensor measurement data entry 305 hashes to a bucket with a hashing index of 0001 and should therefore be stored in the digital memory block 304b.
- the digital memory block 304b may already be filled with four other sensor measurement data entries, as shown.
- FIG. 3b illustrates changes that may be applied to the L2 list 300 in order to allow the sensor measurement data entry 305 (data entry #9) to be stored without requiring the sensor measurement data entries that have already been stored in digital memory block 304b to be relocated or copied.
- the four-bit binary hash key associated with the L2 node 302b can be extended by one extension bit each to form two resultant five-bit hash keys.
- the extension bit may be the most significant bit.
- the four least significant bits of the two resultant five-bit hash keys may have values identical to the four-bit hash key associated with L2 node 302b, while the most significant bits (MSBs) of the two resultant five-bit hash keys differ.
- One of the resultant five-bit hash keys can be associated with the L2 node 302b associated with the four-bit hash key.
- L2 node 302b For clarity, in FIG. 3b, once the L2 node 302b is associated with a resultant five-bit hash key (00001), the L2 node 302b is referred to as L2 node 302b(i). Values of instance variables of L2 node 302b(i), such as a pointer to digital memory block 304b, may remain unchanged.
- An additional L2 node 302b(ii) can be created and associated with the other resultant five-bit hash key (10001).
- the additional L2 node 302b(ii) may comprise a pointer to an additional digital memory block 306b.
- the sensor measurement data entry 305 (data entry #9) can then be stored in the digital memory block 306b.
- L2 nodes 302a and 302c- k Similar changes may be applied with respect to the L2 nodes 302a and 302c- k.
- the four-bit hash key of 302a (0000) may be extended to form resultant hash keys (00000 and 10000).
- One of the resultant hash keys (00000) may be associated with L2 node 302a; for explanatory purposes, L2 node 302a is referred to as L2 node 302a(l) in FIG. 3b.
- values of instance variables of the L2 node 302a(i) such as a pointer to digital memory block 304a, may remain unchanged.
- An additional L2 node 302a(ii) can be created and associated with the other resultant five-bit hash key (10000).
- the additional L2 node 302a(ii) may comprise a pointer to an additional digital memory block 306a.
- Similar changes may be applied with respect to L2 nodes 302c-k such that pointers of L2 nodes 302c(ii) and 302k(ii) point to additional digital memory blocks 306c and 306k, respectively, and pointers of L2 nodes 302c(i) and 302k(i) still point to digital memory blocks 304c and 304k, respectively.
- the hash function may be updated such that sensor measurement data entries that would have mapped to a single bucket associated with a given four-bit hash code are mapped to one of the two buckets associated with five-bit hash codes whose four least significant bits match the given four-bit hash code.
- FIGs. 3a-b illustrate extension from four-bit hash codes into five-bit hash codes
- the same principles explained for FIGs. 3a-b can be applied to extend hash codes for an L2 list from an arbitrary number of bits x into x + 1 bits.
- the number of bits used hash codes of these examples are not intended to be limiting.
- FIGs. 4a-e illustrate an exemplary manner in which an order of LI nodes
- the LI nodes 402a-f in an LI list 400 may be updated as values of priority counter instance variables for the LI nodes 402a-f change.
- the order of LI nodes 402a-f may be updated periodically at fixed time intervals or in response to changes in priority counter values.
- the LI nodes 402a-f may initially be sorted in descending order according to priority counter values.
- the priority counter for LI node 402e may be increased from 385 to 390. Since the priority counter for LI node 402d is only 389, the LI nodes are no longer sorted in descending order according to their respective priority counters.
- updating the order of the LI nodes 402a-f may be postponed until a difference between the priority counters of LI nodes 402e and 402d meets or exceeds a predefined threshold value.
- the difference may be calculated by subtracting the value of the priority counter of the LI node 402d (i.e., the LI node in a position of higher priority in the LI list 400) from the value of the priority counter of the LI node 402e (i.e., the LI node in a position of lower priority in the LI list 400).
- the predefined threshold value may be 7 (though other threshold values, of course, may be used). Since the difference between 389 and 390 is only 1, the order of the LI nodes 402a-f may not be updated in response to this difference.
- the priority counter of LI node 402e may be increased from 390 to 401 such that the predefined threshold value is exceeded by the difference of the priority counter of LI node 402e and the priority counter of LI node 402d.
- LI list 400 may be swapped. After the swapping, the priority counter of LI node 402e may also be compared to the priority counter of LI node 402c. Since the difference between the priority counter of LI node 402e and LI node 402c is 8, the predefined threshold value is exceeded.
- LI list 400 may be swapped.
- the priority counter of LI node 402e may also be compared to the priority counter of LI node 402b. Since the difference between the priority counter of LI node 402e and LI node 402b is -49, the predefined threshold value is not exceeded and no further updates are needed. Again, this difference is calculated by subtracting the value of the priority counter of the LI node in the position of higher priority in the LI List 400 from the value of the priority counter of the LI node in the position of lower priority in the LI list 400.
- FIGs. 5a-c illustrate states of a hybrid indexing/hashing structure for coordinating data storage between local digital memory of a UE and remote digital memory of a cloud storage system in accordance with an example.
- An LI list 500 may comprise LI nodes 502a-n.
- the LI nodes 502a-n may be indexed in the LI list 500 with indices ranging from 0 to an N-l, where there are NL1 nodes in the LI nodes 502a-n (though other ranges of indices can be used as long as each LI node has corresponds to a respective index).
- the LI nodes 502a-n may be sorted in descending order with respect to priority (e.g., as measured by instance variable priority counters).
- the LI nodes 502a-n may comprise instance variable pointers to the L2 lists
- Each of the L2 lists 504a-n may comprise a set of L2 nodes.
- L2 list 504a may include L2 nodes 506a-h
- L2 list 504b may include L2 nodes 507a-h
- L2 list 504c may include L2 nodes 508a-h
- L2 list 504n may include L2 nodes 509a-h.
- Each of the L2 lists 504a-n may comprise a hash table such that each L2 node is associated with a bucket of the hash table.
- a hashing function of a hash table may map data entries to buckets in a manner such that data entries assigned to a common bucket have temporal locality relative to each other.
- Each L2 node may comprise an instance variable pointer to a block of digital memory that may be local (e.g., at the UE) or remote (e.g., at the cloud storage system).
- L2 nodes 506a-d may have pointers to local digital memory blocks 510a-d, respectively
- L2 nodes 506e-h may have pointers to remote digital memory blocks (depicted by a cloud in FIGs. 5a-c).
- L2 nodes 507a-c may include pointers to local digital memory blocks 51 la-c, respectively
- L2 nodes 507d-h may include pointers to remote digital memory blocks.
- L2 nodes 508a-b may include pointers to local digital memory blocks 512a-b, respectively, and L2 nodes 508c-h may include pointers to remote digital memory blocks.
- L2 node 509a may include a pointer to local digital memory block 513a, respectively, and L2 nodes 509b-h may include pointers to remote digital memory blocks.
- Each data block may be the place where data entries for the bucket corresponding to the respective L2 node are stored.
- a first round of data transfer from the cloud storage system to the UE as shown in FIG. 5b may commence as follows. Since LI node 502a is in the position of highest priority in the sorted LI list 500, two additional local digital memory blocks 510e-f can be allocated for measurement data of the L2 list 504a. Pointers of the L2 nodes 506e-f can be directed to the local digital memory blocks 510e-f. Existing data entries for buckets corresponding to L2 nodes 506e-f can be downloaded from the cloud storage system and copied into the local digital memory blocks 510e-f, respectively.
- an additional local digital memory block 51 Id can be allocated for measurement data of the L2 list 504b.
- a pointer of the L2 node 507d can be directed to the local digital memory block 51 Id.
- Existing data entries for a bucket corresponding to L2 node 507d can be downloaded from the cloud storage system and copied into the local digital memory block 511d.
- LI node 502c corresponds to the pivot index (i.e., LI node 502c has a sufficiently high priority)
- an additional local digital memory block 512c can be allocated for measurement data of the L2 list 504c.
- a pointer of the L2 node 508c can be directed to the local digital memory block 512c.
- Existing data entries for a bucket corresponding to L2 node 508c can be downloaded from the cloud storage system and copied into the local digital memory block 512c.
- LI node 502n corresponds to an index of lower priority than the pivot index
- the pointers of L2 nodes 509b-h may remain directed to remote digital memory blocks.
- a second round of data transfer from the cloud storage system to the UE as shown in FIG. 5c may commence as follows. Since LI node 502a remains in the position of highest priority in the sorted LI list 500, two additional local digital memory blocks 510g-h can be allocated for measurement data of the L2 list 504a. Pointers of the L2 nodes 506g-h can be directed to the local digital memory blocks 510g-h. Existing data entries for buckets corresponding to L2 nodes 506g-h can be downloaded from the cloud storage system and copied into the local digital memory blocks 510g-h, respectively.
- LI list 500 an additional local digital memory block 51 le can be allocated for measurement data of the L2 list 504b.
- a pointer of the L2 node 507e can be directed to the local digital memory block 51 le.
- Existing data entries for a bucket corresponding to L2 node 507e can be downloaded from the cloud storage system and copied into the local digital memory block 511e.
- LI node 502c corresponds to the pivot index (i.e., LI node 502c has a sufficiently high priority)
- a limit for local storage space may have been reached. Hence, no additional measurement data is downloaded from the cloud storage system.
- FIGs. 5a-c The example shown in FIGs. 5a-c and explained above serves to demonstrate some aspects of methods and systems to coordinate storage of measurement data between a local device and a cloud storage system.
- more local blocks may be allocated for L2 lists whose corresponding LI nodes have higher priority (as determined by the order of LI nodes in the LI list).
- Local blocks may be allocated on a round-by-round basis, in descending order according to priority as indicated by the indices of the LI list, for LI nodes (and their corresponding L2 lists) until no additional local digital memory is available.
- FIG. 6 illustrates functionality 600 for storing data measurements for efficient retrieval in accordance with an example.
- the functionality can be implemented as instructions stored and executed on a machine, where the instructions are included on at least one non-transitory computer-readable storage medium.
- the functionality 600 may include receiving, at a user equipment (UE), a data measurement taken by a sensor, wherein the data measurement was taken during a time interval.
- UE user equipment
- the functionality 600 may include identifying a type of the data measurement.
- the functionality 600 may include identifying a level- 1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement.
- the LI node may also comprise a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the functionality 600 may include using a hash function to determine a hash key for the data measurement.
- the functionality 600 may include identifying a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket.
- the L2 node may also comprise a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried, a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory, or a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
- the functionality 600 may also include identifying that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements.
- the functionality 600 may also include issuing a command for the data measurement to be stored in the block of digital memory based on the determination.
- the block of digital memory may be at a local device or at a remote data store.
- the functionality 600 may also include identifying that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N.
- the functionality 600 may also include creating an a first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key.
- the functionality 600 may also include associating the first expansion hash key with the bucket of the hash table and with the block of digital memory.
- the functionality 600 may also include associating the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory.
- the functionality 600 may also include issuing a command for the data measurement to be stored in the additional block of digital memory.
- additional LI nodes may be elements of the LI List, each
- LI node that is an element of the LI List may comprise a respective element priority counter that is an instance variable; the LI list may be sorted based on element priority counters.
- the functionality 600 may include determining whether there is sufficient space available in the block of digital memory for the data measurement to be stored [0069]
- FIG. 7 illustrates functionality 700 for retrieving a data measurement from digital memory in accordance with an example.
- the functionality can be implemented as instructions stored and executed on a machine, where the instructions are included on at least one non-transitory computer-readable storage medium.
- the functionality 700 may include receiving, at a user equipment (UE), a request for a data measurement of a specified type, wherein the data measurement was made during a time interval specified in the request.
- UE user equipment
- the functionality 700 may include identifying a level-1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital-memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table.
- the LI node may comprise a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the functionality 700 may include identifying a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data measurement is stored for the bucket.
- the L2 node may further comprise a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory or a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE. Identifying the L2 node associated with the time interval in which the data measurement was taken may be achieved by applying a hashing function to a datum associated with the data measurement.
- additional LI nodes may be elements of the LI List, each
- LI node that is an element of the LI List may comprise a respective element priority counter that is an instance variable, and the LI list can be sorted based on element priority counters.
- the functionality 700 may include incrementing an element priority counter of the LI node, comparing the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List, and swapping a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
- the functionality 700 may also include determining a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list, verifying that the difference meets or exceeds a predefined threshold value, and swapping an initial position of the LI node and an initial position of the neighboring LI node in the LI list based on the verification such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
- additional L2 nodes may correspond to additional respective buckets in the hash table and each respective L2 node may comprise a usage counter that is an instance variable reflecting a frequency with which data
- the functionality 700 may also include comparing the resultant position of the LI node to a predefined pivot position and issuing a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
- the functionality 700 may include comparing the resultant position of the neighboring LI node to a predefined pivot position and issuing a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
- the functionality 700 may include issuing a command for the data measurement to be retrieved from the block of digital memory.
- FIG 8 illustrates functionality 800 for coordinating storage of data
- the functionality can be implemented as instructions stored and executed on a machine, where the instructions are included on at least one non-transitory computer- readable storage medium.
- the functionality 800 may include identifying a level- 1 (LI) list of level-1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values.
- LI level- 1
- LI level-1
- the functionality 800 may include identifying a pivot index for the LI list.
- the functionality 800 may include performing, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index (e.g., the index of the LI node with a highest priority in the LI list), the actions of block 840 and block 850.
- a terminal index as used herein, may refer the index of the first node in a list or the index of a last node in a list.
- the LI node with the lowest numerical index (which is a terminal index) in the LI list may have the highest priority and the LI node with the highest numerical index (which is also a terminal index) in the LI list may have the lowest priority relative to all nodes in the list.
- the LI list is sorted in ascending order according to priority, the LI node with the lowest numerical index in the LI list may have the lowest priority and the LI node with the highest numerical index may have the highest priority.
- the functionality 800 may include identifying a high-priority
- the functionality 800 may include determining whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
- the functionality 800 may also include performing, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following: identifying a high-priority L2 node in a hash table associated with the at least one LI node, determining that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE, and issuing a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from the remote data store.
- the high-priority L2 node may have a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
- the functionality 800 may also include performing, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following: determining that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed because the data measurements in the respective bucket were taken during a range of time in which frequently- accessed data measurements were taken, and identifying the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data
- the functionality 800 may include performing, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index (e.g., an index of an LI node with a lowest priority in the LI list), the following: identifying one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and deleting the data measurements that are stored for the buckets corresponding to the one or more L2 nodes from the local digital memory.
- a second terminal index e.g., an index of an LI node with a lowest priority in the LI list
- the functionality 800 may also include performing, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following: (1) identifying one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at the remote data store; (2) sending the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and (3) deleting the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
- the functionality 800 may include performing, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following: (1) identifying a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high-priority L2 nodes is based on a respective element priority counter value of the respective LI node; (2) determining that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and (3) issuing a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high-priority L2 nodes from the remote data store.
- FIG. 9 provides an example illustration of the wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of wireless device.
- the wireless device can include one or more antennas configured to communicate with a (cellular network) node, macro node, low power node (LPN), or, transmission station, such as a base station (BS), an evolved Node B (eNB), a baseband processing unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WW AN) access point.
- BS base station
- eNB evolved Node B
- BBU baseband processing unit
- RRH remote radio head
- RRE remote radio equipment
- RS relay station
- RE radio equipment
- the wireless device can be configured to communicate using at least one wireless communication standard including 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi.
- the wireless device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards.
- the wireless device can
- the wireless device can also comprise a wireless modem.
- the wireless modem can comprise, for example, a wireless radio transceiver and baseband circuitry (e.g., a baseband processor).
- the wireless modem can, in one example, modulate signals that the wireless device transmits via the one or more antennas and demodulate signals that the wireless device receives via the one or more antennas.
- FIG. 9 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device.
- the display screen can be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display.
- the display screen can be configured as a touch screen.
- the touch screen can use capacitive, resistive, or another type of touch screen technology.
- An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities.
- a non-volatile memory port can also be used to provide data input/output options to a user.
- the non-volatile memory port can also be used to expand the memory capabilities of the wireless device.
- a keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input.
- a virtual keyboard can also be provided using the touch screen.
- Various techniques, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD- ROMs, hard drives, non-transitory computer readable storage medium, or any other machine- readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques.
- Circuitry can include hardware, firmware, program code, executable code, computer instructions, and/or software.
- a non-transitory computer readable storage medium can be a computer readable storage medium that does not include signal.
- the computing device can include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.
- the volatile and non-volatile memory and/or storage elements can be a RAM, EPROM, flash drive, optical drive, magnetic hard drive, solid state drive, or other medium for storing electronic data.
- the node and wireless device can also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module.
- One or more programs that can implement or utilize the various techniques described herein can use an application programming interface (API), reusable controls, and the like.
- API application programming interface
- Such programs can be implemented in a high level procedural or object oriented programming language to communicate with a computer system.
- the program(s) can be implemented in assembly or machine language, if desired.
- the language can be a compiled or interpreted language, and combined with hardware implementations.
- processor can include general-purpose processors, specialized processors such as VLSI, FPGAs, and other types of specialized processors, as well as base-band processors used in transceivers to send, receive, and process wireless communications.
- modules can be implemented as a hardware circuit (e.g., an application-specific integrated circuit (ASIC)) comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
- a module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
- Modules can also be implemented in software for execution by various types of processors.
- An identified module of executable code can, for instance, comprise one or more physical or logical blocks of computer instructions, which can, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but can comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
- a module of executable code can be a single instruction, or many instructions, and can even be distributed over several different code segments, among different programs, and across several memory devices.
- operational data can be identified and illustrated herein within modules, and can be embodied in any suitable form and organized within any suitable type of data structure. The operational data can be collected as a single data set, or can be distributed over different locations including over different storage devices, and can exist, at least partially, merely as electronic signals on a system or network.
- the modules can be passive or active, including agents operable to perform desired functions.
- processor can include general purpose processors, specialized processors such as VLSI, FPGAs, and other types of specialized processors, as well as base band processors used in transceivers to send, receive, and process wireless communications.
- the word “or” indicates an inclusive disjunction.
- the phrase “A or B” represents an inclusive disjunction of exemplary conditions A and B. Hence, “A or B” is false only if both condition A is false and condition B is false. When condition A is true and condition B is also true, “A or B” is also true. When condition A is true and condition B is false, “A or B” is true. When condition B is true and condition A is false, “A or B” is true. In other words, the term “or,” as used herein, should not be construed as an exclusive disjunction. The term “xor” is used where an exclusive disjunction is intended.
- a method for storing data measurements for efficient retrieval comprising:
- UE user equipment
- a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement; using a hash function to determine a hash key for the data measurement;
- L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket;
- the method of storing data can further comprise:
- the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements
- the method of storing data can further comprise:
- the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
- first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
- the additional LI nodes are elements of the LI List
- each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable
- the LI list is sorted based on element priority counters.
- the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the L2 node further comprises at least one of: a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried;
- a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory
- a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
- a method for retrieving a data measurement from digital memory comprising:
- a user equipment UE
- a request for a data measurement of a specified type wherein the data measurement was made during a time interval specified in the request
- identifying a level- 1 (LI) node associated with the specified type wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital- memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
- LI level- 1
- LI level-1
- L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital- memory address of a block of digital memory in which the data measurement is stored for the bucket;
- additional LI nodes are elements of the LI List
- each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable
- the LI list is sorted based on element priority counters.
- the method of retrieving data further comprises:
- the method of retrieving data further comprises: determining a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
- LI node is the initial position of the LI node.
- the additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
- the method of retrieving data further comprises:
- the method of retrieving data further comprises:
- identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
- the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the L2 node further comprises at least one of:
- a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory
- a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
- a method of coordinating storage of data measurements between local digital memory at a user equipment (UE) and a remote data store comprising:
- each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
- the method of coordinating storage of data measurements further comprises:
- the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
- the method further comprises:
- the method of coordinating storage of data measurements further comprises:
- the method of coordinating storage of data measurements further comprises:
- each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at the remote data store
- the method of coordinating storage of data measurements further comprises:
- a system for storing data comprising:
- a sensor configured to gather data
- a user equipment configured to receive data from the sensor, said UE
- circuitry configured to:
- a level-1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement; use a hash function to determine a hash key for the data measurement; identify a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket; and
- the circuitry is further configured to:
- the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements
- the circuitry is further configured to:
- the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
- first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
- additional LI nodes are elements of the LI List
- each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable
- the LI list is sorted based on element priority counters.
- the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the L2 node further comprises at least one of:
- a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried
- a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory
- measurements stored in the block of digital memory are stored remotely relative to the UE.
- a system for retrieving data is provided, the system
- a sensor configured to gather data
- a user equipment configured to receive data from the sensor, said UE comprising circuitry configured to:
- a level- 1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital- memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
- LI level- 1
- L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data
- additional LI nodes are elements of the LI List
- each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable
- the LI list is sorted based on element priority counters.
- the circuitry is further configured to:
- the circuitry is further configured to:
- additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
- the circuitry is further configured to:
- the circuitry is further configured to:
- the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the L2 node further comprises at least one of:
- a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory
- measurements stored in the block of digital memory are stored remotely relative to the UE.
- one or more sensors configured to make data measurements
- a user equipment configured to receive data from the one or more sensors, the UE comprising local digital memory and circuitry configured to:
- each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements made by the one or more sensors and stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
- L2 level-2
- the circuitry is further configured to:
- the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
- the circuitry is further configured to:
- the circuitry is further configured to:
- the circuitry is further configured to:
- each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at a remote data store
- the circuitry is further configured to: perform, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
- a user equipment comprising one or more processors configured to:
- level- 1 (LI) node associated with the type of the data measurement
- LI level-1
- LI level-1
- L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket;
- the one or more processors are further configured to:
- the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and issue a command for the data measurement to be stored in the block of digital memory based on the determination.
- the one or more processors are further configured to:
- the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
- first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
- additional LI nodes are elements of the LI List
- each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable
- the LI list is sorted based on element priority counters.
- the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the L2 node further comprises at least one of:
- a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried
- a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
- a user equipment comprising one or more processors configured to:
- a level- 1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital- memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
- LI level- 1
- L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data
- additional LI nodes are elements of the LI List
- each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable
- the LI list is sorted based on element priority counters.
- the one or more processors are further configured to:
- the one or more processors are further configured to:
- additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
- the one or more processors are further configured to:
- the one or more processors are further configured to:
- identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
- the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
- the L2 node further comprises at least one of: a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
- measurements stored in the block of digital memory are stored remotely relative to the UE.
- a user equipment comprising local digital memory and one or more processors configured to:
- each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements made by the one or more sensors and stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
- L2 level-2
- the one or more processors are further configured to:
- the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
- the one or more processors are further configured to:
- the one or more processors are further configured to:
- the one or more processors are further configured to:
- each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at a remote data store
- the one or more processors are further configured to:
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Technology described herein provides methods whereby a two-level indexing/hashing structure is used to efficiently coordinate storage of sensor measurements between local digital memory (e.g., at a mobile device) and remote digital memory (e.g., at a cloud storage system). The first level of the two-level indexing/hashing structure may be include an array of first-level nodes that are sorted according to priority values. The priority values may be determined based on user data-querying activity. The second level of the two-level indexing/hashing structure may include second-level hash tables wherein buckets are associated with memory blocks of a predefined size. Sensor measurements that were taken during a specific time period may be stored near each other in memory and may be downloaded for local storage if user activity suggests that the user frequently has interest in data from that time period.
Description
EFFICIENT STORAGE AND RETRIEVAL FOR WEARABLE-DEVICE DATA
BACKGROUND
[0001] Wearable devices, such as activity trackers, are becoming increasingly popular. These wearable devices typically include sensors configured to measure quantities from which inferences about a wearer's physical condition and physical activity levels may be made. Some examples of sensors that may be used in wearable devices include
accelerometers, heart rate monitors (e.g., optical heart rate monitors), thermometers, global positioning system (GPS) locators, bioimpedance sensors, galvanic skin response sensors, ultraviolet (UV) sensors, and optical sensors (e.g., that use light-emitting diodes (LEDs)) that measure blood oxygenation or antioxidant levels.
[0002] It is convenient for these wearable devices to be small so that they can be worn throughout a wide range of activities without unduly impeding the wearer's mobility or comfort. Hence, these wearable devices are often small enough to be worn in a sleeve for the leg, an armband, a chest strap, a belt, a shoe, a clip-on assembly, or a wristband.
[0003] When a wearable device is worn throughout a wearer's daily activities, sensors of the wearable device can collect desired measurements at a desired rate. The measurements taken during a specific time period may be used to illustrate trends over time. The
measurements, for example, may be suitable display in a scatterplot (e.g., of the quantity measured plotted against time). Methods such as regression and interpolation may also be applied to the measurements in order to estimate rates of change and trends over time.
Various types of analysis may be applied to the measurements in order to estimate desired quantities that may not be immediately measurable using the sensors (e.g., calories burned).
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure; and, wherein:
[0005] FIG. 1 illustrates an example of a first level (LI) list of an indexing/hashing structure in accordance with an example;
[0006] FIG. 2 illustrates a detailed example of a second-level (L2) list in accordance with an example;
[0007] FIGs. 3a-b illustrate an example of how an indexing/hashing structure may be expanded in accordance with an example;
[0008] FIGs. 4a-e illustrate an exemplary manner in which an order of LI nodes in an
LI list may be updated in accordance with an example;
[0009] FIGs. 5a-c illustrate states of a hybrid indexing/hashing structure for coordinating data storage between local digital memory and remote digital memory in accordance with an example;
[0010] FIG. 6 illustrates functionality for storing data measurements for efficient retrieval in accordance with an example;
[0011] FIG. 7 illustrates functionality for retrieving a data measurement from digital memory in accordance with an example;
[0012] FIG. 8 illustrates functionality for coordinating storage of data measurements between local digital memory and a remote data store in accordance with an example; and
[0013] FIG. 9 provides an example illustration of a wireless device in accordance with an example.
[0014] Reference will now be made to the exemplary embodiments illustrated and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the disclosure scope is thereby intended.
DESCRIPTION OF EMBODIMENTS
[0015] Before some embodiments are disclosed and described, it is to be understood that the claimed subject matter is not limited to the particular structures, process operations, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular examples only and is not intended to be limiting. The same reference numerals in different drawings represent the same element. Numbers provided in flow charts and processes are provided for clarity in illustrating operations and do not necessarily indicate a particular order or sequence.
[0016] An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is
intended to aid readers in understanding the technology more quickly, but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.
[0017] A large number of measurements may be taken by the sensors of a wearable device over the course of several hours, days, or months, especially if the rate at which measurements are taken is relatively high. The wearable device's small size, however, may provide limited physical space for physical memory on which the measurements may be stored. Consequently, a wearable device may be configured to cache a small amount of measurement data and transfer other measurement data to another device that has more available physical memory. For example, a wearable device may transfer measurement data to another device, such as a user equipment (UE) (e.g., a mobile cellular phone), a computer (e.g., a laptop or a desktop), or a remote data store (e.g., a cloud service for data storage). The measurement data may be transferred wirelessly (e.g., using Bluetooth, WiFi, or 3GPP technology) or via a wired connection (e.g., using a universal serial port (USB) cable or an auxiliary input cable). In some cases, sensors that take measurements of interest may be part of a UE that is not wearable device. In such cases, the transfer of measurement data from sensors to physical memory of the UE may occur through circuitry of the UE itself. It should be noted that wearable devices and UEs are not mutually exclusive, but rather, a device may be both a wearable device and a UE.
[0018] In some examples consistent with the present disclosure, a UE and a sensor may be devices that are considered to be part of a system for storing or retrieving
measurement data. In such systems, the sensor may serve as the device within the system that takes measurements of a quantity of interest and conveys the measurements to the UE. In one example, the UE may have an integrated sensor therein and in other examples the sensor device may be a separate and independent device from the UE. In examples where the sensor is separate from the UE, the measurements taken by the sensor may be conveyed wirelessly or through a wired connection (e.g., an auxiliary cable). The UE, in turn, may serve as a device within the system that includes one or more processors (e.g., application processors or baseband processors) that are configured to apply methods described herein in order to determine where and how to store the measurements in order to facilitate efficient storage and retrieval. In a further embodiment, a system may further include a cloud or other remote data store that can communicate with the UE. In one embodiment, the system can include a UE with an integrates sensor and a remote data store that can communicate with the UE. In
another embodiment, the system can include a sensor that is capable of communicating with a separate UE, and a remote data store that is capable of communicating with the UE.
[0019] While a UE such as a smart phone may store some measurement data, UEs are typically also relatively small and therefore have relatively limited digital storage space. Furthermore, in the case of a smartphone, the UE may be used for many other purposes (e.g., making telephone calls, surfing the internet, streaming media, playing video games, etc.) that require use of the UE's limited storage space. As a result, it may be prudent to limit the amount of the UEs storage space that is designated for storing measurement data from sensors in order to ensure that the UE has sufficient available storage space for other purposes. UEs that store measurement data from sensors (e.g., wearable sensors) may therefore be configured to transfer measurement data via a network connection to a cloud data storage system wherein digital data may be stored across one or more servers.
[0020] There are a number of simple approaches addressing how data storage for sensor measurement data is coordinated or synchronized between a UE and a cloud storage system. One approach is to use a basic last-in-first-out (LIFO) scheme (e.g., a stack) wherein measurement data is uploaded at defined time intervals to the cloud storage system in descending order according to measurement timestamps. Another approach is to use a first- in-first-out (FIFO) scheme (e.g., a queue) wherein measurement data is uploaded at defined time intervals to the cloud storage system in ascending order according to measurement timestamps. Measurement data may even be uploaded continuously through streaming so that little or no measurement data is stored locally at the UE (though this may lead to unnecessary use of battery power and bandwidth resources). A single interface may be provided whereby a user can query the measurement data that is stored both locally and remotely. Alternatively, separate interfaces may be used for local data retrieval from the UE's digital memory and for remote data retrieval from the cloud storage system, respectively.
[0021] These approaches for coordinating the storage of measurement data between a
UE and a cloud storage system have some drawbacks, however. For example, a user may wish to retrieve measurement data from storage for display and inspection on the UE. The user may request that measurement data from a certain day, for example, be displayed in a scatterplot so that the user can see activity patterns for that day. If the measurement data for that day is stored on the UE, the measurement data may be retrieved relatively quickly.
However, if the measurement data for that day has been transferred to a cloud storage system and removed from local memory, it may take an inconvenient amount of time to download
the measurement data from the cloud storage system to the UE. In areas where cellular or WiFi coverage is unavailable, the user may be unable to download the measurement data until the UE is moved to a location where coverage is available. Furthermore, if separate interfaces are used to retrieve local data and remote data, the user may be obliged to navigate through both interfaces to download desired portions of the desired measurement data.
[0022] In order to promote a good quality of experience (QoE) for users of wearable devices and UEs that gather measurement data from sensors, at least some of the
measurement data can be stored locally at the UE. However, in the approaches described above, measurement data is selected for local storage based on recentness, based on the type of data structure (e.g., queue or stack) used to cache the data locally, and based on the time intervals at which data is uploaded to the cloud storage system. Even if a user's querying behavior suggests that the user might be more likely to retrieve measurements that were made in a different time frames, the approaches described above provide no solution whereby a UE may preemptively identify and download measurement data from the different time frames. Hence, unless the user happens to conveniently request measurement data from the exact time frame whose measurements are locally stored, the user may have to wait for longer periods of time to access desired measurement data.
[0023] For example, suppose a user is a runner who is trying to identify an optimal rate at which to increase a distance for daily runs without causing an overuse injury (e.g., shin splints). The runner wears an activity tracker with various sensors on a daily basis and the activity tracker sends measurement data to the user's smartphone. The smartphone stores the most recent data locally in a FIFO scheme and periodically uploads the rest of the
measurement data to a cloud storage system via a wireless cellular network connection.
[0024] In this example, also suppose that the user has recently begun to feel pain from an overuse injury— presumably because recent rates of increase in the daily running distance have been too high. Since the user's previous training regimen from about six months prior did not seem to cause any overuse injuries, the user wishes to retrieve measurement data that was gathered during the previous training regimen in order to determine how rates of increase in running distances during the previous training regimen compare to the rates of the user's current training regimen. The user queries the measurement data from six months prior multiple times over the course of a week while trying to ascertain rates of increase in running distance under the prior training regimen. In the meantime, the user takes a week off from running in order to let the overuse injury heal.
[0025] In this scenario, the user has little interest in the most recent measurement data from the week in which the user has been recovering. The user also has great interest in the measurement data from six months ago, as indicated by the user's querying behavior.
Unfortunately, since the user's smartphone is configured to store only the most recent data locally, the user is relegated to waiting for data to be downloaded from the cloud storage system each time the measurement data from six months prior is queried. In the meantime, local storage space at the smartphone that can be accessed much more quickly is occupied by the unsought measurement data from the user's week of rest.
[0026] Systems and methods of the present disclosure provide a more intelligent solution for coordinating the storage of measurement data between a UE and a cloud storage system. Invention embodiments provide a hybrid hashing scheme that enables measurement data to be accessed quickly and prioritized for local storage based on user's querying behavior. Some embodiments may include an indexing/hashing structure with lists at two levels.
[0027] FIG. 1 illustrates an example of first level (LI) list 100 of an indexing/hashing structure in accordance with an example. For simplicity, the LI list 100 of this example is described as an array. However, other list structures, such as linked lists or vectors, may also be used. The LI list 100 may comprise LI nodes 102a-n. In this example, the nodes 102a-n are described as objects (e.g., in an object-oriented programming language such as Java or C++). However, the LI nodes 102a-n may also be of any composite data type (e.g., Structs in C or records in TurboPascal) that permits the LI nodes 102a-n to be designed as described. In addition, while lower case letters are used for convenience in identifying the three nodes shown, it is to be understood that the LI list 100 may generally include an arbitrary number of LI nodes.
[0028] Each of the LI nodes 102a-n may comprise instance variables such as a priority counter, a size, a node identification (ID) number, and a pointer to a respective second level (L2) list 104a-n associated with the respective node. The priority counter, the size, and the node ID may be of one or more primitive numerical data types. Each size instance variable may indicate an amount of digital memory used to store measurement data associated with the respective LI node. Each priority counter instance variable may indicate a number of times that measurement data in the respective L2 list associated with the respective LI node has been queried or accessed. Alternatively, the value of a priority counter instance variable may also be determined based on other types of schemes (e.g., wherein time elapsed
since an LI node's L2 list was last accessed is used to determine a weighting and outlier handling is provided). The LI nodes 102a-n may be sorted in the LI list 100 according to their respective priority counter instance variables. While a pointer is depicted as an instance variable for each node shown in FIG. 1, it is to be understood that another type of indicator of a digital -memory address (e.g., a reference) may also be used.
[0029] Each of the LI nodes 102a-n may be associated with a respective type of measurement data received from sensors. For example, one of the LI nodes 102a-n may be associated with heart rate measurements, while another might be associated with temperature measurements, accelerometer measurements, or another type of measurement. In some examples, different LI nodes might represent subtypes of more general types of measurement data. In these examples, an indexing function may be provided. The indexing function may be used to indicate list indices (e.g., array indices) or node ID numbers of LI nodes in the LI list 100 that are associated with subtypes of a general type.
[0030] The LI nodes 102a-n in the LI list may be sorted according to their respective priority counter instance variable values. Though FIG. 1 illustrates that the LI nodes 102a-n are sorted in descending order from left to right, it is to be understood that the functionality described herein may also be accomplished with trivial adjustments if the LI nodes 102a-n were sorted in ascending order.
[0031] FIG. 2 illustrates a detailed example of an L2 list 200 in accordance with an example. The L2 list 200 may be a hash table. The L2 list 200 may comprise L2 nodes 202a- k. Each of the L2 nodes 202a-k may correspond to a hash-table bucket of the L2 list 200.
[0032] In this example, the L2 nodes 202a-k are described as objects (e.g., in an object-oriented programming language such as Java or C++). However, the L2 nodes 202a-k may also be of any composite data type (e.g., Structs in C or records in TurboPascal) that permits the L2 nodes 202a-k to be designed as described. In addition, while lower case letters are used for convenience in identifying the three nodes shown, it is to be understood that the L2 list 200 may generally include an arbitrary number of L2 nodes.
[0033] Each L2 node 202a-k may comprise instance variables such as a node identification (ID) number (which may also be a binary hash key associated with the respective L2 node), a usage counter, a size, a cloud data availability indicator, and a pointer to a block of digital memory wherein data entries of sensor measurements associated with the respective L2 node may be stored. In FIG. 2, the blocks of digital memory 204a-k are
therefore associated with the L2 nodes 202a-k. Each respective block of digital memory associated with a respective L2 node may contain a predefined number of bits or bytes.
[0034] The usage counter, the size, and the node ID number may be of one or more primitive numerical data types. The cloud data availability indicator may be of a Boolean data type or a primitive numerical data type. Each size instance variable may indicate an amount of digital memory used to store data entries of sensor measurements associated with the respective L2 node. The size may be zero, as shown for L2 node 202k, if there are no data entries of sensor measurements currently stored in the L2 node's associated block of digital memory (block of digital memory 204k, in this example). If an L2 node's entire associated block of digital memory is being used to store data entries of sensor measurements, the size variable may be a maximum value.
[0035] Each usage counter instance variable may indicate a number of times that measurement data in the respective block of digital memory associated with the respective L2 node has been queried or accessed. In some examples, the priority counter of an LI node that points to an L2 list may be the sum of the usage counters of L2 nodes in the L2 list. While a pointer is depicted as an instance variable for each L2 node shown in FIG. 2, it is to be understood that another type of indicator of a digital-memory address (e.g., a reference) may also be used.
[0036] A hashing function associated with the L2 list 200 may be designed to be applied to measurement data such that sensor measurements that are stored in the block of digital memory associated with a respective L2 node were taken during a specific period of time. In other words, for sensor measurements taken during that specific period of time, the hash function can produce the same hash key so that the sensor measurements are placed in the same bucket. In this manner, measurement data (e.g., data entries of sensor
measurements) from a time period can be stored in a single block of digital memory.
Designing the hashing function in this manner allows spatial locality of sensor measurements in memory to reflect temporal locality of the sensor measurements with regard to when the sensor measurements were taken.
[0037] In examples where each L2 node is associated with a respective binary hash key (e.g., as the node ID or hash key of a corresponding bucket), a problem may arise if the hash function maps an additional sensor measurement to an L2 node whose associated block of digital memory is full of existing sensor measurements. One solution would be to allocate a larger block of memory, copy both the existing sensor measurements and the new sensor
measurement over to the larger block, and set the respective L2 node's pointer to the larger block. This approach, though, is relatively inefficient. Furthermore, this might slow the retrieval of sensor measurements from memory in response to queries, since the hash bucket to which the respective L2 node corresponds would hold a larger number of sensor measurement values.
[0038] FIGs. 3a-b illustrate a more efficient approach that may be used when a hash function maps an additional sensor measurement to an L2 node whose associated block of digital memory is full of existing sensor measurements. An L2 list 300 may be a hash table that includes L2 nodes 302a-k. The L2 nodes 302a-k may include pointers (or other indicators of memory addresses) to the associated digital memory blocks 304a-k,
respectively. Each of the digital memory blocks 304a-k may have a predetermined amount of memory in which up to four sensor measurement data entries may be stored. The L2 nodes 302a-k may be associated with four-bit binary hash keys (e.g., 0000, 0001, 0010, and 1 1 1 1, as shown). In this example, the L2 nodes 302a-k are described as objects (e.g., in an object- oriented programming language such as Java or C++). However, the L2 nodes 302a-k may also be of any composite data type (e.g., Structs in C or records in TurboPascal) that permits the L2 nodes 302a-k to be designed as described. In addition, while lower case letters are used for convenience in identifying the three nodes shown, it is to be understood that the L2 list 300 may generally include an arbitrary number of L2 nodes.
[0039] As shown in FIG. 3a, a sensor measurement data entry 305 may be received for storage or indexing in the L2 list 300. A hash function may be applied to the sensor measurement data entry 305 (data entry #9) to determine that the sensor measurement data entry 305 hashes to a bucket with a hashing index of 0001 and should therefore be stored in the digital memory block 304b. However, the digital memory block 304b may already be filled with four other sensor measurement data entries, as shown.
[0040] FIG. 3b illustrates changes that may be applied to the L2 list 300 in order to allow the sensor measurement data entry 305 (data entry #9) to be stored without requiring the sensor measurement data entries that have already been stored in digital memory block 304b to be relocated or copied. The four-bit binary hash key associated with the L2 node 302b can be extended by one extension bit each to form two resultant five-bit hash keys. In some examples, the extension bit may be the most significant bit. The four least significant bits of the two resultant five-bit hash keys may have values identical to the four-bit hash key associated with L2 node 302b, while the most significant bits (MSBs) of the two resultant
five-bit hash keys differ. One of the resultant five-bit hash keys can be associated with the L2 node 302b associated with the four-bit hash key. For clarity, in FIG. 3b, once the L2 node 302b is associated with a resultant five-bit hash key (00001), the L2 node 302b is referred to as L2 node 302b(i). Values of instance variables of L2 node 302b(i), such as a pointer to digital memory block 304b, may remain unchanged. An additional L2 node 302b(ii) can be created and associated with the other resultant five-bit hash key (10001). The additional L2 node 302b(ii) may comprise a pointer to an additional digital memory block 306b. The sensor measurement data entry 305 (data entry #9) can then be stored in the digital memory block 306b.
[0041] Similar changes may be applied with respect to the L2 nodes 302a and 302c- k. For example, the four-bit hash key of 302a (0000) may be extended to form resultant hash keys (00000 and 10000). One of the resultant hash keys (00000) may be associated with L2 node 302a; for explanatory purposes, L2 node 302a is referred to as L2 node 302a(l) in FIG. 3b. Again, values of instance variables of the L2 node 302a(i), such as a pointer to digital memory block 304a, may remain unchanged. An additional L2 node 302a(ii) can be created and associated with the other resultant five-bit hash key (10000). The additional L2 node 302a(ii) may comprise a pointer to an additional digital memory block 306a. As illustrated, similar changes may be applied with respect to L2 nodes 302c-k such that pointers of L2 nodes 302c(ii) and 302k(ii) point to additional digital memory blocks 306c and 306k, respectively, and pointers of L2 nodes 302c(i) and 302k(i) still point to digital memory blocks 304c and 304k, respectively. The hash function may be updated such that sensor measurement data entries that would have mapped to a single bucket associated with a given four-bit hash code are mapped to one of the two buckets associated with five-bit hash codes whose four least significant bits match the given four-bit hash code.
[0042] It should be understood that, although FIGs. 3a-b illustrate extension from four-bit hash codes into five-bit hash codes, the same principles explained for FIGs. 3a-b can be applied to extend hash codes for an L2 list from an arbitrary number of bits x into x + 1 bits. As such, the number of bits used hash codes of these examples are not intended to be limiting.
[0043] FIGs. 4a-e illustrate an exemplary manner in which an order of LI nodes
402a-f in an LI list 400 may be updated as values of priority counter instance variables for the LI nodes 402a-f change. The order of LI nodes 402a-f may be updated periodically at fixed time intervals or in response to changes in priority counter values.
[0044] As shown in FIG. 4a, the LI nodes 402a-f may initially be sorted in descending order according to priority counter values. As shown in selection 404 of FIG. 4b, the priority counter for LI node 402e may be increased from 385 to 390. Since the priority counter for LI node 402d is only 389, the LI nodes are no longer sorted in descending order according to their respective priority counters. However, updating the order of the LI nodes 402a-f may be postponed until a difference between the priority counters of LI nodes 402e and 402d meets or exceeds a predefined threshold value. The difference may be calculated by subtracting the value of the priority counter of the LI node 402d (i.e., the LI node in a position of higher priority in the LI list 400) from the value of the priority counter of the LI node 402e (i.e., the LI node in a position of lower priority in the LI list 400). In FIGs. 4a-e, as an example, the predefined threshold value may be 7 (though other threshold values, of course, may be used). Since the difference between 389 and 390 is only 1, the order of the LI nodes 402a-f may not be updated in response to this difference.
[0045] As shown in selection 406 of FIG. 4c, the priority counter of LI node 402e may be increased from 390 to 401 such that the predefined threshold value is exceeded by the difference of the priority counter of LI node 402e and the priority counter of LI node 402d.
[0046] As shown in FIG. 4d, the positions of LI node 402e and LI node 402d in the
LI list 400 may be swapped. After the swapping, the priority counter of LI node 402e may also be compared to the priority counter of LI node 402c. Since the difference between the priority counter of LI node 402e and LI node 402c is 8, the predefined threshold value is exceeded.
[0047] As shown in FIG. 4e, the positions of LI node 402e and LI node 402c in the
LI list 400 may be swapped. The priority counter of LI node 402e may also be compared to the priority counter of LI node 402b. Since the difference between the priority counter of LI node 402e and LI node 402b is -49, the predefined threshold value is not exceeded and no further updates are needed. Again, this difference is calculated by subtracting the value of the priority counter of the LI node in the position of higher priority in the LI List 400 from the value of the priority counter of the LI node in the position of lower priority in the LI list 400.
[0048] FIGs. 5a-c illustrate states of a hybrid indexing/hashing structure for coordinating data storage between local digital memory of a UE and remote digital memory of a cloud storage system in accordance with an example. An LI list 500 may comprise LI nodes 502a-n. The LI nodes 502a-n may be indexed in the LI list 500 with indices ranging from 0 to an N-l, where there are NL1 nodes in the LI nodes 502a-n (though other ranges of
indices can be used as long as each LI node has corresponds to a respective index). The LI nodes 502a-n may be sorted in descending order with respect to priority (e.g., as measured by instance variable priority counters). There may also be a pivot index selected. In this example, the pivot index may be 2 (which corresponds to LI node 502c). The pivot index may be used to determine a cutoff priority level for data transfer from the cloud storage system to the UE.
[0049] The LI nodes 502a-n may comprise instance variable pointers to the L2 lists
504a-n, respectively, as shown in FIGs. 5a-c. Each of the L2 lists 504a-n may comprise a set of L2 nodes. For example, L2 list 504a may include L2 nodes 506a-h, L2 list 504b may include L2 nodes 507a-h, L2 list 504c may include L2 nodes 508a-h, and L2 list 504n may include L2 nodes 509a-h. Each of the L2 lists 504a-n may comprise a hash table such that each L2 node is associated with a bucket of the hash table. A hashing function of a hash table may map data entries to buckets in a manner such that data entries assigned to a common bucket have temporal locality relative to each other.
[0050] Each L2 node may comprise an instance variable pointer to a block of digital memory that may be local (e.g., at the UE) or remote (e.g., at the cloud storage system). For example, as shown in FIG. 5a, L2 nodes 506a-d may have pointers to local digital memory blocks 510a-d, respectively, while L2 nodes 506e-h may have pointers to remote digital memory blocks (depicted by a cloud in FIGs. 5a-c). In a similar fashion, L2 nodes 507a-c may include pointers to local digital memory blocks 51 la-c, respectively, and L2 nodes 507d-h may include pointers to remote digital memory blocks. L2 nodes 508a-b may include pointers to local digital memory blocks 512a-b, respectively, and L2 nodes 508c-h may include pointers to remote digital memory blocks. L2 node 509a may include a pointer to local digital memory block 513a, respectively, and L2 nodes 509b-h may include pointers to remote digital memory blocks. Each data block may be the place where data entries for the bucket corresponding to the respective L2 node are stored.
[0051] It may be determined that additional local digital memory is available for storing measurement data at the UE. A first round of data transfer from the cloud storage system to the UE as shown in FIG. 5b may commence as follows. Since LI node 502a is in the position of highest priority in the sorted LI list 500, two additional local digital memory blocks 510e-f can be allocated for measurement data of the L2 list 504a. Pointers of the L2 nodes 506e-f can be directed to the local digital memory blocks 510e-f. Existing data entries
for buckets corresponding to L2 nodes 506e-f can be downloaded from the cloud storage system and copied into the local digital memory blocks 510e-f, respectively.
[0052] Since LI node 502b is in the position of second-highest priority in the sorted
LI list 500, an additional local digital memory block 51 Id can be allocated for measurement data of the L2 list 504b. A pointer of the L2 node 507d can be directed to the local digital memory block 51 Id. Existing data entries for a bucket corresponding to L2 node 507d can be downloaded from the cloud storage system and copied into the local digital memory block 511d.
[0053] Since LI node 502c corresponds to the pivot index (i.e., LI node 502c has a sufficiently high priority), an additional local digital memory block 512c can be allocated for measurement data of the L2 list 504c. A pointer of the L2 node 508c can be directed to the local digital memory block 512c. Existing data entries for a bucket corresponding to L2 node 508c can be downloaded from the cloud storage system and copied into the local digital memory block 512c.
[0054] Since LI node 502n corresponds to an index of lower priority than the pivot index, the pointers of L2 nodes 509b-h may remain directed to remote digital memory blocks.
[0055] It may be determined that three additional blocks of local digital memory are still available for storing measurement data at the UE. A second round of data transfer from the cloud storage system to the UE as shown in FIG. 5c may commence as follows. Since LI node 502a remains in the position of highest priority in the sorted LI list 500, two additional local digital memory blocks 510g-h can be allocated for measurement data of the L2 list 504a. Pointers of the L2 nodes 506g-h can be directed to the local digital memory blocks 510g-h. Existing data entries for buckets corresponding to L2 nodes 506g-h can be downloaded from the cloud storage system and copied into the local digital memory blocks 510g-h, respectively.
[0056] Since LI node 502b is in the position of second-highest priority in the sorted
LI list 500, an additional local digital memory block 51 le can be allocated for measurement data of the L2 list 504b. A pointer of the L2 node 507e can be directed to the local digital memory block 51 le. Existing data entries for a bucket corresponding to L2 node 507e can be downloaded from the cloud storage system and copied into the local digital memory block 511e.
[0057] While LI node 502c corresponds to the pivot index (i.e., LI node 502c has a sufficiently high priority), a limit for local storage space may have been reached. Hence, no additional measurement data is downloaded from the cloud storage system.
[0058] The example shown in FIGs. 5a-c and explained above serves to demonstrate some aspects of methods and systems to coordinate storage of measurement data between a local device and a cloud storage system. For example, more local blocks may be allocated for L2 lists whose corresponding LI nodes have higher priority (as determined by the order of LI nodes in the LI list). Local blocks may be allocated on a round-by-round basis, in descending order according to priority as indicated by the indices of the LI list, for LI nodes (and their corresponding L2 lists) until no additional local digital memory is available.
[0059] FIG. 6 illustrates functionality 600 for storing data measurements for efficient retrieval in accordance with an example. The functionality can be implemented as instructions stored and executed on a machine, where the instructions are included on at least one non-transitory computer-readable storage medium.
[0060] As in block 610, the functionality 600 may include receiving, at a user equipment (UE), a data measurement taken by a sensor, wherein the data measurement was taken during a time interval.
[0061] As in block 620, the functionality 600 may include identifying a type of the data measurement.
[0062] As in block 630, the functionality 600 may include identifying a level- 1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement. The LI node may also comprise a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[0063] As in block 640, the functionality 600 may include using a hash function to determine a hash key for the data measurement.
[0064] As in block 650, the functionality 600 may include identifying a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket. The L2 node may also comprise a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2
node are queried, a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory, or a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
[0065] In some examples, the functionality 600 may also include identifying that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements. The functionality 600 may also include issuing a command for the data measurement to be stored in the block of digital memory based on the determination. The block of digital memory may be at a local device or at a remote data store.
[0066] Conversely, in other examples, the functionality 600 may also include identifying that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N. The functionality 600 may also include creating an a first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key. Further, the functionality 600 may also include associating the first expansion hash key with the bucket of the hash table and with the block of digital memory. The functionality 600 may also include associating the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory. The functionality 600 may also include issuing a command for the data measurement to be stored in the additional block of digital memory.
[0067] In some examples, additional LI nodes may be elements of the LI List, each
LI node that is an element of the LI List may comprise a respective element priority counter that is an instance variable; the LI list may be sorted based on element priority counters.
[0068] As in block 660, the functionality 600 may include determining whether there is sufficient space available in the block of digital memory for the data measurement to be stored
[0069] FIG. 7 illustrates functionality 700 for retrieving a data measurement from digital memory in accordance with an example. The functionality can be implemented as instructions stored and executed on a machine, where the instructions are included on at least one non-transitory computer-readable storage medium.
[0070] As in block 710, the functionality 700 may include receiving, at a user equipment (UE), a request for a data measurement of a specified type, wherein the data measurement was made during a time interval specified in the request.
[0071] As in block 720, the functionality 700 may include identifying a level-1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital-memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table. The LI node may comprise a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table. As in block 730, the functionality 700 may include identifying a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data measurement is stored for the bucket. The L2 node may further comprise a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory or a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE. Identifying the L2 node associated with the time interval in which the data measurement was taken may be achieved by applying a hashing function to a datum associated with the data measurement.
[0072] In some examples, additional LI nodes may be elements of the LI List, each
LI node that is an element of the LI List may comprise a respective element priority counter that is an instance variable, and the LI list can be sorted based on element priority counters. In such examples, the functionality 700 may include incrementing an element priority counter of the LI node, comparing the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List, and swapping a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node. In these examples, the functionality 700 may also include determining a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI
node in the LI list, verifying that the difference meets or exceeds a predefined threshold value, and swapping an initial position of the LI node and an initial position of the neighboring LI node in the LI list based on the verification such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
[0073] Furthermore, in such examples, additional L2 nodes may correspond to additional respective buckets in the hash table and each respective L2 node may comprise a usage counter that is an instance variable reflecting a frequency with which data
measurements stored for a respective bucket corresponding to the respective L2 node are requested. In addition, in such examples, the functionality 700 may also include comparing the resultant position of the LI node to a predefined pivot position and issuing a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
Alternatively, the functionality 700 may include comparing the resultant position of the neighboring LI node to a predefined pivot position and issuing a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
[0074] As in block 740, the functionality 700 may include issuing a command for the data measurement to be retrieved from the block of digital memory.
[0075] FIG 8 illustrates functionality 800 for coordinating storage of data
measurements between local digital memory at a UE and a remote data store in accordance with an example. The functionality can be implemented as instructions stored and executed on a machine, where the instructions are included on at least one non-transitory computer- readable storage medium.
[0076] As in block 810, the functionality 800 may include identifying a level- 1 (LI) list of level-1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data
measurements stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values.
[0077] As in block 820, the functionality 800 may include identifying a pivot index for the LI list.
[0078] As in block 830, the functionality 800 may include performing, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index (e.g., the index of the LI node with a highest priority in the LI list), the actions of block 840 and block 850. A terminal index, as used herein, may refer the index of the first node in a list or the index of a last node in a list. Hence, if the LI list is sorted in descending order according to priority, the LI node with the lowest numerical index (which is a terminal index) in the LI list may have the highest priority and the LI node with the highest numerical index (which is also a terminal index) in the LI list may have the lowest priority relative to all nodes in the list. Conversely, if the LI list is sorted in ascending order according to priority, the LI node with the lowest numerical index in the LI list may have the lowest priority and the LI node with the highest numerical index may have the highest priority.
[0079] As in block 840, the functionality 800 may include identifying a high-priority
L2 node in a hash table associated with the respective LI node.
[0080] As in block 850, the functionality 800 may include determining whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
[0081] In some examples, the functionality 800 may also include performing, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following: identifying a high-priority L2 node in a hash table associated with the at least one LI node, determining that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE, and issuing a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from the remote data store. The high-priority L2 node may have a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
[0082] In further examples, the functionality 800 may also include performing, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following: determining that data measurements of the respective bucket
corresponding to the high-priority L2 node are likely to be accessed because the data measurements in the respective bucket were taken during a range of time in which frequently- accessed data measurements were taken, and identifying the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data
measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed.
[0083] In addition, in some examples, the functionality 800 may include performing, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index (e.g., an index of an LI node with a lowest priority in the LI list), the following: identifying one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and deleting the data measurements that are stored for the buckets corresponding to the one or more L2 nodes from the local digital memory. In such examples, the functionality 800 may also include performing, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following: (1) identifying one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at the remote data store; (2) sending the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and (3) deleting the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
[0084] In some examples, the functionality 800 may include performing, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following: (1) identifying a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high-priority L2 nodes is based on a respective element priority counter value of the respective LI node; (2) determining that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and (3) issuing a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high-priority L2 nodes from the remote data store.
[0085] FIG. 9 provides an example illustration of the wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of wireless device. The wireless device can include one or more antennas configured to communicate with a (cellular network) node, macro node, low power node (LPN), or, transmission station, such as a base station (BS), an evolved Node B (eNB), a baseband processing unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WW AN) access point. The wireless device can be configured to communicate using at least one wireless communication standard including 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The wireless device can
communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WW AN. The wireless device can also comprise a wireless modem. The wireless modem can comprise, for example, a wireless radio transceiver and baseband circuitry (e.g., a baseband processor). The wireless modem can, in one example, modulate signals that the wireless device transmits via the one or more antennas and demodulate signals that the wireless device receives via the one or more antennas.
[0086] FIG. 9 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen can be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to a user. The non-volatile memory port can also be used to expand the memory capabilities of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.
[0087] Various techniques, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD- ROMs, hard drives, non-transitory computer readable storage medium, or any other machine- readable storage medium wherein, when the program code is loaded into and executed by a
machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. Circuitry can include hardware, firmware, program code, executable code, computer instructions, and/or software. A non-transitory computer readable storage medium can be a computer readable storage medium that does not include signal. In the case of program code execution on programmable computers, the computing device can include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements can be a RAM, EPROM, flash drive, optical drive, magnetic hard drive, solid state drive, or other medium for storing electronic data. The node and wireless device can also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that can implement or utilize the various techniques described herein can use an application programming interface (API), reusable controls, and the like. Such programs can be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations.
[0088] As used herein, the term processor can include general-purpose processors, specialized processors such as VLSI, FPGAs, and other types of specialized processors, as well as base-band processors used in transceivers to send, receive, and process wireless communications.
[0089] It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit (e.g., an application-specific integrated circuit (ASIC)) comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
[0090] Modules can also be implemented in software for execution by various types of processors. An identified module of executable code can, for instance, comprise one or more physical or logical blocks of computer instructions, which can, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified
module need not be physically located together, but can comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
[0091] Indeed, a module of executable code can be a single instruction, or many instructions, and can even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data can be identified and illustrated herein within modules, and can be embodied in any suitable form and organized within any suitable type of data structure. The operational data can be collected as a single data set, or can be distributed over different locations including over different storage devices, and can exist, at least partially, merely as electronic signals on a system or network. The modules can be passive or active, including agents operable to perform desired functions.
[0092] As used herein, the term "processor" can include general purpose processors, specialized processors such as VLSI, FPGAs, and other types of specialized processors, as well as base band processors used in transceivers to send, receive, and process wireless communications.
[0093] While the flowcharts presented for this technology may imply a specific order of execution, the order of execution may differ from what is illustrated. For example, the order of two more blocks may be rearranged relative to the order shown. Further, two or more blocks shown in succession may be executed in parallel or with partial parallelization. In some configurations, one or more blocks shown in the flow chart may be omitted or skipped. Any number of counters, state variables, warning semaphores, or messages may be added to the logical flow for enhanced utility, accounting, performance, measurement,
troubleshooting, or other purposes.
[0094] As used herein, the word "or" indicates an inclusive disjunction. For example, as used herein, the phrase "A or B" represents an inclusive disjunction of exemplary conditions A and B. Hence, "A or B" is false only if both condition A is false and condition B is false. When condition A is true and condition B is also true, "A or B" is also true. When condition A is true and condition B is false, "A or B" is true. When condition B is true and condition A is false, "A or B" is true. In other words, the term "or," as used herein, should not be construed as an exclusive disjunction. The term "xor" is used where an exclusive disjunction is intended.
[0095] In this disclosure, "comprises," "comprising," "containing" and "having" and the like can have the meaning ascribed to them in U.S. Patent law and can mean "includes," "including," and the like, and are generally interpreted to be open ended terms. The terms "consisting of or "consists of are closed terms, and include only the components, structures, steps, or the like specifically listed in conjunction with such terms, as well as that which is in accordance with U.S. Patent law. "Consisting essentially of or "consists essentially of have the meaning generally ascribed to them by U.S. Patent law. In particular, such terms are generally closed terms, with the exception of allowing inclusion of additional items, materials, components, steps, or elements, that do not materially affect the basic and novel characteristics or function of the item(s) used in connection therewith. For example, trace elements present in a composition, but not affecting the compositions nature or characteristics would be permissible if present under the "consisting essentially of language, even though not expressly recited in a list of items following such terminology. When using an open ended term in the specification, like "comprising" or "including," it is understood that direct support should be afforded also to "consisting essentially of language as well as "consisting of language as if stated explicitly and vice versa.
[0096] "The terms "first," "second," "third," "fourth," and the like in the description and in the claims, if any, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances such that the embodiments described herein are, for example, capable of operation in sequences other than those illustrated or otherwise described herein. Similarly, if a method is described herein as comprising a series of steps, the order of such steps as presented herein is not necessarily the only order in which such steps may be performed, and certain of the stated steps may possibly be omitted and/or certain other steps not described herein may possibly be added to the method.
[0097] Reference throughout this specification to "an example" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment. Thus, appearances of the phrases "in an example" in various places throughout this specification are not necessarily all referring to the same embodiment.
[0098] As used herein, a plurality of items, structural elements, compositional elements, and/or materials can be presented in a common list for convenience. However,
these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and examples can be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous.
[0099] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the foregoing description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of some embodiments. One skilled in the relevant art will recognize, however, that the some embodiments can be practiced without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of different embodiments.
Example Embodiments
[00100] In an exemplary embodiment there is provided, a method for storing data measurements for efficient retrieval, the method comprising:
receiving, at a user equipment (UE), a data measurement taken by a sensor, wherein the data measurement was taken during a time interval;
identifying a type of the data measurement;
identifying a level-1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement; using a hash function to determine a hash key for the data measurement;
identifying a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket; and
determining whether there is sufficient space available in the block of digital memory for the data measurement to be stored.
[00101] In one embodiment, the method of storing data can further comprise:
identifying that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and
issuing a command for the data measurement to be stored in the block of digital memory based on the determination.
[00102] In one embodiment the method of storing data can further comprise:
identifying that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
creating an a first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
associating the first expansion hash key with the bucket of the hash table and with the block of digital memory;
associating the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory; and
issuing a command for the data measurement to be stored in the additional block of digital memory.
[00103] In one embodiment of a method for storing data, the additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
[00104] In one embodiment of a method for storing data, the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[00105] In one embodiment of a method for storing data, the L2 node further comprises at least one of:
a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried;
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
[00106] In one embodiment there is provided, a method for retrieving a data measurement from digital memory, the method comprising:
receiving, at a user equipment (UE), a request for a data measurement of a specified type, wherein the data measurement was made during a time interval specified in the request; identifying a level- 1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital- memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
identifying a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital- memory address of a block of digital memory in which the data measurement is stored for the bucket; and
issuing a command for the data measurement to be retrieved from the block of digital memory.
[00107] In one embodiment of a method for retrieving data, additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
[00108] In one embodiment, the method of retrieving data further comprises:
incrementing an element priority counter of the LI node;
comparing the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List; and
swapping a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
[00109] In one embodiment the method of retrieving data further comprises:
determining a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
verifying that the difference meets or exceeds a predefined threshold value; and swapping an initial position of the LI node and an initial position of the neighboring
LI node in the LI list, based on the verification, such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring
LI node is the initial position of the LI node.
[00110] In one embodiment of a method of retrieving data, the additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
[00111] In one embodiment, the method of retrieving data further comprises:
comparing the resultant position of the LI node to a predefined pivot position; and issuing a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
[00112] In one embodiment, the method of retrieving data further comprises:
comparing the resultant position of the neighboring LI node to a predefined pivot position; and
issuing a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
[00113] In one embodiment of a method of retrieving data, identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
[00114] In one embodiment of a method of retrieving data, the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[00115] In one embodiment of a method of retrieving data, the L2 node further comprises at least one of:
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
[00116] In one embodiment, there is provided a method of coordinating storage of data measurements between local digital memory at a user equipment (UE) and a remote data store, the method comprising:
identifying a level-1 (LI) list of level-1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
identifying a pivot index for the LI list;
performing, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index, the following:
identifying a high-priority L2 node in a hash table associated with the respective LI node; and
determining whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
[00117] In one embodiment, the method of coordinating storage of data measurements further comprises:
performing, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identifying a high-priority L2 node in a hash table associated with the at least one LI node;
determining that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE; and
issuing a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from the remote data store.
[00118] In one embodiment of a method of coordinating storage of data measurements, the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
[00119] In one embodiment of a method of coordinating storage of data measurements, the method further comprises:
performing, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
determining that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed because the data measurements in the respective bucket were taken during a range of time in which frequently- accessed data measurements were taken; and
identifying the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed.
[00120] In one embodiment, the method of coordinating storage of data measurements further comprises:
performing, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index, the following:
identifying one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE; and
deleting the data measurements that are stored for the buckets corresponding to the one or more L2 nodes from the local digital memory.
[00121] In one embodiment, the method of coordinating storage of data measurements further comprises:
performing, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following:
identifying one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for
which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at the remote data store;
sending the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and
deleting the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
[00122] In one embodiment, the method of coordinating storage of data measurements further comprises:
performing, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identifying a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high-priority L2 nodes is based on a respective element priority counter value of the respective LI node;
determining that data measurements of a plurality of respective buckets
corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and
issuing a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high-priority L2 nodes from the remote data store.
[00123] In an example embodiment there is provided a system for storing data, the system comprising:
a sensor configured to gather data; and
a user equipment (UE) configured to receive data from the sensor, said UE
comprising circuitry configured to:
receive, a data measurement taken by the sensor, wherein the data measurement was taken during a time interval;
identify a type of the data measurement;
identify a level-1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement; use a hash function to determine a hash key for the data measurement;
identify a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket; and
determine whether there is sufficient space available in the block of digital memory for the data measurement to be stored.
[00124] In one embodiment of a system for storing data, the circuitry is further configured to:
identify that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and
issue a command for the data measurement to be stored in the block of digital memory based on the determination.
[00125] In one embodiment of a system for storing data, the circuitry is further configured to:
identify that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
create a first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
associate the first expansion hash key with the bucket of the hash table and with the block of digital memory;
associate the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory; and
issue a command for the data measurement to be stored in the additional block of digital memory.
[00126] In one embodiment of a system for storing data, additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
[00127] In one embodiment of a system for storing data, the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[00128] In one embodiment of a system for storing data, the L2 node further comprises at least one of:
a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried;
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data
measurements stored in the block of digital memory are stored remotely relative to the UE.
[00129] In an example embodiment, a system for retrieving data is provided, the system
comprising:
a sensor configured to gather data; and
a user equipment (UE) configured to receive data from the sensor, said UE comprising circuitry configured to:
receive a request for a data measurement of a specified type, wherein the data measurement was made by the sensor during a time interval specified in the request; identify a level- 1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital- memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
identify a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data
measurement is stored for the bucket; and
issue a command for the data measurement to be retrieved from the block of digital memory.
[00130] In one embodiment of a system for retrieving data, additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
[00131] In one embodiment of a system for retrieving data, the circuitry is further configured to:
increment an element priority counter of the LI node;
compare the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List; and
swap a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
[00132] In one embodiment of a system for retrieving data, the circuitry is further configured to:
determine a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
verifying that the difference meets or exceeds a predefined threshold value; and swap an initial position of the LI node and an initial position of the neighboring LI node in the LI list, based on the verification, such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
[00133] In one embodiment of a system for retrieving data, additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
[00134] In one embodiment of a system for retrieving data, the circuitry is further configured to:
compare the resultant position of the LI node to a predefined pivot position; and issue a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
[00135] In one embodiment of a system for retrieving data, the circuitry is further configured to:
compare the resultant position of the neighboring LI node to a predefined pivot position; and
issue a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
[00136] In one embodiment of a system for retrieving data, identifying the L2 node
associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
[00137] In one embodiment of a system for retrieving data, the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[00138] In one embodiment of a system for retrieving data, the L2 node further comprises at least one of:
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data
measurements stored in the block of digital memory are stored remotely relative to the UE.
[00139] In another example embodiment, a system for coordinating storage of data
measurements is provided, the system comprising:
one or more sensors configured to make data measurements;
a user equipment (UE) configured to receive data from the one or more sensors, the UE comprising local digital memory and circuitry configured to:
identify a level-1 (LI) list of level- 1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data
measurements made by the one or more sensors and stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
identify a pivot index for the LI list;
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the respective LI node; and
determine whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
[00140] In one embodiment of a system for coordinating storage of data measurements, the circuitry is further configured to:
perform, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the at least one LI node;
determine that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from a remote data store.
[00141] In one embodiment of a system for coordinating storage of data measurements, the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
[00142] In one embodiment of a system for coordinating storage of data measurements, the circuitry is further configured to:
perform, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
determine that data measurements of the respective bucket
corresponding to the high-priority L2 node are likely to be accessed because
the data measurements in the respective bucket were taken during a range of time in which frequently-accessed data measurements were taken; and
identify the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed.
[00143] In one embodiment of a system for coordinating storage of data measurements, the circuitry is further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index, the following:
identify one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE; and
delete the data measurements that are stored for the buckets
corresponding to the one or more L2 nodes from the local digital memory.
[00144] In one embodiment of a system for coordinating storage of data measurements, the circuitry is further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following:
identify one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at a remote data store;
send the data measurements that are stored for the buckets
corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and
delete the data measurements that are stored for the buckets
corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
[00145] In one embodiment of a system for coordinating storage of data measurements, the circuitry is further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high-priority L2 nodes is based on a respective element priority counter value of the respective LI node; determine that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high-priority L2 nodes from a remote data store.
[00146] In an example embodiment, a user equipment (UE) is provided, the UE comprising one or more processors configured to:
receive, a data measurement taken by the sensor, wherein the data measurement was taken during a time interval;
identify a type of the data measurement;
identify a level- 1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement;
use a hash function to determine a hash key for the data measurement;
identify a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket; and
determine whether there is sufficient space available in the block of digital memory for the data measurement to be stored.
[00147] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
identify that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and
issue a command for the data measurement to be stored in the block of digital memory based on the determination.
[00148] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
identify that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
create a first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
associate the first expansion hash key with the bucket of the hash table and with the block of digital memory;
associate the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory; and
issue a command for the data measurement to be stored in the additional block of digital memory.
[00149] In one embodiment of a user equipment (UE), additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
[00150] In one embodiment of a user equipment (UE), the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[00151] In one embodiment of a user equipment (UE), the L2 node further comprises at least one of:
a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried;
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
[00152] In an example embodiment, a user equipment (UE) is provided, the UE comprising one or more processors configured to:
receive a request for a data measurement of a specified type, wherein the data measurement was made by the sensor during a time interval specified in the request; identify a level- 1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital- memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
identify a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data
measurement is stored for the bucket; and
issue a command for the data measurement to be retrieved from the block of digital memory.
[00153] In one embodiment of a user equipment (UE), additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
[00154] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
increment an element priority counter of the LI node;
compare the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List; and
swap a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
[00155] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
determine a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
verifying that the difference meets or exceeds a predefined threshold value; and swap an initial position of the LI node and an initial position of the neighboring LI node in the LI list, based on the verification, such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
[00156] In one embodiment of a user equipment (UE), additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
[00157] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
compare the resultant position of the LI node to a predefined pivot position; and issue a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
[00158] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
compare the resultant position of the neighboring LI node to a predefined pivot position; and
issue a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
[00159] In one embodiment of a user equipment (UE), identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
[00160] In one embodiment of a user equipment (UE), the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
[00161] In one embodiment of a user equipment (UE), the L2 node further comprises at least one of:
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data
measurements stored in the block of digital memory are stored remotely relative to the UE.
[00162] In an example embodiment, a user equipment (UE) is provided, the UE comprising local digital memory and one or more processors configured to:
identify a level-1 (LI) list of level- 1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level-2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements made by the one or more sensors and stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
identify a pivot index for the LI list;
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the respective LI node; and
determine whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
[00163] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
perform, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the at least one LI node;
determine that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from a remote data store.
[00164] In one embodiment of a user equipment (UE), the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
[00165] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
perform, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
determine that data measurements of the respective bucket
corresponding to the high-priority L2 node are likely to be accessed because the data measurements in the respective bucket were taken during a range of time in which frequently-accessed data measurements were taken; and
identify the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed.
[00166] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index, the following:
identify one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE; and
delete the data measurements that are stored for the buckets
corresponding to the one or more L2 nodes from the local digital memory.
[00167] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following:
identify one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to
buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at a remote data store;
send the data measurements that are stored for the buckets
corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and
delete the data measurements that are stored for the buckets
corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
[00168] In one embodiment of a user equipment (UE), the one or more processors are further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high-priority L2 nodes is based on a respective element priority counter value of the respective LI node; determine that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high-priority L2 nodes from a remote data store.
[00169] While the forgoing examples are illustrative of the principles used in various embodiments in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the embodiments. Accordingly, it is not intended that the technology be limited, except as by the claims set forth below.
Claims
1. A method for storing data measurements for efficient retrieval, the method comprising:
receiving, at a user equipment (UE), a data measurement taken by a sensor, wherein the data measurement was taken during a time interval;
identifying a type of the data measurement;
identifying a level- 1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement;
using a hash function to determine a hash key for the data measurement;
identifying a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital- memory address of a block of digital memory for the bucket; and
determining whether there is sufficient space available in the block of digital memory for the data measurement to be stored.
2. The method of claim 1, further comprising:
identifying that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and
issuing a command for the data measurement to be stored in the block of digital memory based on the determination.
3. The method of claim 1, further comprising;
identifying that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of
digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
creating an a first expansion hash key comprising N+l bits and a second expansion hash key having N+l bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key;
associating the first expansion hash key with the bucket of the hash table and with the block of digital memory;
associating the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory; and
issuing a command for the data measurement to be stored in the additional block of digital memory.
4. The method of claim 1, wherein additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
5. The method of claim 1, wherein the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
6. The method of claim 1, wherein the L2 node further comprises at least one of:
a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried; a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
7. A method for retrieving a data measurement from digital memory, the method comprising: receiving, at a user equipment (UE), a request for a data measurement of a specified type, wherein the data measurement was made during a time interval specified in the request;
identifying a level- 1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital-memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
identifying a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital-memory address of a block of digital memory in which the data measurement is stored for the bucket; and
issuing a command for the data measurement to be retrieved from the block of digital memory.
8. The method of claim 7, wherein additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
9. The method of claim 8, further comprising:
incrementing an element priority counter of the LI node;
comparing the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List; and
swapping a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
10. The method of claim 9, further comprising:
determining a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
verifying that the difference meets or exceeds a predefined threshold value; and
swapping an initial position of the LI node and an initial position of the neighboring LI node in the LI list, based on the verification, such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
11. The method of claim 9, wherein additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
12. The method of claim 11, further comprising:
comparing the resultant position of the LI node to a predefined pivot position; and
issuing a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
13. The method of 11, further comprising:
comparing the resultant position of the neighboring LI node to a predefined pivot position; and
issuing a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
14. The method of claim 7, wherein identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
15. The method of claim 7, wherein the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
16. The method of claim 7, wherein the L2 node further comprises at least one of:
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the
UE.
17. A method of coordinating storage of data measurements between local digital memory at a user equipment (UE) and a remote data store, the method comprising:
identifying a level-1 (LI) list of level- 1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level -2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
identifying a pivot index for the LI list;
performing, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index, the following:
identifying a high-priority L2 node in a hash table associated with the respective LI node; and
determining whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
18. The method of claim 17, further comprising:
performing, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identifying a high-priority L2 node in a hash table associated with the at least one LI node;
determining that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE; and
issuing a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from the remote data store.
19. The method of claim 18, wherein the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
20. The method of claim 18, further comprising:
performing, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
determining that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed because the data measurements in the respective bucket were taken during a range of time in which frequently-accessed data
measurements were taken; and
identifying the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed.
21. The method of claim 17, further comprising:
performing, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index, the following:
identifying one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE; and
deleting the data measurements that are stored for the buckets corresponding to the one or more L2 nodes from the local digital memory.
22. The method of claim 21, further comprising:
performing, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following:
identifying one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at the remote data store;
sending the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and
deleting the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
23. The method of claim 17, further comprising:
performing, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identifying a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high- priority L2 nodes is based on a respective element priority counter value of the respective LI node;
determining that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and
issuing a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high- priority L2 nodes from the remote data store.
24. A system for storing data, the system comprising:
a sensor configured to gather data; and
a user equipment (UE) configured to receive data from the sensor, said UE
comprising circuitry configured to:
receive a data measurement taken by the sensor, wherein the data measurement was taken during a time interval;
identify a type of the data measurement;
identify a level-1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement; use a hash function to determine a hash key for the data measurement;
identify a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket; and
determine whether there is sufficient space available in the block of digital memory for the data measurement to be stored.
25. The system of claim 24, wherein the circuitry is further configured to:
identify that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and
issue a command for the data measurement to be stored in the block of digital memory based on the determination.
26. The system of claim 24, further wherein the circuitry is further configured to:
identify that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
create a first expansion hash key comprising N+1 bits and a second expansion hash key having N+1 bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key; associate the first expansion hash key with the bucket of the hash table and with the block of digital memory;
associate the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory; and
issue a command for the data measurement to be stored in the additional block of digital memory.
27. The system of claim 24, wherein additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
28. The system of claim 24, wherein the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
29. The system of claim 24, wherein the L2 node further comprises at least one of:
a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried; a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
30. A system for retrieving data, the system comprising:
a sensor configured to gather data; and
a user equipment (UE) configured to receive data from the sensor, said UE
comprising circuitry configured to:
receive a request for a data measurement of a specified type, wherein the data measurement was made by the sensor during a time interval specified in the request;
identify a level-1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital-memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
identify a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital- memory address of a block of digital memory in which the data measurement is stored for the bucket; and
issue a command for the data measurement to be retrieved from the block of digital memory.
31. The system of claim 30, wherein additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
32. The system of claim 31, wherein the circuitry is further configured to:
increment an element priority counter of the LI node;
compare the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List; and
swap a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
33. The system of claim 32, wherein the circuitry is further configured to:
determine a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
verifying that the difference meets or exceeds a predefined threshold value; and
swap an initial position of the LI node and an initial position of the neighboring LI node in the LI list, based on the verification, such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
34. The system of claim 32, wherein additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
35. The system of claim 34, wherein the circuitry is further configured to:
compare the resultant position of the LI node to a predefined pivot position; and issue a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
36. The system of claim 34, wherein the circuitry is further configured to:
compare the resultant position of the neighboring LI node to a predefined pivot position; and
issue a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
37. The system of claim 30, wherein identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
38. The system of claim 30, wherein the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
39. The system of claim 30, wherein the L2 node further comprises at least one of:
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
40. A system for coordinating storage of data measurements, the system comprising:
one or more sensors configured to make data measurements;
a user equipment (UE) configured to receive data from the one or more sensors, the UE comprising local digital memory and circuitry configured to:
identify a level-1 (LI) list of level-1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level -2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements made by the one or more sensors and stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
identify a pivot index for the LI list;
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the respective LI node; and
determine whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
41. The system of claim 40, wherein the UE further comprises circuitry configured to:
perform, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the at least one LI node;
determine that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from a remote data store.
42. The system of claim 41, wherein the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
43. The system of claim 41, wherein the UE further comprises circuitry configured to:
perform, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
determine that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed because the data measurements in the respective bucket were taken during a range of time in which frequently-accessed data
measurements were taken; and
identify the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data measurements of the respective bucket corresponding to the high- priority L2 node are likely to be accessed.
44. The system of claim 40, wherein the UE further comprises circuitry configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index, the following:
identify one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE; and
delete the data measurements that are stored for the buckets corresponding to the one or more L2 nodes from the local digital memory.
45. The system of claim 44, wherein the UE further comprises circuitry configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following:
identify one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at a remote data store;
send the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and
delete the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
46. The system of claim 40, wherein the UE further comprises circuitry configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high- priority L2 nodes is based on a respective element priority counter value of the respective LI node;
determine that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high- priority L2 nodes from a remote data store.
47. A user equipment (UE) comprising one or more processors configured to:
receive a data measurement taken by a sensor, wherein the data measurement was taken during a time interval;
identify a type of the data measurement;
identify a level-1 (LI) node associated with the type of the data measurement, wherein a level-1 (LI) list comprises the LI node and the LI node comprises an indicator of a digital-memory address of a hash table associated with the type of the data measurement; use a hash function to determine a hash key for the data measurement;
identify a level-2 (L2) node associated with the time interval in which the data measurement was taken, wherein the L2 node corresponds to a bucket of the hash table associated with the hash key and the L2 node comprises an indicator of a digital-memory address of a block of digital memory for the bucket; and
determine whether there is sufficient space available in the block of digital memory for the data measurement to be stored.
48. The UE of claim 47, wherein the one or more processors are further configured to: identify that there is sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements; and
issue a command for the data measurement to be stored in the block of digital memory based on the determination.
49. The UE of claim 47, wherein the one or more processors are further configured to: identify that there is not sufficient space available in the block of digital memory for the data measurement to be stored therein, wherein the block of digital memory is of a predefined size and the predefined size is sufficient for the block of digital memory to store one or more data measurements, and wherein the hash key comprises a predefined number of bits N;
create a first expansion hash key comprising N+1 bits and a second expansion hash key having N+1 bits, wherein the first expansion hash key and the second expansion hash key have differing most-significant-bit values and the remaining N bits of both the first expansion hash key and the second expansion hash key have values equal to the N bits of the hash key; associate the first expansion hash key with the bucket of the hash table and with the block of digital memory;
associate the second expansion hash key with an additional bucket of the hash table and with an additional block of digital memory; and
issue a command for the data measurement to be stored in the additional block of digital memory.
50. The UE of claim 47, wherein additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
51. The UE of claim 47, wherein the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
52. The UE of claim 47, wherein the L2 node further comprises at least one of:
a usage counter that is an instance variable reflecting a frequency with which data measurements stored for the bucket corresponding to the L2 node are queried; a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
53. A user equipment (UE) comprising one or more processors configured to:
receive a request for a data measurement of a specified type, wherein the data measurement was made by a sensor during a time interval specified in the request;
identify a level-1 (LI) node associated with the specified type, wherein the LI node is an element of a level-1 (LI) list, the LI node comprises an indicator of a digital-memory address of a hash table associated with the specified type, and the data measurement is accessible through the hash table;
identify a level-2 (L2) node associated with the time interval, wherein the L2 node corresponds to a bucket of the hash table and the L2 node comprises an indicator of a digital- memory address of a block of digital memory in which the data measurement is stored for the bucket; and
issue a command for the data measurement to be retrieved from the block of digital memory.
54. The UE of claim 53, wherein additional LI nodes are elements of the LI List, each LI node that is an element of the LI List comprises a respective element priority counter that is an instance variable, and the LI list is sorted based on element priority counters.
55. The UE of claim 54, wherein the one or more processors are further configured to: increment an element priority counter of the LI node;
compare the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI List; and
swap a position of the LI node and a position of the neighboring node in the LI list based on the comparison of the element priority counter of the LI node to the element priority counter of the neighboring LI node.
56. The UE of claim 55, wherein the one or more processors are further configured to: determine a difference between the element priority counter of the LI node to an element priority counter of a neighboring LI node in the LI list;
verifying that the difference meets or exceeds a predefined threshold value; and
swap an initial position of the LI node and an initial position of the neighboring LI node in the LI list, based on the verification, such that a resultant position of the LI node is the initial position of the neighboring LI node and a resultant position of the neighboring LI node is the initial position of the LI node.
57. The UE of claim 55, wherein additional L2 nodes correspond to additional respective buckets in the hash table and each respective L2 node comprises a usage counter that is an instance variable reflecting a frequency with which data measurements stored for a respective bucket corresponding to the respective L2 node are requested.
58. The UE of claim 57, wherein the one or more processors are further configured to: compare the resultant position of the LI node to a predefined pivot position; and issue a command for a plurality of data measurements accessible through the hash table to be downloaded via a network connection and stored in a local block of digital
memory at the UE based on the comparison of the resultant position of the LI node to the predefined pivot position.
59. The UE of claim 57, wherein the one or more processors are further configured to: compare the resultant position of the neighboring LI node to a predefined pivot position; and
issue a command for a plurality of data measurements accessible through a hash referenced by the neighboring LI node to be uploaded via a network connection and stored in a remote block of digital memory based on the comparison of the resultant position of the neighboring LI node to the predefined pivot position.
60. The UE of claim 53, wherein identifying the L2 node associated with the time interval in which the data measurement was taken is achieved by applying a hashing function to a datum associated with the data measurement.
61. The UE of claim 53, wherein the LI node further comprises a size instance variable indicating an amount of digital memory being used to store data measurements that are accessible through the hash table.
62. The UE of claim 53, wherein the L2 node further comprises at least one of:
a size instance variable indicating an amount of digital memory being used to store data measurements in the block of digital memory; or
a remote-storage-availability instance variable indicating whether data measurements stored in the block of digital memory are stored remotely relative to the UE.
63. A user equipment (UE) comprising local digital memory and one or more processors configured to:
identify a level-1 (LI) list of level-1 (LI) nodes, wherein each respective LI node comprises a respective element priority counter that is an instance variable indicating a frequency with which a respective hash table associated with the respective LI node is accessed, wherein each hash table comprises level -2 (L2) nodes corresponding to buckets, wherein each L2 node comprises a respective usage counter that is an instance variable reflecting a frequency with which data measurements
made by one or more sensors and stored for the respective bucket are accessed, and wherein the LI nodes are sorted in the LI list according to element priority counter values;
identify a pivot index for the LI list;
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the respective LI node; and
determine whether data measurements of a respective bucket corresponding to the high-priority L2 node are stored in the local digital memory at the UE.
64. The UE of claim 63, wherein the one or more processors are further configured to:
perform, for at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a high-priority L2 node in a hash table associated with the at least one LI node;
determine that data measurements of a respective bucket corresponding to the high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the respective bucket corresponding to the high-priority L2 node from a remote data store.
65. The UE of claim 64, wherein the high-priority L2 node has a usage counter with a value indicating that data measurements stored for the respective bucket corresponding to the high-priority L2 node are accessed frequently.
66. The UE of claim 64, wherein the one or more processors are further configured to:
perform, for the at least one LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
determine that data measurements of the respective bucket corresponding to the high-priority L2 node are likely to be accessed
because the data measurements in the respective bucket were taken during a range of time in which frequently-accessed data
measurements were taken; and
identify the high-priority L2 node in the hash table associated with the at least one LI node based on the determination that data measurements of the respective bucket corresponding to the high- priority L2 node are likely to be accessed.
67. The UE of claim 63, wherein the one or more processors are further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to a second terminal index, the following:
identify one or more L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE; and
delete the data measurements that are stored for the buckets corresponding to the one or more L2 nodes from the local digital memory.
68. The UE of claim 67, wherein the one or more processors are further configured to:
perform, for each respective LI node having an index in the LI list ranging from the pivot index to the second terminal index, the following:
identify one or more non-backed-up L2 nodes in a hash table associated with the respective LI node, wherein the one or more L2 nodes correspond to buckets for which data measurements are stored in the local digital memory at the UE, and wherein each L2 node comprises an instance variable indicating whether the respective L2 node is backed up at a remote data store;
send the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes to the remote data store via a network connection; and
delete the data measurements that are stored for the buckets corresponding to the one or more non-backed-up L2 nodes from the local digital memory.
The UE of claim 63, wherein the one or more processors are further configured to: perform, for each respective LI node having an index in the LI list ranging from the pivot index to the first terminal index, the following:
identify a number of high-priority L2 nodes in a hash table associated with the respective LI node, wherein the number of high- priority L2 nodes is based on a respective element priority counter value of the respective LI node;
determine that data measurements of a plurality of respective buckets corresponding to the plurality of high-priority L2 node are not stored in the local digital memory at the UE; and
issue a request to download the data measurements of the plurality of respective buckets corresponding to the plurality of high- priority L2 nodes from a remote data store.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/866,711 | 2015-09-25 | ||
| US14/866,711 US20170090814A1 (en) | 2015-09-25 | 2015-09-25 | Efficient storage and retrieval for wearable-device data |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2017053059A1 true WO2017053059A1 (en) | 2017-03-30 |
Family
ID=56979647
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/US2016/050445 Ceased WO2017053059A1 (en) | 2015-09-25 | 2016-09-06 | Efficient storage and retrieval for wearable-device data |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20170090814A1 (en) |
| TW (1) | TWI731870B (en) |
| WO (1) | WO2017053059A1 (en) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9094715B2 (en) | 2009-05-29 | 2015-07-28 | Cognitive Networks, Inc. | Systems and methods for multi-broadcast differentiation |
| US9449090B2 (en) * | 2009-05-29 | 2016-09-20 | Vizio Inscape Technologies, Llc | Systems and methods for addressing a media database using distance associative hashing |
| US9935831B1 (en) * | 2014-06-03 | 2018-04-03 | Big Switch Networks, Inc. | Systems and methods for controlling network switches using a switch modeling interface at a controller |
| WO2016123495A1 (en) | 2015-01-30 | 2016-08-04 | Vizio Inscape Technologies, Llc | Methods for identifying video segments and displaying option to view from an alternative source and/or on an alternative device |
| BR112018000716B1 (en) | 2015-07-16 | 2023-03-28 | Inscape Data, Inc | COMPUTING METHOD AND DEVICE FOR DETECTING COMMON MEDIA SEGMENTS |
| JP6763019B2 (en) | 2015-07-16 | 2020-09-30 | インスケイプ データ インコーポレイテッド | Systems and methods for partitioning search indexes to improve media segment identification efficiency |
| MX384108B (en) | 2015-07-16 | 2025-03-14 | Inscape Data Inc | SYSTEM AND METHOD FOR IMPROVING WORKLOAD MANAGEMENT IN THE ACR TELEVISION MONITORING SYSTEM. |
| KR20170056331A (en) * | 2015-11-13 | 2017-05-23 | 한국전자통신연구원 | Information processing system and method for information processing thereof |
| US11237828B2 (en) * | 2016-04-26 | 2022-02-01 | Onnivation, LLC | Secure matrix space with partitions for concurrent use |
| US9992094B1 (en) * | 2016-06-27 | 2018-06-05 | Amazon Technologies, Inc. | Adaptive forwarding tables |
| US11055300B2 (en) | 2016-09-26 | 2021-07-06 | Splunk Inc. | Real-time search techniques |
| KR101961562B1 (en) * | 2016-10-20 | 2019-03-22 | 영남대학교 산학협력단 | Method for Hash-Join and computer program, and storage medium operating thereof |
| CN108874804B (en) * | 2017-05-09 | 2020-01-14 | 广东神马搜索科技有限公司 | Data storage method, data query method and device |
| US11461027B2 (en) * | 2017-07-18 | 2022-10-04 | Vmware, Inc. | Deduplication-aware load balancing in distributed storage systems |
| US10978018B2 (en) | 2018-05-29 | 2021-04-13 | Samsung Electronics Co., Ltd. | Virtual reality resource management for virtual reality head mounted display devices |
| US11777712B2 (en) * | 2019-03-22 | 2023-10-03 | International Business Machines Corporation | Information management in a database |
| US10976965B1 (en) * | 2020-10-14 | 2021-04-13 | First Capitol Consulting, Inc. | Optimization of in-memory processing of data represented by an acyclic graph so that the removal and re-materialization of data in selected nodes is minimized |
| US12131200B2 (en) * | 2021-07-01 | 2024-10-29 | EMC IP Holding Company LLC | Balanced winner assignment for deadlock resolution |
| TWI816424B (en) * | 2022-06-08 | 2023-09-21 | 啟碁科技股份有限公司 | Data processing method and mirror server for low-power wireless personal area network system |
| CN117331900B (en) * | 2022-06-23 | 2026-03-24 | 启碁科技股份有限公司 | Data processing methods and mirror servers |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6516320B1 (en) * | 1999-03-08 | 2003-02-04 | Pliant Technologies, Inc. | Tiered hashing for data access |
| US7593034B2 (en) * | 2006-08-31 | 2009-09-22 | Dekeyser Paul | Loop recording with book marking |
| US20110038290A1 (en) * | 2009-08-11 | 2011-02-17 | Michelle Xiaohong Gong | Device, system and method of power management in a wireless area network |
| US8983460B2 (en) * | 2012-09-10 | 2015-03-17 | Intel Corporation | Sensor and context based adjustment of the operation of a network controller |
| US9009206B1 (en) * | 2012-11-20 | 2015-04-14 | Netapp, Inc. | Method and system for optimizing traversal and storage of directory entries of a storage volume |
| US20140337375A1 (en) * | 2013-05-07 | 2014-11-13 | Exeray Inc. | Data search and storage with hash table-based data structures |
| US9986569B2 (en) * | 2015-03-18 | 2018-05-29 | Microsoft Technology Licensing, Llc | Battery-backed RAM for wearable devices |
-
2015
- 2015-09-25 US US14/866,711 patent/US20170090814A1/en not_active Abandoned
-
2016
- 2016-08-22 TW TW105126791A patent/TWI731870B/en not_active IP Right Cessation
- 2016-09-06 WO PCT/US2016/050445 patent/WO2017053059A1/en not_active Ceased
Non-Patent Citations (2)
| Title |
|---|
| AMAZON: "Amazon SimpleDB Developer Guide API Version 2009-04-15", 15 April 2009 (2009-04-15), pages 1 - 102, XP055320926, Retrieved from the Internet <URL:http://web.archive.org/web/20140923090501/http://awsdocs.s3.amazonaws.com/SDB/latest/sdb-dg.pdf> [retrieved on 20161118] * |
| NICHOLAS LANE ET AL: "Enabling large-scale human activity inference on smartphones using community similarity networks (csn)", PROCEEDINGS OF THE 13TH INTERNATIONAL CONFERENCE ON UBIQUITOUS COMPUTING, 17 September 2011 (2011-09-17), pages 355 - 364, XP055134486, ISBN: 978-1-45-030630-0, DOI: 10.1145/2030112.2030160 * |
Also Published As
| Publication number | Publication date |
|---|---|
| TW201723867A (en) | 2017-07-01 |
| TWI731870B (en) | 2021-07-01 |
| US20170090814A1 (en) | 2017-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2017053059A1 (en) | Efficient storage and retrieval for wearable-device data | |
| CN111225110B (en) | Mobile communication terminal and method for recommending application or content | |
| AU2017430719B2 (en) | Information transmission method and related product | |
| JP2021531695A (en) | PDCCH monitoring method, terminals and network equipment | |
| US20190205250A1 (en) | Method and device for processing a memory and storage medium | |
| EP2997444A1 (en) | Techniques for natural user interface input based on context | |
| CN108363750B (en) | Clothing recommendation method and related products | |
| CN104850507A (en) | Data caching method and data caching device | |
| WO2014019396A1 (en) | Method and apparatus for switching software interface of a mobile terminal | |
| US11099898B2 (en) | Method for allocating memory resources and terminal device | |
| CN107402813A (en) | The method and mobile terminal of a kind of resource allocation, computer-readable recording medium | |
| WO2018223772A1 (en) | Content recommendation method and system | |
| CN110139390A (en) | Resource scheduling indication method, terminal and the network equipment | |
| WO2015188765A1 (en) | Url error-correcting method, server, terminal and system | |
| CN109062680A (en) | A kind of data load method, device and storage medium | |
| CA3063221C (en) | Timing method for synchronization signal block, and related product | |
| CN110166191B (en) | Method and device for determining monitoring information of search space | |
| KR20230035715A (en) | Search space channel estimation number allocation method and terminal device | |
| EP2775703A1 (en) | Method and apparatus for managing crowd sourced content creation | |
| US20120317408A1 (en) | Method and Apparatus for Changing an Operational Characteristic of a Device in Order to Adjust the Power Consumption Level | |
| CN110704188B (en) | Memory allocator optimization method, device, equipment and storage medium | |
| CN116155445B (en) | Uplink precoding information receiving method, indication method, terminal and network side equipment | |
| CN107257550B (en) | Signal processing method, base station and computer storage medium | |
| TW201442483A (en) | System and method of smart switching dual-SIM phone | |
| US12588042B2 (en) | Method for distributed compute operation across connected devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 16770126 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 16770126 Country of ref document: EP Kind code of ref document: A1 |