本公開涉及用于實現(xiàn)能夠執(zhí)行所提出的方法的機器設(shè)備、網(wǎng)關(guān)和管理器設(shè)備的管理的方法和裝置。

背景技術(shù)：

約束應(yīng)用協(xié)議(CoAP)是被設(shè)計用于處理受限節(jié)點和受限網(wǎng)絡(luò)中的機器對機器(M2M)應(yīng)用的專用web傳送協(xié)議。CoAP在端點之間提供基于請求響應(yīng)的架構(gòu)，其中通過用戶數(shù)據(jù)報協(xié)議(UDP)在通常被分別稱為CoAP服務(wù)器和CoAP客戶端的實體之間執(zhí)行通信。

CoAP被設(shè)計為易于與超文本傳送防議(HTTP)一起工作，以與當(dāng)前Web集成，同時增加附加的特征(諸如例如組播支持、非常低的開銷和針對約束環(huán)境的簡化性)?？梢栽趆ttp：//tools.ietf.org/html/draft-ietf-core-coap-18上找到關(guān)于CoAP的更多信息。

CoAP的一個可用擴展使得CoAP客戶端能夠觀察來自CoAP服務(wù)器的可用資源，或者換句話說，允許CoAP服務(wù)器將可用資源通知給CoAP客戶端，如可以在http：//tools.ietf.org/html/draft-ietf-core-observe-12中看到的。這使得能夠在使用CoAP的受限網(wǎng)絡(luò)中進行服務(wù)器發(fā)起的通信。

開放移動聯(lián)盟設(shè)備管理輕量級(OMA DM LW)是為M2M網(wǎng)絡(luò)而開發(fā)的輕而緊湊的設(shè)備管理協(xié)議，其包括用于實現(xiàn)LWM2M的設(shè)備的設(shè)備管理和服務(wù)實現(xiàn)，如在Lightweight Machine to Machine Technical Specification，Candidate Version 1.0-10 Dec.2013，OMA-TS-LightweightM2M-V1_0-20131210-C，5.1-5.4節(jié)中描述的。設(shè)計用于受限網(wǎng)絡(luò)，OMA DM LW可以在UDP和SMS綁定兩者上運行。這使得OMA DM LW能夠適用于使用CoAP的任何類型的受限設(shè)備或網(wǎng)絡(luò)。

類似于CoAP，OMA DM LW的架構(gòu)是基于客戶端-服務(wù)器模型(包括LWM2M服務(wù)器和LWM2M客戶端兩者)的。然而，在OMA DM LW中，LWM2M客戶端在將被控制的受限設(shè)備中運行，而LWM2M服務(wù)器表示具有某種管理能力的節(jié)點，其可以是網(wǎng)關(guān)(GW)或網(wǎng)絡(luò)節(jié)點。對于典型的物聯(lián)網(wǎng)(IoT)場景，具有多個客戶端、一些服務(wù)器以及充當(dāng)中繼或代理的一些節(jié)點將是常見的，其中這些節(jié)點中的每個節(jié)點包括客戶端和服務(wù)器側(cè)兩者。事實上，非常像CoAP，服務(wù)器和客戶端之間的前沿可能是模糊的，因為所有的LWM2M客戶端最可能也是CoAP服務(wù)器，并且大多數(shù)LWM2M服務(wù)器也應(yīng)當(dāng)是CoAP客戶端。

OMA DM LW引入了用于管理的簡單的基于對象的資源模型，其從CoAP繼承以在LWM2M服務(wù)器和LWM2M客戶端之間使用。在這個模型中，LWM2M客戶端提供的每條信息都是資源，并且資源在邏輯上被組織為對象。因此，對象定義了資源的分組，例如，對象ID3“設(shè)備”包含用于設(shè)備相關(guān)信息的所有資源。

OMA DM LW為訪問對象提供若干接口，其中“信息報告”被提供用于錯誤報告。該接口允許LWM2M服務(wù)器觀察資源并且每當(dāng)在網(wǎng)絡(luò)中發(fā)生改變時被通知(基本遵循發(fā)布/訂閱范例)。

現(xiàn)有的管理解決方案通常由以下實體組成：

·機器設(shè)備(MD)：設(shè)備(可以是受限設(shè)備)包括一個或多個傳感器和/或致動器，其中設(shè)備運行一些管理代理(在本文LWM2M協(xié)議用于此目的)，管理代理必須提供關(guān)于傳感器正在感測什么的信息以及報告管理錯誤和其它相關(guān)問題。傳感器還可以運行常規(guī)CoAP服務(wù)器以為用戶提供對讀數(shù)的訪問。

·管理器設(shè)備：運行管理應(yīng)用的實體，管理應(yīng)用負責(zé)發(fā)送命令、更新固件和MD的其它對象。在實際部署中，管理器設(shè)備還可以包含LWM2M服務(wù)器。

·網(wǎng)關(guān)(GW)：在MD是自身不能夠提供足夠的互聯(lián)網(wǎng)連接的受限設(shè)備的情況下，在代理和管理器設(shè)備之間布置該實體。GW向其MD運行資源目錄(RD)并且可能運行接收的消息的緩存(例如諸如鏡像代理(MP))。GW還向管理器設(shè)備運行一些管理協(xié)議(在該示例中為LWM2M)。在每個MD的注冊過程(通常在引導(dǎo)MD時被執(zhí)行)期間，MD注冊到GW中的RD。

·用戶：最終用戶，其能夠經(jīng)由包括CoAP客戶端的通信設(shè)備請求和接收MD的最新測量。

通常存在可以在MD的傳感器上完成的多個管理操作(例如諸如更新固件、改變訪問控制策略、改變安全設(shè)置和設(shè)置報警)。在LWM2M中，在每個設(shè)備中存在特定的對象以表示這種類型的信息。該特征繼承自CoAP對象和資源；事實上，LWM2M在工作方式上與CoAP幾乎相同。該管理器可以使用GET消息或PUT消息來獲取或存儲關(guān)于這些對象中的任何對象的信息并且通過使用Observe命令來設(shè)置通知。

管理器設(shè)備需要用于管理MD的另一個功能是要知道MD是否被連接。這對于大型IoT部署尤其如此。然而，僅僅為了跟蹤各種設(shè)備的一般狀態(tài)通常需要向管理器設(shè)備的大量消息開銷。

盡管事實上CoAP協(xié)議和LWM2M協(xié)議兩者極其相似，但是它們當(dāng)前不能夠彼此進行通信。管理對象僅僅用于管理目的，而數(shù)據(jù)平面對象或資源僅僅用于數(shù)據(jù)或用戶平面信息。換言之，當(dāng)測量信息被提供到CoAP客戶端時，管理報告被提供給LWM2M服務(wù)器，這不是理想的情況。更具體地，LWM2M在CoAP上運行，其中CoAP定義了多個消息和實體(例如諸如RD和/或MP)以促進與用戶的通信。利用其它協(xié)議(例如諸如HTTP或簡單網(wǎng)絡(luò)管理協(xié)議(SNMP))，通常可以在數(shù)據(jù)平面和控制平面之間具有明確的區(qū)分，但是利用CoAP和LWM2M，使用CoAP來封裝所有消息。

這將通常意味著使用CoAP的所有實體將知道彼此，并且將優(yōu)化協(xié)議以發(fā)送盡可能少的消息。然而這里不是如此。

通常，CoAP消息將用于數(shù)據(jù)平面(例如用于獲得傳感器讀數(shù)或資源發(fā)現(xiàn))，而LWM2M用于管理命令(例如諸如錯誤報告)。這兩種類型的消息/命令將作為MD中的不同進程(即，分別作為用戶進程和管理器進程)運行。

這意味著將存在大量的消息重疊和消息開銷。MD被喚醒的事實將例如被通告兩次，一次針對用戶以及一次針對管理器設(shè)備。

當(dāng)使用標(biāo)準(zhǔn)LWM2M時，管理器設(shè)備可以設(shè)置當(dāng)特定的MD被喚醒時將被接收的通知。管理器設(shè)備還可以輪詢MD中的對象以獲知其是否被連接。然而，這是非常低效率的過程，因為每個MD每次醒來時必須發(fā)送一個消息，表示它是醒著的，以及因此，在每次這種情況下，管理器設(shè)備將針對每個設(shè)備接收一個額外的消息。這顯然帶來可擴展性問題，因為隨著部署的MD的數(shù)量的增加，將需要部署專用機器以聚合和處理管理信息。也不難得到，在將來管理消息將獲得與數(shù)據(jù)消息一樣大，其將甚至進一步增加所有相關(guān)實體的工作量。

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

本文的目的是解決或至少減輕以上描述的問題中的至少一些問題。

根據(jù)一個方面，提出了一種在網(wǎng)關(guān)上可執(zhí)行的方法，所述網(wǎng)關(guān)能夠與機器設(shè)備、用戶設(shè)備和管理器設(shè)備進行通信。所提出的方法包括：從所述管理器設(shè)備接收請求與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息的第一請求；確定在哪些條件下獲取所請求的狀態(tài)信息，并向所述管理器設(shè)備發(fā)送所獲取的狀態(tài)信息；基于對請求與所述機器設(shè)備相關(guān)聯(lián)的更新的數(shù)據(jù)的第二請求的響應(yīng)，確定所述機器設(shè)備的相關(guān)狀態(tài)信息，所述第二請求是從使用的設(shè)備提供給所述機器設(shè)備的，以及所述響應(yīng)是由所述網(wǎng)關(guān)從所述機器設(shè)備接收的，以及將包括所確定的狀態(tài)信息的通知提供給所述管理器設(shè)備。

所提出的方法的一個優(yōu)點在于，可以利用已經(jīng)由機器設(shè)備應(yīng)用于更新用戶設(shè)備，還用于獲得對機器設(shè)備的當(dāng)前狀態(tài)的更新的目的的常規(guī)狀態(tài)更新，由此減少獲得上述信息所需的信令的總量。

根據(jù)一個實施例，在確定相關(guān)狀態(tài)之前向機器設(shè)備轉(zhuǎn)發(fā)第一請求。

在狀態(tài)報告要有時間限制的情況下，則可以應(yīng)用定時器，其中以上所述的方法還包括以下步驟：在向所述機器設(shè)備轉(zhuǎn)發(fā)所述第二請求時啟動定時器，以及基于以下來確定相關(guān)狀態(tài)信息：在所述定時器超時之前接收到對所述第二請求的響應(yīng)的情況下，所述響應(yīng)的內(nèi)容，或者在所啟動的定時器超時之前沒有接收到所述響應(yīng)的情況下，所述網(wǎng)關(guān)已經(jīng)知道的狀態(tài)信息。

根據(jù)一個實施例，獲取所請求的狀態(tài)信息的條件是從所述管理器設(shè)備提供給所述網(wǎng)關(guān)的。

一旦在對第二請求的響應(yīng)中已經(jīng)接收到狀態(tài)信息，則它可以根據(jù)一個實施例存儲在網(wǎng)關(guān)上或?qū)W(wǎng)關(guān)是可訪問的。

根據(jù)另一個方面，提出了一種計算機程序，包括當(dāng)運行在計算機上時使得計算機執(zhí)行根據(jù)以上描述的實施例中的任何一個實施例的方法的代碼裝置。

根據(jù)又一方面，提出了一種計算機程序產(chǎn)品，包括計算機可讀代碼裝置和如上所述的計算機程序，并且所述計算機程序存儲在所述計算機可讀代碼裝置上。

根據(jù)另一個方面，提供了一種在管理器設(shè)備上可執(zhí)行的方法，所述管理器設(shè)備能夠經(jīng)由網(wǎng)關(guān)與機器設(shè)備進行通信。所述方法包括：向所述網(wǎng)關(guān)發(fā)送第一請求，所述第一請求請求所述網(wǎng)關(guān)基于對第二請求的響應(yīng)的內(nèi)容提供與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息，所述第二請求用于請求與所述機器設(shè)備相關(guān)聯(lián)的更新的數(shù)據(jù)，所述第二請求是從使用的設(shè)備提供給所述機器設(shè)備的，并且所述響應(yīng)是由所述網(wǎng)關(guān)從所述機器設(shè)備接收的，以及從所述網(wǎng)關(guān)接收包括所請求的狀態(tài)信息的通知。

根據(jù)一個實施例，第一請求還包括向所述網(wǎng)關(guān)指示所述網(wǎng)關(guān)在哪些條件下要獲取所請求的狀態(tài)信息的指令。

更具體地，指令可以被配置為指示網(wǎng)關(guān)在從所述機器設(shè)備接收到響應(yīng)的情況下，從所述響應(yīng)獲取所請求的狀態(tài)信息，或在未接收到所述響應(yīng)的情況下，從所述網(wǎng)關(guān)的存儲器獲取與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息。

根據(jù)另一個方面，提出了一種計算機程序，包括當(dāng)運行在計算機上時使得計算機執(zhí)行根據(jù)在管理器設(shè)備上可執(zhí)行的方法的實施例中的任何一個實施例的方法的代碼裝置。

根據(jù)又一方面，提出了一種計算機程序產(chǎn)品，包括計算機可讀代碼裝置和如上所述的計算機程序，并且所述計算機程序存儲在所述計算機可讀代碼裝置上。

根據(jù)另一個方面，提出了一種能夠與機器設(shè)備、用戶設(shè)備和管理器設(shè)備進行通信的網(wǎng)關(guān)，其中所述網(wǎng)關(guān)包括用于執(zhí)行以下操作的裝置：從所述管理器設(shè)備接收請求與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息的第一請求；確定在哪些條件下獲取所請求的狀態(tài)信息，并向所述管理器設(shè)備發(fā)送所獲取的狀態(tài)信息；基于對請求與所述機器設(shè)備相關(guān)聯(lián)的更新的數(shù)據(jù)的第二請求的響應(yīng)的內(nèi)容，確定所述機器設(shè)備的相關(guān)狀態(tài)信息，所述第二請求是從使用的設(shè)備提供給所述機器設(shè)備的，以及所述響應(yīng)是由所述網(wǎng)關(guān)從所述機器設(shè)備接收的，以及將包括所確定的狀態(tài)信息的通知提供給所述管理器設(shè)備。

網(wǎng)關(guān)還包括用于向所述機器設(shè)備轉(zhuǎn)發(fā)所述第一請求的裝置。

在網(wǎng)關(guān)將時限應(yīng)用于向管理器設(shè)備報告狀態(tài)的情況下，以上提出的方法還包括用于執(zhí)行以下操作的裝置：在向所述機器設(shè)備轉(zhuǎn)發(fā)所述第二請求時啟動定時器，以及基于以下來確定相關(guān)狀態(tài)信息：在所述定時器超時之前接收到對所述第二請求的響應(yīng)的情況下，所述響應(yīng)的內(nèi)容，或者在所啟動的定時器超時之前沒有接收到所述響應(yīng)的情況下，所述網(wǎng)關(guān)已經(jīng)知道的狀態(tài)信息。

通常，網(wǎng)關(guān)還包括用于存儲在對第二請求的響應(yīng)中接收的狀態(tài)信息的裝置。

根據(jù)又一方面，提出了一種能夠與機器設(shè)備、用戶設(shè)備和管理器設(shè)備進行通信的網(wǎng)關(guān)。網(wǎng)關(guān)包括處理器和存儲器，其中存儲器包括指令，當(dāng)由處理器執(zhí)行時使得網(wǎng)關(guān)執(zhí)行以下動作：從所述管理器設(shè)備接收請求與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息的第一請求；確定在哪些條件下獲取所請求的狀態(tài)信息，并向所述管理器設(shè)備發(fā)送所獲取的狀態(tài)信息；基于對請求與所述機器設(shè)備相關(guān)聯(lián)的更新的數(shù)據(jù)的第二請求的響應(yīng)的內(nèi)容，確定所述機器設(shè)備的相關(guān)狀態(tài)信息，所述第二請求是從用戶設(shè)備提供給所述機器設(shè)備的，以及所述響應(yīng)是由所述網(wǎng)關(guān)從所述機器設(shè)備接收的，以及將包括所確定的狀態(tài)信息的通知提供給所述管理器設(shè)備。

根據(jù)另一個方面，提出了能夠與機器設(shè)備和網(wǎng)關(guān)進行通信的管理器設(shè)備。管理器設(shè)備包括用于執(zhí)行以下操作的裝置：向所述網(wǎng)關(guān)發(fā)送第一請求，所述第一請求請求所述網(wǎng)關(guān)基于對第二請求的響應(yīng)的內(nèi)容提供與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息，所述第二請求用于請求與所述機器設(shè)備相關(guān)聯(lián)的更新的數(shù)據(jù)，所述第二請求是從使用的設(shè)備提供給所述機器設(shè)備的，并且所述響應(yīng)是由所述網(wǎng)關(guān)從所述機器設(shè)備接收的，以及從所述網(wǎng)關(guān)接收包括所請求的狀態(tài)信息的通知。

根據(jù)一個實施例，所提出的裝置將向所述網(wǎng)關(guān)指示所述網(wǎng)關(guān)在哪些條件下要獲取所請求的狀態(tài)信息的指令包括在第一請求中。

所提出的裝置可以被配置為將指令提供到網(wǎng)關(guān)，在從所述機器設(shè)備接收到響應(yīng)的情況下，從所述響應(yīng)獲取所請求的狀態(tài)信息，或在未接收到所述響應(yīng)的情況下，從所述網(wǎng)關(guān)的存儲器獲取與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息。

根據(jù)另一個方面，提出了能夠與機器設(shè)備和網(wǎng)關(guān)進行通信的管理器設(shè)備。管理器設(shè)備包括處理器和存儲器，其中存儲器包括指令，其當(dāng)由處理器執(zhí)行時使得管理器設(shè)備執(zhí)行以下操作：向所述網(wǎng)關(guān)發(fā)送第一請求，所述第一請求請求所述網(wǎng)關(guān)基于對第二請求的響應(yīng)的內(nèi)容提供與所述機器設(shè)備相關(guān)聯(lián)的狀態(tài)信息，所述第二請求用于請求與所述機器設(shè)備相關(guān)聯(lián)的更新的數(shù)據(jù)，所述第二請求是從使用的設(shè)備提供給所述機器設(shè)備的，并且所述響應(yīng)是由所述網(wǎng)關(guān)從所述機器設(shè)備接收的，以及從所述網(wǎng)關(guān)接收包括所請求的狀態(tài)信息的通知。

附圖說明

現(xiàn)在將關(guān)于附圖來更詳細地描述實施例，在附圖中：

圖1是示出了用戶和管理器設(shè)備如何可以經(jīng)由網(wǎng)關(guān)從機器設(shè)備獲取信息的信令方案。

圖2是示出了在機器設(shè)備中執(zhí)行的用于處理源自用戶設(shè)備的請求的方法的流程圖。

圖3是示出了在網(wǎng)關(guān)中執(zhí)行的用于處理源自用戶設(shè)備的請求和用于基于所述請求來更新管理器設(shè)備的方法的流程圖。

圖4是示出了能夠執(zhí)行圖2的方法的根據(jù)第一實施例的機器設(shè)備的框圖。

圖5是示出了能夠執(zhí)行圖2的方法的根據(jù)第二實施例的機器設(shè)備的框圖。

圖6是示出了能夠執(zhí)行圖3的方法的根據(jù)第一實施例的網(wǎng)關(guān)的框圖。

圖7是示出了能夠執(zhí)行圖3的方法的根據(jù)第二實施例的網(wǎng)關(guān)的框圖。

圖8是示出了在管理器設(shè)備中可執(zhí)行的用于提供機器設(shè)備狀態(tài)更新的方法的流程圖。

圖9是示出了能夠執(zhí)行圖8的方法的根據(jù)第一實施例的管理器設(shè)備的框圖。

圖10是示出了能夠執(zhí)行圖8的方法的根據(jù)第二實施例的管理器設(shè)備的框圖。

具體實施方式

提出了一種簡要描述的可以被稱為周期性管理穩(wěn)定化過程的方法，用于優(yōu)化將被分布在管理器設(shè)備和在機器設(shè)備或M2M設(shè)備(其通常是受限設(shè)備)中可操作的代理之間的消息的處理。公開的過程可以使用并且利用已經(jīng)使用的數(shù)據(jù)平面消息(本文被稱為CoAP消息)上的搭載，以便獲取關(guān)于代理是否是醒著的信息，或知道其它狀態(tài)信息，其可以從接收的COAP消息中進行解釋得到。

現(xiàn)在，MD將通常被布置于自身包含RD的GW之后，因為配置為受限設(shè)備的大多數(shù)MD自身不具有朝向因特網(wǎng)的任何蜂窩或其它連接功能。每當(dāng)GW接收經(jīng)由GW向MD發(fā)送的CoAP觀察消息(其可以不同于LWM2M觀察)時，GW將嘗試輪詢MD的所請求的資源。如果MD是休眠的，則GW將嘗試訪問緩存的數(shù)據(jù)(例如通過將請求轉(zhuǎn)發(fā)到鏡像代理(MP))，之后用戶將從MP獲得最新緩存的讀數(shù)。

為了避免這種類型的輪詢，這里充當(dāng)CoAP客戶端的用戶將能夠觀察傳感器資源并且當(dāng)觀察的傳感器資源改變時獲得通知，例如以下在http：//tools.ietf.org/html/draft-ieft-core-observe-12中給出的因特網(wǎng)工程任務(wù)組(IETF)示例：

對于具有附接的溫度傳感器的CoAP服務(wù)器，服務(wù)器可以揭露參數(shù)化資源：

<coap：//server/temperature/critical？above＝45>，如果溫度超出指定的值(本文為45℃)，則將其狀態(tài)改變?yōu)楫?dāng)前溫度，以及當(dāng)溫度下降到低于該閾值時，則將其狀態(tài)改變?yōu)椤癘K”；

在以上描述的場景中，當(dāng)MD的資源的當(dāng)前狀態(tài)改變時，CoAP服務(wù)器將通知CoAP客戶端關(guān)于MD的資源的當(dāng)前狀態(tài)。因為通常情況下MD布置在某個GW之后，所以該GW將該改變轉(zhuǎn)發(fā)給用戶。根據(jù)觀察選項規(guī)范，以上提到的觀察的對象可以直接可替代地是GW。

作為對以上提到的過程的替代，本文提出了一種方法，其中GW還默認產(chǎn)生要被發(fā)送到管理器設(shè)備的新的LWM2M通知消息，目的是提醒管理器設(shè)備：MD(其包括至少一個傳感器)現(xiàn)在是醒著的。默認情況下，GW不知道從CoAP服務(wù)器提供到CoAP客戶端的消息的內(nèi)容；然而盡管可能加密，但是管理器設(shè)備可以知道MD的CoAP服務(wù)器生成至少一個消息并且它因此當(dāng)前是醒著的。根據(jù)替代實施例，可以周期性地生成要發(fā)送到管理器設(shè)備的通知(聚合GW/RD下的多個資源)。

現(xiàn)在將參考圖1來更詳細描述以上提出的方法，其描述了配置為處理多個機器設(shè)備(每個包括傳感器和/或致動器中的一個或多個)、CoAP服務(wù)器和LWM2M客戶端的網(wǎng)絡(luò)，其中為了簡單起見，這些機器設(shè)備(MD)中的僅僅一個(即：正在改變狀態(tài)的MD 400；500)是特別感興趣的，并且因此在圖中示出。圖1還示出了一個本文稱為用戶設(shè)備800的通信設(shè)備，包括CoAP客戶端801，其能夠經(jīng)由包括CoAP資源目錄(RD)601和CoAP鏡像代理(MP)602的位于中間的網(wǎng)關(guān)(GW)600；700獲取關(guān)于MD的更新。此外，包括CoAP服務(wù)器901的管理器設(shè)備900；1000正在發(fā)起所描述的過程。在本布置中，雖然關(guān)于MD 400；500的傳感器/致動器輸出來更新用戶設(shè)備800，但是關(guān)于MD 400；500的狀態(tài)來更新管理器設(shè)備900；1000。

如在圖1中所示，在MD 400；500的引導(dǎo)期間，管理器設(shè)備900；1000通過將創(chuàng)建消息發(fā)送到GW 600；700來在GW 600；700中創(chuàng)建新對象(Status_Object)，如以第一步驟1:10指示的。可選地，該消息還可以包含關(guān)于如何(即，在哪些條件下)聚合來自MD 400；500的通知(例如PDU的大小、最大增量(Delta)等)的對GW 600；700的指令。在后者情況下，可以應(yīng)用特定的延遲時間以便收集更多的通知以進行聚合。在創(chuàng)建響應(yīng)消息中，GW 600；700將包括新對象的位置和MD 400；500的現(xiàn)有狀態(tài)信息。在本示例中，一系列MD已經(jīng)在RD(注意：在LWM2M中的注冊期間，LWM2M客戶端被假定在RD下創(chuàng)建每個設(shè)備的條目)及其相應(yīng)的URN中注冊。該創(chuàng)建響應(yīng)消息被指示為步驟1:20。在給定的示例中，現(xiàn)有三個MD的RD位置是[/jlks78，/83njf，/jfhl9]，其URN為例如[91058，260890，210995]以及其當(dāng)前狀態(tài)為[0，0，0])，其中當(dāng)前狀態(tài)“0”指示MD為關(guān)閉，而設(shè)置為“1”的狀態(tài)指示相應(yīng)的MD為開啟。顯然，在給定的示例中，所有三個MD都是初始關(guān)閉的。

一旦已經(jīng)在GW 600；700中創(chuàng)建了上述對象，則管理器設(shè)備900；1000將觀察Status_Object，如在第三步驟1:30中指示的。在給定的示例中，這意味著該消息指示GW 600,700：在將另一個通知發(fā)送給管理器設(shè)備900；1000之前，其將等待至少最小時間間隔(例如10秒)，并且絕不超過最大時間間隔(例如120秒)，即：即使在確定的最大時間間隔內(nèi)沒有MD改變，也將在該時間間隔之后將通知從GW 600；700發(fā)送給管理器設(shè)備900；1000。應(yīng)用提出的時間間隔以便至少每120秒保持在管理器設(shè)備900；1000上的最新狀態(tài)信息，以及使得管理器設(shè)備900；1000仍然恰好地獲得狀態(tài)更新。在這一點上，每當(dāng)在由MD表示的資源中的任何一個資源中存在修改時(即，當(dāng)MD 400；500通過發(fā)送CoAP消息來回復(fù)CoAP數(shù)據(jù)請求時)，GW 400；500應(yīng)當(dāng)用作為LWM2M消息提供的通知來通知管理器設(shè)備900；1000。

在給定的示例中，運行CoAP客戶端的用戶設(shè)備800向GW600；700發(fā)出GET請求，在本文中以便從MD 400；500獲得最新的溫度測量結(jié)果，如以步驟1:40所指示的：

coap：//temp1.92738.room1.example.com/temperature。

在這種情況下RD和MP兩者共同位于GW 600；700中，所以發(fā)現(xiàn)是立即的。GW 600；700簡單地將請求轉(zhuǎn)發(fā)到MD 400；500，如以步驟1:50所指示的。MD 400；500接收由GW 600；700在步驟1:50中發(fā)送的GET請求，并且在可確認的響應(yīng)上搭載具有請求的溫度信息的有效載荷，如以步驟1:60所指示的，并且在另一個步驟1:70中將該信息發(fā)送到GW 600；700。GW 600；700將該信息轉(zhuǎn)發(fā)到用戶設(shè)備800，如在另一個步驟1:80中所指示的。GW 600；700將不能夠讀取從MD中的任何一個MD提供的有效載荷的內(nèi)容，因為通常這樣的內(nèi)容將被加密，但是GW 600；700將在任何情況下能夠確定步驟1:70的消息實際上是從特定的MD 400；500接收的，并且因此，僅根據(jù)該信息，GW 600；700能夠確定該機器設(shè)備400；500現(xiàn)在是醒著的。GW 600；700將在下一個步驟1:90改變在Status_Object中的MD 400；500狀態(tài)，因為管理器設(shè)備400；500先前在該對象中設(shè)置了觀察，如以上以步驟1:30所指示的。GW 600；700然后在另一個消息1:100的有效載荷中將MD 400；500新發(fā)現(xiàn)的醒著狀態(tài)通知管理器設(shè)備400；500，而其它參數(shù)(即RD位置和URN)保持相同(即不變)。

同時，通過在步驟1:50中轉(zhuǎn)發(fā)請求，GW可以啟動定時器，并且在本示例中，在120秒內(nèi)沒有接收到響應(yīng)的情況下，與在步驟1:100中發(fā)送的消息相對應(yīng)的響應(yīng)將發(fā)送到管理器設(shè)備900；1000，然而這次指示MD 400；500不是醒著的。在后者情況下，沒有與步驟1:80相對應(yīng)的消息將被發(fā)送到用戶設(shè)備800，因為僅當(dāng)從MD 400；500實際接收到更新時才通知用戶設(shè)備800?？商娲兀卺槍ο蚬芾砥髟O(shè)備900；1000報告沒有設(shè)置任何最大時間的情況下，不存在來自MD 400；500的響應(yīng)(即，任何步驟1:70響應(yīng))，簡單地導(dǎo)致沒有消息從GW 600；700提供到管理器設(shè)備900；1000。

總而言之，在數(shù)據(jù)平面中的任何改變(即：在傳感器的輸出中的更新(使用平面更新))將提供給用戶設(shè)備(CoAP消息)和管理器設(shè)備(LWM2M消息)兩者，而管理更新(本文通常為MD的狀態(tài)更新)將僅僅由GW提供給管理器設(shè)備。

以上論述的方法提議使用Status_Object來以壓縮方式從MD獲得狀態(tài)信息。這可以容易地在LWM2M規(guī)范的基礎(chǔ)上實現(xiàn)，因為我們僅需要創(chuàng)建新的對象并相應(yīng)地設(shè)置基本配置參數(shù)。

公開的方法還更好地使用CoAP和LWM2M的共同點以及它們兩者均使用的實體。

所公開的方法增強了管理可擴展性，因為針對每個RD/GW它需要1個創(chuàng)建消息+1個觀察消息，并且需要周期性發(fā)起的通知的數(shù)量限于類似數(shù)量的通知，而不管網(wǎng)絡(luò)是包括1個MD還是100個MD(MD被布置在GW之后)。相反，在當(dāng)前的LWM2M規(guī)范中，管理意味著在每個LWM2M客戶端中設(shè)置特定的對象并且需要在GW或其它網(wǎng)絡(luò)實體中的聚合機制，它還需要在受限設(shè)備上更多的計算和消息收發(fā)。更具體地，在通常已知的場景中，LWM2M服務(wù)器將必須在每個相應(yīng)的MD本身中寫入觀察，指示它每次它醒來時通知LWM2M服務(wù)器。因為MD通常是功率受限設(shè)備，所以期望需要從這些實體發(fā)送的消息的數(shù)量的減少。當(dāng)應(yīng)用如以上提出的方法時這將不是必要的。

此外，通過聚合從GW發(fā)送到管理器設(shè)備的報告，可以甚至進一步減少需要的信令。

當(dāng)MD向CoAP客戶端發(fā)送CoAP響應(yīng)時，它將同時產(chǎn)生將提供到管理器設(shè)備的通知，而不是僅僅一個單個消息。

所提出的方法以恰好的方式使GW實時知道MD是否是醒著的，而不必在相應(yīng)的LWM2M客戶端中設(shè)置任何特定的信息。還可以獲取該信息，而不管在MD和用戶之間使用的任何加密，即：可以獲取所需的信息而不需要消息的任何解密，而是簡單地通過這樣接收它。

圖2是當(dāng)在MD執(zhí)行時的以上所述的方法的流程圖，其中，在第一步驟2:10中，MD接收從用戶設(shè)備經(jīng)由網(wǎng)關(guān)提供的請求資源(這里為MD)的觀察的請求。MD以常規(guī)方式處理請求(例如通過提供來自一個或多個傳感器的新的結(jié)果，通過附接(通常通過將這樣的內(nèi)容搭載在可確認的常規(guī)響應(yīng)上))，如以步驟2:20所指示的，并且將響應(yīng)發(fā)送到GW以在那里進行進一步處理。

圖3是示出了在GW執(zhí)行的相應(yīng)的方法的另一個流程圖。在第一步驟3:10中，由管理器設(shè)備發(fā)起并且從管理器設(shè)備接收監(jiān)視一個或多個MD的狀態(tài)的請求。在下一個步驟3:20中，通過確定或協(xié)商在哪些條件下將執(zhí)行MD的監(jiān)視來完成在步驟3:10發(fā)起的過程。在步驟3:20中已經(jīng)解決了用于獲得狀態(tài)更新的最大時限的情況下，一旦在步驟3:20中已經(jīng)解決了條件，則可以啟動定時器，如以可選的步驟3:30指示的。只要還未達到這樣的時限，過程就在步驟3:40繼續(xù)，其中檢查是否已經(jīng)接收到來自的用戶的用于從至少一個MD獲得更新的輸出的請求。一旦確定已經(jīng)接收到請求，則向相應(yīng)的MD路由這樣的請求，如在下一個步驟3:50中所指示的。一旦在步驟3:50中已經(jīng)轉(zhuǎn)發(fā)請求，如果當(dāng)?shù)却憫?yīng)時將應(yīng)用時限(如在步驟3:60中所指示的)，以確定GW應(yīng)當(dāng)?shù)却齺碜訫D的響應(yīng)多長時間(如在以下的步驟3:70中所指示的)，則通常啟動另一個定時器。一旦從MD接收到響應(yīng)，則GW更新MD狀態(tài)，如在步驟3:80中所指示的，并且將響應(yīng)轉(zhuǎn)發(fā)到用戶設(shè)備，如以步驟3:90所指示的。在下一個步驟3:100中，將MD的當(dāng)前狀態(tài)發(fā)送到管理器設(shè)備。如在圖3中所指示的，在步驟3:30的定時器到期的情況下，還執(zhí)行當(dāng)前狀態(tài)到管理器設(shè)備的發(fā)送。顯然，在從MD接收到響應(yīng)的情況下，狀態(tài)將被設(shè)置為“On”，而在沒有響應(yīng)的情況下，狀態(tài)將被設(shè)置為“Off”。如果在步驟3:70中沒有接收到響應(yīng)，則同樣適用。如已經(jīng)提到的，步驟3:100可以配置為推遲預(yù)定的時間間隔，例如在將執(zhí)行來自多個MD的結(jié)果的聚合的情況下。一旦更新已經(jīng)提供給管理器設(shè)備，如果將應(yīng)用這樣的定時器，則過程從步驟3:30重復(fù)(通過再次初始啟動定時器)，但是在任何情況下，通過等待來自用戶設(shè)備的另一個請求來繼續(xù)該過程。

圖4示出了MD或MD的至少一部分的一個可能的配置，MD或MD的至少一部分能夠執(zhí)行方法，例如以上參考圖2描述的方法。更具體地，圖4的MD 400包括至少一個處理器410，其能夠執(zhí)行存儲在存儲器420中的指令430或代碼，使得當(dāng)執(zhí)行指令430或代碼時執(zhí)行以上提到的方法。MD 400還包括通信接口440，其配置為基于MD 400和GW 600之間的任何類型的已知的通信標(biāo)準(zhǔn)來實現(xiàn)無線或固定通信。可替代地，通信接口440配置為經(jīng)由中間節(jié)點實現(xiàn)MD 400和GW 600；700之間的通信，這不在本文的范圍之內(nèi)。根據(jù)一個實施例，存儲器420和指令430可以被包括在計算機產(chǎn)品450中，其可以例如是可移動固態(tài)存儲器(例如閃存存儲器，例如諸如光盤，例如諸如致密盤(CD)或數(shù)字多功能盤(DVD)或藍光盤或通用串行總線(USB)驅(qū)動器)或適于附接或插入MD上的任何其它類型的存儲器裝置。

根據(jù)另一個實施例，MD 500被配置為包括通信接口510(其可以與圖4的通信接口440相對應(yīng))、存儲器520(其可以與圖4的存儲器420相對應(yīng))以及功能模塊(其可以被配置為軟件模塊、硬件模塊或兩者的組合)。這里，模塊通過通信模塊530和響應(yīng)模塊540來表示，通信模塊530被配置為執(zhí)行圖2的步驟2:10和2:30，響應(yīng)模塊540被配置為執(zhí)行圖2的步驟2:20。MD 500還包括CoAP服務(wù)器550和LWM2M客戶端560，它們中的每個能夠分別與其它相應(yīng)的客戶端和服務(wù)器進行通信，如本文所述的。更具體地，根據(jù)以上提出的實施例中的任何實施例，MD被配置為識別從GW接收的請求并且如以上提出的對這樣的請求作出響應(yīng)，使得網(wǎng)絡(luò)節(jié)點(包括GW)和包括管理功能的網(wǎng)絡(luò)節(jié)點(本文稱為管理器設(shè)備)可以知道MD是否開啟。

圖6示出了GW或包括GW功能的另一個網(wǎng)絡(luò)節(jié)點(其能夠執(zhí)行方法，例如以上參考圖3描述的方法)的一個可能的配置。更具體地，圖6的GW 600包括至少一個處理器610，其能夠執(zhí)行存儲在存儲器620中的指令或代碼，使得當(dāng)執(zhí)行指令630或代碼時執(zhí)行以上提到的方法。GW 600還包括一個或多個通信接口(這里由通信接口640來表示)，其被配置為經(jīng)由用戶設(shè)備800和GW 600，基于GW和管理器設(shè)備900、一個或多個MD 400,500以及一個或多個用戶設(shè)備800(能夠訪問MD 400,500中的至少一個)之間的任何類型的已知的通信標(biāo)準(zhǔn)來實現(xiàn)無線或固定通信?？商娲?，通信接口640被配置為經(jīng)由一個或多個中間節(jié)點實現(xiàn)提到的節(jié)點或設(shè)備之間的通信，這不在本文的范圍之內(nèi)。根據(jù)一個實施例，存儲器620和指令630可以包括在計算機產(chǎn)品650中，其可以例如是可移動固態(tài)存儲器(例如閃存存儲器，例如諸如光盤，例如諸如致密盤(CD)或數(shù)字多功能盤(DVD)或藍光盤或通用串行總線(USB)驅(qū)動器)或適于附接或插入GW上的任何其它類型的存儲器裝置。

根據(jù)圖7中示出的另一個實施例，GW 700被配置為包括至少一個通信接口(本文通過通信接口710來表示)(其可以與圖6的通信信接口630相對應(yīng))、存儲器720(其可以與圖6的存儲器620相對應(yīng))以及功能模塊(其可以配置為軟件模塊、硬件模塊或兩者的組合)。本文通過通信模塊730(其配置為執(zhí)行圖3的步驟3:10、3:40、3:50、3:70、3:90和3:100)、確定模塊740(其配置為執(zhí)行步驟3:20)、更新模塊750(其配置為執(zhí)行步驟3:80)和定時器模塊760(其配置為執(zhí)行圖3的步驟3:30和3:60)來表示模塊。雖然在圖中未明確指示，但是GW 700還通常包括資源目錄和代理鏡像，或能夠提供將如本文描述的那樣使用的相應(yīng)的功能的模塊。更具體地，根據(jù)以上提出的實施例中的任何實施例，GW被配置為向用戶提供更新的MD數(shù)據(jù)以及，作為接收對發(fā)送給MD的請求的響應(yīng)的結(jié)果，還通過應(yīng)用與本文描述的機制相對應(yīng)的機制將MD的狀態(tài)更新提供給管理器設(shè)備。圖8是示出了在網(wǎng)絡(luò)節(jié)點上可執(zhí)行的方法的流程圖，所述網(wǎng)絡(luò)節(jié)點能夠執(zhí)行管理過程，本文稱為管理器設(shè)備。在第一步驟8:10中，管理器設(shè)備將請求發(fā)送給網(wǎng)關(guān)，將關(guān)于在哪些條件下狀態(tài)更新的指令提供給網(wǎng)關(guān)，指示機器設(shè)備的資源的狀態(tài)將提供給管理器設(shè)備。在下一個步驟8:20中，如果適當(dāng)條件適用，如已經(jīng)在上面描述的，則管理器設(shè)備從網(wǎng)關(guān)接收狀態(tài)更新，并且在下一個最后步驟8:30中，管理器設(shè)備可以更新狀態(tài)，并且如果需要，還可以經(jīng)由任何合適的呈現(xiàn)裝置將狀態(tài)呈現(xiàn)給例如操作者。該過程可以通過等待另一個狀態(tài)更新消息而繼續(xù)，直到從管理器設(shè)備提供替代指令為止。根據(jù)一個實施例，存儲器820和指令830可以包括在計算機產(chǎn)品840中，其可以例如是可移動固態(tài)存儲器(例如閃存存儲器，例如諸如光盤，例如諸如致密盤(CD)或數(shù)字多功能盤(DVD)或藍光盤或通用串行總線(USB)驅(qū)動器)或適于附接或插入在管理器設(shè)備上的任何其它類型的存儲器裝置。

圖9示出了管理器設(shè)備900或包括如以上參考圖8描述的管理功能的網(wǎng)絡(luò)節(jié)點的至少一部分的一個可能的配置。更具體地，圖9的管理器設(shè)備900包括至少一個處理器910，其能夠執(zhí)行存儲在存儲器920中的指令930或代碼，使得當(dāng)執(zhí)行指令930或代碼時執(zhí)行以上提到的方法。管理器設(shè)備900還包括通信接口940，其配置為基于管理器設(shè)備900和GW 600；700之間的任何類型的已知的通信標(biāo)準(zhǔn)來實現(xiàn)無線或固定通信?？商娲?，通信接口930配置為經(jīng)由一個或多個中間節(jié)點來實現(xiàn)管理器設(shè)備900和GW 600,700之間的通信，這不在本文的范圍之內(nèi)。根據(jù)一個實施例，存儲器920和指令930可以包括在計算機產(chǎn)品650中。

根據(jù)如在圖10中示出的另一個實施例，管理器設(shè)備1000配置為包括通信接口1010(其可以與圖9的通信接口930相對應(yīng))、存儲器1020(其可以與圖9的存儲器920相對應(yīng))和功能模塊(其可以配置為軟件模塊、硬件模塊或兩者的組合)。這里通過通信模塊1030(其配置為執(zhí)行圖8的步驟8:10和8:20)和更新模塊1040(其配置為執(zhí)行圖8的步驟8:30)來表示模塊。管理器設(shè)備1000還包括能夠經(jīng)由通信接口1010與GW進行通信的CoAP服務(wù)器1050。更具體地，根據(jù)以上提出的實施例中的任何一個實施例的管理器設(shè)備1000被配置為指示GW在哪些條件下接收狀態(tài)更新；識別從GW接收的更新以及更新狀態(tài)(如在接收的更新中指示的)。

應(yīng)當(dāng)理解的是，在本公開內(nèi)的模塊或單元的選擇以及模塊或單元的命名僅僅為了示例目的。還應(yīng)當(dāng)注意的是，在本公開中描述的模塊或單元將被視為邏輯實體，其不必配置為單獨的物理實體，但是可以可替代地配置為組合的單元或模塊(只要可以獲得所描述的功能)。

以上提到的處理器中的任何處理器可以是單個CPU(中央處理單元)，但是還可以包括兩個或多于兩個處理單元。例如，處理器可以包括通用微處理器、指令集處理器和/或相關(guān)芯片集和/或例如ASIC(專用集成電路)的專用微處理器。處理器還可以包括用于緩存目的的板存儲器。計算機程序可以通過連接到處理器的計算機程序產(chǎn)品來攜帶。計算機程序產(chǎn)品可以包括其上可以存儲計算機程序的計算機可讀介質(zhì)。例如，計算機程序產(chǎn)品可以是閃存、RAM(隨機訪問存儲器)ROM(只讀存儲器)或EEPROM。

應(yīng)當(dāng)理解的是，為了簡單起見，以上描述的每個節(jié)點或設(shè)備已經(jīng)被簡化，使得僅僅已經(jīng)添加與理解描述的技術(shù)解決方案相關(guān)的功能，而已經(jīng)省略對于理解所提出的概念不必要的其它常用功能。

還應(yīng)當(dāng)理解的是，在本公開內(nèi)的交互單元的選擇以及單元的命名僅僅為了示例目的，并且適于執(zhí)行以上描述的方法中的任何方法的節(jié)點可以以多個替代方式進行配置以便能夠執(zhí)行所提出的程序動作。

還應(yīng)當(dāng)注意的是，在本公開中描述的單元將被視為邏輯實體而不必視為單獨的物理實體。

所附權(quán)利要求的范圍不應(yīng)當(dāng)受限于如在以上給定的示例中闡述的優(yōu)選的實施例，而應(yīng)當(dāng)被給予與作為整體的描述一致的最寬的解釋。