專利名稱：在無線個人域網(wǎng)上的裝置之間交換數(shù)據(jù)的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種在無線網(wǎng)絡(luò)上的裝置之間執(zhí)行有效的通信的方法和設(shè)備，更具體地說，涉及一種通過改進(jìn)在無線PAN(個人域網(wǎng))上運(yùn)行的裝置的MAC(介質(zhì)訪問控制)而在分配的信道時間期間雙向交換數(shù)據(jù)的方法和設(shè)備。
背景技術(shù)：
由美國國防部為軍事目的而開發(fā)的UWB(超寬帶)，也被稱為數(shù)字脈沖無線，是一種在短距離內(nèi)以低功率在寬頻譜的頻帶上發(fā)送大量數(shù)字?jǐn)?shù)據(jù)的無線技術(shù)。目前正由建立了IEEE802.15.3，即無線PAN標(biāo)準(zhǔn)的工作組進(jìn)行UWB的標(biāo)準(zhǔn)化。IEEE 802.15.3處理PHY(物理層)和MAC。近來，在無線電技術(shù)領(lǐng)域中，改進(jìn)MAC的研究已變得活躍。
802.15.3MAC的特征在于迅速地建立無線網(wǎng)絡(luò)。此外，802.15.3MAC不是基于AP(接入點(diǎn))，而是基于對等網(wǎng)絡(luò)，該對等網(wǎng)絡(luò)被稱作微微網(wǎng)，由PNC(微微網(wǎng)協(xié)調(diào)器)控制。802.15.3MAC采用TDMA(時分多址)系統(tǒng)。如圖1所示，用于在裝置之間交換數(shù)據(jù)的MAC幀被實(shí)施為稱作超級幀的時間結(jié)構(gòu)。超級幀包括包含控制信息的信標(biāo)、用于通過退避發(fā)送數(shù)據(jù)的CAP(競爭訪問周期)、和用于在分配的時間內(nèi)無競爭地發(fā)送數(shù)據(jù)的CTAP(信道時間分配周期)。在它們之中，CAP可被MCTA(管理CTA)替換。目前，通過CSMA/CA(載波偵聽多址接入/沖突避免)系統(tǒng)可在CAP中進(jìn)行競爭訪問，通過時隙Aloha方法可在MCTA中訪問信道。
CTAP可包括多個MCTA塊和多個CTA塊。CTA(信道時間分配)被分為兩種類型即動態(tài)CTA和偽靜態(tài)CTA。動態(tài)CTA可在每個超級幀中改變位置，但是如果超級幀的信標(biāo)丟失，則所述動態(tài)CTA不能在相關(guān)超級幀中使用。另一方面，偽靜態(tài)CTA在相同的固定位置上保持不變，并且即使超級幀的信標(biāo)丟失，所述偽靜態(tài)CTA也可在固定位置上使用。然而，如果信標(biāo)連續(xù)丟失超過對應(yīng)于mMaxLostBeacons的次數(shù)，則偽靜態(tài)CTA不可被使用。因此，由于802.15.3MAC是基于能夠保證QoS(服務(wù)質(zhì)量)的TDMA系統(tǒng)，所以它特別適合家庭網(wǎng)絡(luò)上的多媒體音頻/視頻(A/V)流。但是，MAC還應(yīng)被進(jìn)一步改進(jìn)以有效地利用通過量以及QoS。
在802.15.3MAC中有兩種數(shù)據(jù)傳輸方案即，等時數(shù)據(jù)傳輸方案和異步數(shù)據(jù)傳輸方案。
在等時數(shù)據(jù)傳輸方案中，通過MAC子層管理實(shí)體(MLME)-CREATE-STREAM.request首先從PNC分配信道時間。如圖2所示，隨后通過MAC-ISOCH-DATA.request和MAC-ISOCH-DATA.confirm，在分配的信道時間期間實(shí)際發(fā)送MLME-CREATE-STREAM.confirm和數(shù)據(jù)?？梢酝ㄟ^分析信標(biāo)來獲得分配的信道時間，構(gòu)成微微網(wǎng)的裝置(在下文中稱為“DEV”)因此可以基于獲得的信道時間知道通信開始時間和通信結(jié)束時間。這時，對于分配的信道時間指定源裝置(src DEV)和目的裝置(dest DEV)。在分配的信道時間內(nèi)發(fā)送數(shù)據(jù)的裝置必須是src DEV，但是接收數(shù)據(jù)的裝置不必是在CTA信息中指定的dest DEV。然而，能夠接收數(shù)據(jù)的裝置是“總是喚醒位”或“對源偵聽位”被設(shè)置為1的裝置。
另一方面，如圖3所示，在異步數(shù)據(jù)傳輸方案中，當(dāng)要被發(fā)送的數(shù)據(jù)經(jīng)由MAC-ASYNC-DATA.request到達(dá)MAC層時，src DEV將信道時間請求命令幀發(fā)送到PNC。隨后，當(dāng)src DEV從信標(biāo)知道請求的信道時間已被分配時，在分配的信道時間期間發(fā)送數(shù)據(jù)。類似于等時數(shù)據(jù)傳輸方案，對于分配的信道時間指定一對src DEV和dest DEV，在分配的信道時間期間，只有指定的src DEV可以發(fā)送數(shù)據(jù)。此外，提供一種在競爭訪問周期(CAP)中使用退避算法發(fā)送幀的方法，作為發(fā)送異步數(shù)據(jù)的替換方法。
為了確保數(shù)據(jù)傳輸?shù)目煽啃?，TCP/IP被這樣配置，以使DEV1將幀發(fā)送到DEV2并且DEV2將ACK幀(TCP/IP級別的ACK幀，不是如圖2和圖3所示的Imm-ACK幀)返回給DEV1。以下將詳細(xì)描述當(dāng)由802.15.3MAC提供的數(shù)據(jù)傳輸機(jī)制被直接使用在具有該機(jī)制的TCP/IP中時發(fā)生的問題。
首先，當(dāng)TCP/IP數(shù)據(jù)被等時發(fā)送時，DEV1將向DEV2發(fā)送用于建立與DEV2的連接的幀。為此，DEV1首先向PNC發(fā)送MLME-CREATE-STREAM.request以請求信道時間分配，在該信道時間分配中，src DEV是DEV1，destDEV是DEV2。當(dāng)PNC分配信道時間并發(fā)送包含關(guān)于信道時間的信息的信標(biāo)時，DEV1讀取關(guān)于該信標(biāo)的信息并在指定時間將幀發(fā)送到DEV2。為了發(fā)送從DEV1發(fā)送的幀的響應(yīng)幀，DEV2請求信道時間分配，在該信道時間分配中，src DEV是DEV2，dest DEV是DEV1。類似地，當(dāng)PNC分配信道時間并發(fā)送包含關(guān)于信道時間的信息的信標(biāo)時，DEV2讀取關(guān)于該信標(biāo)的信息并在指定時間將響應(yīng)幀發(fā)送到DEV1。由于持續(xù)分配信道時間，直到接收到MLME-TERMINATE-STREAM.request，所以根據(jù)信標(biāo)中的信道時間信息，在DEV1和DEV2之間交換的數(shù)據(jù)和ACK幀將在被分配給這對src DEV和destDEV的時間被發(fā)送。然而，根據(jù)TCP/IP的特點(diǎn)，直到發(fā)送方在發(fā)送數(shù)據(jù)幀之后接收到ACK幀，發(fā)送方才發(fā)送其它幀。在802.15.3MAC中，只有在來自信標(biāo)的信道時間分配中指定的src DEV可以是信道時間的發(fā)送方。因此，在src DEV為DEV2的信道時間之后，DEV2應(yīng)該發(fā)送TCP/IP級別的ACK幀。因此，盡管在DEV1發(fā)送數(shù)據(jù)之后分配給DEV1和DEV2的時間還有剩余，但是DEV1在剩余的時間期間不能從DEV2接收ACK幀，從而產(chǎn)生了信道時間的浪費(fèi)。
其次，將討論TCP/IP幀被異步發(fā)送的情況。當(dāng)異步數(shù)據(jù)被發(fā)送到競爭訪問周期時，PNC可以或者可以不將CAP分配給超級幀。此外，即使存在分配的CAP，由于在根據(jù)由PNC設(shè)置的標(biāo)準(zhǔn)的期間發(fā)生對異步數(shù)據(jù)是否可被發(fā)送的確定，所以使用CAP發(fā)送TCP/IP幀的方法也無法確保TCP/IP幀的可靠傳輸。接下來，為了通過信道時間分配發(fā)送異步數(shù)據(jù)，應(yīng)該如上所述使用MAC-ASYNCH-DATA.request。
發(fā)明公開技術(shù)問題然而，如圖2和圖3所示，僅在信道時間請求命令已被發(fā)送到PNC并且信道時間隨后被分配之后，數(shù)據(jù)幀才應(yīng)被發(fā)送。這樣的數(shù)據(jù)連續(xù)發(fā)送導(dǎo)致帶寬的浪費(fèi)。此外，由于即使當(dāng)請求了信道時間分配時也不能保證請求的信道時間會被分配，所以每當(dāng)每個數(shù)據(jù)幀被發(fā)送時，嘗試發(fā)送數(shù)據(jù)的裝置應(yīng)該等待，直到至少下一超級幀。因此，將一直發(fā)生時延。
前述問題不僅會發(fā)生在TCP/IP中而且當(dāng)在802.15.3MAC的更高層中執(zhí)行在兩個DEV之間交換數(shù)據(jù)的協(xié)議時也會發(fā)生。
技術(shù)解決方案構(gòu)思本發(fā)明以解決前述問題。本發(fā)明旨在通過改進(jìn)802.15.3MAC(介質(zhì)訪問控制)而實(shí)現(xiàn)在更高的協(xié)議中的有效通信。為此，將提出一種除了802.15.3MAC中的單向傳輸之外在雙向傳輸中使用CTA的方法。
根據(jù)實(shí)現(xiàn)此目標(biāo)的本發(fā)明的一方面，提供一種在無線個人域網(wǎng)(PAN)上的裝置之間交換數(shù)據(jù)的方法，包括以下步驟(1)產(chǎn)生包含確定數(shù)據(jù)傳輸是單向還是雙向的方向信息的信道時間請求幀，將該信道時間請求幀發(fā)送到負(fù)責(zé)信道時間分配的裝置；(2)基于在信道時間請求幀中包含的信息產(chǎn)生包含包括方向信息的信道時間分配信息的幀，并廣播產(chǎn)生的幀；和(3)根據(jù)方向信息在預(yù)定的信道時間期間，在第一和第二裝置之間交換數(shù)據(jù)，所述第一和第二裝置在包含信道時間分配信息的幀中被指定為源裝置和目的裝置。
優(yōu)選地，但不是必須地，所述信道時間請求幀是在IEEE 802.15.3中指定的信道時間請求命令幀。
優(yōu)選地，但不是必須地，所述負(fù)責(zé)信道時間分配的裝置是在IEEE 802.15.3中指定的微微網(wǎng)協(xié)調(diào)器(PNC)。
優(yōu)選地，但不是必須地，包含信道時間分配信息的幀是在IEEE 802.15.3中指定的信標(biāo)幀。
此外，步驟(3)包括以下步驟將數(shù)據(jù)從第一裝置發(fā)送到第二裝置，當(dāng)在數(shù)據(jù)發(fā)送之后第一裝置沒有要發(fā)送的其它數(shù)據(jù)時將NULL幀發(fā)送到第二裝置。
優(yōu)選地，但不是必須地，在PAN上的裝置之間交換數(shù)據(jù)的方法還包括以下步驟如果接收到NULL幀的第二裝置有要發(fā)送到第一裝置的數(shù)據(jù)，則將該數(shù)據(jù)發(fā)送到第一裝置；和如果第二裝置沒有數(shù)據(jù)，則發(fā)送由第一裝置發(fā)送的數(shù)據(jù)的ACK幀。
優(yōu)選地，但不是必須地，在PAN上的裝置之間交換數(shù)據(jù)的方法還包括以下步驟如果接收到ACK幀的第一裝置有要發(fā)送到第二裝置的數(shù)據(jù)，則將該數(shù)據(jù)發(fā)送到第二裝置；和如果第一裝置沒有數(shù)據(jù)，則將NULL幀發(fā)送到第二裝置。
優(yōu)選地，但不是必須地，所述ACK幀是MAC層中的中間ACK幀。
優(yōu)選地，但不是必須地，所述NULL幀僅由MAC頭組成。


通過下面結(jié)合附圖對優(yōu)選實(shí)施例進(jìn)行的描述，本發(fā)明的以上和其它目的、特定和優(yōu)點(diǎn)將會變得清楚，其中
圖1是顯示相關(guān)技術(shù)的超級幀的結(jié)構(gòu)的示圖；圖2是顯示根據(jù)現(xiàn)有技術(shù)請求信道時間分配的過程的示圖；圖3是顯示根據(jù)現(xiàn)有技術(shù)發(fā)送異步數(shù)據(jù)的過程的示圖；圖4是顯示根據(jù)本發(fā)明的信道時間請求命令幀的結(jié)構(gòu)的示圖；圖5是顯示根據(jù)本發(fā)明的信標(biāo)幀的結(jié)構(gòu)的示圖；圖6是顯示第一示例性實(shí)施例的示圖，在該第一示例性實(shí)施例中，在給定的信道時間內(nèi)數(shù)據(jù)在裝置之間雙向地交換；圖7是顯示NULL幀的結(jié)構(gòu)的示圖；圖8是顯示各種幀的幀類型值的根據(jù)第一示例性實(shí)施例的表；圖9是示出第一示例性實(shí)施例的全部操作的流程圖；圖10是顯示第二示例性實(shí)施例的示圖，在該第二示例性實(shí)施例中，在給定的信道時間內(nèi)數(shù)據(jù)在裝置之間雙向地交換；圖11是顯示TOKEN幀的結(jié)構(gòu)的示圖；圖12是顯示各種幀的幀類型值的第二示例性實(shí)施例的表；圖13是示出根據(jù)本發(fā)明的第二示例性實(shí)施例的全部操作的流程圖；圖14是顯示根據(jù)現(xiàn)有技術(shù)進(jìn)行單向傳輸?shù)那闆r下的超級幀結(jié)構(gòu)以及數(shù)據(jù)傳輸過程的示圖；和圖15是顯示根據(jù)本發(fā)明進(jìn)行雙向傳輸?shù)那闆r下的超級幀結(jié)構(gòu)以及數(shù)據(jù)傳輸過程的示圖。
具體實(shí)施例方式
在下文中，將參照附圖詳細(xì)描述本發(fā)明的示例性實(shí)施例。
在其中兩個DEV作為發(fā)送方和接收方的角色不固定而是動態(tài)地交換的信道時間周期被增加，隨后當(dāng)在其中兩個DEV應(yīng)該如同在TCP/IP中一樣交換數(shù)據(jù)的協(xié)議在更高的MAC層被執(zhí)行時，向PNC(微微網(wǎng)協(xié)調(diào)器)請求信道時間。起向微微網(wǎng)中的DEV提供各種服務(wù)的作用的PNC分配信道時間，執(zhí)行DEV之間的同步，并且執(zhí)行使得DEV經(jīng)由無線通信介質(zhì)加入微微網(wǎng)的連接功能。
為了數(shù)據(jù)的交換，首先需要修改由802.15.3MAC提供的MLME-CREATE-STREAM.request的參數(shù)。下面的表1顯示一個新參數(shù)“DirectionType”被添加至其的修改的MLME-CREATE-STREAM.Request的參數(shù)。“DirectionType”定義方向信息，該方向信息被用于確定數(shù)據(jù)傳輸是單向的還是雙向的。
表1

“DirectionType”的參數(shù)如以下表2被定義。
表2

假設(shè)DEV1使用TCP/IP協(xié)議將數(shù)據(jù)發(fā)送到DEV2。首先，DEV1調(diào)用MLME-CREATE-STREAM.request以從PNC請求信道時間。此時，“DirectionType”被設(shè)置為“TWO_WAY”。當(dāng)DEV1的MLME接收MLME-CREATE-STREAM.request時，其將如圖4所示的信道時間請求命令100發(fā)送到PNC。此時，如表1所示，用于定義“DirectionType”的位字段被添加到構(gòu)成信道時間請求命令100的信道時間請求塊110。盡管“DirectionType”字段分配有一個八位字節(jié)，但是因?yàn)樵撟侄卧凇癘NE_WAY”的情況下為“0”在“TWO_WAY”的情況下為“1”，所以對于該字段，僅僅一位信息就足夠了。因此，該字段實(shí)際上僅使用1位，其余7位被保留。
當(dāng)即使在PNC接收信道時間請求命令100之后通信介質(zhì)的資源仍然足夠時，信道時間經(jīng)由信標(biāo)被分配給相關(guān)DEV。圖5顯示信標(biāo)幀200的結(jié)構(gòu)、在信標(biāo)幀中的至少一個“信息元素”字段的“信道時間分配信息元素”字段210的結(jié)構(gòu)、以及存在于“信道時間分配信息元素”字段210中的至少一個“信道時間分配塊”字段211的結(jié)構(gòu)。“信道時間分配塊”字段211包括DestID字段，指示接收DEV的ID；SrcID，指示發(fā)送DEV的ID；在本發(fā)明中定義的DirectionType字段，用以指示數(shù)據(jù)發(fā)送方向是ONE_WAY還是TWO_WAY；流索引字段，指示要被發(fā)送的數(shù)據(jù)流的身份；CTA位置字段，指示CTA在超級幀中的位置；和CTA時長字段，指示CTA的時長。
在DirectionType為ONE_WAY的信道時間期間，僅是已由SrcID指定的DEV，即已發(fā)送了信道時間請求命令100的DEV可以作為發(fā)送方。這與現(xiàn)有的802.15.3相同。如果DirectionType為TWO_WAY的信道時間被分配，則SrcID和DestID已被分別分配至其的兩個DEV都可作為發(fā)送方來在分配的信道時間期間將期望的數(shù)據(jù)發(fā)送到另一DEV。信標(biāo)包括信道時間分配塊211，在信道時間分配塊211中，已發(fā)送了信道時間請求命令100的DEV1由SrcID指定，DEV2由DestId指定?；谛艠?biāo)信息，由SrcID指定的DEV1將首先成為發(fā)送方。
在下文中，圖6至圖9示出本發(fā)明的第一示例性實(shí)施例，圖10至圖13示出本發(fā)明的第二示例性實(shí)施例。
在第一示例性實(shí)施例中，當(dāng)要被src DEV發(fā)送的數(shù)據(jù)沒有剩余時“NULL”幀被發(fā)送，隨后dest DEV可發(fā)送數(shù)據(jù)。盡管dest DEV接收到NULL幀但當(dāng)沒有要發(fā)送的數(shù)據(jù)時，它再次將Imm-ACK(立即ACK)發(fā)送到src DEV，從而將發(fā)送數(shù)據(jù)的機(jī)會再次移交給src DEV。因此，NULL幀的“ACK-policy”變成“Imm-ACK”。
在第二示例性實(shí)施例中，當(dāng)要發(fā)送的數(shù)據(jù)沒有剩余時src DEV發(fā)送“TOKEN幀”。作為響應(yīng)，dest DEV可發(fā)送數(shù)據(jù)。盡管dest DEV接收到TOKEN幀但當(dāng)沒有要發(fā)送的數(shù)據(jù)時，它再次將TOKEN幀發(fā)送到src DEV，從而將發(fā)送數(shù)據(jù)的機(jī)會再次移交給src DEV。因此，TOKEN幀的“ACK-policy”變成“No-ACK”。
將參照圖6至圖9描述本發(fā)明的第一示例性實(shí)施例。
圖6顯示在DirectionType為TWO_WAY的信道時間期間在DEV1和DEV2之間交換數(shù)據(jù)的過程。在從信標(biāo)接收信道時間分配塊211之后，DEV1首先成為發(fā)送方并在指定時間將數(shù)據(jù)發(fā)送到DEV2(S10)，在所述信道時間分配塊211中，已發(fā)送了信道時間請求命令100的DEV1由SrcID指定，DEV2由DestID指定。DEV2根據(jù)從DEV1接收的數(shù)據(jù)幀的ACK策略發(fā)送ACK幀。在此示例中，假定使用Imm-ACK(立即ACK)策略(S20)。如果DEV1此時沒有要發(fā)送的數(shù)據(jù)，則DEV1將NULL幀發(fā)送到DEV2(S30)。NULL幀是一種僅有MAC頭而不存在幀體部分的幀，其結(jié)構(gòu)顯示在圖7中。如果在步驟S30存在一些要發(fā)送的幀，則將發(fā)送數(shù)據(jù)幀而不是NULL幀。如果DEV2在接收到NULL幀時沒有要發(fā)送的數(shù)據(jù)幀，則Imm-ACK被立即發(fā)送(S40)。在接收到響應(yīng)于先前發(fā)送的NULL幀的Imm-ACK幀之后，如果存在要發(fā)送到DEV2的任何數(shù)據(jù)，則DEV1將數(shù)據(jù)發(fā)送到DEV2，或者如果沒有數(shù)據(jù)，則DEV1將NULL幀再次發(fā)送到DEV2(S50)。當(dāng)DEV2再次接收到NULL幀并且其它數(shù)據(jù)隨后準(zhǔn)備好被發(fā)送到DEV1時，數(shù)據(jù)幀而不是Imm-ACK被發(fā)送到DEV1(S60)。由于DEV1沒有接收到Imm-ACK幀而是接收到響應(yīng)于先前發(fā)送的NULL的數(shù)據(jù)幀，所以響應(yīng)于該接收的數(shù)據(jù)幀，DEV1將Imm-ACK發(fā)送到DEV2(S70)。如果接收到所述Imm-ACK的DEV2還有數(shù)據(jù)，則DEV2繼續(xù)發(fā)送數(shù)據(jù)。否則，DEV2將NULL幀發(fā)送到DEV1(S80)。如果DEV1沒有要在此時發(fā)送的數(shù)據(jù)幀，則其將Imm-ACK發(fā)送到DEV2(S90)。重復(fù)以上過程直到分配給這兩個DEV的信道時間結(jié)束。
圖7顯示本發(fā)明提出的“NULL幀”的詳細(xì)結(jié)構(gòu)。NULL幀對應(yīng)于只有MAC頭而沒有幀體的幀，并且與傳統(tǒng)MAC頭相同，NULL幀的大小為10個八位字節(jié)。NULL幀的每個字段的大小為1個八位字節(jié)。這里，幀類型字段710是NULL幀的類型值被記錄在其中的字段。圖8顯示在其中定義了各種字段幀的類型值的表。這些類型值被記錄在MAC頭的b5、b4和b3位中，并且根據(jù)以上的位的組合指示相關(guān)幀是什么幀。例如，“000”指的是信標(biāo)幀，“001”指的是Imm-ACK幀。此外，在現(xiàn)有的IEEE 802.15.3中指定了各種類型的值，諸如延遲ACK幀(值＝“010”)、命令幀(值＝“011”)和數(shù)據(jù)幀(值＝“100”)。在本發(fā)明中，添加了新的類型的值NULL幀，其被指定為“101”。
再次參考圖7，根據(jù)ACK策略的ACK幀的類型值被記錄在ACK策略字段720中。根據(jù)IEEE 802.15.3，ACK幀的類型值被記錄在MAC頭的b8和b7位中，其中，“NO ACK”的值為“00”，“立即ACK”的值為“01”，“延遲ACK”的值為“10”。因此，在此實(shí)施例中，ACK策略字段的值為“01”。此外，發(fā)送相關(guān)NULL幀的DEV的ID被記錄在DestID字段730中，接收相關(guān)NULL幀的DEV的ID被記錄在SrcID字段740中。而且，MAC頭的所有字段的值變?yōu)椤?”。
圖9是示出本發(fā)明的全部操作的流程圖。
首先，第一裝置產(chǎn)生信道時間請求命令幀，將該產(chǎn)生的命令幀發(fā)送到PNC，并且接收發(fā)送的命令幀的ACK(S801)。為此，在第一裝置的DME(裝置管理實(shí)體)產(chǎn)生MLME-CREATE-STREAM.request并將其隨后發(fā)送到MAC的MLME。如在上面的表1中所定義的，除了現(xiàn)有的參數(shù)之外，MLME-CREATE-STREAM.request還包括參數(shù)“DirectionType”。MLME產(chǎn)生用于請求信道時間的命令幀，即信道時間請求命令幀，并隨后將產(chǎn)生的命令幀經(jīng)由物理層發(fā)送到PNC。
接收到命令幀的PNC確定在當(dāng)前信道(無線通信介質(zhì))中是否有可用資源(S802)。如果確定沒有可用資源，則信道時間響應(yīng)命令幀的原因碼被適當(dāng)?shù)乇硎緸椤安恢С謨?yōu)先級”、“信道時間不可用”、“不能被分配為偽靜態(tài)CTA”等，并且信道時間響應(yīng)命令幀隨后被發(fā)送到第一裝置。如果確定有可用資源，則響應(yīng)于信道時間請求的命令幀，即，其原因碼被表示為“成功”的信道時間響應(yīng)命令幀被發(fā)送到第一裝置，并且隨后從第一裝置接收到Imm-ACK(S803)。
接下來，PNC基于在接收的信道時間請求命令幀中存在的信息產(chǎn)生信標(biāo)幀，并隨后向作為微微網(wǎng)成員的DEV廣播該信標(biāo)幀(S804)。信標(biāo)幀包括關(guān)于信道時間分配的信息，該信息依次包括CTA的時長、CTA在超級幀中的位置、用于數(shù)據(jù)識別的流索引、數(shù)據(jù)發(fā)送裝置(第一裝置)的ID、數(shù)據(jù)接收裝置(第二裝置)的ID、和用于指示數(shù)據(jù)傳輸是單向(ONE_WAY)還是雙向(TWO_WAY)的“DirectionType”。在此實(shí)施例中，“DirectionType”被設(shè)置為雙向，即“1”。接收到包含DirectionType信息的信標(biāo)幀的第一和第二裝置可以知道數(shù)據(jù)在它們之間是以雙向方式交換的。
其后，當(dāng)?shù)谝缓偷诙b置可以彼此通信的CTA的起始時間到達(dá)時(步驟S805中的“是”)，第一裝置將數(shù)據(jù)幀發(fā)送到第二裝置并隨后從第二裝置接收Imm-ACK幀(S806)。由于數(shù)據(jù)被分割成具有比最大幀長度短的長度的單位幀并隨后被發(fā)送，所以數(shù)據(jù)幀發(fā)送過程應(yīng)該被執(zhí)行兩次或多次，以發(fā)送比幀單位更長的數(shù)據(jù)。此外，為了在上面的數(shù)據(jù)被全部發(fā)送之后傳送附加數(shù)據(jù)，應(yīng)該執(zhí)行附加幀發(fā)送過程。
如果在前述數(shù)據(jù)發(fā)送過程之后沒有要由第一裝置發(fā)送的數(shù)據(jù)幀(步驟S807中的“否”)，則第一裝置向第二裝置發(fā)送指示沒有要發(fā)送的其它數(shù)據(jù)的NULL幀(S808)。
如果接收到NULL幀的第二裝置也沒有要發(fā)送的數(shù)據(jù)(步驟S809中的“否”)，則第二裝置將Imm-ACK發(fā)送到第一裝置(S810)并返回步驟S807。另一方面，如果有任何數(shù)據(jù)(步驟S809中的“是”)，則第二裝置將數(shù)據(jù)幀發(fā)送到第一裝置并從第一裝置接收Imm-ACK(S811)。隨后，如果有要由第二裝置發(fā)送的其它數(shù)據(jù)(步驟S812中的“是”)，則再執(zhí)行數(shù)據(jù)幀發(fā)送步驟S811。然而，如果沒有要發(fā)送的其它數(shù)據(jù)(步驟S812中的“否”)，則第二裝置將NULL幀發(fā)送到第一裝置(S813)。類似地，如果接收到NULL幀的第一裝置有要被發(fā)送的數(shù)據(jù)(步驟S814中的“是”)，則處理返回到S806。然而，如果沒有數(shù)據(jù)，則第一裝置將Imm-ACK發(fā)送到第二裝置(S815)并且處理隨后返回到步驟S812。
步驟S806至S815從相關(guān)CTA的起始時間執(zhí)行到結(jié)束時間。此外，如果在任何以上的步驟期間CTA的結(jié)束時間到達(dá)，則圖9的處理被終止。
在下文中，將參照附圖10至圖13描述本發(fā)明的第二示例性實(shí)施例。
圖10顯示在DirectionType為TWO_WAY的信道時間期間在DEV1和DEV2之間交換數(shù)據(jù)的過程。在從信標(biāo)接收到在其中已發(fā)送信道時間請求命令100的DEV1由SrcID指定并且DEV2由DestID指定的信道時間分配塊211之后，DEV1首先成為發(fā)送方并在指定時間將數(shù)據(jù)發(fā)送到DEV2(S110)。DEV2根據(jù)從DEV1接收的數(shù)據(jù)幀的ACK策略發(fā)送ACK幀。在此示例中假定是Imm-ACK(立即ACK)策略(S120)。如果此時DEV1沒有要發(fā)送的數(shù)據(jù)，則DEV1將TOKEN幀發(fā)送到DEV2(S130)。TOKEN幀是一種只有MAC頭而沒有幀體部分的幀，其結(jié)構(gòu)顯示在圖11中。在步驟S130中，如果有一些要發(fā)送的幀，則發(fā)送數(shù)據(jù)幀而不是TOKEN幀。如果DEV2在接收到TOKEN幀的時候沒有要發(fā)送的數(shù)據(jù)幀，則另一TOKEN幀被立即發(fā)送(S140)。在接收到響應(yīng)于先前發(fā)送的TOKEN幀的TOKEN幀之后，如果存在任何要發(fā)送到DEV2的數(shù)據(jù)，則DEV1將數(shù)據(jù)發(fā)送到DEV2，或者如果沒有數(shù)據(jù)，則DEV1將TOKEN幀再次發(fā)送到DEV2(S150)。當(dāng)DEV2再次接收到TOKEN幀并且其它數(shù)據(jù)隨后作好發(fā)送到DEV1的準(zhǔn)備時，數(shù)據(jù)幀而不是TOKEN幀被發(fā)送到DEV1(S160)。由于DEV1接收到響應(yīng)于先前發(fā)送的TOKEN幀的數(shù)據(jù)幀，所以DEV1向DEV2發(fā)送Imm-ACK幀以響應(yīng)接收的數(shù)據(jù)幀(S170)。如果接收Imm-ACK的DEV2還有數(shù)據(jù)，則DEV2繼續(xù)發(fā)送數(shù)據(jù)。否則DEV2將TOKEN幀發(fā)送到DEV1(S180)。重復(fù)以上過程直到分配給這兩個DEV的信道時間結(jié)束。
圖11顯示本發(fā)明中提出的“TOKEN幀”的詳細(xì)結(jié)構(gòu)。TOKEN幀對應(yīng)于只有MAC頭而沒有幀體的幀，并且與傳統(tǒng)MAC頭相同，TOKEN幀的大小為10個八位字節(jié)。TOKEN幀的每個字段的大小為1個八位字節(jié)。這里，幀類型字段710是TOKEN幀的類型值被記錄在其中的字段。圖12顯示在其中定義了各種字段幀的類型值的表。這些類型值被記錄在MAC頭的b5、b4和b3位中，并且根據(jù)以上的位的組合指示相關(guān)幀是什么幀。例如，“000”指的是信標(biāo)幀，“001”指的是Imm-ACK幀。此外，在現(xiàn)有的IEEE 802.15.3中指定了各種類型的值，諸如延遲ACK幀(值＝“010”)、命令幀(值＝“011”)和數(shù)據(jù)幀(值＝“100”)。在本發(fā)明中，添加了新的類型的值TOKEN幀，其被指定為“101”。
再次參考圖11，根據(jù)ACK策略的ACK幀的類型值被記錄在ACK策略字段720中。根據(jù)IEEE 802.15.3，ACK幀的類型值被記錄在MAC頭的b8和b7位中，其中，“NO ACK”的值為“00”，“立即ACK”的值為“01”，“延遲ACK”的值為“10”。因此，在此實(shí)施例中，ACK策略字段的值為“00”。此外，發(fā)送相關(guān)TOKEN幀的DEV的ID被記錄在DestID字段730中，接收相關(guān)TOKEN幀的DEV的ID被記錄在SrcID字段740中。而且，MAC頭的所有字段的值變?yōu)椤?”。
圖13是示出本發(fā)明第二實(shí)施例的全部操作的流程圖。
首先，第一裝置產(chǎn)生信道時間請求命令幀，將該產(chǎn)生的命令幀發(fā)送到PNC，并且接收發(fā)送的命令幀的ACK(S901)。為此，在第一裝置的DME中產(chǎn)生MLME-CREATE-STREAM.request并將其隨后發(fā)送到MAC的MLME。如在上面的表1中所定義的，除了現(xiàn)有的參數(shù)之外，MLME-CREATE-STREAM.request還包括參數(shù)“DirectionType”。MLME產(chǎn)生用于請求信道時間的命令幀，即信道時間請求命令幀，并隨后將產(chǎn)生的命令幀經(jīng)由物理層發(fā)送到PNC。
接收到命令幀的PNC確定在當(dāng)前信道(無線通信介質(zhì))中是否有可用資源(S902)。如果確定沒有資源，則信道時間響應(yīng)命令幀的原因碼被適當(dāng)?shù)乇硎緸椤安恢С謨?yōu)先級”、“信道時間不可用”、“不能被分配為偽靜態(tài)CTA”等，并且信道時間響應(yīng)命令幀隨后被發(fā)送到第一裝置。如果確定有可用資源，則響應(yīng)于信道時間請求的命令幀，即，其原因碼被表示為“成功”的信道時間響應(yīng)命令被發(fā)送到第一裝置，并且隨后從第一裝置接收到Imm-ACK(S903)。
接下來，PNC基于在接收的信道時間請求命令幀中存在的信息產(chǎn)生信標(biāo)幀，并隨后向作為微微網(wǎng)成員的DEV廣播該信標(biāo)幀(S904)。信標(biāo)幀包括關(guān)于信道時間分配的信息，該信息依次包括CTA的時長、CTA在超級幀中的位置、用于數(shù)據(jù)識別的流索引、數(shù)據(jù)發(fā)送裝置(第一裝置)的ID、數(shù)據(jù)接收裝置(第二裝置)的ID、和用于指示數(shù)據(jù)傳輸是單向(ONE_WAY)還是雙向(TWO_WAY)的“DirectionType”。在此實(shí)施例中，“DirectionType”被設(shè)置為雙向，即“1”。接收到包含DirectionType信息的信標(biāo)幀的第一和第二裝置可以知道數(shù)據(jù)在它們之間是以雙向方式交換的。
其后，當(dāng)?shù)谝缓偷诙b置可以彼此通信的CTA的起始時間到達(dá)時(步驟S905中的“是”)，第一裝置將數(shù)據(jù)幀發(fā)送到第二裝置并隨后從第二裝置接收Imm-ACK幀(S906)。由于數(shù)據(jù)被分割成具有比最大幀長度短的長度的單位幀并隨后被發(fā)送，所以數(shù)據(jù)幀發(fā)送過程應(yīng)該被執(zhí)行兩次或多次，以發(fā)送比幀單位更長的數(shù)據(jù)。此外，為了在上面的數(shù)據(jù)被全部發(fā)送之后傳送附加數(shù)據(jù)，應(yīng)該執(zhí)行附加幀發(fā)送過程。
如果在前述數(shù)據(jù)發(fā)送過程之后沒有要由第一裝置發(fā)送的數(shù)據(jù)幀(步驟S907中的“否”)，則第一裝置向第二裝置發(fā)送指示沒有要發(fā)送的其它數(shù)據(jù)的TOKEN幀(S908)。如果接收到TOKEN幀的第二裝置也沒有要發(fā)送的數(shù)據(jù)(步驟S909中的“否”)，則第二裝置將Imm-ACK發(fā)送到第一裝置(S910)并隨后返回步驟S907。另一方面，如果有任何數(shù)據(jù)(步驟S909中的“是”)，則第二裝置將數(shù)據(jù)幀發(fā)送到第一裝置并從第一裝置接收Imm-ACK(S911)。隨后，如果有要由第二裝置發(fā)送的其它數(shù)據(jù)(步驟S912中的“是”)，則再執(zhí)行數(shù)據(jù)幀發(fā)送步驟S911。然而，如果沒有要發(fā)送的其它數(shù)據(jù)(步驟S912中的“否”)，則第二裝置將TOKEN幀發(fā)送到第一裝置(S913)。類似地，如果接收到TOKEN幀的第一裝置有要被發(fā)送的數(shù)據(jù)(步驟S914中的“是”)，則處理返回到S906。然而，如果沒有數(shù)據(jù)，則第一裝置將TOKEN幀發(fā)送到第二裝置(S915)并且處理隨后返回到步驟S912。
步驟S906至S915從相關(guān)CTA的起始時間執(zhí)行到結(jié)束時間。此外，如果在任何以上的步驟期間CTA的結(jié)束時間到達(dá)，則圖13的處理被終止。
在下文中，參照圖14和圖15比較根據(jù)現(xiàn)有技術(shù)的CTA中的單向傳輸和根據(jù)本發(fā)明的CTA中的雙向傳輸之間的傳輸效率的差別。
圖14是顯示當(dāng)根據(jù)現(xiàn)有技術(shù)進(jìn)行單向傳輸時的超級幀900的結(jié)構(gòu)以及數(shù)據(jù)傳輸過程的示圖。當(dāng)兩個裝置DEV1和DEV2存在于微微網(wǎng)上并且DEV1嘗試使用TCP/IP將流發(fā)送到DEV2時，數(shù)據(jù)幀從DEV1發(fā)送到DEV2，數(shù)據(jù)幀的ACK幀從DEV2發(fā)送到DEV1。假定MAC層中使用的ACK策略是IMM-ACK策略，超級幀時長為10ms，CAP為1ms。此外，還假定MAC頭的傳輸率是22Mbps，幀凈荷的傳輸率為55Mbps。
如果DEV1和DEV2都請求了具有比率因子1的超級速率(super-rate)CTA，則超級幀900將被圖14所示地使用。現(xiàn)在假定在如圖14所示的超級幀900中沒有除了CTA信息元素(IE)和BSID IE之外的信息元素。
信標(biāo)910包括10字節(jié)的MAC頭、21字節(jié)的微微網(wǎng)同步參數(shù)、16字節(jié)的CTA IE(因?yàn)榇耸纠哂嘘P(guān)于兩個CTA的信息)、20字節(jié)的BSID IE(假定BSID的大小是10字節(jié))。作為在下面的表3中的計算結(jié)果，發(fā)送如此構(gòu)建的信標(biāo)花費(fèi)大約0.012ms。
表3

CTA1930和CTA2 940的傳輸時長分別取決于TU(時間單位)的大小和DEV1與DEV2請求PNC發(fā)送的TU的期望數(shù)量。根據(jù)指定的ACK策略，TU應(yīng)該發(fā)送至少一幀。如果除了信標(biāo)傳輸時間和CAP 920之外的剩余時間被分配給每個DEV，則因?yàn)榧俣―EV1和DEV2都已請求了具有比率因子1的超級速率CTA，所以如圖14所示，CTA1 930和CTA2 940將被分配，在CTA1 930中，src DEV是DEV1，dest DEV是DEV2，在CTA2 940中，src DEV是DEV2，dest DEV是DEV1。根據(jù)PNC的信道時間分配算法和由每個DEV請求的TU，CTA1 930和CTA2 940的時長可被改變。
當(dāng)CTA1 930的起始時間到達(dá)時，DEV1首先將第一幀950發(fā)送到DEV2。此時，第一幀950的凈荷是TCP/IP的數(shù)據(jù)幀。由于最大幀長度是2048字節(jié)(除了MAC頭之外)，所以如下面的表4所示，如果假定第一幀950的長度為2048字節(jié)，則第一幀950的傳輸時間是0.3014ms。
表4

ACK1960是從DEV2發(fā)送到DEV1的并且是根據(jù)MAC層中的MAC的ACK策略發(fā)送的ACK幀。由于在IEEE 802.15.3中ACK幀僅由MAC頭組成，所以發(fā)送該ACK幀將花費(fèi)0.0036ms。
由于在此示例中，通過在MAC層的更高的層中的TCP/IP發(fā)送幀，所以如果DEV1沒有從DEV2接收TCP/IP等級的ACK幀，則DEV1可以不再發(fā)送新幀。當(dāng)DEV1使用TCP/IP將幀發(fā)送到DEV2時，DEV2應(yīng)該發(fā)送發(fā)送的幀的ACK幀。由于該ACK幀在MAC層的更高的層中與在MAC層中發(fā)送的ACK(例如，Imm-ACK)分開發(fā)送，所以在MAC層看來，該幀按與其它數(shù)據(jù)幀相同的方式處理。如圖14所示，第二幀表示DEV2發(fā)送到DEV1的TCP/IP等級的ACK幀。即使DEV2嘗試將第二幀發(fā)送到DEV1，DEV2也應(yīng)該等待，直到DEV2自身被分配作為src DEV的信道時間。因此，僅當(dāng)CTA2 940的起始時間到達(dá)時，第二幀970可被發(fā)送。ACK2 980是將根據(jù)MAC層的ACK策略被發(fā)送的MAC層等級的ACK幀。
如上所述，當(dāng)采用現(xiàn)有的802.15.3的CTA系統(tǒng)時，在10ms的超級幀期間，具有2048字節(jié)的大小的一幀從DEV1被發(fā)送到DEV2，反之亦然。
圖15是顯示當(dāng)根據(jù)本發(fā)明進(jìn)行雙向傳輸時的超級幀900的結(jié)構(gòu)以及數(shù)據(jù)傳輸過程的示圖。當(dāng)DEV1請求PNC分配DirectionType為TWO_WAY的信道時間時，如圖15所示配置相關(guān)超級幀。類似于圖14，也假定除了信標(biāo)傳輸時間和CAP 920之外的全部剩余時間被分配給DEV。第一幀950是將被從DEV1發(fā)送到DEV2的TCP/IP數(shù)據(jù)幀，第二幀970是將被從DEV2發(fā)送到DEV1的TCP/IP級別的ACK幀。還假定考慮直到第二幀970被發(fā)送為止被消耗的處理時間而在第一和第二幀之間發(fā)送一個NULL幀或TOKEN幀990。隨后，如下面的表5所示計算從一個TCP/IP數(shù)據(jù)幀被從DEV1發(fā)送到DEV2開始到該數(shù)據(jù)幀的TCP/IP級別的ACK幀被接收到為止所花費(fèi)的時間。
表5

因此，將通過從10ms的超級幀900減去信標(biāo)910傳輸時間和CAP 920而得到的值除以時間A，將得到在下面的表6中示出的結(jié)果。
表6

根據(jù)該結(jié)果，在單位超級幀期間，DEV1可向DEV2發(fā)送13幀，每個幀的大小為2048字節(jié)，反之亦然。當(dāng)然，如果用指定為超過1的數(shù)的CTA比率因子向PNC請求信道時間，則可發(fā)送比圖14中的數(shù)據(jù)更多的數(shù)據(jù)。然而，由于根據(jù)比率因子或者PNC的信道時間分配算法可改變信道時間分配，所以不能保證最大信道時間總是可用，采用在本發(fā)明中提出的具有DirectionType的信道時間更為有效。
產(chǎn)業(yè)上的可利用性由于源裝置和目的裝置在由現(xiàn)有的802.15.3MAC提供的信道時間中是固定的，所以在信道時間期間僅有一個裝置可發(fā)送數(shù)據(jù)而另一裝置僅應(yīng)接收數(shù)據(jù)。因此，如上所述，對于應(yīng)該根據(jù)其在裝置之間交換幀的協(xié)議，諸如TCP/IP，是沒有效率的。根據(jù)本發(fā)明，可減少這樣的低效率并從而可提高總的傳輸效率。
盡管已連同本發(fā)明的優(yōu)選實(shí)施例描述了本發(fā)明，但本領(lǐng)域的技術(shù)人員應(yīng)該理解，在不脫離本發(fā)明的范圍和精神的情況下，可對其進(jìn)行各種修改和改變。因此，應(yīng)該理解在所有的方面，以上的實(shí)施例不是限制性的，而是示例性的。本發(fā)明的范圍由所附權(quán)利要求定義而不是由本發(fā)明的詳細(xì)描述定義。得自權(quán)利要求及其等同物的所有修改和改變應(yīng)該被解釋為包括在本發(fā)明的范圍中。
權(quán)利要求
1.一種在無線個人域網(wǎng)上的裝置之間交換數(shù)據(jù)的方法，包括以下步驟(a)產(chǎn)生包含確定數(shù)據(jù)傳輸是單向和雙向之一的方向信息的信道時間請求幀，將該信道時間請求幀發(fā)送到負(fù)責(zé)信道時間分配的裝置；(b)基于在信道時間請求幀中包含的信息產(chǎn)生包含包括方向信息的信道時間分配信息的幀，并廣播產(chǎn)生的幀；和(c)根據(jù)方向信息在預(yù)定的信道時間期間，在第一和第二裝置之間交換數(shù)據(jù)，所述第一和第二裝置在包含信道時間分配信息的幀中被指定為源裝置和目的裝置。
2.如權(quán)利要求1所述的方法，其中，所述信道時間請求幀是在IEEE802.15.3中指定的信道時間請求命令幀。
3.如權(quán)利要求1所述的方法，其中，所述負(fù)責(zé)信道時間分配的裝置是在IEEE 802.15.3中指定的微微網(wǎng)協(xié)調(diào)器。
4.如權(quán)利要求1所述的方法，其中，所述包含信道時間分配信息的幀是在IEEE 802.15.3中指定的信標(biāo)幀。
5.如權(quán)利要求1所述的方法，其中，步驟(c)包括將數(shù)據(jù)從第一裝置發(fā)送到第二裝置；和當(dāng)在數(shù)據(jù)發(fā)送之后第一裝置沒有要發(fā)送的其它數(shù)據(jù)時將NULL幀發(fā)送到第二裝置。
6.如權(quán)利要求5所述的方法，其中，步驟(c)還包括如果接收到NULL幀的第二裝置有要發(fā)送到第一裝置的數(shù)據(jù)，則將該數(shù)據(jù)發(fā)送到第一裝置；和如果第二裝置沒有數(shù)據(jù)，則發(fā)送由第一裝置發(fā)送的數(shù)據(jù)的ACK幀。
7.如權(quán)利要求6所述的方法，其中，步驟(c)還包括如果接收到ACK幀的第一裝置有要發(fā)送到第二裝置的數(shù)據(jù)，則將該數(shù)據(jù)發(fā)送到第二裝置；和如果第一裝置沒有數(shù)據(jù)，則將NULL幀發(fā)送到第二裝置。
8.如權(quán)利要求6所述的方法，其中，所述ACK幀是MAC層中的中間ACK幀。
9.如權(quán)利要求5所述的方法，其中，所述NULL幀僅由MAC頭組成，并具有立即ACK策略。
10.如權(quán)利要求1所述的方法，其中，步驟(c)包括將數(shù)據(jù)從第一裝置發(fā)送到第二裝置；和當(dāng)在數(shù)據(jù)發(fā)送之后第一裝置沒有要發(fā)送的其它數(shù)據(jù)時將第一TOKEN幀發(fā)送到第二裝置。
11.如權(quán)利要求10所述的方法，其中，步驟(c)還包括如果接收到所述TOKEN幀的第二裝置有要發(fā)送到第一裝置的數(shù)據(jù)，則將該數(shù)據(jù)發(fā)送到第一裝置；和如果第二裝置沒有數(shù)據(jù)，則發(fā)送用于由第一裝置發(fā)送的數(shù)據(jù)的第二TOKEN幀。
12.如權(quán)利要求11所述的方法，其中，步驟(c)還包括如果接收到第二TOKEN幀的第一裝置有要發(fā)送到第二裝置的數(shù)據(jù)，則將該數(shù)據(jù)發(fā)送到第二裝置；和如果第一裝置沒有數(shù)據(jù)，則將TOKEN幀發(fā)送到第二裝置。
13.如權(quán)利要求10所述的方法，其中，第一TOKEN幀僅由MAC頭組成，并具有No ACK策略。
全文摘要
本發(fā)明涉及一種通過改進(jìn)在無線PAN(個人域網(wǎng))上運(yùn)行的裝置的MAC(介質(zhì)訪問控制)而在分配的信道時間內(nèi)雙向交換數(shù)據(jù)的方法和設(shè)備。本發(fā)明的所述方法包括以下步驟(1)產(chǎn)生包含確定數(shù)據(jù)傳輸是單向還是雙向的方向信息的信道時間請求幀，將該信道時間請求幀發(fā)送到負(fù)責(zé)信道時間分配的裝置；(2)基于在信道時間請求幀中包含的信息產(chǎn)生包含包括方向信息的信道時間分配信息的幀，并廣播產(chǎn)生的幀；和(3)根據(jù)方向信息在預(yù)定的信道時間期間，在第一和第二裝置之間交換數(shù)據(jù)，所述第一和第二裝置在包含信道時間分配信息的幀中被指定為源裝置和目的裝置。
文檔編號H04L12/28GK1875575SQ200480032058
公開日2006年12月6日 申請日期2004年10月18日 優(yōu)先權(quán)日2003年10月29日
發(fā)明者成玹妸, 裴大奎, 洪真佑 申請人:三星電子株式會社