Comment concevoir et configurer un WLAN unique qui porte à la fois le Wi-Fi habituel du personnel/des patients et le trafic IoT médical — étiquettes RTLS, surveillance de pompes à perfusion et terminaux similaires — sur les mêmes points d'accès : l'approche matérielle de la carte IoT additionnelle, la conception VLAN/isolation, et la configuration Huawei AC/AP réelle qui en découle.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Faire fonctionner le Wi-Fi et l'IoT médical comme deux réseaux séparés double le câblage, les points d'accès et les maux de tête d'exploitation — les faire cohabiter en toute sécurité sur un seul réseau est la réponse plus difficile, mais meilleure.
La plupart des hôpitaux n'ont pas prévu dès le départ de construire des réseaux parallèles — c'est arrivé service par service : l'appel infirmier a ajouté sa propre passerelle, la sécurité des nourrissons son propre réseau de lecteurs, le suivi des actifs ses propres étiquettes et son propre back-end — chacun résolvant le problème d'un seul service sans plan à l'échelle de l'hôpital. Le résultat est exactement ce contre quoi l'architecture sous-jacente met en garde : infrastructure reconstruite en double, données cloisonnées par application, ondes radio qui se gênent dans le même couloir, et une équipe d'exploitation réseau qui doit apprendre cinq systèmes différents au lieu d'un seul.
L'alternative est une conception en couches qui sépare les préoccupations plutôt que les réseaux : une couche terminale de dispositifs de détection (moniteurs de perfusion, étiquettes d'actifs, bracelets mère-enfant et similaires), une couche d'accès où une carte ou un module IoT additionnel sur le même point d'accès Wi-Fi capte le protocole non-Wi-Fi que ces appareils utilisent réellement, une couche de transport composée d'infrastructure AP/AC/commutateur ordinaire qui ne fait que relayer le trafic, et une couche applicative — le middleware IoT de l'hôpital ou un système spécifique comme une plateforme de sécurité des nourrissons — qui consomme réellement ces données. Le réseau Wi-Fi et le réseau IoT médical partagent le même point d'accès physique et le même port de commutateur ; ce qui les empêche de s'interférer, ce n'est pas un second jeu de câbles, mais la séparation par VLAN et la rigueur de configuration.
La même paire de radios d'un point d'accès porte le SSID Wi-Fi du personnel/des patients ; un emplacement de carte sur ce même point d'accès porte le protocole IoT médical — séparés par VLAN depuis l'interface jusqu'au serveur applicatif.
Les légendes du schéma restent en anglais pour la clarté technique.
Plan de données réseau (cet exemple)
| Élément | Valeur (cet exemple) |
|---|---|
| VLAN de gestion — trafic de contrôle AP↔AC et chemin carte IoT de l'AP↔intergiciel | VLAN 100 |
| VLAN de service Wi-Fi personnel/patients | VLAN 101 |
| Interface source CAPWAP de l'AC | VLANIF100 |
| Service DHCP pour les clients Wi-Fi (STA) | AC as DHCP server, interface-based pool on VLANIF101 |
| Adresse IP du point d'accès | Static 10.23.100.2/24 |
| Pool d'adresses STA (client Wi-Fi) | 10.23.101.2–10.23.101.254/24 |
| Intergiciel IoT médical / serveur applicatif | 10.23.100.254, UDP port 3000 (example) |
Combinaisons de cartes IoT prises en charge par point d'accès
| Combinaison de cartes | Prise en charge |
|---|---|
| Carte PCIe port réseau (grande, 2 emplacements) + carte USB port réseau | Pris en charge |
| Carte PCIe port réseau (grande, 2 emplacements) + carte USB port série | Pris en charge |
| Carte PCIe port série ×1 + carte USB port réseau | Pris en charge |
| Carte PCIe port série ×1 + carte USB port série | Pris en charge |
| Carte PCIe port série ×2 (petite, 1 emplacement chacune) | Pris en charge |
Ces cinq combinaisons sont toutes prises en charge, sous conditions : une seule des deux cartes peut être une carte port série, les bandes de fréquence de travail des deux cartes ne doivent pas s'interférer, une seule carte à la fois peut fonctionner en mode conteneur, et l'installation de deux cartes port série désactive complètement le port série Bluetooth du point d'accès.
Six étapes suffisent pour mettre en service le Wi-Fi personnel/patients et le chemin réseau propre du point d'accès : trunk sur le commutateur, adressage et DHCP sur l'AC, source CAPWAP de l'AC, mise en ligne du point d'accès, et le service WLAN lui-même.
# 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] quitLa carte IoT partage physiquement le point d'accès avec les radios Wi-Fi — mais elle a besoin de son propre profil pointant vers l'intergiciel IoT de l'hôpital avant de pouvoir communiquer avec lui.
# 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] quitL'adresse IP et le port de l'intergiciel dans cet exemple (10.23.100.254, UDP 3000) proviennent du cas de configuration source ; dans un déploiement réel, ils sont fournis par le fournisseur d'IoT médical, pas choisis par l'équipe réseau.
Ce sont celles qui transforment un réseau Wi-Fi qui aurait dû fonctionner du premier coup en un projet IoT médical que personne n'arrive à boucler.
SYMPTÔMEUn déploiement de sécurité des nourrissons ou de surveillance de perfusion est planifié entre sites reliés par NAT ou via Internet, et l'intégration du fournisseur ne fonctionne tout simplement pas de façon fiable.
CAUSECes scénarios ne sont pris en charge que sur un réseau local routé de couche 2/3 — le protocole sous-jacent entre l'étiquette/le moniteur et l'intergiciel n'est pas conçu pour survivre à une traduction d'adresse.
SOLUTIONGardez le point d'accès, l'AC et l'intergiciel IoT sur un réseau directement routé, sans NAT entre eux ; si des sites doivent être reliés, faites-le par le routage, pas par le NAT.
SYMPTÔMELa plateforme du fournisseur IoT perd la trace d'un point d'accès peu après qu'il fonctionnait normalement — les relevés de ce service cessent d'arriver.
CAUSECertains fournisseurs de cartes IoT enregistrent l'adresse IP propre du point d'accès sur leur serveur ; si le bail DHCP du point d'accès se renouvelle avec une adresse différente, le serveur garde l'ancienne adresse et ce lien est rompu.
SOLUTIONAttribuez au point d'accès une adresse IP statique via le modèle de provisionnement comme indiqué dans ce billet, plutôt qu'un bail DHCP, chaque fois que la documentation du fournisseur de la carte IoT l'exige.
SYMPTÔMEUne seconde carte IoT est ajoutée à un point d'accès qui en avait déjà une, et les étiquettes basées sur Bluetooth cessent d'être lues, ou l'application d'intégration basée sur conteneur cesse de répondre.
CAUSEUn point d'accès équipé de deux cartes IoT n'autorise qu'une seule d'entre elles à être une carte port série, les bandes de fréquence des deux cartes ne doivent pas se chevaucher, une seule carte à la fois peut être configurée en mode conteneur, et l'installation de deux cartes port série désactive entièrement le port série Bluetooth du point d'accès.
SOLUTIONVérifiez la combinaison par rapport à la liste prise en charge avant de commander une seconde carte, et décidez à l'avance quelle carte unique fonctionnera en mode conteneur.
SYMPTÔMELes points d'accès se sont mis en ligne facilement lors du déploiement initial, mais un audit de sécurité ultérieur signale que n'importe quel point d'accès peut rejoindre le contrôleur sans authentification.
CAUSEMettre en ligne un tout nouveau point d'accès nécessite parfois d'autoriser temporairement des sessions DTLS non authentifiées, afin qu'il puisse obtenir ses identifiants de sécurité pour la première fois — et il est facile de passer à la tâche suivante et d'oublier de le désactiver.
SOLUTIONTraitez la fenêtre sans authentification comme temporaire par conception : activez-la seulement le temps que le lot de points d'accès obtienne ses identifiants, puis désactivez-la avant de déclarer le déploiement terminé.
SYMPTÔMELes clients sans fil d'un service voient leurs performances nettement se dégrader à mesure que des terminaux IoT sont ajoutés au même VLAN, alors que rien d'autre n'a changé.
CAUSEEn mode de transfert direct, un port de commutateur faisant face à un point d'accès sans isolation de port configurée peut laisser le trafic de diffusion et de multidiffusion se répliquer vers tous les autres appareils du même VLAN — et le trafic multidiffusion envoyé sur l'interface radio sans fil à des débits obligatoires faibles coûte un temps d'antenne disproportionné par rapport à sa taille.
SOLUTIONConfigurez l'isolation de port sur les ports de commutateur directement connectés aux points d'accès, et appliquez la suppression de multidiffusion au niveau du port du commutateur (transfert direct) ou du modèle de trafic de l'AC (transfert par tunnel), plutôt que de la laisser sans limite.
Un point d'accès affichant « nor » et un VAP affichant « ON » ne confirment que le côté Wi-Fi — vérifiez le profil IoT séparément, sur la carte elle-même, pas seulement sur le papier.
[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 1Ce billet s'appuie sur un cas de configuration WLAN Huawei — un réseau AC/AP étendu par une carte IoT additionnelle pour prendre en charge un cas d'usage de sécurité des nourrissons — et le modèle matériel de carte IoT qui l'accompagne. Il ne couvre pas le module IoT intégré alternatif de Huawei ni la méthode d'accès SLE (星闪) mentionnés dans la même documentation source, ne couvre le protocole d'étiquette ou le comportement d'intergiciel propres à aucun fournisseur RTLS ou de surveillance de perfusion en particulier au-delà du schéma générique d'enregistrement IP/port présenté ici, et ne spécifie pas de schéma de priorité QoS/DSCP, puisque le cas de configuration sur lequel ce billet s'appuie n'en définit pas — cette partie relève du jugement d'ingénierie général, pas d'une valeur par défaut documentée. Il ne couvre pas non plus la voie de configuration par interface web, seulement la CLI.
Tirées du même cas de configuration sur lequel ce billet s'appuie.
Oui, et c'est exactement la conception sur laquelle ce billet s'appuie — un même point d'accès porte à la fois un SSID Wi-Fi pour les appareils du personnel/des patients et, via une carte additionnelle, un protocole distinct pour les terminaux IoT médicaux. Ce qui les sépare n'est pas du matériel distinct, mais la séparation VLAN depuis le point d'accès jusqu'à la destination propre de chaque trafic — le VLAN Wi-Fi va vers le réseau hospitalier, le chemin de gestion de la carte IoT va vers l'intergiciel IoT.
La carte additionnelle est un matériel physique — installée sous forme de carte PCIe à l'intérieur du point d'accès, ou connectée comme module USB — qui ajoute la prise en charge de RFID, ZigBee, Bluetooth ou protocoles similaires à un point d'accès qui ne ferait sinon que du Wi-Fi. Les versions de firmware d'AP plus récentes prennent aussi en charge un module IoT intégré et une méthode d'accès SLE (星闪) comme alternatives ; ce billet se concentre sur la voie de la carte additionnelle présentée dans le cas de configuration CLI, car c'est celle qui dispose d'un exemple complet.
Pas pour les scénarios de sécurité des nourrissons et de surveillance de perfusion sur lesquels ce billet s'appuie — le document source précise explicitement que ces scénarios ne prennent en charge qu'un réseau local routé de couche 2/3, pas un réseau traversant du NAT ou routé par Internet. Prévoyez que le point d'accès, l'AC et l'intergiciel IoT se trouvent sur le même réseau routé.
Les serveurs de certains fournisseurs de cartes IoT conservent une trace de l'adresse IP du point d'accès pour savoir où le joindre — si cette adresse change parce qu'un bail DHCP s'est renouvelé différemment, l'enregistrement du serveur devient obsolète et les relevés cessent d'arriver. Une adresse IP statique attribuée via le modèle de provisionnement de l'AP évite entièrement ce mode de défaillance.
Souvent oui, via deux emplacements de carte IoT — mais avec de vraies limites : une seule des deux cartes peut être une carte port série, leurs bandes de fréquence de travail ne doivent pas s'interférer, une seule carte à la fois peut fonctionner en mode conteneur, et installer deux cartes port série désactive le port série Bluetooth du point d'accès. Vérifiez le tableau des combinaisons prises en charge avant de commander une seconde carte.
Indiquez-nous le nombre de services ou d'unités, le cas d'usage IoT concerné (suivi d'actifs, sécurité des nourrissons, surveillance de perfusion ou similaire), et si vous étendez des points d'accès existants ou partez de zéro — nous vous aiderons à dimensionner le plan VLAN et le matériel des cartes.