210 may additionally and/or alternatively access other data from the control frames (e.g., the data seen in the example table 400 of FIG. 4 further discussed below). In some examples, the control frame receiver 210 implements means for capturing.

The example interval timer 220 of the illustrated example of FIG. 2 keeps track of the time period for determining the virtual bandwidth. The example interval timer 220 determines when a time period for determining the virtual bandwidth has elapsed. In examples disclosed herein, the time period is substantially five minutes. That is, the length of time may be any amount of time within thirty seconds of five minutes (e.g., within ten percent of five minutes). However, any other lengths of time may additionally and/or alternatively be used as the time period. The example interval timer 220 keeps track of the amount of time that the control frames are being captured before calculating the virtual bandwidth. In some examples, the interval timer 220 implements means for controlling.

The example bitrate calculator 230 of the illustrated example of FIG. 2 calculates the bitrate using the data in the captured control frames. The example bitrate calculator 230 uses the bitmap data and the amount of time since the last received control frame data from the control frame accessed by the example control frame receiver 210. In examples disclosed herein, the bitmap is the number of acknowledged data frames between the control frame and a previously captured control frame. The example bitrate calculator 230 divides the bitmap by the amount of time since the last received control frame to determine the bitrate for the control frame captured by the example control frame receiver 210. In some examples, the bitrate calculator 230 implements means for calculating.

The example virtual bandwidth calculator 240 of the illustrated example of FIG. 2 calculates the virtual bandwidth using the data from the control frames captured during the time period. The example virtual bandwidth calculator 240 determines the average bitrate from the control frames received in the time period. The example virtual bandwidth calculator 240 uses the bitrate data captured for each control frame by the example control frame receiver 210 and the amount of time of the time period that is determined by the example interval timer 220. The example virtual bandwidth calculator 240 sums the bitrates from the captured control frames and divides the sum by the total amount of control frames captured in the time period to determine the average bitrate. However, the example virtual bandwidth calculator 240 may additionally and/or alternatively use other averaging methods to determine the average bitrate. The example virtual bandwidth calculator 240 divides the average bitrate by the time period from the example interval timer 220 to determine the virtual bandwidth for the time period. In some examples, the virtual bandwidth event calculator 240 implements means for calculating.

The example virtual bandwidth event generator 250 of the illustrated example of FIG. 2 generates bandwidth events for the virtual bandwidths calculated by the example virtual bandwidth calculator 240. The example virtual bandwidth event generator 250 determines if the calculated virtual bandwidth is greater than zero. The example virtual bandwidth event generator 250 generates the bandwidth event when the virtual bandwidth calculated by the example virtual bandwidth calculator 240 is greater than zero. The example virtual bandwidth event generator 250 provides the bandwidth event to the example streaming probability determiner 145 of FIG. 1 to be used in determining the likelihood that the example user device(s) 110A, 110B, 110C, 110D are streaming media during each time period. In some examples, the virtual bandwidth event generator 250 implements means for generating.

FIGS. 3A and 3B are example representations of a transmission message 310 from user device(s) 110A, 110B, 110C, 110D to a household (HH) access point (A/P) in the example internal network 115 and an example representation of a response message 320 from the HH A/P in the example internal network 115 to the user device(s) 110A, 110B, 110C, 110D. In examples disclosed herein, the user device(s) 110A, 110B, 110C, 110D send quality of service (QoS) data frames in the transmission message 310 of FIG. 3A with a traffic identifier (TID) of 0 and the acknowledgment (ACK) policy of “normal ACK”. In examples disclosed herein, the receiver in the internal network 115 will implicitly acknowledge (because of acknowledgement policy discussed above) with a BlockAck frame carrying the SSN that the user device(s) 110A, 110B, 110C, 110D sent and a bitmap that contains the received packets.

In examples disclosed herein, the bitmap along with the SSN indicates the packets that are being acknowledged by the example internal network 115, where each bit acknowledges one packet and the sequence number of the packet is equal to the starting sequence number plus the bit number. For example, as seen in the example response message 320 of FIG. 3B, the SSN of 2214 and the bitmap of FF7F000000000000 indicate that this example control (BlockAck) frame acknowledged 15 data frame packets from the user device(s) 110A, 110B, 110C, 110D successfully (number of set bits in bitmap). In examples disclosed herein, messages 310 and 320 are exchanged multiple times with the user device(s) 110A, 110B, 110C, 110D sending a several QoS data frames and the receiver on the internal network 115 acknowledging all of the QoS data frames in a single BlockAck frame.

FIG. 4 is an example table representation of information determined by the example virtual bandwidth event detector 125 of FIG. 1. The example virtual bandwidth event detector 125 of FIG. 1 received control (BlockAck) frames and parses the information contained in each frame. The example virtual bandwidth event detector 125 of FIG. 1 also performs calculations to determine virtual bandwidth. The example Table 400 of FIG. 4 includes the information determined by the virtual bandwidth event detector 125 of FIG. 1. Example table 400 includes information from example BlockAck Frames 440-465. For each example BlockAck Frames 440-465 of FIG. 4, the example SSN 410, example time 415, example total time 420, count (bitmap) 425, total count 430, and bitrate 435 are determined.

In the example table 400 of FIG. 4, the example SSN 410 is the starting sequence number of the data packets being acknowledge by the BlockAck frame, the example time 415 is the time the BlockAck Frame was received, the example total time 420 is the time between two example BlockAck Frames 440-465, the example count 425 is the count of acknowledged frames between two Block Ack Frames, the example total count 430 is the total count of acknowledged frames in a given time period, and the example bitrate 435 is the example count 425 divided by the example time 415 multiplied by 1500 (1500 is the maximum transmission unit (MTU) in bytes. In examples disclosed herein, the example virtual bandwidth event detector 125 of FIG. 1 determine the virtual bandwidth by dividing the example bitrate 435 of FIG. 4 by the example total time 420 of FIG. 4 for incremental time periods. In examples disclosed herein, the virtual bandwidth is represented in Kilobytes/Seconds.

FIG. 5 is an example graph representation of a comparison between actual bandwidth based on packet sizes and virtual bandwidth based on the block acknowledgment mechanism in accordance with the examples disclosed herein. In the example graph 500 of FIG. 5, the virtual bandwidth data is collected using the example virtual bandwidth event detector 125 of FIG. 1. In the example graph 500 of FIG. 5, the actual bandwidth is represented as the solid line and the virtual bandwidth is represented as the dashed line. The example graph 500 displays the two bandwidths as Kilobytes over Time in seconds. The example graph 500 shows the differences in bandwidth measurements that are determined using the data packets that are received (actual bandwidth) and the estimated bandwidth measurements that are determined using the control frames (the virtual bandwidth determined by the example virtual bandwidth event detector 125 of FIG. 1).

While an example manner of implementing the virtual bandwidth event detector 125 of FIG. 1 is illustrated in FIG. 2, one or more of the elements, processes and/or devices illustrated in FIG. 2 may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example control frame receiver 210, the example interval timer 220, the example bitrate calculator 230, the example virtual bandwidth calculator 240, the example virtual bandwidth event generator 250 and/or, more generally, the example virtual bandwidth event detector 125 of FIG. 1 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example control frame receiver 210, the example interval timer 220, the example bitrate calculator 230, the example virtual bandwidth calculator 240, the example virtual bandwidth event generator 250 and/or, more generally, the example virtual bandwidth event detector 125 could be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), programmable controller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example control frame receiver 210, the example interval timer 220, the example bitrate calculator 230, the example virtual bandwidth calculator 240, and/or the example virtual bandwidth event generator 250 is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. including the software and/or firmware. Further still, the example virtual bandwidth event detector 125 of FIG. 1 may include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in FIG. 2, and/or may include more than one of any or all of the illustrated elements, processes and devices. As used herein, the phrase “in communication,” including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events.

A flowchart representative of example hardware logic, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the virtual bandwidth event detector 125 of FIG. 2 is shown in FIGS. 6 and 7. The machine readable instructions may be one or more executable programs or portion(s) of an executable program for execution by a computer processor such as the processor 812 shown in the example processor platform 800 discussed below in connection with FIG. 8. The program may be embodied in software stored on a non-transitory computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor 812, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 812 and/or embodied in firmware or dedicated hardware. Further, although the example program is described with reference to the flowchart illustrated in FIGS. 6 and 7, many other methods of implementing the example virtual bandwidth event detector 125 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware.

The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data (e.g., portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc. in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and stored on separate computing devices, wherein the parts when decrypted, decompressed, and combined form a set of executable instructions that implement a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by a computer, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc. in order to execute the instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, the disclosed machine readable instructions and/or corresponding program(s) are intended to encompass such machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.

The machine readable instructions described herein can be represented by any past, present, or future instruction language, scripting language, programming language, etc. For example, the machine readable instructions may be represented using any of the following languages: C, C++, Java, C #, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift, etc.

As mentioned above, the example processes of FIGS. 6 and 7 may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

“Including” and “comprising” (and all forms and tenses thereof) are used herein to be open ended terms. Thus, whenever a claim employs any form of “include” or “comprise” (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc. may be present without falling outside the scope of the corresponding claim or recitation. As used herein, when the phrase “at least” is used as the transition term in, for example, a preamble of a claim, it is open-ended in the same manner as the term “comprising” and “including” are open ended. The term “and/or” when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (1) A alone, (2) B alone, (3) C alone, (4) A with B, (5) A with C, (6) B with C, and (7) A with B and with C. As used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects and/or things, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A and B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase “at least one of A or B” is intended to refer to implementations including any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.

As used herein, singular references (e.g., “a”, “an”, “first”, “second”, etc.) do not exclude a plurality. The term “a” or “an” entity, as used herein, refers to one or more of that entity. The terms “a” (or “an”), “one or more”, and “at least one” can be used interchangeably herein. Furthermore, although individually listed, a plurality of means, elements or method actions may be implemented by, e.g., a single unit or processor. Additionally, although individual features may be included in different examples or claims, these may possibly be combined, and the inclusion in different examples or claims does not imply that a combination of features is not feasible and/or advantageous.

FIG. 6 is a flowchart illustrating example machine-readable instructions which may be executed to implement the example meter 120 and the example streaming probability determiner 145 of FIG. 1. The program of FIG. 6 begins execution at block 610 at which the example virtual bandwidth event detector 125 detects a virtual bandwidth event. The example virtual bandwidth event detector 125 calculates the virtual bandwidth of the example user device(s) 110A, 110B, 110C, 110D using control packet data received by the example internal network 115. As described in further detail below, the example flowchart 610 of FIG. 7 represents example instructions that may be implemented to detect a virtual bandwidth event.

At block 615, the example meter 120 transmits the virtual bandwidth event. The example meter 120 transmits the virtual bandwidth event to the example internal network 115 via the example network communicator 122. In some examples, the internal network 115 communicated the virtual bandwidth event from the meter 120 to the external network 135 via the network device 130. In some examples, the external network 135 provides the virtual bandwidth event to the streaming probability determiner 145.

At block 620, the example streaming probability determiner 145 determines if the virtual bandwidth event indicates media streaming. The example streaming probability determiner 145 receives the virtual bandwidth event from the example virtual bandwidth event detector 125 via the example network communicator 122, the example internal network 115, the example network device 130, and the example external network 135. The example streaming probability determiner 145 determines if the bandwidth of the virtual bandwidth event is indicative of the example user device(s) 110A, 110B, 110C, 110D streaming digital media. In some examples, the streaming probability determiner 145 determines if the bandwidth of the virtual bandwidth event is indicative of streaming media when the bandwidth exceeds a threshold. However, other methods of determining if the bandwidth of the virtual bandwidth event is indicative of streaming media may additionally and/or alternatively be used.

If the example streaming probability determiner 145 determines that the virtual bandwidth event does not indicate media streaming (e.g., block 620 returns a result of NO), then process 600 returns to block 610 at which the example virtual bandwidth event detector 125 detects a virtual bandwidth event. If the example streaming probability determiner 145 determines that the virtual bandwidth event indicates media streaming (e.g., block 620 returns a result of YES), then process 600 continues to block 625 at which the streaming media is credited. At block 625, the example streaming media creditor 150 credits the example user device(s) 110A, 110B, 110C, 110D of FIG. 1 with the media streaming. After block 624, process 600 ends.

FIG. 7 is an example process 610 that is representative of example machine-readable instructions which may be executed to implement the example virtual bandwidth event detector 125 of FIG. 2. The program of FIG. 7 begins execution at block 710 at which the example interval timer 220 starts a timer. At block 715, the example control frame receiver 210 captures a control frame (BlockAck). At block 720, the example control frame receiver determines if the control frame is from the example user device(s) 110A, 110B, 110C, 110D of FIG. 1. If the example control frame receiver 210 determines that control frame is from the example user device(s) 110A, 110B, 110C, 110D of FIG. 1 (e.g., block 715 returns a result of YES), control frame receiver 210 accesses the SSN from the control frame data. (Block 725). If the example control frame receiver 210 determines that the control frame is not from the example user device(s) 110A, 110B, 110C, 110D of FIG. 1 (e.g., block 720 returns a result of NO), the example control frame receiver waits to capture a new control packet (returns to block 715).

At block 730, the example control frame receiver 210 accesses the bitmap from the control frame data. At block 735, the example control frame receiver 210 accesses the amount of time since the last received control frame. At block 740, the example bitrate calculator 230 calculates the bitrate by dividing the bitmap from the control frame data by the amount of time since the last received control frame. At block 745, the example interval timer 220 determines if the timer has reached a threshold since the timer was started. In some examples, the threshold may be any length of time such as, for example, five minutes, fifteen minutes, etc. If the example interval timer 220 determines that the timer has reached a threshold since the timer was started (e.g., block 745 returns a result of YES), the example virtual bandwidth calculator 240 determines the average bitrate from the control frames received in the time period. (Block 750). If the example interval timer 220 determines that the timer has not reached a threshold since the timer was started (e.g., block 745 returns a result of NO), the example control frame receiver 210 waits to capture a new control frame (returns to block 715).

At block 750, the example virtual bandwidth calculator 240 determines the average bitrate from the control frames received in the time period. The example virtual bandwidth calculator 240 may determine the average bitrate from the control frames received by summing the bitrates of each control frame together and dividing by the total number of control frames received. However, other methods of determining an average may additionally and/or alternatively be used to determine the average bitrate of the control frames received. At block 755, the example virtual bandwidth calculator 240 divides the average bitrate by the time period. The example virtual bandwidth calculator 240 receives the time of the time period from the example interval timer 220 to perform the calculation of block 720.

At block 770, the example virtual bandwidth event generator 250 determines is the virtual bandwidth is greater than zero. If the example virtual bandwidth event generator 250 determines that the virtual bandwidth is not greater than zero (e.g., block 770 returns a result of NO), the example control frame receiver 210 waits to capture a new control frame (returns to block 715). If the example virtual bandwidth event generator 250 determines that the virtual bandwidth is greater than zero (e.g., block 760 returns a result of YES), the example virtual bandwidth event generator 250 generates a bandwidth event. (Block 760). Once the bandwidth event is generated, process 610 completes and returns to process 600 of FIG. 6. The example process 610 of FIG. 7 may be repeated over a selected period of time for virtual bandwidth detection.

FIG. 8 is a block diagram of an example processor platform 800 structured to execute the instructions of FIGS. 6 and 7 to implement the virtual bandwidth event detector 125 of FIG. 2. The processor platform 1000 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset or other wearable device, or any other type of computing device.

The processor platform 800 of the illustrated example includes a processor 812. The processor 812 of the illustrated example is hardware. For example, the processor 812 can be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor based (e.g., silicon based) device. In this example, the processor implements the example control frame receiver 210, the example interval timer 220, the example bitrate calculator 230, the example virtual bandwidth calculator 240, and the example virtual bandwidth event generator 250.

The processor 812 of the illustrated example includes a local memory 813 (e.g., a cache). The processor 812 of the illustrated example is in communication with a main memory including a volatile memory 814 and a non-volatile memory 816 via a bus 818. The volatile memory 814 may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) and/or any other type of random access memory device. The non-volatile memory 816 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 814, 816 is controlled by a memory controller.

The processor platform 800 of the illustrated example also includes an interface circuit 820. The interface circuit 820 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a Bluetooth® interface, a near field communication (NFC) interface, and/or a PCI express interface.