一種確定用戶側(cè)設(shè)備狀態(tài)的方法和裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本申請涉及通信技術(shù)領(lǐng)域，尤其涉及一種確定用戶側(cè)設(shè)備狀態(tài)的方法和裝置。
【背景技術(shù)】
[0002]TR-069協(xié)議又稱為用戶側(cè)終端廣域網(wǎng)管理協(xié)議，它提供了對用戶側(cè)終端設(shè)備進(jìn)行管理配置的通用框架、消息規(guī)范、管理方法和數(shù)據(jù)模型。TR-069協(xié)議主要由自動配置服務(wù)器(ACS，Auto-Configurat1n Server)、用戶側(cè)設(shè)備(CPE，Customer Premise Equipment)、業(yè)務(wù)配置管理服務(wù)器以及一些必要的管理接口組成。
[0003]在傳統(tǒng)的SNMP網(wǎng)管系統(tǒng)中，一般使用ping報文來輪詢設(shè)備的狀態(tài)，確定設(shè)備是否可達(dá)。網(wǎng)管服務(wù)器定期向設(shè)備發(fā)送Ping報文，根據(jù)報文返回結(jié)果更新設(shè)備的狀態(tài)。在TR-069協(xié)議中，具備網(wǎng)管服務(wù)器功能的ACS需要定期輪詢CPE的狀態(tài)，由于TR-069協(xié)議是一種廣域網(wǎng)管理協(xié)議，ACS和CPE都在公網(wǎng)中，兩者之間一般都有防火墻，而ping報文使用ICMP協(xié)議，不能穿越防火墻，因此，TR-069協(xié)議給出了一個標(biāo)準(zhǔn)的TR069交互過程，以實(shí)現(xiàn)ACS輪詢CPE的狀態(tài)。
[0004]在上述標(biāo)準(zhǔn)的TR069交互過程中，ACS在獲知了 CPE的狀態(tài)后，還需要再進(jìn)行與狀態(tài)輪詢無關(guān)的Inform報文和Inform Response報文的交互。而這兩種報文所需的流量比較大，大約有5K字節(jié)，如果CPE的數(shù)量比較多，那么ACS用于輪詢CPE狀態(tài)的流量中有相當(dāng)大的一部分是不必要的。

【發(fā)明內(nèi)容】

[0005]有鑒于此，本申請?zhí)峁┮环N確定用戶側(cè)設(shè)備狀態(tài)的方法和裝置，用于解決在獲取CPE狀態(tài)的同時避免Inform報文的交互過程的技術(shù)問題。
[0006]基于本發(fā)明實(shí)施例，提出一種確定用戶側(cè)設(shè)備狀態(tài)的方法，所述方法包括:
[0007]用戶側(cè)設(shè)備CPE通過預(yù)定的支持HTTP服務(wù)的默認(rèn)端口即第一端口接收第一狀態(tài)請求報文，對所述第一狀態(tài)請求報文攜帶的錯誤的用戶信息驗證失敗后回復(fù)狀態(tài)應(yīng)答報文，指示自身狀態(tài)為可達(dá)；或
[0008]CPE通過預(yù)定的專用于檢測CPE狀態(tài)的第二端口接收第二狀態(tài)請求報文，直接針對所述第二狀態(tài)請求報文回復(fù)狀態(tài)應(yīng)答報文，指示自身狀態(tài)為可達(dá)，或者，對所述第二狀態(tài)請求報文攜帶的用戶信息驗證后，回復(fù)狀態(tài)應(yīng)答報文，指示自身狀態(tài)為可達(dá)；或
[0009]CPE通過預(yù)定的支持HTTP服務(wù)的默認(rèn)端口即第一端口及專用于檢測CPE狀態(tài)的特定的統(tǒng)一資源定位符URL接收第三狀態(tài)請求報文，直接針對所述第三狀態(tài)請求報文回復(fù)狀態(tài)應(yīng)答報文，指示自身狀態(tài)為可達(dá)，或者，對所述第三狀態(tài)請求報文攜帶的用戶信息驗證后，回復(fù)狀態(tài)應(yīng)答報文，指示自身狀態(tài)為可達(dá)。
[0010]基于本發(fā)明實(shí)施例，提出一種確定用戶側(cè)設(shè)備狀態(tài)的裝置，應(yīng)用于用戶側(cè)設(shè)備，所述裝置包括:
[0011]接收模塊，用于通過預(yù)定的支持HTTP服務(wù)的默認(rèn)端口即第一端口接收第一狀態(tài)請求報文；或用于通過預(yù)定的專用于檢測CPE狀態(tài)的第二端口接收第二狀態(tài)請求報文；或用于通過預(yù)定的支持HTTP服務(wù)的默認(rèn)端口即第一端口及專用于檢測CPE狀態(tài)的特定的URL接收第三狀態(tài)請求報文；
[0012]驗證模塊，用于對所述第一狀態(tài)請求報文攜帶的錯誤的用戶信息驗證失敗后，通知所述發(fā)送模塊；或用于對所述第二狀態(tài)請求報文或第三狀態(tài)請求報文攜帶的用戶信息驗證后，通知所述發(fā)送模塊；
[0013]所述發(fā)送模塊，用于根據(jù)所述通知，回復(fù)狀態(tài)應(yīng)答報文，指示所述用戶側(cè)設(shè)備狀態(tài)為可達(dá)；或用于直接針對所述第二狀態(tài)請求報文或第三狀態(tài)請求報文回復(fù)狀態(tài)應(yīng)答報文，指示自身狀態(tài)為可達(dá)。
[0014]在本發(fā)明實(shí)施例公開的用戶側(cè)設(shè)備狀態(tài)的方法和裝置中，使用默認(rèn)的支持HTTP服務(wù)的端口時，用戶信息驗證失敗，CPE向ACS回復(fù)狀態(tài)應(yīng)答報文；使用第二端口時，或者，使用默認(rèn)的支持HTTP服務(wù)的端口，但是使用了特定的URL來檢測CPE的狀態(tài)時，CPE接收到狀態(tài)請求報文，不驗證直接回復(fù)一個狀態(tài)應(yīng)答報文，或者，無論驗證成功或失敗，均回復(fù)一個狀態(tài)應(yīng)答報文。在標(biāo)準(zhǔn)TR069交互過程中，必須是使用默認(rèn)的支持HTTP服務(wù)的端口、且用戶信息驗證成功時，才回復(fù)狀態(tài)應(yīng)答報文，并且Inform報文的觸發(fā)需要符合兩個條件:使用默認(rèn)的支持HTTP服務(wù)的端口和用戶信息驗證成功，而本發(fā)明實(shí)施例上述三種實(shí)現(xiàn)方式，均未同時符合上述兩個條件，因此能夠避免Inform報文的觸發(fā)，節(jié)省了流量。
【附圖說明】
[0015]圖1是本發(fā)明實(shí)施例示出的確定用戶側(cè)設(shè)備狀態(tài)方法的流程圖；
[0016]圖2是本發(fā)明實(shí)施例示出的確定用戶側(cè)設(shè)備狀態(tài)裝置的結(jié)構(gòu)圖；
[0017]圖3是本發(fā)明實(shí)施例示出的一種用戶側(cè)設(shè)備的結(jié)構(gòu)示意圖。
【具體實(shí)施方式】
[0018]這里將詳細(xì)地對示例性實(shí)施例進(jìn)行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實(shí)施例中所描述的實(shí)施方式并不代表與本申請相一致的所有實(shí)施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。
[0019]在本申請使用的術(shù)語是僅僅出于描述特定實(shí)施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當(dāng)理解，本文中使用的術(shù)語“和/或”是指并包含一個或多個相關(guān)聯(lián)的列出項目的任何或所有可能組合。
[0020]應(yīng)當(dāng)理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當(dāng)……時”或“響應(yīng)于確定”。
[0021]在標(biāo)準(zhǔn)TR069協(xié)議中，確定用戶側(cè)設(shè)備CPE狀態(tài)的交互過程如下:
[0022]步驟1、CPE在一個端口開放HTTP服務(wù)，默認(rèn)是7547端口 ；
[0023]步驟2、ACS需要更新CPE的狀態(tài)時，向CPE的7547端口發(fā)送HTTP GET報文，攜帶預(yù)先在ACS和CPE上配置的CPE的用戶信息，例如用戶名和/或密碼；
[0024]步驟3、如果CPE已經(jīng)down掉，則無法收到以及響應(yīng)ACS發(fā)送的HTTP GET報文，ACS的HTTP GET報文請求超時，認(rèn)為CPE不可達(dá)，將CPE的狀態(tài)更新為不可達(dá)；
[0025]步驟4、CPE收到HTTP GET報文，CPE上配置的用戶信息與HTTP GET報文中的用戶信息不一致，則網(wǎng)管系統(tǒng)無法正常工作，這種情況不做考慮；
[0026]步驟5、CPE運(yùn)行正常，收到ACS發(fā)送的HTTP GET報文，用戶信息驗證通過，則回復(fù)HTTP STATUS 2000K的空報文，此時，ACS認(rèn)為CPE可達(dá)，將CPE的狀態(tài)更新為可達(dá)。
[0027]步驟6、按照TR069協(xié)議定義，CPE回復(fù)HTTP STATUS 2000K的空報文后，繼續(xù)向ACS 發(fā)送 CONNECT1N REQUEST 的 Inform 報文，ACS 向 CPE 回復(fù) Inform Response 報文。然后，CPE向ACS發(fā)送空報文請求任務(wù)執(zhí)行，ACS發(fā)現(xiàn)沒有需要CPE執(zhí)行的任務(wù)時，回復(fù)HTTPSTATUS 204N0_C0NTENT報文，通知CPE沒有任務(wù)需要執(zhí)行。
[0028]上述過程中，步驟6對于確定CPE狀態(tài)這一目的來說不是必要的步驟。整個步驟6需要的流量大約5k字節(jié)，由于ACS和CPE都位于公網(wǎng)，因此用戶往往對流量使用比較關(guān)注。如果用戶希望在CPE不可達(dá)時盡早知道，則會把狀態(tài)的輪詢間隔設(shè)的比