本申請涉及通信技術(shù)領(lǐng)域，尤其涉及一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法及裝置。

背景技術(shù)：

隨著技術(shù)的不斷發(fā)展，終端的設(shè)備例如各種傳感器越來越多，甚至于未來設(shè)備的數(shù)量可能會遠(yuǎn)遠(yuǎn)超過人類的數(shù)量。為了應(yīng)對如此多的設(shè)備連接通信，物聯(lián)網(wǎng)技術(shù)應(yīng)運(yùn)而生。

基于CAN(控制器局域網(wǎng)絡(luò))方式連接通信的物聯(lián)網(wǎng)中，為了便于管理接入的設(shè)備，CAN主控制器需要給接入的設(shè)備分配ID。

現(xiàn)有技術(shù)中，由于CAN本身只是一個簡單的通用協(xié)議框架，并沒有分配ID的功能，所以分配ID的工作通常都是人工完成的。然而，人工分配ID往往效率較低，并且人工成本也較高。

技術(shù)實現(xiàn)要素：

本申請?zhí)峁┗诳刂破骶钟蚓W(wǎng)絡(luò)的設(shè)備管理方法及裝置，用以解決現(xiàn)有技術(shù)中人工分配ID效率較低，成本較高的問題。

根據(jù)本申請實施例提供的一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法，所述方法包括：

控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播DHCP Discover報文；其中，所述DHCP Discover報文中攜帶一個隨機(jī)數(shù)，所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址，所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文；

控制器局域網(wǎng)絡(luò)的主控制器接收到DHCP Discover報文后根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并廣播DHCP Offer報文；所述DHCP Offer報文中攜帶所分配的第一ID；

控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Offer報文后，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文；其中，所述DHCP Request報文攜帶所述第二ID；

控制器局域網(wǎng)絡(luò)的主控制器接收到DHCP Request報文后判斷該報文中的第二ID與之前所分配的第一ID是否一致；

控制器局域網(wǎng)絡(luò)的主控制器在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，將所述第二ID確定為第三ID，并廣播DHCP Ack報文；其中，所述DHCP Ack報文中攜帶所確定的第三ID；

控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Ack報文后，判斷該報文中的第三ID與所述第二ID是否一致；

控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID。

可選的，所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

可選的，所述分配的ID位于4到240之間。

根據(jù)本申請實施例提供的一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法，所述方法應(yīng)用在所述控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點，所述方法包括：

廣播DHCP Discover報文；其中，所述DHCP Discover報文中攜帶一個隨機(jī)數(shù)，所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址，所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文；

在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Offer報文后，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文；其中，所述DHCP Request報文攜帶所述第二ID；

在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Ack報文后，判斷該報文中的第三ID與所述第二ID是否一致；

在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID。

可選的，在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID之后，所述方法還包括：

將所述最終的ID保存在存儲器中；

相應(yīng)地，

在所述廣播DHCP Discover報文之前，所述方法還包括：

判斷保存的ID是否有效；

在保存的ID無效的情況下，執(zhí)行所述廣播DHCP Discover報文；

在保存的ID有效的情況下，將所述已存在的ID確定為第二ID，執(zhí)行所述廣播DHCP Request報文。

可選的，所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

根據(jù)本申請實施例提供的一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法，所述方法應(yīng)用在所述控制器局域網(wǎng)絡(luò)的主控制器，所述方法包括：

接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Discover報文后，根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并廣播DHCP Offer報文；所述DHCP Offer報文中攜帶所分配的第一ID；

接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Request報文后，判斷該報文中的第二ID與之前所分配的第一ID是否一致；

在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，將所述第二ID確定為第三ID，并廣播DHCP Ack報文；其中，所述DHCP Ack報文中攜帶所確定的第三ID。

可選的，所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

可選的，所述分配的ID位于4到240之間。

根據(jù)本申請實施例提供的一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置，所述裝置應(yīng)用在所述控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點，所述裝置包括：

第一廣播單元，用于廣播DHCP Discover報文；其中，所述DHCP Discover報文中攜帶一個隨機(jī)數(shù)，所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址，所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文；

第二廣播單元，用于在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Offer報文后，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文；其中，所述DHCP Request報文攜帶所述第二ID；

判斷單元，用于在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Ack報文后，判斷該報文中的第三ID與所述第二ID是否一致；

確定單元，用于在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID。

可選的，在所述確定單元之后，所述裝置還包括：

存儲子單元，用于將所述最終的ID保存在存儲器中；

相應(yīng)地，

在所述第一廣播單元之前，所述裝置還包括：

判斷子單元，用于判斷保存的ID是否有效；

所述第一廣播單元，還用于在保存的ID無效的情況下，廣播DHCP Discover報文；

所述第二廣播單元，還用于在保存的ID有效的情況下，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文。

根據(jù)本申請實施例提供的一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置，所述裝置應(yīng)用在所述控制器局域網(wǎng)絡(luò)的主控制器上，所述裝置包括：

分配單元，用于接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Discover報文后，根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID；

第三廣播單元，用于廣播DHCP Offer報文；所述DHCP Offer報文中攜帶所分配的第一ID；

判斷單元，用于接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Request報文后，判斷該報文中的第二ID與之前所分配的第一ID是否一致；

第四廣播單元，在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，將所述第二ID確定為第三ID，并廣播DHCP Ack報文；其中，所述DHCP Ack報文中攜帶所確定的第三ID。

可選的，所述分配的ID位于4到240之間。

本申請實施例，借鑒了DHCP入網(wǎng)報文，在控制器局域網(wǎng)絡(luò)協(xié)議中預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文。如此，控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點與主控制器可以實現(xiàn)DHCP報文交互，即與DHCP入網(wǎng)報文類似的，設(shè)備節(jié)點可以廣播攜帶隨機(jī)數(shù)的DHCP Discover報文；主控制器可以根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并通過DHCP Offer報文廣播出去；設(shè)備節(jié)點接收到DHCP Offer報文后將所述第一ID作為第二ID后，通過DHCP Request報文廣播出去；主控制器在所述第二ID與第一ID一致的情況下，將所述第二ID作為第三ID并通過DHCP Ack報文廣播出去；最后設(shè)備節(jié)點在判斷所述第三ID與第二ID一致的情況下，將所述第三ID確定為最終的ID。這樣，實現(xiàn)了控制器局域網(wǎng)絡(luò)可以自動地對接入的設(shè)備分配ID，實現(xiàn)了提高分配ID的效率，并且由于無需人工分配ID，相應(yīng)地也降低了運(yùn)營成本。

附圖說明

圖1是本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法的流程圖；

圖2是本申請一實施例提供的DHCP Discover報文格式示意圖；

圖3是本申請一實施例提供的DHCP Offer報文格式示意圖；

圖4是本申請一實施例提供的DHCP Request報文格式示意圖；

圖5是本申請一實施例提供的DHCP Ack報文格式示意圖；

圖6是本申請一實施例提供的DHCP NAck報文格式示意圖；

圖7是本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法的流程圖；

圖8是本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法的流程圖；

圖9是本申請?zhí)峁┑幕诳刂破骶钟蚓W(wǎng)絡(luò)的設(shè)備管理裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖；

圖10是本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的模塊示意圖；

圖11是本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的模塊示意圖。

具體實施方式

這里將詳細(xì)地對示例性實施例進(jìn)行說明，其示例表示在附圖中。下面的描述涉及附圖時，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本申請相一致的所有實施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本申請的一些方面相一致的裝置和方法的例子。

在本申請使用的術(shù)語是僅僅出于描述特定實施例的目的，而非旨在限制本申請。在本申請和所附權(quán)利要求書中所使用的單數(shù)形式的“一種”、“所述”和“該”也旨在包括多數(shù)形式，除非上下文清楚地表示其他含義。還應(yīng)當(dāng)理解，本文中使用的術(shù)語“和/或”是指并包含一個或多個相關(guān)聯(lián)的列出項目的任何或所有可能組合。

應(yīng)當(dāng)理解，盡管在本申請可能采用術(shù)語第一、第二、第三等來描述各種信息，但這些信息不應(yīng)限于這些術(shù)語。這些術(shù)語僅用來將同一類型的信息彼此區(qū)分開。例如，在不脫離本申請范圍的情況下，第一信息也可以被稱為第二信息，類似地，第二信息也可以被稱為第一信息。取決于語境，如在此所使用的詞語“如果”可以被解釋成為“在……時”或“當(dāng)……時”或“響應(yīng)于確定”。

相關(guān)技術(shù)中，控制器局域網(wǎng)絡(luò)即CAN總線，是一種傳統(tǒng)的有線連接方式，用于實現(xiàn)各個設(shè)備之間簡單的物理連接?；贑AN方式連接通信時，需要對接入的設(shè)備分配ID。ID與設(shè)備之間是一一對應(yīng)的關(guān)系。通過ID可以快速查找到對應(yīng)的設(shè)備，如此方便管理接入的設(shè)備。然而，由于CAN本身并沒有分配ID的功能，所以分配ID的工作通常都是人工完成的。然而，人工分配ID往往效率較低，特別是在成套設(shè)備接入的情況下，容易出現(xiàn)錯誤，并且人工成本導(dǎo)致的運(yùn)營成本也較高。

為了解決上述問題，請參見圖1，為本申請一實施例提供的一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法的流程圖，該實施例從控制器局域網(wǎng)絡(luò)的主控制器和設(shè)備節(jié)點這兩側(cè)進(jìn)行描述，包括以下步驟：

步驟110：控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播DHCP Discover報文；其中，所述DHCP Discover報文中攜帶一個隨機(jī)數(shù)，所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址，所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文。

本實施例中，在控制器局域網(wǎng)絡(luò)協(xié)議CAN中，具有一個29bit(位)的擴(kuò)展ID。

所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文。即，在該擴(kuò)展ID中重新定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文這五種報文類型。

如下詳細(xì)介紹所述定義的五種DHCP報文：

如圖2所示，為本申請實施例提供的一種DHCP Discover報文格式示意圖。圖2中，利用原擴(kuò)展ID的29bit信息，廣播DHCP Discover，其中，

第0-4bit用于表示報文的分幀序列；本例子中為1111；

第5bit用于表示報文的最后一幀；本例子中為0；

第6-13bit用于表示報文的源地址；本例子中為11111111；

第14-21bit用于表示報文的目的地址；本例子中為00000001；

第22bit用于表示報文是請求報文還是應(yīng)答報文，1表示請求報文，0表示應(yīng)答報文；本例子中為1，即DHCP Discover報文為請求報文；

第23-26bit用于表示報文保留；本例子中為0101；

第27-28bit用于表示優(yōu)先級；本例子中為00；

Data(數(shù)據(jù)區(qū))，具有3byte(字節(jié))，用于表示報文類型和隨機(jī)數(shù)。其中，所述隨機(jī)數(shù)占用了2字節(jié)，所以報文類型占用了1字節(jié)；本例子中為0x01+0x0004，即報文類型為1，隨機(jī)數(shù)為4。

需要說明的是，由于所述報文類型僅占用了1字節(jié)，所以數(shù)據(jù)區(qū)定義報文類型時，將1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

需要說明的是，所述隨機(jī)數(shù)為2字節(jié)，作為一個臨時標(biāo)識，對應(yīng)于設(shè)備地址，并用于申請ID。

如圖3所示，為本申請實施例提供的一種DHCP Offer報文格式示意圖。圖3中，利用原擴(kuò)展ID的29bit信息，所述DHCP Offer中，

第0-4bit用于表示報文的分幀序列；本例子中為1111；

第5bit用于表示報文的最后一幀；本例子中為0；

第6-13bit用于表示報文的源地址；本例子中為00000001；

第14-21bit用于表示報文的目的地址；本例子中為11111111；

第22bit用于表示報文是請求報文還是應(yīng)答報文，1表示請求報文，0表示應(yīng)答報文；本例子中為0，即DHCP Offer報文為應(yīng)答報文；

第23-26bit用于表示報文保留；本例子中為0101；

第27-28bit用于表示優(yōu)先級；本例子中為00；

Data(數(shù)據(jù)區(qū))，具有4byte(字節(jié))，用于表示報文類型、隨機(jī)數(shù)和第一ID。其中，所述報文類型占用了1字節(jié)，所述隨機(jī)數(shù)占用了2字節(jié)，所述第一ID占用了1字節(jié)。本例子中為0x02+0x0004+0x05,即報文類型為2，隨機(jī)數(shù)為4，第一ID為5。

需要說明的是，由于所述報文類型僅占用了1字節(jié)，所以數(shù)據(jù)區(qū)定義報文類型時，將1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

需要說明的是，所述隨機(jī)數(shù)為2字節(jié)，在DHCP Offer報文中的隨機(jī)數(shù)與DHCP Discover報文中的隨機(jī)數(shù)為同一個。

如圖4所示，為本申請實施例提供的一種DHCP Request報文格式示意圖。圖4中，利用原擴(kuò)展ID的29bit信息，廣播DHCP Request，其中，

第0-4bit用于表示報文的分幀序列；本例子中為1111；

第5bit用于表示報文的最后一幀；本例子中為0；

第6-13bit用于表示報文的源地址；本例子中為11111111；

第14-21bit用于表示報文的目的地址；本例子中為00000001；

第22bit用于表示報文是請求報文還是應(yīng)答報文，1表示請求報文，0表示應(yīng)答報文；本例子中為1，即DHCP Request報文為請求報文；

第23-26bit用于表示報文保留；本例子中為0101；

第27-28bit用于表示優(yōu)先級；本例子中為00；

Data(數(shù)據(jù)區(qū))，具有2byte(字節(jié))，用于表示報文類型和第二ID。其中，所述報文類型占用了1字節(jié)，所述第二ID占用了1字節(jié)。本例子中為0x03+0x05,即報文類型為3，第二ID為5。

需要說明的是，由于所述報文類型僅占用了1字節(jié)，所以數(shù)據(jù)區(qū)定義報文類型時，將1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

如圖5所示，為本申請實施例提供的一種DHCP Ack報文格式示意圖。圖5中，利用原擴(kuò)展ID的29bit信息，所述DHCP Ack中，

第0-4bit用于表示報文的分幀序列；本例子中為1111；

第5bit用于表示報文的最后一幀；本例子中為0；

第6-13bit用于表示報文的源地址；本例子中為00000001；

第14-21bit用于表示報文的目的地址；本例子中為11111111；

第22bit用于表示報文是請求報文還是應(yīng)答報文，1表示請求報文，0表示應(yīng)答報文；本例子中為0，即DHCP Ack報文為應(yīng)答報文；

第23-26bit用于表示報文保留；本例子中為0101；

第27-28bit用于表示優(yōu)先級；本例子中為00；

Data(數(shù)據(jù)區(qū))，具有2byte(字節(jié))，用于表示報文類型和第三ID。其中，所述報文類型占用了1字節(jié)，所述第三ID占用了1字節(jié)。本例子中為0x04+0x05,即報文類型為4，第三ID為5。

需要說明的是，由于所述報文類型僅占用了1字節(jié)，所以數(shù)據(jù)區(qū)定義報文類型時，將1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。

如圖6所示，為本申請實施例提供的一種DHCP NAck報文格式示意圖。圖6中，利用原擴(kuò)展ID的29bit信息，所述DHCP NAck中，

第0-4bit用于表示報文的分幀序列；本例子中為1111；

第5bit用于表示報文的最后一幀；本例子中為0；

第6-13bit用于表示報文的源地址；本例子中為00000001；

第14-21bit用于表示報文的目的地址；本例子中為11111111；

第22bit用于表示報文是請求報文還是應(yīng)答報文，1表示請求報文，0表示應(yīng)答報文；本例子中為0，即DHCP NAck報文為應(yīng)答報文；

第23-26bit用于表示報文保留；本例子中為0101；

第27-28bit用于表示優(yōu)先級；本例子中為00；

Data(數(shù)據(jù)區(qū))，具有2byte(字節(jié))，用于表示報文類型和第四ID。其中，所述報文類型占用了1字節(jié)，所述源地址占用了1字節(jié)。本例子中為0x05+0x00,即報文類型為5，第四ID為0。

需要說明的是，由于所述報文類型僅占用了1字節(jié)，所以數(shù)據(jù)區(qū)定義報文類型時，將1代表Discover，2代表Offer，3代表Request，4代表Ack，5代表NAck。所述第四ID在后面進(jìn)行說明。

由于上述CAN協(xié)議預(yù)先定義了DHCP報文，所以控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點可以廣播DHCP Discover報文，并且該報文中攜帶一個隨機(jī)數(shù)。所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址。值得一提的是，所述設(shè)備地址具有唯一性，即每個設(shè)備都具有一個唯一的設(shè)備地址。

步驟120：控制器局域網(wǎng)絡(luò)的主控制器接收到DHCP Discover報文后根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并廣播DHCP Offer報文；所述DHCP Offer報文中攜帶所分配的第一ID。

本實施例中，控制器局域網(wǎng)絡(luò)的主控制器接收到設(shè)備節(jié)點廣播的DHCP Discover報文后，可以根據(jù)隨機(jī)數(shù)分配一個可用的ID(第一ID)。

在實際應(yīng)用中，ID為1字節(jié)，其最大范圍為0-255；由于定義了特殊功能的ID占用了編號(例如，DHCP NAck報文會攜帶的ID為0)，所以能留給設(shè)備節(jié)點使用的ID為4-240之間。

例如，主控制器接收到圖2所示的DHCP Discover報文后，可以分配一個5(可用的ID)，并且廣播如圖3所示的DHCP Offer報文，該DHCP Offer報文的數(shù)據(jù)區(qū)中攜帶有所分配的ID即5。

步驟130：控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Offer報文后，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文；其中，所述DHCP Request報文攜帶所述第二ID。

本實施例中，控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點接收到主控制器發(fā)送的DHCP Offer報文后，可以將該DHCP Offer報文中數(shù)據(jù)區(qū)內(nèi)的第一ID確定為第二ID，并通過DHCP Request報文廣播出去。

例如，設(shè)備節(jié)點接收到圖3所示的DHCP Offer報文后，可以將第一ID(5)確定為第二ID，并廣播圖4所示的DHCP Request報文，在該DHCP Request報文的數(shù)據(jù)區(qū)內(nèi)第二ID為5。

值得一提的是，如果控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點沒有接收到返回的DHCP Offer報文后，可以重復(fù)執(zhí)行步驟110步驟。

步驟140：控制器局域網(wǎng)絡(luò)的主控制器接收到DHCP Request報文后判斷該報文中的第二ID與之前所分配的第一ID是否一致。

本實施例中，控制器局域網(wǎng)絡(luò)的主控制器接收到設(shè)備節(jié)點廣播的DHCP Request報文后，需要判斷該DHCP Request報文中的第二ID與之前所分配的第一ID是否一致。

如果不一致，說明廣播該DHCP Request報文的設(shè)備節(jié)點不合法，則主控制器可以廣播DHCP NAck報文，所述DHCP NAck報文中攜帶有第四ID。如圖6所示，DHCP NAck報文中數(shù)據(jù)區(qū)攜帶有第四ID，并且所述第四ID不是一個有效的ID，即不位于4-240之間。例如本例子中的第四ID為0。

相對應(yīng)的，設(shè)備節(jié)點在接收到所述DHCP報文后，解析該報文得到Data(數(shù)據(jù)區(qū))的報文類型為NAck的情況下，可以需要重新執(zhí)行步驟110。例如，接收到圖6所示的DHCP報文后，解析DHCP報文得到Data(數(shù)據(jù)區(qū))的報文類型為5，由于數(shù)據(jù)區(qū)定義報文類型時，將5代表NAck，所以可以確定該DHCP報文為DHCP NAck報文，從而重新執(zhí)行步驟110。

如果一致，說明廣播該DHCP Request報文的設(shè)備節(jié)點合法，則執(zhí)行步驟150。

步驟150：控制器局域網(wǎng)絡(luò)的主控制器在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，將所述第二ID確定為第三ID，并廣播DHCP Ack報文；其中，所述DHCP Ack報文中攜帶所確定的第三ID。

本實施例中，在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，控制器局域網(wǎng)絡(luò)的主控制器可以將所述第二ID確定為第三ID，并通過DHCP Ack報文將所述第三ID廣播出去。

以圖3和圖4所示的DHCP報文為例，由于圖4所示的DHCP Request報文數(shù)據(jù)區(qū)中的第二ID(為5)，與之前所分配的第一ID即圖3數(shù)據(jù)區(qū)中的第一ID(為5)是一致的，所以主控制器可以將所述第二ID確定為第三ID，廣播如圖5所示的DHCP Ack報文，該DHCP Ack報文的數(shù)據(jù)區(qū)中攜帶有第三ID(為5)。

步驟160：控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Ack報文后，判斷該報文中的第三ID與所述第二ID是否一致。

本實施例中，控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點接收到主控制器返回的DHCP Ack報文后，需要判斷該DHCP Ack報文中的第三ID與所確定的第二ID是否一致。

如果一致，執(zhí)行步驟170。

如果不一致，則重復(fù)執(zhí)行步驟110。

步驟170：控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID。

本實施例中，在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點最終可以將所述第三ID號確定為最終的ID。

通過本申請實施例，借鑒了DHCP入網(wǎng)報文，在控制器局域網(wǎng)絡(luò)協(xié)議中預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文。如此，控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點與主控制器可以實現(xiàn)DHCP報文交互，即與DHCP入網(wǎng)報文類似的，設(shè)備節(jié)點可以廣播攜帶隨機(jī)數(shù)的DHCP Discover報文；主控制器可以根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并通過DHCP Offer報文廣播出去；設(shè)備節(jié)點接收到DHCP Offer報文后將所述第一ID作為第二ID后，通過DHCP Request報文廣播出去；主控制器在所述第二ID與第一ID一致的情況下，將所述第二ID作為第三ID并通過DHCP Ack報文廣播出去；最后設(shè)備節(jié)點在判斷所述第三ID與第二ID一致的情況下，將所述第三ID確定為最終的ID。這樣，實現(xiàn)了控制器局域網(wǎng)絡(luò)可以自動地對接入的設(shè)備分配ID，實現(xiàn)了提高分配ID的效率，并且由于無需人工分配ID，相應(yīng)地也降低了運(yùn)營成本。

以下結(jié)合圖7介紹本申請以控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點為主體的方法實施例，該實施例可以對應(yīng)圖1：

步驟210：廣播DHCP Discover報文；其中，所述DHCP Discover報文中攜帶一個隨機(jī)數(shù)，所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址，所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文。

可選的，所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

步驟220：在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Offer報文后，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文；其中，所述DHCP Request報文攜帶所述第二ID。

步驟230：在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Ack報文后，判斷該報文中的第三ID與所述第二ID是否一致。

步驟240：在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID。

在實際應(yīng)用過程中，例如傳感器這樣微型的設(shè)備是低功耗的，不會一直上電。在設(shè)備重新上電時，會將其視為新接入的設(shè)備，然而，該設(shè)備其實已經(jīng)獲取了ID，如此就會造成多次申請ID，不僅占用了多個可用ID，而且也對服務(wù)器造成額外的壓力。

為了解決上述問題，在上述圖7基礎(chǔ)上，在本申請的另一個實施例中，在所述步驟240之后，所述方法還可以包括：

將所述最終的ID保存在存儲器中；

相應(yīng)地，

在所述步驟210之前，所述方法還包括：

判斷保存的ID是否有效；

在保存的ID無效的情況下，執(zhí)行所述步驟210，即廣播DHCP Discover報文；

在保存的ID有效的情況下，將所述存儲器中保存的ID確定為第二ID，執(zhí)行所述廣播DHCP Request報文。

本實施例中，所述存儲器可以包括例如Flash(Flash EEPROM Memory，閃存)。

設(shè)備上電后，通過查詢存儲器中保存的ID；在查詢到ID的情況下，判斷所述存儲器中保存的ID是否有效。

由于分配的ID位于4-240之間，也就是說有效的ID必定是位于4-240之間的，反之位于4-240之外的ID是無效的。

通過本實施例，對于曾經(jīng)獲取到ID的設(shè)備，該設(shè)備可以將該ID保存到存儲器中，從而在該設(shè)備重新上電后，可以獲取保存在存儲器中的ID，并在該ID有效的情況下，直接將該ID確定為第二ID后，廣播DHCP Request報文。如此，避免每次重新上電設(shè)備都要重復(fù)申請ID。

以下結(jié)合圖8介紹本申請以控制器局域網(wǎng)絡(luò)的主控制器為主體的方法實施例，該實施例可以對應(yīng)圖1：

步驟310：接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Discover報文后，根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并廣播DHCP Offer報文；所述DHCP Offer報文中攜帶所分配的第一ID。

可選的，所述分配的ID位于4到240之間。

步驟320：接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Request報文后，判斷該報文中的第二ID與之前所分配的第一ID是否一致。

步驟330：在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，將所述第二ID確定為第三ID，并廣播DHCP Ack報文；其中，所述DHCP Ack報文中攜帶所確定的第三ID。

可選的，所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

與前述以控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點為主體的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法實施例相對應(yīng)，本申請還提供了基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的實施例。

本申請基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的實施例可以應(yīng)用在控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點上。裝置實施例可以通過軟件實現(xiàn)，也可以通過硬件或者軟硬件結(jié)合的方式實現(xiàn)。以軟件實現(xiàn)為例，作為一個邏輯意義上的裝置，是通過其所在設(shè)備的處理器將非易失性存儲器中對應(yīng)的計算機(jī)程序指令讀取到內(nèi)存中運(yùn)行形成的。從硬件層面而言，如圖9所示，為本申請基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置所在設(shè)備的一種硬件結(jié)構(gòu)圖，除了圖9所示的處理器、網(wǎng)絡(luò)接口、內(nèi)存以及非易失性存儲器之外，實施例中裝置所在的設(shè)備通常根據(jù)該基于控制器局域網(wǎng)絡(luò)的設(shè)備管理的實際功能，還可以包括其他硬件，對此不再贅述。

參見圖10，為本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的模塊圖，該實施例從控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點側(cè)進(jìn)行描述，所述裝置包括：第一廣播單元410、第二廣播單元420、判斷單元430和確定單元440。

其中，第一廣播單元410，用于廣播DHCP Discover報文；其中，所述DHCP Discover報文中攜帶一個隨機(jī)數(shù)，所述隨機(jī)數(shù)用作臨時標(biāo)識發(fā)送設(shè)備地址，所述控制器局域網(wǎng)絡(luò)協(xié)議預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文；

第二廣播單元420，用于在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Offer報文后，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文；其中，所述DHCP Request報文攜帶所述第二ID；

判斷單元430，用于在接收到控制器局域網(wǎng)絡(luò)的主控制器返回的DHCP Ack報文后，判斷該報文中的第三ID與所述第二ID是否一致；

確定單元440，用于在DHCP Ack報文中的第三ID與所述第二ID一致的情況下，將所述第三ID號確定為最終的ID。

在一個可選的實現(xiàn)方式中：

在所述確定單元440之后，所述裝置還包括：

存儲子單元，用于將所述最終的ID保存在存儲器中；

相應(yīng)地，

在所述第一廣播單元410之前，所述裝置還包括：

判斷子單元，用于判斷保存的ID是否有效；

所述第一廣播單元410，還用于在保存的ID無效的情況下，廣播DHCP Discover報文；

所述第二廣播單元420，還用于在保存的ID有效的情況下，將該報文中的第一ID確定為第二ID，并廣播DHCP Request報文。

在一個可選的實現(xiàn)方式中：

所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

類似的，與前述以控制器局域網(wǎng)絡(luò)的主控制器為主體的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理方法實施例相對應(yīng)，本申請還提供了一種基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的實施例。

參見圖11，為本申請一實施例提供的基于控制器局域網(wǎng)絡(luò)的設(shè)備管理裝置的模塊圖，該實施例從控制器局域網(wǎng)絡(luò)的主控制器側(cè)進(jìn)行描述，所述裝置包括：分配單元510、第三廣播單元520、判斷單元530和第四廣播單元540。

其中，分配單元510，用于接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Discover報文后，根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID；

第三廣播單元520，用于廣播DHCP Offer報文；所述DHCP Offer報文中攜帶所分配的第一ID；

判斷單元530，用于接收到控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點廣播的DHCP Request報文后，判斷該報文中的第二ID與之前所分配的第一ID是否一致；

第四廣播單元540，在DHCP Request報文中的第二ID與之前所分配的第一ID一致的情況下，將所述第二ID確定為第三ID，并廣播DHCP Ack報文；其中，所述DHCP Ack報文中攜帶所確定的第三ID。

在一個可選的實現(xiàn)方式中：

所述分配的ID位于4到240之間。

在一個可選的實現(xiàn)方式中：

所述報文中的數(shù)據(jù)區(qū)定義了報文類型，所述報文類型占用1字節(jié)；

1代表Discover，

2代表Offer，

3代表Request，

4代表Ack，

5代表NAck。

綜上所述，通過申請本實施例，借鑒了DHCP入網(wǎng)報文，在控制器局域網(wǎng)絡(luò)協(xié)議中預(yù)先定義了DHCP Discover、DHCP Offer、DHCP Request、DHCP Ack和DHCP NAck報文。如此，控制器局域網(wǎng)絡(luò)的設(shè)備節(jié)點與主控制器可以實現(xiàn)DHCP報文交互，即與DHCP入網(wǎng)報文類似的，設(shè)備節(jié)點可以廣播攜帶隨機(jī)數(shù)的DHCP Discover報文；主控制器可以根據(jù)所述隨機(jī)數(shù)分配一個可用的第一ID，并通過DHCP Offer報文廣播出去；設(shè)備節(jié)點接收到DHCP Offer報文后將所述第一ID作為第二ID后，通過DHCP Request報文廣播出去；主控制器在所述第二ID與第一ID一致的情況下，將所述第二ID作為第三ID并通過DHCP Ack報文廣播出去；最后設(shè)備節(jié)點在判斷所述第三ID與第二ID一致的情況下，將所述第三ID確定為最終的ID。這樣，實現(xiàn)了控制器局域網(wǎng)絡(luò)可以自動地對接入的設(shè)備分配ID，實現(xiàn)了提高分配ID的效率，并且由于無需人工分配ID，相應(yīng)地也降低了運(yùn)營成本。

上述裝置中各個單元的功能和作用的實現(xiàn)過程具體詳見上述方法中對應(yīng)步驟的實現(xiàn)過程，在此不再贅述。

對于裝置實施例而言，由于其基本對應(yīng)于方法實施例，所以相關(guān)之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本申請方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。

本領(lǐng)域技術(shù)人員在考慮說明書及實踐這里公開的發(fā)明后，將容易想到本申請的其它實施方案。本申請旨在涵蓋本申請的任何變型、用途或者適應(yīng)性變化，這些變型、用途或者適應(yīng)性變化遵循本申請的一般性原理并包括本申請未公開的本技術(shù)領(lǐng)域中的公知常識或慣用技術(shù)手段。說明書和實施例僅被視為示例性的，本申請的真正范圍和精神由下面的權(quán)利要求指出。

應(yīng)當(dāng)理解的是，本申請并不局限于上面已經(jīng)描述并在附圖中示出的精確結(jié)構(gòu)，并且可以在不脫離其范圍進(jìn)行各種修改和改變。本申請的范圍僅由所附的權(quán)利要求來限制。