針對資源目錄的搜索引擎優化的制作方法

搜索引擎優化是當前用于“常規”(即，非IoT)互聯網以影響web搜索引擎結果的常用方法。根據經驗，已經發現，在大多數情況下，人類用戶將僅僅從來自web搜索的前幾個返回的統一資源標識符(在下文中統稱為URI)中進行選擇，即使返回的URI的總數可能大約有數以百計或者數以千計的URI(例如，谷歌搜索結果的許多頁面)。即,用戶通常僅選擇在第一次返回的web搜索結果頁面頂部的前幾個URI，而所有其它的URI通常被忽略并且不會被點擊。

針對常規互聯網搜索，返回的URI是基于HTTP的。從技術上講，這意味著URI的第一部分(即，方案)指定“http(s)”。例如，“http://www.bestcars.com”或者“http://mybank.com”是HTTP URI的示例。

人類用戶將通常只關注來自web搜索的前幾個返回的URI的事實與搜索引擎優化互為因果。即，人類用戶已經習慣于現代搜索引擎正將最好的搜索結果隱式地放在返回的URI列表頂部的事實。搜索引擎優化涉及由網站開發者用來幫助確保搜索引擎使其網站排名相對較高的一組技術。

圖1圖示了通常稱為交叉鏈接或者有時稱為入站(inbound)鏈接的常用搜索引擎優化技術。該交叉鏈接技術是為了確保從其它網站指向該給定網站。搜索引擎將有大量交叉鏈路指向其的網站排名較高，這是因為交叉鏈接被認為是一種強有力的網站流行度衡量手段。通過web爬蟲(crawler)來檢測交叉鏈接，搜索引擎定期發出所述web爬蟲以爬取(crawl)并且映射萬維網。

另一常用搜索引擎優化技術是為了確保網絡內容使用選擇的關鍵字。這是因為搜索引擎將特定關鍵字在web頁面中的頻率和分布用作其排名算法的部分輸入。同樣，搜索引擎web爬蟲檢測這些關鍵字。

當前用于支持互聯網資源搜索的IoT模型非常簡單且不支持任何高級搜索引擎優化類概念。在當前IoT中，關鍵搜索節點是存儲指向IoT資源的URI的資源目錄。由IoT服務器直接地將這些URI推送到資源目錄中，而不是如在常規互聯網搜索引擎中那樣通過web爬蟲來發現這些URI。隨后，正在查找特定IoT資源的客戶端將所述資源目錄用作搜索引擎。可以經由例如如在2013年12月11日更新的CoRE資源目錄(CoRE Resource Directory)的互聯網草案(http://tools.ietf.org/html/draft-ietf-core-resource-directory-01)中所公開的來自客戶端的輸入參數來調整搜索。然而，對于給定的客戶端搜索請求，返回的URI列表是平面的、未過濾的、并且潛在地非常大的。

IoT的URI或者可以是如常規互聯網一樣的基于HTTP的，或者經常可以是基于受限應用協議(在下文中稱為CoAP)的。例如，如2013年6月28日更新的受限應用協議(Constrained Application Protocol)的互聯網草案(http://tools.ietf.org/html/draft-ietf-core-coap-18)中所公開的，CoAP是專門為受限設備設計的以其它方式但遵循了HTTP的具象狀態轉移(在下文中統稱為RESTful)方法的優化型網絡傳輸協議。RESTful指用于網絡傳輸協議的通信的無狀態請求/響應模型。

與HTTP方法相似，如果URI的第一部分(即，方案)指定“coap(s)”，那么可以識別到CoAP URI。例如，“coap://tempsensor.floor2.bldg6”或者“coaps://securitycamera.home”是CoAP URI的示例。同樣，對于IoT，在RFC6690“受限RESTful環境鏈路格式(Constrained RESTful Environments Link Format)”(http://tools.ietf.org/html/rfc6690)中定義了URI的描述及其屬性和關系，并且稱為“CORE鏈路格式”。

下面的詳細用例圖示了當前資源目錄如何工作及其一些缺點。假設大型工廠在建筑中分布有1000個溫度傳感器。圖2圖示了向資源目錄登記了URI的溫度傳感器202、204、和206。如圖2所示，傳感器202、204、或者206中的每一個將開始向本地資源目錄208登記(經由CoAP Post)其資源(URI)。這將允許資源目錄構建URI數據庫。在實踐中，在范圍上資源目錄一般位于本地。例如，大城市可能會具有多個資源目錄。然而，理論上，沒有任何事物能阻止資源目錄208在范圍上全球化。資源目錄的范圍完全是一種實現和部署選擇。

圖3圖示了客戶端302向資源目錄查詢溫度傳感器列表的示例。如圖3所示，在溫度傳感器202、204、和206向資源目錄登記其URI之后，客戶端發送搜索查詢(經由CoAP GET)。搜索查詢請求資源目錄識別哪些URI將提供在工廠域中的溫度讀數。這是通過作為查詢的一部分的搜索參數來指定的。

圖4圖示了在相同的示例中資源目錄208如何響應于客戶端搜索查詢而返回未過濾的溫度傳感器列表。資源目錄使用其已經登記在數據庫中的1000個溫度傳感器URI的完整列表進行響應(經由CoAP GET響應)。

圖5中圖示了在該當前IoT模型中客戶端所面臨的挑戰。根據響應于客戶端的查詢而返回的1000個溫度傳感器的列表，客戶端應該嘗試訪問1000個URI中的哪些URI？基本假設是：由于時間、帶寬、處理能力等的限制，客戶端302訪問所有1000個URI是不實際的。

作為附加背景信息，oneM2M(例如，如在“oneM2M Functional Architecture”oneM2M-TS-0001oneM2M Functional Architecture-V-0.42中所公開的)旨在指定可以容易地嵌入各種硬件和軟件內以支持不同的M2M應用(諸如，聯網汽車、智能健康等)的公共服務層。作為公共服務層，OneM2M基本上定義了公共服務功能集合，例如，發現公共服務功能。一種或者多種特定類型的公共服務功能的集合的實例化被稱為公共服務實體。可以將公共服務實體托管在不同類型的網絡節點(諸如，基礎結構節點、中間節點、或者應用專用節點)上。

圖6圖示了oneM2M功能架構600，其中：1)應用實體(AE)602可以經由Mca接口訪問并且利用在公共服務實體(CSE)604中的公共服務功能；2)公共服務實體604可以經由Mcc接口與另一公共服務實體606通信；3)公共服務實體604還可以經由Mcn接口利用來自基礎網絡的網絡服務實體(NSE)608。例如，作為公共服務實體，M2M服務器具有發現公共服務功能，應用實體可以利用該發現公共服務功能來搜索維護在M2M服務器或者甚至在M2M有權訪問的其它地方中的資源。

技術實現要素：

由于多種原因，用于常規互聯網中的高級搜索引擎優化的技術不能直接地用于IoT或者M2M。第一，許多搜索引擎優化技術是基于強大的搜索引擎(諸如，Google)的模型。在該模型中，搜索引擎在整個萬維網中發出web爬蟲以檢測網站屬性(例如，交叉鏈路、關鍵字等)。然而，IoT或者M2M模型的根本差異在于：雖然存在存儲URI的資源目錄，但這些URI是通過服務器直接地推送到資源目錄的。另外，資源目錄不發出任何類型的web爬蟲來確定web空間的屬性。在IoT或者M2M模型中，資源目錄被正在查找特定資源(URI)的用戶用作搜索引擎。

第二，在大多數IoT或者M2M情況中，無人參與IoT或者M2M搜索。與在常規互聯網中的web搜索不同，在IoT或者M2M搜索中，人類不能對要從具有大量返回的URI的搜索結果選擇哪個URI做出認知決策。相反，在IoT或者M2M搜索中，搜索結果通常返回至具有有限決策力和有限處理能力的受限設備。最后，將常規互聯網網站假設為總是可用。然而，在IoT或者M2M中，許多服務器可能會頻繁地進入睡眠模式，并且因此并非總是可用。當前在常規互聯網web搜索結果中未考慮到該特性。

因此，需要向當前資源目錄功能性增添將向IoT或者M2M提供最高效的搜索結果的更高級的搜索引擎優化。所述高級搜索引擎優化可以允許資源目錄向客戶端提供優化的結果，以選擇最好的URI。

本文描述了用于在包括服務器和資源目錄的網絡中向資源目錄提供搜索引擎優化的方法、設備、和系統。在示例實施例中，資源目錄登記從服務器接收的統一資源標識符。資源目錄可以基于測量在每一個統一資源標識符之間的交叉鏈路來確定統一資源標識符的初始排名。統一資源標識符越多地被另一個統一資源標識符交叉鏈接到，則所述統一資源標識符的排名越高。資源目錄還可以基于識別統一資源標識符的上下文來確定初始排名。統一資源標識符的上下文可以包括：資源類型、域、地理定位、組播、以及單播。資源目錄可以基于上下文，諸如相同的資源類型來選擇一組統一資源標識符，并且將該一組統一資源標識符排名為高于未選擇的統一資源標識符組。在確定初始排名時，資源目錄可以生成存儲初始排名的排名數據庫。

響應于從客戶端接收的搜索查詢，資源目錄可以確定存儲在排名數據庫中的統一資源標識符的實時排名。可以通過檢查每一個服務器的睡眠狀態來確定所述實時排名。例如，如果統一資源標識符在搜索時正處于睡眠，那么將所述睡眠的統一資源標識符排名為低于清醒的另一個統一資源標識符，或者將所述睡眠的統一資源標識符從搜索結果完全移除。還可以基于部分地平衡服務器的流量負載來確定實時排名。可以將已經多次排名較高或者已經檢測為具有較高的流量流的統一資源標識符排名為低于其它統一資源標識符。在確定實時排名后，資源目錄可以生成過濾且優先化的統一資源標識符的排名列表，并且將該排名列表返回至客戶端。

提供該發明內容是為了以簡化的形式介紹對于在下面的詳細說明中進一步描述的概念的選擇。該發明內容不旨在識別所要求的主題的關鍵特征或者必要特征，也不旨在限制所要求的主題的范圍。此外，所要求的主題并不限于解決在本公開的任何部分中提到的任何或者全部缺點的限制。

附圖說明

通過下文結合附圖以示例的方式給出的說明書可以得到更詳細的理解，所述附圖中：

圖1是圖示了在常規(非IoT)互聯網中與服務器-A的交叉鏈接的示例的系統圖；

圖2是圖示了向資源目錄登記其統一資源標識符的溫度傳感器的系統圖；

圖3是圖示了客戶端向資源目錄查詢溫度傳感器列表的示例的系統圖；

圖4是圖示了資源目錄返回未過濾的溫度傳感器列表的示例的系統圖；

圖5描繪了客戶端所面臨的從未過濾的統一資源標識符列表獲取資源的挑戰；

圖6是圖示了oneM2M服務層功能架構的系統圖；

圖7是圖示了根據示例實施例的演進型資源目錄架構的系統圖；

圖8是圖示了根據示例實施例的總體資源目錄過程的流程圖；

圖9是圖示了根據示例實施例的用于交叉鏈接排名的子過程的流程圖；

圖10是圖示了根據示例實施例的向資源目錄登記其統一資源標識符的溫度傳感器的系統圖；

圖11是圖示了根據示例實施例的向資源目錄查詢溫度傳感器列表的客戶端的系統圖；

圖12是圖示了根據示例實施例的返回過濾的溫度傳感器列表的資源目錄的系統圖；

圖13是圖示了根據示例實施例的僅從最高排名的統一資源標識符的集合取得資源的客戶端的系統圖；

圖14是圖示了根據示例實施例的在M2M/IoT服務層中具有搜索引擎優化的資源目錄的系統圖；

圖15是圖示了根據示例實施例的在oneM2M功能架構中的公共服務功能內的資源目錄的系統圖；

圖16是圖示了根據示例實施例的在公共服務功能內用于資源登記和資源查詢的資源目錄過程的流程圖；

圖17是圖形用戶界面的示意圖；

圖18A是可以實現一個或者多個公開的實施例的示例機對機(M2M)或者物聯網(IoT)通信系統的系統圖；

圖18B是可以在圖17A圖示的M2M/IoT通信系統內使用的示例架構的系統圖；

圖18C是可以在圖18A圖示的通信系統內使用的示例M2M/IoT終端或者網關設備的系統圖；以及

圖18D是其中可以體現圖18A的通信系統的方面的示例計算系統的框圖。

具體實施方式

提供隨后的詳細說明是為了圖示示例性實施例，并且不旨在限制本發明的范圍、適用性、或者配置。在不脫離本發明的精神和范圍的情況下，可以對元件和步驟的功能和布置做出各種改變。

在本公開中將使用下面的縮寫和定義：

AE 應用實體

CoAP 受限應用協議

CORE 受限RESTful環境

交叉鏈路 在兩個URI之間定義的關系。具體地，一個URI

指向(通向)另一個URI。

CSE 公共服務實體

CSF 公共服務功能

HTTP 超文本傳輸協議

IETF 互聯網工程任務組

IoT 物聯網

M2M 機對機

NSE 網絡服務實體

RD 資源目錄

資源 可以通過URI識別并且可以通過網絡傳輸協議

訪問的網絡數據對象或者SW進程。

REST 具象狀態轉移

(用于網絡傳輸協議的通信的無狀態請求/響應

模型)

SEO 搜索引擎優化

URI 統一資源標識符

(用于識別CoAP或者HTTP資源的字符串。)

web搜索 設計為在web(互聯網)上搜索包含期望信息的

URI的軟件系統。

web傳輸協議 用于在web(互聯網)中傳輸資源的協議。

HTTP和CoAP是IoT的關鍵協議。使用web傳輸協議

的應用可能各種各樣。一個示例是web瀏覽器

(客戶端)和內容服務器(例如，安全攝像機)。

另一個示例是溫度傳感器軟件(客戶端)和控制

服務器。

本公開的演進型RD可以將過濾且優先化的搜索結果提供給針對RD的客戶端搜索查詢。這可以允許客戶端掃描優化的搜索結果，以為其正在查找的資源快速地選擇最好的URI。在示例實施例中，關于初始地存儲URI并且稍后對客戶端搜索請求做出響應，RD的架構包括RD功能塊和處理序列。RD功能塊可以包括用于將最好的搜索結果提供給客戶端的以下URI排名/過濾功能：

●睡眠節點處理：將在客戶端搜索請求時刻當前正喚醒的服務器對應的URI的排名提高。與當前睡眠的客戶端相關聯的URI可以過濾掉或者將其排名降低。

●準負載平衡處理：將與具有較少感知負載的服務器對應的URI的排名提高。

●上下文處理：對URI進行過濾，以減少表示相同物理屬性(例如，溫度傳感器)并且來自相同邏輯域(例如，子網絡)的URI的數量。同樣，將屬于組播(multicast)組或者與提出請求的客戶端處于相同地理定位的URI的排名提高。

●URI交叉鏈接處理：檢查在URI(一般指示高值URI)之間的鏈路，并且將那些URI的排名提高。

在一個實施例中，可以改變現有的IETF協議以支持在從RD發送至客戶端的搜索結果中指示URI的排名。而且，可選地，客戶端可以在初始搜索請求查詢中指示排名范圍和客戶端感興趣的其它信息。

RD架構

圖7圖示了根據示例實施例的演進型RD架構700。具體地，示出了在RD 702中的信息流和處理塊。下面是高級描述：

在圖7的步驟1中，RD 702可以具有用于推送(登記)URI和拉取(查詢)URI的單獨的邏輯數據庫。登記數據庫704可以是從登記其CoAP資源的服務器接收的URI的原始數據庫。處理后數據庫706可以用于提供對查詢的響應。

在圖7的步驟2中，RD 702可以具有用于對URI進行初始排名的新處理塊708。該新處理塊可以包括測量交叉鏈接和/或識別上下文以確定初始排名。由于其獨立于未來客戶端搜索查詢，這些初始處理塊708可以離線執行或者作為后臺處理而執行。

在圖7的步驟3中，隨后將初始排名的URI放入單獨的URI的處理后數據庫706中。注意，原始數據庫704和處理后數據庫706在邏輯上可以分開。原始數據庫704和處理后數據庫706可以實現在單個物理數據庫中，或者可以實現在分離的的物理數據庫中。

在圖7的步驟4中，客戶端搜索查詢可以轉到RD 702的處理后數據庫706，該處理后數據庫706拉取與客戶端查詢參數相應的初始排名列表。

在圖7的步驟5中，實時處理塊710可以用于睡眠狀態和準負載平衡。RD 702可以基于在RD內可用的信息來執行實時檢查，以確定選擇的URI是否在當前正睡眠的服務器上。如果服務器當前正睡眠，那么可以從要發送回客戶端的響應中完全過濾掉那些“睡眠”的URI。替選地，可以將睡眠的URI排名為最低。RD 702還可以基于在RD 702內的信息來執行準負載平衡以確保排名功能不總是將在網絡中的相同URI(資源服務器)排名為最高而結束。準負載平衡也是實時進程。

在圖7的步驟6中，將排名并且過濾的URI列表返回至客戶端作為對其搜索請求的響應。最終排名可以是在不同處理(子排名)塊上的加權平均，并且考慮到了URI的靜態(即，初始排名)和動態(即，實時排名)的組合。

如上所述，在范圍上RD 702一般位于本地。例如，大城市可能會在不同定位中具有多個RD。然而，理論上，沒有任何事物能阻止RD 702在范圍上全球化。RD 702的范圍完全是一種實現和部署選擇。假設在單個RD 702的范圍內執行上文描述的SEO技術。

要理解，可以將圖7中圖示的功能性實現為存儲在M2M網絡的節點(例如，服務器、網關、設備、或者其它計算機系統)(諸如，下文描述的圖18C和18D中圖示的那些中的一個)的存儲器中存儲的、并且在所述節點的處理器上執行的軟件(即，計算機可執行指令)的形式。

RD排名和過濾功能

圖8圖示了根據示例實施例的總體RD過程。在演進型RD 702中的總體RD過程可以包括如圖7和圖8圖示的多種排名和過濾功能。圖8中的總體RD 702過程的關鍵輸出可以是URI列表，其中，在所述列表中的URI的每一個與將被用作對客戶端搜索請求的響應的排名相關聯。同樣要注意，通常可以從RD過程的最終輸出過濾掉一些或者許多URI，并且客戶端可能看不見這些URI。

在圖8的步驟802中，通過服務器801來登記URI。

圖8的步驟804、806、808、和810形成用于處理URI的排名數據庫的循環。在圖8的循環中，步驟806用于測量URI的交叉鏈接，而步驟808用于識別給定URI的上下文。

在圖8的步驟812中，處理URI的數據庫。

圖8的步驟814、816、818、和820示出了對來自客戶端302的請求做出響應的RD 702。

在圖8的步驟814中，從客戶端302接收搜索請求。

在圖8的步驟816中，將最終排名且過濾的搜索提供給客戶端302。

圖8中示出的整個RD過程可能需要在來自客戶端的相同搜索請求(即，具有相同輸入參數的查詢)之間重新運行。這主要是因為實時排名功能。隨著時間的流逝，該部件可能會導致不同的排名輸出。另外，RD過程的變型可以實現相同的排名結果。例如，首先可以將URI分成不同的組(例如，具有交叉鏈路的一組URI、和沒有交叉鏈路的另一組)。隨后，如圖8所示，每次登記新URI時，可以不需要循環通過所有URI。

在一個實施例中，推薦與每一個URI相關聯的排名參數是在(0-63)之間的絕對值。這可以在不會變得過大的情況下提供區分各個URI的足夠的值。多個URI還可以具有相同排名值而結束。可以將給定URI的最終排名參數計算為不同排名子排名(例如，交叉鏈路、上下文等)的加權平均。例如：

·排名(Rank)＝(權重_1×排名_交叉鏈接+權重_2×排名_上下文+權重_3×排名_睡眠+權重_4×排名_準負載平衡)/4

其中，“權重”可以是在0到1之間的因子。例如，在負載平衡非常重要的系統中，應該將權重_4設置為1。替選地，例如，如果已知在網絡(例如，僅有幾個設備的家)中的總流量負載非常低，那么應該將權重_4設置為0.1。

排名值的分配和有關的處理可以是每一個RD 702的內部決策。然而，客戶端仍然可以獲得滿足其輸入搜索準則的URI的有價值且明確的排名輸出列表。這可以遵循如用于當前常規互聯網的相同方法，在這種方法中，每一個搜索引擎(例如，Google、Bing)可以針對相同的輸入搜索參數返回不同的URI排名列表。例如，如果將“最好的披薩”鍵入到谷歌和必應，隨后比較搜索結果，便可以容易地看出這點。然而，演進型RD 702對如何完成用于IoT RD的高效排名方案給出了不同的架構和詳細的指導。

要理解，執行圖8中圖示的步驟的實體是可以被實現為存儲在網絡節點或者計算機系統(諸如，圖18C或者18D圖示的網絡節點或者計算機系統)的存儲器中、并且在該網絡節點或者計算機系統的處理器上執行的軟件的形式的邏輯實體。即，圖8中圖示的方法可以被實現為存儲在網絡節點(諸如，圖18C或者圖18D中圖示的節點或者計算機系統)的存儲器中的軟件(即，計算機可執行指令)的形式，所述計算機可執行指令當由節點的處理器執行時執行圖8中圖示的步驟。還要理解，可以在所述節點的處理器及其執行的所述計算機可執行指令(例如，軟件)的控制下，所述節點的通信電路執行圖8中圖示的任何傳輸和接收步驟。

1.URI交叉鏈接處理：

在IoT中，仍然將URI交叉鏈接視為很重要。在IoT中，交叉鏈路的最常見表達是URI與另一個URI具有定義的關系。有時，這也稱為“類型鏈路(typed link)”，如在RFC6690“Constrained RESTful Environments Link Format(受限RESTful環境鏈路格式)”(http://tools.ietf.org/html/rfc6690)中描述的，其通過引用的方式并入本文使得所述公開在本文中被完整地闡述。

針對IoT的交叉鏈路的示例：如果出于冗余性目的，報警控制器服務器在另一個服務器上具有替選URI。服務器可以經由鏈路格式“主機”和“錨”參數向其URI指示有關的鏈路。具體地，這將在服務器向RD登記或者重新登記其資源(URI)時由服務器指示。該IoT交叉鏈接可以如下表示：

●示例場景：

o出于冗余性目的，報警控制器服務器(URI-1)想要指示替選服務器(URI-2)

■即，如果URI-1不可用，那么客戶端可以轉到URI-2

o因此，當服務器將URI-1登記在RD中時，其可以通過使用以下規約來如下指示URI-2的交叉鏈路：

■coap://home.alarm1/server1/alarm；

■anchor＝"coap://home.alarm2/server2/alarm"；

■rel＝"alternate"

因此，可以使用主機和錨作為交叉鏈接的措施。如在常規互聯網中一樣，可以將交叉鏈路假設為URI的“流行度”的指示。即，指向給定URI的交叉鏈路越多，則應該假設該給定URI越流行并且排名越高。

圖9圖示了根據示例實施例的交叉鏈接排名的子過程。例如，如圖9所示，一旦服務器將URI登記到RD，則RD可以運行以下過程來檢測交叉鏈接。

圖9的步驟902、904、906和908循環通過登記在RD中的所有URI。

圖9的步驟904和906計數(并且歸一化)給定URI交叉鏈接至另一個URI的次數。該歸一化是指排名參數可以具有預定義范圍并且可能需要將交叉鏈路的計數映射到該范圍的事實。例如，預定義范圍在0到100之間，并且已經將給定URI計數為具有1000個交叉鏈路(最多的交叉鏈路)。RD可以將具有1000個交叉鏈路的URI映射至最高的排名(排名0)。如果給定URI僅僅具有20個交叉鏈路(最少的交叉鏈路)，那么RD可以將具有20個交叉鏈路的URI映射至最低的排名(排名100)。

將結果記錄在反映與該URI的交叉鏈接的次數的排名_交叉鏈路參數中。

在示例實施例中，如果服務器曾經請求所述RD刪除具有交叉鏈路的資源(即，URI)，那么該過程可以重新運行。同樣，在要求填入任何未來客戶端搜索查詢將在此處進入RD的處理后URI數據庫的所述客戶端查詢之前，該過程可以離線運行或者運行為后臺處理。在另一示例實施例中，可以運行該過程的變型，從而實現測量交叉鏈接的相同結果。例如，或許能夠標記具有錨參數的URI并且只檢查那些URI，而不是如圖9所示地瀏覽數據庫中的所有URI。

要理解，執行圖9中圖示的步驟的實體是可以被實現為存儲在網絡節點或者計算機系統(諸如，圖18C或者18D圖示的網絡節點或者計算機系統)的存儲器中、并且在該網絡節點或者計算機系統的處理器上執行的軟件的形式的邏輯實體。即，圖9中圖示的方法可以被實現為存儲在網絡節點(諸如，圖18C或者圖18D中圖示的節點或者計算機系統)的存儲器中的軟件(即，計算機可執行指令)的形式，所述計算機可執行指令在由所述節點的處理器執行時，執行圖9中圖示的步驟。還要理解，圖9中圖示的任何傳輸和接收步驟可以在所述節點的處理器及其所執行的計算機可執行指令(例如，軟件)的控制下，所述由節點的通信電路執行。

2.睡眠節點處理

與常規互聯網節點相比，IoT節點的其中一個關鍵特征在于：IoT節點可能經常被低供電，因此經常會進入“睡眠”。例如，IoT節點或者服務器可能是電池或者太陽能供電，并且當其需要節省電力時進入低功率模式。這對IoT節點或者服務器的可用性具有明顯的影響。即，托管URI或者包含URI所指向的底層資源內容的服務器可能并不總是處于上電狀態以實際地維護CoAP請求以訪問這些URI。幸運的是，RD能夠使用睡眠追蹤機制來追蹤困乏服務器。具體地，期望具有睡眠追蹤機制的這些RD了解向其登記了URI的服務器的睡眠調度。這種基于RD的睡眠追蹤機制確定目標資源是否位于困乏服務器上并且困乏服務器當前是否處于睡眠模式。

困乏服務器可以包括多個參數，例如：1)指示節點當前是否處于睡眠模式的睡眠狀態；2)指示節點處于睡眠模式的最大持續時間的睡眠持續時間；3)指示節點已經處于睡眠的時間長度的睡眠時間；以及4)指示節點下一次將進入睡眠的下一次睡眠。困乏服務器的這些參數可以由RD存儲并且由所有感興趣的客戶端訪問。在2014年2月12日更新的“CoAP的增強型困乏節點支持(Enhanced Sleepy Node Supprot for CoAP)”的互聯網草案(http://tools.ietf.org/html/draft-rahman-core-sleepy-05)中對本文提供的基于RD的睡眠追蹤進行了描述，其通過引用的方式并入本文使得所述公開在本文中被完整地闡述。因此，如下所述，如果RD考慮在搜索響應中的URI的睡眠狀態，那么對于客戶端而言將非常有利。

如圖7和圖8所圖示的，在對資源(URI)的搜索請求做出響應之前，但在執行初始排名功能之后，RD可以執行對存儲的睡眠調度的內部實時查找，以判斷任何選擇的URI是否涉及當前正睡眠的服務器。RD可以順序地查找在初始排名數據庫中的每一個URI或者基于搜索查詢中的條件而選擇的一些URI。例如，如果在搜索查詢中的條件將URI指定為特定資源類型，那么RD僅僅查找在初始排名數據庫中具有特定資源類型的URI的睡眠狀態。在這種情況下的“實時”指的是當客戶端搜索請求進入RD時相同的物理(時鐘)時間。這與在客戶端搜索之前某些時間處進行的初始過濾不同。檢查本身是比較已經包含在RD內的服務器睡眠調度，并且判斷在當前時刻服務器是睡眠的還是清醒的。RD不需要訪問在RD外部的任何信息以執行該實時檢查。

可以按照兩種替選方式中的一種來處理當前處于睡眠的URI的排名。一種替選方式是將“睡眠”的URI排名為較低的排名，因為其當前不可用。在未來當所述設備暫時清醒的一段時期內，所述睡眠的URI是可訪問的。另一種替選方案是從返回至提出請求的客戶端的搜索結果中徹底移除睡眠的URI。在該替選方案中，針對搜索結果給出的解釋是其僅僅返回當前可訪問的(清醒的)URI。

為了能夠根據其睡眠調度而適當地同步在對URI的搜索請求和進入睡眠模式的服務器之間的時間，可以要求RD具有可用的準確實時時鐘功能。注意，RD可以與在睡眠服務器中的時鐘同步或者異步。在異步模式中，RD可以在提供搜索請求時包括一些安全緩沖時間，以確保不會由于在RD與服務器之間的時鐘漂移而意外地假設當前睡眠的節點是清醒的。例如，如果存儲的睡眠調度指示睡眠的服務器本應該在2秒前醒來，并且在RD與困乏服務器之間存在幾秒的時鐘漂移，那么RD可以保守地向睡眠調度添加5秒的睡眠，且判斷服務器將再睡眠3秒。安全緩沖時間可以是樂觀的或者悲觀的。這意味著RD可以添加睡眠時間或者減少睡眠時間來確保不會將當前睡眠的節點意外地假設為是清醒的。替選地，RD可以接收服務器的睡眠調度或者睡眠狀態的動態更新，這可以允許其定期地重新同步。

3.準負載平衡處理

IoT設備(諸如，傳感器)通常在客戶端和服務器模式兩者中操作。例如，當傳感器正在向RD登記資源(URI)時，所述傳感器正在扮演客戶端模式。這是因為在這種情況下客戶端正在將CoAP/HTTP請求(例如，PUT)發送至充當服務器的RD。并且，隨后，RD可以執行功能(即，存儲URI)并且制定對客戶端的響應。相反地，如果控制器查詢傳感器，那么傳感器會充當服務器的角色。這是因為，在這種情況下傳感器正在接收請求(例如，GET)并且將執行功能(即，測量溫度)。并且隨后，傳感器可以制定對控制器的響應。因此，所述傳感器被認為是服務器。

IoT服務器通常由于其本身性質而在其資源方面受限。單獨服務器不超載請求很關鍵。例如，針對給定搜索輸入，如果RD正好始終將單個服務器排名較高，由于很多客戶端可能自然地選擇該URI，這可能導致在該服務器上的負載問題。因此，RD基于預期的負載來針對給定搜索輸入試圖平衡將哪個服務器排名較高很重要。

可以以若干方式通過RD來估計負載。一種方式是記錄過去的搜索結果，并且將此作為因素考慮到當前/未來搜索結果中。此處假設，如果給定URI已被多次排名為較高，那么其可能正在接收比較低排名的URI相對更多的流量。因此，作為間接地負載平衡該特定URI的方法，在未來的搜索中，應該將該特定URI排名為稍低。例如，第一搜索結果可以包括10個溫度傳感器，其中，傳感器1的排名為0而傳感器2的排名為1。在第二次請求相同的搜索時，第二次搜索結果可以與第一次搜索結果相同(并且排名可能是相同的)。然而，響應于第三次接收到相同的搜索結果，RD可以確定前兩次進行搜索請求時已經將傳感器1排名為較高，并且在該第三次時將傳感器1排名為低于傳感器2，以避免傳感器1上的相對較高的流量。因此，在第三次搜索結果中，傳感器2的排名可以為0而傳感器1的排名可以為1。在另一示例實施例中，RD還可以考慮計時器作為因素。例如，如果搜索請求相隔幾分鐘或者幾小時，并且在該幾分鐘或者幾小時期間將特定URI排名為高于其它URI，那么RD可以確定在未來的搜索中應該將特定URI排名為較低以避免在該特定URI上的高流量。

另一種方法是記錄進入所述URI的實際請求/流量。當RD與其中正通過流量的反向代理或者邊界節點上物理地同定位時，這是b可能的。這意味著RD具有訪問額外的非RD功能的權限。例如，在基于oneM2M的系統中的網關中實現的RD可以知道去到URI的實際請求或者流量，這是因為網關保持了對URI的請求或者流量的統計，并且RD可以訪問該統計。而且，服務器本身可以提供有用的信息，諸如，服務器是否是由電池或者干線供電、其電池電量等。例如，在電池供電的服務器和干線供電的服務器中，RD可以選擇將電池供電的服務器的排名降低以節省其電池。在另一示例中，RD可以將電池電量低的服務器排名為低于電池電量高的服務器以節省其電池。此外，這些信息可能來自帶外信息源，諸如，RD在提供搜索結果時可以考慮的操作和維護系統(配置信息)的部分。在該功能與下文描述的上下文處理之間還可能存在較強的交互。

該準負載平衡功能可以給出部分但不完整的負載平衡解決方案。這是因為全負載平衡解決方案將需要在服務器中的實際負載(包括由服務器生成的流量)的更精確的知識。然而，這可能超出了SEO RD解決方案的范圍。該準負載平衡主要基于來自內部RD評估的感知負載。

4.上下文處理

在這種情況下，上下文可指URI與其它有關URI的物理或者邏輯關系。示例可以包括：

●與其它相似的URI(例如，溫度傳感器)處于相同邏輯域(例如，子網絡)的URI。

●屬于給定IP組播組(例如，在四樓的所有燈)的URI。

●物理上(即，地理定位)接近其它相似的URI的URI。

●不屬于任何組的URI(即，是單播)。

IoT場景通常涉及測量在有限地理區域(例如，建筑、場地、鄰近區)內的相同物理屬性(例如，溫度、濕度等)的大量傳感器。基于從登記信息接收的“資源類型(rt)”參數，RD知道傳感器的特性。因此，一種有用的過濾方法可能是：RD選擇具有相同資源類型并且屬于相同“域”的傳感器的子集，例如，如在2013年12月11日更新的CoRE資源目錄(CoRE Resource Directory)的互聯網草案(http://tools.ietf.org/html/draft-ietf-core-resource-directory-01)中定義的。例如，如果在相同域(例如，建筑子網絡)中存在1000個溫度傳感器，那么RD可以基于所述傳感器的各種上下文選擇僅僅向客戶端報告在搜索結果中的這些傳感器的較小子集。還可以通過與如上所述的準負載平衡功能的交互來選擇子集。替選地，可以向客戶端報告所有傳感器，但是選擇的URI的子集可以具有高排名值，而剩余的傳感器可以具有低得多的排名值。

IoT還可以支持URI的組通信模式，例如，如在2013年12月23日更新的“CoAP的組通信(Group Communication for CoAP)”的互聯網草案(http://tools.ietf.org/html/draft-ietf-core-groupcomm-18)中公開的。在這種模式中，單個URI經由IP組播映射至一組服務器。目前在常規互聯網中還不支持這種組通信模式。因此，另一種非常有用的排名準則是RD可以將正在映射至一組服務器的組播URI排名為高于單播URI。例如，盡管每一個組播URI可以具有相同的排名，但是它們會中的每一個的排名至少比單播URI高一個。這是因為底層組通信機制可以每個URI向客戶端傳送比單播URI更多的信息。即，單個CoAP組通信請求(例如，GET)可以返回多個響應，這是因為該請求經由IP組播分布到已經訂閱該組的多個服務器。

根據場景，還可以基于各種其它準則來計算上下文。例如，如果在RD中地理定位特征可用，那么可以給予與最靠近提出請求的客戶端的URI相關聯的服務器較高的優先級。例如，在2014年2月12日更新的“用于定位事物的鏈路格式屬性(A Link-Format Attribute for Locating Things)”的互聯網草案(http://tools.ietf.org/html/draft-fossati-core-geo-link-format-attribute-03)中公開了該地理定位特征。這可以要求客戶端按照對RD而言是標準化的方式將其自身定位信息包括在搜索請求中。

信令變化

可以改變與CoAP和HTTP有關的信令以支持演進型RD的SEO類功能。具體地，在實施例中，客戶端可以通過在其搜索請求中指示其對特定數量的URI感興趣和/或其對非困乏節點感興趣來限制搜索響應的大小。來自RD的搜索響應可以將該輸入納入考慮，并且還在搜索響應中明確地指示每一個URI的排名。

在實施例中，可以更新CORE鏈路格式以支持在搜索響應中的“排名”的以下參數。可以結合CoAP或者HTTP協議使用CORE鏈路格式：

●在對客戶端的查詢響應(即，GET響應)中，RD可以通過新參數(即，“排名”)來指示返回的URI的排名。該排名可以優選地如下解釋：

o推薦排名參數是在(0-63)之間的絕對值。然而，這是示例編碼，并且也可以使用其它范圍(例如，0-100)。關鍵準則可以是：排名范圍應該在不會變得過大的情況下提供用于區分各種URI的足夠的值。

o在推薦的排名編碼中，可以將排名值“0”視為最高優先級URI。可以將排名值“63”視為具有最低優先級的URI。

o可以從第一個具有排名＝0的URI開始對返回的URI列表進行連續地排名。注意，多個URI可以具有相同的排名值而結束。

●下面的示例示出了客戶端利用資源類型溫度傳感器(rt＝temperature_sensor)對所有端點執行查找。

o請求：GET coap://rd-lookup/ep？rt＝temperature_sensor

o響應：2.05內容

■<coap://sensorA.home>；ep＝”node_A”；rank＝0

■<coap://sensorC.home>；ep＝”node_C”；rank＝1

■<coap://sensorB.home>；ep＝”node_B”；rank＝2

■<coap://sensorD.home>；ep＝”node_D”；rank＝3

●注意，隨著時間的流逝，發送至RD的給定的相同的查詢請求可以導致排名的URI的不同響應。這可能主要是由于對URI排名的準負載平衡和困倦節點檢查的影響，因為它們都與時間有關。

另外，可選地，在對RD的初始客戶端查詢(即，GEI請求)中，客戶端還可以指示對CoAP協議和HTTP協議兩者的以下偏好：

●在搜索結果中客戶端可以接受的排名參數值的范圍。例如，客戶端可以指示其僅接受在范圍(0-10)內的排名。因此，在這種情況下，RD可能需要另外過濾掉排名在范圍(11-63)內的URI的任何內部搜索結果。

●客戶端是否想要將困乏節點包括在搜索結果中。

例如，所述CoAP協議被公開在2013年6月28日更新的受限應用協議的互聯網草案(http://tools.ietf.org/html/draft-ietf-core-coap-18)中，其通過引用的方式并入本文使得所述公開在本文中被完整地闡述。所述HTTP協議被公開在RFC2616“超文本傳輸協議-HTTP/1.1(Hypertext Transfer Protocol-HTTP/1.1)”(http://tools.ietf.org/html/rfc2616)中，其通過引用的方式并入本文使得所述公開在本文中被完整地闡述。

可以優選地包括信息(諸如，排名的范圍、資源類型、和睡眠狀態指示)作為CoAP/HTTP搜索請求的URI串的查詢部分的一部分，如在RFC3986“統一資源標識符”(URI)：通用語法”(http://tools.ietf.org/html/rfc3986)中公開的，其通過引用的方式并入本文使得所述公開在本文中被完整地闡述。

●GET

coap://rd-lookup/ep？rt＝temperature_sensor&rank＝0&rank＝1&slee

py＝No

●其中，對RD的請求以查找如下URI：

■類型＝“溫度傳感器”

■并且排名＝(0或1)

■并且不應該將困乏節點包括在搜索結果中。

如上所述，上文定義的所有參數(即，排名、困乏節點指示)可以在IETF中標準化或者可以成為事實上的解釋。同樣存在第三種可能的模型，在該模型中，基于裝置制造商和/或網絡運營商的私人訂閱和業務關系，所有這些參數都可能是專有信息。

示例

圖10圖示了根據示例實施例的向資源目錄登記其統一資源標識符的溫度傳感器的示例。假設大型工廠在建筑中分布有1000個溫度傳感器。如圖10所示，每一個傳感器可以經由CoAP Post開始向本地RD 702登記其資源(URI)。這可以允許RD 702構建原始URI的數據庫。RD 702隨后可以基于其屬性(諸如，如上所述的交叉鏈接、上下文等)來處理所有URI。隨后將排名的URI存儲在RD的處理后數據庫中。

圖11圖示了根據示例實施例的向資源目錄查詢溫度傳感器列表的客戶端。在初始排名的URI被存儲在處理后數據庫中之后，如圖11所示，客戶端可以經由CoAP GET發送搜索查詢。該搜索查詢可以請求RD 702識別哪些CoAP資源(URI)將提供工廠中的溫度讀數。即，該查詢可以指定資源類型為“溫度_傳感器”，并且指定域是工廠建筑。此外，客戶端可以指示其僅僅對排名在范圍(0-10)內的URI感興趣。同樣，客戶端可以指示其對當前處于睡眠模式中的服務器上的URI不感興趣。

圖12圖示了根據示例實施例的返回過濾的溫度傳感器列表的資源目錄。參照圖12，RD 702可以經由CoAP GET響應，利用遠低于1000個條目(即，少于傳感器的總數)的優先級化的URI的列表來做出響應。這是因為初始排名和實時過濾可能已經消除了大量URI。由于客戶端指令僅提供在排名(0-10)內的URI，且由于僅考慮當前未睡眠的URI，所以已經明顯地消除了一些URI。可以通過RD，使用針對在RD 702的處理后數據庫中的URI查找之后出現的與困乏節點有關的URI的實時檢查來處理這種情況。

同樣，在這種情況下，所述傳感器可以具有相同的資源類型并且位于相同的域。因此，RD上下文識別功能可以消除來自搜索列表的大量URI，這是因為它們被假設為測量相似(溫度)值。搜索結果列表較小的另一個原因是因為假設許多傳感器當前正睡眠。

圖13圖示了根據示例實施例的僅從最高排名的統一資源標識符取得資源的客戶端。參照圖13，客戶端隨后可以容易且高效地僅請求在過濾的RD搜索結果中返回的最高三個URI。所請求的URI的最終數量可以取決于客戶端應用。

為了清楚起見，本文描述的大部分示例示出了CoAP的使用。然而，一般地，可以利用HTTP來容易地實現等效的功能。同樣，如例如2014年2月12日更新的HTTP-CoAP映射實現指南(Guidelines for HTTP-CoP Mapping Implementation)的互聯網草案(http://tools.ietf.org/html/draft-ietf-core-http-mapping-03)中所公開的，HTTP和CoAP交互工作的混合網絡也可以實現等效的功能，。

要理解，圖10至圖13中圖示的功能性可以被實現為M2M網絡(例如，服務器、網關、設備、或者其它計算機系統)(諸如，下文描述的圖18C或者18D中圖示的那些中的一個)的存儲器中存儲的、并且在所述M2M網絡的節點的處理器上執行的軟件(即，計算機可執行指令)的形式。

圖14圖示了具有在M2M/IoT服務層中實現的搜索引擎優化的資源目錄的實施例。如上所述，RD的SEO類功能(例如，排名和過濾功能)可以拓展至IoT服務層，諸如在“oneM2M Functional Architecture”oneM2M-TS-0001oneM2M Functional Architecture-V-0.4.2中公開的HTTP或者CoAP層上方的層，其通過引用的方式并入本文使得所述公開在本文中被完整地闡述。圖14中圖示了本實施例的示例，該示例具有下主要觀點：

●服務器801可以駐留在IoT裝置1402(例如，3GPP機器類型通信設備)中，而客戶端可以是IoT應用的一部分。

●RD 702(包括如上所述的SEO類特征)可以實現為IoT網關1404或者IoT服務器的一部分。

●服務器801可以通過服務層接口來將資源登記到RD 702，而客戶端同樣可以通過服務層接口向RD 702發出查詢。在IoT網關1404中的RD 702可以運行SEO類特征并且通過服務層接口向客戶端302返回排名的URI的列表。

對于圖14中示出的、RD 702是oneM2M網關的一部分的網絡，RD 702的范圍可以與網關域對應。即，在網關所服務的M2M區域網絡中的所有裝置(服務器)可以將其資源登記到RD 702。RD 702隨后可以處理與這些資源對應的URI并且對所述URI進行排名。至RD 702的搜索查詢隨后可以來自或者網關域的內部或者來自外部網絡域。RD 702隨后可以返回具有涵蓋了位于網關域內部的服務器的排名的URI的搜索結果。

如果如圖14所示，SEO-RD在本地實現為oneM2M網關的一部分，那么RD 702可以容易地具有訪問經由網關1404流向IoT裝置/流出IoT裝置的用戶平面流量的統計的權限。這可以使RD實現上文描述的準負載平衡功能變得更容易。具體地，RD 702或許能夠監測對位于網關邊界內部的URI(資源)的外部請求(例如，CoAP GET)。這可以允許RD 702將負載指標作為因素納入排名計算中，RD 702將該排名計算作為準負載平衡算法的一部分。

圖15圖示了根據另一示例實施例的在oneM2M功能架構中的RD CSF 1502。如圖15所示，可以將上文描述的SEO類特征(例如，排名和過濾)實現為新oneM2M CSF(稱為RD CSF 1502)并且實現為oneM2M CSE的一部分。CSE1 1504可以是M2M/IoT網關或者服務器。RD CSF 1502可以具有以下功能：

●RD CSF 1502可以接受來自AE或者CSE的資源登記并且維護所有登記的資源。

●RD CSF 1502可以根據上文描述的機制對登記的資源進行排名。

RD CSF 1502可以處理來自AE或者CSE的資源查詢并且返回上文描述的過濾的資源列表。要理解，圖14至15中圖示的功能可以被實現為M2M網絡(例如，服務器、網關、裝置、或者其它計算機系統)(諸如，下文描述的圖18C或者18D中圖示的那些中的一個)的存儲器中存儲的、并且在該M2M網絡的節點的處理器上執行的軟件(即，計算機可執行指令)的形式。

圖16基于圖15示出的RD CSF 1502，圖示了資源登記過程和資源查詢過程。

在圖16的步驟1中，請求者1 1602(例如，AE或者CSE)可以將資源登記請求消息發送至RD CSF 1502。該消息可以包含以下信息：1)待登記的資源的列表；2)如上文描述的每一個資源的屬性，諸如，其URI、交叉鏈路、負載、上下文、定位、以及睡眠調度。

o注意，可以通過使用oneM2M中的現有資源宣告(Resource Announcement)來實現該步驟，但是可能需要對每一個宣告的資源添加額外屬性(即，如上文描述的交叉鏈路、負載、上下文、定位、睡眠調度)。

在圖16的步驟2中，RD SCF 1502可以將資源登記響應發送回請求者1 1602。

在圖16的步驟3中，RD CSF 1502可以根據上文描述的方法對所有登記的資源進行排名。

在圖16的步驟4中，請求者2 1604(例如，AE或者CSE)可以將資源查詢消息發送至RD CSF 1502。該消息可以包含以下信息：1)如上文描述的搜索準則，諸如，期望的排名、期望的資源定位、期望的資源負載。

o注意，可以通過使用oneM2M中的現有Discovery CSF與新的如上文描述的準則(諸如，期望的排名)來實現該步驟。

在圖16的步驟5中，RD CSF 1502可以根據上文描述的方法基于包含在步驟4中的準則來搜索其維護的資源。

在圖16的步驟6中，RD CSF 1502可以將結果發送至請求者2(即，發現的資源的列表)。

AE或者CSE本身可能是一種資源。隨后，可以將由AE或者CSE宣告的資源視作其交叉鏈路。結果，可以向具有更多宣告的資源(即，更多的交叉鏈路)的AE或者CSE分配較高的排名，并且其具有較高的可能性被發現并且被返回至請求者2。

同樣要注意，在另一實施例中，替代于在新RD CSF中提供本公開的SEO類特征，可以將這些特征實現為對在oneM2M中的現有Discovery CSF的修改。在該替選實施例中，可以應用在圖16中的相同過程(僅用修改的Discovery CSF替代RD CSF)。

要理解，執行圖16中圖示的步驟的實體是可以被實現為網絡節點或者計算機系統(諸如，圖18C或者18D圖示的網絡節點或者計算機系統)的存儲器中存儲的、并且在該網絡節點或者計算機系統的處理器上執行的軟件的形式的邏輯實體。即，圖16中圖示的方法可以被實現為網絡節點(諸如，圖18C或者圖18D中圖示的節點或者計算機系統)的存儲器中存儲的軟件(即，計算機可執行指令)的形式，其中，計算機可執行指令在由節點的處理器執行時執行圖16中圖示的步驟。還要理解，圖16中圖示的任何傳輸和接收步驟可以在所述節點的處理器和其執行的計算機可執行指令(軟件)的控制下由所述節點的通信電路系統執行。

可以使用界面(諸如，圖形用戶界面(GUI))可以來協助用戶控制和/或配置與資源目錄的搜索引擎優化有關的功能。圖17是圖示了允許用戶查看對資源目錄的搜索結果以理解搜索系統的操作的debug界面1702的示意圖。圖17還圖示了用于調整在資源目錄的搜索引擎中使用的搜索參數的界面1704。要理解的是，可以通過使用顯示器(諸如，下文描述的圖18C-18D示出的顯示器)來產生界面1702和1704。

示例M2M/IoT/WoT通信系統

圖18A是示例可以實現本文描述的演進型資源目錄的SEO類功能的機對機(M2M)、物聯網(IoT)、或者物流網(WoT)通信系統10的示意圖。通常，M2M技術為IoT提供建筑塊，并且任何M2M裝置、網關、或者服務平臺可以是IoT以及IoT服務層的部件等。

通常，M2M技術為IoT/WoT提供建筑塊，并且任何M2M裝置、M2M網關、M2M服務器、或者M2M服務平臺可以是IoT/WoT以及IoT/WoT服務層的部件或者節點等。通信系統10可以用于實現所公開的實施例的功能性并且可以包括功能性和邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT裝置1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)、以及用于產生界面(諸如，界面1702和1704)的邏輯實體。

如圖18A所示，M2M/IoT/WoT通信系統10包括通信網絡12。該通信網絡12可以是固定網絡(例如，以太網、光纖、ISDN、PLC等)或者無線網絡(例如，WLAN、蜂窩等)或者異構網絡的網絡。例如，通信網絡12可以由將內容(諸如，語音、數據、視頻、消息、廣播等)提供給多個用戶的多個接入網絡組成。例如，通信網絡12可以采用一個或者多個信道訪問方法，諸如，碼分多址(CDMA)、時分多址(TDMA)、頻分多址(FDMA)、正交FDMA(OFDMA)、單載波FDMA(SC-FDMA)等。進一步地，通信網絡12可以包括其它網絡，諸如例如，核心網絡、互聯網、傳感器網絡、工業控制網絡、個人區域網絡、融合的個人網絡、衛星網絡、家庭網絡、或者企業網絡。

如圖18A所示，M2M/IoT/WoT通信系統10可以包括基礎結構域和場域。基礎結構域指端對端M2M部署的網絡端，而場域指區域網絡，通常在M2M網關后面。場域和基礎結構域可以包括各種不同的網絡節點(例如，服務器、網關、裝置等)。例如，場域可以包括M2M網關14和終端設備18。要了解，可以按照所期望的將任何數量的M2M網關設備14和M2M終端設備18包括在M2M/IoT/WoT通信系統10中。每一個M2M網關設備14和M2M終端設備18配置為通過使用通信電路系統經由通信網絡12或者直接無線電鏈路來傳輸和接收信號。M2M網關14允許無線M2M設備(例如，蜂窩和非蜂窩)以及固定網絡M2M設備(例如，PLC)或者通過運營商網絡(諸如，通信網絡12)或者直接無線電鏈路通信。例如，M2M終端裝置18可以收集數據，并且經由通信網絡12或者直接無線電鏈路將該數據發送至M2M應用20或者其它M2M設備18。M2M終端設備18還可以從M2M應用20或者M2M終端設備18接收數據。進一步地，如下所述，可以經由M2M服務層22將數據和信號發送至M2M應用20或者從M2M應用20接收數據和信號。M2M終端設備18和網關14可以經由各種網絡(包括，例如，蜂窩、WLAN、WPAN(例如，Zigbee、6LoWPAN、藍牙)、直接無線電鏈路、和有線)通信。

示例性M2M終端設備18包括，但不限于，平板、智能電話、醫療設備、溫度和天氣監測器、聯網汽車、智能電表、游戲控制臺、個人數字助理、健康和健身監測器、燈、恒溫器、電器、車庫門和其它基于驅動器的設備、安全設備、和智能插座。

參照圖18B，在場域中圖示的M2M服務層22向M2M應用20、M2M網關設備14、和M2M終端設備18以及通信網絡12提供服務。通信網絡12可以用于實現所公開的實施例的功能性并且可以包括功能和邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如，界面1702和1704)的邏輯實體。可以通過一個或者多個服務器、計算機、設備、虛擬機器(例如，云/存儲場(farm)等)等(包括例如下文描述的18C和18D中圖示的設備)來實現M2M服務層22。要理解，M2M服務層22可以按照所期望的與任何數量的M2M應用、M2M網關14、M2M終端設備18、和通信網絡12通信。可以通過網絡的一個或者多個節點(可以包括服務器、計算機、裝置等)來實現M2M服務層22。M2M服務層22提供適用于M2M終端設備18、M2M網關14、和M2M應用20的服務能力。可以采用各種方式(例如，作為網絡服務器、在蜂窩核心網絡中、在云中等)來實現M2M服務層22的功能。

與圖示的M2M服務層22相似，在基礎結構域中有M2M服務層22’。M2M服務層22’向在基礎結構域中的M2M應用20’和底層通信網絡12’提供服務。M2M服務層22’還向在場域中的M2M網關14和M2M終端設備18提供服務。要理解，M2M服務層22’可以與任何數量的M2M應用、M2M網關、和M2M設備通信。M2M服務層22’可以通過不同的服務提供商來與服務層交互。通過網絡的一個或者多個節點的M2M服務層22’，該一個或者多個節點可以包括服務器、計算機、設備、虛擬機(例如，云計算/存儲場等)等。

仍然參照圖18B，M2M服務層22和22’提供不同的應用和垂直(vertical)可以利用的服務交付能力的核心集。這些服務能力使M2M應用20和20’能夠與設備交互并且執行諸如數據收集、數據分析、設備管理、安全、開賬單、服務/設備發現等的功能。本質上，這些服務能力使應用解除了實現這些功能性的負擔，從而簡化應用開發并且降低上市成本和時間。服務層22和22’還使M2M應用20和20’能夠通過與服務層22和22’提供的服務相連接的各種網絡12和12’通信。

本申請的方法可以實現為服務層22和22’的一部分。服務層22和22’是通過一組應用編程接口(API)和底層網絡接口來支持增值服務能力的軟件中間件層。ETSI M2M和oneM2M均使用可以包含本申請的連接方法的服務層。ETSI M2M的服務層稱為服務能力層(SCL)。可以將SCL實現在M2M設備(在這種情況下，其稱為設備SCL(DSCL))、網關(在這種情況下，其稱為網關SCL(GSCL))、和/或網絡節點(在這種情況下，其稱為網絡SCL(NSCL))內。OneM2M服務層支持一組公共服務功能(CSF)(即，服務能力)。將一個或者多個特定類型的CSF的集合的實例化稱為公共服務實體(CSE)，可以將該公共服務實體托管在不同類型的網絡節點(例如，基礎結構節點、中間節點、專用應用節點)上。進一步地，可以將本申請的連接方法實現為使用面向服務架構(SOA)和/或面向資源架構(ROA)來訪問服務(諸如，本申請的連接方法)的M2M網絡的一部分。

在一些實施例中，M2M應用20和20’可以結合公開的系統和方法使用。M2M應用20和20’可以包括與UE或者網關交互的應用，并且還可以結合其它公開的系統和方法使用。

在一個實施例中，如圖18B所示，邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如界面1702和1704)的邏輯實體可以托管在由M2M節點(諸如，M2M服務器、M2M網關、或者M2M設備)托管的M2M服務層實例內。例如，邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如界面1702和1704)的邏輯實體可以包括M2M服務層實例內的單獨的服務能力或者作為在現有服務能力內的子功能。

M2M應用20和20’可以包括在各種行業(諸如，但不限于，運輸、健康與保健、聯網家庭、能源管理、資產追蹤、以及安全和監督)中的應用。如上所述，跨越系統的設備、網關、服務器、和其它節點而運行的M2M服務層支持諸如例如，數據收集、設備管理、安全、開賬單、定位追蹤/地理圍墻、設備/服務發現、和遺留系統集成的功能，并且將這些功能作為服務提供給M2M應用20和20’。

通常，服務層22和22’定義通過應用編程接口(API)和底層網絡接口的集合來支持增值服務能力的軟件中間件層。ETSI M2M和oneM2M架構均定義了服務層。ETSI M2M的服務層稱為服務能力層(SCL)。可以將SCL實現在ETSI M2M架構的各種不同節點中。例如，可以將服務層的實例實現在M2M設備(在這種情況下，其稱為設備SCL(DSCL))、網關(在這種情況下，其稱為網關SCL(GSCL))、和/或網絡節點(在這種情況下，其稱為網絡SCL(NSCL))內。oneM2M服務層支持公共服務功能(CSF)(即，服務能力)集合。將一個或者多個特定類型的CSF的集合的實例化稱為公共服務實體(CSE)，可以將該公共服務實體托管在不同類型的網絡節點(例如，基礎結構節點、中間節點、專用應用節點)上。第三代合作伙伴計劃(3GPP)還定義了用于機器類型通信(MTC)的架構。在該架構中，將服務層和其提供的服務能力實現為服務能力服務器(SCS)的一部分。不論是否體現在ETSI M2M架構的DSCL、GSCL、或者NSCL中、在3GPP MTC架構的服務能力服務器(SCS)中、在oneM2M架構的CSF或者CSE中、或者在網絡的任何其它節點中，都可以將服務層的實例實現為或者在網絡中的一個或者多個獨立節點(包括服務器、計算機、和其它計算設備或者節點)上執行的、或者作為一個或者多個現有節點的一部分執行的邏輯實體(例如，軟件、計算機可執行指令等)。作為示例，服務層或者其部件的實例可以被實現為在具有下文描述的圖18C或者18D圖示的通用架構的網絡節點(例如，服務器、計算機、網關、設備等)上運行的軟件的形式。

進一步地，可以將邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如界面1702和1704)的邏輯實體實現為使用面向服務架構(SOA)和/或面向資源架構(ROA)來訪問本申請的服務的M2M網絡的一部分。

圖18C是M2M網絡節點30(諸如，M2M設備18、M2M網關14、或M2M服務器等)的示例硬件/軟件架構的框圖。節點30可以執行或者包括邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如界面1702和1704)的邏輯實體。設備30可以是圖18A至圖18B示出的M2M網絡的一部分或者非M2M網絡的一部分。如圖18C所示，M2M節點30可以包括處理器32、不可移除存儲器44、可移除存儲器46、揚聲器/麥克風38、小鍵盤40、顯示器、觸摸板、和/或指示器42、電源48、全球定位系統(GPS)芯片集50、和其它外圍設備52。節點30還可以包括通信電路系統，諸如收發機34和傳輸/接收元件36。要了解，M2M節點30可以在與實施例保持一致的同時包括前述元件的任何子組合。該節點可以是實現本文描述的SMSF功能性的節點。

處理器32可以是通用處理器、專用處理器、常規處理器、數字信號處理器(DSP)、多個微處理器、與DSP核心相關聯的一個或者多個微處理器、控制器、微控制器、專用集成電路(ASIC)、現場可編程門陣列(FPGA)電路、任何其它類型的集成電路(IC)、狀態機等。通常，處理器32可以執行存儲在節點的存儲器(例如，存儲器44和/或存儲器46)中的計算機可執行指令，以便執行節點的各種要求的功能。例如，處理器32可以執行信號編碼、數據處理、功率控制、輸入/輸出處理、和/或使M2M節點30能夠在無線或者有線環境中操作的任何其它功能性。處理器32可以運行應用層程序(例如，瀏覽器)和/或無線電接入層(RAN)程序和/或其它通信程序。處理器32還可以執行安全操作(諸如，認證、安全密鑰協議、和/或加密操作)，諸如例如在接入層和/或應用層處。

如圖18C所示，處理器32耦合至其通信電路系統(例如，收發機34和傳輸/接收元件36)。通過執行計算機可執行指令，處理器32可以控制通信電路系統，以使節點30經由其所連接的網絡與其它節點通信。具體地，處理器32可以控制通信電路系統，以執行本文和權利要求書中描述的傳輸和接收步驟。盡管圖18C將處理器32和收發機34描述為單獨的部件，但是要了解，可以將處理器32和收發機34集成在電子封裝或者芯片中。

傳輸/收發元件36可以配置為將信號傳輸至其它M2M節點，或者從其它M2M節點接收信號，所述其它M2M節點包括M2M服務器、網關、設備等。例如，在實施例中，傳輸/接收元件36可以是配置為傳輸和/或接收RF信號的天線。傳輸/接收元件36可以支持各種網絡和無線接口，諸如，WLAN、WPAN、蜂窩等。例如，在實施例中，傳輸/接收元件36可以是配置為傳輸和/或接收IR、UV、或者可見光信號的發射機/檢測器。在再一實施例中，傳輸/接收元件36可以配置為傳輸和接收RF和光信號兩者。要了解傳輸/接收元件36可以配置為傳輸和/或接收無線或者有線信號的任何組合。

另外，盡管在圖18C中將傳輸/接收元件36描繪為單個元件，但是M2M節點30可以包括任何數量的傳輸/接收元件36。更具體地，M2M節點30可以采用MIMO技術。因此，在實施例中，M2M節點30可以包括用于傳輸和接收無線信號的兩個或者更多個傳輸/接收元件36(例如，多個天線)。

收發機34可以配置為調制待由傳輸/接收元件36傳輸的信號并且解調制由傳輸/接收元件36接收的信號。如上文提到的，M2M節點30可以具有多模式能力。因此，收發機34可以包括用于使M2M節點30能夠經由多個RAT(諸如例如，UTRA和IEEE 802.11)通信的多個收發機。

處理器32可以訪問來自任何類型的合適的存儲器(諸如，不可移除存儲器44和/或可移除存儲器46)的信息，并且將數據存儲在該任何類型的合適的存儲器中。例如，如上所述，處理器32可以將會話上下文存儲在其存儲器中。不可移除存儲器44可以包括隨機存取存儲器(RAM)、只讀存儲器(ROM)、硬盤、或者任何其它類型的存儲器存儲設備。可移除存儲器46可以包括用戶識別模塊(SIM)卡、記憶棒、安全數字(SD)存儲器卡等。在其它實施例中，處理器32可以訪問來自并未在物理上位于M2M節點30的存儲器(諸如，在服務器或者家庭計算機上)的信息，或者將數據存儲在該存儲器中。處理器32可以配置為控制顯示器或者指示器42上的照明模式、圖像、或者顏色，以為了反映M2M服務層會話遷移或者共享的狀態，或者為了獲取來自用戶的輸入或者向用戶顯示關于所述節點的會話遷移或者共享能力或者設置的信息。在另一示例中，顯示器可以示出針對會話狀態的信息。當前公開在oneM2M實施例中定義了RESTful用戶/應用API。可以在顯示器上示出的圖形用戶界面可以層疊于API頂部，以允許用戶經由本文描述的底層服務層會話功能交互地建立并且管理E2E會話或者其遷移或共享。

處理器32可以接收來自電源48的電力，并且可以配置為分布和/或控制用于M2M節點30中的其它部件的電力。電源48可以是用于向M2M節點30充電的任何合適的設備。例如，電源48可以包括一個或者多個干電池(例如，鎳-鎘(NiCd)、鎳-鋅(NiZn)、鎳金屬氫化物(NiMH)、鋰離子(Li-ion)等)、太陽能電池、燃料電池等。

處理器32還可以耦合至配置為提供關于M2M節點30的當前定位的定位信息(例如，經度和緯度)的GPS芯片集50。要了解，M2M節點30可以在與實施例保持一致的同時通過任何合適的定位確定方法來獲得定位信息。

處理器32可以進一步耦合至其它外圍設備52，該外圍設備52可以包括提供附加特征、功能性、和/或有線或者無線連接性的一個或者多個軟件和/或硬件模塊。例如，外圍設備52可以包括加速度計、電子羅盤、衛星收發機、傳感器、數碼相機(針對照片或者視頻)、通用串行總線(USB)端口、振動設備、電視收發機、免提耳機、模塊、調頻(FM)無線電單元、數字音樂播放器、視頻游戲機模塊、互聯網瀏覽器等。

圖18D是還可以用于實現M2M網絡的一個或者多個節點(諸如，M2M服務器、網關、設備、或者其它節點)的示例性計算系統90的框圖。計算設備90可以包括計算機或者服務器并且可以主要由計算機可讀指令控制，該計算機可讀指令可以是軟件的形式，所述軟件可以在任何時間且以任何手段被存儲或者訪問。計算系統90可以執行或者包括邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如界面1702和1704)的邏輯實體。計算系統90可以是M2M設備、用戶設備、網關、UM/GW或者包括例如移動護理網絡的節點、服務層網絡應用提供者、終端設備18、或者M2M網關設備14的任何其它節點。可以在處理器(諸如，中央處理單元(CPU)91)內執行這種計算機可讀指令，以使計算系統工作。在許多已知的工作站、服務器、和個人計算機中，中央處理單元91由稱作微處理器的單片機CPU來實現。在其它機器中，中央處理單元91可以包括多個處理器。協處理器81是與主CPU 91不同的、執行附加功能或者協助CPU 91的可選處理器。CPU 91和/或處理器81可以接收、生成、并且處理與所公開的針對E2E M2M服務層會話的系統和方法有關的數據，諸如，接收會話證書或者基于會話證書進行認證。

在操作中，CPU 91取得、解碼、并且執行指令，并且經由計算機的主數據傳輸路徑系統總線80將信息傳輸至其它資源并且傳輸來自其它資源的信息。這種系統總線連接在計算系統90中的部件，并且定義用于數據交換的介質。系統總線80通常包括用于發送數據的數據線、用于發送地址的地址線、和用于發送中斷并且用于操作系統總線的控制線。這種系統總線80的示例是PCI(外圍部件互連)總線。

耦合至系統總線80的存儲器包括隨機存取存儲器(RAM)82和只讀存儲器(ROM)93。這種存儲器包括允許信息被存儲并且檢索的電路系統。ROM 93通常包含不能輕易修改的存儲數據。存儲在RAM 82中的數據可以由CPU 91或者其它硬件設備讀取或者改變。可以由存儲器控制器92控制訪問RAM 82和/或ROM 93。當指令被執行時，存儲器控制器92可以提供將虛擬地址轉化成物理地址的地址轉換功能。存儲器控制器92還可以提供將系統內的進程隔離并且將系統進程與用戶進程隔離的存儲器保護功能。因此，在第一模式中運行的程序僅可以訪問通過其自身的進程虛擬地址空間映射的存儲器；該程序不能訪問在另一進程的虛擬地址空間內的存儲器，除非已經建立了在進程之間共享的存儲器。

另外，計算系統90可以包含負責將指令從CPU 91傳送到外圍設備的外圍設備控制器83，諸如，打印機94、鍵盤84、鼠標95、和磁盤驅動器85。

由顯示控制器96控制的顯示器86用于顯示由計算系統90生成的可視輸出。這種可視輸出可以包括文本、圖形、動畫圖形、和視頻。顯示器86可以與基于CRT的視頻顯示器、基于LCD的平板顯示器、基于氣體等離子體的平板顯示器、或者觸摸板一起實現。顯示控制器96包括生成發送至顯示器86的視頻信號所需的電子部件。

進一步地，計算系統90可以包括通信電路系統(諸如例如，網絡適配器97)，所述通信電路系統可以用于將計算系統90連接至外部通信網絡(諸如，圖18A和圖18B的網絡12)，以使計算系統90與網絡的其它節點通信。

要理解本文描述的任何或者所有系統、方法、和過程可以體現為存儲在計算機可讀存儲介質上的計算機可執行指令(即，程序代碼)的形式，所述指令在由機器(諸如M2M網絡的節點，包括例如，M2M服務器、網關、設備等)執行時，執行和/或實現本文描述的系統、方法、和過程。具體地，上文描述的任何步驟、操作、或者功能(包括網關、UE、UE/GW、或者移動核心網絡、服務層、或者網絡應用提供商的任何節點的操作)可以按照這種計算機可執行指令的形式來實現。邏輯實體(諸如，資源目錄208和702、傳感器(諸如，傳感器202、204、和206)、客戶端302、AE 602、CSE 604、606、和1504、NSE 608、數據庫704和706、初始排名功能708、實時排名功能710、服務器801、IoT設備1402、IoT網關(或者服務器)1404、RD CSF 1502、請求者1602和1604)以及用于產生界面(諸如界面1702和1704)的邏輯實體可以體現為存儲在計算機可讀存儲介質上的計算機可執行指令的形式。計算機可讀存儲介質包括實現在用于存儲信息的非暫時性(即，有形的或者物理的)方法或者技術中的易失性和非易失性介質以及可移除和不可移除介質，但是這種計算機可讀存儲介質不包括信號。計算機可讀存儲介質包括但不限于，RAM、ROM、EEPROM、閃速存儲器或者其它存儲器技術、CD-ROM、數字多功能光盤(DVD)或者其它光盤存儲、磁帶盒、磁帶、磁盤存儲或者其它磁性存儲設備、或者可以用于存儲期望的信息并且可以由計算機訪問的任何其它有形的或者物理的介質。

在本公開的主題的優選實施例的描述中，如圖所示，為了清楚起見采用了特定的術語。然而，所要求的主題不旨在限于所選擇的特定術語，并且要理解，每一個特定元件包括以相似的方式操作以完成相似的目標的技術等效物。

該書面描述使用示例(包括最佳模式)來公開本發明，并且還使本領域的任何技術人員能夠實踐本發明(包括制作并且使用任何設備或者系統，并且執行任何并入的方法)。本發明的專利范圍由權利要求書定義，并且可以包括本領域的技術人員能想到的其它示例。如果這些示例具有與權利要求書的文字語言并無不同的元件，或者如果這些示例包括與權利要求書的文字語言無實質性差異的等效元件，那么這種其它示例旨在落入權利要求書的范圍內。