Home / Notes / Hospital Wi-Fi + Medical IoT WLAN Design

NOTES · WLAN / MEDICAL IoT

Hospital Wi-Fi + IoT on One Network: Medical IoT WLAN Design and Config

How to design and configure a single WLAN that safely carries both regular staff/patient Wi-Fi and medical IoT traffic — RTLS asset tags, infusion-pump monitoring and similar terminals — on the same APs: the IoT add-on card hardware approach, VLAN/isolation design, and the real Huawei AC/AP configuration behind it.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why Co-Network Hospital Wi-Fi and Medical IoT at All

Running Wi-Fi and medical IoT as two separate networks doubles the cabling, the APs and the operating headaches — sharing one network safely is the harder but better answer.

Most hospitals didn't set out to build parallel networks. It happened one department at a time: nurse call added its own gateway, infant security added its own reader network, asset tracking added its own tags and its own backend — each one solving a single department's problem without a hospital-wide plan. The result is exactly what the underlying architecture warns against: repeated infrastructure build-out, data siloed by application, radios stepping on each other in the same corridor, and a network operations team that has to learn five different systems instead of one.

The alternative is a layered design that separates concerns instead of separating networks: a terminal layer of sensing devices (infusion monitors, asset tags, mother-infant bracelets and similar), an access layer where an IoT add-on card or module on the same Wi-Fi AP picks up the non-Wi-Fi protocol those devices actually speak, a pipe layer of ordinary AP/AC/switch infrastructure that only forwards the traffic, and an application layer — the hospital's IoT middleware or a specific system like an infant-security platform — that actually consumes it. The Wi-Fi network and the medical IoT network share the same physical AP and the same switch port; what keeps them from interfering with each other is VLAN separation and configuration discipline, not a second set of cables.

Topology: One AP, Two Networks

A single AP radio pair carries the staff/patient Wi-Fi SSID; a card slot in the same AP carries the medical IoT protocol — separated by VLAN from the interface up to the application server.

Diagram labels are kept in English for engineering clarity.

Network Data Plan (this example)

Item	Value (this example)
Management VLAN — AP↔AC control traffic and the AP's IoT card↔middleware path	VLAN 100
Staff/patient Wi-Fi business VLAN	VLAN 101
AC's CAPWAP source interface	VLANIF100
DHCP service for Wi-Fi clients (STA)	AC as DHCP server, interface-based pool on VLANIF101
AP IP address	Static 10.23.100.2/24
STA (Wi-Fi client) address pool	10.23.101.2–10.23.101.254/24
Medical IoT middleware / application server	10.23.100.254, UDP port 3000 (example)

IoT Card Slot Combinations Supported per AP

Card combination	Support
PCIe network-port card (large, 2 slots) + USB network-port card	Supported
PCIe network-port card (large, 2 slots) + USB serial-port card	Supported
PCIe serial-port card ×1 + USB network-port card	Supported
PCIe serial-port card ×1 + USB serial-port card	Supported
PCIe serial-port card ×2 (small, 1 slot each)	Supported

All five combinations are supported, with conditions: only one of the two cards may be a serial-port card, the two cards' working frequency bands must not interfere with each other, only one card can run in container mode at a time, and inserting two serial-port cards disables the AP's Bluetooth serial port.

Step-by-Step: Bringing Up the Shared WLAN

Six moves get the staff/patient Wi-Fi and the AP's own network path online: switch trunking, AC addressing and DHCP, the AP's CAPWAP source, AP onboarding, and the WLAN service itself.

Trunk the switch ports facing the APs so both the management VLAN and the staff/patient Wi-Fi VLAN reach the AC — one trunk link, two VLANs, not two cables.
On the AC, create both VLANs and enable DHCP; give the management VLAN interface its address, and let the business VLAN interface hand out addresses to Wi-Fi clients from an interface-based pool.
Point the AC's CAPWAP source at the management VLAN interface, so every AP in the building has a defined path to register with the controller.
Create a regulatory-domain profile with the correct country code and reference it from an AP group — every AP added to that group inherits the same radio regulatory settings.
Import each AP by its MAC address, name it for its physical location (ward, department, floor), add it to the AP group, and push it a static IP address — not DHCP — through the AP provisioning template.
Build the staff/patient Wi-Fi service: a security profile with a real passphrase policy, an SSID profile, and a VAP profile that ties that SSID to the business VLAN — then apply the VAP profile to both radios in the AP group.

# Access switch — trunk the ports facing the APs
<HUAWEI> system-view
[HUAWEI] sysname Switch
[Switch] vlan batch 100 101
[Switch] interface GE 0/0/1
[Switch-GE0/0/1] port link-type trunk
[Switch-GE0/0/1] port trunk allow-pass vlan 100 101
[Switch-GE0/0/1] quit
[Switch] interface GE 0/0/2
[Switch-GE0/0/2] port link-type trunk
[Switch-GE0/0/2] port trunk pvid vlan 100
[Switch-GE0/0/2] port trunk allow-pass vlan 100 101
[Switch-GE0/0/2] quit

# AC uplink — same two VLANs
<HUAWEI> system-view
[HUAWEI] sysname AC
[AC] vlan batch 100 101
[AC] interface GE 0/0/1
[AC-GE0/0/1] port link-type trunk
[AC-GE0/0/1] port trunk allow-pass vlan 100 101
[AC-GE0/0/1] quit

# AC as DHCP server for STA, via the business VLAN's interface address pool
[AC] dhcp enable
[AC] interface vlanif 100
[AC-Vlanif100] ip address 10.23.100.1 24
[AC-Vlanif100] quit
[AC] interface vlanif 101
[AC-Vlanif101] ip address 10.23.101.1 24
[AC-Vlanif101] dhcp select interface
[AC-Vlanif101] quit

# CAPWAP source + regulatory domain + AP group
[AC] capwap source interface vlanif 100
[AC] wlan
[AC-wlan] regulatory-domain-profile name domain1
[AC-wlan-regulate-domain-domain1] country-code cn
[AC-wlan-regulate-domain-domain1] quit
[AC-wlan] ap-group name ap-group1
[AC-wlan-ap-group-ap-group1] regulatory-domain-profile domain1
Warning: This configuration change will clear the channel and power configurations of radios, and may
restart APs. Continue?[Y/N]:y
[AC-wlan-ap-group-ap-group1] quit
[AC-wlan] quit

# Import the AP by MAC address, name it for its location, assign it a static IP
[AC] wlan
[AC-wlan] ap auth-mode mac-auth
[AC-wlan] ap-id 0 ap-mac 00e0-fc76-e360
[AC-wlan-ap-0] ap-name area_1
[AC-wlan-ap-0] ap-group ap-group1
[AC-wlan-ap-0] quit
[AC-wlan] provision-ap
[AC-wlan-provision-ap] address-mode static
[AC-wlan-provision-ap] ip-address 10.23.100.2 24 gateway 10.23.100.1
[AC-wlan-provision-ap] ac-list 10.23.100.1
[AC-wlan-provision-ap] commit ap-id 0
[AC-wlan-provision-ap] quit

# Staff/patient Wi-Fi: security profile, SSID profile, VAP profile bound to the business VLAN
[AC-wlan] security-profile name wlan-net
[AC-wlan-sec-prof-wlan-net] security wpa-wpa2 psk pass-phrase YsHsjx_202206 aes
[AC-wlan-sec-prof-wlan-net] quit
[AC-wlan] ssid-profile name wlan-net
[AC-wlan-ssid-prof-wlan-net] ssid wlan-net
[AC-wlan-ssid-prof-wlan-net] quit
[AC-wlan] vap-profile name wlan-net
[AC-wlan-vap-prof-wlan-net] forward-mode direct-forward
[AC-wlan-vap-prof-wlan-net] service-vlan vlan-id 101
[AC-wlan-vap-prof-wlan-net] security-profile wlan-net
[AC-wlan-vap-prof-wlan-net] ssid-profile wlan-net
[AC-wlan-vap-prof-wlan-net] quit
[AC-wlan] ap-group name ap-group1
[AC-wlan-ap-group-ap-group1] vap-profile wlan-net wlan 1 radio 0
[AC-wlan-ap-group-ap-group1] vap-profile wlan-net wlan 1 radio 1
[AC-wlan-ap-group-ap-group1] quit

Extending the Same AP to Carry Medical IoT Traffic

The IoT card physically shares the AP with the Wi-Fi radios — the card needs its own profile pointing at the hospital's IoT middleware before it can talk to it.

Create an IoT profile that sets the card type and points at the IoT middleware's IP address and listening port — this is the address the AP will actually send collected sensor data to.
Apply that IoT profile to the AP's card interface, along with the local UDP port the card and the AP use to talk to each other — then hand the AP's IP address to the middleware vendor so their platform can add it as a managed device.

# Create the IoT profile: card type, and the medical IoT middleware's address/port
[AC-wlan] iot-profile name wlan-iot
[AC-wlan-iot-prof-wlan-iot] type common
[AC-wlan-iot-prof-wlan-iot] management-server server-ip 10.23.100.254 server-port 3000
[AC-wlan-iot-prof-wlan-iot] quit

# Apply it to the AP group's IoT card interface, with the local UDP port the card uses
[AC-wlan] ap-group name ap-group1
[AC-wlan-ap-group-ap-group1] card 1
[AC-wlan-group-card-ap-group1/1] iot-profile wlan-iot config-agent udp port 50200
[AC-wlan-group-card-ap-group1/1] quit
[AC-wlan-ap-group-ap-group1] quit

The middleware IP address and port in this example (10.23.100.254, UDP 3000) come from the source configuration case; in a real deployment they're supplied by the medical IoT vendor, not chosen by the network team.

5 Configuration Gotchas

The ones that turn a working Wi-Fi network into a medical IoT project nobody can finish.

1. NAT Doesn't Belong in This Design

SYMPTOMAn infant-security or infusion-monitoring deployment is planned across sites linked by NAT or over the internet, and the vendor's integration simply doesn't work reliably.

CAUSEThese scenarios are only supported over a local, routed Layer 2/3 network — the underlying protocol between the tag/monitor and the middleware isn't designed to survive address translation.

FIXKeep the AP, AC and IoT middleware on a directly routed network with no NAT in between; if sites need to be linked, do it with routing, not NAT.

2. Some IoT Cards Need the AP's Address to Never Change

SYMPTOMThe IoT vendor's platform loses track of an AP shortly after it was working fine — reads stop coming in for that ward.

CAUSECertain IoT card vendors register the AP's own IP address on their server; the server, not the AP, has the outdated address. Assigning the AP a DHCP lease that later renews to a different address breaks that binding.

FIXAssign the AP a static IP address through the provisioning template as shown in this note, rather than a DHCP lease, whenever the IoT card vendor's documentation calls for it.

3. Two IoT Cards in One AP Have Real Coexistence Limits

SYMPTOMA second IoT card is added to an AP that already has one, and Bluetooth-based tags stop being read, or the container-based integration app stops responding.

CAUSEAn AP with two IoT cards allows only one of them to be a serial-port card, the two cards' frequency bands must not overlap, only one card can be configured for container mode at a time, and installing two serial-port cards disables the AP's Bluetooth serial port entirely.

FIXCheck the combination against the supported list before ordering a second card, and decide in advance which single card will run in container mode.

4. Leaving CAPWAP DTLS Unauthenticated After Bring-Up

SYMPTOMAPs came online easily during initial rollout, but a later security review flags that any AP can join the controller without authentication.

CAUSEBringing a brand-new AP online sometimes requires temporarily allowing unauthenticated DTLS sessions so the AP can obtain its security credentials for the first time — and it's easy to move on to the next task and forget to turn that back off.

FIXTreat the no-auth window as temporary by design: enable it only long enough for the AP batch to get its credentials, then disable it before the rollout is called done.

5. Skipping Port Isolation Turns One Noisy Device Into a Ward-Wide Problem

SYMPTOMWireless clients on a ward's Wi-Fi see noticeably worse performance as more IoT terminals are added to the same VLAN, even though nothing else changed.

CAUSEWith direct-forward data forwarding, a switch port facing an AP without port isolation configured can let broadcast and multicast traffic replicate across every other device on the same VLAN — and multicast traffic sent over the wireless air interface at low mandatory rates costs airtime disproportionate to its size.

FIXConfigure port isolation on the switch ports directly connected to APs, and apply multicast suppression at the switch port (direct-forward) or the AC's traffic profile (tunnel-forward) rather than leaving it unbounded.

How to Confirm It's Actually Working

An AP showing “nor” and a VAP showing “ON” only confirm the Wi-Fi side — check the IoT profile separately, on the card, not just on paper.

Run display ap all once the AP is powered on. The State column should read nor (normal) before you consider it onboarded.
Run display vap ssid . Status should read ON for the SSID on each radio it's supposed to be broadcasting on.
Run display iot-profile name to confirm the middleware IP address and port the AP actually has configured — not just the one in your design document.
Once the card is in service, display ap-card all and display ap card { all | card-number | usb } confirm the card is recognized and reporting; iot-card reboot, reset-network-configuration and switch-firmware are the maintenance commands to reach for if it isn't.

[AC-wlan] display ap all
Total AP information:
nor : normal           [1]
ExtraInfo : Extra information
P : insufficient power supply
Total: 1
--------------------------------------------------------------------------------------------------
ID MAC              Name Group           IP         Type              State STA Uptime ExtraInfo
--------------------------------------------------------------------------------------------------
0 00e0-fc76-e360 area_1 ap-group1 10.23.100.2 AirEngine5760-51 nor 0 25S -
--------------------------------------------------------------------------------------------------

[AC-wlan] display vap ssid wlan-net
WID : WLAN ID
Total: 2
--------------------------------------------------------------------------------
AP ID AP name RfID WID BSSID                   Status Auth type        STA SSID
--------------------------------------------------------------------------------
0    area_1 0 1          00E0-FC76-E360 ON            WPA/WPA2-PSK 1            wlan-net
0    area_1 1 1          00E0-FC76-E370 ON            WPA/WPA2-PSK 0            wlan-net
------------------------------------------------------------------------------------

[AC-wlan] display iot-profile name wlan-iot
--------------------------------------------------------------------------------
Type                        : common
Management server IP address             : 10.23.100.254
Management server port                : 3000
--------------------------------------------------------------------------------

display ap-card all
display ap 0 card all
iot-card reboot ap-id 0 card 1
iot-card reset-network-configuration ap-id 0 card 1
iot-card switch-firmware ap-id 0 card 1

Honest Limits of This Note

Honest Limits of This Note

This note is built around one Huawei WLAN configuration case — an AC/AP network extended with an IoT add-on card to support an infant-security use case — and the IoT-card hardware model that goes with it. It doesn't cover Huawei's alternative built-in IoT module or 星闪(SLE) access methods mentioned in the same source material, doesn't cover any specific RTLS or infusion-monitoring vendor's own tag protocol or middleware behavior beyond the generic IP/port registration pattern shown here, and doesn't specify a QoS/DSCP priority scheme, since the configuration case this note is based on doesn't define one — that part is general engineering judgment, not a documented default. It also doesn't cover the Web-GUI configuration path, only the CLI.

Five Questions Worth Having an Answer For

Pulled from the same configuration case this note is built on.

Can we really put medical IoT devices on the same APs as staff and patient Wi-Fi?

Yes, and that's exactly the design this note is based on — a single AP carries both a Wi-Fi SSID for staff/patient devices and, through an add-on card, a separate protocol for medical IoT terminals. What keeps them apart isn't separate hardware, it's VLAN separation from the AP up to each traffic's own destination — the Wi-Fi VLAN goes to the hospital network, the IoT card's management path goes to the IoT middleware.

What's the difference between an IoT add-on card and a built-in IoT module?

The add-on card is physical hardware — installed as a PCIe card inside the AP or connected as a USB module — that adds RFID, ZigBee, Bluetooth or similar protocol support to an AP that otherwise only does Wi-Fi. Newer AP firmware versions also support a built-in IoT module and a SLE (星闪) access method as alternatives; this note focuses on the add-on card path shown in the CLI configuration case, since that's the one with a full worked example.

Can the medical IoT devices and middleware sit on different sites linked by NAT, or over the internet?

Not for the infant-security and infusion-monitoring scenarios this note is based on — the source material is explicit that those only support a local, routed Layer 2/3 network, not a NAT-crossing or internet-routed one. Plan for the AP, AC and IoT middleware to sit on the same routed network.

Why does our IoT vendor insist on a static IP address for the AP instead of DHCP?

Some IoT card vendors' servers keep a record of the AP's IP address to know where to reach it — if that address changes because a DHCP lease renewed differently, the server's record goes stale and readings stop. A static IP assigned through the AP provisioning template avoids that failure mode entirely.

Can one AP run two IoT protocols at once, like RFID and Bluetooth together?

Often yes, through two IoT card slots — but with real limits: only one of the two cards can be a serial-port card, their working frequency bands can't interfere with each other, only one card at a time can run in container mode, and having two serial-port cards installed disables the AP's Bluetooth serial port. Check the supported combination table before ordering a second card.

Planning Wi-Fi and medical IoT on the same hospital network?

Tell us how many wards or departments, which IoT use case (asset tracking, infant security, infusion monitoring or similar), and whether you're extending existing APs or starting fresh — we'll help you size the VLAN plan and the card hardware.

WhatsApp an engineer →