資源管理的製作方法

2023-06-07 02:13:16 2

專利名稱：資源管理的製作方法
技術領域：
本發明涉及用於電信網絡的資源管理的方法、設備和系統。該管理包括資源的分配，釋放或保持。
諸如第三代無線網絡(UMTS通用移動電信系統)的電信網絡或諸如異步傳輸模式網絡的高速網絡打算經由在網絡基礎結構上的計算設備提供諸如語音、數據和多媒體的服務。為了支持具有特定服務質量(QoS)要求的各種服務，資源供應是主要的問題。在每個情況中，通信網絡至少包括一種資源，其將以適當的方式被管理。
在當前電信系統中的許多應用是一對多的應用，其中一個或很少的源向多個接收者發送。支持這種傳輸類型的有效方式是使用多播。多播是一種網際網路絡(internetwork)業務，允許源將數據分組的一個拷貝發送到一個地址，其使得數據分組被傳送到多個接收者。在多播下只有一個消息拷貝將通過網絡中的任何鏈路，而數據分組的多個拷貝將只在通道分叉處實現。此外，如果只發送一個消息的拷貝就足夠了，即使該消息去往大量的接收方，則對於發送者具有性能的改善。在多播傳輸的情況中，網絡連接被預留用於多個用戶並且伺服器也被多個用戶訪問，所以它的資源將在用戶間分發，意味著資源供應要考慮共享該資源的用戶的數目。
使用資源的客戶機的數量可以在特定時間點改變或消失。如果資源在較長的時段沒有被使用，它可能被釋放或銷毀(destroy)。這種資源可以是暫時分配給網絡某個節點的伺服器功能，例如用於傳送目的的選播(anycast)、廣播或多播「關聯」，在節點間的信令關係等。共享資源的問題不僅存在於傳送問題，還適用於處理、存儲容量等。
通常，如上面所述的共享資源的資源供應是網絡中的主要問題之一，而呼叫許可控制是供應策略之一，以限制網絡中呼叫連接的數量，從而減少網絡擁塞和呼叫丟棄。一種呼叫許可模型被用於通信量整形，其例如被應用於確定一個數據流是否應被允許發送。最簡單的通信量整形方案設法使所有的通信量形成為同步的流，以固定時間間隔發送的規則數量的數據。最簡單的通信量整形方案的一個例子是簡單的漏桶。圖7說明了漏桶方案。以數據分組形式的輸入數據流70被放入桶71。數據分組從桶的底部72流出並且在網絡上以速率g被發送。桶的大小B限制有多少數據可以在桶中等待輸入到網絡中。如果數據流攜帶多於桶可以存儲的數據，則超額的數據被丟棄。典型地，每個數據流具有它自己的漏桶。概念上，每個主機通過一個接口被連接至網絡，該接口包括漏桶，即，有限的內部隊列。
一旦資源被建立，呼叫許可算法被用於控制預留資源的使用。另一個方面是所分配的資源的釋放。
除了多播之外還有多個其它的例子，其中存在資源管理的問題，像例如作為傳輸手段的廣播或多播。此外所述問題還存在於點對點通信中，其中多個點對點連接在網絡中構成虛擬導管或隧道，其將被共享。而且資源管理問題還由一些關聯問題而存在，例如在客戶機和它的伺服器之間建立的SCTP流控制傳輸協議的情況中。此處在伺服器和客戶機之間的SCTP關聯是資源，其事實上包括在客戶機和伺服器雙方的存儲器和處理容量，以及用於維持關聯的網絡容量，其中合適的資源管理是有必要的。
應當注意，如果在某個時間段沒有被使用後，它的預留到期，或被伺服器或負責資源管理的實體銷毀，則資源是在「軟狀態」中。否則它被稱為「硬狀態」資源。
相比於釋放或銷毀資源並在空閒時段後基於需要再次佔用或創建它的成本，頻繁的保持空閒資源的成本是較高的。保持空閒的另一個關鍵原因是避免當資源被需要時長的資源建立時間。
在下面給出了一個用於點對點連接中資源管理的例子。在無線網絡中，諸如在分組交換GSM和WCDMA網絡中，PDP-上下文(PDP-context)被建立。在該PDP上下文活動中移動用戶身份與IP位址相關聯。在PDP上下文活動期間，一條隧道在網絡中被建立。在該過程期間服務質量QoS協商也在用戶移動站和網絡之間發生。在PDP上下文建立之後，所述PDP上下文被保持以用於用戶立刻發送或接收內容而不是先等待PDP上下文被建立。
為了保持資源活動的目標，用於不同協議的不同方法被開發，例如保持存活機制，資源刷新消息和類似的當前被不同的網絡標準(H.323、RSVP、NSIS等)使用，用於保持特定資源存活或處於活動狀態。例如在保持存活機制中，一個實例(例如伺服器或客戶機)頻繁地發送包括在數據分組中(例如在報頭中)的消息或信息，該消息或信息指示雖然當前沒有數據在發送但連接被假定為保持開放。因此，如果有數據發送，則通信在相同的已經建立的連接上被執行。這會持續直到伺服器或客戶機決定結束通信，且它們中的一個丟棄連接。
通常生存時間參數被包括在該消息中，並控制資源的生存時間，這樣資源不會不必要地保持太長時間的開放。這種技術被開發用於點對點連接，其中一個實例將它的準備就緒通知給其它設備用於保持連接開放。在定時器到期之後連接被丟棄。
因此，當一個資源被分配給一個用戶時，依照舊例的現有技術使用生存時間參數來重置定義資源生存時間的定時器。那種方式很難考慮在多播連接中的多個用戶或資源擁有者的各種偏好，也不能估計搶先的或預期的資源使用，因為資源的建立和釋放當前是基於管理程序或來自資源用戶的簡單請求。這些程序可能是不準確的並太早或太晚建立或釋放資源。
然而，問題並不只存在於多播傳輸中。在現有技術的許多情況中既沒有提出也沒有完全解決釋放空閒資源的問題，並使它與實現相關。
發明概述本發明的一個目標是提供一種在電信網絡中有效管理資源的解決方案。
本發明具體表現為權利要求1、20和25中所公開的方法。優選實施方式在從屬權利要求中描述，在說明書相應的部分中被公開。
基本思想的方法在權利要求1中被公開，其公開了一種在資源代理中實現的管理過程。
根據本發明的用於通信網絡的資源管理的方法在資源代理中執行下面的步驟，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)，該資源代理被引入在資源擁有者和至少一個資源用戶之間。在第一步中資源使用量度(TTL)被發起。所述量度被用於跟蹤資源用戶資源的預期使用。資源代理獲得用戶使用量度(Keep Alive，InterestMsg)，其通知資源用戶預期的資源的使用。用戶使用量度可以作為來自資源用戶的消息被接收或可替換地，資源代理例如基於預留信息或歷史信息計算所述量度。為了保持資源使用量度(TTL)最新，執行一個更新過程，用於藉助於通過考慮當前和過去的資源使用量度(TTL)值的累積算法，使用用戶使用量度(Keep Alive，InterestMsg)來更新資源使用量度(TTL)。該累積算法的共有特性是更多的值的累積，特別是當前資源使用量度和所述值的歷史的累積，從而補償接收到的用戶使用量度的最終不確定性，該用戶使用量度指示資源用戶預期的資源使用，其可能是不精確的且具有某種程度的不確定性。在這種情況中，通過在時間和不同用戶上平均使用量度，該算法補償從用戶到達的信息的可能的不確定性或隨意性。
根據建立的資源使用量度，作出是否執行管理動作的決定。為了這個目的，執行檢查過程以檢查資源使用量度。假如資源使用量度證明管理動作的執行是必要的，則執行相應的動作，該管理動作可以是分配、保持或釋放資源。
由於累積算法考慮當前和過去的資源使用量度值，另外還有當前和預期的資源用戶的需要，有可能預測資源的使用，所以假如資源不被需要則將不被保持開放並且關閉，即使當用戶使用所述資源時。當前作出這種決定是由於靜態地設置的資源使用量度。
參照權利要求18，公開了根據本發明的資源代理。資源代理被安排以執行用於通信網絡的資源管理，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)。所述資源代理(RB)被置於資源擁有者和至少一個資源用戶之間，並包括發起裝置用於發起共享資源使用量度(TTL)。此外資源代理包括獲取控制器用於獲取用戶使用量度(Keep Alive，InterestMsg)，其通知資源用戶對共享資源的預期使用。更新控制器被引入用於通過考慮當前和過去的資源使用量度(TTL)值的累積算法，使用用戶的使用量度(Keep Alive，InterestMsg)來更新共享資源使用量度(TTL)。為了檢查資源使用量度的目的，使用檢查監視器，資源使用量度指示執行資源管理動作的必要性。依照檢查監視器的結果，資源管理動作裝置適用於執行資源管理動作。所提到的裝置是資源代理的部分，它們被安排以執行關於相應的方法步驟所描述的功能。
建議資源代理具有更多特徵。例如資源擁有者提供不可靠的資源給代理，然後資源代理可以作為一種資源池的擁有者而工作，其管理資源並在失敗的情況下提供它們的冗餘。
此外本發明公開了一種系統，用於通信網絡的資源管理，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)。所述系統包括如上所述的資源代理(RB)，在所述資源代理(RB)和資源擁有者(RO)之間的第一通信接口和在所述資源代理(RB)和至少一個資源用戶(RU)之間的第二通信接口。
在下面本發明優選實施例將被詳細的描述，從而給技術人員提供本發明徹底的和完整的理解，但是這些詳細的實施方式只作為本發明的例子而並不意謂著限制。下面的描述將參照附圖，其中

圖1示出了根據本發明的實施方式的網絡結構的示意性表示，圖2示出了本發明的基本實施方式的流程圖，圖3示出了根據本發明的實施方式的信令的示意性表示，圖4示出了用於釋放共享資源的本發明實施方式的流程圖，圖5示出了用於分配共享資源的本發明的實施方式的流程圖，圖6示出了根據本發明的實施方式的系統結構和接口的示意性表示，圖7示出了根據現有技術使用漏桶方案的呼叫許可的示意性表示，圖8示出了用於使用漏桶方案釋放資源的本發明的實施方式的示意性表示。
圖1示出了根據本發明的實施方式的網絡結構的示意性表示，其中一種新功能節點，稱為資源代理RB，被引入到在至少一個資源擁有者RO和至少一個資源用戶RU之間的通信鏈路上。
應當認識到在本發明的上下文中的術語「資源擁有者」、「資源用戶」、「資源代理」或通常的「節點」、「裝置」指的是在通信網絡中用於提供預定功能的硬體和軟體的任意合適的組合。以這種方式，所述術語通常指的是可以擴展在網絡的多個物理節點上的邏輯實體，但也可以指的是位於一個物理節點上的物理實體。
在其後描述的例子中，資源代理的功能由伺服器或內容提供者執行，其中伺服器可以負責網絡中的通信連結，內容提供者提供將被分發給用戶的內容。
優選的，通信網絡是移動通信網絡，例如根據GPRS(通用分組交換無線業務)或UMTS(通用行動電話系統)或GSM工作的移動通信網絡。然而，本發明也可應用在提供資源的任意通信網絡中。
應當認識到術語「資源」指代任何種類的資源實體。在本發明中公開了兩種資源共享；同時共享，其意味著多個資源用戶同時訪問資源；和順序共享，其意味著在同一時間有一個資源用戶訪問資源。
在下面，所給出的實施方式示出了同時共享的資源。優選地，所述資源的例子是網絡資源，其可以是通信網絡中的虛擬實體並為了分布用戶的共用而佔有或創建。由此，這些可以是例如被用於多播/廣播傳輸的網絡連接，但是在某個網絡節點的資源，例如像處理時間、或存儲量，也可以被認為是根據本發明的分配資源。然而本發明不限於同時共享資源。事實上所建議的方法可以被用於在單個資源用戶的情況下的資源管理。例如該方法可以被用於釋放任何傳輸/連接關聯，例如在客戶機和它的伺服器之間建立的SCTP流控制傳輸協議的情況。如上述的，在伺服器和客戶機之間的SCTP關聯是資源，其事實上包括在客戶機和伺服器二者中的存儲器和處理容量，以及用於維持該關聯的網絡容量。在這種情況中伺服器是資源擁有者而客戶機是資源用戶，執行根據本發明的過程來確定所述關聯是否被保持，這個過程也可以由客戶機或伺服器執行或由客戶機和伺服器兩者獨立地執行。這個控制可能對操作者是有用的，從而節省在一個節點中的資源關聯的成本。在下面給出的兩個實施方式示出了用於共享資源管理的本發明的應用。然而，同樣的過程也應用於沒有被共享的資源。
資源可以是分布實體，且不同節點擁有/持有資源實體的不同部分。然後合理地指派/指定資源擁有者功能至多個或所有的共享資源擁有者身份的節點。在這種情況中資源擁有者和資源代理的邏輯可以被配置在一個節點中。更甚至每個共享資源擁有者身份的節點可以具有它自己的資源代理邏輯。擁有分布資源的最昂貴部分或者具有在過載情況下可能影響系統/服務可用性特性限制的節點/邏輯實體可以具有限制更多的資源管理過程，所以在多數情況中這個節點做出關於是否預留、保持或釋放資源的決定。在這種情況中每個RO也可以執行它自己的RB角色。
回到圖1，可以看到在一個網絡結構中可以放置多於一個資源擁有者。如上面提到的，有不同種類的資源可以得到，且每個資源擁有者擁有至少一種所述資源。同樣，有可能由資源擁有者中的每一個來管理一種資源。然而，在資源代理中將被管理的一種資源具有它自己的管理過程。可替換地，每個資源代理可以負責一種資源。
根據圖1，在資源擁有者RO和資源代理RB之間有一個接口11，用於向資源代理指示資源的可用性。此外在資源代理和資源用戶之間有另一個接口12用於與用戶通信。所述接口被用於通知資源代理關於用戶對於資源使用的準備就緒。因此，用戶可以通過該接口12通知資源代理它們是否想請求資源預留，保持預留的資源或是否它們想要釋放資源。此外該接口還可以被用於進一步的通信目的，這將依照本發明進一步的實施方式而被描述。
優選地，真實的數據通信量不需要經由資源代理。例如共享資源是通信鏈路的情況中，然後傳輸經過所述鏈路而不需要將資源代理包括在通信中。資源使用相對於資源管理過程的獨立通過在資源擁有者和資源用戶間的直接接口13在圖1中描述。
可替換地，實際的數據通信量經過資源代理。例如資源代理RB是資源擁有節點的邏輯部分的情況中。在那種情況中資源使用經過資源代理，其可以控制資源使用是否根據所指示或請求的。此外資源代理可以使用資源使用用於計費或統計目的。
圖2示出本發明的方法的基本實施方式的流程圖，具有在資源代理中執行的步驟。下面的步驟將為了資源管理而被執行。優選地，一個資源代理管理多個資源並因此根據圖2的多個管理過程將在資源代理中被執行。可替換地，管理過程可以分別為每個用戶運行，並隨後執行一個協調多個運行過程的算法以將其減少為單個的值(像單個TTL定時器)。
根據圖2中示出的用於資源管理的方法，在資源代理中執行的所述方法包括步驟S21，其中發起資源使用量度。資源使用量度的發起可以以任何需要的或合適的方式被執行。例如，資源代理可以使用一個值發起它，該值由資源代理自己確定。可替換地，資源擁有者可以提供該值給資源代理。例如資源擁有者確定關於資源的成本或時間間隔，其被發送給資源代理用於估計發起使用量度。使用量度例如可以是使用時間或在某個時間段中花費的錢，這是一個組合(錢，時間間隔)。此外，資源擁有者可以提供附加的信息，諸如像可以被用於影響更新過程結果的資源成本。
而且發起階段可以包括在資源和關於所述資源的信息之間提供關聯。該關聯可以以任何需要的和合適的方式執行。例如當資源擁有者授予資源代理代理資源實體的許可時，資源代理可以生成本地入口(例如資源項目表示)。可替換地，該步驟也可以經由管理程序完成。發起過程導致產生所定義的關聯，例如包括更新過程的模型類型，它的參數和他們的起始值，例如模型＝「漏桶」，量度類型＝「每個佔有資源在特定時段中資源擁有者賺取的錢的平均數量」，該數量由生存理由＝「對於佔有資源實體而言足夠的金錢的實際數量」而指定，後者開啟該資源。
另外地，其它參數也可以被初始化，例如資源使用量度被設置為定義保持資源開放的時間的值。
在步驟S21之後，圖1的方法進行到步驟S25，其中執行檢查資源使用量度。據此該步驟可以根據需要以任何優選的方式執行。例如它可以包括裝置用於改變資源使用量度以具有允許做出決定的可變的值。在S21和S25之間的連接允許用戶興趣的檢測。因此，在沒有用戶使用量度到達的情況中，在步驟S26中該過程經由S25終止，其中執行相應的資源管理動作。
並行地實施步驟S22直到接收到來自用戶的請求為止，其意味著該過程等待一個接收到請求的事件，該請求通知關於資源使用的用戶興趣。用戶能夠例如周期性地通過用戶的使用量度或參數的列表提供他們預期的資源使用的一致估計，其有利於在資源代理中的量度的計算。另一個例子可以是這個信息以不同的間隔被提供。所述量度可以作為一種保持生存信息來實現，其被用在下面的實施方式中。然而，除了發送請求消息之外還有不同的方式用於實現用戶使用量度。一些例子在圖4中進一步給出。
可替換地從資源用戶發送包括用戶使用量度的消息至資源代理，資源代理可以由自身計算用戶使用量度。該計算例如可以基於一種資源的模型類型、歷史信息和已經接收的更新。
應當注意，可以有多個用戶訪問共享資源，意味著請求從不同的用戶通常在不同和變化的時間點到達。還應當認識到信息本身或信息值可能在時間上和/或每用戶而不同。因此建議有某種識別過程以將接入資源用戶與運行管理過程相關。在本發明的一個實施方式中，建議有下面的解決方法。資源用戶發送對資源的請求至資源代理，並為預留資源指出特定類型的資源和可能的時間間隔。當資源代理為資源用戶預留資源實體時，資源代理髮送帶有預留的資源實體的身份ID或關聯ID的ACCEPT(接受)消息。隨後如果資源用戶想要按照期望的資源使用在資源代理更新相應的資源，隨後的KeepAlive消息涉及有效的實體ID。
當用戶的對於資源的使用量度請求到達時，S23，該方法進行到步驟S24，其中用於通過累積算法使用用戶的使用量度來更新資源使用量度的更新過程被執行。
應當注意，在本發明的上下文中的術語「累積算法」指得是用於考慮其它參數，像資源使用量度(TTL)和用戶的使用量度(KeepAlive)的當前和過去的值，執行新資源值計算的任何合適的方法。在隨後的描述中作為例子，描述了一種基於漏桶方法的方式。漏桶是當前用於系統負載控制和呼叫許可目的的算法，這在本發明背景技術部分已經描述。可應用於累積方法的其它算法是所謂的CUSUM算法。這是用於統計質量控制的統計算法，目的是為了檢測隨機過程的行為中的改變。有多個其它的算法用於類似的目的，例如移動平均。類似於移動平均的算法被用於網際網路傳輸協議中的流控制目的。然而，那僅僅是例子且本發明不應被限於這些例子中的任何一個。關於統計算法的更多信息將在Basseville Michele，Nikiforov Igor，Detection of Abrupt ChangesTheory andApplication，Prentice-Hall，Inc.，1993和Carlstein E.，Muller H.-G.，Sigmund D.(ed.).Change-Point Problems.Institute of Math.Statist.Lecture Notes Monograph ser.，V23，1994中找到。
應當注意，該值同樣地不是必須是標量，它們可以屬於任何合適的值空間，它可以是離散的或連續的以及多維的或任何其它自然數。當然需要另外的適配例如為了運行定時器。
此外應當注意，將被使用的累積算法的類型通常在步驟S21被確定，當執行整個過程的初始化時。在步驟S21做出關於哪個算法將被使用的決定。然而自適應到用戶的使用量度(KeepAlive)的輸入數據流的在線算法也可以被使用。在這種情況中新的用戶的使用量度同樣可以觸發算法的改變。如果選擇的算法類型取決於多個參數，所述參數可以按照請求，或者基於任何統計/歷史來估計。這些參數可以使用最小二乘擬合方法被確定，其允許尋找對於給定的統計數據集合/累積歷史最好的擬合參數值，或任何其它合適的方法。該算法同樣可以是自回歸統計算法。
此外應當注意，累積算法可以是自回歸算法，其意味著根據給定的參數做出決定，該算法將被使用。所述參數可以按照請求提供，或者基於任何統計/歷史來估計。
回到圖2，在隨後的步驟S25中，跟蹤是否新的更新資源使用量度證明改變資源狀態的動作是有必要的。資源的狀態可以是資源將被釋放、預留或保持。此外這可以是空閒資源的預留或已預留資源預留的延長。檢查過程的目的是檢查任何動作條件是否達到以執行資源管理動作。該檢查可以以任何合適的需要的方式被執行。例如它可以通過比較功能被執行，將資源使用量度與任何合適的動作條件相比較。例如資源使用量度是否達到動作條件可以從域/集合的值來建立。資源使用量度可以具有單個標量值或向量的形式。例如在資源使用量度的可能值的空間內可以定義三個域域D1「釋放」，域D2「預留」，域D3「保持預留」，其中D2是D3的一部分，動作值可以取三個值「釋放」、「預留/分配」和「保持/延長分配」，其可以使用D1、D2、D3被確定。原則上這些域可以更加複雜，計算幾何學的方法(例如像在Franco P.Preparata，Michael I.Shamos，Computational GeometryAn Introduction，Springer-Verlag，1993中所描述的)可以被用於校驗新的值屬於哪個域，以及將採取哪個動作。優選地資源使用量度值被轉換為正的標量並開始TTL定時器。總之這些僅僅是關於用於決定資源管理動作的檢查過程的例子。
既然如果比較的結果聲明資源使用量度證明了改變是有必要的，則開始一個動作以改變資源的狀態，S26，例如通過決定相應資源的釋放或預留或延長預留。否則，當比較的結果是動作值沒有達到時，該方法進行到步驟S22，其中等待新的用戶的使用請求。
在下面描述了根據圖3的在資源擁有者、資源用戶和資源代理之間的示意性信令交換。在第一步驟，S31，資源擁有者提供資源，例如通過發送OFFER消息至資源代理。優選地，所述消息可以帶有一些參數，例如資源類型，資源身份，可用性模式或保持生存標記，定義資源的可用性或通知任何計劃下時間和它的時間，或通知在資源使用時間中的變化，或通知資源冗餘。隨後，資源代理決定它的對於管理提供的資源的興趣。該決定在隨後的步驟S32中通過通知達到決定的ACCEPT/REJECT消息被發送至資源擁有者。
參照圖3，在資源代理和資源用戶之間有一個接口。資源用戶例如通過REQUEST(ResType，Usage Pattern)消息，3A，通知它的對於使用提供的資源的興趣。作為對接收到來自資源用戶的請求的反應，資源代理驗證該請求並發送接受或拒絕消息至用戶，3B。資源的使用獨立於資源代理並在資源擁有者和資源用戶之間直接地執行，35。ACCEPT消息包括資源描述符，資源ID等。實際上ACCEPT消息可以包括根據RB資源可以/將被多個資源用戶佔有用於共用時的時間，例如所述消息可以包括多播會話的開始時間，其基於資源用戶的興趣而估計。
在下面根據圖4給出了本發明的一個實施方式，圖4示出了用於釋放共享資源的本發明的一個實施方式的流程圖。下面的步驟將被執行以決定共享資源的釋放。下面的實施方式是基於關於量度參數的一些例子。然而這些例子不應被看作實現本發明的限制。在步驟S41，TimeToLive TTL作為資源使用量度的例子被發起。如已經提到的，資源使用量度的發起可以以任何需要的或合適的方式被執行。還如已經關於圖2所提到的，使用量度可以是例如使用時間或在某個時間段中花費的錢，其是一個組合(錢，時間間隔)。可替換地，資源代理可以基於接收到的消息、事件或傳送的服務，或歷史知識來調整資源的生存時間(TTL)定時器。例如在廣播、多播或選播的情況中，無論何時內容被分布到分組時，TTL可以增加一個默認值。
在步驟S41之後，圖4的方法進行到步驟S44，其中啟動了以TTL發起的計數器。所述計數器的實現可以以任何需要的或合適的方式被實施，例如它可以僅是與時間無關的計數器，或它可以與一些別的事情有關，諸如處理容量，資源的成本或類似的。在下面我們使用定時器作為計數器的例子，然而這不應被看作本發明的任何限制。
所述定時器的目的是指明保持預留資源的時間。在隨後的步驟S45中示出了定時器的運行終止，由此在定時器到達值0的情況下運行終止被傳送，S46。在這種情況中資源被釋放，S47。在本實施方式中，步驟S44，S45和S46構成檢查使用量度的通常步驟，如在圖2的步驟25中示出的。然而，停止定時器被來自資源用戶的輸入更新消息停止，所以當前TTL等於定時器到期所剩下的時間。如果沒有來自資源用戶的更新消息直到定時器到期，當定時器到期時，TTL被設為0。剛剛提到的流程描述了一種情況，即當使用量度被發起並沒有指明用戶的興趣的用戶的使用量度消息到達時。此處過程經由S44，S45，S46運行並結束於S47，其中釋放資源，因為看起來沒有用戶對擁有資源預留感興趣。
在下面呈現了圖4的第二部分，在步驟S42，KeepAlive消息到達。根據本發明，用戶能夠周期性提供他們預期的資源使用的一致估計。可替換地，這可以被管理地/手動地釋放，例如資源代理基於每時段請求的次數估計要求的預留時間。所述估計通過用戶的使用量度被發送到資源代理。所述量度可以根據圖4的實施方式被實現為KeepAlive消息。用戶在服務請求消息中發送KeepAlive消息至資源擁有者並在他們的KeepAlive信息到期在適當的消息中周期性地重發它。然而，不是真的必須周期性地發送KeepAlive消息。也可以不是周期性地發送KeepAlive消息，而是當資源實際需要的時候發送。當資源被預留時，資源代理可以向資源用戶以ACCEPT消息的方式請求周期性的KeepAlive更新。還應當注意，KeepAlive信息也可以通過將被分布的內容的接收而被指示而不需要任何專用的KeepAlive指示符。用戶的使用量度的值在從資源用戶發送到它的資源代理的不同的KeepAlive消息中可以具有不同的值。
當KeepAlive到達時，S42，方法進行到步驟S43，其中執行更新過程用於通過累計算法使用接收到的KeepAlive更新TTL。
在下面描述了基於漏桶方式通過累計算法計算新TTL的實施方式。
如已經提到的，累計算法考慮資源使用量度的過去的值並加上用戶的當前需要。因此，在這個例子中Total_KeepAlive值通過其中的模型函數fct被更新。
Total_KeepAlive(n+1)＝fct(Total_KeepAlive(n)，KeepAlive，……)其中對於漏桶方式，上面的公式具有下面的形式Total_KeepAlive(n+1)＝MIN(Total_KeepAlive(n)-ΔTTL+KeepAlive*weight，MAX_Total)其中Total_KeepAlive(n)描述累計它的過去值的當前資源使用量度；ΔTTL是在最後TTL更新之後期滿的時間；weight可以取決於考慮優先級的用戶身份或類別；MAX_Total定義漏桶的總容量。
新估計的Total_KeepAlive(n+1)值被用於確定新的TTL，其中TTL＝Total_KeepAlive(n+1)-ReasonToLiveReasonToLive值影響資源釋放的時間點。因此，ReasonToLive值越高對於釋放資源的決定越快作出。
如在圖4中在步驟S44中說明的，初始地被設為TTL的定時器使用新計算出的TTL更新並且所述定時器開始運行。
在下面，為了解釋上面介紹的關於漏桶的參數，參照圖8給出了用於TTL的計算的實施方式。
圖8示出了漏桶算法的示意性表示。漏桶具有上限值，其是指示可以被分配給Total_KeepAlive的最大值的MAX_Total。
應當注意，在資源代理中可能有其它的控制漏桶的參數，例如，每給定時間間隔的輸入KeepAlive消息的最小數量被引入以便在資源代理中提供負載保護。
所述桶的底部建有ReasonToLive值，其示出通過該桶管理的資源何時被釋放。進入桶的上面的箭頭指示輸入KeepAlive消息。出去的箭頭指示TTL定時器的下降。
如上所述，被設為TTL的定時器倒計數。根據圖8，當新的KeepAlive消息到達時，所述定時器被更新為較高的值，意味著桶的深度增加。另外當沒有新的KeepAlive消息到達時，定時器達到0級，意味著資源將被釋放。
應當注意，諸如ReasonToLive，MAX_Total，weight之類配置參數的設置和Model_function的選擇取決於實際需要並可以隨著情況而改變。特別地，應當強調的是該函數可以考慮其它的參數，例如像資源成本，資源可用性等。由於上述的計算步驟類似於CUSUM算法，開發的用於構建CUSUM模型的統計方法全部可以被用於確定模型參數。
此外，應當注意，通過選擇模型函數，一個函數對於不同使用情況可以調整算法，例如該算法還可以考慮是否有一個或多個單元使用資源(例如，多個源分布內容至多播組)並據此適配TTL。在多個源的情況中，該算法可以對於內容提供者計算相同成本共享，例如在內容提供者(通常不是內容接收者)付費的商業廣告分發的情況中。提供較高的TTL意味著更高的相關成本。
還應當注意，KeepAlive值被與內容發送者身份存儲在一起用於計費目的，這樣可以實現對於被使用或保持開的資源的合適的計費。本發明還能夠對資源預留但沒有被資源用戶使用的時間計費。
根據圖8，還有指示用於分配新資源的可能值的ReasonToReserve值，如參考圖5的實施方式中描述的。
回到圖4，說明了定時器被設為新更新的TTL值並開始運行，S43。所述定時器的實現可以以任何需要的或合適的方式被實施。例如它可以倒計數時間單元。倒計數也可以考慮資源的實際使用。例如當使用更多帶寬時計數的減少可以更快，這是通過在開始定時器之前恰當地縮放/加權TTL來完成的。在隨後的步驟中，S44，示出了運行的定時器。所述定時器周期性地被檢查，它是否達到了預定的值，步驟S45。在該實施方式中，預定的值被設為0。然而，每個經歷的值都適用。如果定時器已經到達了預定的值，則資源被釋放。否則過程返回到步驟S44，從其箭頭也提供到步驟S47，其中等待新的KeepAlive消息。
應當注意，資源釋放過程可以根據資源的類型以不同的方式被實現。例如如果資源是伺服器中的存儲器，則特定信息將被發送給伺服器以通知資源釋放。
在下面呈現了根據圖5的本發明的一個實施方式，圖5示出了用於執行資源分配的本發明的一個實施方式的流程圖。下面的步驟將被執行以作出相應的決定。
在步驟S51，資源使用量度通過預定的值被發起，其在這個情況中是0。在步驟S51之後，圖5的方法進行到步驟S56，其被執行直到接收到來自用戶的請求為止。所述請求在這個實施方式中被表示為InterestMsg，其指示用戶對於某個類型資源的興趣。為了能夠發送InterestMsg，用戶將被通知這個資源分配的可能性。這可以通過例如從資源擁有者發送到潛在用戶的廣播消息而完成。然而，有多個已知的方法用於通知用戶新的硬體或服務，所以這些在此處沒有描述。
在隨後的步驟S53中，資源代理執行更新過程用於藉助於累積函數通過InterestMsg更新資源使用量度。
在下面的累計函數的實施方式中，在資源預留模式中，Total Interest表示涉及興趣量度的資源使用量度。在這個例子中，Total_Interest值藉助於模型函數fct2被更新，其中Total_Interest(n+1)＝fct2(Total_Interest(n)，InterestMsg，...)相應的模型函數可能具有下面的形式
Total_Interest(n+1)＝MIN(MAX(Total_Interest(n)- ΔTTL，0)+InterestMsg*weight，MAX_Total)其中Total_Interest(n)描述當前資源興趣量度；ΔTTL是在最後的Total_Interest更新後期滿的時間；weight可以取決於考慮一些種類的優先級的用戶的身份或類別；MAX_Total定義漏桶的總容量，且和在上面的資源釋放模型中相同。
應當注意，對於一些資源預留模型，沒有必要開始定時器，其取決於用戶在InterestMsg中提供的興趣模式。然而在一些情況中，在最後更新之後過去的時間將被考慮，因為它在上述的例子中通過在模型中包括ΔTTL參數指出。
模型函數的另一個例子可以是像移動平均這樣的函數Total_Interest(n+1)＝T_Weight(n)*Total_Interest(n)+weight*InterestMsg其中T_Weight(n)是在每個步驟中調整Toatl_Interest(n)的(平滑)參數。
當用戶數量被計數時，用戶可以周期性地發送InterestMsg或僅一次。然而，這不應當被看作對本發明的限制。然而，使用更新過程，特定資源的累積興趣被估計。在每次更新之後，所述值與預定的ReasonToReserve值相比較，S54。如果所述值已達到，用於資源分配的過程被開始。否則過程回到狀態，S56，其中等待下一個InterestMsg。
優選地，建議當資源已經根據上述的過程被分配時開始資源釋放方法。在這種情況中Total_KeepAlive(0)被初始化，通過當前的Total_Interest(n+1)值或通過任何其它合適的值，而TTL使用Total_KeepAlive(0)-ReasonToLive或任何其它合適的值來初始化。
在下面根據本發明的系統結構和接口的實施方式被參考圖6給出。圖6示出了出了用於廣播或多播內容供應的系統的示意性表示，其中內容提供者CP表示資源擁有者且資源是在多個用戶間分發內容的共享的通信網絡，用戶在該上下文中是內容接收者CR。進一步如已經提到的，共享資源也可以是多播組。根據本發明，資源代理包含漏桶算法用於每個將被管理的資源。在內容提供者CP和內容接收者CS之間，有一個資源代理RB管理共享的資源。進一步參考圖6，在資源代理和內容提供者之間具有查詢接口。通過邏輯連接6C，內容提供者發送內容至資源代理。
在這個實施方式中，真實的資源使用經由資源代理進行，所以所述資源代理能夠控制通信量。
優選地，資源代理也向內容提供者提供查詢接口，6B和6A。所述接口被用於查詢對於執行管理資源的過程所需要的參數。在下面一些例子被給出以說明哪個參數可以在通信實例間交換。例如通過6A接口關於資源可用性(像例如資源是否已經被建立)的請求信息可以被查詢。這個查詢典型地用於非時間緊急的內容，其優選地當資源已經被另一個內容提供者建立時被分發，例如以減少的成本。進一步為了確保合適的工作更新過程，一些另外的參數或更精確的估計參數可以被查詢。在特別的實施方式中，關於漏桶參數的請求信息，諸如ReasonToLive，資源用戶的數量，可以被定製。此外資源代理可以要求關於資源特性的信息，像例如可得到帶寬，QoS，預留成本和/或此刻資源的實際使用(由於成本可以取決於同時的資源用戶的數量)，以設置影響關於以更好的方式預留/分配或釋放資源的決定的參數。用於管理資源的管理過程可以需要其它的參數為了以更好的方式設置它的參數。例如更新過程的參數可以取決於資源成本，其可以影響漏桶狀態。
代替內容提供者查詢資源代理，內容提供者也可以由資源代理通知，優選地當它們已經為了相應的信息分發而登記。這種通信可以通過6B接口被執行。例如資源代理可以發送一個消息，一些僅建立了類型「X」的資源和仍然有「Y」數量的帶寬可使用。
優選地，資源使用信息被存儲且發送至計費伺服器，其可以使用這個信息以在資源用戶間建立資源的更好的成本分布(甚至對於資源僅僅預留而沒有實際使用的時間)。這種通信在圖6中被指明為6D。
然而這些僅僅是例子，示出通過接口另外的信息可以被查詢以確保根據本發明的資源管理過程的更好性能。
權利要求
1.一種用於通信網絡的資源管理的方法，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)，其特徵在於用於管理資源的資源代理(RB)被引入並執行下面的步驟—發起資源使用量度(TTL)，並—獲取用戶的使用量度(Keep Alive，InterestMsg)，其通知由至少一個資源用戶預期的資源使用，並—執行更新過程用於藉助於累積算法使用用戶的使用量度(Keep Alive，InterestMsg)來更新資源使用量度(TTL)，該累積算法考慮資源使用量度(TTL)當前和過去的值，並—執行檢查過程用於檢查資源使用量度，結果指示執行資源管理動作的必要性，並—根據檢查過程的結果執行資源管理動作。
2.根據權利要求1的方法，其特徵在於資源是順序的或同時的共享資源。
3.根據權利要求1或2的方法，其特徵在於資源使用量度通過一個值被發起，該值從接收自至少一個從資源擁有者的參數中估計。
4.根據權利要求1或2的方法，其特徵在於資源使用量度通過在資源代理處確定的值發起。
5.根據權利要求1至4中的一個的方法，其特徵在於發起步驟包括提供在資源和與所述資源相關的信息之間的關聯。
6.根據權利要求1至5中的一個的方法，其特徵在於資源使用量度被設為一個值，該值定義保持打開資源的時間。
7.根據權利要求1的方法，其特徵在於用戶的使用量度從至少一個資源用戶周期性地被接收。
8.根據權利要求7的方法，其特徵在於用戶的使用量度根據資源用戶的需要在請求時從至少一個資源用戶被接收。
9.根據權利要求1的方法，其特徵在於用戶的使用量度在資源代理中被計算。
10.根據權利要求1至9中的一個的方法，其特徵在於識別過程在資源代理中被執行，以識別在至少一個資源用戶和相應的資源、它的擁有者和管理過程間的關係。
11.根據權利要求1的方法，其特徵在於用於更新資源使用量度(TTL)的更新過程基於漏桶算法或CUSUM算法。
12.根據權利要求1的方法，其特徵在於資源管理動作是資源的分配，資源的保持或資源的釋放。
13.根據權利要求1的方法，其特徵在於檢查過程藉助於比較函數來執行，其中資源使用量度與動作條件相比較。
14.根據權利要求1至13中的一個的方法，其特徵在於所述方法使用通過在資源代理和資源擁有者之間放置的第一接口接收的附加的信息。
15.根據前述的權利要求1至14中的一個的方法，其特徵在於定時器被設為資源使用量度且所述定時器開始倒計時，其中所述定時器被檢查關於執行資源釋放的必要性。
16.根據前述的權利要求1至14中的一個的方法，其特徵在於資源量度指示至少一個資源用戶對執行資源分配的興趣。
17.根據權利要求1至16中的一個的方法，其特徵在於附加的接口被引入以與計費實體交換信息。
18.根據權利要求17的方法，其特徵在於為了計費，資源已經被預留但沒有真正使用的時間被估計。
19.根據權利要求17或18的方法，其特徵在於為了計費，關於共享資源的多個資源用戶的數量的信息被估計。
20.一種安排為執行用於通信網絡的資源管理的資源代理，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)，其特徵在於所述資源代理包括—發起裝置，用於資源使用量度(TTL)的發起，—獲取控制器，用於獲取用戶的使用量度(Keep Alive，InterestMsg)，其通知由至少一個資源用戶預期的資源使用，—更新控制器，用於藉助於累積算法使用用戶的使用量度(Keep Alive，InterestMsg)來更新資源使用量度(TTL)，該累積算法考慮資源使用量度(TTL)當前和過去的值，—檢查監視器，用於檢查資源使用量度，指示執行資源管理動作的必要性，—資源管理動作裝置，用於根據檢查監視器的結果執行資源管理動作。
21.根據權利要求20的資源代理，其特徵在於所述資源代理具有第一通信裝置用於與在所述代理和資源擁有者之間放置的第一通信接口交互，以及第二通信裝置用於與在所述代理和至少一個資源用戶之間放置的第二通信接口交互。
22.根據權利要求20或21的資源代理，其特徵在於所述資源代理具有第三通信裝置用於與在所述代理和計費單元之間放置的第三通信接口交互。
23.根據權利要求20的資源代理，其特徵在於所述資源代理適於使真實的資源通信量經過所述資源代理。
24.根據權利要求20至23中的一個的資源代理，其特徵在於所述資源代理適於提供不可靠的資源用於代理。
25.一種用於通信網絡的資源管理的系統，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)，其特徵在於所述系統包括根據權利要求17的被引入在資源擁有者(RO)和至少一個資源用戶(RU)之間的資源代理(RB)、在所述資源代理(RB)和資源擁有者(RO)之間的第一通信接口以及在所述資源代理(RB)和至少一個資源用戶(RU)之間的第二通信接口，其中所述資源代理適於執行根據權利要求1的方法。
26.根據權利要求25的系統，其特徵在於所述系統包括計費單元以及在資源代理和所述計費單元之間的第三通信接口。
全文摘要
本發明涉及一種用於在通信網絡中的資源管理的方法、設備和系統，該通信網絡具有提供資源的資源擁有者(RO)和至少一個使用資源的資源用戶(RU)。根據本發明，資源代理被引入在資源擁有者和至少一個資源用戶之間。所述代理被安排為執行管理過程用於決定是否執行資源的分配、保持或釋放。為了做出決定，資源使用量度(TTL)被使用。根據本發明，當得到通知資源用戶預期的對資源的使用的用戶使用量度(Keep Alive，Interest Msg)時，所述量度被更新。該更新通過累計算法被執行，該累積算法考慮資源使用量度(TTL)的當前和過去值。
文檔編號H04L29/06GK101023646SQ200480043841
公開日2007年8月22日 申請日期2004年8月21日 優先權日2004年8月21日
發明者F·亨德舍德特, A·赫裡比丘克 申請人:艾利森電話股份有限公司