A gateway is not a larger sensor node with an Ethernet jack glued to the side. It is the place where many weak, slow, noisy or sleepy device conversations are turned into traffic a wired network can tolerate. That makes the copper connector, the magnetics, the switch, the PHY, the packet buffer, the isolation boundary and the power entry part of the same design problem.

The wireless side may forgive delay, retries and sleeping nodes. The wired side expects link state, frames, timing and fault behavior to look disciplined. A gateway that aggregates data has to translate between those two cultures without letting one damage the other. If it only forwards bytes, it is a cable adapter. If it owns buffering, timing, segmentation and fault reporting, it becomes infrastructure.

The gateway sits at a boundary, not in the middle

Where a gateway sits in an IoT network is the first choice because it decides what the box must remember. A leaf node can lose a reading and try again. A gateway may be responsible for preserving the reading, stamping time onto it, filtering duplicates, compressing chatter, translating a field protocol into IP traffic, and telling the upstream system which device failed rather than only saying the link went quiet. That is a different role from a node that only samples one sensor and reports when asked.

The boundary can sit near the machines, near the cloud edge, inside a cabinet, or at the edge of a building network. Each location changes the electronics. Near machines, the gateway sees electrical noise, ground differences, cable abuse and maintenance wiring. Near IT equipment, it sees network policy, port security, IP addressing and update discipline. In a remote cabinet, it may need to store data for hours before the uplink returns. On a building network, it may need to behave like a sober Ethernet device among switches that do not care why a sensor is chatty. Placement is an electrical decision and an operational decision at once.

The gateway also decides which failures remain local. If one radio sensor floods the network, does the gateway drop that device, slow the whole subnet, or keep pushing frames upstream? If a wired port goes down, does it restart the PHY, log the port, or reboot the product? If the upstream cable is unplugged, does it keep collecting field data and report a gap later? These policies require hardware support: memory, stable time, link status pins, reset control, watchdogs and enough power integrity that a network event does not become a processor reset.

The first rule is to choose what the gateway owns.

The switch is where local traffic stops becoming processor work

KSZ8995MAI as the Ethernet switch in a gateway is useful when the gateway has more than one wired port and should not ask the main processor to touch every frame. A switch learns MAC addresses, forwards local traffic, handles link state per port and keeps packet movement in hardware. In a small industrial or building gateway, that can turn a board from one uplink plus one service port into a small local network node. The processor still configures, monitors and manages policy, but raw frame movement no longer consumes its attention.

The design work around a switch begins at the ports. Each RJ45 path needs magnetics, common-mode behavior, ESD protection, pair routing, LED handling and a mechanical opening that will survive real cable use. The differential pairs are short enough on many gateway boards that they look forgiving, then fail when a connector, common-mode choke or magnetics footprint disturbs impedance. The switch package may be digital, but the port edge is analog radio-frequency work carried through twisted pair.

Switches also make product behavior visible. Link LEDs, port counters, link-up timing and per-port reset behavior can turn a service call from guessing into diagnosis. A gateway that tells which port lost link is easier to support than one that reports only network unavailable. That support value has to be designed into the board. If LED pins are not routed, if link status is not available to firmware, or if all ports share one reset line with no order, the hardware has already decided how little the product can explain later.

There is a security and policy angle too. A gateway with several copper ports may become the unplanned bridge between a field network and a building network. Even when the silicon can forward everything, the product may need to block some traffic, separate service access, or keep field chatter from leaking into the uplink. That decision belongs to firmware and system policy, but hardware must give it enough hooks: management interface, reset control, clocking, nonvolatile settings and a processor that can observe the switch rather than only power it.

A switch makes the gateway feel like infrastructure, not a dongle.

PHYs and packet engines decide how much the MCU has to know

LAN8710A-EZC-TR bringing wired connectivity to a node points to the classic Ethernet PHY path. The PHY handles the electrical line, link negotiation and physical coding, while the MAC lives in the microcontroller or processor. That is a clean architecture when the host already has an Ethernet MAC and enough pins for the interface. The PHY is then the analog front end of the network port: magnetics, crystal or clocking, strap pins, reset, link LEDs, differential pairs and isolation choices set whether the cable behaves like a link or a noise antenna.

W5500 adding a hardware TCP IP stack to an MCU is a different bargain. A small MCU without a full network stack can speak SPI to a chip that owns Ethernet MAC, PHY-facing behavior and TCP/IP sockets in hardware. That can reduce firmware size and time-to-link for a small device that needs a few connections rather than a full Linux network stack. It also moves limits into the chip: socket count, buffer size, protocol behavior, throughput, driver model and how errors are reported. The MCU does not escape networking. It trades one kind of networking work for another. The board still needs a clear interrupt path, chip select timing, reset order, socket recovery rule and enough buffer discipline that a slow upstream server does not block sensor collection behind it.

ENC28J60 for low cost Ethernet access sits in the older low-cost corner, where SPI access to Ethernet was enough to add a network port to simple controllers. It can still make sense when throughput is modest and firmware already knows the part. The danger is assuming the low-cost chip carries the whole system cost. Firmware stack work, CPU load, packet buffering, interrupt behavior, power draw, magnetics, protection and test time still count. A cheap Ethernet controller can be a fine answer for a constrained job, or a way to spend engineering time that a different silicon choice would have saved.

Industrial PHY work is about link behavior under abuse

DP83848 as an Ethernet PHY for industrial gear is less about putting Ethernet on a schematic and more about keeping the link believable in a cabinet or machine. The PHY has to manage cable length, transformer behavior, link pulses, auto-negotiation, clock quality, ESD events and common-mode noise while the processor expects a clean digital interface. A poor layout can make a good PHY look unstable. A poor clock can make a stable schematic fail emissions or link margin. A poor reset sequence can turn power-up into a lottery.

The PHY is also where the gateway can learn about the physical network. Link up, link down, speed, duplex, remote fault and interrupt behavior are not decorative status bits. They decide whether the gateway can tell the difference between a remote device powered down, a cable unplugged, a bad negotiation and an upstream switch rebooting. Wired networks feel solid because they expose physical state. The product should use that state instead of treating Ethernet as a black socket.

PoE turns the network cable into part of the power design

TPS23753 for the powered device side of PoE brings the power story into the network story. Power over Ethernet lets a gateway or node receive power through the same cable that carries data, which can simplify installation in ceilings, cabinets and distributed sensor points. It also means the front end must identify as a powered device, survive detection and classification, manage inrush, isolate the power path, convert the incoming voltage and keep the data path quiet while power is being negotiated.

PoE changes mechanical and service assumptions. The installer may see one cable and expect the box to wake. The network switch may budget power per port. A long cable may drop voltage. A field device may brown out when an auxiliary load turns on. If the gateway has downstream ports, the design must be clear about whether it only receives PoE, passes power, or powers other loads from a local rail. Those are not small wording differences. They change magnetics choice, isolation, thermal design, protection, connector labeling and field support.

PoE also creates a timing interaction between link and power. A device may have power before link, link before application readiness, or a power classification that succeeds while firmware is still booting. The system should avoid telling the network it is ready before the data path can store and forward. A powered gateway is useful because one cable can bring both energy and communication, but that cable then becomes both a network fault path and a power fault path. Treating those two paths as one design keeps surprises out of the service log.

A gateway earns trust by shaping traffic before it leaves

The wired connector may be the visible sign of a gateway, but the job is not finished at the jack. The gateway has to collect data from field devices, keep enough context to survive dropouts, choose which traffic deserves the uplink, and tell the rest of the system what happened when the link changed. That requires a switch when local ports should move frames without processor work, a PHY when the host owns the MAC, a hardware TCP/IP engine when a small MCU needs a narrower network job, a low-cost controller only when its firmware cost is honest, and PoE only when power entry is designed as carefully as data entry. Good aggregation is a timing and fault-behavior problem before it is a bandwidth problem. When the board respects the connector, the magnetics, the packet path, the power path and the service story together, the gateway stops being a box on a cable and becomes a dependable edge of the network.