AU2011267957A1 - Systems and methods for data packet transmission - Google Patents
Systems and methods for data packet transmissionInfo
- Publication number
- AU2011267957A1 AU2011267957A1 AU2011267957A AU2011267957A AU2011267957A1 AU 2011267957 A1 AU2011267957 A1 AU 2011267957A1 AU 2011267957 A AU2011267957 A AU 2011267957A AU 2011267957 A AU2011267957 A AU 2011267957A AU 2011267957 A1 AU2011267957 A1 AU 2011267957A1
- Authority
- AU
- Australia
- Prior art keywords
- data integrity
- led
- integrity value
- data
- network packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Description
SYSTEMS AND METHODS FOR DATA PACKET TRANSMISSION
TECHNICAL FIELD
[0001] This disclosure relates generally to systems and methods for transmitting data packets, and more particularly to systems and methods for reducing the
transmission of static data and improving the utilization of available bandwidth for the transmission of variable data.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] Non-limiting and non-exhaustive embodiments of the disclosure are described, including various embodiments of the disclosure with reference to the figures, in which:
[0003] FIG. 1 A illustrates a flow chart of a method for preparing and transmitting a network packet that includes a data integrity value that may be utilized to verify a static datum and variable data included in the network packet.
[0004] FIG. 1 B illustrates a flow chart of a method for receiving a network packet prepared according to the method illustrated in FIG. 1A and verifying the static datum and variable data included in the network packet.
[0005] FIG. 2A illustrates a conceptual representation of one embodiment of the preparation of a network packet for transmission.
[0006] FIG. 2B illustrates a conceptual representation of the processing of a network packet that was prepared and transmitted according to the method of FIG. 2A.
[0007] FIG. 3A illustrates a flow diagram of a method, in which an IED transmits a network packet including a data integrity value based on a seed value corresponding to identification information of the transmitting IED.
[0008] FIG. 3B illustrates a flow diagram of a method 350, in which a receiving IED receives and verifies a network packet transmitted according to the method illustrated in FIG. 3A.
[0009] FIG. 4 illustrates a block diagram of one embodiment in which several lEDs are communicatively coupled via a communications network.
[0010] FIG. 5 is a functional block diagram of an IED that is configured to transmit, receive, and/or verify a static datum and a variable datum based on a data verification value.
[0011] In the following description, numerous specific details are provided for a thorough understanding of the various embodiments disclosed herein. However, those skilled in the art will recognize that the systems and methods disclosed herein can be
practiced without one or more of the specific details, or with other methods, components, materials, etc. In addition, in some cases, well-known structures, materials, or operations may not be shown or described in detail in order to avoid obscuring aspects of the disclosure. Furthermore, the described features, structures, characteristics may be combined in any suitable manner in one or more alternative embodiments.
DETAILED DESCRIPTION
[0012] Data may be transmitted on a communication network by sending and receiving data encapsulated in network packets. Each network packet may include a header section and a payload section. As the term is used herein, a payload section refers to data to be communicated in a data packet. In contrast, a header section comprises data to route and/or interpret a data packet. For example, a header section may contain information identifying the packet's destination, source, length, version, service, protocol, etc. In various systems, the header section may only be utilized in the transmission process, and the header section may be discarded once the payload has been received by the destination system and verified.
[0013] A header section of a network packet may include information identifying a sender of the network packet and a data integrity value that allows a recipient to verify that the network packet arrived unchanged. As the term is used herein, a data integrity value comprises a value generated by any function or algorithm that generates a datum from an arbitrary block of digital data for the purpose of detecting alterations or variations in the data. The integrity of the original data can be checked at any later time by recalculating the data integrity value using the same pre-defined function or algorithm and comparing it with the received data integrity value. If the recalculated data integrity value and the received data integrity value do not match, the data was likely altered between the transmitting and receiving points. Examples of data integrity values include checksums, hash values, cryptographic hash values, data fingerprints, digital signatures, and the like. Each of the foregoing types of data integrity values may be generated by a corresponding function, namely a checksum function, a hash function, a cryptographic hash function, a data fingerprint function, and a digital signature function, respectively.
[0014] In certain applications, it may be desirable to configure a device to only accept input from or communicate with an authorized device. A network packet
recipient may use sender identification information to verify that a particular network packet originated from an authorized sender. For example, an intelligent electronic device (IED) in an electric power delivery system (such as a transmission or distribution system) may be configured to communicate only with certain authorized lEDs. A recipient IED may disregard network packets that originate from unauthorized or unexpected sender lEDs. A significant premium may be placed on data integrity in a power delivery system, since data corruption may result in undesirable consequences {e.g., interruption of electrical service to end users, failure to trip a faulted line, and the like). Accordingly, a receiving IED may be configured to disregard network packets transmitted by inadvertently cross-connected or unauthorized devices.
[0015] Due to electrical noise on data communication media (such as, for example, conductive lines, fiber-optic cables, radio frequency communication media, and the like) or other communication errors, it is possible for one or more bits of data in a bit stream to become corrupt during transmission. In such cases a network packet may be considered corrupt and may not be useable. According to various embodiments disclosed herein, a data integrity value may be utilized to verify that the data
encapsulated within a received network packet arrived unchanged. Further, various embodiments disclosed herein may also allow for the verification of a static datum using the data integrity value.
[0016] The size of a network packet may depend on the transmission protocol and bandwidth available in a system. For example, in high bandwidth systems {e.g., 1 Mb/s and higher), a network packet may contain thousands of bits; the header may be a small percentage of the overall packet size. However, some protocols and lower bandwidth systems {e.g., transmission systems having a transmission rate lower than 1 Mb/s), may utilize packets limited to only a few hundred bits or fewer. When
transmitting packets with relatively small packet sizes, the header may consume a larger percentage of the total available bandwidth in a system then when transmitting packets with larger packet sizes. Accordingly, reducing the amount of data transmitted in a header section may correspondingly increase the bandwidth available to transmit payload data. In various embodiments disclosed herein, a static datum may be omitted from network packets; however, the static datum may be used by both the sending and receiving device in order to generate and verify a data integrity value.
[0017] For example, a monitoring IED in a power system may be configured to monitor a power system parameter such as current on each of three phases of a power
line and to provide digitally encoded current samples to a control lED every millisecond. The monitoring lED may be configured to report information only to the control lED and to receive instructions only from the control lED. The connection between the monitoring lED and the control lED may be relatively limited in bandwidth {e.g., 64 kb/s). The packet size in such a system may be constrained by the time-sensitive nature of the data. In other words, in order for the monitoring lED to provide a timely data sample to the control lED every millisecond, at least one data packet is transmitted every millisecond. Each data packet may include header information in order to correctly route the packet, identify the sender, and provide a data integrity value. In this system, the identity of the sender remains constant during normal operation. Using the systems and methods described herein, the use of system bandwidth to transmit static data, such as the identity of the sender, may be decreased or avoided, and accordingly a greater portion of the system's bandwidth may be dedicated to transmission of useful data.
[0018] According to one embodiment, a sending lED calculates a first data integrity value based on the payload of a network packet and sending lED identification information. The transmitted network packet may include the first data integrity value, but may omit the sending lED's identification information from the network packet. A receiving lED may replace the omitted sending lED identification information with expected identification information preprogrammed into the receiving lED. The receiving lED may then calculate a second data integrity value of the received network packet payload together with the expected identification information. The second data integrity value may only match the first data integrity value included in the network packet if the expected identification information matches the sending lED identification information used to calculate the first data integrity value. Accordingly, a network packet is verified only if the network packet was not corrupted during transmission and the expected identification information matches the sending lED identification
information. If an unauthorized or cross-connected lED transmits a network packet to a receiving lED, the network packet will fail verification. As will be discussed in greater detail below, verification failures may be addressed in a variety of ways.
[0019] According to an alternative embodiment, a sending lED calculates a data integrity value of a network packet based on a seed value corresponding to sending lED identification information. As the term is used herein, a seed is an initialization value when calculating a data integrity value. Similarly, a receiving lED verifies
received network packets using an expected seed value corresponding to expected identification information. Accordingly, only network packets transmitted by one or more sending lEDs authorized to communicate with a particular receiving IED may be verified by the one or more receiving lEDs.
[0020] According to various embodiments, by omitting a static datum from
transmitted network packets, a larger percentage of each network packet may be used for the payload. Furthermore, by encoding a static datum within a data integrity value included in each network packet, a receiving IED may verify the static datum, together with the payload data.
[0021] If a receiving IED receives a threshold number of sequential network packets that fail verification, there may be an inadvertent cross-connection or other error in the system. According to various embodiments, a receiving IED may be configured to report such an error and/or attempt to identify and report the identification information of the cross connected or errant IED.
[0022] Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearance of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, an "embodiment" may be a system, a method, or a product of a process.
[0023] Throughout the remainder of the disclosure specific examples relating to power monitoring and delivery systems are provided. However, it will be readily apparent to one of skill in the art that similar principles may be applied to other applications, including general-purpose communication networks.
[0024] The phrases "connected to," "networked," and "in communication with" refer to any form of interaction between two or more entities, including mechanical, electrical, magnetic, and electromagnetic interactions. Two components may be connected to each other even though they are not in direct physical contact with each other and even though there may be intermediary devices between the two components.
[0025] Some of the infrastructure that can be used with embodiments disclosed herein is already available, such as: general-purpose computers, computer
programming tools and techniques, digital storage media, and communications networks. A computer may include a processor such as a microprocessor,
microcontroller, logic circuitry, or the like. The processor may include a special purpose processing device such as an ASIC, PAL, PLA, PLD, Field Programmable Gate Array, or other customized or programmable device. The computer may also include a computer readable storage device such as non-volatile memory, static RAM, dynamic RAM, ROM, CD-ROM, disk, tape, magnetic, optical, flash memory, or other computer- readable storage medium.
[0026] As used herein, the term I ED may refer to any microprocessor-based device that monitors, controls, automates, and/or protects monitored equipment within the power system. Such devices may include, for example, remote terminal units, differential relays, distance relays, directional relays, feeder relays, overcurrent relays, voltage regulator controls, voltage relays, breaker failure relays, generator relays, motor relays, automation controllers, bay controllers, meters, recloser controls,
communications processors, computing platforms, programmable logic controllers (PLCs), programmable automation controllers, input and output modules, and the like. lEDs may be connected to a network, and communication on the network may be facilitated by networking devices including but not limited to multiplexers, routers, hubs, gateways, firewalls, and switches, each of which may also be considered an IED. The networking devices may use a variety of physical media such as electrical, optical fiber or radio-wave connections. Furthermore, networking and communication devices may be incorporated in an IED or be in communication with an IED. The term IED may be used interchangeably to describe an individual IED or a system comprising multiple lEDs.
[0027] Aspects of certain embodiments described herein may be implemented as software modules or components. As used herein, a software module or component may include any type of computer instruction or computer executable code located within a computer-readable storage medium. A software module may, for instance, comprise one or more physical or logical blocks of computer instructions, which may be organized as a routine, program, object, component, data structure, etc., that performs one or more tasks or implements particular abstract data types.
[0028] In certain embodiments, a particular software module may comprise disparate instructions stored in different locations of a computer-readable storage medium, which together implement the described functionality of the module. Indeed, a module may comprise a single instruction or many instructions, and may be distributed over several different code segments, among different programs, and across several
computer-readable storage media. Some embodiments may be practiced in a distributed computing environment where tasks are performed by a remote processing device linked through a communications network. In a distributed computing
environment, software modules may be located in local and/or remote computer readable storage media. In addition, data being tied or rendered together in a database record may be resident in the same computer readable storage medium, or across several computer readable storage media, and may be linked together in fields of a record in a database across a network.
[0029] The software modules described herein tangibly embody a program, functions, and/or instructions that are executable by computer(s) to perform tasks as described herein. Suitable software, as applicable, may be readily provided by those of skill in the pertinent art(s) using the teachings presented herein and programming languages and tools, such as XML, Java, Pascal, C++, C, database languages, APIs, SDKs, assembly, firmware, microcode, and/or other languages and tools. Additionally, software, firmware, and hardware may be interchangeably used to implement a given function.
[0030] In the following description, numerous details are provided to give a thorough understanding of various embodiments. One skilled in the relevant art will recognize, however, that the embodiments disclosed herein can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of this disclosure.
[0031] FIG. 1A illustrates a flow chart of a method 100 for transmitting a network packet that includes a data integrity value. The data integrity value may be utilized to verify a static datum and variable data. In connection with FIG. 1A, an example is provided, in which the static datum comprises information identifying a transmitting IED. Information identifying a transmitting IED may include, for example, an IED name, identification number, a firmware/software identification value, and the like. An IED name or identification number may be used to ensure that data from an inadvertently cross-connected device is not used by the receiving end. A firmware/software identification value may be used to ensure that the transmitting and receiving lEDs are compatible, so that the meaning of the transmitted data is correctly understood by the receiving device. For example, a new firmware revision may change a scaling value of a data item. If the transmitting and receiving lEDs having different firmware revisions
use different scaling values, the data may not be interpreted or processed correctly. In other words, checking compatibility of firmware revisions may help to prevent misinterpretation of data. In other examples, the static datum may represent another type of datum {e.g., feeder information, an identification of a cryptography key, etc.).
[0032] According to the illustrated embodiment, at 1 10 the transmitting IED may join identification information of the transmitting IED to data to be transmitted, thus creating a joined set of identification information and data. In various embodiments, the identification information may comprise the transmitting lED's user-assigned name, serial number, model number, firmware version, Media Access Control (MAC) address, Internet Protocol (IP) address, and/or combinations of any of the foregoing.
[0033] At 1 15, the IED may then calculate a data integrity value of the joined set of identification information and data. A data integrity value may be obtained using any of a number of available algorithms, including but not limited to, a parity word, any variety of checksum algorithms {e.g., a BSD checksum, a Fletcher's checksum, an Adler checksum), a Cyclic Redundancy Check (CRC), a Bose-Chaudhuri-Hocquienghem
(BCH) check, a Longitudinal Redundancy Check (LRC), a Reed-Solomon block code, a Hamming code, and the like.
[0034] In various embodiments disclosed herein, verifying the identity of a sender of a data packet may be accomplished even though the packet does not include information explicitly identifying the sender. At 120 the transmitting IED may disjoin the identification information from the data, and at 125, the IED may create a network packet comprising the data integrity value and the data, but it omits the identification information. In one embodiment, the data integrity value is included within the header of the network packet. In other embodiments, the data integrity value may be appended to the end of the data packet. The omission of sender identification information may allow for more bits in each data packet to be allocated for payload data. At 130, the IED transmits the network packet comprising the data and the data integrity value.
[0035] According to method 100, the number of bits used for identification
information does not reduce the size of the network packet available to transmit variable data {e.g., the payload section) because the identification information is not included in the network packet. A variety of types of data integrity algorithms, such as those referenced above, may be used to produce a fixed-size data integrity value from an arbitrarily large data set. Accordingly, a variety of types of data may be utilized in
order to provide identification infornnation and to encode the identification infornnation in a data integrity value.
[0036] FIG. 1 B illustrates a flow chart of a method 150 for receiving a network packet prepared according to the method illustrated in FIG. 1A and verifying the static datum and variable data included in the network packet. At 155, a receiving lED receives the network packet comprising a received data integrity value and received data. At 160, the receiving lED may calculate a second data integrity value using expected identification information and the received data.
[0037] As described above, the data integrity value included in the received packet was calculated using the transmitting lED's sender identification information, together with the data to be transmitted. Accordingly, the expected sending lED identification information is joined to the received data, and a second data integrity value of the received data and expected identification information is calculated by the receiving lED. In various embodiments, the expected identification information may be
preprogrammed in the receiving lED (i.e., may have been provided prior to receipt of the packet being analyzed), may be transmitted periodically by the transmitting lED, or may be derived by the receiving lED. The expected identification information may correspond to one or more lEDs from which the receiving lED is authorized to receive network packets.
[0038] After replacing the previously disjoined sender identification information of the transmitting lED with the expected identification information, the receiving lED may calculate a second data integrity value of the joined data and expected identification information. At 170, the second data integrity value may be compared to the received data integrity value to verify the network packet's data integrity and that the network packet was transmitted by an lED from which the receiving lED expects to receive data. That is, if the expected identification information of the receiving lED matches the sender identification information of the transmitting lED and the data was not corrupted during transmission, the second data integrity value will match the received data integrity value.
[0039] At 170, if the received network packet is verified (by determining that the second data integrity value matches the received data integrity value), then the received data can be used by the receiving lED, at 175. If the received data fails verification, the data may be discarded, at 171 A, or alternatively, a request for retransmission of the unverified data may be generated, at 171 B. In systems in which
data is time-sensitive {e.g., an approximately real-time feed of data), receipt of each data packet may not be necessary, and unverified data may be dropped. In other instances, however, receipt of each packet may be necessary (e.g., the transmission of a digital file across a data network), and thus retransmission of the data may be requested.
[0040] In certain embodiments, at 173, where verification of data has failed, the system may attempt to verify the data using alternative identification data. For example, a receiving IED may have access to identification information of a plurality of transmitting lEDs. Accordingly, the receiving IED may calculate alternative data integrity values using identification data of the known plurality of transmitting lEDs. If the number of transmitting lEDs is relatively small, a receiving IED may be able to identify the source of the data. In certain embodiments, an alert may notify an operator of a configuration change and/or configuration error that is causing network packets to be misrouted. The identification of the inadvertently connected source of data may be displayed when generating the alert. Determining the source of the data may simplify and accelerate troubleshooting of the problem.
[0041] The receipt of a threshold number of packets that have failed verification may indicate a persistent change, such as a change in a system's configuration.
Accordingly, at 185, a determination may be made as to whether a threshold number of packets have failed verification. For example, if 100 sequential packets fail verification, an unexpected configuration change may have occurred, or a substantial source of noise may have been introduced. In either case, the verification failure may be reported to a system operator at 190 and end.
[0042] FIG. 2A illustrates a conceptual representation of the preparation of a network packet for transmission, according to one embodiment. At 201 , a transmitting IED prepares data to be transmitted 210. As described above, the network packet to be transmitted may include a payload section and a header section. The header section may comprise one or more static pieces of data. In the illustrated example, the static datum comprises IED identification information 220 of the transmitting IED. A variety of types of identification information may be utilized. For example, various embodiments may utilize one or more of the following: a user-assigned name, a serial number, a model number, a firmware version, a Media Access Control (MAC) address, an Internet Protocol (IP) address, combinations of the above, and the like. In typical operation, each of these values may remain static.
[0043] At 203, the transmitting lED may join its identification information 220 to data to be transmitted 210. According to various embodiments, lED identification
information 220 may be joined to the beginning, inserted within, or joined at the end of the data to be transmitted 210. Certain data transmission algorithms insert the data integrity value at or near the end of the packet. Inserting the data integrity value at the end of the packet may allow for calculation of the data integrity value approximately in real time, and as such, the data integrity value may not be known until the entire packet is formed. At 205, the transmitting lED may calculate data integrity value 230 based on lED identification information 220 and data to be transmitted 210. As discussed above, a variety of types of algorithms may be utilized to generate an appropriate data integrity value, based upon the transmitting lED identification information 220 and data to be transmitted 210.
[0044] At 207, lED identification information 220 {e.g., the static datum) may be disjoined or otherwise removed from the network packet. At 209, the transmitting lED may transmit the network packet, including data integrity value 230 and data to be transmitted 210, but omitting transmitting lED identification information 220. According to various embodiments, the transmitting lED identification information 220 may be provided to a receiving lED prior to the transmission of a network packet. This information may be preprogrammed into the receiving lED, or in other embodiments, this information may be sent from the transmitting lED to a receiving lED according to a schedule.
[0045] By omitting the transmitting lED identification information 220 from each network packet, a greater proportion of the network packet may be allocated to the payload. Further, the data integrity value may be utilized to provide an indication of data corruption, as well as an indication of the identity of the transmitting lED. In certain embodiments, a receiving lED may be configured to differentiate between a verification failure caused by a transmission error and a verification failure caused by receiving a data packet from an unexpected transmitting lED. In systems in which the receiving lED is able to calculate alternative data integrity values using alternative transmitting lED identification information, the system may identify data packets received from an unexpected transmitting lED. In this way, if a transmitting lED is cross-connected or otherwise sends an unauthorized network packet to a receiving lED, the unauthorized network packet may fail verification. To the extent that the receiving lED is able to verify the network packet using alternative transmitting lED
identification infornnation, the verification failure is caused by receiving a data packet from an unexpected source. To the extent that the receiving lED cannot verify the packet using alternative transmitting lED identification information, the system may conclude that the verification failure was caused by a transmission error.
[0046] FIG. 2B illustrates a conceptual representation of the processing of a network packet that was prepared and transmitted according to the method of FIG. 2A. At 250, a receiving lED receives a network packet from a transmitting lED. The received network packet comprises a received data integrity value 270 and received data 260. At 252, the receiving lED may join expected lED identification information 280 to received data 260. At 254, the receiving lED may calculate a second data integrity value 285, based on the expected lED identification information 280 and the received data 260.
[0047] If expected I ED identification information 280 corresponds to the I ED
identification information omitted from the packet prepared according to the method of Fig. 2A, then the calculated data integrity value 285 will match received data integrity value 270. At 290, calculated data integrity value 285 may be compared with received data integrity value 270. If calculated data integrity value 285 matches received data integrity value 270, verification of the received network packet is successful 295. If, on the other hand, calculated data integrity value 285 does not match received data integrity value 270, verification fails 293. A network packet that fails verification may signify that the network packet was corrupted during transmission and/or that the transmitting lED was not an lED from which the receiving lED expected to receive a network packet. If the transmitting lED was not an lED from which the receiving lED expected to receive a network packet, the lED may report a configuration error in the communications network.
[0048] FIG. 3A illustrates a flow diagram of a method 300, in which an lED transmits a network packet including a data integrity value based on a seed value corresponding to identification information of the transmitting lED. A receiving lED may be configured with the same seed value in order to use the data integrity value to verify a received network packet. Accordingly, the transmitting lED may omit identification information from the network packet, while still allowing a receiving lED to verify that the network packet was transmitted by an expected lED.
[0049] In the embodiment illustrated in FIG. 3A, a seeded data integrity value may be calculated using a static datum 310. In one example, the static datum may comprise
a transmitting lED's identification information. The seed data integrity value may be calculated using any number of data integrity algorithms, including those listed above.
[0050] At 315, a seeded data integrity value may be calculated based on the seed data integrity value and at least one variable datum. In other words, the calculations utilized to generate the seed data integrity value need not be recalculated. Rather a data integrity value algorithm may begin with the seed data integrity value as an initial value, and only perform calculations in order to modify the seed data integrity value based on the variable datum.
[0051] At 320, the transmitting I ED creates a network packet. The network packet may include a header section, which may comprise the seeded data integrity value, and a payload section, which may contain the variable data to be transmitted. According to various embodiments, the header section may also comprise information used to route the network packet to the intended recipient. At 325, the IED transmits the network packet containing the data and the data integrity value.
[0052] FIG. 3B illustrates a flow diagram of a method 350, in which a receiving IED receives and verifies a network packet transmitted according to the method illustrated in FIG. 3A. The receiving IED may receive the seed data integrity value at some point prior to transmission of a network packet. At 355, the receiving IED receives the network packet containing the received seeded data integrity value and the received data. At 360, the receiving IED calculates a second seeded data integrity value using the seed data integrity value and the received data. The preconfigured seed value may correspond to the seed value used by the transmitting IED. According to various embodiments, a receiving IED may be preconfigured with multiple seed values, each corresponding to the identification information of lEDs from which the receiving IED expects to receive network packets. Accordingly, the receiving IED may need to calculate a data integrity value using each of its preconfigured data integrity values to determine which, if any, authorized IED transmitted the network packet.
[0053] At 370, the calculated seeded data integrity value and the received seeded data integrity value may be compared. If the calculated seeded data integrity value and the received seeded data integrity value match, the verification is successful 375. If the calculated seeded data integrity value and the received seeded data integrity value do not match, the verification fails 371 . In one embodiment, when verification fails 371 , the receiving IED may attempt to verify the integrity of the network packet using alternative seed data integrity values.
[0054] FIG. 4 illustrates a block diagram of a communications network 400 comprising lEDs 440-456 and communications networks 460 and 470. According to various embodiments, communications network 400 may include any number of lEDs and/or communications networks. As illustrated in FIG. 4, lEDs 440-456 are connected to one or more communications networks 460 and/or 470. For example, IED 450 may communicate with IED 452 through communications network 460, and with IED 446 through communications network 460 and communications network 470. According to alternative embodiments, some lEDs may be in direct communication with other lEDs.
[0055] According to one embodiment, lEDs 440-456 are part of an electric power delivery system. In this embodiment, it may be desirable to configure certain lEDs to communicate only with other specified lEDs. For example, lEDs 440-446 may be control lEDs, each of which makes decisions based on monitoring lEDs 450-456. For example, IED 446 may be configured to control a power system relay in response to data received from IED 456. IED 446 may be configured to disregard network packets transmitted by other lEDs. Thus, if IED 454 transmits a network packet to IED 446, it should be disregarded.
[0056] According to one embodiment, to ensure that IED 446 only responds to data transmitted by IED 456, each network packet transmitted by IED 456 may include sender identification information in the header of the network packet. Receiving IED 446, may then confirm that IED 456 transmitted the network packet by reviewing the sender identification information. IED 446 may use a data integrity value contained within the transmitted network packet to verify that the network packet arrived without data corruption. The transmission of identification information may reduce the amount of useful data that can be transmitted.
[0057] According to another embodiment, a transmitting IED omits the sender identification information from the network packet, and instead generates a data integrity value using the transmitting lED's identification information, together with the data to be transmitted. In this manner, a receiving IED may verify a received network packet's data integrity by calculating a matching data integrity value using expected identification information, so long as the expected identification information is the same as the sender identification information.
[0058] Returning to the example described above, IED 456 transmits a network packet to IED 446 that includes a data integrity value based on the contents of the network packet and the sender identification information of IED 456. However, IED 456
may not transmit the sender identification information of lED 456. IED 446 may receive the transmitted network packet and calculate a data integrity value based on the contents of the network packet and expected identification information. The expected identification information may be preprogrammed in IED 446 and may correspond to the sender identification of IED 456. Thus, the data integrity value calculated by IED 446 will match the data integrity value included in the network packet transmitted by IED 456.
[0059] The network packet may fail verification if the data is corrupted during transmission or if the expected identification information does not match the sender identification information of IED 456. For example, IED 454 transmits a network packet to IED 446 including a data integrity value based on the contents of the network packet and the sender identification information of IED 454. IED 446 may be authorized to only receive network packets from IED 456. IED 446 may calculate a data integrity value of the received network packet based on expected identification information corresponding to IED 456. The data integrity value calculated by IED 446 may be different than the data integrity value transmitted by IED 454 because the sender identification information of IED 454 does not match the expected identification information of IED 446. The network packet may fail verification and be disregarded by IED 446. According to one example, only those network packets transmitted by lEDs whose sender identification information corresponds to a receiving lEDs expected identification information are verified by the receiving IED.
[0060] FIG. 5 is a functional block diagram of an IED 500 that is configured to transmit, receive, and/or verify a static datum and a variable datum based on a data verification value. IED 500 includes a processor 530, a Random Access Memory (RAM) 540, and a network interface 550. A data bus 520 interconnects these components and also connects these components to a computer-readable storage medium 570. Processor 530 may be embodied as a general-purpose processor, an application specific processor, a microcontroller, a digital signal processor, a field- programmable logic array, or other device known in the art. Processor 530 performs logical and arithmetic operations based on program code stored within computer- readable storage medium 570. Computer-readable storage medium 570 may comprise various modules executable on processor 530. According to various embodiments, processor 530, RAM 540, network interface 550, bus 520, and computer-readable storage medium 570 may comprise any number of hardware, software, firmware and/or
similar components, as may be appreciated by one of skill in the art. Computer- readable storage medium 570 may include one or more modules 572-580.
[0061] According to various embodiments, modules 572-580 may be omitted and/or additional modules may be included. IED 500 may include a data integrity value calculation module 572 configured to calculate a data integrity value to be transmitted in a network packet. Furthermore, the data integrity value may be calculated based on the contents of the network packet together with identification information of IED 500. Alternatively, the data integrity value may be calculated on the contents of the network packet using a seed value corresponding to sender identification information of IED 500.
[0062] IED 500 may include network packet transmission module 574 configured to interface with network interface 550 to transmit network packets. IED 500 may further include network packet receiving module 576 configured to interface with network interface 550 to receive network packets. IED 500 may also include network packet verification module 578 configured to verify that received network packets were transmitted by lEDs from which IED 500 expects to receive data.
[0063] According to one embodiment network packet verification module 578 calculates a data integrity value based on at least a portion of a received network packet together with expected identification information preprogrammed in IED 500. According to one embodiment, if the value returned from the data integrity value calculated by IED 500 matches the data integrity value transmitted in the received network packet, then both the sender of the packet and the data contained in the packet are verified. According to an alternative embodiment, IED 500 calculates a data integrity value based on at least a portion of a received network packet using a seed value corresponding to expected identification information. Again, if the data integrity value calculated by IED 500 matches the data integrity value transmitted with the network packet then the network packet is verified. If the data integrity values do not match, then the network packet may fail verification.
[0064] According to one embodiment, IED 500 further includes network packet identification module 580 configured to identify the sender of a threshold number of sequential network packets that fail verification. According to one embodiment, if a threshold number of network packets fail verification, then network packet identification module 580 may report an error. Additionally, network packet identification module 580 may attempt to verify the network packet using alternative seed values and/or expected
identification information. IED 500 may still consider network packets verified using alternative identification information by network packet identification module 580 to be unverified; however, IED 500 may be able to report the identity of an IED transmitting unauthorized or cross-connected network packets.
[0065] The above description provides numerous specific details for a thorough understanding of the embodiments described herein. However, those of skill in the art will recognize that one or more of the specific details may be omitted, or other methods, components, or materials may be used. In some cases, operations are not shown or described in detail.
[0066] While specific embodiments and applications of the disclosure have been illustrated and described, it is to be understood that the disclosure is not limited to the precise configuration and components disclosed herein. Various modifications, changes, and variations apparent to those of skill in the art may be made in the arrangement, operation, and details of the methods and systems of the disclosure without departing from the spirit and scope of the disclosure.
Claims (20)
1 . A method of transmitting data in a data network, comprising:
a first intelligent electronic device (lED) calculating a first data integrity value based on a static datum and a variable datum;
the first lED transmitting a network packet using a data network in electrical communication with the first lED and a second lED, the network packet comprising the first data integrity value and the variable datum and the network packet omitting the static datum;
a second lED receiving the network packet comprising the first data integrity value and the variable datum, the network packet omitting the static datum;
the second lED calculating a second data integrity value based on the static datum and the variable datum; and
the second lED verifying the network packet by comparing the first data integrity value and the second data integrity value.
2. The method of claim 1 , wherein the static datum comprises identification information of the first lED.
3. The method of claim 2, wherein the identification information comprises information selected from the group consisting of a user assigned name, a serial number, a model number, a firmware version, a media access control address, and an Internet Protocol address.
4. The method of claim 1 , wherein the static datum comprises a seeded data integrity value, the seeded data integrity value comprising an output of a data integrity algorithm.
5. The method of claim 4, wherein an input of the data integrity algorithm comprises identification information of the first lED.
6. The method of claim 1 , wherein the variable datum represents at least one characteristic of an electric power delivery system.
7. The method of claim 1 , further comprising communicating the static datum to the second lED prior to the first lED transmitting the network packet.
8. The method of claim 1 , further comprising configuring the second lED using the static datum prior to the first lED transmitting a network packet.
9. The method of claim 1 , further comprising periodically transmitting the static datum to the second lED according to an established schedule.
10. The method of claim 1 , further comprising determining that the first data integrity value differs from the second data integrity value.
1 1 . The method of claim 1 , further comprising:
the second lED receiving a threshold number of sequential network packets, each of which comprises a data integrity value and variable data;
the second lED failing to verify any of the threshold number of sequential network packets using expected identification information;
the second lED reporting that a threshold number of sequential network packets failed verification.
12. The method of claim 1 1 , further comprising,
the second lED attempting to verify each of the threshold number of sequential network packets using alternative identification information;
wherein the alternative identification information corresponds to a third lED.
13. The method of claim 1 , wherein the data integrity value comprises one of a parity word, a BSD checksum, a Fletcher's checksum, an Adler checksum, a Cyclic Redundancy Check, a Bose-Chaudhuri-Hocquienghem check, a Longitudinal
Redundancy Check, a Reed-Solomon block code, and a Hamming code.
14. A system to transmit encoded identification information in a network packet, comprising:
a first Intelligent Electronic Device (lED), comprising
a first network interface to communicate with other networked devices; a first processor in communication with the first network interface;
a first computer-readable storage medium in electrical communication with the processor and comprising computer instructions executable on the first processor, the first computer-readable storage medium comprising:
a first data integrity value calculation module to calculate a first data integrity value based on identification information of the first IED and a variable datum;
a first network packet transmission module to transmit a network packet comprising the first data integrity value and the variable datum and to omit the static datum;
a second IED, comprising
a second network interface to communicate with the first IED; a second processor in communication with the second network interface; a second computer-readable storage medium in electrical communication with the processor and comprising computer instructions executable on the second processor, the computer-readable storage medium comprising:
an expected identification information;
a network packet verification module to calculate a second data integrity value based on the variable datum and the expected identification information;
wherein the network packet verification module compares the first data integrity value and the second data integrity value to verify that the network packet originated from the first IED.
15. The system of claim 14, wherein the identification information of the first
IED comprises information selected from the group consisting of a user-assigned name, a serial number, a model number, a firmware version, a media access control address, and an Internet Protocol address.
16. The system of claim 14, wherein the variable datum represents at least one characteristic of an electric power delivery system.
17. An Intelligent Electronic Device (IED) to transmit data in a data network, comprising: a network interface to communicate with other networked devices; a processor in communication with the network interface;
a computer-readable storage medium in electrical communication with the processor and comprising computer instructions executable on the processor, the computer-readable storage medium comprising:
a data integrity value calculation module to calculate a data integrity value based on a static datum and a variable datum;
a network packet transmission module to transmit a network packet comprising the data integrity value and the variable datum and to omit the static datum.
18. The system of claim 17, wherein the static datum comprises identification information of the IED.
19. The system of claim 18, wherein the identification information comprises information selected from the group consisting of a user-assigned name, a serial number, a model number, a firmware version, a media access control address, and an Internet Protocol address.
20. The system of claim 17, wherein the static datum comprises a seeded data integrity value, the seeded data integrity value comprising an output of a data integrity algorithm, and wherein an input of the data integrity algorithm comprises the identification information.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/818,410 US8565229B2 (en) | 2010-06-18 | 2010-06-18 | Systems and methods for data packet transmission |
US12/818,410 | 2010-06-18 | ||
PCT/US2011/040165 WO2011159603A2 (en) | 2010-06-18 | 2011-06-13 | Systems and methods for data packet transmission |
Publications (2)
Publication Number | Publication Date |
---|---|
AU2011267957A1 true AU2011267957A1 (en) | 2012-12-20 |
AU2011267957B2 AU2011267957B2 (en) | 2015-03-12 |
Family
ID=45328627
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
AU2011267957A Ceased AU2011267957B2 (en) | 2010-06-18 | 2011-06-13 | Systems and methods for data packet transmission |
Country Status (8)
Country | Link |
---|---|
US (1) | US8565229B2 (en) |
AU (1) | AU2011267957B2 (en) |
BR (1) | BR112012030680A2 (en) |
CA (1) | CA2802986A1 (en) |
MX (1) | MX2012013819A (en) |
NZ (1) | NZ604054A (en) |
WO (1) | WO2011159603A2 (en) |
ZA (1) | ZA201208816B (en) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102349450B1 (en) * | 2014-12-08 | 2022-01-10 | 삼성전자주식회사 | Method and Apparatus For Providing Integrity Authentication Data |
US20160191678A1 (en) * | 2014-12-27 | 2016-06-30 | Jesse C. Brandeburg | Technologies for data integrity of multi-network packet operations |
CN109993002B (en) * | 2017-12-29 | 2023-12-22 | 西门子公司 | Data integrity protection method and device |
CN113572578B (en) * | 2021-07-28 | 2023-06-30 | 南方电网数字电网研究院有限公司 | TCP data transmission method, device, equipment and medium based on data center |
Family Cites Families (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2108442C (en) | 1992-10-16 | 2000-04-25 | Jeffrey B. Roberts | Fault identification system for use in protective relays for power transmission lines |
US5793750A (en) | 1995-10-20 | 1998-08-11 | Schweitzer Engineering Laboratories, Inc. | System of communicating output function status indications between two or more power system protective relays |
US6518767B1 (en) | 2000-10-19 | 2003-02-11 | Schweitzer Engineering Laboratories, Inc. | Line differential protection system for a power transmission line |
US6590397B2 (en) | 2000-10-19 | 2003-07-08 | Schweitzer Engineering Laboratories, Inc. | Line differential protection system for a power transmission line |
EP1255372B1 (en) | 2001-05-03 | 2008-03-19 | Telefonaktiebolaget LM Ericsson (publ) | Method and system for data integrity protection |
US6947269B2 (en) | 2001-07-06 | 2005-09-20 | Schweitzer Engineering Laboratories, Inc. | Relay-to-relay direct communication system in an electric power system |
US8111492B2 (en) | 2001-07-06 | 2012-02-07 | Schweitzer Engineering Laboratories, Inc. | Apparatus, system, and method for creating one or more slow-speed communications channels utilizing a real-time communication channel |
US7463467B2 (en) | 2001-07-06 | 2008-12-09 | Schweitzer Engineering Laboratories, Inc. | Relay-to-relay direct communication system and method in an electric power system |
US7779267B2 (en) * | 2001-09-04 | 2010-08-17 | Hewlett-Packard Development Company, L.P. | Method and apparatus for using a secret in a distributed computing system |
US7010613B2 (en) * | 2001-09-07 | 2006-03-07 | Intel Corporation | Methods and apparatus for reducing frame overhead on local area networks |
US7356596B2 (en) * | 2001-12-07 | 2008-04-08 | Architecture Technology Corp. | Protecting networks from access link flooding attacks |
GB0226420D0 (en) * | 2002-11-13 | 2002-12-18 | Koninkl Philips Electronics Nv | An improved communications protocol |
US7603710B2 (en) | 2003-04-03 | 2009-10-13 | Network Security Technologies, Inc. | Method and system for detecting characteristics of a wireless network |
US7913294B1 (en) * | 2003-06-24 | 2011-03-22 | Nvidia Corporation | Network protocol processing for filtering packets |
US7577895B2 (en) | 2004-09-30 | 2009-08-18 | Intel Corporation | Initialization seed to allow data padding for cyclic redundancy code calculation |
US7987367B2 (en) * | 2006-08-30 | 2011-07-26 | Samsung Electronics Co., Ltd. | Method and apparatus for key agreement between devices using polynomial ring |
KR100905378B1 (en) | 2006-08-30 | 2009-07-01 | 가부시키가이샤 도모에가와 세이시쇼 | Fiber optic coil and method for producing it |
US7630863B2 (en) | 2006-09-19 | 2009-12-08 | Schweitzer Engineering Laboratories, Inc. | Apparatus, method, and system for wide-area protection and control using power system data having a time component associated therewith |
FR2909241B1 (en) | 2006-11-27 | 2009-06-05 | Canon Kk | METHODS AND DEVICES FOR DYNAMICALLY MANAGING TRANSMISSION ERRORS THROUGH NETWORK INTERCONNECTION POINTS. |
US8045589B2 (en) * | 2007-04-26 | 2011-10-25 | Kyocera Corporation | Radio communication system with data structure change |
US8571021B2 (en) * | 2009-06-10 | 2013-10-29 | Microchip Technology Incorporated | Packet based data transmission with reduced data size |
US8154836B2 (en) | 2009-09-17 | 2012-04-10 | Schweitzer Engineering Laboratories, Inc. | Line current differential protection upon loss of an external time reference |
-
2010
- 2010-06-18 US US12/818,410 patent/US8565229B2/en active Active
-
2011
- 2011-06-13 CA CA2802986A patent/CA2802986A1/en not_active Abandoned
- 2011-06-13 BR BR112012030680A patent/BR112012030680A2/en not_active IP Right Cessation
- 2011-06-13 AU AU2011267957A patent/AU2011267957B2/en not_active Ceased
- 2011-06-13 WO PCT/US2011/040165 patent/WO2011159603A2/en active Application Filing
- 2011-06-13 NZ NZ604054A patent/NZ604054A/en not_active IP Right Cessation
- 2011-06-13 MX MX2012013819A patent/MX2012013819A/en active IP Right Grant
-
2012
- 2012-11-22 ZA ZA2012/08816A patent/ZA201208816B/en unknown
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104539739B (en) | A kind of system, method and device that file uploads | |
AU2011267957B2 (en) | Systems and methods for data packet transmission | |
CN103595661B (en) | Message fragmentation restructuring method and device | |
CN110941859A (en) | Method, apparatus, computer-readable storage medium, and computer program product for block chain formation consensus | |
CN104601550B (en) | Reverse isolation file transmission system and method based on cluster array | |
WO2015109334A1 (en) | Usb power delivery multiple drop using cyclic redundancy check | |
CN105939201A (en) | Method and device for checking state of server | |
CN101902479A (en) | Network isolation system and data transmission method thereof | |
US8351605B2 (en) | Stealth message transmission in a network | |
AU2011267957A1 (en) | Systems and methods for data packet transmission | |
CN102404326B (en) | Method, system and device for validating safety of messages | |
Crain et al. | Bolt-on security extensions for industrial control system protocols: A case study of dnp3 sav5 | |
CN108894915B (en) | Wind power generation remote monitoring system and working method thereof | |
WO2022099683A1 (en) | Data transmission method and apparatus, device, system, and storage medium | |
CN105897689B (en) | Embedded system and method thereof | |
CN113259121A (en) | Method, device and equipment for safely transmitting monitoring data of capacitor bank | |
CN113852470A (en) | Proposal broadcasting method, device, equipment and storage medium | |
CN104348578A (en) | Data processing method and device | |
EP2822204B1 (en) | Communication device and communication method | |
Garcia et al. | Covert channel communication through physical interdependencies in cyber-physical infrastructures | |
CN110381050B (en) | Multi-protocol conversion and verification method and device for data packet | |
CN110198202B (en) | Method and device for checking AFDX (avionics full Duplex switched Ethernet) bus message data source | |
US10044469B2 (en) | Communication device and communication method | |
CN112383506A (en) | Network control device, method, equipment and medium of non-original module | |
CN108243034B (en) | Fault determination method, receiver and transmitter |