# Module 13: Gateways & Mixed Networks

> TCP↔RTU routing, unit IDs, latency, and how to keep mixed deployments diagnosable.

**Phase:** Integration & Real Systems  
**Estimated time:** 11 min  
**Release status:** Published  
**Content version:** 1.0.0  
**Source:** https://learnmodbus.studioseventeen.io/lesson/gateways-mixed-networks

## What you'll be able to do
- Route a TCP request to a serial server using the Unit ID.
- Predict gateway-induced latency and exception behavior.
- Diagnose 'works in dev, fails through the gateway' problems.

## Three things people get wrong
1. **Assuming the gateway forwards exceptions verbatim.** Some gateways synthesize their own exceptions on timeout. The exception code may not match the device's behavior.
2. **Polling faster than the slowest serial bus.** The serial side has a max throughput. Over-polling causes queueing and gateway-side timeouts.
3. **Reusing Unit ID 1 for two devices.** Each device behind the gateway needs a unique Unit ID — this is the gateway's only addressing handle.

## From the field
**The gateway with a 50 ms quiet window**

A perfectly working integration started timing out after a firmware bump. The new gateway enforced a 50 ms gap between RTU polls; the SCADA was issuing back-to-back reads. Spacing the polls fixed it; the lesson was to always profile the actual round-trip after a gateway change.

## References
- [Modbus gateway design patterns (Modbus.org wiki)](https://modbus.org/)

## Lesson

# Module 13 Lesson: Gateways And Mixed Networks
## Learner Outcome

By the end of this module, learners can trace a Modbus request through a mixed TCP and serial path, explain how the Unit Identifier may affect gateway routing, distinguish transparent routing from mapped gateway behavior, and classify gateway failures without treating product-specific behavior as a universal Modbus rule.

## Key Concepts

- A gateway connects different Modbus transports while preserving the Modbus PDU concept.
- True Modbus TCP uses an MBAP header and does not include an RTU address byte or RTU CRC.
- A TCP-to-RTU gateway may use the MBAP Unit Identifier as a downstream serial server address.
- Some gateways use mapping tables, internal device profiles, cached values, or agent-style polling instead of transparent forwarding.
- Gateway exceptions `0A` and `0B` are valid Modbus exception responses, not the same thing as client-side silence.
- Polling through a gateway must account for downstream serial timing, retries, map gaps, read quantity limits, data freshness, and bus load.

## Key Terms

- Gateway: a device or software path that bridges transports, routes requests, maps addresses, or exposes downstream devices.
- Transparent routing: gateway behavior where the upstream request is forwarded with minimal application-level mapping.
- Mapped routing: gateway behavior where a route table, profile, or internal mapping changes how requests reach downstream targets.
- Downstream serial server: the serial-side Modbus server reached through a gateway.
- Cache/freshness: whether returned data is current or stored by the gateway.
- Gateway exception: a Modbus exception response related to gateway path or downstream target behavior.

## Source-Grounded Explanation

### The Gateway Boundary

The Modbus PDU is the function code plus data. Each transport wraps that PDU differently:

```text
Modbus TCP side:  MBAP Header | Function Code | Data
Serial RTU side:  Server Address | Function Code | Data | CRC Low | CRC High
```

A TCP-to-RTU gateway sits at that boundary. It receives a Modbus TCP ADU, uses routing configuration such as the Unit Identifier or a mapping table, builds a serial request, waits for the downstream serial response, then returns a Modbus TCP response to the upstream client.

The PDU may be the same operation on both sides, but the wrapper is not the same. If a client tool sends RTU-over-TCP bytes to a gateway expecting true Modbus TCP, the problem is the selected mode, not the register map.

### Unit Identifier And Route Evidence

The Unit Identifier is part of the Modbus TCP MBAP header. It is not a generic documentation prefix and it is not the same thing as the `4xxxx` holding-register notation.

Gateway paths commonly use the Unit Identifier to select a downstream serial server. For example, Unit Identifier `7` may route to downstream RTU server address `7`. That is a common gateway pattern, not a protocol guarantee for every product.

Use this evidence hierarchy:

| Evidence | What It Can Prove | Source Boundary |
|---|---|---|
| TCP request bytes | Transaction Identifier, Protocol Identifier, Length, Unit Identifier, function code, PDU address, and quantity. | Official TCP guide for field meanings; synthetic fixture unless captured. |
| Gateway route table or manual | Whether Unit Identifier maps directly to a downstream server, a table entry, or an internal profile. | Vendor-specific note for the selected gateway. |
| Downstream serial capture or gateway log | Which RTU server address, function, address, quantity, and CRC the gateway emitted. | Lab/tool evidence; not generic unless repeated by source. |
| TCP response bytes | Whether the client received a normal response, Modbus exception response, or no response before timeout. | Official protocol for response shape; gateway reason may be product-specific. |

Some manuals or tools may call the downstream route value a device ID, slave ID, server ID, unit ID, or address. In this course, use `Unit Identifier` for the MBAP byte and `downstream serial server address` for the RTU/ASCII address. Mention legacy `slave ID` only when reading older manuals or tool labels.

### Transparent Versus Mapped Gateways

Gateway behavior belongs in one of three buckets until the selected product manual proves otherwise:

| Gateway Pattern | Practical Meaning | Learner Question |
|---|---|---|
| Transparent routing | The gateway uses the TCP Unit Identifier as the downstream serial address and forwards the PDU with minimal application-level mapping. | Does Unit Identifier `7` actually generate a serial request to address `7`? |
| Mapped routing | The gateway uses a route table, address map, tag map, or device profile to choose the downstream request. | What configured map turns the client's request into the downstream request? |
| Cached or agent behavior | The gateway or data agent may poll downstream devices separately and answer upstream reads from stored values. | What proves the value is fresh and tied to the current downstream state? |

Do not teach cache age, timeout defaults, concurrent-client limits, or mapping-table rules as generic Modbus facts. Those are product or lab-configuration facts.

### Gateway Exceptions

The Modbus application protocol includes gateway-related exception codes:

| Exception | Name | Practical Meaning |
|---:|---|---|
| `0A` | Gateway Path Unavailable | The gateway could not allocate or use the path needed for the request. |
| `0B` | Gateway Target Device Failed To Respond | The gateway processed the upstream request but did not receive the expected response from the downstream target. |

Exception `0B` is different from a client-side timeout. With `0B`, the gateway sent a valid Modbus exception response. With a timeout, the upstream client received no valid response before its own deadline.

### Timeout And Polling Strategy

Mixed networks have a timing chain:

```text
TCP client timeout
  must allow for
gateway queueing + serial transmission + downstream response time + retries + gateway response
```

The upstream client timeout should be long enough for the gateway to finish the downstream attempt and return a normal response or a gateway exception. Numeric timeout values must come from the selected gateway manual, downstream device manual, lab configuration, or measured capture evidence.

Polling design also changes through a gateway. A fast Ethernet client can overload one half-duplex serial trunk if it polls too many devices, too many registers, or too many clients at once. Group reads by device, function, register-map continuity, update rate, safety impact, data type, and freshness requirement.

## Practical Example: Transparent TCP-To-RTU Routing

Scenario: A SCADA client reads a temperature value through a TCP-to-RTU gateway.

| Item | Value |
|---|---|
| Upstream transport | Modbus TCP |
| Downstream transport | Modbus RTU over RS-485 |
| Gateway IP | `192.0.2.50` documentation example address |
| TCP port | `502` for classic Modbus TCP |
| Unit Identifier | `7`, intended downstream RTU server address |
| Function code | `03` Read Holding Registers |
| Documented register | Holding register `40021` |
| Actual PDU address | `0x0014` if the map uses one-based `40001` notation |
| Quantity | `2` registers |
| Data type | 32-bit signed integer, high word first |
| Scale/unit | `0.1 deg C` |
| Expected normal response | Function `03`, byte count `4`, two registers of data |
| Likely exception/failure mode | `0B` if downstream server `7` does not respond; client timeout if the gateway is unreachable; `02` if the address/range is invalid |

Request path:

1. The TCP client sends an MBAP header with Unit Identifier `7`, then PDU `03 00 14 00 02`.
2. The gateway route configuration decides whether Unit Identifier `7` maps to downstream server address `7`.
3. In a transparent routing fixture, the gateway builds RTU request `07 03 00 14 00 02` plus CRC.
4. The downstream RTU server responds with function `03`, byte count `4`, and two register values.
5. The gateway removes the serial CRC, wraps the response PDU in a Modbus TCP ADU, and returns it with the matching Transaction Identifier and Unit Identifier.

If the response contains plausible bytes but the engineering value is wrong, stay in the data-representation layer: address base, register order, signedness, scale, unit, word order, or freshness may be the issue. Do not blame the gateway path until route and response evidence says so.

## Common Pitfalls

- Treating the Unit Identifier as irrelevant when it actually selects the downstream serial server.
- Treating Unit Identifier routing as universal when the gateway uses a mapping table.
- Selecting RTU-over-TCP in a client when the gateway expects true Modbus TCP.
- Looking for an RTU CRC inside the true Modbus TCP payload.
- Misreading exception `0B` as the same thing as upstream client timeout.
- Assuming a successful Modbus response proves the value is fresh when a cache or agent mode may be involved.
- Polling multiple upstream clients as if one gateway creates unlimited serial bandwidth.
- Reading across reserved map gaps and treating exception `02` as a gateway failure.
- Using one timeout value for every downstream path without checking serial speed, retries, and response time.

## Instructor Flow

1. Start with the Module 12 MBAP packet and ask what the Unit Identifier might mean in a gateway path.
2. Draw the same PDU inside two envelopes: MBAP on the TCP side and address/CRC on the RTU side.
3. Compare transparent routing, mapped routing, and cached or agent-style behavior.
4. Classify `0A`, `0B`, `02`, client timeout, stale value, and wrong mode using evidence cards.
5. Keep product-specific settings gated until a selected gateway manual or emulator path is reviewed.

## Check-Your-Understanding

1. A client receives Modbus exception `0B` from a gateway. What evidence does that provide that a client-side timeout does not?
2. Why is Unit Identifier `7` not enough by itself to prove the gateway used downstream serial server address `7`?
3. What is the difference between true Modbus TCP and RTU-over-TCP at the gateway boundary?
4. Why might a syntactically valid Modbus response still contain stale data?
5. What source should govern numeric timeout defaults for a real gateway integration?

## Source Notes

- Official TCP basis: Modbus Messaging on TCP/IP Implementation Guide V1.0b for MBAP header fields, Unit Identifier context, and Modbus TCP ADU structure.
- Official protocol basis: Modbus Application Protocol Specification V1.1b3 for function code `03`, exception-response shape, and exception codes including `0A` and `0B`.
- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for MBAP header fields, Unit Identifier and gateway routing, TCP connection behavior and concurrency, IANA service name `mbap` on port `502`, RTU/ASCII frame fields where gateway paths bridge to serial, normal response vs exception response, and exception codes and exception response PDU shape.
- Internal course basis: `course-phase-drafts/phase-4-integration-troubleshooting-real-systems.md`, `modbus-wiki.md`, and `gateway-source-notes.md`.
- Vendor-specific basis: transparent routing, mapped routing, cache/freshness behavior, timeout defaults, retry settings, broadcast handling, and concurrent-client limits require a selected gateway manual or verified emulator before release.
- Synthetic source: the worked example and gateway routing cards are course-authored fixtures, not captured traffic from a real gateway.

## Completion Checkpoint

Before moving on, learners should trace one request from TCP client, through gateway route decision, to downstream target, then classify which parts are official Modbus evidence and which parts require selected gateway evidence.

## Reusable Assets

- [Gateway routing lab](https://learnmodbus.studioseventeen.io/lesson/gateways-mixed-networks?page=lab-1)
- [Gateway routing checklist](https://learnmodbus.studioseventeen.io/resource/gateway-routing-checklist)
- [Gateway Evidence Appendix](https://learnmodbus.studioseventeen.io/resource/gateway-evidence-appendix)
- [Module 13 quiz](https://learnmodbus.studioseventeen.io/lesson/gateways-mixed-networks?page=quiz)
- [Modbus TCP packet inspection worksheet](https://learnmodbus.studioseventeen.io/resource/modbus-tcp-packet-inspection-worksheet)

## Diagram source

```mermaid
flowchart LR
  SC["SCADA<br/>(TCP client)"] -- "TCP : Unit 5" --> G["Gateway"]
  G -- "RTU : Addr 5" --> D1["Drive"]
  G -- "RTU : Addr 12" --> D2["Meter"]
```

## Labs

### Lab 1

# Lab 15: Gateway Routing Without Hardware
## Learner Outcome

Learners can trace a Modbus TCP request through a synthetic TCP-to-RTU gateway path, identify route evidence, distinguish transparent and mapped behavior, and classify gateway-related failures before changing register addresses or data types.

## Prerequisites

- Module 5: documented address versus PDU address.
- Module 11: RTU frame structure and serial server address.
- Module 12: Modbus TCP MBAP fields and Unit Identifier.
- Module 13 lesson through gateway exceptions and routing patterns.

## Safety And Scope

This is a no-hardware and no-network lab. It uses course-authored routing cards, not a live gateway. Do not scan networks or connect to production devices. Later emulator or real-gateway extensions must use an isolated lab network, named gateway documentation, expected outputs, and the [Gateway Evidence Appendix](https://learnmodbus.studioseventeen.io/resource/gateway-evidence-appendix).

## Scenario

A client is configured to read holding register `40021` through a TCP-to-RTU gateway. The learner receives saved upstream bytes, route notes, and observed outcomes. The task is to classify each attempt and name the next evidence-producing check.

Base request:

| Field | Value |
|---|---|
| Transport to gateway | Modbus TCP |
| Downstream transport | Modbus RTU over RS-485 |
| Gateway IP | `192.0.2.50` documentation example address |
| TCP port | `502` |
| Function code | `03` Read Holding Registers |
| Documented register | `40021` |
| Actual PDU address | `0x0014` |
| Quantity | `2` registers |
| Data type | 32-bit signed integer |
| Scale/unit | `0.1 deg C` |

## Gateway Routing Cards

| Card | Upstream Request PDU Context | Route Evidence | Observed Result | Question |
|---|---|---|---|---|
| A | Unit Identifier `7`, PDU `03 00 14 00 02` | Transparent route note says Unit ID `7` maps to downstream serial server `7`; simulated downstream request is `07 03 00 14 00 02` plus CRC. | Normal TCP response with function `03`, byte count `4`, two registers. | What proves this was a successful gateway path? |
| B | Unit Identifier `8`, same PDU | Transparent route note says Unit ID `8` maps to downstream serial server `8`; downstream target is offline in the fixture. | Modbus TCP exception response with function `83`, exception `0B`. | Why is this not the same as a client timeout? |
| C | Unit Identifier `7`, same PDU | No gateway response bytes are observed before the client deadline. | Client-side timeout. | What evidence is missing compared with Card B? |
| D | Unit Identifier `7`, PDU `03 00 2F 00 08` | Gateway routes to downstream server `7`; selected range crosses a synthetic reserved gap. | Exception response with function `83`, exception `02`. | Why is this not automatically a gateway-path problem? |
| E | Unit Identifier `3`, PDU `03 00 14 00 02` | Gateway mapping table says TCP Unit ID `3` and address range `0x0014-0x0015` route to downstream server `7`. | Normal TCP response with mapped-route note. | Why would transparent Unit ID assumptions be wrong here? |
| F | Unit Identifier `7`, same PDU | Gateway cache note says value may be served from stored data when downstream polling is stale. | Normal TCP response plus stale-quality note in the scenario. | Why is this a freshness problem rather than a packet syntax problem? |
| G | Client sends `07 03 00 14 00 02` plus RTU CRC over TCP. | Gateway expects true Modbus TCP with MBAP, not RTU-over-TCP. | No valid Modbus TCP response in the fixture. | Which client mode should be checked first? |
| H | Unit Identifier `7`, same PDU | Gateway downstream attempt is still in progress when the upstream client timeout expires. | Client timeout in first run; normal or `0B` response after timeout alignment is corrected in the scenario. | What settings must be compared before choosing a numeric timeout? |
| I | Unit Identifier `9`, same PDU | Gateway route note says no path is available for Unit ID `9` in the fixture. | Modbus TCP exception response with function `83`, exception `0A`. | What route/path evidence should be checked before changing the register map? |

## Procedure

1. For each card, identify the upstream transport, Unit Identifier, function code, documented register, PDU address, and quantity.
2. Decide whether the route looks transparent, mapped, cached/agent-style, wrong-mode, or unresolved.
3. Classify the observed result as normal response, exception `0A`, exception `0B`, exception `02`, client-side timeout, stale-value risk, or wrong mode.
4. Write the next evidence-producing check, such as route table, downstream serial capture, gateway log, timeout chain, cache/freshness setting, or client mode.
5. Record what not to change yet.

## Worksheet

| Card | Route Pattern | Diagnostic Bucket | Evidence Used | Next Check | What Not To Change Yet |
|---|---|---|---|---|---|
| A |  |  |  |  |  |
| B |  |  |  |  |  |
| C |  |  |  |  |  |
| D |  |  |  |  |  |
| E |  |  |  |  |  |
| F |  |  |  |  |  |
| G |  |  |  |  |  |
| H |  |  |  |  |  |
| I |  |  |  |  |  |

## Answer Key

| Card | Route Pattern | Diagnostic Bucket | Evidence Used | Next Check | What Not To Change Yet |
|---|---|---|---|---|---|
| A | Transparent routing fixture | Normal response | Unit ID `7`, route note, downstream request to server `7`, normal response | Confirm response Transaction ID and Unit ID; decode value using map | scale, word order, timeout |
| B | Transparent routing fixture | Gateway exception `0B` | Valid TCP exception response from gateway | Check downstream device power/address/serial settings and gateway log | upstream TCP reachability; it responded |
| C | Unresolved path | Client-side timeout | No valid response bytes before client deadline | Check gateway reachability, firewall, client timeout, gateway queue, and route | exception-code interpretation; no exception was received |
| D | Transparent route with invalid range | Exception `02` | Gateway routed, downstream or mapped target rejected address/range | Check register-map gap, address base, quantity, and read grouping | gateway reachability and RTU-over-TCP mode |
| E | Mapped routing fixture | Normal mapped response | Mapping table overrides direct Unit ID assumption | Inspect configured route table and document mapping evidence | assuming Unit ID equals downstream server address |
| F | Cached or agent-style fixture | Stale-value risk | Normal response plus scenario freshness note | Check timestamp, quality, cache age, and downstream live comparison | packet syntax and CRC; response can be syntactically valid |
| G | Wrong mode | RTU-over-TCP versus true Modbus TCP mismatch | RTU-style bytes instead of MBAP header | Select true Modbus TCP mode or verify gateway manual for RTU-over-TCP support | PDU address, scale, word order |
| H | Timeout-chain mismatch | Client timeout before gateway completes downstream attempt | Scenario says gateway attempt outlasts upstream client timeout | Compare client timeout, gateway serial timeout, retries, serial speed, and downstream response time | inventing a generic numeric timeout |
| I | Unavailable gateway path fixture | Gateway exception `0A` | Valid TCP exception response from gateway | Check gateway route availability, path configuration, route table, and product diagnostics | register address, scale, word order |

## Expected Observations

- Unit Identifier can be route evidence, but gateway configuration decides whether it maps directly to a downstream serial address.
- Exception `0B` means the gateway produced a valid Modbus exception response about the downstream target.
- Exception `0A` means the gateway reported path availability evidence, not a decoded-value problem.
- A client timeout means the client saw no valid response before its deadline.
- Exception `02` can indicate an address/range problem even through a gateway.
- A normal response may still require freshness checks when caching or agent behavior is in play.
- Wrong TCP mode should be fixed before register-map or data-type troubleshooting.

## Troubleshooting Notes

- Keep `Unit Identifier`, downstream serial server address, and legacy `slave ID` labels separate in notes.
- Treat mapping tables, cache behavior, retry counts, timeout defaults, and concurrent-client limits as selected-gateway facts, not generic Modbus facts.
- Do not assign numeric timing values until the gateway manual, downstream device manual, and lab configuration are known.
- If a later emulator is selected, preserve these cards as pre-lab reasoning before live testing.

## Check Questions

1. Which card proves the difference between exception `0B` and a client timeout?
2. Which card shows why Unit Identifier does not always equal downstream serial server address?
3. Which card is a true Modbus TCP versus RTU-over-TCP mode problem?
4. Which card should send you to freshness or quality evidence instead of packet syntax?
5. Which card should send you to address range and read grouping evidence?
6. Which card should send you to route/path availability evidence?

## Instructor Notes

- Ask learners to draw Card A as two wrappers around the same PDU: MBAP on the TCP side and address/CRC on the RTU side.
- Use Card E to prevent over-learning the transparent routing shortcut.
- Use Cards B and C side by side to separate valid exception response from silence.
- Use Card H to reinforce timeout chains without teaching made-up default values.

## Source Notes

- Official TCP source: Modbus Messaging on TCP/IP Implementation Guide V1.0b for MBAP fields and Modbus TCP ADU structure.
- Official protocol source: Modbus Application Protocol Specification V1.1b3 for function `03`, exception response shape, exception `02`, exception `0A`, and exception `0B`.
- Internal course source: `gateway-source-notes.md` for candidate gateway behaviors and verification gates.
- Synthetic source: all cards are course-authored fixtures, not captured gateway traffic.
- Release gate: product-specific behavior requires a selected gateway manual or verified emulator plus the [Gateway Evidence Appendix](https://learnmodbus.studioseventeen.io/resource/gateway-evidence-appendix) before this lab becomes learner-release-ready.

## Knowledge check

# Module 13 Quiz: Gateways And Mixed Networks
## Questions

1. A Modbus TCP client sends Unit Identifier `7` to a TCP-to-RTU gateway. Which statement is safest?
   A. Unit Identifier `7` always proves the downstream RTU server address is `7`.
   B. Unit Identifier `7` may be route evidence, but the gateway manual or route table must confirm how it is used.
   C. Unit Identifier is only a documentation prefix like `40001`.
   D. Unit Identifier is ignored by all gateways.

2. A client receives a valid Modbus TCP exception response with exception code `0B`. What does that prove?
   A. The upstream client received no response at all.
   B. The gateway reported that the downstream target failed to respond.
   C. The client selected RTU-over-TCP.
   D. The register value was decoded with the wrong word order.

3. Which byte pattern best indicates RTU-style bytes rather than true Modbus TCP?
   A. `00 2A 00 00 00 06 07 03 00 14 00 02`
   B. `00 2A 00 00 00 03 07 83 0B`
   C. `07 03 00 14 00 02` followed by an RTU CRC
   D. `00 2A 00 00 00 05 07 03 02 00 FA`

4. A gateway mapping table says TCP Unit ID `3` and address range `0x0014-0x0015` route to downstream serial server `7`. What should the learner document?
   A. Unit ID `3` is invalid because it does not match server `7`.
   B. The gateway uses mapped routing for this request, so direct Unit ID-to-server assumptions do not apply.
   C. The PDU address must be changed to `0x0003`.
   D. The response is stale by definition.

5. A gateway returns a normal Modbus response, but the route note says the gateway may answer from a cache when downstream polling is stale. What is the next best check?
   A. RTU CRC in the TCP payload.
   B. MBAP Length only.
   C. Freshness, timestamp, quality, cache age, or direct downstream comparison.
   D. Change the documented register from `40021` to `40022`.

6. Which timeout principle is correct for a gateway path?
   A. The upstream client timeout should be selected from a universal Modbus default.
   B. The upstream client timeout should allow the gateway downstream timeout, serial transmission, turnaround, retries, and response path.
   C. TCP clients never need timeout settings.
   D. Gateway timeout settings are official Modbus protocol constants.

7. A request through a gateway receives exception `02` after reading a range that crosses a reserved register gap. Which interpretation is most likely?
   A. The gateway is unreachable.
   B. The read range or address is invalid for the downstream or mapped target.
   C. The response is necessarily stale.
   D. The client must switch to RTU-over-TCP.

8. Which source should govern product-specific cache behavior for a real gateway integration?
   A. A generic Modbus addressing cheat sheet.
   B. The selected gateway manual or verified emulator/lab evidence.
   C. The existence of TCP port `502`.
   D. The fact that Modbus registers are 16 bits.

9. A gateway returns exception code `0A` for a request to Unit Identifier `9`. Which next check best matches the evidence?
   A. Check the route/path availability, route table, gateway diagnostics, or product-specific path configuration.
   B. Change the 32-bit word order.
   C. Add an RTU CRC to the Modbus TCP payload.
   D. Treat it as proof that the downstream target responded with bad data.

## Answer Key

1. B. Unit Identifier is route evidence in many gateway paths, but exact handling is product-specific.
2. B. Exception `0B` is a valid gateway exception response about downstream target response failure; it is not client-side silence.
3. C. RTU-style bytes use serial address/function/data plus CRC, not an MBAP header.
4. B. The mapping table is the governing evidence for that gateway route.
5. C. A syntactically valid response can still be stale if the gateway or agent caches data.
6. B. Timeout alignment is a chain; numeric values must come from selected source and lab evidence.
7. B. Exception `02` points to illegal data address/range evidence, not automatically gateway reachability.
8. B. Cache behavior is implementation-specific and must be tied to a named gateway/manual or verified lab setup.
9. A. Exception `0A` is gateway path unavailable evidence, so routing/path configuration comes before value decoding.

## Distractor Review Notes

| Question | Correct | Why The Distractors Are Wrong |
|---:|---|---|
| 1 | B | A overgeneralizes gateway behavior, C confuses Unit Identifier with address notation, and D denies common gateway routing use. |
| 2 | B | A contradicts the valid exception response, C guesses a different transport mode, and D jumps to value interpretation. |
| 3 | C | A/B/D include MBAP-style TCP framing; C shows serial address/function/data plus an RTU CRC. |
| 4 | B | A assumes direct Unit ID mapping, C changes the data address without evidence, and D invents staleness. |
| 5 | C | A adds RTU CRC to TCP, B checks only syntax, and D changes the address before proving freshness. |
| 6 | B | A/D invent universal timeout constants, and C denies that TCP clients still need practical timeout handling. |
| 7 | B | A would fit path failure evidence, C invents cache behavior, and D changes mode despite an address/range exception. |
| 8 | B | A/C/D are generic facts that do not define a selected gateway's cache behavior. |
| 9 | A | B decodes a value before route evidence, C mixes serial CRC into TCP, and D misreads gateway path-unavailable evidence as downstream data. |

## Instructor Notes

- Use questions 1 and 4 together to prevent learners from overgeneralizing transparent Unit Identifier routing.
- Use questions 2 and 6 to separate exception evidence from timeout evidence.
- Use question 5 to connect gateway work to Module 8 quality and freshness concepts.
- Add a product-manual scenario after a gateway source pack is selected.

## Source Notes

- Official citation targets: [official-citation-map.md](https://learnmodbus.studioseventeen.io/resource/official-citation-map) rows for MBAP header fields, Unit Identifier and gateway routing, TCP connection behavior and concurrency, RTU/ASCII frame fields where RTU-style bytes are contrasted with true TCP, normal response vs exception response, and exception codes and exception response PDU shape.
- Route tables, caching, timeout defaults, retries, broadcast handling, and concurrent-client limits remain gateway product behavior until a manual or emulator source pack is selected.

---
_Learn Modbus · learnmodbus.studioseventeen.io · Module 13/16 · v1.0.0 · Exported for offline / agent use._