專利名稱：通過管理tcp ack來提高lan中的吞吐量的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及在無線視頻分配系統(tǒng)中從諸如機頂盒(STB)等主設(shè)備向諸如STB等遠 程設(shè)備分配壓縮的多媒體/視頻。
背景技術(shù)：
對于有線視頻服務(wù)，通常在線纜上特定視頻節(jié)目專用的頻帶內(nèi)廣播該特定視頻節(jié) 目。房屋中的任何電視可以通過調(diào)諧至該頻率而被調(diào)諧至任何特定節(jié)目。就更新的電視服 務(wù)(例如，衛(wèi)星電視分配、因特網(wǎng)電視分配)而言，在主STB中調(diào)諧節(jié)目，然后通過家庭網(wǎng)絡(luò) 分配至遠程STB。在許多情況下，需要安裝家庭網(wǎng)絡(luò)(或家庭分配系統(tǒng))。盡管線(同軸電 纜、雙絞線等)是可靠的，但是安裝起來十分昂貴，并且房主可能不希望安裝員為了安裝而 鉆穿墻壁。因此，廠家對于視頻節(jié)目再分配系統(tǒng)問題的無線解決方案很感興趣。多數(shù)現(xiàn)有的家庭數(shù)字視頻分配系統(tǒng)使用以太網(wǎng)作為分配介質(zhì)。由于多數(shù)以太網(wǎng)安 裝使用至少IOOMbps的鏈路速率并使用交換機而交換機有選擇地僅向包含編址設(shè)備的分 支發(fā)送業(yè)務(wù)，因此當(dāng)使用在業(yè)務(wù)速率受控的視頻再分配系統(tǒng)時存在極少的QoS問題。如果 在相同網(wǎng)絡(luò)上發(fā)送通用IP數(shù)據(jù)業(yè)務(wù)而不采用某種類型的QoS保護，則使用以太網(wǎng)會存在 問題。當(dāng)前存在可用于以太網(wǎng)的一種類型的媒體訪問控制(MAC)級QoS。使用虛擬局域網(wǎng) (VLAN)標(biāo)簽中的用戶優(yōu)先字段是一種基于優(yōu)先級的方案。當(dāng)前，附加參數(shù)化QoS(帶寬請 求、帶寬保證、允許控制等)是研究IEEE802網(wǎng)絡(luò)橋接的IEEE802. 1小組委員會中多個工作 組之一的研究主題。然而，以太網(wǎng)的缺點在于，需要線路來實現(xiàn)，并且十分需要一種無新線 (no-new-wires)安裝技術(shù)。所需要的是一種通過MAC級橋接來代替以太網(wǎng)分配的無線分配系統(tǒng)。許多家庭網(wǎng) 絡(luò)使用IP協(xié)議來分配視頻，但存在許多可能性。在一些情況下，使用由實時傳輸協(xié)議(RTP) 指定的UDP來發(fā)送視頻，而在其他情況下(例如，數(shù)字生活網(wǎng)絡(luò)聯(lián)盟(DLNA))，視頻通過TCP 進行分配。UDP僅需要單向通信，而TCP需要雙向通信。還存在其他可能。希望存在一種 不需要對已具有以太網(wǎng)接口的主設(shè)備/STB和遠程設(shè)備/STB進行任何修改(即，無需帶寬 預(yù)留、無需與無線網(wǎng)橋設(shè)備對話等)的家庭分配系統(tǒng)。由于介質(zhì)是無線的從而是頻帶受限 的公共介質(zhì)，還期望MAC層是極其高效的。為此，本發(fā)明使用TDMA MAC方案。在TDMA MAC 方案中，指定時間分配以產(chǎn)生每一客戶端/遠程設(shè)備(STB)的專用帶寬。本文所使用的“/” 指示相同組件的別名。視頻的確切比特率和其他特征可以是未知的，甚至對于先驗的主STB 來說也是如此。即使視頻的確切比特率是先驗已知的，也希望能夠不需要主STB就能具有 與無線設(shè)備(遠程和/或主橋接節(jié)點)的任意特定或新的通信。由于多媒體業(yè)務(wù)大多從主 設(shè)備下行至若干遠程設(shè)備，因此有機會消除開銷。當(dāng)TCP用于分配多媒體流時，多數(shù)上行業(yè) 務(wù)是TCPACK。消除這些TCP ACK中的一些將降低傳輸開銷量，允許更多可用BW被專用于實 際攜帶多媒體流信息。被分配至從遠程STB/設(shè)備到主設(shè)備/STB的返回/上行路徑的時間不可用于用于 視頻分配的下行路徑。由于視頻分配是目標(biāo)系統(tǒng)的主要功能，因此期望降低由TCP ACK引起的開銷并降低TCP滑動窗口的負面影響。當(dāng)前正在IEEE中進行標(biāo)準(zhǔn)化的IEEE802. IlN正作為一種用于視頻分配的方法得到大力宣揚。對于IEEE 802. IlN的主題技術(shù)尚存在許多問題。首先，該技術(shù)仍舊基于 CSMAdEEE 802. 11)。該類型的MAC層內(nèi)在上是效率低的并且不提供QoS保證。盡管向IEEE 802. IlN添加了許多MAC級QoS增強，但是基于CSMA的MAC與TDMA MAC—樣高效是不可能 的。QoS增強包括源自IEEE 802. IlE的基于優(yōu)先級的QoS和一些形式的輪詢，以及添加 MAC服務(wù)數(shù)據(jù)單元(MSDU)和MAC協(xié)議數(shù)據(jù)單元(MPDU)匯聚。這些增強對管理IEEE802. 11 網(wǎng)絡(luò)的資源非常有用，但是不提供無線家庭視頻分配系統(tǒng)所需要或期望的任何QoS保證。 輪詢可以用來創(chuàng)建本發(fā)明能夠?qū)ζ溥M行操作的類TDMA服務(wù)，但是輪詢本身降低了 MAC效 率。MAC效率對于無線網(wǎng)絡(luò)來說甚至更關(guān)鍵，這是由于可用于房屋的更遠程區(qū)域的鏈路速率 是有限的。多數(shù)當(dāng)前無線局域網(wǎng)(WLAN)利用公共傳輸介質(zhì)(即，相同傳輸頻率下的無線頻 譜)。因此，MAC需要共享該介質(zhì)的機制。應(yīng)當(dāng)注意，一旦經(jīng)由CSMA獲得了或經(jīng)由輪詢分配 了傳輸機會，就能夠應(yīng)用本發(fā)明?！┓?wù)供應(yīng)商尋找基于同軸電纜、電話線和/或電源線的無新線技術(shù)。存在許 多不同的可能，多數(shù)可能具有優(yōu)先級或參數(shù)化QoS的形式。這些解決方案的固有問題在于， 即使在房屋中已存在同軸電纜或電話線，那些線路可能還沒有連接至正確的點，或者是對 于技術(shù)來說很難處理的拓撲。大多數(shù)這樣的技術(shù)還與其他房屋共享帶寬(例如，在一個電 源變壓器上最多有4個房屋的電源線)并且當(dāng)前缺乏可靠性。對于參數(shù)化服務(wù)，STB必須知 道為每一條鏈路保留多少帶寬。對于視頻家庭分配系統(tǒng)來說，業(yè)務(wù)不受控，可以是突發(fā)的， 并且至少部分上是未知的。本發(fā)明包括解決了上述突出問題的家庭多媒體流分配系統(tǒng)。

發(fā)明內(nèi)容
多數(shù)當(dāng)前無線LAN利用公共傳輸介質(zhì)(S卩，相同傳輸頻率下的無線頻譜)。因此，媒 體訪問控制(MAC)層需要共享該介質(zhì)的機制。多數(shù)機制基于載波偵聽多路訪問(CSMA)MAC 層(例如，IEEE802. 11)。這種類型的MAC層內(nèi)在地效率很低，并且不提供服務(wù)質(zhì)量(QoS) 保證。由于可用于房屋更遠程區(qū)域的鏈路速率是有限的，因此MAC效率對無線網(wǎng)絡(luò)來說甚 至更關(guān)鍵。為了實現(xiàn)極高的效率和QoS保證，本發(fā)明使用基于時分多址(TDMA)的MAC IEEE 802. 15. 3b。對于基本的TDMA功能使用標(biāo)準(zhǔn)MAC，但是添加了降低由于TCP ACK引起的網(wǎng)絡(luò) 負載的能力。本發(fā)明的設(shè)計所針對的典型系統(tǒng)包括主設(shè)備，用于向多達三個客戶端/遠程設(shè) 備分配基于因特網(wǎng)協(xié)議(IP)的視頻。所述設(shè)備是以太網(wǎng)/無線MAC層設(shè)備，其中在基于以 太網(wǎng)的STB中進行實際的視頻調(diào)諧以及呈現(xiàn)。盡管就STB而言對本發(fā)明進行了描述，但是 不管該設(shè)備的名稱如何，通過本發(fā)明可以想到具有等同或類似功能的任何設(shè)備。通常，MAC 網(wǎng)橋連接可能相同或可能不同的LAN網(wǎng)段。通過網(wǎng)橋互聯(lián)的不同LAN技術(shù)的集合被稱作網(wǎng) 橋局域網(wǎng)。純MAC網(wǎng)橋在MAC服務(wù)邊界以下工作，并且對于MAC網(wǎng)橋服務(wù)邊界以上所使用 的協(xié)議來說是透明的，只不過在QoS方面有可能不同。下面，就與三個遠程STB進行受限通信(S卩，發(fā)向/來自主STB的所有通信)的示 例家庭視頻分配系統(tǒng)而言，對本發(fā)明的系統(tǒng)和方法進行描述。本文所述技術(shù)可以容易地被擴展至更一般的家庭網(wǎng)絡(luò)。應(yīng)當(dāng)注意的是，到目前為止，不存在可以將三條高清晰視頻流分 配至房屋中的三個遠程位置的無線家庭分配系統(tǒng)。還應(yīng)當(dāng)理解的是，盡管就包括視頻流的 示例實施例而言對本發(fā)明進行描述，但顯而易見的是，術(shù)語“視頻”可以被擴展至包括“多媒 體流”，“多媒體流”包括諸如數(shù)字音頻等其他流媒體。所有業(yè)務(wù)被限制為去往或來自主橋接設(shè)備。主橋接設(shè)備周期性地發(fā)送信標(biāo)，信標(biāo) 制定了每一設(shè)備可以在其中發(fā)送其數(shù)據(jù)的信道時間分配(CTA)。信標(biāo)加上到下一信標(biāo)為止 的所有CTA被稱作如圖8所示的“超幀”。CTA1、2和3用于下行業(yè)務(wù)(多數(shù)為視頻)。CTA4、 5和6用于上行業(yè)務(wù)(多數(shù)為TCP確認(ACK)和其他管理/控制幀)。主網(wǎng)橋設(shè)備在傳輸信 標(biāo)之前確定CTA分配。通常，CTA可以是由主設(shè)備(主STB)確定或由遠程設(shè)備(遠程STB) 請求的固定時隙。期望充分利用所有可用的時間分配/時隙。本發(fā)明還具有的優(yōu)點是，無需改變包括承載視頻的協(xié)議在內(nèi)的視頻系統(tǒng)中間件。在上述應(yīng)用中，視頻通過TCP來分配，TCP是覆蓋在協(xié)議棧中的IP之上的面向連 接的雙向協(xié)議。盡管TCP ACK可用于通過互聯(lián)網(wǎng)進行的傳輸，但是如在本發(fā)明中這樣，TCP ACK在可靠LAN中、用于視頻流內(nèi)的有用性是存在問題的。然而，TCP在橋接設(shè)備中可用作 中間件，并且期望不改變現(xiàn)有的中間件而是對其擴充和增強。通過低物理層(PHY)分組錯 誤率以及MAC層處的重傳可以實現(xiàn)高可靠性。還期望降低由遠程STB返回的TCP ACK引起 的開銷以及對TCP滑動窗口的負面影響。本文描述了用于降低由TCP ACK引起的開銷的三種方法。將前兩種方法進行組合 以形成第三種方法。由于本發(fā)明示例實施例(出于描述的目的)基于TDMA MAC,因此根據(jù) 超幀的長度，每5或10毫秒產(chǎn)生一次從遠程STB到主STB的大量傳輸。對于該傳輸，遠程 STB從其傳輸隊列中取出分組并將它們組裝到用于傳輸?shù)膸蛄?或匯聚的幀)中。在示 例實施例中，所有該業(yè)務(wù)均發(fā)往主STB。對于第一種方法，遠程網(wǎng)橋設(shè)備檢查其發(fā)送隊列中 的幀的IP和TCP報頭，并確定可以刪除哪個ACK。根據(jù)幀的內(nèi)容，用一個TCP ACK來代替若 干TCP ACK。這允許將更短的CTA分配至遠程設(shè)備/STB，為分配至主設(shè)備/STB的CTA留下 更多時間，從而為下行視頻分配更多時間。在第二種方法中，通過主網(wǎng)橋設(shè)備產(chǎn)生返回主STB的TCP ACK。在這種情況下，主 STB誤認為分組已被遠程STB接收。主網(wǎng)橋設(shè)備記錄TCP滑動窗口、TCP序號、最大段大小 (MSS)及其本身的發(fā)送隊列。如果TCP幀過于頻繁地從主STB到達，則主網(wǎng)橋設(shè)備保持TCP ACK直到隊列級降低為止。這是流控制的一種形式。主網(wǎng)橋設(shè)備還攔截實際從遠程STB返 回的TCP ACK，以確保這些TCP ACK不會被轉(zhuǎn)發(fā)至主STB。可選地，TCP ACK可以被遠程網(wǎng) 橋設(shè)備攔截，并且如果需要可以將概要報告發(fā)送給主網(wǎng)橋設(shè)備。還可能的是，遠程網(wǎng)橋設(shè)備 丟棄所攔截的TCP ACK。第二種方法具有的優(yōu)點是，除了降低開銷還能夠減小小TCP滑動窗 口的負面影響。第三種方法將上述兩種方法進行組合。如第二種方法中的那樣，TCP ACK由網(wǎng)橋 設(shè)備(主或遠程)之一在本地產(chǎn)生，然而，如第一種方法所述的那樣，將由遠程STB返回的 TCP ACK進行組合。由于這些方法涉及MAC、IP和TCP層/功能并駐留在網(wǎng)橋/MAC層中， 因此這些方法被認為是跨層的。有利的是，減小了通過TCP傳送流的負面影響，同時不需要 改變STB。網(wǎng)橋設(shè)備識別并執(zhí)行有限量的TCP/IP處理。對于一般的數(shù)據(jù)網(wǎng)絡(luò)業(yè)務(wù)，工業(yè)上 多半使所有層保持分離和獨立。MAC層通常不知道在其幀的有效載荷中承載的數(shù)據(jù)業(yè)務(wù)的
6類型。例如，家用的以太網(wǎng)交換機不知道TCP或IP，并且實際上通常不需要安裝。網(wǎng)橋?qū)W(wǎng) 絡(luò)而言是透明的，并工作于MAC層。沒有一種分配系統(tǒng)中的現(xiàn)有方法針對于通過MAC/網(wǎng)橋 層的參與來減少TCP ACK。描述了一種用于管理確認的方法和裝置，包括通過連接來識別數(shù)據(jù)分組和確認、 確定可以刪除哪些確認、用單個確認來代替能夠被刪除的確認、以及發(fā)送該單個確認。描述 了一種用于管理確認的可選方法和裝置，包括接收數(shù)據(jù)段、跟蹤連接、確定是否存在針對 預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段、以及如果存在針對預(yù)定數(shù)目的信道時間分 配而言足夠多的數(shù)據(jù)段則產(chǎn)生針對所選連接的確認。還描述了將上述兩種方法進行組合的 又一可選方法。


當(dāng)結(jié)合附圖閱讀時，根據(jù)以下詳細描述可以更好地理解本發(fā)明。附圖包括以下簡 要描述的圖圖1是根據(jù)本發(fā)明原理的示例無線家庭視頻分配系統(tǒng)。圖2是MAC級網(wǎng)橋。圖3是通用無線網(wǎng)橋。圖4是本發(fā)明的示例實施例中、具有適于無線家庭視頻分布的約束路徑的無線網(wǎng) 橋。圖5是主STB和無線MAC網(wǎng)橋的服務(wù)器側(cè)的軟件(邏輯結(jié)構(gòu))的方框圖。圖6是遠程/客戶端STB和無線MAC網(wǎng)橋的客戶端側(cè)的軟件(邏輯結(jié)構(gòu))的方框 圖。圖7是根據(jù)本發(fā)明原理的無線MAC網(wǎng)橋的方框圖，示出了如何使用DTA。圖8示出了根據(jù)本發(fā)明的超幀。圖9是針對連接至視頻服務(wù)器(主STB)的PNC的高層發(fā)送分組流圖。圖10是針對連接至視頻服務(wù)器(主STB)的PNC的高層接收分組流圖。圖11是針對連接至視頻客戶端(遠程STB)的DEV-x的高層發(fā)送分組流圖。圖12是針對連接至視頻客戶端(遠程STB)的DEV-x的高層接收分組流圖。圖13示出了單個下行CTA (PNC至DEV-x)。圖14示出了超MAC幀(MAC幀的非標(biāo)準(zhǔn)匯聚)和物理幀格式。圖15示出了單個上行CTA (DEV-x至PNC)。圖 16 示出了 TCP/IP 封裝。圖17示出了 IP報頭。圖18示出了 TCP報頭。圖19示出了 TCP滑動窗口操作。圖20是在遠程橋接設(shè)備處的處理的示例實施例的高層流程圖。圖21是在主橋接設(shè)備處的處理的第二示例實施例的高層流程圖。圖22是在主橋接設(shè)備中轉(zhuǎn)發(fā)遠程確認(ACK)的高層流程圖。圖23是在遠程橋接設(shè)備處的第二實施例的高層流程圖。
具體實施例方式本發(fā)明以支持TDMA服務(wù)的IEEE802. 15. 3b MAC為基礎(chǔ)(信標(biāo)在超幀的起始處，傳 輸時間分配在超幀內(nèi))。IEEE 802. 15b是針對個人設(shè)計的，因此比為LAN或城域網(wǎng)(MAN)設(shè) 計的那些技術(shù)更“簡單”。盡管可以使用其他TDMA MAC(例如，IEEE802. 16)，但是現(xiàn)有技術(shù) 中還沒有嘗試純粹基于MAC層可以使用的業(yè)務(wù)特征來動態(tài)分配CTA長度。盡管IEEE 802. 16 是針對無線城域網(wǎng)(WMAN)設(shè)計的，并用于向服務(wù)訂戶進行因特網(wǎng)分配。IEEE 802. 16包含 使服務(wù)供應(yīng)商能夠訂制它們的網(wǎng)絡(luò)的許多特征和選項。雖然關(guān)于IEEE 802. 15. 3b來描述 本發(fā)明的示例實施例，但該構(gòu)思同樣可以應(yīng)用于IEEE 802. 16的實施例。存在稍多的用于 解析的報頭。當(dāng)設(shè)置CTA時存在一些必須考慮的TCP特征。TCP是利用32位序號和請求號以 及16位滑動窗口長度字段的傳輸協(xié)議。這三組數(shù)用來實現(xiàn)“停止等待”或“退回N幀”ARQ 差錯恢復(fù)方案。由于正被發(fā)送的發(fā)送隊列中的TCP分組“在網(wǎng)絡(luò)中”，因此必須由目的地將 TCP窗口設(shè)置的足夠大，以允許那些分組延遲。通常，MAC層橋接設(shè)備并不對設(shè)置窗口大小 進行控制，然而CTA的初始選擇和超幀的長度可以被選擇得足夠短以盡量減少問題。超幀 的長度是可調(diào)整的(可適應(yīng)的)，以便能夠改變TCP窗口大小。對于10毫秒超幀，每10毫秒發(fā)送大約19個1400字節(jié)的TCP分組。這相當(dāng)26600 比特。為了描述以下示例實施例，已選擇接近165千字節(jié)的發(fā)送緩沖隊列。對于TCP業(yè)務(wù)， 由于TCP窗口大小不允許多于64千字節(jié)的延遲數(shù)據(jù)，因此發(fā)送緩沖隊列將永遠不會溢出。 甚至可能的是，窗口可以足夠小以甚至不允許完全填滿CTA。為此，最好以短的超幀(5毫 秒)開始。此時發(fā)送緩沖隊列無需大于51千字節(jié)，但至少能夠處理單個TCP會話。然而， 選擇165千字節(jié)發(fā)送緩沖隊列，以避免在通過UDP發(fā)送視頻的情況下丟失分組。應(yīng)注意的是，ARQ差錯恢復(fù)方案的數(shù)學(xué)模型已在隊列理論領(lǐng)域中得到了充分的發(fā) 展，并且如果需要可以用它來更精確地對TCP性能進行建模。假設(shè)窗口足夠大從而允許足 夠的延遲TCP分組(一些分組在隊列中而另一些分組在CTA中)。在示例實施例中，允許多 達5次的重傳，CTA應(yīng)當(dāng)足夠小以致于約5次的數(shù)據(jù)可以加入發(fā)送緩沖隊列。如果使用最 大的TCP窗口，5毫秒的超幀將滿足上述情況。盡管初始應(yīng)用將是使用TCP的流視頻，但是存在足夠的實現(xiàn)不確定性，確保一般 意義下良好性能的唯一方式是允許該初始應(yīng)用適配于業(yè)務(wù)模式。實時的長度靈活的超幀結(jié)構(gòu)是可行的，這種超幀結(jié)構(gòu)被認為增加了系統(tǒng)健壯性并 改進了系統(tǒng)性能。超幀的長度可以取決于示例實施例中三個單獨視頻隊列的長度、下行傳 輸信道條件和任何其他可能的因素。在長度靈活的超幀的情況下，信標(biāo)必須廣播后繼CTA 的長度，并且通知每一遠程STB針對于它的CTA的長度。如上所述，存在這樣的可能如果相對于CTA的長度TCP接收窗口足夠小，則直 到從前幀接收到ACK服務(wù)器才釋放下個分組，從而有效地減慢了源處的流。所述速率可 能降至期望的實時流速率以下。為了避免上述情況，本發(fā)明選擇不會導(dǎo)致該欠數(shù)據(jù)情況 (starvedcondition)的CTA大小。為了保持適當(dāng)?shù)乃俾?，如果CTA大小減少了，那就需要 提高出現(xiàn)的頻率。這通過減小超幀的大小或通過每一超幀向該鏈路分配多個一個CTA來實 現(xiàn)。進一步如上所述，TCP窗口大小的不確定性導(dǎo)致改變 幀長度的可能。改變超幀長度可以在MAC層處通過基于查看TCP首部來觸發(fā)超幀改變予以實現(xiàn)；或更恰當(dāng)?shù)赝ㄟ^監(jiān) 控發(fā)送緩沖隊列，并在發(fā)送緩沖隊列為空的狀態(tài)過于頻繁導(dǎo)致CTA缺少發(fā)送數(shù)據(jù)的情況下 縮短超幀予以實現(xiàn)。首先，在示例實施例中使用固定超幀長度。給定固定超幀長度，研究如 何修改CTA長度以適應(yīng)業(yè)務(wù)特征。在這種情況下，由于STB中的TCP?？梢詫CK分組和 /或可以在包含數(shù)據(jù)的分組的首部中包括ACK，因此對于向通常用于TCP ACK的CTA分配多 長時間而言，存在某種不確定性。至少，已知任何給定發(fā)送隊列的平均輸出分組率必須保持在平均分組到達率之 下，否則，隊列將溢出。然而，即使平均到達率小于平均離開率，由于輸入流的統(tǒng)計屬性的緣 故，輸入速率可能臨時超過輸出速率。保持平均輸出速率高于平均輸入速率是必需的，但是 是不足夠的。由于缺乏IP業(yè)務(wù)的專一性，最好使系統(tǒng)具有自適應(yīng)性。為了實現(xiàn)自適應(yīng)性，記錄每一超幀的隊列信息。隊列信息包括隊列大小(如果是 固定的，則不需要發(fā)送)、隊列中分組的數(shù)目、隊列中分組的平均長度、以及輸入分組速率的 估計。將該信息與有關(guān)于到每一 DEV/遠程STB的可靠鏈路速率的信息一起用作自適應(yīng)算 法的輸入，自適應(yīng)算法的目標(biāo)是不使分組丟失，并且以達到所述目標(biāo)的方式向CTA分配超 幀時間。自適應(yīng)算法盡量使每一隊列中分組數(shù)量的期望值最小化(從而最小化延遲)，和/ 或使隊列溢出的概率最小化。通過監(jiān)控隊列級，MAC可以調(diào)整每一超幀的CTA，以優(yōu)先發(fā)送 幾乎充滿的隊列。本發(fā)明涉及無線視頻服務(wù)分配系統(tǒng)的MAC和橋接層，所述無線視頻服務(wù)分配系統(tǒng) 從主STB向遠程STB分配壓縮的視頻。系統(tǒng)部分利用了 IEEE 802. 15. 3b TDMA MAC，因此使 用該標(biāo)準(zhǔn)的一些術(shù)語。在圖1中示出了將所述技術(shù)內(nèi)建于STB中的示例系統(tǒng)。主STB 105從視頻的各種視頻源(包括先進電視制式委員會(ATSC)天線(數(shù)字電 視)、衛(wèi)星天線和廣域網(wǎng)(WAN)調(diào)制解調(diào)器)接收輸入。主STB向視頻顯示器110 (例如，電 視)提供輸出，視頻顯示器110包括合成式國家電視標(biāo)準(zhǔn)委員會(NTSC)視頻顯示器、高清 晰多媒體接口(HDMI)分量視頻顯示器、以及連接至用戶交換機的局域網(wǎng)(LAN)。主STB具 有5個衛(wèi)星調(diào)諧器(電子節(jié)目指南(EPG)、主調(diào)諧器、三個遠程調(diào)諧器和記錄調(diào)諧器)。主 調(diào)諧器用于調(diào)諧至與主STB進行通信的顯示器的用戶所期望的節(jié)目。三個遠程調(diào)諧器用于 調(diào)諧至遠程顯示器的每個用戶期望的節(jié)目。EPG調(diào)諧器用于調(diào)諧至電子節(jié)目指南。記錄調(diào) 諧器用于在與主STB進行通信的顯示器的用戶正在觀看由主衛(wèi)星調(diào)諧器調(diào)諧至的節(jié)目時， 調(diào)諧至該用戶期望記錄的節(jié)目。主STB具有兩個ATSC調(diào)諧器主調(diào)諧器和記錄調(diào)諧器。主 調(diào)諧器用于調(diào)諧至與主STB進行通信的顯示器的用戶期望的節(jié)目。記錄調(diào)諧器用于在與主 STB進行通信的顯示器的用戶正在觀看由主調(diào)諧器調(diào)諧至的節(jié)目時，調(diào)諧至該用戶期望記 錄的節(jié)目。主STB還具有解復(fù)用器(多路分配器)、個人錄像機(PVR)、與遙控設(shè)備一起使 用的紅外(IR)接收機、衛(wèi)星/ATSC解碼器和無線集線器。主STB 105可以以大約20Mbps 向每一遠程STB發(fā)送視頻。主STB 105可以與每一遠程STB交換衛(wèi)星供應(yīng)商IP業(yè)務(wù)。主 STB 105可以與每一遠程STB交換控制信息。主STB與三個遠程STB (遠程STBl 115、遠程STB2 125和遠程STB3 135)進行通 信。遠程STBl 115與視頻顯示器120進行通信。遠程STB2 125與視頻顯示器130進行通 信。遠程STB3 135與視頻顯示器140進行通信。遠程STB是以類似方式配置的，因此將僅 描述遠程STB1。遠程STBl 115具有衛(wèi)星/ATSC解碼器、與遙控設(shè)備一起使用的IR接收機、以及無線站。遠程STBl 115可以以大約20Mbps從接收主STB 105接收視頻。遠程STBl可 以在其自身與主STB 105之間交換衛(wèi)星供應(yīng)商IP業(yè)務(wù)。遠程STBl 115可以與主STB 105 交換控制信息。將本發(fā)明構(gòu)建為MAC級無線網(wǎng)橋(見圖2)。通常，MAC網(wǎng)橋連接相同或不同的LAN 網(wǎng)段。通過網(wǎng)橋互聯(lián)的不同LAN技術(shù)的集合被稱作網(wǎng)橋局域網(wǎng)。MAC網(wǎng)橋在MAC服務(wù)邊界 以下工作，并且對于MAC網(wǎng)橋服務(wù)邊界以上所使用的協(xié)議來說是透明的，只不過在QoS方面 有可能不同。MAC服務(wù)用戶位于MAC服務(wù)邊界之上，MAC服務(wù)供應(yīng)商位于MAC服務(wù)邊界之 下。MAC層網(wǎng)橋包括與每一 LAN網(wǎng)段/組件連接的中繼。圖3中示出了通用無線網(wǎng)橋。無線網(wǎng)橋305經(jīng)由以太網(wǎng)連接與服務(wù)器進行通信。 圖中示出了兩個服務(wù)器310、315。無線網(wǎng)橋305還經(jīng)由以太網(wǎng)連接與客戶端進行通信。圖 中示出了 4個客戶端320、325、330、335。DEVO在通用無線網(wǎng)橋內(nèi)，DEVO是微微網(wǎng)控制器 (PNC)340。PNC 340與多個設(shè)備進行無線通信。圖中示出了三個設(shè)備DEVl 345、DEV2 350 和DEV3 355。DEV0/PNC 340與服務(wù)器310、315進行通信。DEVl 345與客戶端320進行通 信。DEV2 350與客戶端325進行通信。DEV3 355與客戶端330、335進行通信。然而，本發(fā)明的示例實施例具有適于無線家庭視頻服務(wù)分配應(yīng)用的約束路徑。在 圖4中由虛線示出了可能的數(shù)據(jù)路徑。無線網(wǎng)橋405與主STB 410進行無線通信。無線網(wǎng) 橋405還與遠程STB 415、420、425進行無線通信。無線網(wǎng)橋405的內(nèi)部配置如圖2所示。 所有業(yè)務(wù)去往/來自主STB 410。圖5示出了服務(wù)器端(主STB和網(wǎng)橋設(shè)備)的軟件架構(gòu)。應(yīng)注意的是，主網(wǎng)橋設(shè) 備還是如IEEE 802. 15. 3所述的微微網(wǎng)控制器(PNC)。主STB 505具有主STB 505中的中 間件視頻服務(wù)器應(yīng)用510。多媒體流中間件515與媒體QoS控制520和設(shè)備驅(qū)動525連接。 多媒體流中間件515向設(shè)備驅(qū)動525轉(zhuǎn)發(fā)視頻數(shù)據(jù)，并與媒體Qos控制中間件520交換控 制信息。媒體QoS控制中間件與設(shè)備驅(qū)動525交換控制信息。設(shè)備驅(qū)動525主要與網(wǎng)絡(luò)接 口(IEEE 802. 3) 530交換視頻數(shù)據(jù)?？梢浦膊僮飨到y(tǒng)Unix (POSIX)驅(qū)動535的子集位于設(shè) 備驅(qū)動525內(nèi)，用于從媒體流中間件515接收視頻數(shù)據(jù)和控制信息，并與媒體QoS控制中間 件520交換信息。POSIX驅(qū)動的子集與TCP/IP棧540和媒體流協(xié)議545以及QoS管理和 控制550中的QoS中間件交換信息。PNC 555具有無線MAC視頻服務(wù)器網(wǎng)橋應(yīng)用560，無線 MAC視頻服務(wù)器網(wǎng)橋應(yīng)用560與軟件565交換控制信息，軟件565包括多個軟件模塊。軟件 565與無線射頻接口 570和IEEE802. 3驅(qū)動575交換視頻數(shù)據(jù)和控制信息。IEEE 802. 3驅(qū) 動主要與IEEE802. 3網(wǎng)絡(luò)接口 580交換視頻數(shù)據(jù)，IEEE802. 3網(wǎng)絡(luò)接口 580與IEEE 802. 3 網(wǎng)絡(luò)接口 530連接并交換該視頻信息。軟件565包括許多軟件組件，所述軟件組件包括覆 蓋在無線設(shè)備管理實體(DME)和IEEE802. 2幀匯聚子層(FCSL)服務(wù)接入點(SAP)上層的 IEEE802. ID橋接模塊。無線MAC視頻服務(wù)器網(wǎng)橋應(yīng)用560與無線DME管理SAP連接。無 線 DME 管理 SAP 以及無線 DME 和 IEEE 802. 2FCSL SAP 均覆蓋在 IEEE 802. 2FCSL DME 的 上層，IEEE 802. 2FCSL DME執(zhí)行IEEE 802. 15. 3b PNC的功能、進行QoS調(diào)度、以及管理網(wǎng) 橋功能。IEEE 802. 2 FCSL DME 覆蓋在 IEEE 802. 15. 3b MAC SAP 和 IEEE 802. 15. 3b MAC 層管理實體(MLME)SAP的上層。IEEE 802.15.3b MAC層管理實體(MLME) SAP覆蓋在IEEE 802. 15. 3b MLME上層，IEEE 802. 15. 3b MLME覆蓋在無線物理層管理實體(PLME) SAP上層。 IEEE 802. 15. 3b MAC SAP 覆蓋在 IEEE 802. 15. 3b MAC 子層上層，IEEE 802. 15. 3b MAC 子層覆蓋在無線物理SAP上層。IEEE 802. 15.3b MAC SAP覆蓋在無線物理層上層。無線物理 層管理實體(PLME) SAP覆蓋在無線物理層PLME上層。無線PLME與無線物理層進行通信。 IEEE 802. 15. 3b MAC子層與IEEE802. 15. 3b MLME進行通信。無線物理層和無線PLME分別 與無線射頻接口交換視頻數(shù)據(jù)和控制信息。圖6示出了客戶端側(cè)(遠程STB和網(wǎng)橋設(shè)備)的SW架構(gòu)。應(yīng)注意的是，本發(fā)明 處于網(wǎng)橋設(shè)備中，而上下文示出了 STB。應(yīng)注意的是，遠程/客戶端網(wǎng)橋設(shè)備還是如IEEE 802. 15. 3所述的DEV-x (非PNC設(shè)備)。遠程/客戶端STB 605中具有中間件視頻客戶端應(yīng) 用610。媒體流中間件615與媒體QoS控制620和設(shè)備驅(qū)動625連接。媒體流中間件615 將視頻數(shù)據(jù)接收至設(shè)備驅(qū)動625，并與媒體QoS控制中間件620交換控制信息。媒體QoS控 制中間件與設(shè)備驅(qū)動交換控制信息。設(shè)備驅(qū)動625主要與網(wǎng)絡(luò)接口(IEEE 802.3)630交換 視頻數(shù)據(jù)。POSIX驅(qū)動635的子集位于設(shè)備驅(qū)動625內(nèi)，用于主要向媒體流中間件615發(fā) 送視頻數(shù)據(jù)并與媒體QoS控制中間件620交換信息。POSIX驅(qū)動的子集與TCP/IP棧640和 媒體流協(xié)議545以及QoS管理和控制650中的QoS中間件交換信息。DEV_x 655具有無線 MAC視頻客戶端網(wǎng)橋應(yīng)用660，無線MAC視頻客戶端網(wǎng)橋應(yīng)用660與包括多個軟件模塊的軟 件665交換視頻數(shù)據(jù)和控制信息。軟件665與無線射頻接口 670和IEEE 802. 3驅(qū)動675 交換視頻數(shù)據(jù)和控制信息。IEEE 802. 3驅(qū)動主要與IEEE 802. 3網(wǎng)絡(luò)接口 680交換視頻數(shù) 據(jù)，IEEE 802. 3網(wǎng)絡(luò)接口 680與IEEE 802. 3網(wǎng)絡(luò)接口 630連接并與其交換該視頻數(shù)據(jù)。軟件665包括許多軟件組件，所述軟件組件包括覆蓋在無線DME和IEEE 802. 2 FCSL SAP上層的IEEE 802. ID橋接模塊。無線MAC視頻客戶端網(wǎng)橋應(yīng)用660與無線DME管理 SAP連接。無線DME管理SAP與無線DME和IEEE 802.2 FCSL SAP均覆蓋在IEEE 802.2 FCSL DME上層，IEEE 802. 2 FCSL DME執(zhí)行IEEE802. 15. 3b DEV-χ的功能、向PNC發(fā)送狀態(tài)以進 行QoS調(diào)度、以及管理網(wǎng)橋功能。IEEE802. 2 FCSL DME覆蓋在IEEE 802. 15.3b MAC SAP和 IEEE 802. 15. 3b MLME SAP 上層。IEEE 802. 15. 3b MLME SAP 覆蓋在 IEEE 802. 15. 3b MLME 上層，IEEE802. 15. 3b MLME覆蓋在無線物理層管理實體(PLME) SAP上層。IEEE802. 15. 3b MAC SAP覆蓋在IEEE 802. 15. 3b MAC子層上層，IEEE802. 15. 3b MAC子層覆蓋在無線物理 SAP上層。IEEE 802.15.3b MACSAP覆蓋在無線物理層上層。無線PLME SAP覆蓋在無線 物理層PLME上層。無線PLME與無線物理層進行通信。IEEE 802. 15. 3b MAC子層與IEEE 802.15.3b MLME進行通信。無線物理層和無線PLME與無線射頻接口交換視頻數(shù)據(jù)和控制 信息。軟件665和660接收具有關(guān)于CTA信息的信標(biāo)信號、接收下行CTA內(nèi)的再分配視頻 /媒體、并在適當(dāng)?shù)纳闲蠧TA中發(fā)送MAC級ACK或NAK。應(yīng)注意的是，這些ACK不同于當(dāng)使 用TCP時可以在視頻客戶端處產(chǎn)生的TCP ACK。下面參照圖7，圖7是根據(jù)本發(fā)明原理的無線MAC網(wǎng)橋的方框圖。PNC 705在所分 配的CTA中向/從遠程STB 710、715、720發(fā)送和接收數(shù)據(jù)/信息。主設(shè)備705周期性地發(fā) 送信標(biāo)，信標(biāo)制定了每一設(shè)備可以在其中發(fā)送其數(shù)據(jù)的信道時間分配(CTA)。CTA 1、2和3 用于下行業(yè)務(wù)(多數(shù)為視頻)。CTA 4、5和6用于上行業(yè)務(wù)(多數(shù)為TCP ACK和其他管理 幀)。在圖8中示出了超幀。主設(shè)備在傳輸信標(biāo)之前確定CTA。通常，CTA是由主設(shè)備/ PNC確定或由遠程設(shè)備/STB請求的固定時隙。特別地，對于IEEE 802. 15. 3b，標(biāo)準(zhǔn)指定遠 程STB/設(shè)備通過向PNC發(fā)送“CTReq”消息來請求帶寬。然而，無論請求還是設(shè)置CTA時間，沒有設(shè)備真正事先知道所有的IP業(yè)務(wù)特征，尤其對于遠程STB更是如此。業(yè)務(wù)可以基于 UDP(不返回ACK)或基于TCP。有時，所有的業(yè)務(wù)都是下行的，而有時較為對稱。期望通過 適配CTA內(nèi)的時間量來優(yōu)化業(yè)務(wù)流，以充分利用所有可用時間。首先通過無線方式發(fā)送超 幀的最左部分，然后通過無線方式發(fā)送超幀的最右部分。在信標(biāo)之后，以首先發(fā)送下行CTA 然后發(fā)送上行CTA的順序來發(fā)送CTA。本發(fā)明上下文中，超幀可以在5毫秒和10毫秒之間 改變。在圖9和10中示出了針對連接至主STB的PNC的示例分組流圖。在圖11和12 中示出了針對連接至遠程STB的DEV-x(即，非PNC設(shè)備)的示例分組流圖。如上所述，示 例高清晰視頻分配系統(tǒng)的無線MAC網(wǎng)橋充當(dāng)約束網(wǎng)橋?，F(xiàn)在參照圖9，PNC在以太網(wǎng)端口 905上接收以太網(wǎng)視頻數(shù)據(jù)幀(主要為視頻)。 PNC確定超幀的長度和每一 CTA。根據(jù)目的地MAC地址來將幀放入適當(dāng)?shù)陌l(fā)送隊列910a、 910b、910c。PNC可以通過如IEEE 802. D所述的泛洪(flooding)來學(xué)習(xí)MAC地址，或者可 以手動填寫濾波/路由表。為了減小圖上的混亂，在描述本發(fā)明時假設(shè)每一發(fā)送端口(發(fā) 往每一 DEV-x/遠程STB)僅有一個隊列。如果期望有多個優(yōu)先級，則每一發(fā)送端口(發(fā)往 每一 DEV-x/遠程STB)將存在多個隊列。即，每一優(yōu)先級組一個隊列。將以太網(wǎng)視頻數(shù)據(jù) 幀劃分成隊列。在示例實施例中，隊列分別是165千字節(jié)，并且超幀在5毫秒長和10毫秒 的長度之間。將隊列中的視頻數(shù)據(jù)幀轉(zhuǎn)發(fā)至軟件模塊915，軟件模塊915將以太網(wǎng)視頻數(shù) 據(jù)幀轉(zhuǎn)換成IEEE 802. 15.3b MAC幀，IEEE802. 15. 3b MAC幀包括優(yōu)先級映射、幀校驗序列 (FCS)、段和報頭校正碼(HCC)計算。軟件模塊915接收轉(zhuǎn)發(fā)表和服務(wù)流，以處理從數(shù)據(jù)存 儲單元920接收的以太網(wǎng)視頻數(shù)據(jù)幀。軟件模塊915與用于存儲發(fā)送MAC服務(wù)數(shù)據(jù)單元 (MSDU)的緩沖器925進行通信。軟件模塊930從軟件模塊915請求MAC幀，以便構(gòu)建超幀。 軟件模塊915向軟件模塊930轉(zhuǎn)發(fā)多個MSDU。軟件模塊930從數(shù)據(jù)存儲單元935接收物理 特征和參數(shù)，并從緩沖器940接收來自在先服務(wù)幀的MSDU確認(ACK)，以便構(gòu)建超幀。數(shù) 據(jù)存儲單元945從在先超幀接收被存儲為本地和遠程DEV(STB)隊列長度的MAC帶寬管理 命令，從而可以改變CTA長度。將該信息轉(zhuǎn)發(fā)至MAC帶寬管理實體950，MAC帶寬管理實體 950向軟件模塊930轉(zhuǎn)發(fā)CTA長度，以便進一步支持超幀的構(gòu)建。軟件模塊930還從超幀重 傳緩沖器955接收來自在先幀的、要被重傳的MSDU，所述超幀重傳緩沖器955在每一遠程 STB MAC協(xié)議數(shù)據(jù)單元(MPDU)中存儲多個MSDU并丟棄已確認的MSDU。將由軟件模塊930 構(gòu)建的超幀存儲在超幀構(gòu)建緩沖器960中。由軟件模塊930構(gòu)建的超幀包括下行MPDU和 上行時間。超幀構(gòu)建緩沖器960以每一遠程STB MPDU多個MSDU的形式將所構(gòu)建的超幀轉(zhuǎn) 發(fā)至超幀發(fā)送緩沖器965。超幀發(fā)送緩沖器965將其從超幀構(gòu)建緩沖器接收的超幀轉(zhuǎn)發(fā)至 超幀重傳緩沖器955。超幀發(fā)送緩沖器965將完整的MPDU轉(zhuǎn)發(fā)至軟件模塊970。軟件模塊 在接收間隔期間從遠程STB接收延遲的ACK，并從定時時鐘975接收定時信息。軟件模塊 970將多個MSDU匯聚在每一 MPDU中，并將它們轉(zhuǎn)發(fā)至發(fā)送用的物理層模塊980。軟件模塊 970基于信標(biāo)中的定時使用定時，并將發(fā)送數(shù)據(jù)、發(fā)送數(shù)據(jù)速率、發(fā)送長度、發(fā)送功率電平和 發(fā)送天線控制轉(zhuǎn)發(fā)至物理層模塊980，物理層模塊980將物理數(shù)據(jù)協(xié)議單元(PPDU)從PNC 發(fā)送至指定的遠程STB。由于圖10示出了接收分組的流動，描述將從圖的右側(cè)開始進行。在物理層軟件模 塊1005處接收PPDU，物理層軟件模塊1005還從定時時鐘1010接收輸入。物理層軟件模塊
12將所接收的數(shù)據(jù)、長度、鏈路質(zhì)量指示符(LQI)、接收信號強度指示符(RSSI)和PHY接收錯 誤轉(zhuǎn)發(fā)至軟件模塊1015。軟件模塊1015基于定時信標(biāo)利用定時將PPDU分成由MSDU匯聚 的MPDU，并將MPDU轉(zhuǎn)發(fā)至軟件模塊1020，軟件模塊1020執(zhí)行HCC計算、分離完整MSDU幀 或片段、處理幀校驗序列、記錄正確接收的MSDU、響應(yīng)于延遲的ACK請求來構(gòu)建延遲的ACK、 以及對MSDU進行過濾從而將僅用于服務(wù)器的正確MSDU傳送至服務(wù)器(主STB)。軟件模塊 1020轉(zhuǎn)發(fā)針對所接收的MSDU的延遲ACK，并丟棄不用于服務(wù)器(主STB)的MSDU。軟件模 塊1020從數(shù)據(jù)存儲單元1025接收物理特征和參數(shù)，以便執(zhí)行上述功能。軟件模塊1020將 諸如延遲ACK等MAC命令和帶寬管理消息轉(zhuǎn)發(fā)至軟件模塊1030，軟件模塊1030分離MAC命 令，并將MSDU ACK轉(zhuǎn)發(fā)至MSDU ACK緩沖器1035以及將MAC帶寬信息單元(IE)轉(zhuǎn)發(fā)至MAC 帶寬管理實體1040。軟件模塊1020還將MSDU (主要是TCP ACK)轉(zhuǎn)發(fā)至軟件模塊1045，軟 件模塊1045根據(jù)片段重構(gòu)完整的MSDU、存儲不完整的MSDU的片段以及以適當(dāng)?shù)捻樞蚍胖?MSDU。軟件模塊1045與重排序幀構(gòu)建緩沖器1050以及接收MSDU片段緩沖器1055進行通 信。軟件模塊1045將完整的MSDU轉(zhuǎn)發(fā)至軟件模塊1060，在軟件模塊1060中將完整的MSDU 轉(zhuǎn)換成包括幀校驗序列和優(yōu)先級映射的以太網(wǎng)幀。軟件模塊從數(shù)據(jù)存儲單元1065接收轉(zhuǎn) 發(fā)表和服務(wù)流信息，并將以太網(wǎng)幀轉(zhuǎn)發(fā)至服務(wù)器(主STB)。圖11是針對連接至遠程STB (視頻客戶端)的DEV-x的高層發(fā)送分組流。由軟件 模塊1105接收以太網(wǎng)幀，軟件模塊1105對來自視頻客戶端的輸入幀進行過濾和分類。軟 件模塊1105將以太網(wǎng)幀轉(zhuǎn)發(fā)至幀隊列1110。由于所有的業(yè)務(wù)都將去往服務(wù)器(主STB)， 因此僅存在一個隊列。然而，如果期望多個優(yōu)先級，則應(yīng)實現(xiàn)多個隊列(每一優(yōu)先級組一個 隊列)。將隊列中的數(shù)據(jù)轉(zhuǎn)發(fā)至軟件模塊1115，軟件模塊1115將以太網(wǎng)幀轉(zhuǎn)換成包括優(yōu)先 級映射、幀校驗序列、段和HCC計算的IEEE 802. 15.3MAC幀。軟件模塊1115從數(shù)據(jù)存儲單 元1120接收轉(zhuǎn)發(fā)表和服務(wù)流信息。軟件模塊1115還與發(fā)送MSDU發(fā)送緩沖器1125進行通 信。軟件模塊將多個MSDU轉(zhuǎn)發(fā)至軟件模塊1130，軟件模塊1130在下個超幀內(nèi)構(gòu)建用于發(fā) 送的上行MPDU。軟件模塊1115還接收來自軟件模塊1130的請求。軟件模塊1130從緩沖 器1135接收來自在先超幀的MSDU ACK。軟件模塊1130從數(shù)據(jù)存儲單元1140接收物理特 征和參數(shù)，并從數(shù)據(jù)存儲單元1140接收來自信標(biāo)的CTA信息。軟件模塊1130從軟件模塊 1150接收MAC帶寬管理命令，軟件模塊1150使用從數(shù)據(jù)存儲單元1155接收的本地隊列長 度信息和從數(shù)據(jù)存儲單元1160接收的來自在先超幀的MAC帶寬請求響應(yīng)(以非標(biāo)準(zhǔn)方式 使用IEEE 802. 15. 3MAC命令來交換隊列信息)來構(gòu)建帶寬管理消息。軟件模塊1130從超 幀重傳緩沖器1165接收來自在先幀的、要被重傳的MSDU。超幀重傳緩沖器1165還丟棄已 確認的MSDU。軟件模塊1130與構(gòu)建緩沖器1170進行通信，構(gòu)建緩沖器1170是針對下一超 幀的上行MPDU的緩沖器。構(gòu)建緩沖器1170將上行MPDU轉(zhuǎn)發(fā)至超幀發(fā)送緩沖器1175，超幀 發(fā)送緩沖器1175將上行MPDU轉(zhuǎn)發(fā)至軟件模塊1180。超幀發(fā)送緩沖器1175還將上行MPDU 轉(zhuǎn)發(fā)至超幀重傳緩沖器1165。軟件模塊1180基于信標(biāo)利用定時將多個MSDU匯聚在每一 MPDU中，并將MPDU傳送至發(fā)送用的物理層軟件模塊1185。軟件模塊從定時時鐘1190接收 定時，并在接收間隔期間從服務(wù)器(主STB)接收延遲的ACK。軟件模塊1180將發(fā)送數(shù)據(jù)、 發(fā)送數(shù)據(jù)速率、發(fā)送長度、發(fā)送功率電平、以及發(fā)送天線控制轉(zhuǎn)發(fā)至物理層軟件模塊1185。在圖12中示出了遠程DEV中接收處理的大致過程。接收處理主要包括分解超幀 然后重構(gòu)以太網(wǎng)幀(包括重組被分為片段的幀)。接收端還檢查錯誤，并準(zhǔn)備用于發(fā)回PNC的DLY ACK(—種大的ACK)。在與其中有分組到達CTA反方向的CTA的起始時刻發(fā)送DLY ACK。這是與標(biāo)準(zhǔn)存在的另一偏差。圖12是針對連接至視頻客戶端(遠程STB)的DEV-x的高層接收分組的流圖，因 此描述將從圖的右側(cè)開始進行。軟件模塊1205接收PPDU并將所接收的數(shù)據(jù)、所接收的錯 誤、長度、LQI和RSSI轉(zhuǎn)發(fā)至軟件模塊1215。軟件模塊1205從軟件模塊1215接收天線控 制信息，并從定時時鐘1210接收定時信息。軟件模塊1215從物理層軟件模塊1205接收 MPDU。將多個MSDU匯聚到每一 MPDU中。軟件模塊1215從定時時鐘1210接收定時。軟件 模塊1215將MPDU片轉(zhuǎn)發(fā)至軟件模塊1220，軟件模塊1220執(zhí)行HCC計算、分離完整MSDU幀 或片段、處理幀校驗序列、記錄正確接收的MSDU、響應(yīng)于延遲的ACK請求構(gòu)建延遲的ACK、以 及對MSDU進行過濾并僅轉(zhuǎn)發(fā)用于服務(wù)器(主STB)的正確接收的MSDU。軟件模塊從數(shù)據(jù)存 儲單元1225接收物理特征和參數(shù)，并轉(zhuǎn)發(fā)針對所接收的MSDU的延遲ACK。軟件模塊1220 丟棄不用于視頻客戶端(遠程STB)的MSDU，并將MAC命令轉(zhuǎn)發(fā)至軟件模塊1230，軟件模塊 1230分離MAC管理消息，并將MAC帶寬響應(yīng)轉(zhuǎn)發(fā)至數(shù)據(jù)存儲單元1235，以及將來自遠程STB 的MSDU ACK轉(zhuǎn)發(fā)至MSDU緩沖器1240。軟件模塊1220將MSDU轉(zhuǎn)發(fā)至軟件模塊1245，軟件 模塊1245根據(jù)片段重構(gòu)完整的MSDU、存儲不完整MSDU的片段、以及以適當(dāng)順序放置MSDU。 軟件模塊1245與重排序和幀構(gòu)建緩沖器1250以及接收MSDU片段緩沖器1255進行通信。 軟件模塊1245將完整的MSDU轉(zhuǎn)發(fā)至軟件模塊1260，軟件模塊1260將MAC幀轉(zhuǎn)換成包括優(yōu) 先級的以太網(wǎng)幀。軟件模塊1260還從數(shù)據(jù)存儲單元1265接收轉(zhuǎn)發(fā)表和服務(wù)流信息。參照圖13，物理前導(dǎo)和物理報頭組成每一 CTA中的一個物理幀。發(fā)往遠程STB的 延遲ACK、對遠程STB的隊列狀態(tài)信息請求(隊列Res)和發(fā)往遠程STB的多個數(shù)據(jù)分組組 成具有保護MAC報頭的MAC幀的集合。與CTA內(nèi)任何剩余時間級聯(lián)的上述物理幀和MAC幀 集合組成了發(fā)往遠程STB的PNC的下行CTA?，F(xiàn)在參照圖14，對于每一 MAC有效載荷，存在相應(yīng)的MAC報頭。對HCC進行計算并 將其插在MAC報頭之后MAC有效載荷之前。對FCS進行計算，并將其插在MAC有效載荷之 后。這可以針對每一 MAC有效載荷來進行以創(chuàng)建超MAC幀。超MAC幀長度是物理報頭的一 部分，將物理報頭插入超MAC幀之前來形成CTA，對CTA進行調(diào)制和并通過無線方式將其發(fā) 送。以慢而可靠的速率來發(fā)送物理報頭，并以某期望速率來發(fā)送CTA的超MAC部分。以類似的方式來發(fā)送CTA4、5和6內(nèi)的幀。圖15中示出了這些CTA之一中發(fā)送的 幀的示例，圖15示出了單個上行CTA(DEV-x至PNC)，單個上行CTA包括物理幀和具有保護 報頭的MAC幀的集合以及CTA內(nèi)的任何剩余時間。對于本發(fā)明，多數(shù)上行業(yè)務(wù)將是TCP ACK。 類似于圖13中所示的下行CTA，物理幀包括物理前導(dǎo)和物理報頭。MAC幀的集合包括發(fā)往 PNC的延遲ACK、發(fā)往PNC的隊列信息和發(fā)往PNC的數(shù)據(jù)分組。應(yīng)注意的是，該CTA包括將 隊列狀態(tài)信息攜帶回PNC的幀。該隊列狀態(tài)信息可以包括隊列的大小(如果隊列的大小 是可變的)、隊列中的幀數(shù)、幀的平均長度、以及隊列輸入處的幀到達率。對于本發(fā)明，假設(shè)使用TCP從主STB發(fā)送視頻流分組(下行)。由此，將沿著視頻 的反向(上行)產(chǎn)生TCP ACK。這些TCP ACK添加了開銷，如果去除這些開銷，則可以為更 多的實際業(yè)務(wù)(即，下行視頻)節(jié)省時間。此外，由于構(gòu)建至TCP中的流控制機制以及由于 無線網(wǎng)橋所添加的額外延時(由于緩沖器和CTA)，TCP可以保持視頻流達到實際需要達到 的速率。
14
首先，簡要描述TCP，從而更好地理解該問題。然后提出可以幫助解決問題的幾個 位于高層的跨層修改。應(yīng)當(dāng)注意，改變主STB和遠程STB中TCP參數(shù)本身將是解決該問題 的另一方式，但是如多次所提及的，假設(shè)這種方式是不可能的。TCP是全雙工的面向連接的傳輸協(xié)議，TCP發(fā)送數(shù)據(jù)流的段。UDP發(fā)送所述分組。 TCP的一個特征是可靠傳送。這可以通過使用TCP ACK來確保。盡管已證明該機制對因特 網(wǎng)業(yè)務(wù)有利，但用于創(chuàng)建可靠傳送的優(yōu)點在已具有高可靠性的LAN上是存在問題的。因此， TCP ACK增加了顯著的開銷。在網(wǎng)絡(luò)帶寬有限(諸如無線網(wǎng)絡(luò))的情況下，該開銷的缺陷極 大。圖16中示出了 TCP封裝。TCP報頭附加在TCP有效載荷之前。IP報頭比附加在 這二者之前。TCP有效載荷和TCP報頭的組合又被稱作TCP段。TCP段和IP報頭的組合又 被稱作IP數(shù)據(jù)報。圖17和18分別示出了 IP報頭和TCP報頭。IP報頭包括目的地IP地址和源IP 地址。此外，IP報頭包括用于標(biāo)識其有效載荷的協(xié)議號。在TCP的情況下，該協(xié)議號為17。 在UDP的情況下，該協(xié)議號為6。TCP報頭包括目的地端口號和源端口號。位于各端的設(shè)備 使用端口號來標(biāo)識軟件應(yīng)用或與TCP連接相關(guān)聯(lián)的碼。此外，TCP報頭包括對本發(fā)明的操作而言十分重要的若干其他字段。由于TCP是 全雙工連接，每一端保留分離的序號計數(shù)器。32比特序號是字節(jié)計數(shù)器，針對作為相同TCP 連接一部分的離開的每一分組，通過源設(shè)備使字節(jié)計數(shù)器遞增。報頭還包括用于通知發(fā)送 機接收機所期望的下個字節(jié)的32比特的確認號(換言之，接收機已成功接收到字節(jié)-1)。 全雙工TCP連接的反向遵循相同過程。將最大段大小(MSS)從接收機發(fā)送至發(fā)送機，指示其可以接收的最大段大小(字 節(jié))。典型的TCP MSS是1024 (通常)、536(默認，在一端不從另一端接收MSS的情況下)、 在以太網(wǎng)上為1460，等等。默認的536反應(yīng)出IP必須能夠處理最小尺寸為576字節(jié)的分組 (有效載荷以及TCP和IP報頭)的事實。因此，發(fā)送至因特網(wǎng)的業(yè)務(wù)通常受限于該數(shù)字。 通過路徑最大傳輸單元(MTU)發(fā)現(xiàn)來確定外部與內(nèi)部路由。校驗和覆蓋TCP報頭和數(shù)據(jù)，并用于確定是否已正確接收到幀。最常見的選擇字 段是當(dāng)建立連接時發(fā)送的最大段大小(MSS)。ACK字段表示確認值是有效的。序號用于在無需選擇性重傳或否定確認的情況下實現(xiàn)滑動窗口協(xié)議。序號可以使 用在“退回N幀”方案或“停止等待”方案中。在圖19中示出了 TCP滑動窗口操作。基本 上，在任何給定時刻，“在網(wǎng)絡(luò)中”允許有限數(shù)目的未確認的字節(jié)。當(dāng)字節(jié)被確認時，窗口的 尾部向左移動。當(dāng)字節(jié)被確認和/或公告了更大窗口時，窗口的前端向左移動?？捎么翱谥?剩余的字節(jié)數(shù)目取決于窗口大小以及已經(jīng)發(fā)送了多少字節(jié)。目的地基于其可以接收的字節(jié) 數(shù)(可能基于接收緩沖器大小)來設(shè)置窗口大小?；瑒哟翱趯?dǎo)致以下所示的公知帶寬時延 禾只的限制° Window_Size (Capacity) = effective BW(bits/sec) XRound Trip Time (sec)TCP最初僅具有16-比特窗口大小，這意味著當(dāng)TCP接收機將窗口大小設(shè)置為最大 時，在網(wǎng)絡(luò)中僅允許64千字節(jié)。已對窗口大小進行修改使其包括縮放選項，允許在網(wǎng)絡(luò)中 存在更多未確認的字節(jié)。然而，由于傳統(tǒng)實現(xiàn)以及傳統(tǒng)實現(xiàn)“多數(shù)時間”有效，因此許多實 現(xiàn)方式仍舊僅使用16比特滑動窗口。由于視頻所需的高帶寬以及TDMA MAC無線網(wǎng)橋所需 的延時，有限的TCP滑動窗口在目標(biāo)應(yīng)用中會引起問題。
為了了解滑動窗口如何對示例橋接系統(tǒng)產(chǎn)生負面影響，考慮以下示例。對于超幀 長度固定為5或10毫秒以及CTA固定的情況，表1示出了一些代表性的值。表2示出了使 用這里所示的MPDU匯聚方法、在每一 CTA內(nèi)期望的分組的近似數(shù)目和若干其他特定假設(shè) (例如，視頻分組大小)。往返時間(RTT)是從發(fā)送TCP分組的時刻到接收僅與該段相關(guān)聯(lián) 的TCP ACK的時刻的時間。如果超幀為10毫秒，則RTT至少為20毫秒。由于發(fā)送隊列中 的分組以及MAC層處的重傳，RTT實際上將更高。在20Mbps和20毫秒延時下，滑動窗口將 必須至少為50千比特，以允許流以期望的速率運行。在該示例中，額外的緩沖以及數(shù)據(jù)到 來與CTA的起始不同步將有可能使流慢下來。此外，TCP滑動窗口可以被設(shè)置為低于50千 字節(jié)。表1超MAC幀大小和推薦CTA長度
權(quán)利要求
一種用于管理確認的方法，包括通過連接來識別數(shù)據(jù)分組和確認；確定能夠刪除所述確認中的哪些確認；利用單個確認來代替能夠被刪除的所述確認；以及發(fā)送所述單個確認。
2.根據(jù)權(quán)利要求1所述的方法，其中，所述識別動作還包括查看發(fā)送隊列中的報頭。
3.根據(jù)權(quán)利要求2所述的方法，其中，所述查看動作還包括查看所述報頭中的標(biāo)記。
4.根據(jù)權(quán)利要求2所述的方法，其中，所述確定動作還包括確定哪些確認是來自公共 連接的。
5.根據(jù)權(quán)利要求4所述的方法，還包括讀取所述報頭中的序號。
6.根據(jù)權(quán)利要求5所述的方法，其中，所述單個確認具有被確認的所述數(shù)據(jù)分組的最高序號。
7.根據(jù)權(quán)利要求1所述的方法，還包括 確定是否存在要傳輸?shù)挠行лd荷分組；以及 在所述有效載荷分組中發(fā)送所述單個確認。
8.根據(jù)權(quán)利要求1所述的方法，其中，所述連接是TCP連接。
9.根據(jù)權(quán)利要求1所述的方法，其中，所述確認是TCP確認，并且所述單個確認是TCP 確認。
10.一種用于管理確認的方法，包括 接收數(shù)據(jù)段；跟蹤連接；確定是否存在針對預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段；以及 如果存在針對所述預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段，則產(chǎn)生針對所選連 接的所述確認。
11.根據(jù)權(quán)利要求10所述的方法，還包括如果幀到達得過于頻繁，則保留確認。
12.根據(jù)權(quán)利要求10所述的方法，還包括 攔截由遠程設(shè)備轉(zhuǎn)發(fā)的段確認；確定所述段是否已被確認；如果所述段已被確認，則丟棄所述段確認；以及如果所述段還未被確認，則轉(zhuǎn)發(fā)所述段確認。
13.根據(jù)權(quán)利要求10所述的方法，還包括接收概要報告。
14.根據(jù)權(quán)利要求10所述的方法，其中，所述連接是TCP連接。
15.根據(jù)權(quán)利要求10所述的方法，其中，所述確認是TCP確認。
16.根據(jù)權(quán)利要求10所述的方法，還包括將所述確認匯聚到單個確認中。
17.一種用于管理確認的設(shè)備，包括用于通過連接來識別數(shù)據(jù)分組和確認的裝置； 用于確定能夠刪除所述確認中的哪些確認的裝置； 用于利用單個確認來代替能夠被刪除的所述確認的裝置；以及 用于傳輸所述單個確認的裝置。
18.根據(jù)權(quán)利要求17所述的設(shè)備，其中，所述用于識別的裝置還包括用于查看發(fā)送隊 列中的報頭的裝置。
19.根據(jù)權(quán)利要求18所述的設(shè)備，其中，所述用于查看的裝置還包括用于查看所述報 頭中標(biāo)記的裝置。
20.根據(jù)權(quán)利要求18所述的設(shè)備，其中，所述用于確定的裝置還包括用于確定哪些確 認是來自公共連接的裝置。
21.根據(jù)權(quán)利要求20所述的設(shè)備，還包括用于讀取所述報頭中的序號的裝置。
22.根據(jù)權(quán)利要求21所述的設(shè)備，其中，所述單個確認具有被確認的所述數(shù)據(jù)分組的最高序號。
23.根據(jù)權(quán)利要求17所述的設(shè)備，還包括用于確定是否存在要傳輸?shù)挠行лd荷分組的裝置；以及 用于在所述有效載荷分組中發(fā)送所述單個確認的裝置。
24.根據(jù)權(quán)利要求17所述的設(shè)備，其中，所述連接是TCP連接。
25.根據(jù)權(quán)利要求17所述的設(shè)備，其中，所述確認是TCP確認，并且所述單個確認是 TCP確認。
26.一種用于管理確認的設(shè)備，包括 用于接收數(shù)據(jù)段的裝置；用于跟蹤連接的裝置；用于確定是否存在針對預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段的裝置；以及 用于如果存在針對所述預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段則產(chǎn)生針對所 選連接的所述確認的裝置。
27.根據(jù)權(quán)利要求26所述的設(shè)備，還包括用于如果幀到達過于頻繁則保留確認的裝置。
28.根據(jù)權(quán)利要求26所述的設(shè)備，還包括 用于攔截由遠程設(shè)備轉(zhuǎn)發(fā)的段確認的裝置； 用于確定所述段是否已被確認的裝置；用于如果所述段已被確認則丟棄所述段確認的裝置；以及 用于如果所述段還未被確認則轉(zhuǎn)發(fā)所述段確認的裝置。
29.根據(jù)權(quán)利要求16所述的設(shè)備，還包括接收概要報告。
30.根據(jù)權(quán)利要求16所述的設(shè)備，其中，所述連接是TCP連接。
31.根據(jù)權(quán)利要求26所述的設(shè)備，其中，所述確認是TCP確認。
32.根據(jù)權(quán)利要求26所述的設(shè)備，還包括用于將所述確認匯聚到單個確認中的裝置。
全文摘要
描述了一種用于管理確認的方法和裝置，包括通過連接來識別數(shù)據(jù)分組和確認、確定可以刪除哪些確認、用單個確認來代替能夠被刪除的確認、以及發(fā)送該單個確認。描述了一種用于管理確認的可選方法和裝置，包括接收數(shù)據(jù)段、跟蹤連接、確定是否存在針對預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段、以及如果存在針對預(yù)定數(shù)目的信道時間分配而言足夠多的數(shù)據(jù)段則產(chǎn)生針對所選連接的確認。
文檔編號H04W84/20GK101971590SQ200680056686
公開日2011年2月9日 申請日期2006年12月20日 優(yōu)先權(quán)日2006年12月20日
發(fā)明者托馬斯·安東尼·施塔爾, 闐慶江 申請人:湯姆森許可貿(mào)易公司