無線CAPWAP隧道技術——理論篇
【CAPWAP】本文詳細介紹了CAPWAP協議報文、狀態機、隧道建立過程三部分,幫助大家深入理解CAPWAP協議技術原理。
本文作者:田小楊
銳捷網絡技術服務部互聯網服務中心
前言

CAPWAP協議介紹
本次無線CAPWAP隧道技術的介紹分為理論篇和實踐篇,本期理論篇詳細介紹了CAPWAP協議報文、狀態機、隧道建立過程三部分,幫助大家深入理解CAPWAP協議技術原理。下一期實踐篇,將梳理項目中最常遇到的CAPWAP隧道無法建立的可能原因和解決思路。希望本文能夠幫助各位讀者把CAPWAP協議技術學透徹、用熟練。
CAPWAP協議簡介
在瘦AP場景下,AP不能單獨工作,需要與AC配合使用,因此AP和AC之間需要一個通信協議可以讓它們進行互聯。CAPWAP協議用于AC對其所關聯的AP的集中管理和控制,為AP和AC之間的互通性提供了一個通用封裝和傳輸機制。
CAPWAP協議主要具備以下幾個功能:
-
AP對AC的自動發現;
-
AP和AC的狀態機運行和維護;
-
AC對AP進行管理、業務配置下發;
-
STA數據封裝CAPWAP隧道進行轉發。
CAPWAP協議報文介紹
CAPWAP協議有兩種類型的報文:CAPWAP控制報文和數據報文。控制報文主要攜帶的是信息要素,用于AC對于AP工作參數的配置和CAPWAP隧道的維護;數據報文主要攜帶終端發送的數據報文,用于傳輸終端的上層數據。控制報文和數據報文分別傳輸在不同的UDP端口,控制報文使用端口5246,數據報文使用端口5247。
CAPWAP控制報文
不受DTLS保護的CAPWAP控制報文由CAPWAP前導、CAPWAP首部、控制首部、信息要素組成;受DTLS保護的CAPWAP控制報文由CAPWAP前導、DTLS首部、CAPWAP首部、控制首部、信息要素、DTLS尾部組成。是否受DTLS保護是CAPWAP的可選項, DTLS用于對CAPWAP報文進行加密和驗證,提高CAPWAP報文的安全性。銳捷無線設備CAPWAP控制報文DTLS保護默認開啟,可在ac-controller模式下通過命令no capwap dtls enable關閉用于故障排查(銳捷設備命令行)。
![]()
不受DTLS保護的CAPWAP控制報文格式
![]()
受DTLS保護的CAPWAP控制報文格式
CAPWAP前導中只包含Version和Type兩個字段,Version始終為0,Type有兩個可選參數0(CAPWAP Header)和1(CAPWAP DTLS Header)。CAPWAP前導的作用是通告其后面跟著的載荷類型是CAPWAP首部還是DTLS首部,即通告該CAPWAP報文是否加密。

CAPWAP控制報文中的CAPWAP前導
CAPWAP首部,Header Length指出CAPWAP首部大小;Radio ID用于指出此消息與哪個物理無線電設備關聯;Wireless Binding ID用于指出與此無線電設備關聯的無線分組的類型;Header Flags標志位目前有六位在用,每一位代表不同含義具體可參考《RFC 5415》;Fragment ID和Fragment Offset用于CAPWAP報文分片時使用。

CAPWAP控制報文中的CAPWAP首部
控制首部,Message Type用于表示CAPWAP控制報文的類型,目前有26種類型控制報文,每種類型控制報文的作用不同且攜帶的信息元素也不同,具體請查看本文最后的附錄1《CAPWAP協議控制報文類型匯總解析》;Sequence Number序列號,用于匹配Request報文和Response報文,Response報文中序列號與其要回復的Request報文中的序列號相同;Message Element Length指出其后攜帶的信息要素的大小;Flags始終為0。

CAPWAP控制報文中的控制首部
信息要素載荷是由多個獨立的信息要素組成,其中包含的信息要素的類型和數量與CAPWAP控制報文類型有關,每個信息要素由Type、Length、Value及其他字段組成。其中Type指出信息要素的類型,其中1-1023是CAPWAP協議信息要素,1024-2047是IEEE 802.11信息要素,具體請查看本文最后的附錄2《CAPWAP協議控制報文消息要素類型匯總解析》。

CAPWAP控制報文中的信息要素
CAPWAP數據報文
不受DTLS保護的CAPWAP數據報文由CAPWAP前導、CAPWAP首部、數據報文組成;受DTLS保護的CAPWAP數據報文由CAPWAP前導、DTLS首部、CAPWAP首部、數據報文、DTLS尾部組成。是否受DTLS保護是CAPWAP的可選項, DTLS用于對CAPWAP報文進行加密和驗證,提高CAPWAP報文的安全性。銳捷無線設備CAPWAP數據報文DTLS保護默認關閉,可通過命令開啟。
![]()
不受DTLS保護的CAPWAP數據報文格式
![]()
受DTLS保護的CAPWAP數據報文格式
CAPWAP前導和CAPWAP首部在CAPWAP控制報文中和數據報文中格式封裝相同此處不在贅述。

CAPWAP數據報文格式
CAPWAP協議狀態機介紹
CAPWAP協議狀態機由AC和AP使用,運行CAPWAP協議的AC和AP一共存在以下15種狀態機,其中AC或AP在每一種狀態下僅允許發送和接收特定的信息報文。
|
CAPWAP狀態機 |
狀態含義 |
|
Start狀態 |
AP開始和AC會話的初始狀態 |
|
Idle狀態 |
AP初始化完成后的狀態 |
|
Discovery狀態 |
AP進入發現AC的狀態,如果AP指定AC,這個狀態可以跳過 |
|
DTLS Setup狀態 |
DTLS會話建立 |
|
Authorize狀態 |
DTLS會話證書認證 |
|
DTLS Connect狀態 |
認證通過后進行連接狀態 |
|
Join狀態 |
會話連接建立完成 |
|
Image Date狀態 |
AP從AC下載一個可執行的版本文件,AP可以進行版本升級,升級完會重啟,DTLS會話因此斷開 |
|
Configure狀態 |
AP從AC獲取配置 |
|
Data Check狀態 |
AP和AC進行消息交換,確認配置 |
|
Run狀態 |
進入正常的運行狀態 |
|
Reset狀態 |
重啟設備 |
|
Sulking狀態 |
AP不能和AC進行通信切換到該狀態,可以進入Discovery狀態重新發現AC |
|
DTLS Teardown狀態 |
關閉DTLS會話 |
|
Dead狀態 |
完全清除狀態 |
CAPWAP協議AC和AP的狀態機
由于CAPWAP協議使用DTLS,CAPWAP狀態機的某些指令會觸發DTLS狀態機中的狀態轉換,而DTLS狀態機中的某些通知會觸發CAPWAP狀態機中的狀態轉換。所以如下圖所示CAPWAP狀態轉換情況較多,本文下一小節為各位讀者介紹CAPWAP隧道成功建立過程中AC和AP的CAPWAP狀態機的變化情況,想了解更多狀態機轉換條件介紹的讀者可以閱讀《RFC 5415》。

CAPWAP完整狀態機轉換圖
CAPWAP隧道建立過程介紹
本小節結合報文交互和狀態機變化介紹CAPWAP隧道建立過程,讀者在閱讀時可結合上兩小節CAPWAP協議報文介紹和CAPWAP協議狀態機介紹共同理解。

CAPWAP隧道建立過程中報文交互和狀態機變化
AP啟動后狀態機處于Idle狀態,AP通過多種途徑(IPv4單播、IPv4廣播、IPv4組播、IPv6組播)明文發送Discovery Request報文,用于發現網絡中可用的AC,并提供自己的基本信息給AC。AC收到Discovery Request報文后,使用Discovery Response報文回應,將自己支持的服務告訴給請求AP。因為此時DTLS隧道還未建立,所以Discovery Request報文和Discovery Response報文是使用明文交互的。
隨后AP和AC進行DTLS驗證建立DTLS加密隧道,隧道建立成功后,之后交互的CAPWAP控制報文全部通過DTLS隧道加密保護,是否受DTLS保護是可選的。
DTLS隧道建立后,AP發出Join Request報文用于申請加入AC。AC收到Join Request報文并回應Join Response報文答復AP是否同意AP加入。
Join Response報文中包括Image Identifier消息要素,指出AC要求AP運行的軟件版本。AP收到Join Response報文后,對比當前使用版本和AC要求的版本是否一致,若版本一致狀態機進入Configure狀態。若版本不一致狀態機進入Image Data狀態,AP與AC交互Image Data Request報文和Image Data Response報文進行版本傳輸并升級,升級后AP進行重啟,重新與AC進行CAPWAP隧道建立。
AP狀態機變為Configure狀態后,AP發出Config Status Request報文,用于向AC請求配置文件下發,AC收到Config Status Request報文后回應Config Status Response報文,通知AP按要求進行配置。
AC發送Config Status Response報文下發配置后還需要確認配置是否在AP上執行成功,AP收到Config Status Response后,狀態機進入Data Check狀態, 并發送Change State Event Request報文報告配置執行情況,AC收到Change State Event Request報文后回應Change State Event Response報文,狀態機變為Run狀態,至此AP與AC的CAPWAP隧道建立成功。

不受DTLS保護的CAPWAP隧道建立過程報文交互
總結
附錄1:CAPWAP協議控制報文類型匯總解析
|
CAPWAP控制報文類型 |
Message Type |
作用 |
|
Discovery Request |
1 |
AP發送,用于發現網絡中可用的AC,并提供自己的基本信息給AC |
|
Discovery Response |
2 |
AC發送,將自己支持的服務告訴給前來請求的AP |
|
Join Request |
3 |
AP發送,用于申請加入AC |
|
Join Response |
4 |
AC發送,用于對AP加入申請的響應 |
|
Configuration Status Request |
5 |
AP發送,用于向AC請求配置文件下發 |
|
Configuration Status Response |
6 |
AC發送,用于將自己的配置數據同步給AP |
|
Configuration Update Request |
7 |
AC發送,用于同步AP配置更新 |
|
Configuration Update Response |
8 |
AP發送,用于告訴AC更新配置文件的執行情況 |
|
WTP Event Request |
9 |
AP用來發送信息給AC,WTP Event Request可能是階段性發送或者是作為一個AP同步事件的響應 |
|
WTP Event Response |
10 |
響應WTP Event Request |
|
Change State Event Request |
11 |
當AP收到來自AC的Configuration Status Response,AP使用Change State Event Request來提供Radio的當前狀態,確認AC提供的配置已經成功應用;在Run狀態下,AP發送Change State Event Request來告訴AC,AP的Radio發生了意料之外的改變 |
|
Change State Event Response |
12 |
AC發送,響應Change State Event Request |
|
Echo Request |
13 |
AP和AC之間發送,在控制報文沒有發送的時候,用于CAPWAP隧道的維系 |
|
Echo Response |
14 |
AP和AC之間響應,在控制報文沒有發送的時候,用于CAPWAP隧道的維系 |
|
Image Data Request |
15 |
AP發送,用于鏡像文件的申請 |
|
Image Data Response |
16 |
AC發送,用于對AP鏡像文件申請的響應 |
|
Reset Request |
17 |
AP重啟請求 |
|
Reset Response |
18 |
AC對AP重啟請求的響應 |
|
Primary Discovery Request |
19 |
AP發送,判斷他首選(或配置的)AC是否可用或者執行一個Path MTU Discovery |
|
Primary Discovery Response |
20 |
AC發送,告訴AP自己當前可用與支持的服務 |
|
Data Transfer Request |
21 |
AP將自己的調試信息發送給AC |
|
Data Transfer Response |
22 |
AC對Data Transfer Request消息的響應 |
|
Clear Configuration Request |
23 |
AC發送,用于告訴AP將自己的配置恢復至出廠默認值 |
|
Clear Configuration Response |
24 |
AP發送,恢復出廠默認配置之后,發送給AC確認 |
|
Station Configuration Request |
25 |
AC用于創建、修改、刪除AP上的Station會話狀態 |
|
Station Configuration Response |
26 |
響應Station Configuration Request |
附錄2:CAPWAP協議控制報文消息要素類型匯總解析
|
CAPWAP控制報文信息要素類型 |
Type |
作用 |
|
AC Descriptor |
1 |
AC描述符消息要素由AC用于通知它目前的狀態 |
|
AC IPv4 List |
2 |
AC IPv4列表消息要素用于為AP配置可供AP加入的最新AC列表 |
|
AC IPv6 List |
3 |
AC IPv6列表消息要素用于為AP配置可供AP加入的最新AC列表 |
|
AC Name |
4 |
AC名稱消息要素包含以UTF-8格式表示的AC身份 |
|
AC Name with Priority |
5 |
帶優先權的AC名稱消息要素的AC Name由AC發送給AP,以便配置優先的AC |
|
AC Timestamp |
6 |
AC時間戳消息要素由AC發送,用于同步AP時鐘 |
|
Add MAC Access Control List (ACL) Entry |
7 |
添加MAC ACL條目消息要素由AC用于在AP上添加MAC ACL列表條目,確保AP不再為該消息中給出的MAC地址提供服務 |
|
Add Station |
8 |
添加終端消息要素由AC用于通知AP它應當轉發終端的流量 |
|
CAPWAP Control IPv4 Address |
10 |
CAPWAP控制IPv4地址消息要素由AC在Discovery處理期間發送給AP,以及由AC用于提供該AC上的可用接口和提供目前連接的AP數量 |
|
CAPWAP Control IPv6 Address |
11 |
CAPWAP控制IPv6地址消息要素由AC在Discovery處理期間發送給AP,以及由AC用于提供該AC上的可用接口和提供目前連接的AP數量 |
|
CAPWAP Timers |
12 |
CAPWAP計時器消息要素由AC用于配置AP上的CAPWAP計時器 |
|
Data Transfer Data |
13 |
數據傳輸數據消息要素由AP用于提供信息給AC用于調試 |
|
Data Transfer Mode |
14 |
數據傳輸模式消息要素由AP用于指出它正在發送到AC用于調試的數據傳輸信息類型 |
|
Decryption Error Report |
15 |
解密錯誤報告消息要素的值由AP用于通知解密出錯的AC,這些錯誤是自上次報告以來發生的 |
|
Decryption Error Report Period |
16 |
解密錯誤報告周期消息要素值由AC用于通知AP,它應當多長時間發送一次解密錯誤報告消息 |
|
Delete MAC ACL Entry |
17 |
刪除MAC ACL條目消息要素由AC用于在AP上刪除MAC ACL條目,確保AP向在該消息中給出的MAC地址提供服務 |
|
Delete Station |
18 |
刪除終端消息要素由AC用于通知AP,它不應當再對特定終端提供服務。 |
|
Discovery Type |
20 |
發現類型消息要素由AP用于簡要說明,它是如何最終知道存在一個AC,它正在向該AC發送Discovery Request消息 |
|
Duplicate IPv4 Address |
21 |
重復的IPv4地址消息要素由AP用于通知AC,該AP已經檢測到另一臺設備,該設備使用的IP地址與此AP目前正在使用的相同 |
|
Duplicate IPv6 Address |
22 |
重復的IPv6地址消息要素由AP用于通知AC,該AP已經檢測到另一臺設備,該設備使用的IP地址與此AP目前正在使用的相同 |
|
Idle Timeout |
23 |
空閑超時消息要素由AC發送給AP,向其提供Idle Timeout值,AP在它所有激活的站中應當強制執行此值 |
|
Image Data |
24 |
映像數據消息要素出現在AC發送的Image Data Request消息中 |
|
Image Identifier |
25 |
映像標識符消息要素由AC發送給AP,指出預期將在AP上運行的激活軟件版本 |
|
Image Information |
26 |
映像信息消息要素出現在由AC發送給AP的Image Data Response 消息中 |
|
Initiate Download |
27 |
啟動下載消息要素由AP用于通知AC,AC應當發起固件更新 |
|
Location Data |
28 |
位置數據消息要素是字節長度可變UTF-8編碼串,包含用戶定義的位置信息 |
|
Maximum Message Length |
29 |
最大消息長度消息要素由AP包括在Join Request消息中,用于告訴AC該AP支持的最大CAPWAP消息長度 |
|
CAPWAP Local IPv4 Address |
30 |
CAPWAP本地IPv4地址消息要素由AP在Join Request中發送,或者由AC在Join Response中發送 |
|
Radio Administrative State |
31 |
無線電設備管理狀態消息要素用于傳遞特定無線電設備的狀態 |
|
Radio Operational State |
32 |
無線電設備運行狀態消息要素由AP發送給AC,傳遞無線電設備的運行狀態 |
|
Result Code |
33 |
結果代碼消息要素是32位整數值,包括Request消息結果,該 Request消息對應Response消息中含有的序列號 |
|
Returned Message Element |
34 |
返回的消息要素由AP在Change State Event Request消息中發送,用于通知AC它不能在本地使用Configuration Status Response中的哪些消息要素 |
|
Session ID |
35 |
會話ID消息要素值包含隨機產生的無符號128位整數 |
|
Statistics Timer |
36 |
統計量計時器消息要素值由AC用于告訴AP,AP將以此頻次收到的它盼望的最新統計數據 |
|
Vendor Specific Payload |
37 |
特定供應商凈荷消息要素用于在AP和AC間傳遞特定供應商信息 |
|
WTP Board Data |
38 |
AP主板數據消息要素由AP發送給AC,包括目前硬件信息 |
|
WTP Descriptor |
39 |
AP描述符消息要素由AP用于傳遞它目前的硬件和軟件(固件)配置 |
|
WTP Fallback |
40 |
AP回退消息要素由AC發送給AP,用于AP檢測到它的首選AC時,開啟或關閉自動CAPWAP回退 |
|
WTP Frame Tunnel Mode |
41 |
AP幀隧道模式消息要素使AP能夠告訴AC,它支持的隧道化運行模式 |
|
WTP MAC Type |
44 |
AP MAC類型消息要素使AP能夠將它的運行模式告訴AC |
|
WTP Name |
45 |
AP名稱消息要素是可變長度UTF-8編碼字節串 |
|
WTP Radio Statistics |
47 |
AP無線電設備統計量消息要素由AP發送給AC,傳遞關于無線電設備行為的統計數據,以及重新設置AP無線電設備的原因 |
|
WTP Reboot Statistics |
48 |
AP重啟統計量消息要素由AP發送給AC,傳遞AP發生重新啟動的原因 |
|
WTP Static IP Address Information |
49 |
AP靜態IP地址信息消息要素由AC用于在AP上配置或刪除先前配置的靜態IP地址 |
|
CAPWAP Local IPv6 Address |
50 |
CAPWAP本地IPv6地址消息要素由AP在Join Request中發送,或者由AC在Join Response中發送 |
|
CAPWAP Transport Protocol |
51 |
CAPWAP傳輸協議消息要素如果CAPWAP在IPv6上運行,可以使用UDP-Lite或UDP傳輸 |
|
MTU Discovery Padding |
52 |
MTU發現填充消息要素用作填充,執行MTU發現,必須包含值為0xFF,長度任意的八位位組 |
|
ECN Support |
53 |
ECN支持消息要素由AP和AC發送,指出它們支持Explicit Congestion Notification (ECN)位 |
|
IEEE 802.11 Add WLAN |
1024 |
由AC發往AP,由AC用來在AP上定義一個新的WLAN |
|
IEEE 802.11 Antenna |
1025 |
由AP向AC通信來提供天線可用信息,同時AC可以使用該消息元素來重新配置AP的天線 |
|
IEEE 802.11 Assigned WTP BSSID |
1026 |
是AP在IEEE 802.11 WLAN Configuration Request報文中含有IEEE 802.11 Add WLAN消息元素時進行包含 |
|
IEEE 802.11 Delete WLAN |
1027 |
用來告知AP以前建立的一個WLAN被刪除 |
|
IEEE 802.11 Direct Sequence Control |
1028 |
是一個雙向的消息元素,當由AP發送時,包含現在的狀態;由AC發送時,AP必須保證AC所提供的值 |
|
IEEE 802.11 Information Element |
1029 |
用于傳送任何802.11協議中定義的IE。數據字段中里面包含將會存在于IEEE 802.11 MAC管理消息中的原始IE |
|
IEEE 802.11 MAC Operation |
1030 |
由AC發送來設置AP上IEEE 802.11MAC的參數 |
|
IEEE 802.11 MIC Countermeasures |
1031 |
由AP發送給AC表明一個MIC失敗發生 |
|
IEEE 802.11 Multi-Domain Capability |
1032 |
被AC用來告訴AP調整的極限,AC會在每一個頻段里發送一個消息元素來表明在該域里面進行調整的范圍約束 |
|
IEEE 802.11 OFDM Control |
1033 |
是一個雙向的消息元素,當由AP發送時,包含當前的狀態。當由AC發送時,AP必須支持所接受到的值 |
|
IEEE 802.11 Rate Set |
1034 |
由AC發送,包含了所支持的速率 |
|
IEEE 802.11 RSNA Error Report From Station |
1035 |
被AP用來向AC發送RSN錯誤報告,如果沒有錯誤,AP不需要任何報告 |
|
IEEE 802.11 Station |
1036 |
伴隨著Add Station消息元素,用來從AC向AP發送IEEE 802.11 STA策略,最新的IEEE 802.11消息元素會覆蓋之前接受到的任何消息元素 |
|
IEEE 802.11 Station QoS Profile |
1037 |
含STA可能用到的最大的IEEE 802.11e優先級標識符 |
|
IEEE 802.11 Station Session Key |
1038 |
用于AC決定STA加密必須在AP上執行 |
|
IEEE 802.11 Statistics |
1039 |
由AP發送,用來傳輸自己當前的統計信息 |
|
IEEE 802.11 Supported Rates |
1040 |
由AP發送,來表示他支持的速率 |
|
IEEE 802.11 Tx Power |
1041 |
當由AP發送時,是Radio的當前功率;當由AC發送時,包含AP必須要支持的功率 |
|
IEEE 802.11 Tx Power Level |
1042 |
由AP發送,包含所有支持的不同的功率 |
|
IEEE 802.11 Update Station QoS |
1043 |
用來在AP上改變一個指定STA的服務質量策略 |
|
IEEE 802.11 Update WLAN |
1044 |
由AC來使用在AP上來定義一個無線局域網 |
|
IEEE 802.11 WTP Quality of Service |
1045 |
由AC發向AP,用于通信QOS的配置信息 |
|
IEEE 802.11 WTP Radio Configuration |
1046 |
由AC用來在AP上配置一個Radio;或者AP用來發送其Radio配置信息給AC |
|
IEEE 802.11 WTP Radio Fail Alarm Indication |
1047 |
是由AP在檢測到一個Radio錯誤發送給AC |
|
IEEE 802.11 WTP Radio Information |
1048 |
用來為AP里的每個Radio傳遞Radio信息 |
相關推薦:
相關標簽:
點贊
更多技術博文
-
解密DeepSeek-V3推理網絡:MoE架構如何重構低時延、高吞吐需求?DeepSeek-V3發布推動分布式推理網絡架構升級,MoE模型引入大規模專家并行通信,推理流量特征顯著變化,Decode階段對網絡時度敏感。網絡需保障低時延與高吞吐,通過端網協同負載均衡與擁塞控制技術優化性能。高效運維實現故障快速定位與業務高可用,單軌雙平面與Shuffle多平面組網方案在低成本下滿足高性能推理需求,為大規模MoE模型部署提供核心網絡支撐。
-
#交換機
-
-
高密場景無線網絡新解法:銳捷Wi-Fi 7 AP 與 龍伯透鏡天線正式成團銳捷網絡在中國國際大學生創新大賽(2025)總決賽推出旗艦Wi-Fi 7無線AP RG-AP9520-RDX及龍伯透鏡天線組合,針對高密場景實現零卡頓、低時延和高并發網絡體驗。該方案通過多檔賦形天線和智能無線技術,有效解決干擾與覆蓋問題,適用于場館、辦公等高密度環境,提供穩定可靠的無線網絡解決方案。
-
#無線網
-
#Wi-Fi 7
-
#無線
-
#放裝式AP
-
-
打造“一云多用”的算力服務平臺:銳捷高職教一朵云2.0解決方案發布銳捷高職教一朵云2.0解決方案幫助學校構建統一云桌面算力平臺,支持教學、實訓、科研和AI等全場景應用,實現一云多用。通過資源池化和智能調度,提升資源利用效率,降低運維成本,覆蓋公共機房、專業實訓、教師辦公及AI教學等多場景需求,助力教育信息化從分散走向融合,推動規模化與個性化培養結合。
-
#云桌面
-
#高職教
-
-
醫院無線升級必看:“全院零漫游”六大謎題全解析銳捷網絡的全院零漫游方案是新一代醫療無線解決方案,專為智慧醫院設計,通過零漫游主機和天線入室技術實現全院覆蓋和移動零漫游體驗。方案支持業務擴展全適配,優化運維管理,確保內外網物理隔離安全,并便捷部署物聯網應用,幫助醫院提升網絡性能,支持舊設備利舊升級,降低成本。
-
#醫療
-
#醫院網絡
-
#無線
-