Part 01

TR069協議簡介 

協議即約定，通信協議約定了通信雙方交互所遵循的方式和細則。TR069協議約定用戶側設備（Customer Premises Equipment，即CPE）和自動配置服務器（Auto-Configuration Server，即ACS）之間交互的規則。我們知道HTTP協議是基于TCP協議，COAP協議是基于UDP協議，而這里的TR069協議則是基于HTTP1.1的協議傳輸，SOAP標準封裝XML的消息內容格式，消息內容部分如下圖1：

Part 02

TR069協議用途 

TR069協議提供了對下一代網絡中家庭網絡設備進行管理配置的通用框架、消息規范、管理方法和數據模型。在網管模型中，ACS負責對終端設備CPE進行遠程集中管理，解決CPE設備的管理困難，節約維護成本，提高問題解決效率。

ACS實現對CPE的遠程管理，核心便是ACS與CPE之間的連接交互。不同于MQTT協議，客戶端與服務器之間維持一個長鏈接，ACS同CPE的連接僅在存在交互需要時建立短鏈接。

Part 03

CPE連接ACS 

CPE首次啟動會主動對ACS發起HTTP連接，進行注冊上線動作，通過RPC方法中的inform方法上報0 BOOTSTRAP和1 BOOT（如上圖SOAP封裝的XML消息內容案例），如平臺有需要配置或者獲取的參數，也會在這次連接中進行。交互如下：

第一步：CPE直接對ACS發起HTTP連接請求，請求案例頭部如下：

POST /ACS-server/test HTTP/1.1
SOAPAction: 
Content-Length: 3923
......

第二步：ACS響應401，要求CPE進行HTTP Digest Authentication認證，即摘要認證，響應案例如下：

HTTP/1.1 401 Unauthorized
Server: XXX
WWW-Authenticate: Digest
realm="XXX",qop="XXX",nnotallow="5ad62dabf90594eed8d2d72cec12e5f9",opaque="60D0FDDCC498497B82138713D1383D9F"
......

第三步：CPE根據ACS響應的WWW-Authenticate信息，以及url、username和password，按照摘要認證算法計算response，構建出再次請求的摘要認證信息Authorization，并再次發起HTTP請求，進行inform上報。攜帶認證信息再次請求，案例如下：

POST /ACS-server/test HTTP/1.1
SOAPAction: 
Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nnotallow="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000001, cnnotallow="12327701", respnotallow="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX"
Content-Length: 3923
......

第四步：ACS響應200 OK，SOAP內容為InformResponse，摘要認證到這里已經完成。根據響應頭的Set-Cookie信息設置CPE下個請求的Cookie。案例如下：

HTTP/1.1 200 OK
Server: XXX
Set-Cookie:
JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29; Path=XXX;XXX
......

第五步：CPE發起的一個空的HTTP請求，根據TR069協議，消息體長度必須為0，如下案例可以看到Content-Length是0：

POST /ACS-server/test HTTP/1.1
Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nnotallow="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000002, cnnotallow="12327701", respnotallow="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX"
Content-Length: 0
Cookie:
JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29
......

第六步：ACS響應HTTP 空請求，封裝SOAP調用RPC方法，對終端設備進行參數配置或者查詢等操作。

HTTP/1.1 200 OK
Server: XXX
Content-Type: text/xml;charset=UTF-8
Content-Length: 2226
......

第七步：CPE發起請求，封裝SOAP對應響應RPC方法。如果終端管理平臺查詢后還需要進行配置，則第六步和第七步會有兩次，如都不需要，則第六步和第七步可省略。如存在，案例如下：

POST /ACS-server/acs HTTP/1.1
SOAPAction: 
Authorization: Digest realm="XXX", username="XXX", algorithm="MD5", nnotallow="5ad62dabf90594eed8d2d72cec12e5f9", uri="/ACS-server/test", nc=00000003, cnnotallow="12327701", respnotallow="XXXXXX", opaque="60D0FDDCC498497B82138713D1383D9F", qop="XXX"
Content-Length: 528
Cookie:
JSESSIONID=15F51C74ED3AE0FE45A382BEBC145D29
......

第八步：ACS下發一個空HTTP響應，根據TR069協議，狀態碼使用“204（無內容）”，表示本次會話結束。案例如下：

HTTP/1.1 204 No Content
Server: XXX
Date: Fri, 23 Jan 2023 00:15:14 GMT

這里我們針對第三步的摘要認證展開說明。這里簡要說明下WWW-Authenticate和Authorization中涉及到的一些參數，更多詳細內容可以自行參閱RFC2617等相關文檔。

? digest ==>認證方式

? realm ==>領域，領域參數是強制的，必須存在

? qop ==>保護的質量，“auth”表示只進行身份查驗， “auth-int”表示進行查驗外，還有一些完整性保護

? nonce ==>服務器側生成的隨機數，在每個401回應產生時，被唯一創建，為防止攻擊產生，參與加密

? cnonce ==>即client nonce

? uri ==>客戶端想要訪問的URL

? nc ==>連續請求次數，在同一個TCP連接里，設備每POST一次，nc+1

? algorithm ==>用來生產摘要及校驗和的算法對

? response ==>用來證明用戶是否知道口令

response計算通常過程分以下三步^[2]：

第一步：計算HA1

• HA1=MD5(A1)=MD5(username:realm:password)；

第二步：計算HA2

• 如果 qop 值為“auth”或未指定，那么HA2=MD5(A2)=MD5(method:uri)；
• 如果 qop 值為“auth-int”，那么HA2=MD5(A2)=MD5(method:uri:MD5(entityBody)；

第三步：根據HA1和HA2計算response

• 如果 qop 值為“auth”或“auth-int”，那么respnotallow=MD5(HA1:nonce:nc:cnonce:qop:HA2)；
• 如果 qop 未指定，那么respnotallow=MD5(HA1:nonce:HA2) 。

Authorization構建:CPE端生成cnonce，nc從00000000開始累計，response根據上述公式計算，opaque、qop、nonce、realm繼承自WWW-Authenticate，添加上username、algorithm和uri。

此外，終端管理系統可能還會對Manufacturer、OUI等參數進行查驗，如查驗不通過，響應403，即服務器理解客戶的請求，但拒絕處理它。

Part 04

ACS連接CPE 

通過ACS對CPE進行參數配置時，ACS作為主動方觸發本次連接。此時，ACS主動連接CEP，方式有兩種：

（1）非NAT模式下，ACS對CPE發起HTTP連接請求，使用終端上報的地址：Device.ManagementServer.ConnectionRequestURL，終端要求進行HTTP摘要認證。

（2）NAT模式下，ACS在公網環境下與內網下CPE交互，通過NAT穿越獲取CPE公網地址進行交互，實現流程見下文。

NAT，即網絡地址轉換。STUN 存在的目的就是進行NAT穿越^[1]，這里STUN將作為一個工具來服務于本次的ACS連接CPE實現。讓終端用來發現其在公網IP和端口，并作為一種保活（keep-alive）協議來維持NAT的綁定。

NAT模式下，ACS連接CPE實現具體如下：

第一步：基于STUN協議實現ACS與CPE之間的捆綁請求和響應，并維持。可借助第三方開源JSTUN庫，地址：https://gitee.com/javabedlamite/JSTUN/。如下是相關報文案例：

第二步：根據捆綁響應解析CPE公網IP和端口。根據STUN協議定義，MAPPED-ADDRESS屬性對應即是客戶端映射地址；在這里也是CPE的公網地址。

第三步：根據映射的端口地址構建終端管理系統的UDP回連地址；并上報ACS。涉及使用TR069數據模型中以下兩個參數：

• Device.ManagementServer.UDPCnotallow=CEP公網地址
• Device.ManagementServer.NATDetected=true通過Inform 4 VALUE CHANGE 

通知上報ACS，CPE支持NAT穿越，以及其在公網UDP回連地址。

第四步：某時刻，ACS需要對CPE進行配置，只需終端管理平臺對CPE的發起UDP請求，終端設備側解析后，觸發CPE對ACS發起Inform 6 CONNECTION REQUEST（根據Tr069協議，Inform 6表明本次會話是由ACS側要求而建立的）。到此ACS連接CPE完成。

第五步：在本次連接中，ACS下發對CPE的配置、查詢、重啟、診斷等約定支持的任務，CPE執行并響應。

整體流程大致實現可如下：

Part 05

主流圖形數據庫 

 ACS和CPE之間雙向連接建立的實現，是終端管理系統遠程管理終端的基本和前提。本文主要就ACS連接CEP和CPE連接ASC，各詳細講述一種連接實現方式和流程。目前，家庭智能網關普遍通過TR069協議納管于各省份的省側管理平臺，一些機頂盒也在通過TR069協議進行納管；在萬物互聯背景下，未來規模也許會更大。