Wiznet makers

요약

nRF9160 LTE SoC와 SPI 접속 유선 LAN 모듈을 결합해 LTE-Ethernet 게이트웨이를 구현한 프로젝트입니다. W5500은 SPI 이더넷 모듈 선택지 중 하나로 사용되었으며, Zephyr 내장 디바이스 드라이버를 통해 동작합니다. 벤더 라이브러리를 직접 이식하는 방식 대비 안정성이 크게 향상되었고, Config 변경만으로 LAN 모듈을 교체할 수 있다는 점이 주목할 만합니다.

개요

LTE 모뎀을 내장한 단말은 무선 연결에는 강하지만, 유선 LAN 장비와 직접 연결할 수단이 없습니다. 이 프로젝트는 셀룰러망과 유선 Ethernet을 잇는 게이트웨이를 만들어 이 간극을 메웁니다.

기존에 SPI 유선 LAN 모듈을 임베디드에서 다룰 때는 벤더 라이브러리를 이식해 SPI를 직접 제어하는 방식이 흔했습니다. 이 경우 구현 복잡도와 안정성이 문제였습니다. 저자는 대신 Zephyr RTOS가 제공하는 표준 이더넷 디바이스 드라이버를 사용해, 더 간단하고 안정적인 구현을 달성했습니다.

대상 독자는 Zephyr / nRF Connect SDK 기반 임베디드 개발자와 LTE IoT 게이트웨이 제작자입니다.

→ 원문: https://qiita.com/Akihiro-Sakaniwa/items/4fc751ce5c827958ed06

시스템 아키텍처

게이트웨이는 LTE 측에서 받은 패킷을 유선 LAN 측으로, 그 반대로도 포워딩합니다. 핵심은 RAW 패킷 소켓(AF_PACKET, SOCK_RAW)을 통한 L2 프레임 전달입니다.

• 수신 경로: LAN 측 프레임을 net_context_recv 콜백으로 수신 → LTE 측으로 전달
• 송신 경로: LTE 측 RAW 소켓에서 수신 → ARP로 목적지 MAC 해석 → Ethernet 프레임 구성 → net_context_sendto로 LAN 측 송신
• 스레드 분리: 송신·수신을 각각 eth_tx_thread, eth_rx_thread로 분리해 양방향 처리

기술 특징

이 프로젝트의 가장 큰 설계적 미덕은 하드웨어 추상화입니다.

• Config 기반 모듈 교체: prj.conf의 CONFIG_ETH_<칩명>과 overlay.dts의 compatible 값만 바꾸면, 소스 코드 수정 없이 LAN 모듈을 교체할 수 있습니다.
• MAC 주소 처리 차이: W5500과 ENC28J60은 MAC 주소를 내장하지 않아 local-mac-address 지정이 필요합니다. 반면 ENC424J600·ENC624J600은 내장하고 있어 불필요합니다.
• 네트워크 스택: CONFIG_NET_NATIVE=y로 Zephyr 네이티브 IP 스택을 사용하며, IPv4 / ARP / UDP / TCP를 활성화합니다.
• RAW 패킷 처리: 라우터 동작을 위해 CONFIG_NET_SOCKETS_PACKET을 켜고, sockaddr_ll 구조체로 L2 프레임을 직접 송신합니다.

저자는 드라이버의 안정성을 특히 강조합니다. **"W5500이 별개의 칩처럼 느껴질 만큼 안정적이었다"**는 표현으로, Zephyr 드라이버 사용이 SPI 직접 제어 대비 신뢰성을 크게 끌어올렸음을 전합니다.

Zephyr 드라이버로 W5500을 다루는 법

이 섹션은 W5500이 이 프로젝트에서 어떤 역할을 하는지 정확히 짚는 것이 목적입니다.

실제 사용 구조

• W5500은 Zephyr의 wiznet,w5500 디바이스 드라이버를 통해 구동됩니다.
• 이 경로에서 W5500은 MAC + PHY(L2 Ethernet) 계층 역할을 수행합니다.
• TCP/IP 처리는 Zephyr 네이티브 IP 스택이 담당합니다(CONFIG_NET_NATIVE).

여기서 한 가지를 분명히 해야 합니다. 이 프로젝트는 W5500의 하드와이어드 TCP/IP 엔진을 사용하지 않습니다. Zephyr 드라이버 경로에서 W5500은 L2 프레임 송수신만 담당하며 [추정] (Zephyr w5500 드라이버는 MACRAW 모드로 동작), 상위 TCP/IP는 MCU 측 소프트웨어 스택이 처리합니다. 따라서 이 사례를 "하드웨어 TCP/IP 오프로딩"으로 설명하면 부정확합니다.

LTE SoC인 nRF9160은 유선 LAN 인터페이스를 갖고 있지 않습니다. 따라서 W5500 같은 SPI 이더넷 컨트롤러는 게이트웨이의 유선 측을 구성하는 필수 부품이 됩니다. 본 프로젝트는 그 역할을 안정적으로 수행하는 표준 드라이버 레퍼런스로서 의미가 있습니다.

오프로딩이 가치가 되는 확장 시나리오 [추정]

• 기존 구조: MCU가 Zephyr 소프트웨어 IP 스택을 직접 구동 → MCU 연산·메모리 부담 존재
• WIZnet 적용 구조: 하드와이어드 TCP/IP 스택을 내장한 W5100S / W6100을 오프로딩 모드로 사용 → SPI 인터페이스로 네트워크 처리 분리
• 기대 효과: 저사양 MCU 게이트웨이에서 MCU 부하·코드 복잡도 감소, 네트워크 안정성 향상

다만 본 프로젝트의 목표(범용 드라이버 기반 모듈 교체)와는 결이 다르므로, 어디까지나 별도 요건이 있을 때의 선택지입니다.

시장과 활용처: 셀룰러-이더넷 브리지의 수요

이 게이트웨이가 어떤 시장에 닿아 있는지 살펴봅니다.

흥미로운 흐름이 있습니다. 순수 셀룰러 단말은 게이트웨이 없이 클라우드에 직결되는 방향으로 진화하고 있습니다. IP 상호운용성 덕분에 별도 라우터·게이트웨이 없이 양방향 연결이 가능하기 때문입니다. 그렇다면 셀룰러-이더넷 게이트웨이의 진짜 가치는 "이미 깔려 있는 유선 인프라 자산을 셀룰러망에 편입"하는 브리지 수요에 있습니다.

동일 카테고리의 상용 제품

• MultiConnect eCell — 셀룰러-이더넷 브리지. 자판기·키오스크·사이니지·ATM 같은 고정 자산의 무선 페일오버
• ProSoft ICX35-HWC — PAC/PLC·RTU·계측기에 4G LTE 이더넷·시리얼 연결
• AirLink RV50X — SCADA·원격 모니터링용 산업 셀룰러 게이트웨이

적용 시나리오

• 산업 원격 모니터링 / SCADA: 변전소·상수도 펌프장·가스 압축기 등 다운되어선 안 되는 인프라의 원격 데이터 수집
• 셀룰러 페일오버: 유선 회선 장애 시 백업 회선으로 동작
• 분산·원격 사이트 연결: 유선 배선이 불가능한 위치의 장비 연결
• 고정 자산 연결: 키오스크·사이니지·POS 등

시장 규모 (출처 기반)

→ 셀룰러 IoT 시장: https://www.mordorintelligence.com/industry-reports/cellular-iot-market → LTE IoT 시장: https://www.mordorintelligence.com/industry-reports/lte-iot-market

nRF9160은 LTE-M / NB-IoT 영역의 저전력 SoC입니다. 이 시장이 본 아키텍처의 적정 포지셔닝을 알려줍니다. 고대역폭 SCADA 라우터보다는 저전력 필드 게이트웨이나 소형 셀룰러 백업 브리지가 자연스러운 적용처입니다. 단가 압력이 큰 이 영역에서 저비용·소형 SPI 이더넷 컨트롤러의 BOM 경쟁력이 W5500 채택의 실질적 근거가 됩니다.

한계 및 개선 방향

원 프로젝트는 "Zephyr 표준 드라이버로 안정적인 게이트웨이를 만든다"는 목표를 충실히 달성했습니다. 그 기여를 전제로, 발전 방향을 정리합니다.

현재 한계

• W5500 하드웨어 TCP/IP 미활용: MCU가 소프트웨어 IP 스택을 직접 구동해 연산·메모리 부담이 존재
• HEAP 관리 리스크: 수신 콜백에서 net_pkt / net_buf를 해제하지 않으면 HEAP 고갈로 수신 불능 (저자 명시)
• 스루풋 한계 [추정]: 소프트웨어 스레드 기반 RAW 포워딩은 고대역폭 트래픽에서 지연·처리량 제약 가능
• 단일 인터페이스 구조: 다중 인터페이스·QoS·VPN·페일오버는 미구현

개선 방향

• 저사양 MCU 게이트웨이로 확장 시, W5100S / W6100의 하드와이어드 TCP/IP 오프로딩 활용 검토
• 수신 버퍼·스레드 수명주기 관리 보강으로 장기 가동 안정성 확보
• 듀얼 SIM 페일오버·VPN 등 상용 게이트웨이 수준의 기능 점진적 추가

FAQ

Q1. Zephyr 드라이버로 W5500을 붙이는 게 어렵나요? overlay.dts에 compatible = "wiznet,w5500"을 지정하고 prj.conf에서 CONFIG_ETH_W5500=y를 켜면 됩니다. 소스 코드 변경 없이 Config만으로 적용됩니다.

Q2. W5500과 ENC 계열 중 무엇을 선택해야 하나요? 부품 수급·단가·MAC 내장 여부가 기준입니다. W5500과 ENC28J60은 MAC 미내장이라 local-mac-address 설정이 필요하고, ENC424/624J600은 내장합니다. 본 구조에서는 Config 교체만으로 전환 가능합니다.

Q3. 이 게이트웨이는 어떤 용도에 적합한가요? 저전력·저~중대역폭의 필드 장비 연결, 셀룰러 백업 회선, 원격 사이트의 유선 장비 편입에 적합합니다. 고대역폭 영상 전송 등에는 상용 5G 게이트웨이가 더 적합합니다.

Q4. 하드웨어 TCP/IP 오프로딩이 필요하면 어떻게 하나요? MCU 부하를 줄여야 하는 저사양 게이트웨이라면, 하드와이어드 TCP/IP 스택을 내장한 W5100S / W6100을 오프로딩 모드로 사용하는 구조를 검토할 수 있습니다. [추정]

Q5. 안정성은 실제로 어떤가요? 저자는 벤더 라이브러리 직접 이식 대비 Zephyr 드라이버 사용이 훨씬 안정적이었다고 평가합니다. "W5500이 별개의 칩처럼 느껴질 정도"라는 표현으로 신뢰성 향상을 강조합니다.

Summary

This project builds an LTE-to-Ethernet gateway by combining the nRF9160 LTE SoC with an SPI-connected wired LAN module. The W5500 serves as one of the selectable SPI Ethernet modules and runs through Zephyr's built-in device driver. Compared to porting a vendor library directly, this approach delivers noticeably better stability, and you can swap LAN modules with a config change alone.

Overview

A device with a built-in LTE modem connects well over the air, but it has no native way to link with wired LAN equipment. This project fills that gap by building a gateway that bridges the cellular network and wired Ethernet.

Traditionally, using an SPI wired LAN module in embedded systems meant porting a vendor library and driving SPI directly. That path carried real costs in complexity and stability. Instead, the author used the standard Ethernet device driver that Zephyr RTOS provides, achieving a simpler and more stable implementation.

The target readers are embedded developers working with Zephyr / nRF Connect SDK and builders of LTE IoT gateways.

→ Source: https://qiita.com/Akihiro-Sakaniwa/items/4fc751ce5c827958ed06

Architecture

The gateway forwards packets from the LTE side to the wired LAN side, and back again. The core mechanism is L2 frame forwarding through RAW packet sockets (AF_PACKET, SOCK_RAW).

• Receive path: A LAN-side frame arrives via the net_context_recv callback, then forwards to the LTE side.
• Transmit path: The LTE-side RAW socket receives a packet, ARP resolves the destination MAC, an Ethernet frame is built, and net_context_sendto sends it to the LAN side.
• Thread separation: Transmit and receive run on separate threads, eth_tx_thread and eth_rx_thread, for full-duplex handling.

Technical Highlights

The biggest design virtue of this project is hardware abstraction.

• Config-based module swap: Change CONFIG_ETH_<chip> in prj.conf and the compatible value in overlay.dts, and you can switch LAN modules without touching source code.
• MAC address handling: The W5500 and ENC28J60 do not embed a MAC address, so they require a local-mac-address setting. The ENC424J600 and ENC624J600 embed one, so it is unnecessary.
• Network stack: With CONFIG_NET_NATIVE=y, the project uses Zephyr's native IP stack and enables IPv4 / ARP / UDP / TCP.
• RAW packet handling: For router behavior, CONFIG_NET_SOCKETS_PACKET is enabled, and L2 frames are sent directly via the sockaddr_ll structure.

The author especially emphasizes driver stability. The phrase "the W5500 felt like a completely different chip" captures how much the Zephyr driver improved reliability over direct SPI control.

Where WIZnet Fits

This section pins down exactly what role the W5500 plays in this project.

Actual usage structure

• The W5500 runs through Zephyr's wiznet,w5500 device driver.
• On this path, the W5500 acts as the MAC + PHY (L2 Ethernet) layer.
• TCP/IP is handled by the Zephyr native IP stack (CONFIG_NET_NATIVE).

One point deserves a clear statement. This project does not use the W5500's hardwired TCP/IP engine. On the Zephyr driver path, the W5500 handles only L2 frame transmission and reception [Inferred] (the Zephyr w5500 driver operates in MACRAW mode), while the upper TCP/IP runs on the MCU-side software stack. Describing this case as "hardware TCP/IP offloading" would therefore be inaccurate.

The nRF9160, an LTE SoC, has no wired LAN interface. As a result, an SPI Ethernet controller like the W5500 becomes an essential component for the gateway's wired side. This project carries value as a standard-driver reference that performs that role reliably.

Expansion scenario where offloading adds value [Inferred]

• Existing structure: The MCU drives the Zephyr software IP stack directly, which adds compute and memory load on the MCU.
• WIZnet-applied structure: Use the W5100S / W6100, which embed a hardwired TCP/IP stack, in offload mode to separate network processing over the SPI interface.
• Expected effect: On low-spec MCU gateways, this reduces MCU load and code complexity while improving network stability.

That said, this differs in spirit from the project's goal (generic driver-based module swapping), so it is strictly an option for cases with separate requirements.

Market and Use Cases

Here we look at the market this gateway connects to.

There is an interesting trend. Pure cellular devices are evolving toward direct cloud connection without a gateway. IP interoperability enables bidirectional links without a separate router or gateway. In that light, the real value of a cellular-to-Ethernet gateway lies in bridge demand that brings existing wired infrastructure assets onto the cellular network.

Commercial products in the same category

• MultiConnect eCell — A cellular-to-Ethernet bridge. Wireless failover for fixed assets like vending machines, kiosks, signage, and ATMs.
• ProSoft ICX35-HWC — 4G LTE Ethernet and serial connectivity for PAC/PLCs, RTUs, and instruments.
• AirLink RV50X — An industrial cellular gateway for SCADA and remote monitoring.

Use case scenarios

• Industrial remote monitoring / SCADA: Remote data collection for infrastructure that cannot go down, such as substations, water pump stations, and gas compressors.
• Cellular failover: Operates as a backup link when the wired line fails.
• Distributed and remote site connectivity: Connecting equipment where wired cabling is not possible.
• Fixed asset connectivity: Kiosks, signage, POS, and similar.

Market size (source-based)

→ Cellular IoT market: https://www.mordorintelligence.com/industry-reports/cellular-iot-market → LTE IoT market: https://www.mordorintelligence.com/industry-reports/lte-iot-market

The nRF9160 is a low-power SoC in the LTE-M / NB-IoT space. This market points to the right positioning for this architecture. Rather than a high-bandwidth SCADA router, the natural fit is a low-power field gateway or a compact cellular backup bridge. In this cost-sensitive space, the BOM competitiveness of a low-cost, small SPI Ethernet controller becomes the practical case for choosing the W5500.

Limitations and Future Improvements

The original project fully achieved its goal: building a stable gateway with standard Zephyr drivers. With that contribution acknowledged, here are directions for improvement.

Current limitations

• W5500 hardware TCP/IP unused: The MCU drives the software IP stack directly, adding compute and memory load.
• HEAP management risk: If the receive callback does not free net_pkt / net_buf, the HEAP exhausts and reception stops (noted by the author).
• Throughput limit [Inferred]: Software-thread-based RAW forwarding may face latency and throughput constraints under high-bandwidth traffic.
• Single-interface structure: Multiple interfaces, QoS, VPN, and failover are not implemented.

Future improvements

• When expanding to low-spec MCU gateways, consider the hardwired TCP/IP offloading of the W5100S / W6100.
• Strengthen receive-buffer and thread lifecycle management to secure long-running stability.
• Gradually add commercial-gateway-grade features such as dual-SIM failover and VPN.

FAQ

Q1. Is it hard to attach the W5500 with the Zephyr driver? Set compatible = "wiznet,w5500" in overlay.dts and enable CONFIG_ETH_W5500=y in prj.conf. It applies through config alone, with no source code changes.

Q2. Should I choose the W5500 or an ENC-series chip? The criteria are part availability, unit cost, and whether a MAC is embedded. The W5500 and ENC28J60 lack an embedded MAC and need a local-mac-address setting, while the ENC424/624J600 embed one. In this structure, you can switch with a config change alone.

Q3. What is this gateway suited for? It fits low-power, low-to-medium-bandwidth field device connectivity, cellular backup links, and bringing remote-site wired equipment onto a network. For high-bandwidth video, a commercial 5G gateway is a better fit.

Q4. What if I need hardware TCP/IP offloading? For a low-spec gateway where you must reduce MCU load, consider a structure that uses the W5100S / W6100 with their embedded hardwired TCP/IP stack in offload mode. [Inferred]

Q5. How is the stability in practice? The author rates the Zephyr driver as far more stable than directly porting a vendor library. The phrase "the W5500 felt like a completely different chip" underscores the reliability gain.