Method for Inserting and Removing Padding from Packets
Claim Score by NHIP
Abstract
The invention relates to the field of data packet management, and more specifically to the field of managing of data packets in such a manner that power consumption is reduced, such reduction being especially beneficial for portable device applications. In accordance with an embodiment of the invention there is provided a method of handling and manipulating data wherein padding and unpadding operations for a packet of data are performed at the transmission/reception of a packet from a network, and data handling is minimized within the portable device. According to another embodiment of the invention there is provided a method of encryption for packet data absent the padding data.

Term
0.9 yearsto projected expiry
Projected expiry 28 August 2027, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
39 claims: 9 independent, 30 dependent
- 1A communication device comprising:a. a port to receive an asynchronous padded packet comprising a plurality of data bits and a plurality of padding bits from a network;and b. a counter to count the data bits in the padded packet received from the network;c. a buffer;and d. a cryptographic engine, coupled to the port, counter and buffer, to remove the padding bits from the received padded packet and store the data bits in the buffer.
- 7A communication device for transmitting data comprising:a. a transmitter for transmitting a padded packet including received data bits;and b. a counter, within the transmitter, to count the number of data bits transmitted, wherein the transmitter combines the received data bits with padding bits by automatically inserting a number of the padding bits into the padded packet, the number of padding bits being determined based on a count value of the counter and further based on a minimum desired packet length.
- 11A wireless communication device comprising:a. a receiver receiving a padded packet having data bits and padding bits, the receiver removing the padded bits before storing the data bits;and b. a memory coupled to the receiver, the memory storing the data bits absent the padding bits.
- 13A wireless communication device comprising:a. a cryptographic engine receiving data bits to be transmitted, determining how many padding bits are required by a selected encryption algorithm, including the required number of padding bits with the data bits before encryption, and encrypting the data bits and padding bits to form an encrypted padded packet;and b. a transmitter receiving the encrypted padded packet from the cryptographic engine and transmitting the encrypted padded packet.
- 14A method for transmitting data comprising:a. receiving within a transmitter, data bits from a processor;b. transmitting each of the received data bits from the transmitter;c. using a counter within the transmitter to count the data bits transmitted;and d. automatically inserting within the packet, a number of padding bits and transmitting the packet from the transmitter, the number of padding bits being based on the number of data bits transmitted as indicated by the counter and further based on a minimum desired packet length.
- 23Broadest claimClaim Score 91, very broad(NHIP)A method for receiving encrypted data comprising:a. receiving within a transmitter, an encrypted padded packet having data bits and padding bits;b. decrypting the padded packet;c. removing the padding bits;and d. storing the data bits absent the padding bits to a memory outside the transmitter.
- 29A method of ciphering a packet using a cryptographic engine comprising:a. receiving data bits in the cryptographic engine;b. adding, within the cryptographic engine, padding bits to the received data bits based on the number of received data bits and a desired length for the packet;and c. encrypting the received data bits and added padding bits within the cryptographic engine, to encrypt the packet.
- 37A method for transmitting a packet using IPSec (Internet Protocol Security) protocols comprising:a. a. transmitting a packet from a Transport layer to a Network (IP) layer, wherein the packet includes an authentication header (AH) and an encryption service payload (ESP), and wherein the ESP payload handles encrypted IP data of variable length and has padding bits of a determined padding length to ensure the data will be a predetermined length;b. encrypting and padding the data within a cryptographic engine connected to a transceiver of an Ethernet controller, wherein the data, the padding bits, a value indicating padding length, and a next header are encrypted;and c. wrapping the packet in a second IP packet.
- 39A method for receiving a packet using IPSec (Internet Protocol Security) protocols comprising:a. decrypting the packet within a cryptographic engine connected to a receiver of an Ethernet controller using security data available to the cryptographic engine;b. removing padding bits and an outer IP header;and c. passing decrypted unpadded data to a Transport layer.
Independent claims9
35 paragraphs in 5 sections, as filed
FIELD OF THE INVENTION
0001The invention relates to the field of data packet management and more specifically to the field of managing of data packets in such a manner that power consumption is reduced.
BACKGROUND OF THE INVENTION
0002Currently, there exists a standard for transmitting datagrams over Ethernet networks. The basic unit of data transmission over an Ethernet network is a frame wherein the Ethernet frame defines the data layout at the OSI Layer 2 link level. Ethernet has a minimum packet size because the transmission of a packet at the source node without hearing a collision is assumed to be an acknowledgement of the transmission and no collisions are assumed until the source has heard the end of packet transmission.
0003The length of an Ethernet frame is typically no less than 64 bytes or 512 bits and no more than 1518 bytes. The 64 bytes consist of two 6-byte addresses, 2-bytes of type, 4-bytes CRC, and 46 bytes of data. The exception to the minimum length is the Gigabit Ethernet standard where the minimum packet size is increased to 512 bytes.
0004A runt packet is then considered as a packet that is smaller than the minimum Ethernet frame size of 64 bytes excluding the preamble. This minimum size is tied to the maximum propagation time of an Ethernet network segment (51.2 microseconds) and it takes approximately 51.2 microseconds to transmit 64 bytes of data. Therefore, every node on the segment is aware that another node is transmitting before the transmission is complete, providing for more accurate collision detection. Typically, if the host has less than 46 bytes of data to send, the host pads bytes to make the data into 46 bytes.
0005This operation is typically done at the processor or microcontroller in communication with the Ethernet controller.
0006Furthermore, in some cases, other padding is done to ensure security of the packet over the network. For example, this padding is done to conceal the actual length of the payload or the header.
0007In wireless communication, it is desired to transmit as few bytes as possible and, therefore, padding is typically undesirable. That said, it must be employed, where necessary, to meet a standard, such as the Ethernet standard. This results in padding and unpadding operations that are wasteful of processing time and, for portable devices, battery power.
SUMMARY OF THE INVENTION
0008In accordance with the invention there is provided a method of removing padding from a packet comprising: receiving a packet from a network at a receiver, the packet comprising padding data; storing a portion of the data packet including other than padding data within a memory; and, other than storing a portion of the data packet comprising padding data within the memory.
0009In accordance with the invention there is provided a method of inserting padding within a packet comprising: receiving a packet from a memory, the packet absent padding data; transmitting the packet via a network; and, automatically inserting padding data within the packet during transmission thereof.
0010In accordance with the invention there is also provided a method of encrypting a packet using a cryptographic engine comprising: receiving data, the packet comprising padding data; performing a cipher operation on the data including one of discarding padding data within data that is decrypted during the ciphering and adding padding data to the data prior to encryption thereof during the ciphering, the padding data other than stored within memory with the data in a plain text form.
BRIEF DESCRIPTION OF THE DRAWINGS
0011Exemplary embodiments of the invention will now be described in conjunction with the following drawings, in which:
0012<figref idref="DRAWINGS">FIG. 1</figref> illustrates a data packet processing system in accordance with a first embodiment of the invention;
0013<figref idref="DRAWINGS">FIG. 2</figref> illustrates operating steps according to the second embodiment of the invention for removal/insertion of padding of a packet;
0014<figref idref="DRAWINGS">FIG. 3</figref> shows a simplified data flow diagram showing a packet including padding received by the Ethernet controller;
0015<figref idref="DRAWINGS">FIG. 4</figref> illustrates a simplified data flow path diagram showing a data packet absent padding bytes for transmission from a transceiver;
0016<figref idref="DRAWINGS">FIG. 5</figref> illustrates data flow for a method for transmitting a packet using IPSec protocols according to a second embodiment of the present invention.
0017<figref idref="DRAWINGS">FIG. 6</figref> illustrates data flow for a method for receiving a packet using IPSec protocols wherein the cryptographic engine connected to the receiver of an Ethernet controller decrypts the packet, removes its padding and the new IP header and passes the unpadded data to the transport layer;
0018<figref idref="DRAWINGS">FIG. 7</figref> shows a simplified data flow diagram for transmitting a packet using IPSec protocols; and,
0019<figref idref="DRAWINGS">FIG. 8</figref> shows a simplified data flow diagram of a method for receiving an encrypted padded packet according to IPSec protocols.
DETAILED DESCRIPTION THE INVENTION
0020<figref idref="DRAWINGS">FIG. 1</figref> illustrates a method according to the invention for processing of an Ethernet frame. An Ethernet frame comprises a preamble used for synchronization; a start frame delimiter marking the start of a frame; a destination field showing the MAC address of the network node to which the frame is addressed; a source field showing the MAC address of the transmitting node; a length/type field indicating the number of bytes to follow in the data field; a data field containing the information being sent across the network; a Pad field used to lengthen the data field; and, a frame check sequence field to test for errors.
0021In order to detect collision across a network according to CSMA/CD, a minimum packet size of 64 bytes is set for an Ethernet frame wherein 46 bytes comprise the data. In the case where the data field is less than 46 bytes long, then the Pad field is filled with a zero-octet pattern. Typically, a collision occurs when two nodes attempt to transmit at the same time. A transmitting node is generally required to transmit the minimum packet size and detect whether collision has occurred. For 10 Mbps and 100 Mbps Ethernet, the slot time is 512 bit times, which is also the minimum length of an Ethernet packet. As such, any frame received by a node that is less than 64 bytes in length is automatically assumed to be a fragment from a collision and is discarded.
0022Typically, the microprocessor determines an amount of padding and performs the insertion and removal of padding for an Ethernet packet. The data packet including padding is then provided to a transceiver for transmission to the Ethernet network.
0023In wireless applications, reducing power consumption is extremely important resulting in a longer battery life and improving performance. This is possible through limiting an amount of data transmitted when possible. A further method for reducing power consumption in battery powered wireless devices is to limit processor operations and other power consuming operations. Each data transfer and each storage operation is known to consume power and is, therefore, beneficial only when necessary.
0024<figref idref="DRAWINGS">FIG. 1</figref> shows a simplified flow diagram of a method for receiving a frame including padding according to one embodiment of the invention. A packet is received at a transceiver. The transceiver includes a receiver of an Ethernet controller. Within the transceiver is a counter. When a received data packet includes padding therein, the data is received but only the data absent the padding bits is stored in a memory buffer. The memory buffer is for storing the data for later retrieval by a microprocessor. For example, the transceiver includes a counter for counting the number of bits until the start of padding. Once the counter has completed counting, the remainder of the packet data is discarded as it comprises only padding. Thus, the padding bytes are not processed, moved or stored within the data buffer or retrieved therefrom by the microprocessor. This saves power consumption that would be necessary to move the padding bits throughout the circuit.
0025Referring to <figref idref="DRAWINGS">FIG. 2</figref>, a simplified flow diagram of a method for padding a frame according to one embodiment of the invention is shown. An unpadded packet is received from a processor at a transceiver. The transceiver includes a transmitter for transmitting data, the data in the form of an Ethernet packet. Within the transceiver is a counter. When a received data packet absent padding therein but requiring padding is received from the processor, the amount of padding necessary is determined. The transmitter then transmits the data within the data packet and inserts padding bits as necessary during transmission thereof. Thus, the padding bytes need not be transferred from the processor to the transceiver. Though the term determined is used with relation to finding an amount of padding, it is a simple matter to have a counter counting down transmitted bits and when greater than zero, continuing the transmission with padding bits until the counter reaches zero.
0026For example, when the data packet is transferred from the processor via a memory buffer, the data packet is stored within the memory buffer. The memory buffer is for storing the data for retrieval by the transceiver and for transmission therefrom. Thus the padding bits are not stored by the processor in the memory buffer and need not be retrieved by the transceiver, thereby reducing power consumption over circuits that require the transfer of the padding bits.
0027In <figref idref="DRAWINGS">FIG. 3</figref> a data flow diagram showing a packet including padding received by the Ethernet controller is shown. If the amount of data X<b>2</b> within the packet is below 46 bytes then the packet includes padding therein of Y<b>2</b> bytes such that X<b>2</b>+Y<b>2</b>=46 bytes. The transceiver then ignores the padding bytes Y<b>2</b> such that only the data bytes X<b>2</b> absent the padding bytes are stored in the memory buffer. The data bytes X<b>2</b> absent the padding bytes Y<b>2</b> are retrieved from the buffer by the microprocessor. By reducing the number of bytes stored in the memory buffer from X<b>2</b>+Y<b>2</b> to X<b>2</b>, the number of bytes retrieved from the memory buffer and processed is reduced thereby decreasing memory access operations by 2(Y<b>2</b>)—one store and one retrieve per padding byte—and decreasing power consumption for the data receive operation.
0028<figref idref="DRAWINGS">FIG. 4</figref> illustrates a data flow path diagram showing a data packet absent padding bytes for transmission from a transceiver. For example, if a packet with X<b>1</b> bytes of data being less than 46 bytes is to be transmitted, the microprocessor loads the X<b>1</b> bytes into the buffer to be retrieved by the transceiver of an Ethernet controller. The transceiver transmits the retrieved bytes and then, during transmission, adds Y<b>1</b> padding bytes such that the data comprises 46 bytes. In this manner, the transceiver only retrieves X<b>1</b> bytes from the buffer and generates the further Y<b>1</b> bytes for transmission therefrom. The resulting operation requires Y<b>1</b> fewer store operations and Y<b>1</b> fewer retrieve operations thereby reducing power consumption.
0029<figref idref="DRAWINGS">FIG. 5</figref> illustrates a method for transmitting a packet using IPSec protocols according to a second embodiment of the present invention. As shown, a packet is transmitted from the transport layer to the Network (IP) layer. Typically, this framework includes an authentication header (AH) and encryption service payload (ESP) where the combination provides privacy, integrity and authentication for IP. Typically data that is encrypted is referred to encrypted data, data that is decrypted refers to decrypted data, data that is unsecured is referred to as plain text data, and ciphering is used as a term to denote both encryption and decryption processes.
0030The ESP payload handles encryption of the IP data and the payload data is of variable length as the ESP also contains 0 bytes to 255 bytes of padding to ensure the data will be of the correct length for particular types of encryption processes. ESP typically puts information both before and after a protected data. In the present embodiment of the invention, the cryptographic engine connected to the transceiver of the Ethernet controller handles the encryption and the padding. For encryption, the data, the padding and the padding length and the next header are encrypted. The packet then adds a new IP header thereby wrapping the IP packet in another IP packet. In this manner the packet remains secure upon transmission and is not easily analyzable by a third-party.
0031Alternatively, <figref idref="DRAWINGS">FIG. 6</figref> shows that upon receiving a packet encrypted using IPSec protocols, the cryptographic engine connected to the receiver of an Ethernet controller decrypts the packet, removes its padding and the new IP header and passes the unpadded data to the transport layer. Typically, this removal of padding is performed at the microprocessor, thereby requiring a larger than necessary data transfer to and from a memory buffer. By performing the padding and removal of padding within the cryptographic engine, the power required for data transfer is reduced while maintaining functionality.
0032Referring to <figref idref="DRAWINGS">FIG. 7</figref>, a data flow diagram for transmitting a packet using IPSec protocols is shown. The packet is received from the transport layer comprising an IP header and the rest of the packet passed from the transport layer. A cryptographic engine determines a padding length in accordance with a selected encryption algorithm. The padding is then inserted within the data during encryption such that the padding data need not be transferred numerous times to and from memory, thereby saving power. The encrypted data packet including padding bytes therein is then passed along the network such that the length of the original IP packet and its contents are not easily determinable without a cryptographic engine supporting a same encryption standard and having security information necessary for decrypting the encrypted data packet.
0033Referring to <figref idref="DRAWINGS">FIG. 8</figref>, a data flow diagram of a method for receiving an encrypted padded packet according to IPSec protocols is illustrated. The received packet containing an ESP payload and variable padding is received by a cryptographic engine having security data available thereto for use in accessing data secured within the encrypted data packet. The cryptographic engine decrypts data within the packet and stores the data absent padding data within a memory buffer for being accessed by a processor. Thus, padding bytes within the decrypted data are not transferred to the processor thereof, thereby saving power for the overall operation.
0034Advantageously, the embodiments described above operate within existing standards to provide improved power performance for portable and battery operated devices. Though the invention is described with reference to transceivers, it is equally applicable to receivers, transmitters, and to cryptographic engines.
0035Numerous other embodiments may be envisaged without departing from the spirit or scope of the invention.
Contents5
10 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US10348506B2 | Cited by | United States of America | Search report |
| WO2022268105A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US11071059B2 | Cited by | United States of America | Applicant |
| US10200348B2 | Cited by | United States of America | Search report |
| US10588083B2 | Cited by | United States of America | Applicant |
| US2022015032A1 | Cited by | United States of America | Search report |
| WO2018213497A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
6 members in 1 office
Priority claims14
| Document | Office | Kind | Date |
|---|---|---|---|
| 70445905 | United States of America | P | |
| 70445905 | United States of America | P | |
| 49741806 | United States of America | A | |
| 49741806 | United States of America | A | |
| 201313958041 | United States of America | A | |
| 201313958041 | United States of America | A | |
| 201514846670 | United States of America | A | |
| 11497418 | – | – | – |
| 13958041 | – | – | – |
| 60704459 | – | – | – |
| US20050704459P | – | – | – |
| US20060497418 | – | – | – |
| US201313958041 | – | – | – |
| US201514846670 | – | – | – |
Members6
| Document | Office | Kind | |
|---|---|---|---|
| US2007091886A1 | United States of America | A1 | |
| US8514894B2 | United States of America | B2 | |
| US2013329885A1 | United States of America | A1 | |
| US9130800B2 | United States of America | B2 | |
| US2015382238A1 | United States of America | A1 | |
| US10244428B2 | United States of America | B2 |
76 transactions on the USPTO file
Allowed after 1 non-final rejection and 1 final rejection.
- Non-final rejections
- 1
- Final rejections
- 1
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Response to Reasons for AllowanceREAS | REAS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Applicant Initiated Interview SummaryMEXIA | MEXIA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Interview Summary- Applicant InitiatedEXIA | EXIA | |
| Electronic request for Examiner InterviewM865E | M865E | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Paralegal or electronic terminal disclaimer approvedP574 | P574 | |
| Paralegal or electronic terminal disclaimer approvedP574 | P574 | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Terminal Disclaimer FiledDIST | DIST | |
| Terminal Disclaimer FiledDIST | DIST | |
| Response after Final ActionA.NE | A.NE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Paralegal TD Not acceptedP575 | P575 | |
| Paralegal TD Not acceptedP575 | P575 | |
| New or Additional Drawing FiledC614 | C614 | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Terminal Disclaimer FiledDIST | DIST | |
| Terminal Disclaimer FiledDIST | DIST | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response to Election / Restriction FiledELC. | ELC. | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Notice of Informal or Non-Responsive AmendmentNINA | NINA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Informal or Non-Responsive Amendment after Examiner ActionA.I. | A.I. | |
| Response to Election / Restriction FiledELC. | ELC. | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Restriction RequirementMCTRS | MCTRS | |
| Restriction/Election RequirementCTRS | CTRS | |
| Email NotificationEML_NTR | EML_NTR | |
| Application ready for PDX access by participating foreign officesCCRDY | CCRDY | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Email NotificationEML_NTR | EML_NTR | |
| Application Is Now CompleteCOMP | COMP | |
| Application Is Now CompleteCOMP | COMP | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| FITF set to NO - revise initial settingFTFI | FTFI | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Oath or Declaration Filed (Including Supplemental)C602 | C602 | |
| Patent Term Adjustment - Ready for ExaminationPTA.RFE | PTA.RFE | |
| Entity Status Set To Undiscounted (Initial Default Setting or Status Change)BIG. | BIG. | |
| Initial Exam Team nnIEXX | IEXX |
3 recorded assignments at the USPTO, latest first
- Now
Now: Held by
SYNOPSYS INC - 2015-12-10
Assignment of assignors interest.
Ownership change- From
- DAVIS STEPHEN
- To
- SYNOPSYS INC
Recorded 2015-12-10, Signed 2015-12-09
- 2015-11-23
Assignment of assignors interest.
- From
- BORZA MICHAEL
- To
- SYNOPSYS INC
Recorded 2015-11-23, Signed 2015-11-15
- 2015-10-08
Assignment of assignors interest.
- From
- ELLIPTIC TECHNOLOGIES INC
- To
- SYNOPSYS INC
Recorded 2015-10-08, Signed 2015-10-08
5 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication
- 20150382238
- Publication, DOCDB
- 2015382238
- Publication, EPODOC
- US2015382238
- Application
- 14846670
- Application, DOCDB
- 201514846670
- Application, EPODOC
- US201514846670
Titles
- English
- Method for Inserting and Removing Padding from Packets
Patent term adjustment
- A delay
- +314 daysthe office missed an examination deadline
- B delay
- +203 dayspendency past three years
- Applicant delay
- −126 days
- Net adjustment
- 391 days
Classification
- CPC, 7
- H04W28/06
- H04L12/413
- H04L63/0485
- H04L63/164
- H04W52/0229
- Y02D30/70
- H04L29/06959
- IPC, 3
- H04W28 06
- H04L29 06
- H04W52 02
- USPC, 1
- 370389000