Method and device for processing data packets

Abstract

The invention proposes a method of encoding data packet by encoding type information and size information of said data packet into the same field. The invention also proposes a method of processing data packets received. The data packet comprises a header part and a message part. The header part comprises at least one bit for indicating the type of said data packet, said method comprising a step 101 of obtaining the size information of said data packet based on said at least one bit.

Claims

1. A method of processing a data packet in a wireless power system, the method comprising: receiving a data packet from a second wireless power device by a first wireless power device, wherein the data packet comprises a header and a message, wherein the header includes a header value, wherein the header value indicates whether a type of the data packet is known to the first wireless power device; selecting a message size option from a plurality of message size options based on the header value, wherein the message size options are arranged to enable calculation of a size of the message based on the header value; and utilizing a size of the message, wherein the size of the message is calculated based on the header value by applying a message size formula.

2. The method as claimed in claim 1, wherein the message size formula is S=(Y+(X−Z)/Q), wherein S is the size of the data packet, wherein X is a value of a header part of the data packet, wherein Y is an integer value, wherein Z is an integer value, wherein Q is an integer value.

3. The method as claimed in claim 1, wherein plurality of message size options comprise a plurality of header values and associated message sizes, wherein a look-up table comprises the plurality of header values and the associated message sizes, wherein the message size is selected from the look-up table.

4. The method as claimed in claim 3, wherein the look-up table comprises: TABLE-US-00003 Header Value Range Message Length 0x00~0x1F 1 + (Y − 0)/32 0x20~0x7F  2 + (Y − 32)/16  0x80~0xDF  8 + (Y − 128)/8 0xE0~0xFF 20 + (Y − 224)/4 wherein the message lengths in the table are calculated according the equations and stored in the table, wherein Y corresponds to the header value.

5. The method of claim 3, wherein the look-up table associates a plurality of header value ranges with a corresponding plurality of message size options.

6. The method as claimed in claim 1, further comprising: identifying a checksum of the data packet by the first device, wherein the checksum indicates a first value; calculating a second value based on the message by the first device; and determining, by the first device, whether the data packet is correct by comparing the second value and the first value.

7. The method as claimed in claim 6, further comprising calculating the second value using an exclusive-or.

8. The method as claimed in claim 6, further comprising discarding the data packet when the data packet is incorrect.

9. The method as claimed in claim 6, further comprising: inductively transmitting power from the first device to the second wireless power device; and aborting transmission of the power to the second wireless power device from the first device when the data packet is determined to be incorrect; wherein the data packet is received by decoding a modulation of a wireless power field, wherein the wireless power field is generated by the first wireless power device.

10. A computer program stored on a non-transitory medium, wherein the computer program when executed on a processor performs the method as claimed in claim 1.

11. A first wireless power device for processing a data packet received from a second wireless power device, the first wireless power device comprising: a memory circuit, wherein the memory circuit is configured to store a plurality of header values and an associated plurality of message size options, wherein the message size options are arranged to enable calculation of a size of a received data packet; and a processing circuitry, wherein the processing circuitry is configured to receive the data packet, wherein the data packet comprises a header and a message, wherein the header comprises a header value that indicates whether a type of the data packet is known to the first wireless power device, wherein the processing circuitry is configured to select a message size option from the plurality of message size options, wherein the processing circuitry is configured to obtain a size of the message based on the header value using the selected message size option, wherein the size of the message is calculated based on the header value by applying a message size formula.

12. The first wireless power device as claimed in claim 11, wherein the message size formula is S=(Y+(X−Z)/Q), wherein S is the size of the data packet, wherein X is a value of a header part of the data packet, wherein Y is an integer value, wherein Z is an integer value, wherein Q is an integer value.

13. The first wireless power device as claimed in claim 11, wherein the memory circuit is configured to store the plurality of header values and associated message size options in a look-up table, wherein the processing circuitry is configured to select the message size option from the look-up table.

14. The first wireless power device as claimed in claim 11, wherein the look-up table comprises: TABLE-US-00004 Header Value Range Message Length 0x00~0x1F 1 + (Y − 0)/32 0x20~0x7F  2 + (Y − 32)/16  0x80~0xDF  8 + (Y − 128)/8 0xE0~0xFF 20 + (Y − 224)/4 wherein the message lengths in the table are calculated according the equations and stored in the table, wherein Y corresponds to the header value.

15. The first wireless power device of claim 14, wherein the look-up table associates a plurality of header value ranges with a corresponding plurality of message sizes.

16. The first wireless power device as claimed in claim 9, wherein the processing circuitry is configured to identify a checksum of the data packet, wherein the processing circuitry is configured to calculate a second value based on the message, wherein the processing circuitry is configured to determine whether the data packet is correct by comparing the second value and the checksum.

17. The first wireless power device as claimed in claim 11, wherein the processing circuitry is configured to discard the data packet when the processing circuitry determines that the data packet is incorrect.

18. The first wireless power device as claimed in claim 17, wherein the processing circuitry is configured to receive the data packet sent by the second wireless power device by decoding a modulation of an electromagnetic field, wherein the electromagnetic field is generated by the first wireless power device, wherein the processing circuitry is further configured to abort transmitting the power when the processing circuitry determines that the data packet is incorrect.

19. A method of processing a data packet in a wireless power system, the method comprising: receiving a data packet from a second wireless power device by a first wireless power device, wherein the data packet comprises a header and a message, wherein the header includes a header value, wherein the header value indicates whether a type of the data packet is known to the first wireless power device; selecting a message size option from a plurality of message size options based on the header value; and selecting a size of the message based on the header value using the selected message size option.

20. The method as claimed in claim 19, wherein plurality of message size options comprise a plurality of header values and associated message sizes, wherein a look-up table comprises the plurality of header values and the associated message sizes, wherein the message size is selected from the look-up table.

21. The method of claim 20, wherein the look-up table associates a plurality of header value ranges with a corresponding plurality of message sizes.

22. The method as claimed in claim 19, wherein the message size formula is S=(Y+(X−Z)/Q), wherein S is the size of the data packet, wherein X is a value of a header part of the data packet, wherein Y is an integer value, wherein Z is an integer value, wherein Q is an integer value.

23. The method as claimed in claim 19, wherein the look-up table comprises: TABLE-US-00005 Header Value Range Message Length 0x00~0x1F 1 + (Y − 0)/32 0x20~0x7F  2 + (Y − 32)/16  0x80~0xDF  8 + (Y − 128)/8 0xE0~0xFF 20 + (Y − 224)/4 wherein the message lengths in the table are calculated according the equations and stored in the table, wherein Y corresponds to the header value.

24. The method as claimed in claim 19, further comprising: identifying a checksum of the data packet by the first wireless power device, wherein the checksum indicates a first value; calculating a second value based on the message by the first wireless power device; and determining, by the first wireless power device, whether the data packet is correct by comparing the second value and the first value.

25. The method as claimed in claim 24 further comprising: inductively transmitting power from the wireless power to the second wireless power device; and aborting transmission of the power to the second wireless power device from the first wireless power device when the data packet is determined to be incorrect; wherein the data packet is received by decoding a modulation of a wireless power field, wherein the wireless power field is generated by the first wireless power device.

26. A computer program stored on a non-transitory medium, wherein the computer program when executed on a processor performs the method as claimed in claim 19.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The invention is explained in further detail, and by way of example, with reference to the accompanying drawings wherein:

(2) FIG. 1 shows a flowchart according to an embodiment of this invention;

(3) FIG. 2 depicts an example of the structure of data packet 200;

(4) FIG. 3 illustrates a block diagram of the first device 300.

(5) The dotted lines in the Figures indicate related steps or blocks that are optional; in some embodiments, these can be omitted.

(6) Throughout the above drawings, like reference numerals will be understood to refer to like, similar or corresponding features or functions.

DETAILED DESCRIPTION

(7) From the first aspect of the invention, a data packet comprising a header part and a message part is proposed. The header part comprises at least one bit for indicating the type of said data packet, and the at least one bit is also associated with the size information of the data packet.

(8) In such a way, the size information of a data packet can be encoded into the limited size of header part of said data packet and obtained by the device receiving that data packet. There are no additional dedicated bits for indicating the size information of the data packet.

(9) An encoder for encoding such a data packet is proposed. The encoder could be implemented by means of hardware or software, or both. For example it can be implemented by a memory stored with instruction code or by a processor or a chip, etc.

(10) A device comprising the aforementioned encoder is proposed, the device comprising a unit for sending the data packet to another device.

(11) The association between the size information and the header part can be implemented by introducing a look-up table stored in the device receiving the data packet. The look-up table lists the bits that are used for indicating the type of data packet and the size information of this data packet-type.

(12) As indicated above, in many cases, since the message part is the only part whose size may be different depending on the type, the size of the message part (also referred to as “length of the message part”) is the only size information that needs to be encoded.

(13) A concept of size classes can be used to indicate the size information, with a size class being a range of packet types which all have the same size. For example, size class 1 means that the message part consists of one byte, and size class 7 means that the message part consists of 7 bytes. Assuming the header part has one byte, this provides for up to 256 size classes, where each size class can have 1 . . . 256 packets (with the constraint that the total number of packets does not exceed 256).

(14) Table 1 shows an example of this implementation. It is to be noted that only column 1 and column 2 of table 1 are needed for implementing this invention. Column 3 is not necessary for the step of association size information to the header part; it is used just for the purpose of illustrating the concept of the invention.

(15) As shown in table 1, the header parts from 0x00 to 0x0F reflect a message length of size class 1, which means that the packet type represented by any header part with a value from 0x00 to 0x0F has a message part that consists of 1 byte. In this way, a device receiving a data packet can obtain the size information of the data packet from table 1.

(16) From table 1, it can be seen that both the defined type and the reserved type have been associated with size information. Therefore, a device receiving a type-unknown packet also can obtain the size information of such a type-unknown packet; and if a new packet type with a 7-byte message part needs to be defined in an upgrade (future) version of a protocol, one can select any of the reserved packet types from the group of size class 7, i.e. the header part of the selected packet type having a 7-byte message part should be in the range of values between 0x52 and 0x57. As a result, although an old version device does not know the newly defined packet type according to the old version look-up table, the old version device can get the size information of this unknown (undefined) packet. For example, for header byte 0x1F, although table 1 shows that it is a “reserved” packet type, the size of its message part can be obtained, which is 2.

(17) This ensures forward compatibility with future releases without changes to the existing packet size and structure.

(18) TABLE-US-00001 TABLE 1 Column 1 Column 2 Column 3 Header byte Size class Packet type 0x00 1 Reserved 0x01 1 Signal Strength 0x02 1 End Power Transfer . . . 0x05 1 Charge Status 0x06 1 Reserved . . . 1 Reserved 0x0F 1 Reserved 0x10 2 Reserved . . . 2 Reserved 0x1F 2 Reserved . . . 0x50 Reserved 0x51 7 Identification 0x52 7 Reserved . . . 7 Reserved 0x57 7 Reserved . . . 0xFC 31 Reserved 0xFD 31 Reserved 0xFE 32 Reserved 0xFF 32 Reserved

(19) Since it will require substantial space to store the table that associates size information of the data packet with the header part (such as table 1), in an advantageous implementation, the size information can be calculated from the header part using a simple formula, i.e. associating the size information with the header part via a formula, e.g. the formula is: header/8+1, where the division is an integer division (i.e. discarding any non-zero remainder; which means for a header with one byte for indicating the type of the data packet, the header having 256 different values representing 256 types, that this formula provides for 32 size classes having 8 possible packet types each. For example, if the header is: 0x52, the size information should be: 0x52/8+1=11, which means for example the message part is 11 bytes.

(20) The formula can be different, based on how many size classes are needed and how many packet types are needed for each size class.

(21) Without losing universality, in the following, the device receiving the data packet is referred to as a first device, and the device for sending the data packet is referred to as a second device. The first device and the second device could be any devices as long as the second device can send data to the first device and the first device can receive the data and interpret the data so as to perform the predefined action according to the received data. The methods and the first device for processing data packets are illustrated in detail hereinafter by way of example without limiting the protective scope of this invention.

(22) FIG. 1 shows a flow chart of a method of processing a data packet by a first device according to an embodiment of this invention.

(23) FIG. 2 shows an example of the structure of the data packet 200. The data packet 200 consists of four parts, namely, preamble part 201, header part 202, message part 203 and checksum part 204. The pre-amble part 201 signals the start of a data packet. The header part 202 indicates the type and size of the data packet. The message part 203 carries the message that the second device intends to transmit to the first device. The checksum part 204 is intended to be used to verify whether the data packet 200 is correct or not by means of the first device.

(24) The first part that follows after the preamble 201 is the header part 202. The header part 202 is used to indicate the type of the data packet 200; in the scenario of this invention, the header part is assumed to be small; it has for example only 8 bits (1 byte).

(25) The header part 202 is followed by the message part 203. The message part 203 has multiple bits for carrying the message. As indicated above, for different types of data packet, the size of the message part may be different. Some packet types may only need 1 byte as message part, while other packet types may need much more than 1 byte for carrying a message.

(26) FIG. 3 schematically illustrates a block diagram of a first device 300.

(27) Now, referring to FIGS. 1˜3, the first device 300 comprises a memory 307 for storing the data packet 200 which is received from a second device. The received data packet 200 comprises a header part 202 and a message part 203. The header part 202 comprises at least one bit for indicating the type of said data packet, e.g. the header part 202 has 1 byte (b.sub.0, b.sub.1, . . . , b.sub.7) for indicating the type of the data packet 200. The first device 300 comprises a first unit 301 for performing a step 101 of obtaining the size information of said data packet 200 based on b.sub.0˜b.sub.7.

(28) Optionally, the obtaining step 101 can be performed by checking a look-up table associating b.sub.0˜b.sub.7 with the size information of the packet 200. The look-up table should be pre-stored in the first device 300. An example of such a look-up table is column 1 and column 2 of table 1. For example, according to table 1, for the value of 0xFC, the size of the message part is in class 31, which means for example the message part has 31 bytes.

(29) Advantageously, the obtaining step 101 can be performed by calculating the size of the packet, based on the value of the header part 202 according to a predefined formula pre-stored in the first device 300.

(30) Table 2 shows an example of the pre-stored formulas for calculating the size of the packet (size of the message part) according to the value of the header part 202.

(31) TABLE-US-00002 TABLE 2 Header Message Size 0x00~0x1F 1 + (header − 0)/32 0x20~0x7F  2 + (header − 32)/16  0x80~0xDF  8 + (header − 128)/8 0xE0~0xFF 20 + (header − 224)/4

(32) As shown in table 2, for header part values from 0x20 to 0x7F, the formula for calculating the size of the message part is (2+(header−32)/16). For example, if the header part 202 is 0x52, the size of the message part of packet 200 should be: 2+(0x52−32)/16=2+(82−32)/16=5, which means that the size of the message part of packet 200 is 5 bytes (40 bits).

(33) Knowing the size information of the data packet 200, it helps to identify (locate) the different parts of the packet.

(34) Advantageously, the first device 300 may comprise a second unit 302 for performing a step 102 of identifying said message part from said data packet according to the obtained size information. As a result, which bits belong to the message part 203 and which bits belong to the checksum part can be determined. In other words, the message part can be located.

(35) When the different parts of the data packet are located, the first device 300 is then able to further perform some actions. For example, knowing which bits belong to the checksum byte, the first device then is able to verify the correctness of the received data packet 200.

(36) Advantageously, the first device 300 comprises a third unit 303 for performing a step 103 of calculating a second value according to the identified message part; a fourth unit 304 for performing a step 104 of determining whether said data packet is correct or not by comparing a first value indicated by the checksum part 204 with the calculated second value.

(37) The checksum part has a fixed-size datum computed from an arbitrary block of digital data for the purpose of detecting accidental errors that may have been introduced during its transmission or storage. The integrity of the data packet can be checked at any later time by re-computing the checksum value and comparing it with the stored one. If the checksums do not match, the data was almost certainly altered (either intentionally or unintentionally). The procedure that yields the checksum from the data is called a checksum function or checksum algorithm. A good checksum algorithm will yield a different result with high probability when the data is accidentally corrupted; if the checksums match, the data is very likely to be free of accidental errors.

(38) The checksum part 204 comprises for example a single byte indicating a first value for verifying whether the data packet 200 is correct or not, i.e to verify whether the data packet 200 has been received correctly or not after the packet 200 is received by the first device from the second device.

(39) To determine whether the packet 200 is correct, firstly, the first device has to retrieve the first value from the checksum part 204. Since the checksum part 204 follows the message part 203, the checksum byte 204 can be located when the message part 203 is located.

(40) The first value represented by the checksum byte 204 is calculated according to a predefined algorithm by the second device and is added to the packet 200 as the checksum byte before the packet 200 is sent to the first device 300. If the first device 300 calculates the second value according to the same predefined algorithm, the second value should be the same as the first value. If the two checksum values are the same, the packet 200 has been transmitted correctly, i.e the packet 200 is correct; however, if they are not the same, there has been a transmission error during the transmission of the packet.

(41) There are many algorithms for calculating the first and second value, for example, the longitudinal parity check, which breaks the data into “words” with a fixed number n of bits, and then computes the exclusive-or (referred to as XOR) of all those words. The result is appended to the packet as an extra word. To check the integrity of a message, the first device computes the exclusive-or of all its words (header byte, message part, and checksum byte); if the result is not a word with n zeros, the first device knows that a transmission error occurred.

(42) As an example, the algorithm is: header byte XOR 1st message byte XOR 2nd message byte XOR . . . XOR last message byte. Consider for example the byte sequence 0x23 0x10 0x35 0x06 0x45. The packet starts at the first byte of the sequence, i.e. the header byte is 0x23. This means that the size of the message in the packet is 2 bytes according to table 2, i.e. 0x10 0x35. The byte following the message is the checksum, i.e. 0x06, which is calculated as 0x23 XOR 0x10 XOR 0x35. The last byte in the sequence (i.e. 0x45) is not actually part of the packet (and would be ignored by a transmitter).

(43) Alternatively, any other known checksum algorithms could be used.

(44) Advantageously, the first device further comprises a fifth unit 305 for performing a step 105 of discarding said data packet 200 when the fourth unit 304 determines that the data packet 200 is incorrect.

(45) Since the packet 200 has been verified to be incorrect, the transmitter has to discard the data packet and wait for the next data packet, irrespective of whether the received data packet is a type-known packet or a type-unknown packet.

(46) If the header part 202 corresponds to a type-unknown packet, it means the first device 300 does not know which type the data packet 200 is, and therefore the first device 300 cannot make use of this data packet. In this case, the first device has to discard the received data packet 200 no matter whether the packet is correct or incorrect so as to ensure that a first generation of e.g. transmitter would remain compatible with future generations of receivers.

(47) Advantageously, the first device 300 corresponds to a transmitter, the second device corresponds to a receiver. The transmitter comprises one or more primary coils which are coupled with one or more secondary coils of the receiver. The primary coil is applied to an AC power source to generate a magnetic field which will induce a voltage in the secondary coils; in such a way, the transmitter can transmit power to the receiver. When the transmitter applies power to the receiver, the receiver can send data packet 300 by modulating the power drawn from said transmitter, i.e. by varying the power consumed from said transmitter. The first device 300 further comprises a sixth unit 306 for performing a step 106 of aborting the transmission of power when the fourth unit 304 determines that the data packet is incorrect. If the data packet 200 is sent in this way, the incorrectness of the data packet 200 indicates a power transmission problem since the data packet is modulated onto the power signal.

(48) There are numerous ways of implementing functions by means of items of hardware or software, or both. In this respect, the drawings are also very illustrative, each representing only one possible embodiment of the invention. For example, the above-mentioned unit 301, 302, 303, 304, 305, 306 can be implemented by one or a plurality of memories stored with different instruction codes. These units may also be implemented by one or a plurality of printed circuit boards or by one or a plurality of processors.

(49) It should be noted that the above described embodiments are given for describing rather than limiting the invention, and it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the invention as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the invention and the appended claims. The protection scope of the invention is defined by the accompanying claims. In addition, any of the reference numerals in the claims should not be interpreted as a limitation to the claims. Use of the verb “comprise” and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The indefinite article “a” or “an” preceding an element or step does not exclude the presence of a plurality of such elements or steps.