Patent Application
20150359016
Aspects of the present disclosure relate generally to wireless communication systems, and more particularly, to a client estimation of round trip time via transport control protocol signals over multiple radio access technologies.
Wireless communication networks are widely deployed to provide various communication services such as telephony, video, data, messaging, broadcasts, and so on. Such networks, which are usually multiple access networks, support communications for multiple users by sharing the available network resources. One example of such a network is the UMTS Terrestrial Radio Access Network (UTRAN). The UTRAN is the radio access network (RAN) defined as a part of the Universal Mobile Telecommunications System (UMTS), a third generation (3G) mobile phone technology supported by the 3rd Generation Partnership Project (3GPP). UMTS, which is the successor to Global System for Mobile Communications (GSM) technologies, currently supports various air interface standards, such as Wideband-Code Division Multiple Access (W-CDMA), Time Division-Code Division Multiple Access (TD-CDMA), and Time Division-Synchronous Code Division Multiple Access (TD-SCDMA). UMTS also supports enhanced 3 G data communications protocols, such as High Speed Packet Access (HSPA), which provides higher data transfer speeds and capacity to associated UMTS networks.
Generally, in order to determine how much data a client should request over a transport control protocol (TCP) connection where multiple TCP connections are established over a multiple radio access technology topography, it is desirable for the client to know the round trip time (RTT) between itself and a server over each radio access technology and its accompanying backbone/Internet routing path. Moreover, in order to request an optimal amount of data over each radio access technology, the client may multiply the RTT by the data rate to ascertain the Bandwidth-Delay Product (BDP). Accordingly, a mechanism is desired whereby a client can calculate a reliable RTT estimate between itself and a server on a frequent and regular basis.
The following presents a simplified summary of one or more aspects of the present disclosure, in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure, and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.
Aspects of the present disclosure provide methods, apparatuses, computer program products, and processing systems directed to a client estimation of round trip time via transport control protocol (TCP) signals over multiple radio access technologies. In one aspect, the disclosure provides a method that includes facilitating establishing a plurality of TCP connections across multiple radio access technologies between a client and a server such that each radio access technology is associated with at least one of the plurality of TCP connections. The method further includes selecting at least one TCP connection of the plurality of TCP connections for each of the multiple radio access technologies and transmitting at least one probe signal from the client to the server over the selected TCP connection. At least one acknowledgment signal is then received from the server via the selected TCP connection, such that the at least one acknowledgment signal is a TCP acknowledgment signal received in response to the at least one probe signal. The method concludes with an estimating of a round trip time between the client and the server based on the at least one probe signal and the at least one acknowledgment signal.
In another aspect, a device comprising a transmit circuit, a receive circuit, and an estimate circuit is disclosed. Here, the transmit circuit is configured to facilitate establishing a plurality of TCP connections across multiple radio access technologies between a client and a server such that each radio access technology is associated with at least one of the plurality of TCP connections. The transmit circuit further comprises a TCP selection subcircuit configured to select at least one TCP connection of the plurality of TCP connections for each of the multiple radio access technologies, wherein the transmit circuit is configured to transmit at least one probe signal from the client to the server over the selected TCP connection. The receive circuit is then configured to receive at least one acknowledgment signal at the client from the server via the selected TCP connection in response to the at least one probe signal, whereas the estimate circuit is configured to estimate a round trip time between the client and the server based on the at least one probe signal and the at least one acknowledgment signal.
In a further aspect, another device is disclosed. Here, the device comprises means for transmitting configured to facilitate establishing a plurality of TCP connections across multiple radio access technologies between a client and a server such that each radio access technology is associated with at least one of the plurality of TCP connections. In this implementation, at least one TCP connection of the plurality of TCP connections is selected for each of the multiple radio access technologies, wherein the means for transmitting is further configured to transmit at least one probe signal from the client to the server over the selected TCP connection. The device further comprises means for receiving at least one acknowledgment signal from the server via the selected TCP connection in response to the at least one probe signal, and means for estimating a round trip time between the client and the server based on the at least one probe signal and the at least one acknowledgment signal.
In yet another aspect, a non-transitory machine-readable storage medium having one or more instructions stored thereon is disclosed. Here, when executed by at least one processor, the one or more instructions cause the at least one processor to facilitate establishing a plurality of TCP connections across multiple radio access technologies between a client and a server such that each radio access technology is associated with at least one of the plurality of TCP connections. Instructions are also provided for causing the at least one processor to select at least one TCP connection of the plurality of TCP connections for each of the multiple radio access technologies, and transmit at least one probe signal from the client to the server over the selected TCP connection. The instructions further comprise instructions for causing the at least one processor to receive at least one acknowledgment signal at the client from the server over the selected TCP connection in response to the at least one probe signal, and estimate a round trip time between the client and the server based on the at least one probe signal and the at least one acknowledgment signal.
These and other disclosed aspects will become more fully understood upon a review of the detailed description, which follows. Other aspects, features, and aspects of the present invention will become apparent to those of ordinary skill in the art, upon reviewing the following description of specific, exemplary aspects of the present invention in conjunction with the accompanying figures. While features of the present invention may be discussed relative to certain aspects and figures below, all aspects of the present invention can include one or more of the advantageous features discussed herein. In other words, while one or more aspects may be discussed as having certain advantageous features, one or more of such features may also be used in accordance with the various aspects of the invention discussed herein. In similar fashion, while exemplary aspects may be discussed below as device, system, or method aspects it should be understood that such exemplary aspects can be implemented in various devices, systems, and methods.
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
The various aspects disclosed herein are generally directed to facilitating a client estimation of round trip time (RTT) between the client and a server. Particular aspects are disclosed for estimating such RTT via transport control protocol (TCP) signals disseminated over multiple radio access technologies. For instance, a configuration is contemplated in which the client performs RTT estimations based on TCP keepalive probes transmitted to a server in conjunction with TCP server responses to those probes, wherein aspects are disclosed for performing such estimations based on the probes and their corresponding responses either 1) after receiving an initial set of responses to an initial set of corresponding probes (e.g., immediately after, such as upon detecting that a predetermined number of acknowledgment signals have been received), or 2) after a TCP connection is established (e.g., immediately after, such as after the first few hundred milliseconds after the TCP connection is established). Within such configuration, it may be desirable to transmit TCP keepalive probes on a frequent and regular basis (e.g., with a period on the order of tens of milliseconds (ms)). In order to transmit such probes accordingly, aspects are disclosed for reconfiguring various TCP parameters. For example, because the two hour default value of tcp_keepidle (i.e., the length of time the TCP connection is kept active when no data is received) in current TCP implementations might be too long, aspects disclosed herein include shortening this value. It is also noted that, because the TCP clock (i.e., t_idle) counts the number of 500 ms clock ticks since a TCP segment was last received on the TCP connection, the smallest possible tcp_keepidle value allowed by current TCP implementations is 500 ms. As disclosed herein, however, this can be changed to a granularity of 1 ms, if a 1 ms system clock is used instead of the 500 ms t_idle clock.
Various aspects for selecting which TCP connection to utilize for estimating RTT are also contemplated. For instance, in a first implementation, the client establishes a single TCP connection for each radio access technology. Here, each of these single TCP connections are kept idle except for the sending of TCP keepalive probes by the client and the reception of acknowledgments (ACKs) from the server. Additionally, the client also establishes one or more TCP connections for each radio access technology (on an as needed basis), wherein these TCP connections are used for data and ACKs (i.e., the client requests data from the server on these TCP connections). In a second implementation, the client establishes two or more TCP connections for each radio access technology for data and ACKs (i.e., the client requests data from the server on these TCP connections), but when these TCP connections are idle (i.e., when no data is being received on them), TCP keepalive probes are sent in a round-robin fashion over these TCP connections.
In this example, the processing system 114 may be implemented with a bus architecture, represented generally by the bus 102. The bus 102 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 114 and the overall design constraints. The bus 102 links together various circuits including one or more processors (represented generally by the processor 104), a memory 105, and computer-readable media (represented generally by the computer-readable medium 106). The bus 102 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further. A bus interface 108 provides an interface between the bus 102 and a transceiver 110. The transceiver 110 provides a means for communicating with various other apparatus over a transmission medium. Depending upon the nature of the apparatus, a user interface 112 (e.g., keypad, display, speaker, microphone, joystick) may also be provided.
In an aspect of the disclosure, computer-readable medium 106 is configured to include various instructions 106a, 106b, and/or 106c to facilitate estimating RTTs between a client and server via TCP signals. In a similar aspect, such estimating can instead be implemented via hardware by coupling processor 104 to any of circuits 120, 130, and/or 140, as shown. Moreover, it is contemplated that the estimating may be performed by any combination of instructions 106a, 106b, and/or 106c, as well as any combination of circuits 120, 130, and/or 140. In a particular aspect of the disclosure, instructions 106a and circuit 120 are directed to facilitating establishing TCP connections across multiple radio access technologies between UE 100 and a server, and transmitting a TCP probe signal to the server over a selected TCP connection, which is discussed in further detail below with reference to
Referring back to the remaining elements of
One or more processors 104 in the processing system may execute software.
Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The software may reside on a computer-readable medium 106. The computer-readable medium 106 may be a non-transitory computer-readable medium. A non-transitory computer-readable medium includes, by way of example, a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip), an optical disk (e.g., a compact disc (CD) or a digital versatile disc (DVD)), a smart card, a flash memory device (e.g., a card, a stick, or a key drive), a random access memory (RAM), a read only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, a removable disk, and any other suitable medium for storing software and/or instructions that may be accessed and read by a computer. The computer-readable medium may also include, by way of example, a transmission line, and any other suitable medium for transmitting software and/or instructions that may be accessed and read by a computer. The computer-readable medium 106 may reside in the processing system 114, external to the processing system 114, or distributed across multiple entities including the processing system 114. The computer-readable medium 106 may be embodied in a computer program product. By way of example, a computer program product may include a computer-readable medium in packaging materials. Those skilled in the art will recognize how best to implement the described functionality presented throughout this disclosure depending on the particular application and the overall design constraints imposed on the overall system.
Referring next to
For configurations where a proxy server is used (a situation which may not, in general, be known a priori) and/or where the processing delay at the origin server needs to be accounted for, it is contemplated that the disclosed RTT estimate calculation may account for both. Accordingly, at blocks 204 and 206 the UE transmits a TCP probe signal with frequency fTCP
Various aspects directed to transmitting TCP probe signals disclosed herein are now discussed with reference to
In a particular aspect of the disclosure, it is contemplated that either of probe selection sub-circuit 310 and/or probe selection instructions 312 may be configured for selecting a probe signal type associated with each TCP probe signal transmission. For instance, the TCP probe signal may be either a TCP keepalive signal or an HTTP HEAD request. Indeed, as discussed in further detail below, it is further contemplated that transmit circuit 120 and/or transmit instructions 106a may be configured to transmit a first probe signal of a first type and subsequently transmit a second probe signal of a second type. For example, probe selection sub-circuit 310 and/or probe selection instructions 312 may be configured to select a TCP keepalive signal for the first probe signal, and probe selection sub-circuit 310 and/or probe selection instructions 312 may be configured to select an HTTP HEAD request for the second probe signal.
As mentioned above, particular aspects disclosed herein utilize TCP keepalive signals to facilitate performing RTT estimate calculations. To this end, although TCP keepalive signals are not currently part of the TCP specification, most implementations support TCP keepalive functionality. It should be noted that either end of a TCP connection may send TCP keepalive probes, which are turned off by default. It should be further noted that a TCP keepalive probe may be an empty (or 1 byte) TCP segment with the ACK bit set and with the sequence number (SN) equal to one less than the next sequence number to be sent. Because this sequence number has already been acknowledged by the receiving peer, the arriving TCP segment simply elicits an ACK that is used to determine whether the connection is still operating. If there is no activity on the TCP connection for some period of time, the host with TCP keepalive enabled sends a TCP keepalive probe to its peer. If no response is received, the TCP keepalive probe is retransmitted periodically until a maximum number of TCP keepalive probes has been reached. If this occurs, the peer's system is deemed unreachable and the TCP connection is terminated.
Referring next to
Another configurable parameter illustrated in
A “tcptv_keepcnt” value is also configurable, wherein these values specify the maximum number of TCP keepalive probes—1 that a TCP connection will send to another host waiting for a response. In
Another TCP keepalive parameter illustrated in
Referring next to
It should be appreciated that multiple TCP connections may exist between a UE client and a server at any given time. Accordingly, in a particular aspect of the disclosure, either of TCP selection sub-circuit 320 and/or TCP selection instructions 322 may be configured to select a particular TCP connection from a plurality of TCP connections across multiple radio access technologies, wherein the selected TCP connection is an idle TCP connection. RTT estimates are then calculated as a function of TCP probe signals transmitted via the selected TCP connection.
Various aspects for selecting which TCP connection to utilize for estimating RTT are contemplated. A first implementation is illustrated in
A second implementation is illustrated in
Referring next to
As illustrated, procedure 800 begins at block 810 where various TCP parameters are configured. As mentioned previously, such configuration may include configuring values for any of tcp_keepidle, tcp_keepintvl, tcptv_keepcnt, and/or t_idle. Procedure 800 then continues to blocks 820 and 830 where the UE respectively determines the desired TCP probe signal frequency fTCP
In a further aspect of the disclosure, the UE is also configured to select the particular TCP connection(s) to use for transmitting TCP probe signals. Here, it is contemplated that such selection is performed at block 840, wherein the TCP connection may be selected according to any of a plurality of selection algorithms. For instance, as described with reference to
After the UE has been properly configured, procedure 800 then proceeds to block 850 where the UE detects a trigger for transmitting a TCP probe signal. As previously mentioned, such a trigger may leverage a TCP keepalive timer that exists in current TCP implementations. For instance, the expiration of a TCP keepalive timer may be detected at block 850, which triggers the transmission of TCP probe signals at a frequency of fTCP
Various aspects directed to receiving acknowledgment signals in response to probe signal transmissions disclosed herein are now discussed with reference to
In a particular aspect of the disclosure, it is contemplated that RTT estimates may be performed after a triggering event has been detected, wherein receive circuit 130 and/or receive instructions 106b may be configured to facilitate such detection. For instance, it may be desirable to perform RTT estimates immediately upon establishing a TCP connection. To facilitate implementing such a trigger, either of detector sub-circuit 910 and/or detector instructions 912 may be configured to detect whether at least one TCP connection has been established between the UE and a server. Alternatively, rather than performing RTT estimates immediately upon establishing a TCP connection, it may be desirable to wait until a threshold number of acknowledgment signals have been received in response to probe signals transmitted by the UE. To facilitate implementing this type of trigger, either of counter sub-circuit 920 and/or counter instructions 922 may be configured to count the number of acknowledgment signals received by the UE.
Referring next to
As illustrated, procedure 1000 begins at block 1010 where receive circuit 130 and/or receive instructions 106b detect that TCP probe signals have been transmitted. Such detection may be facilitated via hardware by connecting transmit circuit 120 and receive circuit 130 and/or via software by configuring receive instructions 106b to receive a value from transmit instructions 106a indicating that a TCP probe signal has been transmitted. Upon detecting that a TCP probe signal has been transmitted, the UE may then begin monitoring the status of its TCP connection(s) with a server at block 1020. As previously mentioned, because it may be desirable to perform RTT estimates immediately upon establishing a TCP connection, either of detector sub-circuit 910 and/or detector instructions 912 may be used to monitor TCP connections at block 1020. Procedure 1000 then continues to block 1030 where acknowledgment signals are received in response to the TCP probe signal transmissions. In a particular aspect of the disclosure, either of counter sub-circuit 920 and/or counter instructions 922 may be used to count the number of acknowledgment signals received by the UE at block 1030. Procedure 1000 then concludes at block 1040 where the TCP connection status ascertained at block 1020, and a count of the number of acknowledgment signals received by the UE at block 1030, are output. Here, because such output may be used as a trigger to begin performing RTT estimates, it is contemplated that this output may be provided either via hardware (e.g., by connecting receive circuit 130 and estimate circuit 140) and/or via software (e.g., by configuring receive instructions 106b to transmit values to estimate instructions 106c representing such output).
Various aspects directed to estimating round trip time disclosed herein are now discussed with reference to
As previously mentioned, it may be desirable to have RTT estimates performed after a triggering event has been detected. To facilitate such triggering, it is contemplated that either of trigger sub-circuit 1110 and/or trigger instructions 1112 may be included, wherein either of trigger sub-circuit 1110 and/or trigger instructions 1112 may be configured to operate in conjunction with subcomponents of receive circuit 130 and/or receive instructions 106b, as desired. For instance, if the desired trigger is an established TCP connection, either of trigger sub-circuit 1110 and/or trigger instructions 1112 may be configured to operate in conjunction with detector sub-circuit 910 and/or detector instructions 912, wherein an RTT estimation is triggered upon detecting that a TCP connection has been established. Alternatively, if the desired trigger is a threshold number of acknowledgments, either of trigger sub-circuit 1110 and/or trigger instructions 1112 may be configured to operate in conjunction with counter sub-circuit 920 and/or counter instructions 922, wherein an RTT estimation is triggered upon detecting that a predetermined number of acknowledgment signals have been received.
As indicated above, various aspects disclosed herein are directed to having a client perform RTT estimations based on TCP keepalive probes transmitted to a server in conjunction with TCP server responses to those probes. Referring next to
RTT_WWANTCP
For WLAN TCP connections, however, the UE 1200 uses:
RTT_WLANTCP
Note that equations (1) and (2) above do not account for the processing delay at the origin server (i.e., HTTP HEAD requests are not transmitted by the UE 1200).
Referring next to
RTT_WWANTotal≈RTT_WWANTCP
where,
RTT_WWANTCP
Similarly, for WLAN TCP connections:
RTT_WLANTotal≈RTT_WLANTCP
where,
RTT_WLANTCP
Note that equations (3) through (6) above do not account for the processing delay at the origin server (i.e., HTTP HEAD requests are not transmitted by the UE 1300).
If the delay is deemed non-negligible though (i.e., if RTT_WWANTCP
RTT_WWANTotal=RTT_WWANHTTP
RTT_WLANTotal=RTT_WLANHTTP
The RTT between the proxy server 1350 and the origin server 1340 may then be estimated as follows:
RTT_WWANproxy-origin≈RTT_WWANHTTP
RTT_WLANproxy-origin≈RTT_WLANHTTP
Then, when only TCP keepalive probes are sent (i.e., at a higher frequency than HTTP HEAD requests), the total RTT is estimated as follows:
RTT_WWANTotal≈RTT_WWANTCP
RTT_WLANTotal≈RTT_WLANTCP
where the values for RTT_WWANproxy-origin and RTT_WLANproxy-origin are from the last time that the TCP probe signal and HTTP HEAD request were transmitted at the same time.
Note that equations (7) through (12) above account for both the presence of a proxy server 1350 and the processing delay at the origin server 1340 since HTTP HEAD requests are transmitted by the UE 1300.
As previously mentioned, it is contemplated that TCP keepalive signals may be used in conjunction with a TCP timestamps option to improve RTT estimate accuracy. Accordingly, to facilitate such implementation, it is contemplated that either of timestamp sub-circuit 1120 and/or timestamp instructions 1122 may be included and configured to ascertain timestamp data from a TCP timestamps option, wherein RTT estimates are determined as a function of the timestamp data. To this end, it should be noted that a TCP timestamps option is defined in Request for Comments (RFC) 1323, Section 3.2, and may be sent in an initial synchronize (SYN) segment (i.e., SYN bit is set and ACK bit is not set). The TCP timestamps option is also defined to include various fields. For instance, a Timestamp Value field (TSval) includes the current timestamp clock value of the TCP sending this option. A Timestamp Echo Reply field (TSecr) is also included, which is only valid if the ACK bit is set in the TCP header. If it is valid, it echoes the timestamp value that was sent by the remote TCP in the TSval field of the timestamps option.
For purposes of estimating RTT, particular TCP timestamps option implementation specific parameters which are not included in the actual TCP timestamps option should be noted. For instance, the “tcp_now” value specifies the timestamp clock, wherein this value is initialized to zero when the kernel is initialized and incremented by one every 500 ms. For some implementations, however, it is contemplated that a 1 ms system clock may be used instead of a 500 ms clock.
Various other TCP timestamps option implementation specific parameters are also used but not included in the actual TCP timestamps option itself. For instance, the “ts_recent” value specifies a copy of the most recent valid timestamp from the other end (i.e., ts_recent=TSval), wherein TSecr subsequently equals ts_recent in the corresponding ACK. Values for “ts_val” and “ts_ecr” are also included, wherein ts_val specifies the timestamp sent by the other end with its TCP data segment (i.e., TSval), and wherein ts_ecr specifies the timestamp from the TCP data segment that is being acknowledged by the received ACK (i.e., TSecr).
By utilizing a TCP timestamp option, the RTT of a transmitted TCP data segment and its ACK may be calculated as:
RTT=tcp_now−ts_ecr (12)
If tcp_now is tied to a 500 ms clock, however, RTTs are measured in multiples of 500 ms. In order to provide higher resolution RTT measurements, tcp_now can be tied to the 1 ms system clock instead, wherein RTT estimates are calculated by recording the system clock when a TCP data segment is transmitted, and then reading the system clock when the corresponding ACK is received. In
Referring next to
As illustrated, procedure 1600 begins at block 1610 where various timestamp option parameters are configured. Such parameters may, for example, include tying tcp_now to the 1 ms system clock instead of the 500 ms clock, as indicated above, wherein timestamp option configurations are facilitated by timestamp sub-circuit 1120 and/or timestamp instructions 1122. A trigger for performing an RTT estimate after transmitting a TCP probe signal is then detected at block 1620, which may include any of the aforementioned triggers mentioned above (e.g., establishment of a TCP connection, threshold number of acknowledgment signals, etc.). Procedure 1600 then proceeds to block 1630 where timestamp data associated with each received acknowledgment is retrieved.
Upon receiving TCP acknowledgments and retrieving their corresponding timestamp data, the UE may estimate the RTT (viz. RTTTCP
Several aspects of a telecommunications system have been presented with reference to particular systems. As those skilled in the art will readily appreciate, various aspects described throughout this disclosure may be extended to other telecommunication systems, network architectures and communication standards.
By way of example, various aspects may be extended to other UMTS systems such as TD-SCDMA and TD-CDMA. Various aspects may also be extended to systems employing LTE (in FDD, TDD, or both modes), LTE-Advanced (LTE-A) (in FDD, TDD, or both modes), CDMA2000, Evolution-Data Optimized (EV-DO), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Ultra-Wideband (UWB), Bluetooth, and/or other suitable systems. The actual telecommunication standard, network architecture, and/or communication standard employed will depend on the specific application and the overall design constraints imposed on the system.
Within the present disclosure, the word “exemplary” is used to mean “serving as an example, instance, or illustration.” Any implementation or aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects of the disclosure. Likewise, the term “aspects” does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation. The term “coupled” is used herein to refer to the direct or indirect coupling between two objects. For example, if object A physically touches object B, and object B touches object C, then objects A and C may still be considered coupled to one another—even if they do not directly physically touch each other. For instance, a first die may be coupled to a second die in a package even though the first die is never directly physically in contact with the second die. The terms “circuit” and “circuitry” are used broadly, and intended to include both hardware implementations of electrical devices and conductors that, when connected and configured, enable the performance of the functions described in the present disclosure, without limitation as to the type of electronic circuits, as well as software implementations of information and instructions that, when executed by a processor, enable the performance of the functions described in the present disclosure.
One or more of the components, steps, features and/or functions illustrated in
It is to be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented unless specifically recited therein.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. A phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of a, b, or c” is intended to cover: one or more a; one or more b; one or more c; one or more a and one or more b; one or more a and one or more c; one or more b and one or more c; and one or more a, one or more b, and one or more c. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.”
This application claims priority to and the benefit of provisional patent application No. 62/009,673, filed in the United States Patent and Trademark Office on Jun. 9, 2014, the entire content of which is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62009673 | Jun 2014 | US |
