---
title: "nRF9160とSPI有線LANモジュール(W5500,enc28j60,enc624j600)でLTE-ETHERNET-GATEWAYを作った話。"
url: "https://maker.wiznet.io/scott/projects/nrf9160spilan-w5500enc28j60enc624j600-lte-ethernet-gateway/"
markdown_url: "https://maker.wiznet.io/scott/projects/nrf9160spilan-w5500enc28j60enc624j600-lte-ethernet-gateway/md"
type: "UCC: User Created Content"
author: "Akihiro-Sakaniwa (Akihiro Sakaniwa)"
author_url: "https://qiita.com/Akihiro-Sakaniwa/items/4fc751ce5c827958ed06"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Akihiro-Sakaniwa (Akihiro Sakaniwa)"
original_url: "https://qiita.com/Akihiro-Sakaniwa/items/4fc751ce5c827958ed06"
published: "2026-06-05"
language: "en"
hardware: ["WIZnet W5500"]
likes: 0
views: 225
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# nRF9160とSPI有線LANモジュール(W5500,enc28j60,enc624j600)でLTE-ETHERNET-GATEWAYを作った話。

> Bridging Cellular to Wired LAN: An nRF9160 LTE Gateway with the W5500

Original author: Akihiro-Sakaniwa (Akihiro Sakaniwa) (source: https://qiita.com/Akihiro-Sakaniwa/items/4fc751ce5c827958ed06)

## Components

- **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/))

## Article

## 요약

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

![](https://maker.wiznet.io/upload/ckeditor5/199704292%5F1780668930%2Epng)

## 개요

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 프레임 전달입니다.

![](https://maker.wiznet.io/upload/ckeditor5/199704292%5F1780669376%2Epng)

- **수신 경로**: 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 부하·코드 복잡도 감소, 네트워크 안정성 향상

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

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

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

![](https://maker.wiznet.io/upload/ckeditor5/199704292%5F1780669929%2Epng)

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

**동일 카테고리의 상용 제품**

- **MultiConnect eCell** — 셀룰러-이더넷 브리지. 자판기·키오스크·사이니지·ATM 같은 고정 자산의 무선 페일오버

- **ProSoft ICX35-HWC** — PAC/PLC·RTU·계측기에 4G LTE 이더넷·시리얼 연결

- **AirLink RV50X** — SCADA·원격 모니터링용 산업 셀룰러 게이트웨이

**적용 시나리오**

- **산업 원격 모니터링 / SCADA**: 변전소·상수도 펌프장·가스 압축기 등 다운되어선 안 되는 인프라의 원격 데이터 수집

- **셀룰러 페일오버**: 유선 회선 장애 시 백업 회선으로 동작

- **분산·원격 사이트 연결**: 유선 배선이 불가능한 위치의 장비 연결

- **고정 자산 연결**: 키오스크·사이니지·POS 등

**시장 규모 (출처 기반)**

| 구분 | 규모/전망 | 출처 |
| --- | --- | --- |
| 셀룰러 IoT(상위 시장) | 2025년 76.3억 달러 → 2030년 216.6억 달러, CAGR 23.2% | Mordor Intelligence |
| 셀룰러 라우터·게이트웨이 | 2024~2030년 CAGR 약 10.5% | Yuzela/Research |
| LTE IoT(NB-IoT+LTE-M) | 2025년 18.3억 달러 → 2030년 41.8억 달러, CAGR 18% | Mordor Intelligence |

→ 셀룰러 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.

![](https://maker.wiznet.io/upload/ckeditor5/199704292%5F1780669954%2Epng)

## 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`).

![](https://maker.wiznet.io/upload/ckeditor5/199704292%5F1780669948%2Epng)

- **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.

![](https://maker.wiznet.io/upload/ckeditor5/199704292%5F1780669936%2Epng)

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)**

| Segment | Size / Forecast | Source |
| --- | --- | --- |
| Cellular IoT (upper market) | USD 7.63B in 2025 → USD 21.66B by 2030, CAGR 23.2% | Mordor Intelligence |
| Cellular router & gateway | CAGR of about 10.5% over 2024–2030 | Yuzela/Research |
| LTE IoT (NB-IoT + LTE-M) | USD 1.83B in 2025 → USD 4.18B by 2030, CAGR 18% | Mordor Intelligence |

→ 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.

---

---

Source: https://maker.wiznet.io/scott/projects/nrf9160spilan-w5500enc28j60enc624j600-lte-ethernet-gateway/