Patent Application
20070274209
Some embodiments of the invention may be better understood by referring to the following description accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
References to “one embodiment”, “an embodiment”, “example embodiment”, “various embodiments”, etc., indicate that the embodiment(s) of the invention so described may include particular features, structures, or characteristics, but not every embodiment necessarily includes the particular features, structures, or characteristics. Further, some embodiments may have some, all, or none of the features described for other embodiments.
In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements co-operate or interact with each other, but they may or may not be in direct physical or electrical contact.
The term “wireless” may be used to describe circuits, devices, systems, methods, techniques, communications channels, etc., that may communicate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, although in some embodiments they might not. The term “mobile wireless device” may be used to describe a wireless device that may be moved while it is communicating.
As used in the claims, unless otherwise specified the use of the ordinal adjectives “first”, “second”, “third”, etc., to describe a common object, merely indicate that different instances of like elements are being referred to, and are not intended to imply that the elements so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.
Various embodiments of the invention may be implemented in one or any combination of hardware, firmware, and software. The invention may also be implemented as instructions contained in or on a machine-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein. A machine-readable medium may include any mechanism for storing, transmitting, and/or receiving information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium may include a storage medium, such as but not limited to read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; a flash memory device, etc. A machine-readable medium may also include a propagated signal which has been modulated to encode the instructions, such as but not limited to electromagnetic, optical, or acoustical carrier wave signals.
Various embodiments of the invention may prioritize the data segments that are to be transmitted in a single burst (sometimes called a transmission region), placing higher priority segments ahead of lower priority segments in the transmission. In this manner, if a later portion of the transmission is lost because it cannot be reliably received, the higher priority segments may have already been correctly received before the problem occurred because they were placed earlier in the transmission. This technique may be especially helpful with protocols in which the data segments have a variable length, and each data segment contains a value indicating its length. With such protocols, a loss of the length indicator in any segment may cause the loss of all subsequent segments in the transmission.
The criteria used to determine priority may be based on various factors. In some embodiments, the factors may include user application considerations. For example, streaming video and/or Voice over Internet Protocol (VoIP) may have a high priority, since a delay in receiving a data segment may interrupt a smooth presentation of the video or audio information. Conversely, backing up data remotely may have low priority, since some delay in receiving portions of the data are not usually considered important. In some other embodiments, priority may be based on network operational considerations. For example, some handshaking protocols are time critical—a response to a query must be received within a certain time period or the connection between the two devices may deteriorate or even be terminated. Conversely, reporting long-term downtime percentages for a wide-area network may have relatively low priority, since any reaction to that information will probably involve long human delays. Some embodiments may combine various types of factors, such as combining user application and/or network operation and/or other factors.
The process of ordering the data segments by their priority level may be performed in various ways, one of which begins at 120 by selecting a data segment that is to be transmitted. The data segments may take various forms, and may be described in various ways. A data segment called a protocol data unit (PDU) is used here for illustrative purposes, but other types of data segments may alternatively be used. The selected PDU may be examined at 130 to determine if its priority level is at least as high as any of the PDUs that remain to be selected for this particular transmission. If not, another PDU may be selected and similarly examined. If yes, the selected PDU may be placed into the next location in a transmission buffer at 140. As determined at 150 and 160, if the transmission buffer is full, or if the transmission buffer is not full but there are no more PDUs to select for this transmission, then the PDUs in the transmission buffer may be transmitted at 170. If the transmission buffer is not full and there are more PDUs to select for this transmission, then the process may return to 120 to select another PDU, and the cycle may continue until the PDUs are transmitted. Once the buffer is transmitted (or in some embodiments just flagged for transmission), the process of flow diagram 100 may be repeated whenever there are more PDUs to be transmitted.
Although this example illustrates the use of group priorities, other embodiments may assign a different priority level for each PDU. Still other embodiments may use a combination of group priorities and individual priorities. Although this example only shows the PDUs, the actual transmission may include other fields, such as but not limited to any or all of: a preamble, a header, a data integrity check such as a cyclic redundancy check (CRC) value, etc. The transmission buffer may include any or all of such additional fields, or they may be inserted dynamically before actual transmission.
Each PDU may have a defined format, one embodiment of which is shown as including a PDU header which may contain information defining various aspects of the PDU. The data field may contain any feasible information. In some embodiments the data field may contain headers and/or data fields and/or CRC's for units of information smaller that a PDU or its equivalent. The end of the PDU may include a value to check the data integrity of the received PDU, such as a PDU CRC. In some embodiments the PDU may include other fields and/or details not shown.
Each PDU header may have a defined format, one embodiment of which is shown at the bottom of
HT—Header type. In some embodiments this may distinguish between a generic informational header, and a signaling header (which may not be followed by a data field).
EC—Encryption control. In some embodiments this may indicate if the subsequent data is encrypted.
Type—The type of payload in the data field. In some embodiments this may indicate the format used within the data field, including the presence of sub-headers.
ES—Extended subheader. In some embodiments, this may indicate additional header information.
CI—CRC indicator. In some embodiments this may indicate whether a CRC or other data integrity value is appended to the end of the data (e.g., in some embodiments there may not be a PDU CRC field).
EKS—Encryption key sequence. In some embodiments this may contain one or more keys associated with encryption/decryption of the data.
LEN—Length of the PDU. In some embodiments this field may indicate the length of the PDU in standards units (e.g., in bytes). The value contained in this field may be used by the receiving device to determine where in the transmission that the current PDU ends and the subsequent PDU begins. In some embodiments, knowing this information may be critical to correctly receiving the remainder of the transmission.
CID—Connection identifier. In some embodiments this field may identify the connection between the transmitting and receiving parties for this PDU
HCS—Header check sequence. In some embodiments this field may serve as a data integrity check (similar to a CRC) just for this header. In some embodiments a failure of the data integrity check of the header (e.g., based on the HCS) may cause the accuracy of the entire header to be questionable, which may in turn cause the value in the length field to be questionable, which may in turn cause the remaining PDUs in the transmission to be unparsable. The effect of a failed HCS may vary, depending on whether other factors permit the integrity of the length field to be verified.
The foregoing description is intended to be illustrative and not limiting. Variations will occur to those of skill in the art. Those variations are intended to be included in the various embodiments of the invention, which are limited only by the spirit and scope of the following claims.
