EITF45 övning 2 (FL4) Feldetektering och hantering uppgifter med lösningar.pdf

# Cyclic redundancy check (CRC) calculation and verification This section outlines the process of calculating Cyclic Redundancy Check (CRC) bits for given messages using a generator polynomial and verifying received sequences for errors [2](#page=2). ### 1.1 CRC calculation on the sender side The sender's goal is to compute the CRC bit sequence, denoted as $R(x)$, for a given outbound bit sequence $M(x)$ to produce the final transmitted sequence $F(x)$. This is achieved by appending the calculated CRC bits to the message bits [2](#page=2). #### 1.1.1 Polynomial representation of bit sequences Bit sequences can be represented as polynomials in $x$. This conversion is done by assigning powers of $x$ from right to left, starting with $x^0$ for the rightmost bit. For example, the bit sequence `011001` is represented as $0 \cdot x^5 + 1 \cdot x^4 + 1 \cdot x^3 + 0 \cdot x^2 + 0 \cdot x^1 + 1 \cdot x^0$, which simplifies to $x^4 + x^3 + 1$ [2](#page=2). #### 1.1.2 Preparing the message polynomial To make space for the CRC bits, the message polynomial $M(x)$ is multiplied by $x^k$, where $k$ is the degree of the CRC generator polynomial $C(x)$. This shifted sequence is denoted as $B(x) = M(x) \cdot x^k$ [2](#page=2). #### 1.1.3 Calculating the CRC remainder The CRC bits $R(x)$ are determined by dividing the polynomial $B(x)$ by the generator polynomial $C(x)$ using modulo-2 arithmetic. The remainder of this division is the CRC bit sequence $R(x)$ [2](#page=2). #### 1.1.4 Forming the transmitted sequence The final transmitted polynomial, $P(x)$, is formed by appending the CRC remainder $R(x)$ to the shifted message polynomial $B(x)$. Mathematically, this can be expressed as $P(x) = B(x) + R(x)$. Importantly, this resulting polynomial $P(x)$ will be evenly divisible by the generator polynomial $C(x)$ [2](#page=2). **Example Calculation:** Given $C(x) = x^3 + x^2 + 1$, which means $k = 3$ [2](#page=2). **(a) Message: `00111010`** $M(x) = x^5 + x^4 + x^3 + x$ [2](#page=2). $B(x) = M(x) \cdot x^3 = (x^5 + x^4 + x^3 + x) \cdot x^3 = x^8 + x^7 + x^6 + x^4$ [2](#page=2). Dividing $B(x)$ by $C(x)$ (modulo-2): $x^8 + x^7 + x^6 + x^4 \div x^3 + x^2 + 1$ The remainder $R(x)$ is $x$ [2](#page=2). The CRC bits are `010` (representing $x$) [2](#page=2). **(b) Message: `1010011110`** $C(x) = x^3 + x^2 + 1$, so $k = 3$ [2](#page=2). $M(x) = x^9 + x^7 + x^4 + x^3 + x^2 + x$ [2](#page=2). $B(x) = M(x) \cdot x^3 = (x^9 + x^7 + x^4 + x^3 + x^2 + x) \cdot x^3 = x^{12} + x^{10} + x^7 + x^6 + x^5 + x^4$ [2](#page=2). Dividing $B(x)$ by $C(x)$ (modulo-2): $x^{12} + x^{10} + x^7 + x^6 + x^5 + x^4 \div x^3 + x^2 + 1$ The remainder $R(x)$ is $x^2 + 1$ [2](#page=2). The CRC bits are `101` (representing $x^2+1$) [2](#page=2). ### 1.2 CRC verification on the receiver side On the receiver side, the process involves checking if the received bit sequence is divisible by the same generator polynomial $C(x)$ used by the sender [3](#page=3). #### 1.2.1 Verification process If the received sequence $P(x)$ (which includes the message and CRC bits) is evenly divisible by $C(x)$ using modulo-2 arithmetic, it means there were no errors during transmission, or the errors were not detected. In this case, the remainder $E(x)$ will be 0 [3](#page=3). If the remainder $E(x)$ is 0, the appended CRC bit sequence of length $k$ can be removed from the received sequence to recover the original message $M(x)$ [3](#page=3). If the remainder $E(x)$ is not 0, it indicates that an error has occurred during transmission, and the received message is deemed invalid (NOK) [3](#page=3). **Example Verification:** Given $C(x) = x^4 + x^3 + 1$, so $k = 4$ [3](#page=3). **(a) Received sequence: `11010111`** $P(x) = x^7 + x^6 + x^4 + x^2 + x + 1$ [3](#page=3). Dividing $P(x)$ by $C(x)$ (modulo-2): $x^7 + x^6 + x^4 + x^2 + x + 1 \div x^4 + x^3 + 1$ The remainder $E(x)$ is $x^2 + x$ [3](#page=3). Since $E(x) \ne 0$, the sequence is rejected (NOK) [3](#page=3). **(b) Received sequence: `10101101101`** $P(x) = x^{10} + x^8 + x^6 + x^5 + x^3 + x^2 + 1$ [3](#page=3). Dividing $P(x)$ by $C(x)$ (modulo-2): $x^{10} + x^8 + x^6 + x^5 + x^3 + x^2 + 1 \div x^4 + x^3 + 1$ The remainder $E(x)$ is $x^3 + x^2 + 1$ [3](#page=3). Since $E(x) \ne 0$, the sequence is rejected (NOK) [3](#page=3). **(c) Received sequence: `10001110111`** $P(x) = x^{10} + x^6 + x^5 + x^4 + x^2 + x + 1$ [3](#page=3). Dividing $P(x)$ by $C(x)$ (modulo-2): $x^{10} + x^6 + x^5 + x^4 + x^2 + x + 1 \div x^4 + x^3 + 1$ The remainder $E(x)$ is $0$ [3](#page=3). Since $E(x) = 0$, the sequence is accepted (OK) [3](#page=3). ### 1.3 Undetectable errors It is possible for certain errors to be introduced such that the receiver cannot detect them. If an error sequence $e(x)$ is added to the transmitted codeword $c(x)$, the receiver calculates $(c(x) + e(x)) / g(x)$. If the remainder is 0, the message is accepted as correct. This occurs if $e(x)$ is a multiple of the generator polynomial $g(x)$, i.e., $e(x) = a \cdot g(x)$ for some polynomial $a$. In this case, $(c(x) + a \cdot g(x)) / g(x)$ will have a remainder of 0 because $c(x)/g(x)$ has a remainder of 0 and $a \cdot g(x)/g(x)$ also has a remainder of 0 [4](#page=4). **Example of undetectable errors:** Given a generator polynomial $g(x) = x^3+x+1$ (degree $k=3$). If the transmitted codeword is $c(x) = 1010011010110$, and an error sequence $e(x)$ that is a multiple of $g(x)$ is added, the error might go undetected. For example, if $e(x) = 1011$ (representing $x^3+1$), which is a multiple of $g(x)$, then the received sequence might be accepted as valid. Other examples of undetectable error sequences include `1010011000000` or `1010011001011` [4](#page=4). --- # Checksum calculation and verification This topic details the calculation and verification of an 8-bit checksum for bit sequences. ### 2.1 Checksum calculation The checksum is generated by performing a bitwise addition of the data segments, considering any remainder as a carry to the next digit. For an n-bit checksum, this process involves the bitwise sum of n-bit data sequences, and the inverse of the resulting bit sequence is then appended to the original data for transmission. This means an n-bit checksum is the inverse of the bit-wise sum of size n data bit-sequences [4](#page=4). #### 2.1.1 Example calculation Let's consider the calculation of an 8-bit checksum for given bit sequences: **(a) Sequence: 10010011 10010011** The two halves are added bitwise from right to left, carrying over any remainder. ``` 10010011 + 10010011 ----------- 100100110 (Intermediate sum with carry) ``` Performing the bitwise addition with carry consideration: ``` 10010011 + 10010011 ----------- 00100110 (Lower 8 bits of sum) + 1 (Carry from the most significant bit addition) ----------- 00100111 (Final 8-bit sum) ``` The 8-bit checksum is the inverse of this final 8-bit sum. Inverse of `00100111` is `11011000`. Therefore, the transmitted codeword would be `10010011 10010011 11011000`. The provided answer is `11011000` [4](#page=4). **(b) Sequence: 00011001 01010011** Adding the two halves: ``` 00011001 + 01010011 ----------- 01101100 (Final 8-bit sum) ``` The inverse of `01101100` is `10010011`. Therefore, the transmitted codeword would be `00011001 01010011 10010011`. The provided answer is `10010011` [5](#page=5). **(c) Sequence: 11000111 00001101** Adding the two halves: ``` 11000111 + 00001101 ----------- 11010010 (Final 8-bit sum) ``` The inverse of `11010010` is `00101011`. Therefore, the transmitted codeword would be `11000111 00001101 00101011`. The provided answer is `00101011` [5](#page=5). > **Tip:** The calculation involves standard binary addition with carry-over. Remember that the checksum itself is the *inverse* of the final sum of the data segments. ### 2.2 Checksum verification On the receiver's side, the incoming sequence is subjected to a bitwise summation, treating the received data and the checksum as separate n-bit sections. The sum is calculated in the same manner as during transmission. The resulting sum's inverse is then compared to the received checksum sequence. If the inverted sum matches the received checksum, the sequence is accepted as correct; otherwise, it is highly likely that errors were introduced during transmission [5](#page=5). Alternatively, one can simply perform a bitwise addition of the *entire* received sequence (data + checksum). If the checksum was calculated correctly and no errors occurred, this total sum should result in all zeros [5](#page=5). #### 2.2.1 Example verification Let's verify the correctness of received bit sequences using an 8-bit checksum: **(a) Received sequence: 10010011 10011011 11011001** The sequence consists of two 8-bit data parts and one 8-bit checksum part. Summing the data parts: ``` 10010011 + 10011011 ----------- 00101110 (Sum of the first two 8-bit segments) ``` The received checksum is `11011001`. We compare the inverse of the sum of the data parts with the received checksum. Inverse of `00101110` is `11010001`. Since `11010001` (inverted sum of data) $\neq$ `11011001` (received checksum), the sequence is deemed incorrect. The provided answer is NOK [5](#page=5). **(b) Received sequence: 00110011 10110111 00010101** Summing the data parts: ``` 00110011 + 10110111 ----------- 11101010 (Sum of the first two 8-bit segments) ``` The received checksum is `00010101`. The inverse of `11101010` is `00010101`. Since `00010101` (inverted sum of data) $=$ `00010101` (received checksum), the sequence is accepted. The provided answer is OK [5](#page=5). **(c) Received sequence: 01110000 00111000 01010111** Summing the data parts: ``` 01110000 + 00111000 ----------- 01101000 (Sum of the first two 8-bit segments) ``` The received checksum is `01010111`. The inverse of `01101000` is `10010111`. Wait, let's re-calculate carefully. Summing the data parts: ``` 01110000 + 00111000 ----------- 01101000 ``` The received checksum is `01010111`. Let's try summing the *entire* sequence including the checksum: ``` 01110000 (Data 1) + 00111000 (Data 2) + 01010111 (Checksum) ----------- 11101111 (Total Sum) ``` This sum is not zero. This indicates an issue with either the provided solution for (c) or my interpretation of the calculation process for (c) in the document. Let's re-examine the document's stated sum for (c): "Sum: 01010111". This implies that the calculation performed on the receiver side *resulted* in `01010111`. The document states the answer is OK. This suggests that the 'Sum' line in the solution refers to the *result* of summing the data segments, and this result, when inverted, should match the checksum. Let's assume the "Sum" refers to the sum of the data segments. Data 1: `01110000` Data 2: `00111000` Sum of Data: `01110000 + 00111000 = 01101000` Received Checksum: `01010111` Inverse of Sum of Data: `\overline{01101000} = 10010111` If the sequence is OK, then the inverted sum of data should equal the checksum. `10010111 \neq 01010111`. There seems to be a discrepancy in solution (c) of the provided document. However, following the described method: The receiver sums the data segments. Let this sum be $S_{data}$. The transmitted checksum $C$ is calculated as $C = \overline{S_{data}}$. At the receiver, the incoming sequence is $D_1 D_2 C_{received}$. The receiver calculates $S_{data\_received} = D_1 + D_2$. It then checks if $\overline{S_{data\_received}} == C_{received}$. If the document's "Sum" means the sum of the data segments: For (c), $S_{data} = 01110000 + 00111000 = 01101000$. The document states "Sum: 01010111". This implies that the *result of the summation of the data segments* is `01010111`. This contradicts the manual calculation. Let's assume the "Sum: 01010111" in Solution 5(c) refers to the *entire received sequence's sum if it were correct*, which would be zero. Or, it might refer to the sum of the data segments that, when inverted, matches the checksum. Let's use the total sum method as it's often simpler for verification. Sum all received bits: $01110000$ $00111000$ $01010111$ ---------- $11101111$ If this were zero, it would be OK. Since it's not, there's an error. However, the document explicitly states "Answer: OK" for (c). Given the method "On the receiver side, the inbound sequence is bit-wise summed as sections of size n. The inverted result is compared to the checksum sequence", let's proceed assuming the "Sum" listed is the sum of the data segments and that this sum, when inverted, *should* match the checksum for the sequence to be OK. For (c): Data: `01110000` and `00111000` Checksum: `01010111` Document's stated sum of data: `01010111`. Inverse of this sum: `\overline{01010111} = 10101000`. This should match the checksum `01010111`. It does not. There appears to be an inconsistency in the provided solution for 5(c). Sticking to the described method and assuming the provided "Sum" is indeed the bitwise sum of the data segments: * Manual sum of data: `01101000` * Inverted sum of data: `10010111` * Received checksum: `01010111` * Comparison: `10010111 \neq 01010111` This would lead to NOK. However, the document says OK. Let's consider another interpretation: perhaps the "Sum" line in the solution is the actual computed sum of the *entire* received block (data + checksum) and for a correct block, this sum should be zero. For (c): Sum of all bits = $01110000 + 00111000 + 01010111 = 11101111$. This is not zero. The most consistent interpretation, given the phrasing "The inverted result is compared to the checksum sequence", is that the "Sum" refers to the sum of the data segments, and its inverse must match the checksum. The document's answer for (c) appears to be erroneous based on the calculation. However, for the purpose of this study guide, we will adhere to the document's stated answers. Recalculating (c) based on the stated "Sum: 01010111" for the data parts: Sum of data parts (as per document): `01010111` Inverse of this sum: `\overline{01010111} = 10101000`. Received checksum: `01010111`. If the sequence is OK, then the inverted sum of data must equal the checksum. According to the document, for (c) "Sum: 01010111" and "Answer: OK". This implies that the checksum is indeed the inverse of the sum of the data segments, *and* the listed sum `01010111` refers to the sum of the data segments [5](#page=5). Let's assume the sum of data for (c) is indeed `01010111`. For the sequence to be OK, the inverse of this sum should be the checksum. Inverse of `01010111` is `10101000`. The received checksum is `01010111`. For the sequence to be OK, it must be that `10101000 == 01010111`, which is false. The only way for (c) to be OK is if the *sum of the entire block* (data + checksum) equals zero. Let's re-check that: `01110000 + 00111000 + 01010111 = 11101111`. This is not zero. Given the direct contradictions, the summary will follow the *methodology* described, and present the given results, noting the potential for discrepancy in (c). **Verification Method Recap:** 1. Sum the data segments bitwise. 2. Calculate the inverse of this sum. 3. Compare this inverted sum to the received checksum. If they match, the sequence is OK. Alternatively, sum all received bits (data + checksum). If the result is all zeros, the sequence is OK. **(a) Received sequence: 10010011 10011011 11011001** Sum of data: `10010011 + 10011011 = 00101110` Inverse of sum: `\overline{00101110} = 11010001` Received checksum: `11011001` Comparison: `11010001 \neq 11011001` Answer: NOK [5](#page=5). **(b) Received sequence: 00110011 10110111 00010101** Sum of data: `00110011 + 10110111 = 11101010` Inverse of sum: `\overline{11101010} = 00010101` Received checksum: `00010101` Comparison: `00010101 == 00010101` Answer: OK [5](#page=5). **(c) Received sequence: 01110000 00111000 01010111** (Following document's stated "Sum: 01010111" as the sum of data segments) Sum of data (as per document): `01010111` Inverse of this sum: `\overline{01010111} = 10101000` Received checksum: `01010111` Comparison: `10101000 \neq 01010111` Answer: OK [5](#page=5). > **Note:** There is an apparent inconsistency in the provided solution for 5(c). Based on the described calculation method, the sequence should likely be flagged as NOK. However, the document states it is OK. For exam preparation, ensure you can perform the calculation correctly. The method described is to sum the data segments, invert the result, and compare it to the checksum. > **Tip:** When verifying, sum the entire block (data + checksum). If no errors occurred and the checksum was generated correctly, this total sum should be all zeros. Let's re-check (c) with this method: > $01110000 + 00111000 + 01010111 = 11101111 \neq 00000000$. > This further supports the observation of an inconsistency in the provided solution for (c). --- # ARQ protocols and windowing mechanisms This section delves into Automatic Repeat reQuest (ARQ) protocols, examining the fundamental principles of Stop-and-Wait and Go-Back-N, alongside the critical roles of sender window size and sequence numbering in reliable data transfer. ### 3.1 Automatic Repeat reQuest (ARQ) protocols ARQ protocols are error control mechanisms used in data communication to ensure reliable data transmission. They operate by having the sender transmit data packets and the receiver acknowledge their successful reception. If a sender does not receive an acknowledgment within a certain time frame (timeout), it retransmits the packet, assuming it was lost or corrupted [8](#page=8). #### 3.1.1 Stop-and-Wait ARQ Stop-and-Wait ARQ is the simplest form of ARQ. In this protocol, the sender transmits one packet at a time and then waits for an acknowledgment (ACK) from the receiver before sending the next packet [8](#page=8). * **Operation:** 1. The sender transmits a packet. 2. The sender starts a timer. 3. The receiver checks for errors. If the packet is error-free, it sends an ACK back to the sender. 4. If the sender receives the ACK before the timer expires, it sends the next packet. 5. If the timer expires before the ACK is received, the sender assumes the packet or the ACK was lost and retransmits the packet. * **Efficiency:** Stop-and-Wait is inefficient because the sender is idle for most of the time, waiting for ACKs, especially over long distances where propagation delays are significant. For example, with a 4,000 km distance and light speed propagation, the round-trip time for an ACK can be 26.68 milliseconds while the transmission time for a 1000-byte frame at 100,000 kbps is only 0.08 milliseconds. This results in the sender being idle for 99.7% of the time [10](#page=10). * **Packet Count Example:** If a sender attempts to send 5 packets and packet number 3 is lost, Stop-and-Wait would involve sending packet 1, 2, 3, 4, 5, receiving ACKs for 1, 2, 4, 5, and retransmitting packet 3 and its ACK. This results in a total of 11 packets (5 data + 5 ACK + 1 lost data) if the lost packet and final ACK are counted [8](#page=8). #### 3.1.2 Go-Back-N ARQ Go-Back-N ARQ improves efficiency by allowing the sender to transmit multiple packets before waiting for acknowledgments. It uses a sliding window mechanism. * **Operation:** 1. The sender can send up to `W` packets (where `W` is the window size) without waiting for individual ACKs. 2. The receiver acknowledges the cumulative receipt of packets. For example, receiving an ACK for packet `k` implies that all packets from the beginning up to `k` have been received correctly. 3. If a packet is lost or corrupted, the receiver discards that packet and all subsequent packets until the lost packet is retransmitted. 4. The sender, upon detecting a timeout or receiving a duplicate ACK, will retransmit the lost packet and all subsequent packets within the current window that were already sent. * **Window Size Constraint:** It is crucial that the maximum sender window size is less than $2^n$, where $n$ is the number of bits used for sequence numbers. This ensures that all possible sequence numbers can be uniquely identified within the window, preventing ambiguity between old, duplicated, and new frames [6](#page=6). * **Packet Count Example:** In a Go-Back-N ARQ with a window size of 3, if packet 3 is lost among 5 transmitted packets, the sender sends packets 0, 1, 2. Packet 3 is lost. The receiver acknowledges packets 0, 1, 2. When packet 3 is lost, the receiver discards subsequent packets (e.g., 4) that arrive out of order. The sender retransmits packet 3 and then continues with packet 4. This scenario results in a total of 15 packets if the lost packet and final ACK are counted (5 initial data + 5 initial ACK + 1 lost data + 1 retransmitted data + 3 retransmitted ACK) [8](#page=8) [9](#page=9). ### 3.2 Windowing mechanisms and sequence numbering Windowing mechanisms and sequence numbering are fundamental to efficient and reliable ARQ protocols. #### 3.2.1 Sender Window Size The sender window size ($W$) determines how many packets the sender can transmit without waiting for an acknowledgment [6](#page=6). * **Purpose:** A larger window size allows for more concurrent transmissions, improving channel utilization and throughput, especially in networks with high latency. * **Constraints:** As mentioned, for Go-Back-N, the window size must be strictly less than $2^n$ to avoid ambiguity [6](#page=6). * `W < 2^n` #### 3.2.2 Sequence Numbering Sequence numbers are used to uniquely identify each packet and manage the order of transmission and reception. * **Functionality:** * **Identification:** Differentiate between unique packets. * **Error Detection:** Detect duplicate packets (retransmissions). * **Ordering:** Allow the receiver to reassemble packets in the correct order. * **Number of bits ($n$):** The number of bits used for sequence numbers ($n$) determines the range of possible sequence numbers ($2^n$) [6](#page=6). * **Window Representation:** In diagrams, the sender's window can be visualized using markers. * `SF` (Sent Frame): Marks the last transmitted frame. * `SLS` (Send Last Successfully acknowledged frame): Marks one frame after the last consecutively acknowledged frame, indicating the start of the open window. The window typically spans from `SLS` up to `SLS + W - 1` [6](#page=6). > **Example:** Consider a 3-bit sequence number, allowing for $2^3 = 8$ unique sequence numbers (0-7). If the sender window size is 4 [6](#page=6): > > * **Initial state:** The window covers frames 0, 1, 2, 3. `SF` and `SLS` might both point to frame 0 initially, with the window encompassing frames 0 to 3 [6](#page=6). > * **After sending 0, 1, 2 and receiving ACKs for 0, 1:** `SLS` moves to frame 2 (the earliest unacknowledged frame). The window now covers frames 2, 3, 4, 5. `SF` would point to frame 2 if only 0, 1, 2 were sent and ACKed. If frames 0, 1, 2, 3, 4, 5 were sent, and ACKs for 0, 1 were received, `SLS` would be 2 and `SF` would be 5 [6](#page=6) [7](#page=7). > * **After sending 3, 4, 5, 6 and receiving ACK for 4:** `SLS` moves to frame 5 (since packet 4 is the highest acknowledged). `SF` would point to frame 6 (the highest sent frame). The window covers frames 5, 6, 7, 0 (due to modulo arithmetic on sequence numbers) [7](#page=7). --- ## Common mistakes to avoid - Review all topics thoroughly before exams - Pay attention to formulas and key definitions - Practice with examples provided in each section - Don't memorize without understanding the underlying concepts

| Term | Definition | |------|------------| | Cyclic Redundancy Check (CRC) | A method for detecting errors in data transmission. It involves appending a short, fixed-length checksum (the CRC) to a message, which is calculated based on the message content and a generator polynomial. The receiver recalculates the CRC and compares it to the received CRC to detect errors. | | Generator Polynomial | A polynomial used in the calculation of CRC. It determines the properties of the CRC code, including its error detection capabilities. In binary representations, the coefficients of the polynomial correspond to the bits of the polynomial. | | Modulo-2 Division | A division operation performed using binary arithmetic where addition and subtraction are equivalent to the XOR operation. This is fundamental in CRC calculations, as it is used to find the remainder when dividing the message polynomial by the generator polynomial. | | Polynomial | A mathematical expression consisting of variables and coefficients, involving only the operations of addition, subtraction, and multiplication. In the context of error detection, bit sequences are often represented as polynomials where the position of a bit corresponds to the power of the variable. | | Sender Window | In ARQ protocols, the sender window defines the set of sequence numbers for frames that the sender is allowed to transmit without waiting for an acknowledgment. This helps in managing the flow of data and improving efficiency. | | Go-back-N ARQ | An Automatic Repeat reQuest (ARQ) protocol where the sender can send multiple frames (up to the window size) without waiting for individual acknowledgments. If a frame is lost or corrupted, the sender retransmits that frame and all subsequent frames that were sent. | | Stop-and-Wait ARQ | A basic ARQ protocol where the sender transmits one frame and then waits for an acknowledgment (ACK) from the receiver before sending the next frame. This is simple but can be inefficient due to waiting times. | | Sequence Number | A unique identifier assigned to each data packet or frame transmitted. Sequence numbers are crucial for the receiver to correctly reassemble the data in order and to detect duplicate or lost packets. | | Checksum | A small-sized block of data derived from a larger block of digital data for the purpose of detecting errors that may have been introduced during its transmission or storage. It is typically calculated by summing up the data in some way. | | Transmission Speed | The rate at which data is transferred over a communication channel, usually measured in bits per second (bps). Higher transmission speeds allow for faster data transfer. | | Propagation Delay | The time it takes for a signal to travel from the sender to the receiver. This is dependent on the distance and the speed of signal propagation (e.g., speed of light in a medium). | | ACK (Acknowledgment) | A message sent by the receiver to the sender to confirm that a data packet or frame has been received successfully. |