服務(wù)會話資源管理本發(fā)明涉及服務(wù)會話資源管理，尤其但不排他地涉及用于設(shè)備的局域網(wǎng)中多個服務(wù)的并行使用的帶寬的管理。這種局域網(wǎng)的一個示例是以寬帶通信接入服務(wù)的訂戶為前提的網(wǎng)絡(luò)，例如，作為家庭或小企業(yè)網(wǎng)安裝的一部分提供以使得多個設(shè)備能夠通過單個寬帶使能通信線接入服務(wù)的網(wǎng)絡(luò)?？梢灶A(yù)期：對于位于相同局域網(wǎng)（LAN）內(nèi)的設(shè)備同時使用多個服務(wù)具有不斷增長的需求，這要求單個寬帶接入線的并行使用。這種需求通過諸如以下因素驅(qū)動：較高寬帶速度的可用性、家用中多個因特網(wǎng)使能設(shè)備的增加、多用戶家庭、以及因特網(wǎng)上數(shù)量不斷增長的可用內(nèi)容尤其是視頻服務(wù)的增加。管理用于接入多個服務(wù)的單個寬帶線的同時使用要求接入網(wǎng)絡(luò)上并且以服務(wù)訂戶為前提的家庭網(wǎng)絡(luò)內(nèi)可用帶寬的仔細(xì)管理。一般而言，在寬帶接入服務(wù)的銷售點(diǎn)，甚至在被預(yù)測具有寬帶接入的任意服務(wù)的銷售點(diǎn)，寬帶接入服務(wù)提供商不能確定什么服務(wù)組合將對客戶可用。例如，如果客戶具有兩個數(shù)字電視解碼器（通常已知為機(jī)頂盒（STB），盡管很少放置在電視機(jī)的頂部），如果每個流傳輸內(nèi)容頻道包含標(biāo)清（SD）電視（TV）頻道，則10Mbps的寬帶線速率將允許兩個STB同時顯示不同流傳輸?shù)膬?nèi)容頻道，但是如果需要高清（HD）TV頻道流，它所需要的額外帶寬將排除寬帶線上第二頻道（SD或HD）的流傳輸。為了在多個設(shè)備之間實(shí)施適當(dāng)?shù)闹俨梅?wù)，在使用點(diǎn)必須做出可以完成什么工作的實(shí)時判決而不折衷對于服務(wù)的接入和接入服務(wù)的服務(wù)質(zhì)量（QoS）。附圖的圖1示出通信系統(tǒng)10的一部分，其中，來自一個或更多外部數(shù)據(jù)源12的數(shù)據(jù)通過寬帶接入線16經(jīng)由多服務(wù)接入節(jié)點(diǎn)（MSAN）14流傳輸?shù)浇尤朦c(diǎn)/路由器設(shè)備18，該接入點(diǎn)/路由器設(shè)備18提供對于在以寬帶接入線服務(wù)訂戶為前提提供的局域網(wǎng)20中的多個用戶終端22、24的寬帶接入。如圖1所示，接入點(diǎn)/路由器18還提供對于用戶終端22、24的路由器支持，使得在（多個）有線通信鏈路26（例如，電力線和/或以太網(wǎng)鏈路）和/或無線通信鏈路28（例如WLAN或WIFI鏈路）上出現(xiàn)多個同時內(nèi)部會話且支持用戶終端22、24和外部內(nèi)容源16之間通過接入線16的外部會話。本領(lǐng)域中已知的這種集成接入點(diǎn)/路由器18的示例是BTHomeHubTM。用戶終端的示例包括數(shù)據(jù)消費(fèi)客戶端設(shè)備22，例如消費(fèi)諸如STB的內(nèi)容數(shù)據(jù)的設(shè)備、因特網(wǎng)協(xié)議（IP）使能TV、媒體流傳輸器、平板設(shè)備、音頻/視頻播放器、計(jì)算機(jī)設(shè)備和移動/固定電話設(shè)備。用戶終端的示例還包括位于LAN20中的數(shù)據(jù)資源設(shè)備24。數(shù)據(jù)資源設(shè)備24通過有線或無線通信鏈路26、28內(nèi)部地連接到路由器18以向數(shù)據(jù)消費(fèi)設(shè)備22分發(fā)諸如內(nèi)容的數(shù)據(jù)。內(nèi)部數(shù)據(jù)源設(shè)備24的示例例如包括：諸如個人視頻記錄器（PVR）的內(nèi)容源設(shè)備、內(nèi)容存儲設(shè)備以及諸如計(jì)算機(jī)、移動電話和網(wǎng)絡(luò)附加存儲（NAS）設(shè)備之類的存儲內(nèi)容的任意其它設(shè)備。術(shù)語內(nèi)容和等價術(shù)語內(nèi)容數(shù)據(jù)在本領(lǐng)域中是公知的且一般表示代表在內(nèi)容消費(fèi)設(shè)備上播放的音頻或視頻內(nèi)容的數(shù)據(jù)，例如電影、電視節(jié)目、音樂文件、游戲等，且可以具有多媒體數(shù)據(jù)格式。內(nèi)容數(shù)據(jù)通常對于用于播放用戶終端的帶寬資源和播放用戶終端上的處理資源提出高需求。對于新服務(wù)會話預(yù)留資源以接入內(nèi)容傳送服務(wù)的需求必須與維持確立的服務(wù)會話（內(nèi)容當(dāng)前通過該會話傳送）體驗(yàn)的服務(wù)質(zhì)量的需求相平衡。實(shí)際上，除非在到路由器18的接入鏈路16和客戶端22、24與路由器18之間的內(nèi)部鏈路二者上可用的帶寬不受限，否則必須部署一些仲裁處理。存在用于管理接入線上的帶寬以確保用于接入內(nèi)容和維持傳送的內(nèi)容的QoS的上述競爭需求之間的適當(dāng)平衡的各種方法。例如從國際專利說明書WO2007/081171已知獲得信息以確定在流傳輸來自家庭網(wǎng)絡(luò)外部的服務(wù)器的內(nèi)容時將預(yù)留的正確數(shù)量的帶寬。在該參考中，“外部服務(wù)器”（實(shí)際是包含多個服務(wù)器的外部網(wǎng)絡(luò)）被建模以確定所需的容量。美國專利6,738,819描述了基于網(wǎng)絡(luò)負(fù)載監(jiān)控而執(zhí)行準(zhǔn)入控制的方法。然而，在兩種情況中，方法通過各個客戶端設(shè)備操作，且不提供對于不能直接利用該容量的任意客戶端設(shè)備的支持。除非準(zhǔn)入控制被所有客戶端設(shè)備調(diào)用，否則分配處理可以針對所有客戶端設(shè)備折衷。本領(lǐng)域中已知的局部帶寬管理技術(shù)包括實(shí)施諸如在被UPnP論壇的籌劃指導(dǎo)委員會用作標(biāo)準(zhǔn)化DCP且于2008年11月30日發(fā)布的“UPnP-QoS架構(gòu)：3UPnP版本1.0”中描述的通用即插即用（UPnP）服務(wù)質(zhì)量（QoS）架構(gòu)的技術(shù)，其內(nèi)容此處通過引用結(jié)合于此。該文檔描述了一種會話管理設(shè)備，其適于提供局部帶寬管理能力以使得視頻流傳輸客戶端能夠確定它是否安全地啟動新的按需點(diǎn)播（VoD）或線性TV流（非VoDIPTV）而并沒有不利地影響任意現(xiàn)有流?？梢曰诋?dāng)前寬帶線速率和相關(guān)限制的了解以及在相同線上運(yùn)行的其它VoD和線性TV服務(wù)的了解（包括每個服務(wù)都消費(fèi)多少帶寬）做出這種判定。這種架構(gòu)中的UPnPQoS使能用戶終端22、24能夠與UPnPQoS使能路由器18針對帶寬進(jìn)行協(xié)商。UPnPQoS路由器18仲裁相同寬帶線16上和相同網(wǎng)絡(luò)20內(nèi)多個服務(wù)的同時使用。例如，如果用戶已經(jīng)使用一個服務(wù)且對于使用第二服務(wù)做出嘗試，且兩個服務(wù)的組合帶寬需求超過了客戶寬帶連接或局域網(wǎng)29其中任意一個的容量（例如，如果在已知為“WiFi的”IEEE802.11無線協(xié)議下操作，則第二嘗試將被阻斷或現(xiàn)有連接必須被暫停以允許第二嘗試被連接）。大多數(shù)有效仲裁解決方案要求所有用戶設(shè)備22、24和路由器18在仲裁處理中完全地協(xié)作。然而，除非連接到路由器18的所有用戶終端22、24支持仲裁能力，否則這將將難以實(shí)現(xiàn)。圖2針對類似的元件保持圖1的編號方案，且示出從UPnPQoS用戶終端22接收用于新會話的請求的UPnP服務(wù)質(zhì)量（QoS）服務(wù)管理器將如何實(shí)施這種寬帶仲裁處理。UPnPQoS服務(wù)管理器（通過查詢或通過檢索存儲值）確定寬帶接入線上的可用線速率且從它當(dāng)前預(yù)留以被現(xiàn)有會話使用的寬帶接入線資源的內(nèi)部狀態(tài)意識確定是否足有的資源可用于支持新服務(wù)器會話（步驟34）。如果所需資源不可用，例如，如果提供支持新服務(wù)會話所需的資源將不利地影響已經(jīng)通過一個或更多其它會話提供的服務(wù)的QoS，則適當(dāng)?shù)捻憫?yīng)被發(fā)送到請求UPnPQoS客戶終端，拒絕對于請求服務(wù)的接入（步驟46）。然而如果資源可用，則UPnPQoS服務(wù)管理器預(yù)留資源（步驟38）且更新其內(nèi)部狀態(tài)（步驟40），使得它保持用于未來請求管理預(yù)留的資源的了解。UPnPQoS服務(wù)管理器然后向請求UPnPQoS客戶端發(fā)送指示會話資源已經(jīng)被預(yù)留的響應(yīng)（步驟42）且UPnPQoS客戶終端22然后開始新會話（步驟44）。圖3針對類似的元件保持圖1的編號方案，且示意性示出當(dāng)無UPnP能力且不能以這種方式與UPnPQoS服務(wù)管理器協(xié)作的客戶終端22也通過將接入線16請求服務(wù)時將發(fā)生什么。在圖3中，在通過非UPnPQoS使能客戶終端22產(chǎn)生新會話請求（步驟60）之后，新會話開始通過寬帶接入線使用資源而無需在先的預(yù)留（步驟62）（備選地，它可以預(yù)留接入線上的資源而不參考uPnPQoS服務(wù)管理器）。隨之而來的帶寬利用意味著現(xiàn)有會話可能具有較小帶寬且所以可能體驗(yàn)其服務(wù)質(zhì)量的下降或甚至不成熟的終止。如圖3示意性示出，接入線（62）的這種使用影響UPnPQoS服務(wù)管理器的操作，因?yàn)槠鋬?nèi)部狀態(tài)以兩種方式不再如圖2所述的那樣精確。首先，當(dāng)新會話使用不被UPnPQoS服務(wù)管理器預(yù)留的資源且因此圖2中的步驟（34）將不檢索在接入線上利用的實(shí)際帶寬。其次，資源預(yù)留（56）影響的現(xiàn)有會話的帶寬利用的任意突降或終止也可以不能傳輸?shù)経PnPQoS管理服務(wù)器。這些影響意味著UPnPQoS服務(wù)管理器將不再具有針對寬帶接入線上的實(shí)際資源利用而被存儲的正確內(nèi)部狀態(tài)。因此，在非UPnOQoS客戶終端22服務(wù)會話存在的同時UPnPQoS服務(wù)管理器的進(jìn)行中性能將折衷，因?yàn)镼oS服務(wù)管理器將基于在寬帶通信接入線16上存在比針對任意給定線速率實(shí)際可用的帶寬更大的帶寬做出判定。因此，取決于路由器18仲裁源于客戶終端的數(shù)據(jù)請求的環(huán)境和方式，非UPnPQoS客戶終端可以奪取它們需要的所有帶寬而沒有任意競爭需求，或者不能獲得它們需要的帶寬或在會話期間無警告地突然失去連接。類似地，由于UPnPQoS服務(wù)管理器缺少非UPnPQoS客戶終端會話通過接入線消費(fèi)的帶寬的任意了解，UPnPQoS服務(wù)管理支持客戶端終端將損害。這些結(jié)果中的任何一個都不導(dǎo)致用戶的良好體驗(yàn)。因此，希望提供一種請求仲裁系統(tǒng)，其將針對來自連接到路由器的所有終端的數(shù)據(jù)請求進(jìn)行操作而無需各個終端中的任意特殊能力。本發(fā)明的第一方面尋求提供一種服務(wù)會話請求截取器，該服務(wù)請求截取器被布置為截取在通信網(wǎng)絡(luò)中由客戶終端產(chǎn)生的針對數(shù)據(jù)服務(wù)的請求，該截取器包括：用于接收所述多個客戶終端產(chǎn)生的服務(wù)請求的裝置；用于確定接收的服務(wù)請求的目的地地址的裝置；用于從被確定為與一個或更多預(yù)定截取觸發(fā)目的地地址匹配的目的地地址截取對于內(nèi)容的服務(wù)請求的裝置；用于針對每個所述截取的服務(wù)請求確定用于所述被請求的服務(wù)的所需資源的裝置；用于向資源管理器轉(zhuǎn)發(fā)用于所述所需資源的資源預(yù)留請求的裝置；以及用于根據(jù)從所述資源管理器接收到所述所需資源已被預(yù)留的指示，向所述目的地地址轉(zhuǎn)發(fā)接收到的請求的裝置。用于請求的服務(wù)的所需資源可以從目的地地址得出，且尤其從所述服務(wù)請求尋址的統(tǒng)一資源定位符得出。備選地，所需資源可以通過統(tǒng)一資源定位符的格式和/或內(nèi)容指示。資源可以包含有線或無線通信鏈路上的帶寬。服務(wù)請求截取器還可以包括布置為處理來自所述資源管理器的拒絕請求消息以提取使得能夠識別已預(yù)留資源的并行服務(wù)會話的信息的裝置。服務(wù)請求截取器還可以包括：用于截取由服務(wù)請求客戶終端產(chǎn)生的服務(wù)會話請求的裝置；用于確定用于滿足所述服務(wù)會話請求以維持一個或更多預(yù)定傳送標(biāo)準(zhǔn)所需的至少一個會話資源的裝置；用于確定至少一個所需會話資源不可用的裝置；用于拒絕所述服務(wù)請求的裝置；以及用于向所述服務(wù)請求用戶終端提供與利用所述至少一個服務(wù)會話資源的至少一個其它服務(wù)會話相關(guān)的信息的裝置，由此，所述客戶終端的用戶能夠接收到所述信息，并且根據(jù)所述信息來選擇性地修改所述至少一個其它服務(wù)會話中的所述至少一個。服務(wù)請求截取器還可以包括：用于產(chǎn)生用于所提取的信息的信息標(biāo)識符的裝置；用于產(chǎn)生包括所述信息標(biāo)識符的重定向消息的裝置；用于將包括所述信息標(biāo)識符的所述重定向信息發(fā)送到發(fā)出被拒絕的服務(wù)請求的客戶終端的裝置；以及響應(yīng)于從請求數(shù)據(jù)服務(wù)器接收到請求所述所提取的信息的消息向所述請求數(shù)據(jù)服務(wù)器提供所述所提取的信息的裝置，該消息使用所述信息標(biāo)識符來識別被請求的信息。本發(fā)明還擴(kuò)展到一種系統(tǒng)，該系統(tǒng)包括如上限定的服務(wù)請求截取器和數(shù)據(jù)服務(wù)器，該數(shù)據(jù)服務(wù)器包括：布置為從客戶終端接收消息的裝置；從所述接收到的消息中提取所述信息標(biāo)識符的裝置；產(chǎn)生所述消息以從所述服務(wù)請求截取器請求信息的裝置，該消息包括所述信息標(biāo)識符；由此，響應(yīng)于從所述服務(wù)請求截取器接收到所述信息，所述數(shù)據(jù)服務(wù)器向所述客戶終端提供所述信息。本發(fā)明還擴(kuò)展至用于局域網(wǎng)的路由器，該路由器能夠在通信鏈路上路由多個至少部分同時的服務(wù)會話，該路由器包括如上限定的服務(wù)請求截取器，且還包括資源管理器，該資源管理器包括：存儲用于所述通信鏈路的資源的當(dāng)前資源利用指示符的裝置；通過所述通信鏈路接收要求資源預(yù)留的服務(wù)會話請求的裝置；處理接收到的請求，且根據(jù)所述當(dāng)前資源利用指示符和在所述通信鏈路上的最大資源可用性的確定，在所述通信鏈路上可用時預(yù)留所需資源的裝置，其中，響應(yīng)于從所述服務(wù)請求截取器接收到請求，所述當(dāng)前資源利用指示符通過所述服務(wù)請求處理器更新，以指示通過一個或更多客戶終端建立的一個或更多服務(wù)會話使用的資源，所述一個或更多客戶終端被配置成在所述通信線路上發(fā)送服務(wù)請求，而無需從所述服務(wù)會話管理器請求對于服務(wù)的接入。該路由器還可以包括：多個用戶端口，每個端口用于連接到所述客戶終端，外部連接端口；用于在所述端口和所述外部連接端口之間發(fā)送數(shù)據(jù)和對于數(shù)據(jù)的請求的切換裝置；線速率校驗(yàn)器；一個或更多數(shù)據(jù)處理器，其布置為實(shí)施所述服務(wù)會話資源管理器，用于處理在每個端口接收的服務(wù)會話數(shù)據(jù)請求，并且選擇將被轉(zhuǎn)發(fā)到所述外部連接端口的服務(wù)會話請求。備選地，在路由器上執(zhí)行截取，但是確立資源預(yù)留需求所需的所有其它功能性做出預(yù)留請求，且使得對于請求的判定可以在路由器組件外部實(shí)施，例如在PC、STB、NAS或附屬于路由器的另一組件或在中央網(wǎng)絡(luò)位置實(shí)施。根據(jù)另一方面，本發(fā)明提供一種服務(wù)會話資源管理方法，在通信網(wǎng)絡(luò)中由客戶終端產(chǎn)生的針對數(shù)據(jù)服務(wù)的請求被截?。捍_定每個接收到的服務(wù)請求的目的地地址；從被確定為與一個或更多預(yù)定截取觸發(fā)目的地地址匹配的目的地地址識別針對將被檢索的內(nèi)容的服務(wù)請求；針對每個所述截取的服務(wù)請求，確定用于所述被請求的服務(wù)的所需資源；產(chǎn)生用于所述所需資源的資源預(yù)留請求，以及確定所述所需資源是否可用，如果所述所需資源可用，則預(yù)留所述所需資源，如果所述所需資源已被預(yù)留，則將接收到的請求轉(zhuǎn)發(fā)到所述目的地地址。該方法還包括更新當(dāng)前資源利用指示符，以指示通過一個或更多客戶終端建立的一個或更多服務(wù)會話使用的資源，所述一個或更多客戶終端被配置成在所述通信線路上發(fā)送服務(wù)請求，而無需從所述服務(wù)會話管理器請求對于服務(wù)的接入。該方法還可以包括以下步驟：截取由服務(wù)請求客戶終端產(chǎn)生的服務(wù)會話請求；確定用于滿足所述服務(wù)會話請求以維持一個或更多預(yù)定傳送標(biāo)準(zhǔn)所需的至少一個會話資源；確定至少一個所需會話資源不可用；拒絕所述服務(wù)請求；以及，向所述服務(wù)請求用戶終端提供與利用所述至少一個服務(wù)會話資源的至少一個其它服務(wù)會話相關(guān)的信息，由此，所述客戶終端的用戶能夠接收到所述信息，并且根據(jù)所述信息來選擇性地修改所述至少一個其它服務(wù)會話中的所述至少一個。這樣，當(dāng)不支持UPnPQoS服務(wù)管理的客戶終端例如通過請求使用針對形成具有高于最佳努力轉(zhuǎn)發(fā)類的優(yōu)先級的數(shù)據(jù)流的包預(yù)留的帶寬的服務(wù)嘗試請求將使用接入網(wǎng)絡(luò)通信鏈路上“優(yōu)質(zhì)”帶寬的服務(wù)時，也使用優(yōu)選帶寬的其它服務(wù)將較不可能被意外或不利地影響，因?yàn)閁PnPQoS服務(wù)管理器現(xiàn)在可以監(jiān)控這種客戶終端帶寬利用。資源管理器優(yōu)選地是在UPnPQoS服務(wù)管理架構(gòu)標(biāo)準(zhǔn)（諸如標(biāo)準(zhǔn)的版本3）中指定類型的通用即插即用（UPnP）服務(wù)質(zhì)量（QoS）服務(wù)管理器。通信鏈路可以包括容放諸如異步數(shù)字用戶線（ADSL）鏈路或其它類型的DSL鏈路的寬帶接入線的線，且所述通信鏈路上的資源可以包含使用所述寬帶接入鏈路可用的帶寬。備選地，通信鏈路可以包含內(nèi)部鏈路和位于經(jīng)由路由器連接的局域網(wǎng)內(nèi)的多個設(shè)備，在該路由器上布置所述服務(wù)會話資源管理器。通信鏈路可以包含無線或有線通信信道且可以在其它客戶端設(shè)備內(nèi)部或在LAN外部。適當(dāng)時，路由器設(shè)備配置成保持通信信道上可用帶寬（或等價地數(shù)據(jù)速率）的容量的估算且使得該容量可用于QoS服務(wù)會話管理器。向QoS服務(wù)會話管理器指示（或被QoS服務(wù)會話管理器使用）的值優(yōu)選地稍小于理論帶寬或可用的數(shù)據(jù)速率。例如，當(dāng)路由器使得某一帶寬值在無線信道上可用時，從理論速率的10%以下到10%的任意值可用。類似地，電力線用作通信鏈路（例如路由器設(shè)備18上設(shè)備和以太網(wǎng)接口之間的連接）的實(shí)施方式可以要求實(shí)際帶寬調(diào)節(jié)到最低值以允許安全余量。寬帶接入鏈路可以使用銅、線纜、光纖或無線（例如3G、WiMax等）鏈路提供。新服務(wù)會話請求可以被服務(wù)請求截取器截取以確定其資源需求，由此在服務(wù)會話資源預(yù)留請求中確定的資源需求通過服務(wù)請求截取器轉(zhuǎn)發(fā)到所述服務(wù)請求處理器。服務(wù)會話資源管理器還包括在從所述資源利用指示符確定存在不足資源用于所述一個或更多客戶端中的所述一個請求的新服務(wù)會話時導(dǎo)致錯誤消息被發(fā)送到所述一個或更多客戶端其中一個的裝置。如果從所述資源利用指示符確定存在足夠的資源用于所述一個或更多客戶終端其中一個請求的新服務(wù)會話時，所述一個或更多客戶終端被配置成通過所述通信線發(fā)送服務(wù)器請求，而無需從所述服務(wù)會話管理器請求對于服務(wù)的接入，則所述服務(wù)會話資源管理器可以預(yù)留用于所述新服務(wù)會話的資源。錯誤消息可以指示在所述通信線上使用所述資源的一個或更多現(xiàn)有會話。如果新服務(wù)會話或一個或更多指示的現(xiàn)有服務(wù)會話被用戶優(yōu)選，接收所述錯誤消息的客戶終端還可以請求終端的用戶提供的會話偏好信息，其中響應(yīng)于所述會話偏好信息被傳輸?shù)剿龇?wù)會話資源管理器，所述服務(wù)會話資源管理器根據(jù)所述會話偏好信息預(yù)留資源。如果所述會話偏好信息針對新服務(wù)會話指示用于優(yōu)于現(xiàn)有服務(wù)會話的用戶偏好，識別所述現(xiàn)有服務(wù)會話的會話偏好信息可以被傳輸?shù)铰酚善骰蛲獠繑?shù)據(jù)源或在所述通信線的服務(wù)器端的遠(yuǎn)程接入服務(wù)器，其中所述路由器或外部數(shù)據(jù)源或遠(yuǎn)程接入服務(wù)器根據(jù)所述用戶偏好信息修改現(xiàn)有服務(wù)會話和/或終止所述服務(wù)會話?，F(xiàn)有服務(wù)會話可以被修改為增加或減小所述會話偏好信息中識別的現(xiàn)有服務(wù)會話使用的預(yù)留資源。所述會話偏好信息中識別的現(xiàn)有服務(wù)會話可以被終止。資源可以包含所述通信線上的帶寬。服務(wù)會話可以用于數(shù)據(jù)流。數(shù)據(jù)流可以包含音頻和/或視頻內(nèi)容數(shù)據(jù)。原則上它可以擴(kuò)展到家庭環(huán)境中的非音頻/視頻流量，例如VPN流量。服務(wù)會話管理器可以包括UPnP使能服務(wù)質(zhì)量（QoS）服務(wù)管理器且所述當(dāng)前資源利用指示符可以通過所述服務(wù)請求處理器更新以指示通過配置成不支持UPnP服務(wù)質(zhì)量服務(wù)管理的一個或更多客戶終端確立的一個或更多服務(wù)會話使用的資源，所述一個或更多客戶終端通過所述通信線發(fā)送服務(wù)請求，而無需從所述UPnP使能服務(wù)質(zhì)量服務(wù)管理器請求對于服務(wù)的接入。本發(fā)明的另一方面包括在一種能夠在通信線上在多個客戶終端之間路由多個服務(wù)會話的路由器中的服務(wù)會話資源管理的方法，該方法包括以下步驟：存儲用于所述通信線的資源的當(dāng)前資源利用指示符；處理來自所述多個客戶終端中的一個的新服務(wù)會話請求以確定所述通信線上用于所述新服務(wù)會話的所需資源；根據(jù)可用線速率和所述當(dāng)前利用指示符確定資源是否對于所述請求的服務(wù)會話可用；預(yù)留所需資源；更新所述當(dāng)前利用指示符以指示允許的資源預(yù)留；以及響應(yīng)于所述資源被預(yù)留的所述客戶端，其中該方法還包括：更新當(dāng)前資源利用指示符，以指示通過一個或更多客戶終端建立的一個或更多服務(wù)會話使用的資源，所述一個或更多客戶終端被配置成在所述通信線路上發(fā)送服務(wù)請求，而無需從所述服務(wù)會話管理器請求對于服務(wù)的接入。本發(fā)明的另一方面包括一種用于包括多個客戶終端的局域通信網(wǎng)絡(luò)的路由器，該路由器包括根據(jù)本發(fā)明的上述方面的服務(wù)會話資源管理器。路由器還可以包括：多個用戶端口，每個端口用于連接到所述客戶終端；外部連接端口；用于在端口和所述外部連接端口之間發(fā)送數(shù)據(jù)和用于數(shù)據(jù)的請求的切換裝置；線速率校驗(yàn)器；以及一個或更多數(shù)據(jù)處理器，布置為實(shí)施所述服務(wù)會話資源管理器且布置為用于處理在每個端口接收的服務(wù)會話數(shù)據(jù)且選擇哪個服務(wù)會話請求將被轉(zhuǎn)發(fā)到外部連接端口。用戶端口中的一個或更多個可以具有相關(guān)服務(wù)請求截取器，該相關(guān)服務(wù)請求截取器具有：終端識別裝置，用于識別附連到所述一個或更多用戶端口的相應(yīng)一個的用戶終端；截取裝置，用于截取在所述一個或更多用戶端口接收的服務(wù)會話數(shù)據(jù)請求和服務(wù)會話資源管理器產(chǎn)生的任意響應(yīng)數(shù)據(jù)；數(shù)據(jù)調(diào)適裝置，用于調(diào)適服務(wù)會話資源管理器產(chǎn)生的任意所述響應(yīng)數(shù)據(jù)；傳輸裝置，向連接到端口的用戶終端轉(zhuǎn)發(fā)調(diào)適的響應(yīng)數(shù)據(jù)，其中路由器還配置成更新所述服務(wù)會話資源管理器的所述當(dāng)前資源利用指示符以指示被一個或更多截取的服務(wù)會話數(shù)據(jù)請求使用的資源。本發(fā)明的另一方面涉及用于局域通信網(wǎng)絡(luò)的路由器，該路由器具有：用于連接到多個用戶終端的多個用戶端口；用于在端口和所述外部連接端口之間發(fā)送數(shù)據(jù)和用于數(shù)據(jù)的請求的切換裝置；以及仲裁處理器，具有：請求處理器，處理在每個端口接收的數(shù)據(jù)請求且選擇哪個數(shù)據(jù)請求將被轉(zhuǎn)發(fā)到外部連接端口；以及響應(yīng)處理器，向接收請求的相應(yīng)端口返回涉及數(shù)據(jù)請求的響應(yīng)數(shù)據(jù)；其中用戶端口中的一個或更多個具有相關(guān)服務(wù)請求截取器，相關(guān)服務(wù)請求截取器具有：用于識別附連到用戶端口的用戶終端的終端識別裝置；用于截取在端口接收的數(shù)據(jù)請求和仲裁處理器產(chǎn)生的響應(yīng)數(shù)據(jù)的截取裝置；以及用于產(chǎn)生調(diào)適于連接到端口的用戶終端的響應(yīng)數(shù)據(jù)的數(shù)據(jù)調(diào)適裝置。相關(guān)服務(wù)請求截取器用作代理，允許未裝配有仲裁工具的“遺留”用戶終端在帶寬的協(xié)商中協(xié)作。具體而言，它可以允許路由器被告知設(shè)備所需的帶寬，或它應(yīng)當(dāng)被賦予的任意優(yōu)先級（例如，通過請求的數(shù)據(jù)的識別或通過允許一個用戶在仲裁用于數(shù)據(jù)的請求中被賦予優(yōu)先級的用戶產(chǎn)生的密碼）。服務(wù)請求截取器還可以以適于在用戶設(shè)備上顯示的形式產(chǎn)生數(shù)據(jù)，例如，用以告知用戶為什么數(shù)據(jù)請求被拒絕或現(xiàn)有流將被終止以導(dǎo)致以“優(yōu)雅”方式發(fā)生任何必要的斷開。服務(wù)請求截取器還可以布置為當(dāng)針對帶寬的需求減小到可以適應(yīng)請求的級別時例如通過提示客戶重新提交原先拒絕的請求（SRI然后截取且轉(zhuǎn)發(fā)到QoS服務(wù)管理器）重新提交原先被拒絕或中斷的請求。本發(fā)明的另一方面尋求提供一種用于被資源仲裁使能客戶終端和資源仲裁非使能客戶終端二者使用的通信線的服務(wù)會話資源仲裁器，該資源仲裁器包括：接收服務(wù)會話資源請求的裝置；確定請求的資源的可用性的裝置；響應(yīng)接收的服務(wù)會話資源請求以指示所述請求被準(zhǔn)許的裝置；其中確定請求的資源的可用性的所述裝置包括通過資源仲裁使能和非資源仲裁使能客戶終端二者請求的服務(wù)的資源利用的確定。因此本發(fā)明能夠?yàn)榉荱PnPQoS服務(wù)管理支持客戶終端提供關(guān)于使用防止來自客戶終端的服務(wù)請求被接受的資源的其它服務(wù)會話的信息，該方法包括以下步驟：從客戶終端截取服務(wù)請求；產(chǎn)生用于服務(wù)請求的請求標(biāo)識符；以及產(chǎn)生用于所述請求的服務(wù)的流量描述符；向擴(kuò)展UPnPQoS服務(wù)管理器轉(zhuǎn)發(fā)用于服務(wù)請求的所述流量描述符；從所述擴(kuò)展UPnPQoS服務(wù)管理器接收包括錯誤消息的拒絕消息，該錯誤消息包括識別所述其它服務(wù)會話和所述流量描述符的信息；從所述流量描述符確定用于所述拒絕請求的請求標(biāo)識符；存儲與確定的請求標(biāo)識符相關(guān)的錯誤信息；產(chǎn)生包括所述請求標(biāo)識符和布置為動態(tài)產(chǎn)生錯誤信息的網(wǎng)絡(luò)服務(wù)器的地址的重定向消息；將重定向消息發(fā)送到所述客戶端。在客戶終端，響應(yīng)于所述重定向消息的接收，包括所述請求標(biāo)識符的HPPT請求被重定向到所述網(wǎng)絡(luò)服務(wù)器。接收包括所述請求標(biāo)識符的所述HTTP請求的網(wǎng)絡(luò)服務(wù)器通過以下步驟處理HTTP請求：提取所述請求標(biāo)識符；產(chǎn)生用于包括提取的請求標(biāo)識符的錯誤信息的請求；向所述服務(wù)請求截取器發(fā)送所述請求；接收使用所述請求標(biāo)識符定位所述錯誤信息的所述服務(wù)請求截取器檢索的錯誤信息；以及產(chǎn)生包含所述錯誤信息的網(wǎng)頁，由此客戶終端顯示如此產(chǎn)生的所述網(wǎng)頁。在上文和隨附的獨(dú)立和從屬權(quán)利要求中提及了本發(fā)明的多個方面和實(shí)施方式，它們可以以本領(lǐng)域技術(shù)人員顯見的任意方式組合。服務(wù)質(zhì)量條件可以包含以下一個或更多個：預(yù)定范圍的等待時間、可變延時、編碼質(zhì)量、色飽和度、關(guān)于圖像質(zhì)量的感覺平均評價分?jǐn)?shù)等。資源可以包含以下一個或更多個：到接入點(diǎn)的寬帶接入線上的帶寬，客戶終端經(jīng)由該接入點(diǎn)被提供以到所述寬帶線的接入；服務(wù)請求設(shè)備和接入點(diǎn)之間的有線或無線路徑上到服務(wù)請求設(shè)備的通信信道上的帶寬，客戶終端經(jīng)由該接入點(diǎn)被提供以到所述寬帶線的接入；服務(wù)請求設(shè)備和布置為提供所述被請求的服務(wù)的所述多個客戶終端中的服務(wù)提供終端之間的有線或無線路徑上到服務(wù)請求設(shè)備的通信信道上的帶寬；服務(wù)請求設(shè)備和所述服務(wù)提供設(shè)備之間的有線或無線路徑上到服務(wù)提供設(shè)備的通信信道上的帶寬?，F(xiàn)在將參考附圖描述本發(fā)明的實(shí)施方式，實(shí)施方式僅通過示例的方式給出，且附圖中：圖1是其中內(nèi)容數(shù)據(jù)被局域網(wǎng)內(nèi)多個不同設(shè)備消費(fèi)的通信系統(tǒng)的示意圖；圖2是示出實(shí)施圖1的局域網(wǎng)中示出的路由器中的UPnPQoS服務(wù)管理的方法中的步驟的流程圖；圖3是不支持UPnPQoS服務(wù)管理的客戶終端產(chǎn)生的會話對圖2中示出的方法的影響的示意圖；圖4是包括根據(jù)本發(fā)明的實(shí)施方式的服務(wù)會話資源管理器和與之協(xié)作的多個用戶設(shè)備的路由器的示意圖；圖5a是示出根據(jù)本發(fā)明的實(shí)施方式實(shí)施服務(wù)會話資源管理的方法中的步驟的流程圖；圖5b是示出根據(jù)本發(fā)明的備選實(shí)施方式實(shí)施服務(wù)會話資源管理的方法中的步驟的流程圖；圖6是示出在根據(jù)本發(fā)明的另一實(shí)施方式實(shí)施服務(wù)會話資源管理的方法中執(zhí)行的附加步驟的流程圖；圖7是示出根據(jù)本發(fā)明的又一實(shí)施方式通過實(shí)施服務(wù)會話資源管理的方法執(zhí)行的步驟的流程圖；圖8更詳細(xì)地示出如何實(shí)施HTTP重定向以通過在圖5b中示出的本發(fā)明的實(shí)施方式中的UPnPQoS服務(wù)管理器傳輸服務(wù)請求被拒絕接入；圖9示出用于本發(fā)明的實(shí)施方式的資源預(yù)留和后續(xù)刷新的消息的流程；圖10a示出根據(jù)本發(fā)明的實(shí)施方式如何告知QoS服務(wù)管理器IGMP服務(wù)會話何時終止；以及圖10b示出根據(jù)本發(fā)明的實(shí)施方式如何告知QoS服務(wù)管理器HTTP服務(wù)會話何時終止；圖11示出如何針對HTTP和IGMP截取服務(wù)請求確定資源需求；以及圖12示出確定用于HTTP和IGMP服務(wù)請求的資源需求的備選方式?，F(xiàn)在將參考附圖描述發(fā)明人目前設(shè)計(jì)的本發(fā)明的最佳模式。圖4示出根據(jù)本發(fā)明的實(shí)施方式的接入點(diǎn)/路由器18，其中路由器的功能性與如圖1所示到寬帶接入線16的接入點(diǎn)提供的功能性相關(guān)。備選地，分離的接入點(diǎn)和路由器可以用于實(shí)施本發(fā)明。除非上下文明確指示，否則此后接入點(diǎn)/路由器功能性此處將通過術(shù)語“路由器”引用。如圖4所示，路由器18包括根設(shè)備70，該根設(shè)備70包括預(yù)留用于維持通過連接到寬帶接入線16的外部端口（未示出）確立的服務(wù)會話的QoS的資源的裝置。根設(shè)備70包括配置成支持各種服務(wù)的很多嵌入設(shè)備72、74以及布置為在競爭接入線上帶寬的并發(fā)服務(wù)會話請求之間進(jìn)行仲裁以管理請求的服務(wù)會話的服務(wù)質(zhì)量的帶寬仲裁器裝置。仲裁器裝置通過使用服務(wù)會話資源或服務(wù)質(zhì)量（QoS）管理器72實(shí)施，例如通過諸如如圖4所示的UPnPQoS服務(wù)管理器這樣的服務(wù)會話資源管理器實(shí)施。QoS管理器72（此處等價地也稱為資源管理器或QoS服務(wù)管理器或UQoSM）慣例地包括一般遵循名為“UPnPQoS管理器3：用于UPnP版本1.0的服務(wù)模板版本1.01”且于2008年11月3日發(fā)布的UPnPQoS管理器設(shè)備控制協(xié)議（DCP）標(biāo)準(zhǔn)的第三版本的組件，其全部內(nèi)容此處通過引用合并于此，且在書寫時可以從http://www.upnp.org/specs/qos/UPnP-qos-QosManager-v3-Service.pdf下載，其慣例地部署在遵循狀態(tài)為標(biāo)準(zhǔn)化DCP且于2008年11月30日發(fā)布的名為“用于UPnP版本1.0的UPnPQoS架構(gòu):3”的UPnPQoS架構(gòu)DCP標(biāo)準(zhǔn)的第三版本的架構(gòu)中，其全部內(nèi)容此處通過引用合并于此，且在書寫時可以從http://www.upnp.org/specs/qos/UPnP-qos-Architecture-v3.pdf下載，根據(jù)本發(fā)明，除了或取代從UPnPQoS服務(wù)管理使能客戶終端22b接收請求，UQoSM72布置為從也使用標(biāo)準(zhǔn)UPnPQoSv3協(xié)議信息的服務(wù)請求截取器（SRI）76接收QoS服務(wù)請求。SRI76截取一般地沒有使用UPnPQoS服務(wù)管理協(xié)議（或具體而言版本3，如果客戶終端用于接收回關(guān)于競爭服務(wù)會話的信息）的能力的客戶終端22a（或24a，如果這種數(shù)據(jù)提供終端此時用作接收數(shù)據(jù)的客戶終端）產(chǎn)生的服務(wù)請求。SRI處理截取的請求以確定足夠的信息以產(chǎn)生與UQoSM72在其下操作的UPnPQoS服務(wù)管理通信協(xié)議的版本兼容的服務(wù)請求，以確保滿足用于一個或更多預(yù)定傳送條件的需求，例如，根據(jù)本發(fā)明，用于在滿足服務(wù)請求時提供預(yù)定級別的QoS。SRI76確定諸如帶寬之類所需的資源且通過向UQoSM76提供該信息，UWoSM72內(nèi)部存儲的資源利用的狀態(tài)，例如，寬帶通信接入16線（任何其它內(nèi)部信道）上的帶寬資源利用通過UQoSM72更新。這樣，作為UQoSM72從預(yù)留諸如帶寬之類的資源的任意UPnPQoS服務(wù)管理支持客戶終端22b（此處也被稱為“仲裁客戶終端”）接收服務(wù)請求的結(jié)果，且作為服務(wù)請求截取器（SRI）76產(chǎn)生用于非仲裁客戶終端22a的請求的結(jié)果，UQoSM72更新其內(nèi)部狀態(tài)。SRI76通過監(jiān)控面對客戶終端22、24的路由器18上的多個端口（未示出）且截取遵循預(yù)定截取標(biāo)準(zhǔn)（在某些情形下可以動態(tài)地變化，參見稍后的描述）的服務(wù)請求完成這點(diǎn)。截取的請求源自于不支持QoS服務(wù)管理器72提供的UPnPQoS服務(wù)管理的客戶終端22a。不支持UPnPQoS服務(wù)管理的客戶終端22a此處也被稱為“非UPnPQoS服務(wù)管理支持客戶終端”或非仲裁客戶終端。如上所述，盡管此處對于包括消費(fèi)內(nèi)容的用戶終端的客戶終端22a、b做出參考，但是，圖1中示出的內(nèi)部內(nèi)容源設(shè)備24也可以包括這種內(nèi)容消費(fèi)設(shè)備22a、b。SRI優(yōu)選地配置成僅截取針對所謂的優(yōu)質(zhì)內(nèi)容服務(wù)（包括這種服務(wù)：響應(yīng)于服務(wù)請求被接受提供的數(shù)據(jù)流中的包將具有高于用于數(shù)據(jù)轉(zhuǎn)發(fā)目的的最佳努力的優(yōu)先級的包）的請求。這種服務(wù)還已知為“優(yōu)質(zhì)帶寬”服務(wù)，因?yàn)樗鼈兪褂每煞直婢哂懈哂谟糜跀?shù)據(jù)轉(zhuǎn)發(fā)目的的最佳努力的優(yōu)先級的包的帶寬。由于不具有與用于優(yōu)質(zhì)帶寬服務(wù)服務(wù)器的目的地IP地址匹配的目的地IP地址，一些非優(yōu)質(zhì)帶寬請求從截取處理消除。當(dāng)目的地IP地址被識別時，作為有效載荷在TCP包中運(yùn)送的HTTP請求也使用某種合適的機(jī)制（例如通過深層數(shù)據(jù)包檢查）檢查。如果HTTP請求包含用于對應(yīng)于優(yōu)質(zhì)帶寬服務(wù)的請求數(shù)據(jù)的統(tǒng)一資源定位符時，HTTP請求被SRI76截取。然而，如果HTTP請求涉及從不是優(yōu)質(zhì)帶寬服務(wù)的相同目的地地址可用的另一服務(wù)（它僅需要針對請求的數(shù)據(jù)的最佳努力包轉(zhuǎn)發(fā)），則截取的服務(wù)請求通過SRI釋放以被轉(zhuǎn)發(fā)到其目的地。如圖4所示，QoS服務(wù)管理器72布置為響應(yīng)于從支持UPnPQoS服務(wù)管理器的客戶終端22b接收服務(wù)會話請求而調(diào)用因特網(wǎng)網(wǎng)關(guān)嵌入設(shè)備74中的QoS設(shè)備服務(wù)80。服務(wù)請求截取器（SRI）76監(jiān)控面對局域網(wǎng)20的路由器18上的多個端口，客戶終端22a、b從該端口產(chǎn)生服務(wù)請求。來自客戶終端22b的服務(wù)請求經(jīng)過SRI76而沒有QoS服務(wù)管理器72處理的截取。然而，當(dāng)在通過SRI76監(jiān)控的端口上接收來自客戶終端22a的服務(wù)請求時，服務(wù)請求被截取。如果確定針對將使用優(yōu)質(zhì)帶寬傳送的服務(wù)的請求，則SRI76不允許截取的服務(wù)請求通過外部地面對寬帶接入線16的端口轉(zhuǎn)發(fā)出去，直到QoS服務(wù)管理器72指示足夠的資源可用且使用截取的服務(wù)請求所需的資源更新資源利用的內(nèi)部存儲狀態(tài)。在一個實(shí)施方式中，QoS服務(wù)管理器72通過寬帶接入線16更新其資源利用的內(nèi)部存儲狀態(tài)的資源利用數(shù)量通過SRI76確定，但是在其它實(shí)施方式中可以通過QoS服務(wù)管理器72確定。例如，用于客戶終端22a產(chǎn)生的內(nèi)容流的每個截取的服務(wù)請求被分析以確定其資源需求（諸如，例如，其轉(zhuǎn)發(fā)類、優(yōu)先級和帶寬需求）。確定資源需求的一種方式是識別與請求的內(nèi)容流相關(guān)的媒體特性的類型。如果請求的內(nèi)容流包含標(biāo)清或高清電視頻道，例如，SRI76從QoS服務(wù)管理器72產(chǎn)生用于該帶寬量的服務(wù)資源請求。這使得QoS服務(wù)管理器能夠確定相關(guān)帶寬量是否可用，且如果可用，通過通信線16預(yù)留該帶帶寬。在書寫本說明書時是不支持UPnPQoS服務(wù)管理的客戶終端22a的類型的示例例如包括運(yùn)行BBCiPlayer、iTune、AppleTMTV內(nèi)容消費(fèi)應(yīng)用的客戶終端。在本發(fā)明的一個實(shí)施方式中，當(dāng)客戶終端22a首先連接到路由器18上的端口時，客戶端控制模塊識別設(shè)備且產(chǎn)生服務(wù)請求截取器應(yīng)用。每個SRI應(yīng)用的角色是從不具有仲裁能力的客戶端設(shè)備22a截取超文本傳輸協(xié)議（HTTP）服務(wù)請求和因特網(wǎng)組管理協(xié)議（IGMP）服務(wù)請求，如果QoS服務(wù)會話管理器72包括UQoSM72，則諸如是不支持UPnPQoS服務(wù)管理的客戶端設(shè)備。如上所述，HTTP和IGMP服務(wù)請求通過SRI應(yīng)用分析以確定響應(yīng)于來自外部數(shù)據(jù)源12的服務(wù)請求而傳送的數(shù)據(jù)將在寬帶接入線16上需要的資源。一旦滿足請求的服務(wù)所需的寬帶接入線資源被分析，則SRI應(yīng)用使用預(yù)留所需資源的請求調(diào)用QoS服務(wù)管理器72。QoS服務(wù)管理器72處理請求以確定所需資源是否可用，且如果可用，則向SRI76發(fā)送響應(yīng)以允許服務(wù)請求被轉(zhuǎn)發(fā)到其目的地。QoS服務(wù)管理器72然后更新其內(nèi)部數(shù)據(jù)存儲指示符以指示服務(wù)請求將通過寬帶接入線使用的資源。對于非UPnPQoS服務(wù)管理支持客戶終端22a，SRI76必須向UQoSM72提供滿足給定傳送條件所需的帶寬的詳細(xì)內(nèi)容，使得UQoSM72能夠預(yù)留資源以維持預(yù)定服務(wù)質(zhì)量，例如，在被傳送到客戶終端的數(shù)據(jù)流中在預(yù)定范圍的可變延時或可變等待時間內(nèi)提供請求的服務(wù)方面，在傳送或服務(wù)策略中指定的QoS。UQoSM72通過從存儲器或通過動態(tài)地查詢線速率校驗(yàn)器82檢索寬帶接入線16上的當(dāng)前可用線速率確定是否足夠的帶寬資源可用于滿足服務(wù)請求。UQoSM72用作QoS和資源管理器，因?yàn)樗ㄟ^確定所需的附加帶寬資源是否超過通過從線當(dāng)前可用線速率減去用于在其內(nèi)部存儲器中存儲的寬帶接入線上的帶寬利用率的總資源利用指示符而確定的帶寬資源，來確定可用線速率是否可以支持滿足服務(wù)請求所需的附加帶寬資源。如果足夠的帶寬可用，則服務(wù)請求被準(zhǔn)許。UQoSM72預(yù)留所需資源，使得可以維持依照SRI76發(fā)送的資源需求的QoS級別。UQoSM72更新其內(nèi)部狀態(tài)且在適當(dāng)時將響應(yīng)發(fā)送回客戶終端22b或SRI76。如果足夠的帶寬不可用，服務(wù)請求被拒絕。UQoSM76發(fā)送回指示請求被拒絕的響應(yīng)。SRI76然后處理請求且在客戶終端22a使用的通信協(xié)議中產(chǎn)生適當(dāng)?shù)腻e誤消息以產(chǎn)生服務(wù)請求（例如，如果使用HTTP產(chǎn)生服務(wù)請求，則HTTP錯誤消息被發(fā)送到客戶終端，且如果IGMP用于產(chǎn)生服務(wù)請求，則發(fā)送IGMP錯誤消息）。QoS服務(wù)管理器72的服務(wù)請求拒絕的原因可以在它產(chǎn)生的拒絕消息中指示。服務(wù)拒絕可以指示為是由于線速率不足或由于線上的其它服務(wù)。SRI76可以在它產(chǎn)生的錯誤消息中包括該信息以用于以適用于設(shè)備類型的格式傳輸?shù)娇蛻舳?。在本發(fā)明的一個實(shí)施方式中，如果帶寬不可用，則QoS服務(wù)管理器提供進(jìn)行中會話的詳細(xì)內(nèi)容，使得客戶終端22a和/或客戶終端22b可以向用戶顯示適當(dāng)?shù)南?。這樣，通過提供SRI76以從客戶終端22a（其本身不具有協(xié)商資源以滿足它們產(chǎn)生的服務(wù)請求的能力）截取IMGP和HTTP服務(wù)請求，QoS服務(wù)管理器72能夠成功地監(jiān)控寬帶接入線的帶寬利用，且能夠針對位于局域網(wǎng)絡(luò)20中的兩種類型的客戶端22a、b，在寬帶接入線16上數(shù)據(jù)流的帶寬需求之間進(jìn)行仲裁。這意味著：即使當(dāng)具有相同數(shù)據(jù)轉(zhuǎn)發(fā)類（即，在寬帶接入線上具有相同優(yōu)先級的那些包）的多個服務(wù)會話至少部分地同時運(yùn)行時，帶寬資源仲裁策略可以通過UQoSM72實(shí)施以針對允許的所有服務(wù)會話維持相對好的QoS。現(xiàn)在轉(zhuǎn)向圖5a，示出根據(jù)本發(fā)明的實(shí)施方式的服務(wù)會話資源管理的方法中的步驟，其中非仲裁使能客戶終端22a（此處示為不支持UPnPQoS服務(wù)管理的客戶終端22a）產(chǎn)生服務(wù)會話請求（步驟90）。使用HTTP或IGMP或一些其它合適的通信協(xié)議產(chǎn)生請求以使得客戶終端22a通過寬帶接入線16接收數(shù)據(jù)流。SRI92截取服務(wù)會話請求（步驟92）。現(xiàn)在簡要地轉(zhuǎn)向附圖的圖8，現(xiàn)在將描述被SRI76使用以截取服務(wù)會話請求消息的標(biāo)準(zhǔn)。圖8示出針對圖5b中示出的本發(fā)明的實(shí)施方式如何處理錯誤消息，其中產(chǎn)生HTTP重定向以使得客戶終端能夠在其服務(wù)請求在服務(wù)請求截取器（SRI）76的截取之后的點(diǎn)被丟棄時接收某些錯誤消息。如圖8所示，客戶終端22a產(chǎn)生服務(wù)請求。具有已知為指定內(nèi)容源服務(wù)器地址的IP目的地地址的包被SRI76截取。SRI76然后檢查包的內(nèi)容以確定它們包含用于指定統(tǒng)一資源定位符（URL）的HTTP請求。使用遵循命名慣例的URL確定資源需求，使得URL本身與帶寬需求相關(guān)，或備選地，其可以使用元數(shù)據(jù)或諸如圖12描述的標(biāo)簽信息確定。與針對給定URL滿足一個或更多級別的QoS所需的帶寬相關(guān)的信息被本地地存儲在路由器18上，使得它可以被SRI76本地地檢索，或如果一些合適數(shù)據(jù)服務(wù)器上遠(yuǎn)程地存儲，SRI76配置成遠(yuǎn)程地從相關(guān)數(shù)據(jù)服務(wù)器檢索帶寬（以及提供維持用于傳送內(nèi)容的給定QoS所需的資源需求的任意其它信息）?；緮?shù)據(jù)檢索操作使用來自請求的URL（或IGMP請求的多播地址）作為搜索索引，例如，查找操作，其然后針對給定URL從相應(yīng)的數(shù)據(jù)記錄/條目檢索資源需求。如上所述，這要求URL響應(yīng)于命名慣例，其中URL本身指示用于請求的流量流的相關(guān)資源需求（或通過參考使用URL的數(shù)據(jù)記錄可以確定需求）。在資源可能被檢索的同時，在一些實(shí)例中，SRI76可以基于檢索的信息計(jì)算它們。例如，如果URL對應(yīng)于用于高清VoD或高清線性TV服務(wù)的內(nèi)容流，則SRI可以計(jì)算用于維持在寬帶接入線上向路由器18（且如果會話源自IP地址被分配給觸發(fā)截取處理的內(nèi)部內(nèi)容源，還內(nèi)部地）轉(zhuǎn)發(fā)與該流相關(guān)的類的高優(yōu)先級包的協(xié)議QoS的所需帶寬。隨后響應(yīng)于服務(wù)請求以會話標(biāo)識符等形式被接受而識別將被傳送的流量流的方式通過SRI來產(chǎn)生，以被包括在它向QoS服務(wù)管理器72發(fā)送的服務(wù)資源請求中。會話標(biāo)識符可以包含遵循所需UPnPQoS服務(wù)管理標(biāo)準(zhǔn)格式的RequestTrafficQoS()。RequestTrafficQoS()消息具有一個參數(shù)：InitialTrafficDescriptor。InitialTrafficDescriptor包括TrafficId（其包含源地址、源端口、目的地地址、目的地端口和IP協(xié)議）和AvailableOrderedTspecList（其包含一個或更多流量說明（Tspec））。Tspec指定所需的帶寬。因而，通過產(chǎn)生QoS服務(wù)管理器稍后可以使用的用于非UPNPQoS客戶終端22a的Tspec，SRI有效地確保UQoSM更有效地針對UPnP服務(wù)支持客戶終端操作且用于基于使用的多播IGMP地址或指定URL（從其請求內(nèi)容流）使得非QoS客戶終端能夠體驗(yàn)通過傳輸?shù)椒?wù)請求截取器76的參數(shù)確定的QoS級別。有利地，這意味著內(nèi)容分發(fā)器可以向所有設(shè)備而非僅預(yù)先配置成實(shí)施UPnPQoS服務(wù)管理的那些設(shè)備提供QoS維持服務(wù)。現(xiàn)在轉(zhuǎn)向圖5a，如下面更詳細(xì)地描述，SRI76分析通過寬帶接入線16發(fā)送請求的數(shù)據(jù)流所需的資源（步驟94）。SRI76將從所需資源確定傳輸?shù)絈oS管理器72的合適會話標(biāo)識符，且在一些實(shí)施方式還產(chǎn)生RequestID以在請求被QoS管理器72拒絕時促進(jìn)向客戶終端報告錯誤信息。在已經(jīng)通過產(chǎn)生服務(wù)會話資源預(yù)留請求而創(chuàng)建關(guān)聯(lián)會話標(biāo)識符（或備選地流量流特性）與請求標(biāo)識符的數(shù)據(jù)記錄的情況下，SRI76然后使用相關(guān)會話信息查詢QoS管理器72。QoS管理器72此處包括：資源仲裁服務(wù)會話資源管理器72，此處示為UPnPQoS服務(wù)管理器（也稱為UPnPQoS管理器（UQoSM））（步驟96），其類型優(yōu)選地實(shí)施最新UPnPQoS服務(wù)管理標(biāo)準(zhǔn)（當(dāng)前版本3）。服務(wù)會話資源預(yù)留請求優(yōu)選地包含QM:RequestExtendedTrafficQos()類型的消息，該消息包括用于識別服務(wù)請求的流量流的裝置。例如，QM:RequestExtendedTrafficQos()包括TrafficId（其可以包括源地址、源端口、目的地地址和目的地端口）以及指定用于請求的流量流的帶寬偏好的一個或更多流量說明（TSpec）。在步驟94中，SRI確定所需的帶寬且在被發(fā)送到UPnPQoS管理器（UQoSM）72的服務(wù)會話資源預(yù)留請求中的流量說明中包括該帶寬。UQoSM72接收服務(wù)會話資源預(yù)留請求且處理它以確定所需的資源（例如，所需帶寬）是否可用（步驟30）以及將返回到SRI76的任意其它信息。UQoSM72調(diào)用UPnP服務(wù)QoS設(shè)備80來確定當(dāng)前線速率，例如，QoS設(shè)備80可以動態(tài)地查詢線速率校驗(yàn)器82或從線速率校驗(yàn)器可以放置線速率更新在其中的存儲器檢索原先存儲的值（步驟32）。UQoSM72然后從其內(nèi)部狀態(tài)記錄確定當(dāng)前線資源利用（步驟34），且通過比較被請求的帶寬與小于由其內(nèi)部狀態(tài)數(shù)據(jù)記錄指示的當(dāng)前資源利用的線速率來確定線的可用帶寬充足。如果沒有足夠的帶寬，則UQosM72向SRI76發(fā)送UPnP拒絕消息（步驟102），SRI76然后將拒絕消息內(nèi)容調(diào)適到適用于返回到服務(wù)請求客戶終端22a的形式（步驟104a），且該服務(wù)請求被丟棄。如果原始服務(wù)請求包含IGMP服務(wù)請求，沒有錯誤消息被傳輸回到客戶終端。圖5b示出向客戶終端傳輸錯誤信息的備選方式，其中HTTP服務(wù)請求通過客戶終端原始地產(chǎn)生，其中SRI76在它丟棄客戶端服務(wù)請求時向請求的客戶終端發(fā)送回HTTP重定向消息（步驟S104b）。這使得客戶終端能夠使用所述接入線上和/或LAN20內(nèi)部的資源確定關(guān)于其它服務(wù)會話的信息。然而，如果UQoSM72確定存在用于被請求的服務(wù)會話的足夠帶寬資源以并沒有不利影響現(xiàn)有服務(wù)會話，它預(yù)留資源（步驟38）。UPnPQoS服務(wù)管理器72將正常地考慮新服務(wù)將對于具有相同數(shù)據(jù)轉(zhuǎn)發(fā)類和/或包優(yōu)先級的會話的影響，使得，例如相同數(shù)據(jù)轉(zhuǎn)發(fā)類的和/或具有相同包優(yōu)先級的競爭的會話被適當(dāng)?shù)刂俨茫驗(yàn)榉駝t它們將具有用于資源的等價排序。UQoSM然后更新其內(nèi)部狀態(tài)以指示新的資源利用（步驟40），且向SRI指示資源可用（步驟S98），使得SRI76向其外部目的地轉(zhuǎn)發(fā)服務(wù)會話請求（步驟100）。這種資源管理器要求ICT76以RequestTrafficQoSExtended()消息形式（即，遵循V3標(biāo)準(zhǔn)的形式）發(fā)送服務(wù)會話資源請求。這與較早標(biāo)準(zhǔn)的RequestTraffcQos()消息具有相同的參數(shù)值：InitialTrafficDescriptor，但是相應(yīng)地通過QoS管理器產(chǎn)生和返回更多的信息，例如，如果請求被拒絕，可以返回阻斷會話的列表。InitialTrafficDescriptor包括TafficID（其包含源地址（SA）、源端口（路由器18上）、目的地地址、目的地端口（路由器18上）和IP協(xié)議），availableOrderedTspecList（其包含一個或更多TSpec）。Tspec將指定所需的帶寬。盡管所有流量識別字段是可選的，在SRI76意識到該信息的情況中，優(yōu)選的是，在傳送到QoS管理器72的TrafficID中包括該信息。trafficID通過查看相關(guān)流參數(shù)來創(chuàng)建。Tspec通過查找與URL中的某一術(shù)語相關(guān)或與某一多播地址相關(guān)的帶寬來創(chuàng)建。如果該信息被配置到路由器18，則查找可以是本地的，或者，被遠(yuǎn)程地配置。本發(fā)明的實(shí)施方式因而使得UQoSM72能夠接收諸如用于流量流的所需帶寬這樣的資源需求的指示，當(dāng)SRI76從URL結(jié)構(gòu)確定帶寬時，所述流量流被非UPnPQoS服務(wù)管理支持客戶終端所請求。圖6示出圖5b中示出的方法的延伸，其接續(xù)步驟102和104。在圖6中，響應(yīng)于接收到HTTP重定向消息（步驟104），客戶終端22a向遠(yuǎn)程網(wǎng)絡(luò)服務(wù)器103發(fā)送查詢（步驟106）且從遠(yuǎn)程網(wǎng)絡(luò)服務(wù)器103（見圖8）接收識別使用資源且阻斷客戶終端22a產(chǎn)生的服務(wù)請求的其它服務(wù)會話的信息（步驟108）。如圖6所示，該信息顯示在請服務(wù)請求客戶終端22a上以使得來自客戶終端22a的用戶輸入能夠指示新服務(wù)優(yōu)于現(xiàn)有服務(wù)中任意一個的偏好。如果用戶否定地指示，則不采取進(jìn)一步的動作（步驟114）。相應(yīng)地，從圖5b的步驟104b構(gòu)建，阻塞的會話的列表被返回且為用戶呈現(xiàn)終止這些會話中的一個的選項(xiàng)。存在用戶和網(wǎng)絡(luò)服務(wù)器103之間的交互且客戶終端22a使用網(wǎng)絡(luò)瀏覽器來使得這些HTTP交互被支持且所以可以保留非QoS意識。對于諸如STB、TV等客戶終端，網(wǎng)絡(luò)瀏覽器可能具有有限的功能性且包括基本應(yīng)用（而不是諸如InternetExplorerTM的個人計(jì)算機(jī)環(huán)境中熟悉的網(wǎng)絡(luò)瀏覽器）。然而，如果用戶指示存在對于新服務(wù)的偏好，客戶終端22a響應(yīng)于網(wǎng)絡(luò)服務(wù)器103，該網(wǎng)絡(luò)服務(wù)器103配置成產(chǎn)生發(fā)送到SRI76的優(yōu)選會話信息，該SRI76識別哪個會話被終止和/或哪個會話被保留。SRI然后響應(yīng)于UQoSM72，該UQoSM72然后可以終止任意（多個）不希望的會話（步驟110）。備選地，網(wǎng)絡(luò)服務(wù)器103可以顯示關(guān)于用于客戶終端的備選會話或客戶終端的用戶的足夠的信息以在非優(yōu)選服務(wù)會話中向接收數(shù)據(jù)流的另一設(shè)備發(fā)送請求以終止該服務(wù)會話或向遠(yuǎn)程數(shù)據(jù)源或?qū)拵нh(yuǎn)程接入服務(wù)器發(fā)送請求以終止流。任意方式，在不希望的服務(wù)會話終止的適當(dāng)時間之后，客戶端設(shè)備22a重新產(chǎn)生用于優(yōu)選服務(wù)的服務(wù)會話請求（步驟112）。相應(yīng)地，通過提供響應(yīng)于HTTP服務(wù)請求被拒絕產(chǎn)生重定向消息的SRI，阻塞的會話的列表可以返回到請求被拒絕的客戶終端，使得客戶終端的用戶可以被提供終止阻塞的會話中的一個的選項(xiàng)。為了支持用戶和網(wǎng)絡(luò)服務(wù)器103之間的這種交互，客戶終端必須提供用于將被支持的交互的適當(dāng)裝置，諸如可以支持HTTP交互的網(wǎng)絡(luò)瀏覽器。這使得客戶終端22a保留非QoS意識。UPnPQoSV3通信協(xié)議支持的優(yōu)先認(rèn)購機(jī)制用于UQoSM72以基于可能或可能不涉及與終端用戶的交互的一些策略作為新請求的處理的一部分終止現(xiàn)有會話。然而，這種基于策略的方法不適于非UPnPQoS客戶端且所以需要使用上述HTTP的網(wǎng)頁方法，一旦用戶終止現(xiàn)有會話，該方法需要客戶端22a重新請求新會話。這可以通過在會話終止列表頁面之后使得客戶終端重定向回到原始URL來實(shí)施。或者備選地，顯示用戶再次嘗試的提示?？蛻舳藢⑿枰惶峁┮宰銐蜢`活的瀏覽器以支持使得其工作的所有上述交互。通過使用用于重定向的URL（其例如包括RequestId作為參數(shù)）的結(jié)構(gòu)的協(xié)議慣例，RequestId被嵌入在重定向的HTTP服務(wù)請求中。因?yàn)镾RI產(chǎn)生URL和后續(xù)處理它（作為網(wǎng)絡(luò)服務(wù)器的代表），慣例確立為SRI設(shè)計(jì)的一部分。附圖的圖7示出根據(jù)本發(fā)明的實(shí)施方式管理服務(wù)會話的方法的另一實(shí)施方式，其中，示為UPnPQoS服務(wù)管理器的仲裁服務(wù)會話資源管理器72從示為UPnPQoS使能客戶終端的仲裁使能客戶終端22b接收服務(wù)會話請求（步驟30）。UPnPQoS服務(wù)管理器（UQoSM）72通過從數(shù)據(jù)存儲檢索可用線速率或通過在線速率校驗(yàn)器中查詢確定可用線速率（步驟32）。UPnPQoS服務(wù)管理器72意識到寬帶接入線的當(dāng)前資源利用（步驟34）且UQoSM72基于當(dāng)前可用線速率和當(dāng)前線資源利用率的意識確定是否有足夠的資源可用于所述服務(wù)請求（步驟36）。如果資源可用，則該方法進(jìn)行以預(yù)留資源（步驟38）且關(guān)于帶寬利用更新UQoSM72的內(nèi)部意識狀態(tài)（步驟40），且合適的響應(yīng)被發(fā)送到UPnPQoS使能客戶終端22b（步驟42），在此之后，會話開始（步驟44）。然而，如果資源不可用，包括與服務(wù)請求的接收并發(fā)地使用接入線16上的資源的現(xiàn)有服務(wù)的詳細(xì)內(nèi)容的UPnP服務(wù)拒絕消息被發(fā)送到客戶終端22b（步驟46）。在該實(shí)施方式中，客戶終端22b配置成顯示其它現(xiàn)有會話且提示用戶對于新和/或現(xiàn)有服務(wù)會話之間的偏好（步驟48）。如果響應(yīng)指示新服務(wù)具有優(yōu)于現(xiàn)有服務(wù)會話的偏好，則該偏好信息被發(fā)送到UQoSM72，使得它可以終止非優(yōu)選服務(wù)會話和/或請求被發(fā)送到外部數(shù)據(jù)服務(wù)器和/或流量指示器以修改現(xiàn)有流量流的流量特性（例如，降低其轉(zhuǎn)發(fā)類和/包優(yōu)先級）?？蛻艚K端22然后等待適當(dāng)量的時間以允許非優(yōu)選服務(wù)會話終止且然后重新產(chǎn)生用于優(yōu)選服務(wù)的服務(wù)會話請求?，F(xiàn)在參考圖8，如果資源管理器72拒絕服務(wù)請求，它將產(chǎn)生返回到SRI76的拒絕消息，該SRI76使用流量描述符識別拒絕的流量流。拒絕消息可以包含錯誤信息，SRI76配置成將該錯誤信息傳輸?shù)娇蛻艚K端，例如，如果拒絕的請求是擴(kuò)展QoS請求，則響應(yīng)可以列舉當(dāng)前占用資源的流量流。在這種情況中，SRI產(chǎn)生包括識別涉及拒絕的服務(wù)會話的錯誤消息的某種方式的重定向消息。錯誤信息標(biāo)識符的示例包括RequestID以關(guān)聯(lián)信息和可以通過SRI76產(chǎn)生的接收的請求，或者備選地，當(dāng)拒絕消息被檢索時，RequestRejectID可以通過SRI產(chǎn)生且使用。在任一情況中，SRI76包括當(dāng)它產(chǎn)生用于發(fā)送到客戶終端的重定向消息時的信息標(biāo)識符，使得錯誤信息可以隨后被提供到客戶終端。這意味著當(dāng)SRI丟棄服務(wù)請求時，對于客戶終端接收的重定向消息進(jìn)行動作的客戶終端聯(lián)系在重定向中所指示的數(shù)據(jù)服務(wù)器103。當(dāng)數(shù)據(jù)服務(wù)器（或等價地網(wǎng)絡(luò)服務(wù)器）103從客戶終端22a接收到重定向的HTTP請求時，它動態(tài)地產(chǎn)生提供已經(jīng)阻斷請求的其它會話的細(xì)節(jié)的網(wǎng)頁。信息通過錯誤信息來提供，該錯誤信息是通過使用重定向中客戶終端提供的信息標(biāo)識符查詢SRI76而被檢索的。在這種情況中，SRI產(chǎn)生包括識別拒絕服務(wù)會話的某種方式的重定向消息。盡管UPnPQoS管理流量描述符可以用于識別對于UQoSM72的請求，如果使用較簡單的數(shù)據(jù)結(jié)構(gòu)，則是優(yōu)選的。因?yàn)檎埱笠呀?jīng)被拒絕，仍沒有產(chǎn)生用于租約刷新的種類的流量處理，且所以使用SessionID（即，使用流量描述符）檢索當(dāng)SRI76產(chǎn)生請求時存儲的RequestID且RequestID然后作為重定向消息的一部分被發(fā)送到客戶端，使得當(dāng)SRI丟棄來自客戶端的服務(wù)請求時，客戶端可以被提供指示請求為什么從網(wǎng)絡(luò)服務(wù)器103被拒絕的信息，該網(wǎng)絡(luò)服務(wù)器103由SRI76提供錯誤信息。因此，當(dāng)SRI76接收到請求拒絕消息時，它提取相關(guān)錯誤信息，諸如當(dāng)前利用寬帶接入線16上的資源的阻塞的流量流的列表（或者，內(nèi)部地，占有LAN20的內(nèi)部資源），且將該消息與RequestID相關(guān)聯(lián)地存儲。SRI76然后產(chǎn)生包括RequestID的重定向消息，該重定向消息被發(fā)送到客戶終端22a?？蛻艚K端22a然后產(chǎn)生針對在網(wǎng)絡(luò)服務(wù)器103處的重定向URL的新服務(wù)請求，該請求包括SRI產(chǎn)生的服務(wù)請求的RequestID。網(wǎng)絡(luò)服務(wù)器103提取RequestID，且動態(tài)地產(chǎn)生通過使用requestID查詢SRI76請求的網(wǎng)頁。SRI76處理來自網(wǎng)絡(luò)服務(wù)器103的針對錯誤信息的請求、提取RequestID且檢索相關(guān)錯誤信息。在被發(fā)送到網(wǎng)絡(luò)服務(wù)器103的響應(yīng)中的錯誤信息使得網(wǎng)絡(luò)服務(wù)器103能夠動態(tài)地在稍后顯示在客戶終端上的網(wǎng)頁中產(chǎn)生相關(guān)錯誤信息。附圖的圖9示出QoS管理器72針對非QoS支持客戶終端22a請求的流量流預(yù)留的帶寬如何維持相關(guān)流量流的持續(xù)時間。如圖9所示，SRI76從非UPnPQoS服務(wù)管理支持客戶終端22a截取HTTP或IGMP服務(wù)請求。具有預(yù)定級別的QoS地滿足請求所需的適當(dāng)量的資源（例如，具有特定QoS（其可以依賴于包優(yōu)先級和/或轉(zhuǎn)發(fā)類以及IGMP請求的指定多播地址或HTTP請求的URL）地通過客戶終端22a接收的流量流所需的帶寬）通過SRI76確定。SRI76則包括當(dāng)它以傳統(tǒng)UPnPQoS服務(wù)管理格式產(chǎn)生服務(wù)會話資源請求時用于請求的服務(wù)的所需QoS的資源需求。SRI76產(chǎn)生的請求還包括隨后識別請求的流量流的方式，例如，它可以產(chǎn)生UPnPQoS流量標(biāo)識符，該流量標(biāo)識符包含流量描述符，該流量描述符包括流量詳細(xì)說明（TSpec）。如果QoS管理器72接受請求，則它預(yù)留帶寬、更新其內(nèi)部狀態(tài)且產(chǎn)生適當(dāng)類型的接受消息，該接受消息將包括TrafficHandle以允許資源預(yù)留在超過缺省租約時段的時間段上維持，在該時段之后，QoS管理器72將自動地釋放所需的資源（租約可以短至幾分鐘，使得如果存在任何問題，QoS管理器可以以相對快速的標(biāo)度整理）。該TrafficHandle與TrafficID和Tspec數(shù)據(jù)一同返回且通過服務(wù)請求截取器76本地地存儲。一旦接受，SRI76向使用請求的流量流響應(yīng)的遠(yuǎn)程數(shù)據(jù)服務(wù)器12轉(zhuǎn)發(fā)服務(wù)請求。在流量被流傳輸?shù)娇蛻艚K端22a的同時，SRI76監(jiān)控被路由{通過監(jiān)控?向外}向服務(wù)請求客戶終端的包的流動，該客戶終端具有用于已知為與指定流量流相關(guān)的數(shù)據(jù)服務(wù)器的源IP地址。監(jiān)控可以使用本領(lǐng)域中任何合適的流監(jiān)控技術(shù)執(zhí)行，諸如對包進(jìn)行計(jì)數(shù)。SRI76產(chǎn)生識別每個監(jiān)控的流量流（因?yàn)槿绻鄠€流被LAN20內(nèi)的設(shè)備接收，則不止一個可以在給定時間被監(jiān)控）的刷新消息。發(fā)送到QoS服務(wù)管理器72的刷新資源預(yù)留消息包含依照UPnPQoS服務(wù)管理標(biāo)準(zhǔn)的當(dāng)前版本的UpdateTrafficQoSExtended()消息，其包括響應(yīng)于原始RequestTrafficQos()消息被接受通過QoS管理器返回的流量處理（TrafficHandle）。這是必須的，因?yàn)閁PnP-QoSv3中的預(yù)留導(dǎo)致有限（多個）網(wǎng)絡(luò)資源被分配給指定流量流，如果不再需要，這些資源必須被釋放，使得其它流或應(yīng)用可以使用這些資源。如果計(jì)時器超時而沒有在租約時間段內(nèi)接收到預(yù)留的明確釋放，假設(shè)不再需要預(yù)留，且預(yù)留和資源被釋放。為了擴(kuò)展租約時間段，UpdateTrafficQoSExtended()消息被發(fā)送到QoS服務(wù)管理器72。圖10A示出當(dāng)IGMP多播會話終止時如何釋放資源。在從圖9繼續(xù)的圖10A中，SRI76繼續(xù)監(jiān)控流，直到產(chǎn)生IGMP離開消息，此時它依照UQoSM76遵循的相關(guān)UPnPQoS標(biāo)準(zhǔn)發(fā)送特定釋放消息，然后可以釋放預(yù)留和資源。一個備選是簡單地停止發(fā)送用于流的UpdateTrafficQoS消息，已經(jīng)接收用于該流的IGMP離開消息，但是這不是優(yōu)選解決方案。圖10B示出圖9將如何繼續(xù)，直到HTTP監(jiān)控流量流停止以被客戶終端22a接收。在這種情況中，SRI76監(jiān)控連接且截取TcP關(guān)閉連接消息，這然后將導(dǎo)致特定釋放消息被發(fā)送到QoS服務(wù)管理器72，或如上所述，盡管另一選擇較沒有整理，但是將不發(fā)送刷新消息。圖11更詳細(xì)地示出對于非UPnP客戶端，SRI76需要如何從URL（http）或多播地址（IGMP）確定資源需求。在http的情況中，我們具有在HTTP請求中嵌入元數(shù)據(jù)標(biāo)簽的選項(xiàng)（在圖12中單獨(dú)地顯示）。如圖11所示，SRI76監(jiān)控在路由器18上的客戶終端面對端口上接收的所有包，且如果確定它們是定向到已知多播源的IGMP包或如果包具有數(shù)據(jù)記錄在資源預(yù)留數(shù)據(jù)存儲中存在的目的地IP地址，則它截取它們。數(shù)據(jù)存儲可以包含數(shù)據(jù)庫或僅僅是文件，其中，對應(yīng)于用于遠(yuǎn)程數(shù)據(jù)存儲12（或備選地，內(nèi)部數(shù)據(jù)源20a）的IP地址的IP地址被列舉。所有非截取流量簡單地被允許前進(jìn)到其目的地（101）。然而，如果SRI截取IGMP包，則多播目的地地址用于檢索用于請求的流的資源需求（94a）。如果SRI截取與SRI配置成對其進(jìn)行過濾的IP地址匹配的包，則截取的包的有效載荷被檢查（94b）以確定它是否包含包括用于數(shù)據(jù)服務(wù)器（12、24）的URL的HTTP請求（94b）。遠(yuǎn)程數(shù)據(jù)服務(wù)器12可以要求資源在接入線上被預(yù)留以用于使用數(shù)據(jù)消費(fèi)客戶終端22a確立的會話。如果數(shù)據(jù)消費(fèi)客戶終端22a從內(nèi)部數(shù)據(jù)源24（諸如依照數(shù)字生活網(wǎng)絡(luò)聯(lián)盟分布數(shù)據(jù)的數(shù)據(jù)源）請求內(nèi)容，則會話資源請求位于LAN20的內(nèi)部。URL然后被SRI提取且使用以執(zhí)行查找操作以確定資源需求，如果存在這種資源需求，它將需要指示給QoS服務(wù)管理器（94c）。一旦資源已知，SRI查詢QoS服務(wù)管理器以請求所需資源的預(yù)留（96）。不是執(zhí)行查找，URL本身可以傳達(dá)關(guān)于所需資源的足夠信息，以使得SRI能夠直接確定它需要QoS服務(wù)管理器針對請求的服務(wù)預(yù)留的資源。例如，URL路徑的一部分可以識別與該URL相關(guān)的內(nèi)容的類型，例如，用于標(biāo)清流量流服務(wù)請求的http://sd.cdd.bt.net/toy_story3-sd.avi和用于高清流量流服務(wù)請求的http://hd.cdd.bt.net/toy_story3-hd.avi。需要確定針對可從服務(wù)請求識別的每個標(biāo)清或高清頻道和所需帶寬的查找，除非提供指示SRI76需要向UQoSM72提供的流量說明（Tspec）的這個和任意其它關(guān)鍵參數(shù)（包括是否需要優(yōu)質(zhì)帶寬）的URL。通過從URL本身識別所需的清晰度，SRI76針對相關(guān)寬帶接入線16使用相應(yīng)帶寬需求以從QoS服務(wù)管理器72請求足夠的資源。圖12示出一個備選，其中不是URL指示帶寬，當(dāng)用戶使用客戶端應(yīng)用選擇內(nèi)容項(xiàng)（步驟89a）時，客戶端應(yīng)用配置成捕獲與選擇的內(nèi)容項(xiàng)相關(guān)的元數(shù)據(jù)，該元數(shù)據(jù)然后作為標(biāo)簽被包括在用于該內(nèi)容項(xiàng)的服務(wù)請求中（步驟89b）。在這種情況下，如果安裝客戶端應(yīng)用的客戶終端不支持UPnPQoS服務(wù)管理，則當(dāng)SRI76截取用于所選內(nèi)容項(xiàng)的服務(wù)請求時（92），它提取以嵌入在服務(wù)請求中的標(biāo)簽形式提供的元數(shù)據(jù)（94d）且從元數(shù)據(jù)標(biāo)簽確定資源需求（94e）。資源需求然后用在SRI產(chǎn)生的流量描述符中以提供到UQoSM以針對與被請求的內(nèi)容項(xiàng)相對應(yīng)的流量流預(yù)留適當(dāng)?shù)馁Y源（96）。除非在說明書中特別區(qū)分，此處描述的所有圖對于類似的元件保持編號方案。因而根據(jù)本發(fā)明的服務(wù)請求截取器（SRI）76配置成向經(jīng)過面對LAN20中的客戶終端的端口的流量應(yīng)用過濾器，且過濾出來自非UPnPQoS能力客戶端設(shè)備的請求，使得QoS服務(wù)管理器正確地作用，且使得這種客戶端仍可以接收QoS管理服務(wù)。SRI76產(chǎn)生足夠的信息以效仿UPnP控制點(diǎn)可以產(chǎn)生且包括在流量描述符中的信息的類型，從而被包括在QoS服務(wù)請求中。在實(shí)施其中使用使得可以改變數(shù)據(jù)流接收的編碼版本的自適應(yīng)比特率的本發(fā)明的系統(tǒng)中，可以針對不同編碼版本產(chǎn)生重復(fù)HTTP請求。在這種實(shí)施方式中，在SRI76確定源地址、目的地地址以及面對客戶終端22a的端口和面對數(shù)據(jù)服務(wù)器12、24的端口以查看相同的端口已經(jīng)用于接收現(xiàn)有流量流之后，SRI76必須針對接收的每個新HTTP請求執(zhí)行附加查找操作。如果是HTTP請求，HTTP請求被確定為涉及在不同自適應(yīng)比特率的較早的請求；即涉及不同編碼版本。備選地，如果其遵循合適的命名慣例，可以從HTTP請求的URL做出相同的確定。如果接收的請求是用于將被維持的預(yù)留的重復(fù)HTTP請求，新HTTP請求被鏈接到較早請求且沒有附加請求被轉(zhuǎn)發(fā)到UQoSM76，除非資源預(yù)留需求中的變化被確定且原始數(shù)據(jù)流被維持。管理此的一種方式是在傳輸控制協(xié)議（TCP）級別，因?yàn)槎鄠€HTTP請求可以在相同TCP連接上服務(wù)。只要HTTP請求能夠被視為作為相同TCP連接的一部分發(fā)生，它們不需要被進(jìn)一步處理。存在這樣的危險：延遲的中間HTTP請求將導(dǎo)致抖動的按需點(diǎn)播服務(wù)。限制抖動的一種方式是，只要新HTTP預(yù)留就位，用于第一級別截取的標(biāo)準(zhǔn)（在IP層或應(yīng)用層）被更新。這防止相同流中連續(xù)HTTP請求的阻斷，因?yàn)槌司哂刑囟ㄔ吹刂罚ɑ蚋鼉?yōu)選地具有特定源和目的地端口）的包，截取標(biāo)準(zhǔn)從截取到已知VoDIP地址的所有IP包到已知VoD地址的所有IP包地變化。這樣，SRI應(yīng)用動態(tài)可變級別的服務(wù)請求截取。客戶端還可以配置成重復(fù)對于SRI76的服務(wù)請求，且不是從UQoSM72向客戶終端轉(zhuǎn)發(fā)拒絕，SRI76可以配置成重定向客戶終端且等待用戶輸入被所述網(wǎng)絡(luò)服務(wù)器103接收，而不管用戶是否針對當(dāng)前會話具有優(yōu)于另一進(jìn)行中會話的偏好。如果用戶選擇另一進(jìn)行中會話，則SRI76可以在預(yù)定時間時段之后或響應(yīng)于指示另一服務(wù)會話已經(jīng)終止的適當(dāng)觸發(fā)事件，向UQoSM72發(fā)送重復(fù)服務(wù)會話資源預(yù)留請求。服務(wù)請求截取器還可以布置為在用于帶寬的需求減小到可以適應(yīng)請求的級別時提示客戶終端重新提交原先被拒絕或中斷的請求。下面重復(fù)的摘要形成說明的一部分：描述了一種在路由器中使用的服務(wù)會話請求截取器，該路由器能夠在通信線上路由多個至少部分同時的服務(wù)會話，該服務(wù)會話請求截取器在競爭帶寬的服務(wù)之間進(jìn)行仲裁。服務(wù)會話管理器基于仲裁使能和仲裁非使能設(shè)備二者更新其內(nèi)部狀態(tài)。資源管理器包含：存儲器，布置為存儲用于所述通信線的資源的當(dāng)前資源利用指示符；服務(wù)請求處理器，布置為處理來自客戶終端的新服務(wù)會話請求以確定所述通信線上用于所述新服務(wù)會話的所需資源且根據(jù)可用線速率和所述當(dāng)前利用指示符確定所需資源是否可用；預(yù)留所需資源的裝置；更新所述當(dāng)前利用指示符以指示允許的資源預(yù)留的裝置；以及響應(yīng)于預(yù)留了所述資源的所述請求客戶端的裝置；其中所述當(dāng)前資源利用指示符通過所述服務(wù)請求處理器更新，以指示通過一個或更多客戶終端建立的一個或更多服務(wù)會話使用的資源，所述一個或更多客戶終端被配置成在所述通信線路上發(fā)送服務(wù)請求，而無需從所述服務(wù)會話管理器請求對于服務(wù)的接入。本領(lǐng)域技術(shù)人員將意識到對于上述實(shí)施方式中描述的特征中的一個或更多個的修改和/或功能備選，且為簡單起見，可以在明顯作為本發(fā)明的特征被包括的地方從詳細(xì)的描述中省略這種特征。當(dāng)依照本領(lǐng)域技術(shù)人員的知識，使用說明書適當(dāng)?shù)亟庾x時，權(quán)利要求的發(fā)明范圍相應(yīng)地將從附圖確定，且不限于此處描述的文字示例。