一種資源預(yù)約方法及裝置制造方法
【專利摘要】一種資源預(yù)約方法及裝置，應(yīng)用于WiFi系統(tǒng)中，所述方法包括：目的節(jié)點接收源節(jié)點發(fā)送的資源預(yù)約請求，并向所述源節(jié)點發(fā)送資源預(yù)約響應(yīng)，所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽所述資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量；所述目的節(jié)點判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)，如果未接收到，則向所述其它節(jié)點發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量，重新競爭資源。這樣，就能在解決隱藏節(jié)點問題的同時，保證網(wǎng)絡(luò)資源的充分合理利用。
【專利說明】一種資源預(yù)約方法及裝置
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及通信【技術(shù)領(lǐng)域】，具體涉及一種資源預(yù)約方法及裝置。
【背景技術(shù)】
[0002] 為了解決WiFi網(wǎng)絡(luò)存在的"隱藏節(jié)點"問題，IEEE802. 11標(biāo)準(zhǔn)引入了 RTS/ CTS(Request To Send/Clear To Send,請求發(fā)送/清除發(fā)送）機(jī)制，該機(jī)制相當(dāng)于一種握 手協(xié)議，其基本原理就是源節(jié)點和目的節(jié)點各發(fā)送一個用于預(yù)約資源的短幀，以此來抑制 其它節(jié)點競爭資源，具體過程可簡述如下：
[0003] 首先，源節(jié)點向網(wǎng)絡(luò)中的其它節(jié)點發(fā)送RTS(Request To Send,請求發(fā)送）中貞， 以使偵聽到該幀的節(jié)點根據(jù)RTS幀中的持續(xù)時間域Duration表示的時間T1設(shè)置自身的 NAV(Network Allocation Vector,網(wǎng)絡(luò)分配矢量），進(jìn)而通過NAV倒數(shù)計數(shù)的方式避免與源 節(jié)點競爭資源。
[0004] 其次，目的節(jié)點接收到RTS巾貞之后，相隔一個SIFS (Short Interframe Space,短中貞 間間隔）向網(wǎng)絡(luò)中的其它節(jié)點發(fā)送CTS(Clear To Send，清除發(fā)送）幀，以使偵聽到該幀的 節(jié)點根據(jù)CTS巾貞中的Duration域表示的時間T2設(shè)置自身的NAV，進(jìn)而通過NAV倒數(shù)計數(shù)的 方式避免與目的節(jié)點競爭資源。
[0005] 最后，源節(jié)點接收到CTS幀后，相隔一個SIFS與目的節(jié)點進(jìn)行數(shù)據(jù)傳輸。
[0006] 因為，所有接收到RTS幀或者CTS幀的節(jié)點的NAV均大于默認(rèn)值0,而只要NAV大 于0,節(jié)點即會認(rèn)為周圍存在數(shù)據(jù)傳輸，信道處于忙狀態(tài)，就不會嘗試競爭信道，從而有效避 免節(jié)點碰撞。需要說明的是，目的節(jié)點和源節(jié)點雖然也可根據(jù)RTS幀或者CTS幀設(shè)置自身 的NAV值，但二者無需根據(jù)NAV值判斷信道狀態(tài)。
[0007] 然而，受干擾和隨機(jī)噪聲等因素的影響，WiFi系統(tǒng)的信道經(jīng)常處于不穩(wěn)定狀態(tài)，這 就可能出現(xiàn)CTS幀傳輸失敗、或者源節(jié)點解析CTS幀失敗等情況，進(jìn)而導(dǎo)致源節(jié)點不再進(jìn)行 后續(xù)數(shù)據(jù)幀的發(fā)送，使得目的節(jié)點在發(fā)出CTS幀并相隔一個SIFS之后接收不到源節(jié)點發(fā)送 的數(shù)據(jù)幀。但是，在目的節(jié)點發(fā)出CTS幀之后，能偵聽到該幀的節(jié)點已經(jīng)根據(jù)時間T2設(shè)置 了自身的NAV，這些節(jié)點在NAV歸零前始終認(rèn)為信道處于忙狀態(tài)，其傳輸被抑制，這就會導(dǎo) 致這一時間段內(nèi)信道資源的浪費，降低網(wǎng)絡(luò)資源利用率。
【發(fā)明內(nèi)容】
[0008] 本發(fā)明實施例的資源預(yù)約方法及裝置，用以提高WiFi系統(tǒng)的資源利用率。
[0009] 為此，本發(fā)明實施例提供如下技術(shù)方案：
[0010] 第一方面，本發(fā)明實施例提供了一種資源預(yù)約方法，所述方法應(yīng)用于WiFi系統(tǒng)， 所述方法包括：
[0011]目的節(jié)點接收源節(jié)點發(fā)送的資源預(yù)約請求，并向所述源節(jié)點發(fā)送資源預(yù)約響應(yīng)， 所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽所述 資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量；
[0012] 所述目的節(jié)點判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)，如果未接收 至IJ，則發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量，重新競爭資源。
[0013] 在第一方面的第一種可能的實現(xiàn)方式中，在所述向所述其它節(jié)點發(fā)送資源釋放指 令之前，所述方法還包括：
[0014] 計算獲得所述預(yù)約時間的剩余時間，并與發(fā)送所述資源釋放指令所需的時間相比 較，若所述剩余時間不小于發(fā)送所述資源釋放指令所需的時間，則向所述其它節(jié)點發(fā)送所 述資源釋放指令；其中，所述剩余時間為所述預(yù)約時間與所述預(yù)定時間之差。
[0015] 結(jié)合第一方面以及第一方面的第一種可能的實現(xiàn)方式，在第二種可能的實現(xiàn)方式 中，所述資源預(yù)約響應(yīng)為所述目的節(jié)點接收到所述資源預(yù)約請求后，相隔一個第一幀間間 隔發(fā)送的第一資源預(yù)約響應(yīng)；
[0016] 則所述向所述其它節(jié)點發(fā)送資源釋放指令，包括：
[0017] 所述目的節(jié)點向所述其它節(jié)點發(fā)送第一資源釋放指令，以使所述其它節(jié)點根據(jù)所 述第一資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
[0018] 結(jié)合第一方面以及第一方面的第一種可能的實現(xiàn)方式，在第三種可能的實現(xiàn)方式 中，所述資源預(yù)約響應(yīng)為所述目的節(jié)點接收到所述資源預(yù)約請求后，相隔一個第一幀間間 隔、第一資源預(yù)約響應(yīng)以及第二幀間間隔發(fā)送的第二資源預(yù)約響應(yīng)；
[0019] 則所述向所述其它節(jié)點發(fā)送資源釋放指令，包括：
[0020] 所述目的節(jié)點向所述其它節(jié)點發(fā)送第一資源釋放指令，并相隔一個所述第一幀間 間隔向所述其它節(jié)點發(fā)送第二資源釋放指令，以使所述其它節(jié)點根據(jù)所述第一資源釋放指 令或者第二資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
[0021] 結(jié)合第一方面以及第一方面的第一種至第三種任一種可能的實現(xiàn)方式，在第四種 可能的實現(xiàn)方式中，
[0022] 所述預(yù)定時間 T = aSIFSTime+aPHY-RX-START-Delay+aSlotTime，
[0023] 其中，aSIFSTime為第一幀間間隔，aPHY-RX-START-Delay為物理層反應(yīng)時間， aSlotTime為時隙長度。
[0024] 結(jié)合第一方面以及第一方面的第一種至第四種任一種可能的實現(xiàn)方式，在第五種 可能的實現(xiàn)方式中，獲得所述資源釋放指令的方式為：
[0025] 改造資源預(yù)約響應(yīng)、確認(rèn)幀、零數(shù)據(jù)報文中的任一種，獲得所述資源釋放指令；或 者，
[0026] 使用無競爭結(jié)束幀作為所述資源釋放指令；或者，
[0027] 構(gòu)建新的控制幀作為所述資源釋放指令。
[0028] 結(jié)合第一方面的第五種可能的實現(xiàn)方式，在第六種可能的實現(xiàn)方式中，如果通過 改造所述資源預(yù)約響應(yīng)或者所述確認(rèn)幀獲得所述資源釋放指令，則資源釋放指示位為幀控 制域內(nèi)的任一保留位；或者，
[0029] 如果通過改造所述資源預(yù)約響應(yīng)或者所述確認(rèn)幀獲得所述資源釋放指令，則資源 釋放指示位為持續(xù)時間域內(nèi)的任一保留組合；或者，
[0030] 如果通過改造所述零數(shù)據(jù)報文獲得所述資源釋放指令，則資源釋放指示位為調(diào)制 編碼方式域內(nèi)的任一保留組合；
[0031] 其中，所述資源釋放指示位，用于指示所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量。
[0032] 結(jié)合第一方面的第六種可能的實現(xiàn)方式，在第七種可能的實現(xiàn)方式中，如果所述 資源釋放指示位為所述幀控制域內(nèi)的任一保留位，則將所述資源預(yù)約響應(yīng)的持續(xù)時間域設(shè) 置為網(wǎng)絡(luò)分配矢量的默認(rèn)值。
[0033] 第二方面，本發(fā)明實施例提供了一種資源預(yù)約裝置，所述裝置應(yīng)用于WiFi系統(tǒng)， 所述裝置包括：
[0034] 接收單元，用于接收源節(jié)點發(fā)送的資源預(yù)約請求；
[0035] 發(fā)送單元，用于在接收到所述資源預(yù)約請求之后，向所述源節(jié)點發(fā)送資源預(yù)約響 應(yīng)，所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽所 述資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量；
[0036] 第一判斷單元，用于判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)；
[0037] 資源釋放單元，用于在所述第一判斷單元判斷未接收到所述源節(jié)點發(fā)送的數(shù)據(jù) 時，向所述其它節(jié)點發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量，重 新競爭資源。
[0038] 在第二方面的第一種可能的實現(xiàn)方式中，所述裝置還包括：
[0039] 計算單元，用于計算獲得所述預(yù)約時間的剩余時間，所述剩余時間為所述預(yù)約時 間與所述預(yù)定時間之差；
[0040] 第二判斷單元，用于比較所述剩余時間與所述資源釋放單元發(fā)送所述資源釋放指 令所需的時間，若所述剩余時間不小于發(fā)送所述資源釋放指令所需的時間，則通知所述資 源釋放單元向所述其它節(jié)點發(fā)送所述資源釋放指令。
[0041] 結(jié)合第二方面以及第二方面的第一種可能的實現(xiàn)方式，在第二種可能的實現(xiàn)方式 中，所述發(fā)送單元，具體用于在接收到所述資源預(yù)約請求之后，相隔一個第一幀間間隔向所 述源節(jié)點發(fā)送第一資源預(yù)約響應(yīng)；則
[0042] 所述資源釋放單元，具體用于向所述其它節(jié)點發(fā)送第一資源釋放指令，以使所述 其它節(jié)點根據(jù)所述第一資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
[0043] 結(jié)合第二方面以及第二方面的第一種可能的實現(xiàn)方式，在第三種可能的實現(xiàn)方式 中，所述發(fā)送單元，具體用于在接收到所述資源預(yù)約請求之后，相隔一個第一幀間間隔、第 一資源預(yù)約響應(yīng)以及第二幀間間隔向所述源節(jié)點發(fā)送第二資源預(yù)約響應(yīng)；則 [0044] 所述資源釋放單元，具體用于向所述其它節(jié)點發(fā)送第一資源釋放指令，并相隔一 個所述第一幀間間隔向所述其它節(jié)點發(fā)送第二資源釋放指令，以使所述其它節(jié)點根據(jù)所述 第一資源釋放指令或者第二資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
[0045] 結(jié)合第二方面以及第二方面的第一種至第三種任一種可能的實現(xiàn)方式，在第四種 可能的實現(xiàn)方式中，所述第一判斷單元判斷是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)的預(yù)定時間 T為：
[0046] T = aSIFSTime+aPHY-RX-START-Delay+aSlotTime,
[0047] 其中，aSIFSTime為第一幀間間隔，aPHY-RX-START-Delay為物理層反應(yīng)時間， aSlotTime為時隙長度。
[0048] 本發(fā)明實施的資源預(yù)約方法及裝置，目的節(jié)點接收到源節(jié)點的資源預(yù)約請求后， 先向源節(jié)點返回一包含預(yù)約時間的資源預(yù)約響應(yīng)，從而控制系統(tǒng)中能偵聽到資源預(yù)約響應(yīng) 的其它節(jié)點按照預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量，避免與源節(jié)點的數(shù)據(jù)發(fā)送過程在目的 節(jié)點上發(fā)生碰撞；然后再判斷源節(jié)點是否在預(yù)定時間內(nèi)向其發(fā)送了數(shù)據(jù)，如果未發(fā)送則通 過資源釋放指令提前結(jié)束對其它節(jié)點的傳輸抑制過程。這樣，在解決隱藏節(jié)點問題的同時， 還能保證網(wǎng)絡(luò)資源的充分合理利用。
【專利附圖】
【附圖說明】
[0049] 為了更清楚地說明本申請實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn) 有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本 申請中記載的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，還可以根據(jù)這些附圖獲得其它 的附圖。
[0050] 圖1是隱藏節(jié)點的構(gòu)成示意圖；
[0051] 圖2是本發(fā)明資源預(yù)約方法實施例1的流程圖；
[0052] 圖3是現(xiàn)有技術(shù)中RTS/CTS機(jī)制的示意圖；
[0053] 圖4是利用本發(fā)明方案的RTS/CTS機(jī)制的示意圖；
[0054] 圖5a是802. 11η標(biāo)準(zhǔn)之前preamble中SIG域的格式示意圖；
[0055] 圖5b是802. 1 In標(biāo)準(zhǔn)preamble中SIG域的格式不意圖；
[0056] 圖6是CTS/ACK的幀構(gòu)成示意圖；
[0057] 圖7是Frame Control域的構(gòu)成不意圖；
[0058] 圖8是Duration域的使用示意圖；
[0059] 圖9是CF-End的幀構(gòu)成示意圖；
[0060] 圖10是本發(fā)明資源預(yù)約方法實施例2的流程圖；
[0061] 圖11是本發(fā)明在雙CTS機(jī)制中的一種應(yīng)用方式的示意圖；
[0062] 圖12是本發(fā)明在雙CTS機(jī)制中的另一種應(yīng)用方式的示意圖；
[0063] 圖13是本發(fā)明資源預(yù)約裝置實施例1的示意圖；
[0064] 圖14是本發(fā)明資源預(yù)約裝置實施例2的示意圖；
[0065] 圖15是本發(fā)明資源預(yù)約裝置的硬件構(gòu)成示意圖。
【具體實施方式】
[0066] 為了使本【技術(shù)領(lǐng)域】的人員更好地理解本發(fā)明方案，下面結(jié)合附圖和實施方式對本 發(fā)明實施例作進(jìn)一步的詳細(xì)說明。
[0067] 現(xiàn)有的WiFi系統(tǒng)中，隱藏節(jié)點問題嚴(yán)重影響著無線網(wǎng)絡(luò)的性能，所謂隱藏節(jié)點指 的是，節(jié)點A能被節(jié)點B看到，但是卻不能被與節(jié)點B通信的節(jié)點C看到，這樣節(jié)點A對于 節(jié)點C來說就是一個隱藏節(jié)點。
[0068] 下面結(jié)合圖1所示示意圖對隱藏節(jié)點影響網(wǎng)絡(luò)性能的過程進(jìn)行解釋說明。其中， 節(jié)點3是節(jié)點1的隱藏節(jié)點，也就是說節(jié)點3無法偵聽節(jié)點1發(fā)送的信號，如果當(dāng)前時刻節(jié) 點1正在向節(jié)點2發(fā)送數(shù)據(jù)，因節(jié)點3不知曉節(jié)點1與2之間是否在通信，故此時節(jié)點3也 可能會向節(jié)點2發(fā)送數(shù)據(jù)，導(dǎo)致節(jié)點3與1在節(jié)點2上發(fā)生碰撞，使節(jié)點2接收錯誤，致使 此次傳輸機(jī)會（Transmission Opportunity, ΤΧ0Ρ)被浪費。此外，如果WiFi系統(tǒng)中各個 節(jié)點布設(shè)的位置較近，則即使節(jié)點3在同一時刻不向節(jié)點2發(fā)送數(shù)據(jù)，而是向節(jié)點4發(fā)送數(shù) 據(jù)，也可能因節(jié)點3向節(jié)點4發(fā)送數(shù)據(jù)干擾到節(jié)點2接收節(jié)點1發(fā)送的數(shù)據(jù)，導(dǎo)致節(jié)點2接 收錯誤，降低無線網(wǎng)絡(luò)傳輸性能。
[0069] 為了解決這一問題而提出的 RTS/CTS(Request To Send/Clear To Send,請求發(fā) 送/允許發(fā)送）機(jī)制，可理解為：源節(jié)點（上述示例中的節(jié)點1即可視為源節(jié)點）在與目的 節(jié)點（上述示例中的節(jié)點2即可視為目的節(jié)點）建立通信之前，先向目的節(jié)點發(fā)送RTS幀 申請資源，并通過RTS幀使能偵聽到該幀的節(jié)點據(jù)其設(shè)置自身的NAV，從而抑制這些節(jié)點的 數(shù)據(jù)傳輸，避免與源節(jié)點發(fā)生碰撞。相應(yīng)地，目的節(jié)點在接收到RTS幀之后，向源節(jié)點發(fā)送 CTS幀，并使能偵聽到CTS幀的節(jié)點（如上述示例中的節(jié)點3)據(jù)其設(shè)置自身的NAV，并以此 來抑制這部分節(jié)點的數(shù)據(jù)傳輸，避免與目的節(jié)點發(fā)生碰撞。這樣，就不會出現(xiàn)源節(jié)點的隱藏 節(jié)點與源節(jié)點的傳輸發(fā)生碰撞的情況。
[0070] RTS/CTS機(jī)制在解決隱藏節(jié)點問題的同時，還帶來了一個新的問題，就是在源節(jié)點 與目的節(jié)點間CTS幀傳輸失敗或者源節(jié)點解析CTS幀失敗后的資源浪費問題，本發(fā)明技術(shù) 方案即是為了解決這一新問題而提出。
[0071] 下面對本發(fā)明的資源預(yù)約方法進(jìn)行解釋說明。
[0072] 參見圖2,示出了本發(fā)明資源預(yù)約方法實施例1的流程圖，所述方法應(yīng)用于WiFi系 統(tǒng)，所述方法包括：
[0073] 步驟101，目的節(jié)點接收源節(jié)點發(fā)送的資源預(yù)約請求，并向所述源節(jié)點發(fā)送資源預(yù) 約響應(yīng)，所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵 聽所述資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量。
[0074] 為了避免節(jié)點間的碰撞，源節(jié)點在與目的節(jié)點建立通信之前，先向目的節(jié)點發(fā)送 資源預(yù)約請求，作為該請求的一種實現(xiàn)方式其可體現(xiàn)為RTS幀，對于接收到RTS幀的節(jié)點來 說，可按處理動作被大致分為兩類：
[0075] -類是目的節(jié)點，該節(jié)點是源節(jié)點想要建立通信的節(jié)點，因此在其接收到RTS幀 并間隔一個SIFS之后要向源節(jié)點發(fā)送一個資源預(yù)約響應(yīng)，作為該響應(yīng)的一種實現(xiàn)方式其 可體現(xiàn)為CTS幀。
[0076] -類是除去目的節(jié)點之外的其它節(jié)點，這類節(jié)點能偵聽到源節(jié)點發(fā)送的數(shù)據(jù)，還 可能會是目的節(jié)點的隱藏節(jié)點，因此，源節(jié)點要通過RTS幀控制這類節(jié)點設(shè)置好各自的 NAV，以便這類節(jié)點可以根據(jù)NAV的大小判斷資源的使用情況。參見圖3所示示意圖可知， 這類節(jié)點設(shè)置的 NAV(RTS)為（CTS_Time+Data_Time+ACK_Time+3XSIFS)，其中，CTS_Time 為目的節(jié)點發(fā)送CTS幀的時間，Data_Time為源節(jié)點傳輸數(shù)據(jù)幀的時間，ACK_Time為數(shù)據(jù)傳 輸完畢后目的節(jié)點發(fā)送確認(rèn)幀的時間，SIFS為短幀間間隔。
[0077] 需要說明的是，目的節(jié)點亦會根據(jù)RTS幀設(shè)置其自身的NAV，但卻無需利用其設(shè)置 的NAV判斷資源使用情況，此處暫不介紹本發(fā)明中目的節(jié)點設(shè)置NAV的用處。
[0078] 當(dāng)然，對于接收到CTS幀的節(jié)點來說，按處理動作也可被分為兩類：
[0079] -類是源節(jié)點，該節(jié)點想要向目的節(jié)點發(fā)送數(shù)據(jù)，因此在其接收到CTS幀并間隔 一個SIFS之后應(yīng)向目的節(jié)點傳送數(shù)據(jù)幀。
[0080] 一類是除去源節(jié)點之外的其它節(jié)點，這類節(jié)點能偵聽到目的節(jié)點發(fā)送的數(shù)據(jù)，還 可能是源節(jié)點的隱藏節(jié)點，會影響目的節(jié)點的數(shù)據(jù)接收，因此，目的節(jié)點要通過CTS幀控制 這類節(jié)點設(shè)置好各自的NAV，以便這類節(jié)點可以根據(jù)NAV的大小判斷資源的使用情況。參見 圖 3 可知，這類節(jié)點設(shè)置的 NAV(CTS)為（Data_Time+ACK_Time+2XSIFS)。
[0081] 需要說明的是，源節(jié)點亦可根據(jù)CTS幀設(shè)置其自身的NAV，但因為其要利用占用的 資源向目的節(jié)點發(fā)送數(shù)據(jù)，故無需通過NAV判斷資源使用情況，本發(fā)明對源節(jié)點設(shè)置NAV不 做過多介紹。
[0082] 本步驟指的即是能偵聽到CTS幀的節(jié)點根據(jù)CTS幀設(shè)置自身NAV的過程，其中預(yù) 約時間即上述的（Data_Time+ACK_Time+2XSIFS)。
[0083] 需要說明的是，本發(fā)明中的資源可具體體現(xiàn)為無線信道資源，節(jié)點可體現(xiàn)為無線 訪問接入點AP(Access Point)、或者諸如手機(jī)等站點設(shè)備STA(Station)，可由實際應(yīng)用情 況決定，對此不做進(jìn)一步的限定。
[0084] 步驟102,所述目的節(jié)點判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)，如 果未接收到，則向所述其它節(jié)點發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò) 分配矢量，重新競爭資源。
[0085] 如上所述，在正常情況下，源節(jié)點接收到目的節(jié)點的CTS幀之后，間隔一個SIFS就 會向目的節(jié)點發(fā)送數(shù)據(jù)幀，但是，如若信道不穩(wěn)定出現(xiàn)源節(jié)點未向目的節(jié)點發(fā)送數(shù)據(jù)幀的 情況，則為了避免這種情況下的資源浪費，本發(fā)明的目的節(jié)點會等待一個合理延遲后主動 判斷其是否接收到源節(jié)點發(fā)送的數(shù)據(jù)，如果接收到，則仍可按正常流程進(jìn)行數(shù)據(jù)的發(fā)送與 接收；如果未接收到，則釋放源節(jié)點占用的資源，并通知根據(jù)該CTS幀設(shè)置其NAV的節(jié)點初 始化其NAV后重新競爭信道資源，這樣就可有效避免源節(jié)點占用信道但不發(fā)送數(shù)據(jù)情況下 對信道資源的浪費。
[0086] 需要說明的是，上述合理延遲也即預(yù)定時間T，大于源節(jié)點正常情況下向目的節(jié)點 發(fā)數(shù)據(jù)幀經(jīng)過的間隔SIFS。也就是說，在本發(fā)明技術(shù)方案中，如若在時間區(qū)間t內(nèi)接收到源 節(jié)點發(fā)送的數(shù)據(jù)均認(rèn)為是正常情況，如若超出了 T仍未接收到源節(jié)點發(fā)送的數(shù)據(jù)則認(rèn)為是 異常情況，要終止對其它節(jié)點的傳輸抑制，使其它節(jié)點與源節(jié)點重新開始競爭信道資源，具 體可參見圖4所示示意圖。其中，虛線框的data幀和ACK幀表示未發(fā)送的幀，NAV(CTS)中 黑色部分表示節(jié)點被抑制傳輸?shù)臅r間，白色部分表示節(jié)點提前結(jié)束傳輸抑制過程的時間。
[0087] 下面對本發(fā)明中預(yù)定時間T的選取進(jìn)行解釋說明。
[0088] 按照802. 11標(biāo)準(zhǔn)規(guī)定，如果在（理論接收時間+Timeout Interval)之后仍未檢 測到后續(xù)幀，則認(rèn)為超時。對應(yīng)到本發(fā)明技術(shù)方案中，理論接收時間為aSIFSTime ;Timeout Interval = aPHY-RX-START-Delay+aSlotTime，即為圖 4 中的 t，則所述預(yù)定時間 T = aSIF STime+aPHY-RX-START-De 1 ay+aS 1 otTime。其中，
[0089] aSIFSTime為短幀間間隔時間，是一個物理層參數(shù)，上述提及的SIFS是一個 MAC(Media Access Control,媒體介入控制）層參數(shù)，aSIFSTime是SIFS的物理層表示，兩 者數(shù)值完全相等。
[0090] aPHY-RX-START-Delay表示的是從設(shè)備物理層檢測到幀傳輸開始到向上層發(fā)送接 收指示所需時間，即物理層的反應(yīng)時間，為物理層參數(shù)。
[0091] aSlotTime為時隙長度，也是一個物理層參數(shù)，該參數(shù)主要是考慮到時鐘對準(zhǔn)等因 素對計時準(zhǔn)確性的影響而設(shè)置，也就是說，對于數(shù)據(jù)幀來說還允許存在一個aSlotTime的 可能延遲。
[0092] 上述兩個參數(shù)均可由標(biāo)準(zhǔn)定義并給出具體數(shù)值，例如，在802. lln標(biāo)準(zhǔn)中，使用 2. 4GHz 頻帶時 aSlotTime = 9 μ s 或 20us，使用 5GHz 頻段時 aSlotTime = 9 μ s，對應(yīng)在這 兩種情況下的 aPHY-RX-START-Delay = 33 μ s ;而在 802. 11η 標(biāo)準(zhǔn)之前的 OFDM (Orthogonal Frequency Division Multiplexing,正交頻分復(fù)用技術(shù)）物理層中，這些參數(shù)的取值 與帶寬有關(guān)，例如20/10/511取對應(yīng)的331〇丨111116取值分別是9/13/21口8，對應(yīng)于此， aPHY-RX-START-Delay 的取值分別是 25/49/97 μ s。
[0093] 由上述內(nèi)容可知，在確定目的節(jié)點接收數(shù)據(jù)幀的最大允許延遲時間（也即 預(yù)定時間）時要考慮三個因素：一是理論接收時間aSIFSTime，一是物理層反應(yīng)時間 aPHY-RX-START-Delay，一是時隙 aSlotTime。
[0094] 本發(fā)明為了解決在信道不穩(wěn)定情況下的資源浪費問題，由目的節(jié)點在預(yù)定時間內(nèi) 偵聽源節(jié)點發(fā)送的數(shù)據(jù)，如果偵聽到，則保留源節(jié)點對信道資源的占用，接收源節(jié)點發(fā)送的 數(shù)據(jù)；如果未偵聽到，則釋放分配給源節(jié)點的信道資源，同時還解除對其它能偵聽目的節(jié)點 數(shù)據(jù)的節(jié)點的傳輸抑制，保證信道盡可能的被合理利用。這樣，既能解決隱藏節(jié)點問題，又 能提高網(wǎng)絡(luò)資源的利用率。
[0095] 在實際應(yīng)用中，能夠偵聽到目的節(jié)點數(shù)據(jù)的其它節(jié)點可分為兩類：一類是既能偵 聽目的節(jié)點數(shù)據(jù)又能偵聽源節(jié)點數(shù)據(jù)的節(jié)點，另一類是只能偵聽到目的節(jié)點而不能偵聽到 源節(jié)點數(shù)據(jù)的節(jié)點。后者是源節(jié)點的隱藏節(jié)點。對于前者來說，其除了可以根據(jù)資源釋放 指令重新競爭信道，還可通過偵聽源節(jié)點的數(shù)據(jù)發(fā)送情況來決定是否解除自身的傳輸抑制 過程；但是，對于后一類節(jié)點來說，其無法獲知源節(jié)點的數(shù)據(jù)發(fā)送情況，只能在資源釋放指 令的作用下提前解除傳輸抑制過程。因此，為了保證在源節(jié)點不發(fā)送數(shù)據(jù)情況下，不同節(jié)點 對信道資源的合理公平競爭，本發(fā)明通過目的節(jié)點代替其它節(jié)點偵聽源節(jié)點的數(shù)據(jù)發(fā)送情 況，并在需要釋放信道資源時通知其它節(jié)點初始化NAV，重新競爭資源。
[0096] 另外，需要說明的是，所謂初始化NAV指的是將NAV的數(shù)值賦為默認(rèn)值，該默認(rèn)值 可以是現(xiàn)有技術(shù)中的零，也就是說初始化NAV即控制NAV歸零；也可以按照需要將默認(rèn)值設(shè) 置為任意數(shù)值，例如設(shè)置為1，則在根據(jù)Duration域表示的時間設(shè)置NAV時，要在默認(rèn)值1 的基礎(chǔ)上設(shè)置，進(jìn)一步在初始化NAV時也即是將其數(shù)值歸為默認(rèn)值1。本發(fā)明對NAV的初始 默認(rèn)值的設(shè)置不做限定。
[0097] 對于控制與目的節(jié)點通信的其它節(jié)點初始化NAV的資源釋放指令來說，其可以構(gòu) 建新的控制幀來實現(xiàn)，也可以使用無競爭結(jié)束幀CF-End實現(xiàn)，還可以改造已有的幀來實 現(xiàn)，例如改造資源預(yù)約響應(yīng)CTS、確認(rèn)巾貞ACK (Acknowledgment)、零數(shù)據(jù)報文NDP (Null Data Packet)等等，下面--進(jìn)行解釋說明。
[0098] 1.改造 NDP幀獲得資源釋放指令
[0099] 資源釋放指令用于釋放源節(jié)點對信道的占用，解除對其它節(jié)點的傳輸抑制，且考 慮到節(jié)省信道資源以及節(jié)電，幀長度應(yīng)越短越好，因此可以考慮使用NDP幀。
[0100] -般情況下，實際發(fā)送的巾貞由物理頭preamble和MAC巾貞構(gòu)成。Preamble包括長/ 短訓(xùn)練、信號域SIG等，進(jìn)一步地SIG域又包含發(fā)送速率、MAC幀長度等信息。因 SIG域中 可包含一些簡單信息，故可以只發(fā)送Preamble而不發(fā)送后面的MAC巾貞，這種只有preamble 而無 MAC幀的幀就稱為NDP幀。
[0101] 參見圖5a，示出了 802. lln標(biāo)準(zhǔn)之前物理頭中SIG域的格式示意圖，因為0FDM物 理層只支持8種發(fā)送速率，因此4位速率域RATE構(gòu)成的16種組合中還存在8種保留組合， 這樣，就可使用這些保留組合中的任一種來表示資源釋放指示，從而將NDP幀改造為資源 釋放指令來使用。當(dāng)然，LENGTH域還可攜帶其它信息，如源節(jié)點的部分MAC地址或者目的 節(jié)點當(dāng)前的NAV值。其中，部分MAC地址由完整MAC地址截取部分（如最后12位）或者對 完整MAC作變換（如哈希運算）所得。這樣，能偵聽目的節(jié)點數(shù)據(jù)的其它節(jié)點接收到經(jīng)由 NDP幀改造獲得的資源釋放指令，即可判斷其RATE域是哪種組合，如果是保留組合中的一 種，就可以根據(jù)資源釋放指示將各自的NAV初始化為默認(rèn)值。具體釋放過程可體現(xiàn)如下：
[0102] 若LENGTH域為源節(jié)點的部分MAC地址，則當(dāng)其它節(jié)點接收到資源釋放指令后，先 判斷自己是否需要根據(jù)該指令初始化NAV，因為在節(jié)點偵聽到CTS幀并據(jù)其設(shè)置NAV時，節(jié) 點會記錄下CTS幀的RA域，也即要知曉本次是在哪個源節(jié)點的作用下被抑制傳輸?shù)?，故?節(jié)點接收到資源釋放指令后，可比對其記錄的RA域是否與LENGTH域中的部分MAC地址相 匹配，如果匹配，則根據(jù)資源釋放指令將其NAV初始化為默認(rèn)值；若不匹配，則丟棄該資源 釋放指令。
[0103] 若LENGTH域為目的節(jié)點當(dāng)前的NAV值，則當(dāng)其它節(jié)點接收到資源釋放指令后，先 判斷自己的NAV值與LENGTH域的差的絕對值是否小于或等于預(yù)定義的門限值，若是，則根 據(jù)資源釋放指令將其NAV初始化為默認(rèn)值；若不是，則丟棄該資源釋放指令。上述的門限值 為系統(tǒng)參數(shù)，可由AP在信標(biāo)幀Beacon中廣播。本方案即為上述使目的節(jié)點根據(jù)RTS幀設(shè) 置其NAV的用處。
[0104] 參見圖5b，示出了 802. lln標(biāo)準(zhǔn)物理頭中SIG域的格式示意圖，與圖5a相比，由 調(diào)制編碼方式（Modulation and Coding Scheme, MCS)字段替代了 RATE字段，用于表示發(fā) 送速率。7位MCS字段可表達(dá)128種調(diào)制編碼方案，而802. lln標(biāo)準(zhǔn)中支持77種調(diào)制編碼 方案，故還存在51種保留組合。這樣，就可使用這些保留組合中的任一種來表示資源釋放 指示，從而將NDP幀改造為資源釋放指令來使用。需要說明的是，SIG域中除循環(huán)冗余校驗 CRC、尾位Tail Bit、非探測信號Not Sounding之外的其它字段均可用來承載如源節(jié)點的 部分MAC地址或者目的節(jié)點當(dāng)前的NAV值等信息，其它節(jié)點根據(jù)資源釋放指令初始化各自 NAV的過程與上述0FDM物理層相似，此處不再贅述。此外，為了與當(dāng)前標(biāo)準(zhǔn)兼容，應(yīng)將Not Sounding字段設(shè)置為1。
[0105] 2.改造 CTS/ACK幀獲得資源釋放指令
[0106] CTS和ACK均為控制巾貞，具有相似的幀結(jié)構(gòu)，參見圖6,示出了 CTS/ACK的幀構(gòu)成示 意圖，其中，F(xiàn)rame Control為巾貞控制域，Duration為持續(xù)時間域（用于表示后續(xù)數(shù)據(jù)發(fā)送 及確認(rèn)所需時間），RA為源節(jié)點MAC地址，F(xiàn)CS為幀校驗序列。本發(fā)明可以通過改造 Frame Control域或者Duration域獲得資源釋放指令，下面分別進(jìn)行解釋說明。
[0107] (1)改造 Frame Control域獲得資源釋放指令
[0108] 參見圖7,示出了 Frame Control域的構(gòu)成示意圖。因為CTS/ACK均是控制幀，而 控制幀中存在一些保留位，例如：用于表示數(shù)據(jù)到外部網(wǎng)絡(luò)去的位To DS，用于表示數(shù)據(jù)來 自外部網(wǎng)絡(luò)的位From DS，用于表示巾貞分片傳輸?shù)奈籑ore Fragments,用于表示數(shù)據(jù)重傳的 位Retry,用于表示是否使用加密算法的位Protected Frame,用于表示HT control域存在 或要嚴(yán)格順序發(fā)送的位Order，上述保留位在控制幀中不會被使用到，因此可以從中任選一 個作為資源釋放指示位，將CTS/ACK改造為資源釋放指令來使用。
[0109] 需要說明的是，依據(jù)含義就近原則，考慮到每個保留位的含義，可優(yōu)選使用Retry 位作為資源釋放指示位，當(dāng)然，Retry位與上述其它保留位相比，實質(zhì)上并無不同。
[0110] 這樣，能偵聽目的節(jié)點數(shù)據(jù)的其它節(jié)點接收到經(jīng)由Frame Control域改造獲得的 資源釋放指令，即可判斷用于作為資源釋放指示位的保留位的取值，進(jìn)而決定是否初始化 NAV。
[0111] (2)改造 Duration域獲得資源釋放指令
[0112] Duration域包含0?15共計16位，若Duration域被使用在PS-Poll巾貞中則用 于表不 AID (Association Identifier，連接標(biāo)識符）；若 Duration 域被使用在 PCF (Point Coordination Function，點協(xié)調(diào)功能）中的 CFP(Contention Free Period，無競爭周期階 段）傳輸?shù)膸袆t被設(shè)置為固定值32768 ;若Duration域被使用在其它幀中則表示后續(xù) 數(shù)據(jù)發(fā)送及確認(rèn)所需時間；除此之外，Duration域還存在一些未使用的保留組合，具體可 參見圖8所示示意圖，因此，可使用這些保留組合中的任一種來表示資源釋放指示，從而將 CTS/ACK改造為資源釋放指令來使用。
[0113] 這樣，能偵聽目的節(jié)點數(shù)據(jù)的其它節(jié)點接收到經(jīng)由Duration域改造獲得的資源 釋放指令，即可判斷Duration域使用的是哪種組合，如果是保留組合中的一種，就可以根 據(jù)資源釋放指示將各自的NAV初始化為默認(rèn)值。例如，將最高兩位為1、其它位為0的保留 組合作為資源釋放指示使用，如果與目的節(jié)點通信的其它節(jié)點發(fā)現(xiàn)Duration域為該保留 組合，則初始化NAV，以重新進(jìn)行資源競爭。
[0114] 對于上述通過改造 CTS/ACK巾貞的Frame Control域獲得資源釋放指令的方式來 說，本發(fā)明還提供了以下優(yōu)選方案，具體描述如下：
[0115] 考慮到設(shè)備兼容性的問題，在改造 Frame Control域的同時，還可將CTS/ACK中貞 Duration域用于表示后續(xù)數(shù)據(jù)發(fā)送及確認(rèn)所需的時間設(shè)置為NAV的默認(rèn)值，若采用現(xiàn)有技 術(shù)中NAV的默認(rèn)取值為0的方案，也即將Duration域表示的時間設(shè)置為0,以此實現(xiàn)本發(fā)明 的新節(jié)點設(shè)備與現(xiàn)有技術(shù)中的舊節(jié)點設(shè)備（此處的新節(jié)點設(shè)備和舊節(jié)點設(shè)備指的是可偵 聽目的節(jié)點數(shù)據(jù)的其它節(jié)點）間的兼容：
[0116] 因為資源釋放指令是由CTS/ACK巾貞改造（具體是改造 Frame Control域）而成， 故該指令中包含有Duration域，因此對于舊節(jié)點設(shè)備來說，在其接收到資源釋放指令后， 還是會自動讀取Duration域，并據(jù)其設(shè)置自身的NAV，而若指令中Duration域表示的時間 大于節(jié)點目前設(shè)置的NAV數(shù)值，則節(jié)點會更改其NAV為Duration域表示的時間（一般情況 下，節(jié)點會選取較大的數(shù)值作為其當(dāng)前NAV值），如果Duration域表示的時間不大于節(jié)點當(dāng) 前的NAV值，則不會影響節(jié)點的NAV設(shè)置，因此，為了保證資源釋放指令既能指示節(jié)點結(jié)束 傳輸抑制過程，又不影響節(jié)點的NAV設(shè)置，就要將Duration域表示的時間設(shè)置為NAV的默 認(rèn)值（節(jié)點當(dāng)前的NAV數(shù)值絕對不會大于其默認(rèn)值）。
[0117] 而對于具有識別資源釋放指令功能的新節(jié)點設(shè)備來說，只要檢測到Frame Control域中的資源釋放指示，就不會再根據(jù)Duration域設(shè)置其NAV，且如果資源釋放指示 位的值表示要初始化NAV，則節(jié)點還要初始化其NAV為默認(rèn)值，結(jié)束傳輸抑制過程。
[0118] 對于上述改造 CTS/ACK幀獲得資源釋放指令的方式來說，節(jié)點的具體釋放過程可 體現(xiàn)如下：
[0119] 當(dāng)節(jié)點接收到資源釋放指令后，先判斷是否需要初始化NAV，即判斷Frame Control域中的資源釋放指示位是否為預(yù)設(shè)值（如規(guī)定預(yù)設(shè)值為" 1"表示要釋放資源，則判 斷指示位是否為" 1"），或者判斷Duration域使用的是否為保留組合中的一種。如果經(jīng)判 斷為需要初始化NAV，則節(jié)點再判斷該指示是否針對自己，對此可通過比對節(jié)點記錄的CTS 幀的RA域與資源釋放指令的RA域?qū)崿F(xiàn)，如果相同，則根據(jù)資源釋放指令將其NAV初始化為 默認(rèn)值；若不同，則丟棄該資源釋放指令。
[0120] 除了上述通過改造現(xiàn)有幀獲得資源釋放指令之外，還可直接將CF-End幀作為資 源釋放指令使用，具體解釋如下：
[0121] 現(xiàn)有技術(shù)中，如果源節(jié)點與目的節(jié)點完成數(shù)據(jù)交互之后，若發(fā)現(xiàn)預(yù)約時間還有剩 余，且該剩余足以發(fā)送一個CF-End巾貞,源節(jié)點即會向目的節(jié)點發(fā)送CF-End巾貞告知目的節(jié)點 其可以提前釋放資源，相應(yīng)地，作為目的節(jié)點的一個響應(yīng)動作，其也會向源節(jié)點回復(fù)CF-End 幀，這樣，能偵聽目的節(jié)點數(shù)據(jù)的其它節(jié)點就會在該響應(yīng)CF-End幀的作用下初始化各自的 NAV。
[0122] 綜上所述，本發(fā)明亦可應(yīng)用CF-End幀充當(dāng)資源釋放指令來提前解除對其它節(jié)點 的傳輸抑制，只不過現(xiàn)有技術(shù)中，觸發(fā)發(fā)送CF-End幀主體是源節(jié)點，觸發(fā)條件是數(shù)據(jù)交互 完成后尚有足夠多的剩余資源；本發(fā)明考技術(shù)方案中，觸發(fā)發(fā)送CF-End幀的主體是目的節(jié) 點，觸發(fā)條件是目的節(jié)點判定源節(jié)點未按約定傳輸數(shù)據(jù)。
[0123] 參見圖9所示的CF-End幀的結(jié)構(gòu)示意圖，在本方式下節(jié)點的釋放過程可體現(xiàn)如 下：
[0124] 將CF-End的Duration域設(shè)置為目的節(jié)點當(dāng)前的NAV值，當(dāng)其它節(jié)點接收到作為 資源釋放指令使用的CF-End幀后，先判斷自己是否需要根據(jù)該指令初始化NAV，即判斷節(jié) 點自己的NAV值與CF-End巾貞的Duration域的差的絕對值是否小于或等于預(yù)定義的門限 值，若是，則將其NAV初始化為默認(rèn)值；若不是，則丟棄該資源釋放指令。上述的門限值為系 統(tǒng)參數(shù)，可由AP在Beacon幀中廣播。
[0125] 另一種利用CF-End實現(xiàn)資源釋放指令的方法是：將RA域設(shè)置為源節(jié)點MAC地址， TA域設(shè)置為目的節(jié)點MAC地址，當(dāng)其它節(jié)點接收到作為資源釋放指令使用的CF-End幀后， 先判斷自己是否需要根據(jù)該指令初始化NAV，即通過比對節(jié)點記錄的CTS幀的RA域與資源 釋放指令的RA域?qū)崿F(xiàn)，如果相同，則將其NAV初始化為默認(rèn)值；若不同，則丟棄該資源釋放 指令。
[0126] 參見圖10,示出了本發(fā)明資源預(yù)約方法實施例2的流程圖，所述方法應(yīng)用于WiFi 系統(tǒng)，所述方法包括：
[0127] 步驟201，目的節(jié)點接收源節(jié)點發(fā)送的資源預(yù)約請求，并向所述源節(jié)點發(fā)送資源預(yù) 約響應(yīng)，所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵 聽所述資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量。
[0128] 步驟202,所述目的節(jié)點判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)。
[0129] 步驟203,如果在預(yù)定時間內(nèi)未接收到所述源節(jié)點發(fā)送的數(shù)據(jù)，則計算獲得所述預(yù) 約時間的剩余時間，并與發(fā)送所述資源釋放指令所需的時間相比較，其中，所述剩余時間為 所述預(yù)約時間與所述預(yù)定時間之差。
[0130] 步驟204,如果所述剩余時間不小于發(fā)送所述資源釋放指令所需的時間，則向所述 其它節(jié)點發(fā)送所述資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量，重新競 爭資源。
[0131] 作為本發(fā)明的一種優(yōu)選方案，在目的節(jié)點確定未在合理延遲時間內(nèi)接收到源節(jié)點 發(fā)送的數(shù)據(jù)時，并不直接向其它節(jié)點發(fā)資源釋放指令，因為發(fā)送指令也是需要一定的時間 的，因此先判斷下當(dāng)前剩余的時間與發(fā)送指令花費的時間哪個更長。所謂剩余時間指的是 當(dāng)前時刻到預(yù)約時間結(jié)束的時長，也即從當(dāng)前時刻開始，其它節(jié)點還需要等待多長時間才 可重新競爭信道，或者也可以理解為從當(dāng)前時刻開始至NAV倒數(shù)計數(shù)到默認(rèn)值還需要多長 時間，具體計算方式為剩余時間=預(yù)約時間-預(yù)定時間。
[0132] 如果發(fā)送指令花費的時間小于剩余時間，顯然通過資源釋放指令可以提前結(jié)束其 它節(jié)點的傳輸抑制過程，從而使網(wǎng)絡(luò)中的節(jié)點重新開始競爭信道資源，盡量降低資源浪費。
[0133] 如果發(fā)送指令花費的時間大于剩余時間，則通過資源釋放指令初始化NAV的方式 反而會延長資源浪費的時間，因此，在這種情況下目的節(jié)點可以不向其它節(jié)點發(fā)送資源釋 放指令，而是等待其它節(jié)點通過NAV倒數(shù)為默認(rèn)值的方式結(jié)束傳輸抑制過程，以此降低資 源浪費。
[0134] 如果發(fā)送指令花費的時間等于剩余時間，則這兩種方式會在同一時刻結(jié)束其它節(jié) 點的傳輸抑制過程，因此，可以選用這兩種方式中的任一種來終止源節(jié)點對信道的占用，本 發(fā)明對此可不做限定。
[0135] 下面結(jié)合具體應(yīng)用對本發(fā)明技術(shù)方案的實現(xiàn)過程進(jìn)行簡單介紹。
[0136] 目前，在解決隱藏節(jié)點問題時存在兩種機(jī)制，一種是單CTS機(jī)制，適用于只包含舊 節(jié)點設(shè)備或者只包含新節(jié)點設(shè)備的網(wǎng)絡(luò)，一種是雙CTS機(jī)制，適用于既包含新節(jié)點設(shè)備又 包含舊節(jié)點設(shè)備的網(wǎng)絡(luò)。所謂新節(jié)點設(shè)備指的是支持STBC(Space-Time Block Coding，空 時分組編碼）模式和non-STBC模式的節(jié)點，舊節(jié)點設(shè)備指的是只支持non-STBC模式的節(jié) 點。
[0137] 對于單CTS機(jī)制來說，本發(fā)明技術(shù)方案的實現(xiàn)過程可描述如下：
[0138] (1)源節(jié)點向目的節(jié)點發(fā)送RTS幀，請求進(jìn)行信道資源預(yù)留，能偵聽到RTS幀的節(jié) 點將其NAV設(shè)置為（CTS_Time+Data_Time+ACK_Time+3 X SIFS)，并開始進(jìn)行倒數(shù)計數(shù)。
[0139] (2)目的節(jié)點接收到RTS幀后，相隔一個SIFS向源節(jié)點發(fā)送CTS幀（可視為是第 一資源預(yù)約響應(yīng)，SIFS可視為是第一幀間間隔），能偵聽到CTS幀的節(jié)點將其NAV設(shè)置為 (Data_Time+ACK_Time+2 X SIFS)，并開始進(jìn)行倒數(shù)計數(shù)。
[0140] (3)目的節(jié)點從發(fā)送CTS幀對應(yīng)的PHY-TXEND. conf irm開始計時，如若在預(yù)定 時間（aSIFSTime+aPHY-RX-START-Delay+aSlotTime)內(nèi)未檢測到來自物理層（PHY)的 PHY-RXSTART. indication，則認(rèn)為其向源節(jié)點傳送的CTS幀傳輸失敗，可釋放源節(jié)點請求 占用的信道資源。
[0141] (4)對于釋放源節(jié)點占用的信道資源的方式有兩種，一種是等待其它節(jié)點的NAV 倒數(shù)計數(shù)為零，再一種即是發(fā)送資源釋放指令。為了使資源釋放過程更為合理化，本發(fā)明在 確定CTS幀傳輸失敗的情況下，還可執(zhí)行以下步驟 ：
[0142] 目的節(jié)點計算獲得預(yù)約時間的剩余時間，并判斷剩余時間是否小于傳輸資源釋放 指令所需的時間，如果小于，則按第一種方式等待其它節(jié)點的NAV值倒數(shù)計數(shù)為零，以此釋 放信道資源；如果不小于，則按第二種方式發(fā)送資源釋放指令（可視為是第一資源釋放指 令），由指令直接控制其它節(jié)點初始化NAV，釋放信道資源。
[0143] (5)對于發(fā)送第一資源釋放指令的方式來說，如果選用Frame Control域中的保 留位Retry作為資源釋放指示位，且在該指示位為" 1"時控制節(jié)點的初始化NAV，則在其它 節(jié)點接收到指令后，讀取Retry位，若為" 1"，則不論其NAV倒數(shù)計數(shù)為幾均將其初始化為默 認(rèn)值，重新與網(wǎng)絡(luò)中的節(jié)點競爭信道資源，至此就完成了本發(fā)明的資源預(yù)約過程。
[0144] 對于雙CTS機(jī)制來說，本發(fā)明技術(shù)方案的實現(xiàn)過程可描述如下：
[0145] (1)源節(jié)點向目的節(jié)點發(fā)送RTS巾貞，請求進(jìn)行信道資源預(yù)留，能偵聽到RTS幀的節(jié) 點將其NAV設(shè)置為（CTS_Time+Data_Time+ACK_Time+3 X SIFS)，并開始進(jìn)行倒數(shù)計數(shù)。
[0146] (2)目的節(jié)點接收到RTS幀后，分別以STBC模式和non-STBC模式向源節(jié)點發(fā)送 CTS幀，能偵聽到CTS幀的節(jié)點：如果能識別STBC模式的CTS幀，則據(jù)此設(shè)置其NAV，如果 能識別non-STBC模式的CTS幀，則據(jù)此設(shè)置其NAV，最終設(shè)置的NAV值為（Data_Time+ACK_ Time+2XSIFS)，同樣開始進(jìn)行倒數(shù)計數(shù)。
[0147] 本步驟中，目的節(jié)點發(fā)送CTS幀的具體過程為：目的節(jié)點接收到RTS幀，相隔一個 第一幀間間隔發(fā)送第一資源預(yù)約響應(yīng)，然后再相隔一個第二幀間間隔發(fā)送第二資源預(yù)約響 應(yīng)。
[0148] 參見圖11所示示意圖，如果源節(jié)點向目的節(jié)點發(fā)送一個STBC模式的RTS幀，則目 的節(jié)點間隔一個SIFS (可視為是第一幀間間隔）向源節(jié)點發(fā)送一個STBC模式的CTS (可視 為是第一資源預(yù)約響應(yīng)），然后再間隔一個SIFS(可視為是第二幀間間隔）向源節(jié)點發(fā)送一 個non-STBC模式的CTS (可視為是第二資源預(yù)約響應(yīng)）。
[0149] 或者，參見圖12所示示意圖，如果源節(jié)點向目的節(jié)點發(fā)送一個non-STBC模式的 RTS巾貞，則目的節(jié)點間隔一個SIFS (可視為是第一幀間間隔）向源節(jié)點發(fā)送一個non-STBC 模式的CTS (可視為是第一資源預(yù)約響應(yīng)），然后再間隔一個PIFS(PCF Interframe Space, 點協(xié)調(diào)功能幀間間隔，PIFS > SIFS，可視為是第二幀間間隔）向源節(jié)點發(fā)送一個STBC模式 的CTS (可視為是第二資源預(yù)約響應(yīng)）。
[0150] 對于圖12所示示意圖來說，因為新節(jié)點設(shè)備和舊節(jié)點設(shè)備均可以發(fā)送non-STBC 模式的RTS幀，因此，在目的節(jié)點接收到一個non-STBC模式的RTS幀時，并不能確定其來自 于哪種源節(jié)點。此外，若源節(jié)點為舊節(jié)點設(shè)備，則其在目的節(jié)點回復(fù)CTS幀之后間隔SIFS 就會向目的節(jié)點發(fā)送數(shù)據(jù)幀，若目的節(jié)點也在發(fā)出第一個CTS幀并間隔SIFS之后發(fā)出第二 個CTS幀，則會導(dǎo)致沖突，因此，在接收到non-STBC模式的RTS幀時，目的節(jié)點發(fā)出第一個 CTS幀之后間隔一個PIFS再發(fā)出第二個CTS幀，避免與舊節(jié)點設(shè)備的傳輸發(fā)生碰撞。
[0151] 對于圖11所示示意圖來說，因為只有新節(jié)點設(shè)備可以發(fā)送STBC模式的RTS幀，因 此，目的節(jié)點可以明確發(fā)送RTS幀的源節(jié)點的類型，故只需等待SIFS即可發(fā)送第二個CTS 幀。
[0152] (3)目的節(jié)點從發(fā)送第二個CTS幀對應(yīng)的PHY-TXEND. confirm開始計時，如若在 預(yù)定時間（aSIFSTime+aPHY-RX-START-Delay+aSlotTime)內(nèi)未檢測到來自物理層（PHY)的 PHY-RXSTART. indication，則認(rèn)為其向源節(jié)點傳送的CTS幀傳輸失敗，可釋放源節(jié)點請求 占用的信道資源。
[0153] (4)對于釋放源節(jié)點占用的信道資源的方式有兩種，一種是等待其它節(jié)點的NAV 倒數(shù)計數(shù)為零，再一種即是發(fā)送資源釋放指令。為了使資源釋放過程更為合理化，本發(fā)明在 確定CTS幀傳輸失敗的情況下，還可執(zhí)行以下步驟 ：
[0154] 目的節(jié)點計算獲得預(yù)約時間的剩余時間，并判斷剩余時間是否小于傳輸資源釋放 指令所需的時間，如果小于，則按第一種方式等待其它節(jié)點的NAV值倒數(shù)計數(shù)為零，以此釋 放信道資源；如果不小于，則按第二種方式向其它節(jié)點發(fā)送資源釋放指令，由指令直接控制 其它節(jié)點的NAV歸零，釋放信道資源。
[0155] 本步驟中，目的節(jié)點發(fā)送資源釋放指令的具體過程為：目的節(jié)點判定剩余時間較 大時，則發(fā)送第一資源釋放指令，然后再相隔一個第一幀間間隔發(fā)送第二資源釋放指令，本 步驟中所說的發(fā)送資源釋放指令的時間指的是，發(fā)送第一資源釋放指令、第二資源釋放指 令以及第一幀間間隔所需的時間和。
[0156] 參見圖11所示示意圖，目的節(jié)點發(fā)送一個STBC模式的資源釋放指令MRI (Medium Release Indication，可視為是第一資源釋放指令），然后再間隔一個SIFS (可視為是第一 幀間間隔）發(fā)送一個non-STBC模式的MRI (可視為是第二資源釋放指令）。
[0157] 參見圖12所示示意圖，目的節(jié)點發(fā)送一個non-STBC模式的資源釋放指令MRI (可 視為是第一資源釋放指令），然后再間隔一個SIFS (可視為是第一幀間間隔）發(fā)送一個 STBC模式的MRI (可視為是第二資源釋放指令）。
[0158] 需要說明的是，為了提高網(wǎng)絡(luò)性能，使源節(jié)點盡快接收到CTS幀并向目的節(jié)點發(fā) 送數(shù)據(jù)幀，一般情況下，目的節(jié)點會先發(fā)送與RTS幀模式相同的CTS幀（例如，RTS幀為STBC 模式，則目的節(jié)點先發(fā)STBC模式的CTS，間隔一個幀間間隔后再發(fā)non-STBC模式的CTS)， 而對兩種模式的資源釋放指令則無發(fā)送順序的要求。當(dāng)然，如若不考慮網(wǎng)絡(luò)性能，只要使源 節(jié)點接收到CTS幀即可，則目的節(jié)點發(fā)送兩種模式的CTS幀也無順序要求，對此本發(fā)明不做 限定。
[0159] (5)對于發(fā)送第一資源釋放指令和第二資源釋放指令的方式來說，如果同樣以 Retry位為" 1"表示釋放資源，則接收到指令的節(jié)點：如果能識別STBC模式的指令，則據(jù)此 將其NAV初始化為零；如果能識別non-STBC模式的指令，則據(jù)此將其NAV初始化為默認(rèn)值， 重新與網(wǎng)絡(luò)中的節(jié)點競爭信道資源，至此就完成了本發(fā)明的資源預(yù)約過程。
[0160] 參見圖13,示出了本發(fā)明資源預(yù)約裝置實施例1的示意圖，所述裝置應(yīng)用于WiFi 系統(tǒng)，所述裝置包括：
[0161] 接收單元301，用于接收源節(jié)點發(fā)送的資源預(yù)約請求。
[0162] 發(fā)送單元302,用于在接收到所述資源預(yù)約請求之后（具體可體現(xiàn)為間隔一個 SIFS之后），向所述源節(jié)點發(fā)送資源預(yù)約響應(yīng)，所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源 預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽所述資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間 設(shè)置各自的網(wǎng)絡(luò)分配矢量。
[0163] 第一判斷單元303,用于判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)；
[0164] 預(yù)定時間 T = aSIFSTime+aPHY-RX-START-Delay+aSlotTime，
[0165] 其中，aSIFSTime為第一幀間間隔，aPHY-RX-START-Delay為物理層反應(yīng)時間， aSlotTime為時隙長度。
[0166] 資源釋放單元304,用于在所述第一判斷單元判斷未接收到所述源節(jié)點發(fā)送的數(shù) 據(jù)時，向所述其它節(jié)點發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量， 重新競爭資源。
[0167] 需要說明的是，對于資源釋放單元發(fā)送的資源釋放指令來說，其可以構(gòu)建新的控 制幀來實現(xiàn)，也可以使用無競爭結(jié)束幀CF-End幀實現(xiàn)，還可以改造已有的幀來實現(xiàn)，例如 改造資源預(yù)約響應(yīng)CTS、確認(rèn)幀ACK、零數(shù)據(jù)報文NDP等等。其具體實現(xiàn)過程已在上述方法 實施例解釋說明，此處不再贅述。
[0168] 目前，在解決隱藏節(jié)點問題時存在兩種機(jī)制，一種是單CTS機(jī)制，一種是雙CTS機(jī) 制：
[0169] 對于單CTS機(jī)制的方案來說，
[0170] 所述發(fā)送單元，具體用于在接收到所述資源預(yù)約請求之后，相隔一個第一幀間間 隔向所述源節(jié)點發(fā)送第一資源預(yù)約響應(yīng)；則
[0171] 所述資源釋放單元，具體用于向所述其它節(jié)點發(fā)送第一資源釋放指令，以使所述 其它節(jié)點根據(jù)所述第一資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
[0172] 對于雙CTS機(jī)制的方案來說，
[0173] 所述發(fā)送單元，具體用于在接收到所述資源預(yù)約請求之后，相隔一個第一幀間間 隔、第一資源預(yù)約響應(yīng)以及第二幀間間隔向所述源節(jié)點發(fā)送第二資源預(yù)約響應(yīng)；則
[0174] 所述資源釋放單元，具體用于向所述其它節(jié)點發(fā)送第一資源釋放指令，并相隔一 個所述第一幀間間隔向所述其它節(jié)點發(fā)送第二資源釋放指令，以使所述其它節(jié)點根據(jù)所述 第一資源釋放指令或者第二資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
[0175] 參見圖14,示出了本發(fā)明資源預(yù)約裝置實施例2的示意圖，所述裝置應(yīng)用于WiFi 系統(tǒng)，所述裝置包括：
[0176] 接收單元401，用于接收源節(jié)點發(fā)送的資源預(yù)約請求。
[0177] 發(fā)送單元402,用于在接收到所述資源預(yù)約請求之后，向所述源節(jié)點發(fā)送資源預(yù)約 響應(yīng)，所述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽 所述資源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量。
[0178] 第一判斷單元403,用于判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)。
[0179] 計算單元404,用于在所述第一判斷單元判斷未接收到所述源節(jié)點發(fā)送的數(shù)據(jù)時， 計算獲得所述預(yù)約時間的剩余時間，所述剩余時間為所述預(yù)約時間與所述預(yù)定時間之差。
[0180] 第二判斷單元405,用于比較所述剩余時間與所述資源釋放單元發(fā)送所述資源釋 放指令所需的時間。
[0181] 資源釋放單元406,用于在所述第二判斷單元判斷所述剩余時間不小于發(fā)送所述 資源釋放指令所需的時間時，向所述其它節(jié)點發(fā)送資源釋放指令，以使所述其它節(jié)點初始 化各自的網(wǎng)絡(luò)分配矢量，重新競爭資源。
[0182] 需要說明的是，對于單CTS機(jī)制的方案來說，發(fā)送資源釋放指令的時間指的是發(fā) 送第一資源釋放指令所需的時間；對于雙CTS機(jī)制的方案來說，發(fā)送資源釋放指令的時間 指的是發(fā)送第一資源釋放指令、第二資源釋放指令以及第一幀間間隔所需的時間和，其中 第一資源釋放指令、第二資源釋放指令指的是STBC模式和non-STBC模式發(fā)送的指令。
[0183] 進(jìn)一步地，本發(fā)明實施例還分別提供了資源預(yù)約裝置的硬件構(gòu)成?？砂ㄖ辽僖?個處理器（例如CPU)，至少一個網(wǎng)絡(luò)接口或者其它通信接口，存儲器，和至少一個通信總 線，用于實現(xiàn)這些裝置之間的連接通信。處理器用于執(zhí)行存儲器中存儲的可執(zhí)行模塊，例如 計算機(jī)程序。存儲器可能包含高速隨機(jī)存取存儲器（RAM :Random Access Memory),也可能 還包括非不穩(wěn)定的存儲器（non-volatile memory),例如至少一個磁盤存儲器。通過至少 一個網(wǎng)絡(luò)接口（可以是有線或者無線）實現(xiàn)該系統(tǒng)網(wǎng)關(guān)與至少一個其它網(wǎng)元之間的通信連 接，可以使用互聯(lián)網(wǎng)，廣域網(wǎng)，本地網(wǎng)，城域網(wǎng)等。
[0184] 參見圖15,在一些實施方式中，存儲器中存儲了程序指令，程序指令可以被處理器 執(zhí)行，其中，程序指令包括接收單元301、發(fā)送單元302、第一判斷單元303、資源釋放單元 304,各單元的具體實現(xiàn)可參見圖13所揭示的相應(yīng)單元?；蛘叱绦蛑噶钸€可包括圖14所揭 示的其它單元，這里不再贅述。
[0185] 本發(fā)明方案可以在由計算機(jī)執(zhí)行的計算機(jī)可執(zhí)行指令的一般上下文中描述，例如 程序單元。一般地，程序單元包括執(zhí)行特定任務(wù)或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對 象、組件、數(shù)據(jù)結(jié)構(gòu)等等。也可以在分布式計算環(huán)境中實踐本發(fā)明方案，在這些分布式計算 環(huán)境中，由通過通信網(wǎng)絡(luò)而被連接的遠(yuǎn)程處理設(shè)備來執(zhí)行任務(wù)。在分布式計算環(huán)境中，程序 單元可以位于包括存儲設(shè)備在內(nèi)的本地和遠(yuǎn)程計算機(jī)存儲介質(zhì)中。
[0186] 本說明書中的各個實施例均采用遞進(jìn)的方式描述，各個實施例之間相同相似的部 分互相參見即可，每個實施例重點說明的都是與其它實施例的不同之處。尤其，對于裝置實 施例而言，由于其基本相似于方法實施例，所以描述得比較簡單，相關(guān)之處參見方法實施例 的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明 的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是 物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡(luò)單元上。可以根據(jù)實際的需要 選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領(lǐng)域普通技術(shù)人員在不付出 創(chuàng)造性勞動的情況下，即可以理解并實施。
[0187] 以上對本發(fā)明實施例進(jìn)行了詳細(xì)介紹，本文中應(yīng)用了【具體實施方式】對本發(fā)明進(jìn)行 了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及設(shè)備；同時，對于本領(lǐng)域的 一般技術(shù)人員，依據(jù)本發(fā)明的思想，在【具體實施方式】及應(yīng)用范圍上均會有改變之處，綜上所 述，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
【權(quán)利要求】
1. 一種資源預(yù)約方法，其特征在于，所述方法應(yīng)用于WiFi系統(tǒng)，所述方法包括： 目的節(jié)點接收源節(jié)點發(fā)送的資源預(yù)約請求，并向所述源節(jié)點發(fā)送資源預(yù)約響應(yīng)，所述 資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽所述資源 預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量； 所述目的節(jié)點判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)，如果未接收到， 則發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量，重新競爭資源。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述向所述其它節(jié)點發(fā)送資源釋放指 令之前，所述方法還包括： 計算獲得所述預(yù)約時間的剩余時間，并與發(fā)送所述資源釋放指令所需的時間相比較， 若所述剩余時間不小于發(fā)送所述資源釋放指令所需的時間，則向所述其它節(jié)點發(fā)送所述資 源釋放指令；其中，所述剩余時間為所述預(yù)約時間與所述預(yù)定時間之差。
3. 根據(jù)權(quán)利要求1或2所述的方法，其特征在于， 所述資源預(yù)約響應(yīng)為所述目的節(jié)點接收到所述資源預(yù)約請求后，相隔一個第一幀間間 隔發(fā)送的第一資源預(yù)約響應(yīng)； 則所述向所述其它節(jié)點發(fā)送資源釋放指令，包括： 所述目的節(jié)點向所述其它節(jié)點發(fā)送第一資源釋放指令，以使所述其它節(jié)點根據(jù)所述第 一資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
4. 根據(jù)權(quán)利要求1或2所述的方法，其特征在于， 所述資源預(yù)約響應(yīng)為所述目的節(jié)點接收到所述資源預(yù)約請求后，相隔一個第一幀間間 隔、第一資源預(yù)約響應(yīng)以及第二幀間間隔發(fā)送的第二資源預(yù)約響應(yīng)； 則所述向所述其它節(jié)點發(fā)送資源釋放指令，包括： 所述目的節(jié)點向所述其它節(jié)點發(fā)送第一資源釋放指令，并相隔一個所述第一幀間間隔 向所述其它節(jié)點發(fā)送第二資源釋放指令，以使所述其它節(jié)點根據(jù)所述第一資源釋放指令或 者第二資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
5. 根據(jù)權(quán)利要求1至4任一項所述的方法，其特征在于， 所述預(yù)定時間 T = aSIFSTime+aPHY-RX-START-Delay+aSlotTime， 其中，aSIFSTime為第一幀間間隔，aPHY-RX-START-Delay為物理層反應(yīng)時間， aSlotTime為時隙長度。
6. 根據(jù)權(quán)利要求1至5任一項所述的方法，其特征在于，獲得所述資源釋放指令的方式 為： 改造資源預(yù)約響應(yīng)、確認(rèn)幀、零數(shù)據(jù)報文中的任一種，獲得所述資源釋放指令；或者， 使用無競爭結(jié)束幀作為所述資源釋放指令；或者， 構(gòu)建新的控制幀作為所述資源釋放指令。
7. 根據(jù)權(quán)利要求6所述的方法，其特征在于， 如果通過改造所述資源預(yù)約響應(yīng)或者所述確認(rèn)幀獲得所述資源釋放指令，則資源釋放 指示位為巾貞控制域內(nèi)的任一保留位；或者， 如果通過改造所述資源預(yù)約響應(yīng)或者所述確認(rèn)幀獲得所述資源釋放指令，則資源釋放 指示位為持續(xù)時間域內(nèi)的任一保留組合；或者， 如果通過改造所述零數(shù)據(jù)報文獲得所述資源釋放指令，則資源釋放指示位為調(diào)制編碼 方式域內(nèi)的任一保留組合； 其中，所述資源釋放指示位，用于指示所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量。
8. 根據(jù)權(quán)利要求7所述的方法，其特征在于， 如果所述資源釋放指示位為所述幀控制域內(nèi)的任一保留位，則將所述資源預(yù)約響應(yīng)的 持續(xù)時間域設(shè)置為網(wǎng)絡(luò)分配矢量的默認(rèn)值。
9. 一種資源預(yù)約裝置，其特征在于，所述裝置應(yīng)用于WiFi系統(tǒng)，所述裝置包括： 接收單元，用于接收源節(jié)點發(fā)送的資源預(yù)約請求； 發(fā)送單元，用于在接收到所述資源預(yù)約請求之后，向所述源節(jié)點發(fā)送資源預(yù)約響應(yīng)，所 述資源預(yù)約響應(yīng)包含預(yù)約時間，所述資源預(yù)約響應(yīng)用于使所述WiFi系統(tǒng)中能偵聽所述資 源預(yù)約響應(yīng)的其它節(jié)點按照所述預(yù)約時間設(shè)置各自的網(wǎng)絡(luò)分配矢量； 第一判斷單元，用于判斷在預(yù)定時間內(nèi)是否接收到所述源節(jié)點發(fā)送的數(shù)據(jù)； 資源釋放單元，用于在所述第一判斷單元判斷未接收到所述源節(jié)點發(fā)送的數(shù)據(jù)時，向 所述其它節(jié)點發(fā)送資源釋放指令，以使所述其它節(jié)點初始化各自的網(wǎng)絡(luò)分配矢量，重新競 爭資源。
10. 根據(jù)權(quán)利要求1所述的裝置，其特征在于，所述裝置還包括： 計算單元，用于計算獲得所述預(yù)約時間的剩余時間，所述剩余時間為所述預(yù)約時間與 所述預(yù)定時間之差； 第二判斷單元，用于比較所述剩余時間與所述資源釋放單元發(fā)送所述資源釋放指令所 需的時間，若所述剩余時間不小于發(fā)送所述資源釋放指令所需的時間，則通知所述資源釋 放單元向所述其它節(jié)點發(fā)送所述資源釋放指令。
11. 根據(jù)權(quán)利要求9或10所述的裝置，其特征在于， 所述發(fā)送單元，具體用于在接收到所述資源預(yù)約請求之后，相隔一個第一幀間間隔向 所述源節(jié)點發(fā)送第一資源預(yù)約響應(yīng)；則 所述資源釋放單元，具體用于向所述其它節(jié)點發(fā)送第一資源釋放指令，以使所述其它 節(jié)點根據(jù)所述第一資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
12. 根據(jù)權(quán)利要求9或10所述的裝置，其特征在于， 所述發(fā)送單元，具體用于在接收到所述資源預(yù)約請求之后，相隔一個第一幀間間隔、第 一資源預(yù)約響應(yīng)以及第二巾貞間間隔向所述源節(jié)點發(fā)送第二資源預(yù)約響應(yīng)；則 所述資源釋放單元，具體用于向所述其它節(jié)點發(fā)送第一資源釋放指令，并相隔一個所 述第一幀間間隔向所述其它節(jié)點發(fā)送第二資源釋放指令，以使所述其它節(jié)點根據(jù)所述第一 資源釋放指令或者第二資源釋放指令初始化所述網(wǎng)絡(luò)分配矢量。
13. 根據(jù)權(quán)利要求9至12任一項所述的裝置，其特征在于，所述第一判斷單元判斷是否 接收到所述源節(jié)點發(fā)送的數(shù)據(jù)的預(yù)定時間T為： T = aSIFSTime+aPHY-RX-START-Delay+aSlotTime, 其中，aSIFSTime為第一幀間間隔，aPHY-RX-START-Delay為物理層反應(yīng)時間， aSlotTime為時隙長度。
【文檔編號】H04W74/08GK104105216SQ201310121350
【公開日】2014年10月15日 申請日期:2013年4月9日 優(yōu)先權(quán)日:2013年4月9日
【發(fā)明者】杜振國, 方平, 丁志明 申請人:華為終端有限公司