CN1875575A - 在无线个人域网上的装置之间交换数据的方法 - Google Patents
在无线个人域网上的装置之间交换数据的方法 Download PDFInfo
- Publication number
- CN1875575A CN1875575A CNA2004800320589A CN200480032058A CN1875575A CN 1875575 A CN1875575 A CN 1875575A CN A2004800320589 A CNA2004800320589 A CN A2004800320589A CN 200480032058 A CN200480032058 A CN 200480032058A CN 1875575 A CN1875575 A CN 1875575A
- Authority
- CN
- China
- Prior art keywords
- frame
- data
- channel time
- send
- sent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Small-Scale Networks (AREA)
Abstract
本发明涉及一种通过改进在无线PAN(个人域网)上运行的装置的MAC(介质访问控制)而在分配的信道时间内双向交换数据的方法和设备。本发明的所述方法包括以下步骤:(1)产生包含确定数据传输是单向还是双向的方向信息的信道时间请求帧,将该信道时间请求帧发送到负责信道时间分配的装置;(2)基于在信道时间请求帧中包含的信息产生包含包括方向信息的信道时间分配信息的帧,并广播产生的帧;和(3)根据方向信息在预定的信道时间期间,在第一和第二装置之间交换数据,所述第一和第二装置在包含信道时间分配信息的帧中被指定为源装置和目的装置。
Description
技术领域
本发明涉及一种在无线网络上的装置之间执行有效的通信的方法和设备,更具体地说,涉及一种通过改进在无线PAN(个人域网)上运行的装置的MAC(介质访问控制)而在分配的信道时间期间双向交换数据的方法和设备。
背景技术
由美国国防部为军事目的而开发的UWB(超宽带),也被称为数字脉冲无线,是一种在短距离内以低功率在宽频谱的频带上发送大量数字数据的无线技术。目前正由建立了IEEE802.15.3,即无线PAN标准的工作组进行UWB的标准化。IEEE 802.15.3处理PHY(物理层)和MAC。近来,在无线电技术领域中,改进MAC的研究已变得活跃。
802.15.3MAC的特征在于迅速地建立无线网络。此外,802.15.3MAC不是基于AP(接入点),而是基于对等网络,该对等网络被称作微微网,由PNC(微微网协调器)控制。802.15.3MAC采用TDMA(时分多址)系统。如图1所示,用于在装置之间交换数据的MAC帧被实施为称作超级帧的时间结构。超级帧包括:包含控制信息的信标、用于通过退避发送数据的CAP(竞争访问周期)、和用于在分配的时间内无竞争地发送数据的CTAP(信道时间分配周期)。在它们之中,CAP可被MCTA(管理CTA)替换。目前,通过CSMA/CA(载波侦听多址接入/冲突避免)系统可在CAP中进行竞争访问,通过时隙Aloha方法可在MCTA中访问信道。
CTAP可包括多个MCTA块和多个CTA块。CTA(信道时间分配)被分为两种类型:即动态CTA和伪静态CTA。动态CTA可在每个超级帧中改变位置,但是如果超级帧的信标丢失,则所述动态CTA不能在相关超级帧中使用。另一方面,伪静态CTA在相同的固定位置上保持不变,并且即使超级帧的信标丢失,所述伪静态CTA也可在固定位置上使用。然而,如果信标连续丢失超过对应于mMaxLostBeacons的次数,则伪静态CTA不可被使用。因此,由于802.15.3MAC是基于能够保证QoS(服务质量)的TDMA系统,所以它特别适合家庭网络上的多媒体音频/视频(A/V)流。但是,MAC还应被进一步改进以有效地利用通过量以及QoS。
在802.15.3MAC中有两种数据传输方案:即,等时数据传输方案和异步数据传输方案。
在等时数据传输方案中,通过MAC子层管理实体(MLME)-CREATE-STREAM.request首先从PNC分配信道时间。如图2所示,随后通过MAC-ISOCH-DATA.request和MAC-ISOCH-DATA.confirm,在分配的信道时间期间实际发送MLME-CREATE-STREAM.confirm和数据。可以通过分析信标来获得分配的信道时间,构成微微网的装置(在下文中称为“DEV”)因此可以基于获得的信道时间知道通信开始时间和通信结束时间。这时,对于分配的信道时间指定源装置(src DEV)和目的装置(dest DEV)。在分配的信道时间内发送数据的装置必须是src DEV,但是接收数据的装置不必是在CTA信息中指定的dest DEV。然而,能够接收数据的装置是“总是唤醒位”或“对源侦听位”被设置为1的装置。
另一方面,如图3所示,在异步数据传输方案中,当要被发送的数据经由MAC-ASYNC-DATA.request到达MAC层时,src DEV将信道时间请求命令帧发送到PNC。随后,当src DEV从信标知道请求的信道时间已被分配时,在分配的信道时间期间发送数据。类似于等时数据传输方案,对于分配的信道时间指定一对src DEV和dest DEV,在分配的信道时间期间,只有指定的src DEV可以发送数据。此外,提供一种在竞争访问周期(CAP)中使用退避算法发送帧的方法,作为发送异步数据的替换方法。
为了确保数据传输的可靠性,TCP/IP被这样配置,以使DEV1将帧发送到DEV2并且DEV2将ACK帧(TCP/IP级别的ACK帧,不是如图2和图3所示的Imm-ACK帧)返回给DEV1。以下将详细描述当由802.15.3MAC提供的数据传输机制被直接使用在具有该机制的TCP/IP中时发生的问题。
首先,当TCP/IP数据被等时发送时,DEV1将向DEV2发送用于建立与DEV2的连接的帧。为此,DEV1首先向PNC发送MLME-CREATE-STREAM.request以请求信道时间分配,在该信道时间分配中,src DEV是DEV1,destDEV是DEV2。当PNC分配信道时间并发送包含关于信道时间的信息的信标时,DEV1读取关于该信标的信息并在指定时间将帧发送到DEV2。为了发送从DEV1发送的帧的响应帧,DEV2请求信道时间分配,在该信道时间分配中,src DEV是DEV2,dest DEV是DEV1。类似地,当PNC分配信道时间并发送包含关于信道时间的信息的信标时,DEV2读取关于该信标的信息并在指定时间将响应帧发送到DEV1。由于持续分配信道时间,直到接收到MLME-TERMINATE-STREAM.request,所以根据信标中的信道时间信息,在DEV1和DEV2之间交换的数据和ACK帧将在被分配给这对src DEV和destDEV的时间被发送。然而,根据TCP/IP的特点,直到发送方在发送数据帧之后接收到ACK帧,发送方才发送其它帧。在802.15.3MAC中,只有在来自信标的信道时间分配中指定的src DEV可以是信道时间的发送方。因此,在src DEV为DEV2的信道时间之后,DEV2应该发送TCP/IP级别的ACK帧。因此,尽管在DEV1发送数据之后分配给DEV1和DEV2的时间还有剩余,但是DEV1在剩余的时间期间不能从DEV2接收ACK帧,从而产生了信道时间的浪费。
其次,将讨论TCP/IP帧被异步发送的情况。当异步数据被发送到竞争访问周期时,PNC可以或者可以不将CAP分配给超级帧。此外,即使存在分配的CAP,由于在根据由PNC设置的标准的期间发生对异步数据是否可被发送的确定,所以使用CAP发送TCP/IP帧的方法也无法确保TCP/IP帧的可靠传输。接下来,为了通过信道时间分配发送异步数据,应该如上所述使用MAC-ASYNCH-DATA.request。
发明公开
技术问题
然而,如图2和图3所示,仅在信道时间请求命令已被发送到PNC并且信道时间随后被分配之后,数据帧才应被发送。这样的数据连续发送导致带宽的浪费。此外,由于即使当请求了信道时间分配时也不能保证请求的信道时间会被分配,所以每当每个数据帧被发送时,尝试发送数据的装置应该等待,直到至少下一超级帧。因此,将一直发生时延。
前述问题不仅会发生在TCP/IP中而且当在802.15.3MAC的更高层中执行在两个DEV之间交换数据的协议时也会发生。
技术解决方案
构思本发明以解决前述问题。本发明旨在通过改进802.15.3MAC(介质访问控制)而实现在更高的协议中的有效通信。为此,将提出一种除了802.15.3MAC中的单向传输之外在双向传输中使用CTA的方法。
根据实现此目标的本发明的一方面,提供一种在无线个人域网(PAN)上的装置之间交换数据的方法,包括以下步骤:(1)产生包含确定数据传输是单向还是双向的方向信息的信道时间请求帧,将该信道时间请求帧发送到负责信道时间分配的装置;(2)基于在信道时间请求帧中包含的信息产生包含包括方向信息的信道时间分配信息的帧,并广播产生的帧;和(3)根据方向信息在预定的信道时间期间,在第一和第二装置之间交换数据,所述第一和第二装置在包含信道时间分配信息的帧中被指定为源装置和目的装置。
优选地,但不是必须地,所述信道时间请求帧是在IEEE 802.15.3中指定的信道时间请求命令帧。
优选地,但不是必须地,所述负责信道时间分配的装置是在IEEE 802.15.3中指定的微微网协调器(PNC)。
优选地,但不是必须地,包含信道时间分配信息的帧是在IEEE 802.15.3中指定的信标帧。
此外,步骤(3)包括以下步骤:将数据从第一装置发送到第二装置,当在数据发送之后第一装置没有要发送的其它数据时将NULL帧发送到第二装置。
优选地,但不是必须地,在PAN上的装置之间交换数据的方法还包括以下步骤:如果接收到NULL帧的第二装置有要发送到第一装置的数据,则将该数据发送到第一装置;和如果第二装置没有数据,则发送由第一装置发送的数据的ACK帧。
优选地,但不是必须地,在PAN上的装置之间交换数据的方法还包括以下步骤:如果接收到ACK帧的第一装置有要发送到第二装置的数据,则将该数据发送到第二装置;和如果第一装置没有数据,则将NULL帧发送到第二装置。
优选地,但不是必须地,所述ACK帧是MAC层中的中间ACK帧。
优选地,但不是必须地,所述NULL帧仅由MAC头组成。
附图说明
通过下面结合附图对优选实施例进行的描述,本发明的以上和其它目的、特定和优点将会变得清楚,其中:
图1是显示相关技术的超级帧的结构的示图;
图2是显示根据现有技术请求信道时间分配的过程的示图;
图3是显示根据现有技术发送异步数据的过程的示图;
图4是显示根据本发明的信道时间请求命令帧的结构的示图;
图5是显示根据本发明的信标帧的结构的示图;
图6是显示第一示例性实施例的示图,在该第一示例性实施例中,在给定的信道时间内数据在装置之间双向地交换;
图7是显示NULL帧的结构的示图;
图8是显示各种帧的帧类型值的根据第一示例性实施例的表;
图9是示出第一示例性实施例的全部操作的流程图;
图10是显示第二示例性实施例的示图,在该第二示例性实施例中,在给定的信道时间内数据在装置之间双向地交换;
图11是显示TOKEN帧的结构的示图;
图12是显示各种帧的帧类型值的第二示例性实施例的表;
图13是示出根据本发明的第二示例性实施例的全部操作的流程图;
图14是显示根据现有技术进行单向传输的情况下的超级帧结构以及数据传输过程的示图;和
图15是显示根据本发明进行双向传输的情况下的超级帧结构以及数据传输过程的示图。
具体实施方式
在下文中,将参照附图详细描述本发明的示例性实施例。
在其中两个DEV作为发送方和接收方的角色不固定而是动态地交换的信道时间周期被增加,随后当在其中两个DEV应该如同在TCP/IP中一样交换数据的协议在更高的MAC层被执行时,向PNC(微微网协调器)请求信道时间。起向微微网中的DEV提供各种服务的作用的PNC分配信道时间,执行DEV之间的同步,并且执行使得DEV经由无线通信介质加入微微网的连接功能。
为了数据的交换,首先需要修改由802.15.3MAC提供的MLME-CREATE-STREAM.request的参数。下面的表1显示一个新参数“DirectionType”被添加至其的修改的MLME-CREATE-STREAM.Request的参数。“DirectionType”定义方向信息,该方向信息被用于确定数据传输是单向的还是双向的。
表1
MLME-CREATE-STREAM.request{ TrgtID,DSPSSetIndex,StreamRequestID,StreamIndex,ACKPolicy Priority,PNCTRqType,CTAType,CTARateType,CTARateFactor,Direction Tvpe,CTRqTU,MinNumTUs,DesiredNumTUs,RequestTimeout} |
“DirectionType”的参数如以下表2被定义。
表2
名称 | 类型 | 有效范围 | 描述 |
DirectionType | 枚举 | ONE_WAY,TWO_WAY | 指示仅有一个DEV可以成为能够发送数据的src DEV(ONE_WAY)还是两个DEV都能成为src DEV(TWO_WAY) |
假设DEV1使用TCP/IP协议将数据发送到DEV2。首先,DEV1调用MLME-CREATE-STREAM.request以从PNC请求信道时间。此时,“DirectionType”被设置为“TWO_WAY”。当DEV1的MLME接收MLME-CREATE-STREAM.request时,其将如图4所示的信道时间请求命令100发送到PNC。此时,如表1所示,用于定义“DirectionType”的位字段被添加到构成信道时间请求命令100的信道时间请求块110。尽管“DirectionType”字段分配有一个八位字节,但是因为该字段在“ONE_WAY”的情况下为“0”在“TWO_WAY”的情况下为“1”,所以对于该字段,仅仅一位信息就足够了。因此,该字段实际上仅使用1位,其余7位被保留。
当即使在PNC接收信道时间请求命令100之后通信介质的资源仍然足够时,信道时间经由信标被分配给相关DEV。图5显示信标帧200的结构、在信标帧中的至少一个“信息元素”字段的“信道时间分配信息元素”字段210的结构、以及存在于“信道时间分配信息元素”字段210中的至少一个“信道时间分配块”字段211的结构。“信道时间分配块”字段211包括:DestID字段,指示接收DEV的ID;SrcID,指示发送DEV的ID;在本发明中定义的DirectionType字段,用以指示数据发送方向是ONE_WAY还是TWO_WAY;流索引字段,指示要被发送的数据流的身份;CTA位置字段,指示CTA在超级帧中的位置;和CTA时长字段,指示CTA的时长。
在DirectionType为ONE_WAY的信道时间期间,仅是已由SrcID指定的DEV,即已发送了信道时间请求命令100的DEV可以作为发送方。这与现有的802.15.3相同。如果DirectionType为TWO_WAY的信道时间被分配,则SrcID和DestID已被分别分配至其的两个DEV都可作为发送方来在分配的信道时间期间将期望的数据发送到另一DEV。信标包括信道时间分配块211,在信道时间分配块211中,已发送了信道时间请求命令100的DEV1由SrcID指定,DEV2由DestId指定。基于信标信息,由SrcID指定的DEV1将首先成为发送方。
在下文中,图6至图9示出本发明的第一示例性实施例,图10至图13示出本发明的第二示例性实施例。
在第一示例性实施例中,当要被src DEV发送的数据没有剩余时“NULL”帧被发送,随后dest DEV可发送数据。尽管dest DEV接收到NULL帧但当没有要发送的数据时,它再次将Imm-ACK(立即ACK)发送到src DEV,从而将发送数据的机会再次移交给src DEV。因此,NULL帧的“ACK-policy”变成“Imm-ACK”。
在第二示例性实施例中,当要发送的数据没有剩余时src DEV发送“TOKEN帧”。作为响应,dest DEV可发送数据。尽管dest DEV接收到TOKEN帧但当没有要发送的数据时,它再次将TOKEN帧发送到src DEV,从而将发送数据的机会再次移交给src DEV。因此,TOKEN帧的“ACK-policy”变成“No-ACK”。
将参照图6至图9描述本发明的第一示例性实施例。
图6显示在DirectionType为TWO_WAY的信道时间期间在DEV1和DEV2之间交换数据的过程。在从信标接收信道时间分配块211之后,DEV1首先成为发送方并在指定时间将数据发送到DEV2(S10),在所述信道时间分配块211中,已发送了信道时间请求命令100的DEV1由SrcID指定,DEV2由DestID指定。DEV2根据从DEV1接收的数据帧的ACK策略发送ACK帧。在此示例中,假定使用Imm-ACK(立即ACK)策略(S20)。如果DEV1此时没有要发送的数据,则DEV1将NULL帧发送到DEV2(S30)。NULL帧是一种仅有MAC头而不存在帧体部分的帧,其结构显示在图7中。如果在步骤S30存在一些要发送的帧,则将发送数据帧而不是NULL帧。如果DEV2在接收到NULL帧时没有要发送的数据帧,则Imm-ACK被立即发送(S40)。在接收到响应于先前发送的NULL帧的Imm-ACK帧之后,如果存在要发送到DEV2的任何数据,则DEV1将数据发送到DEV2,或者如果没有数据,则DEV1将NULL帧再次发送到DEV2(S50)。当DEV2再次接收到NULL帧并且其它数据随后准备好被发送到DEV1时,数据帧而不是Imm-ACK被发送到DEV1(S60)。由于DEV1没有接收到Imm-ACK帧而是接收到响应于先前发送的NULL的数据帧,所以响应于该接收的数据帧,DEV1将Imm-ACK发送到DEV2(S70)。如果接收到所述Imm-ACK的DEV2还有数据,则DEV2继续发送数据。否则,DEV2将NULL帧发送到DEV1(S80)。如果DEV1没有要在此时发送的数据帧,则其将Imm-ACK发送到DEV2(S90)。重复以上过程直到分配给这两个DEV的信道时间结束。
图7显示本发明提出的“NULL帧”的详细结构。NULL帧对应于只有MAC头而没有帧体的帧,并且与传统MAC头相同,NULL帧的大小为10个八位字节。NULL帧的每个字段的大小为1个八位字节。这里,帧类型字段710是NULL帧的类型值被记录在其中的字段。图8显示在其中定义了各种字段帧的类型值的表。这些类型值被记录在MAC头的b5、b4和b3位中,并且根据以上的位的组合指示相关帧是什么帧。例如,“000”指的是信标帧,“001”指的是Imm-ACK帧。此外,在现有的IEEE 802.15.3中指定了各种类型的值,诸如延迟ACK帧(值=“010”)、命令帧(值=“011”)和数据帧(值=“100”)。在本发明中,添加了新的类型的值NULL帧,其被指定为“101”。
再次参考图7,根据ACK策略的ACK帧的类型值被记录在ACK策略字段720中。根据IEEE 802.15.3,ACK帧的类型值被记录在MAC头的b8和b7位中,其中,“NO ACK”的值为“00”,“立即ACK”的值为“01”,“延迟ACK”的值为“10”。因此,在此实施例中,ACK策略字段的值为“01”。此外,发送相关NULL帧的DEV的ID被记录在DestID字段730中,接收相关NULL帧的DEV的ID被记录在SrcID字段740中。而且,MAC头的所有字段的值变为“0”。
图9是示出本发明的全部操作的流程图。
首先,第一装置产生信道时间请求命令帧,将该产生的命令帧发送到PNC,并且接收发送的命令帧的ACK(S801)。为此,在第一装置的DME(装置管理实体)产生MLME-CREATE-STREAM.request并将其随后发送到MAC的MLME。如在上面的表1中所定义的,除了现有的参数之外,MLME-CREATE-STREAM.request还包括参数“DirectionType”。MLME产生用于请求信道时间的命令帧,即信道时间请求命令帧,并随后将产生的命令帧经由物理层发送到PNC。
接收到命令帧的PNC确定在当前信道(无线通信介质)中是否有可用资源(S802)。如果确定没有可用资源,则信道时间响应命令帧的原因码被适当地表示为“不支持优先级”、“信道时间不可用”、“不能被分配为伪静态CTA”等,并且信道时间响应命令帧随后被发送到第一装置。如果确定有可用资源,则响应于信道时间请求的命令帧,即,其原因码被表示为“成功”的信道时间响应命令帧被发送到第一装置,并且随后从第一装置接收到Imm-ACK(S803)。
接下来,PNC基于在接收的信道时间请求命令帧中存在的信息产生信标帧,并随后向作为微微网成员的DEV广播该信标帧(S804)。信标帧包括关于信道时间分配的信息,该信息依次包括:CTA的时长、CTA在超级帧中的位置、用于数据识别的流索引、数据发送装置(第一装置)的ID、数据接收装置(第二装置)的ID、和用于指示数据传输是单向(ONE_WAY)还是双向(TWO_WAY)的“DirectionType”。在此实施例中,“DirectionType”被设置为双向,即“1”。接收到包含DirectionType信息的信标帧的第一和第二装置可以知道数据在它们之间是以双向方式交换的。
其后,当第一和第二装置可以彼此通信的CTA的起始时间到达时(步骤S805中的“是”),第一装置将数据帧发送到第二装置并随后从第二装置接收Imm-ACK帧(S806)。由于数据被分割成具有比最大帧长度短的长度的单位帧并随后被发送,所以数据帧发送过程应该被执行两次或多次,以发送比帧单位更长的数据。此外,为了在上面的数据被全部发送之后传送附加数据,应该执行附加帧发送过程。
如果在前述数据发送过程之后没有要由第一装置发送的数据帧(步骤S807中的“否”),则第一装置向第二装置发送指示没有要发送的其它数据的NULL帧(S808)。
如果接收到NULL帧的第二装置也没有要发送的数据(步骤S809中的“否”),则第二装置将Imm-ACK发送到第一装置(S810)并返回步骤S807。另一方面,如果有任何数据(步骤S809中的“是”),则第二装置将数据帧发送到第一装置并从第一装置接收Imm-ACK(S811)。随后,如果有要由第二装置发送的其它数据(步骤S812中的“是”),则再执行数据帧发送步骤S811。然而,如果没有要发送的其它数据(步骤S812中的“否”),则第二装置将NULL帧发送到第一装置(S813)。类似地,如果接收到NULL帧的第一装置有要被发送的数据(步骤S814中的“是”),则处理返回到S806。然而,如果没有数据,则第一装置将Imm-ACK发送到第二装置(S815)并且处理随后返回到步骤S812。
步骤S806至S815从相关CTA的起始时间执行到结束时间。此外,如果在任何以上的步骤期间CTA的结束时间到达,则图9的处理被终止。
在下文中,将参照附图10至图13描述本发明的第二示例性实施例。
图10显示在DirectionType为TWO_WAY的信道时间期间在DEV1和DEV2之间交换数据的过程。在从信标接收到在其中已发送信道时间请求命令100的DEV1由SrcID指定并且DEV2由DestID指定的信道时间分配块211之后,DEV1首先成为发送方并在指定时间将数据发送到DEV2(S110)。DEV2根据从DEV1接收的数据帧的ACK策略发送ACK帧。在此示例中假定是Imm-ACK(立即ACK)策略(S120)。如果此时DEV1没有要发送的数据,则DEV1将TOKEN帧发送到DEV2(S130)。TOKEN帧是一种只有MAC头而没有帧体部分的帧,其结构显示在图11中。在步骤S130中,如果有一些要发送的帧,则发送数据帧而不是TOKEN帧。如果DEV2在接收到TOKEN帧的时候没有要发送的数据帧,则另一TOKEN帧被立即发送(S140)。在接收到响应于先前发送的TOKEN帧的TOKEN帧之后,如果存在任何要发送到DEV2的数据,则DEV1将数据发送到DEV2,或者如果没有数据,则DEV1将TOKEN帧再次发送到DEV2(S150)。当DEV2再次接收到TOKEN帧并且其它数据随后作好发送到DEV1的准备时,数据帧而不是TOKEN帧被发送到DEV1(S160)。由于DEV1接收到响应于先前发送的TOKEN帧的数据帧,所以DEV1向DEV2发送Imm-ACK帧以响应接收的数据帧(S170)。如果接收Imm-ACK的DEV2还有数据,则DEV2继续发送数据。否则DEV2将TOKEN帧发送到DEV1(S180)。重复以上过程直到分配给这两个DEV的信道时间结束。
图11显示本发明中提出的“TOKEN帧”的详细结构。TOKEN帧对应于只有MAC头而没有帧体的帧,并且与传统MAC头相同,TOKEN帧的大小为10个八位字节。TOKEN帧的每个字段的大小为1个八位字节。这里,帧类型字段710是TOKEN帧的类型值被记录在其中的字段。图12显示在其中定义了各种字段帧的类型值的表。这些类型值被记录在MAC头的b5、b4和b3位中,并且根据以上的位的组合指示相关帧是什么帧。例如,“000”指的是信标帧,“001”指的是Imm-ACK帧。此外,在现有的IEEE 802.15.3中指定了各种类型的值,诸如延迟ACK帧(值=“010”)、命令帧(值=“011”)和数据帧(值=“100”)。在本发明中,添加了新的类型的值TOKEN帧,其被指定为“101”。
再次参考图11,根据ACK策略的ACK帧的类型值被记录在ACK策略字段720中。根据IEEE 802.15.3,ACK帧的类型值被记录在MAC头的b8和b7位中,其中,“NO ACK”的值为“00”,“立即ACK”的值为“01”,“延迟ACK”的值为“10”。因此,在此实施例中,ACK策略字段的值为“00”。此外,发送相关TOKEN帧的DEV的ID被记录在DestID字段730中,接收相关TOKEN帧的DEV的ID被记录在SrcID字段740中。而且,MAC头的所有字段的值变为“0”。
图13是示出本发明第二实施例的全部操作的流程图。
首先,第一装置产生信道时间请求命令帧,将该产生的命令帧发送到PNC,并且接收发送的命令帧的ACK(S901)。为此,在第一装置的DME中产生MLME-CREATE-STREAM.request并将其随后发送到MAC的MLME。如在上面的表1中所定义的,除了现有的参数之外,MLME-CREATE-STREAM.request还包括参数“DirectionType”。MLME产生用于请求信道时间的命令帧,即信道时间请求命令帧,并随后将产生的命令帧经由物理层发送到PNC。
接收到命令帧的PNC确定在当前信道(无线通信介质)中是否有可用资源(S902)。如果确定没有资源,则信道时间响应命令帧的原因码被适当地表示为“不支持优先级”、“信道时间不可用”、“不能被分配为伪静态CTA”等,并且信道时间响应命令帧随后被发送到第一装置。如果确定有可用资源,则响应于信道时间请求的命令帧,即,其原因码被表示为“成功”的信道时间响应命令被发送到第一装置,并且随后从第一装置接收到Imm-ACK(S903)。
接下来,PNC基于在接收的信道时间请求命令帧中存在的信息产生信标帧,并随后向作为微微网成员的DEV广播该信标帧(S904)。信标帧包括关于信道时间分配的信息,该信息依次包括:CTA的时长、CTA在超级帧中的位置、用于数据识别的流索引、数据发送装置(第一装置)的ID、数据接收装置(第二装置)的ID、和用于指示数据传输是单向(ONE_WAY)还是双向(TWO_WAY)的“DirectionType”。在此实施例中,“DirectionType”被设置为双向,即“1”。接收到包含DirectionType信息的信标帧的第一和第二装置可以知道数据在它们之间是以双向方式交换的。
其后,当第一和第二装置可以彼此通信的CTA的起始时间到达时(步骤S905中的“是”),第一装置将数据帧发送到第二装置并随后从第二装置接收Imm-ACK帧(S906)。由于数据被分割成具有比最大帧长度短的长度的单位帧并随后被发送,所以数据帧发送过程应该被执行两次或多次,以发送比帧单位更长的数据。此外,为了在上面的数据被全部发送之后传送附加数据,应该执行附加帧发送过程。
如果在前述数据发送过程之后没有要由第一装置发送的数据帧(步骤S907中的“否”),则第一装置向第二装置发送指示没有要发送的其它数据的TOKEN帧(S908)。如果接收到TOKEN帧的第二装置也没有要发送的数据(步骤S909中的“否”),则第二装置将Imm-ACK发送到第一装置(S910)并随后返回步骤S907。另一方面,如果有任何数据(步骤S909中的“是”),则第二装置将数据帧发送到第一装置并从第一装置接收Imm-ACK(S911)。随后,如果有要由第二装置发送的其它数据(步骤S912中的“是”),则再执行数据帧发送步骤S911。然而,如果没有要发送的其它数据(步骤S912中的“否”),则第二装置将TOKEN帧发送到第一装置(S913)。类似地,如果接收到TOKEN帧的第一装置有要被发送的数据(步骤S914中的“是”),则处理返回到S906。然而,如果没有数据,则第一装置将TOKEN帧发送到第二装置(S915)并且处理随后返回到步骤S912。
步骤S906至S915从相关CTA的起始时间执行到结束时间。此外,如果在任何以上的步骤期间CTA的结束时间到达,则图13的处理被终止。
在下文中,参照图14和图15比较根据现有技术的CTA中的单向传输和根据本发明的CTA中的双向传输之间的传输效率的差别。
图14是显示当根据现有技术进行单向传输时的超级帧900的结构以及数据传输过程的示图。当两个装置DEV1和DEV2存在于微微网上并且DEV1尝试使用TCP/IP将流发送到DEV2时,数据帧从DEV1发送到DEV2,数据帧的ACK帧从DEV2发送到DEV1。假定MAC层中使用的ACK策略是IMM-ACK策略,超级帧时长为10ms,CAP为1ms。此外,还假定MAC头的传输率是22Mbps,帧净荷的传输率为55Mbps。
如果DEV1和DEV2都请求了具有比率因子1的超级速率(super-rate)CTA,则超级帧900将被图14所示地使用。现在假定在如图14所示的超级帧900中没有除了CTA信息元素(IE)和BSID IE之外的信息元素。
信标910包括10字节的MAC头、21字节的微微网同步参数、16字节的CTA IE(因为此示例具有关于两个CTA的信息)、20字节的BSID IE(假定BSID的大小是10字节)。作为在下面的表3中的计算结果,发送如此构建的信标花费大约0.012ms。
表3
头传输时间:(10×8bits)×1000ms/22Mbps=0.0036ms,净荷传输时间:(21+16+20)× 8bits×1000ms/55Mbps=0.0082ms |
CTA1930和CTA2 940的传输时长分别取决于TU(时间单位)的大小和DEV1与DEV2请求PNC发送的TU的期望数量。根据指定的ACK策略,TU应该发送至少一帧。如果除了信标传输时间和CAP 920之外的剩余时间被分配给每个DEV,则因为假定DEV1和DEV2都已请求了具有比率因子1的超级速率CTA,所以如图14所示,CTA1 930和CTA2 940将被分配,在CTA1 930中,src DEV是DEV1,dest DEV是DEV2,在CTA2 940中,src DEV是DEV2,dest DEV是DEV1。根据PNC的信道时间分配算法和由每个DEV请求的TU,CTA1 930和CTA2 940的时长可被改变。
当CTA1 930的起始时间到达时,DEV1首先将第一帧950发送到DEV2。此时,第一帧950的净荷是TCP/IP的数据帧。由于最大帧长度是2048字节(除了MAC头之外),所以如下面的表4所示,如果假定第一帧950的长度为2048字节,则第一帧950的传输时间是0.3014ms。
表4
(MAC头传输时间)+(2048×8bits)×1000ms/55Mbps=0.0036ms+0.2979ms=0.3014ms |
ACK1960是从DEV2发送到DEV1的并且是根据MAC层中的MAC的ACK策略发送的ACK帧。由于在IEEE 802.15.3中ACK帧仅由MAC头组成,所以发送该ACK帧将花费0.0036ms。
由于在此示例中,通过在MAC层的更高的层中的TCP/IP发送帧,所以如果DEV1没有从DEV2接收TCP/IP等级的ACK帧,则DEV1可以不再发送新帧。当DEV1使用TCP/IP将帧发送到DEV2时,DEV2应该发送发送的帧的ACK帧。由于该ACK帧在MAC层的更高的层中与在MAC层中发送的ACK(例如,Imm-ACK)分开发送,所以在MAC层看来,该帧按与其它数据帧相同的方式处理。如图14所示,第二帧表示DEV2发送到DEV1的TCP/IP等级的ACK帧。即使DEV2尝试将第二帧发送到DEV1,DEV2也应该等待,直到DEV2自身被分配作为src DEV的信道时间。因此,仅当CTA2 940的起始时间到达时,第二帧970可被发送。ACK2 980是将根据MAC层的ACK策略被发送的MAC层等级的ACK帧。
如上所述,当采用现有的802.15.3的CTA系统时,在10ms的超级帧期间,具有2048字节的大小的一帧从DEV1被发送到DEV2,反之亦然。
图15是显示当根据本发明进行双向传输时的超级帧900的结构以及数据传输过程的示图。当DEV1请求PNC分配DirectionType为TWO_WAY的信道时间时,如图15所示配置相关超级帧。类似于图14,也假定除了信标传输时间和CAP 920之外的全部剩余时间被分配给DEV。第一帧950是将被从DEV1发送到DEV2的TCP/IP数据帧,第二帧970是将被从DEV2发送到DEV1的TCP/IP级别的ACK帧。还假定考虑直到第二帧970被发送为止被消耗的处理时间而在第一和第二帧之间发送一个NULL帧或TOKEN帧990。随后,如下面的表5所示计算从一个TCP/IP数据帧被从DEV1发送到DEV2开始到该数据帧的TCP/IP级别的ACK帧被接收到为止所花费的时间。
表5
A=第一帧传输时间+SIFS+ACK1传输时间+SIFS+NULL帧(或TOKEN帧)传输时间+SIFS+第二帧传输时间+SIFS+ACK2传输时间+SIFS=0.3015ms+0.01ms+0.0036ms+0.01ms+0.0036ms+0.01ms+0.3015ms+0.01ms+0.0036ms+0.01ms=0.6638ms |
因此,将通过从10ms的超级帧900减去信标910传输时间和CAP 920而得到的值除以时间A,将得到在下面的表6中示出的结果。
表6
(10-0.012-0.01-1)/0.6638≈13 |
根据该结果,在单位超级帧期间,DEV1可向DEV2发送13帧,每个帧的大小为2048字节,反之亦然。当然,如果用指定为超过1的数的CTA比率因子向PNC请求信道时间,则可发送比图14中的数据更多的数据。然而,由于根据比率因子或者PNC的信道时间分配算法可改变信道时间分配,所以不能保证最大信道时间总是可用,采用在本发明中提出的具有DirectionType的信道时间更为有效。
产业上的可利用性
由于源装置和目的装置在由现有的802.15.3MAC提供的信道时间中是固定的,所以在信道时间期间仅有一个装置可发送数据而另一装置仅应接收数据。因此,如上所述,对于应该根据其在装置之间交换帧的协议,诸如TCP/IP,是没有效率的。根据本发明,可减少这样的低效率并从而可提高总的传输效率。
尽管已连同本发明的优选实施例描述了本发明,但本领域的技术人员应该理解,在不脱离本发明的范围和精神的情况下,可对其进行各种修改和改变。因此,应该理解在所有的方面,以上的实施例不是限制性的,而是示例性的。本发明的范围由所附权利要求定义而不是由本发明的详细描述定义。得自权利要求及其等同物的所有修改和改变应该被解释为包括在本发明的范围中。
Claims (13)
1、一种在无线个人域网上的装置之间交换数据的方法,包括以下步骤:
(a)产生包含确定数据传输是单向和双向之一的方向信息的信道时间请求帧,将该信道时间请求帧发送到负责信道时间分配的装置;
(b)基于在信道时间请求帧中包含的信息产生包含包括方向信息的信道时间分配信息的帧,并广播产生的帧;和
(c)根据方向信息在预定的信道时间期间,在第一和第二装置之间交换数据,所述第一和第二装置在包含信道时间分配信息的帧中被指定为源装置和目的装置。
2、如权利要求1所述的方法,其中,所述信道时间请求帧是在IEEE802.15.3中指定的信道时间请求命令帧。
3、如权利要求1所述的方法,其中,所述负责信道时间分配的装置是在IEEE 802.15.3中指定的微微网协调器。
4、如权利要求1所述的方法,其中,所述包含信道时间分配信息的帧是在IEEE 802.15.3中指定的信标帧。
5、如权利要求1所述的方法,其中,步骤(c)包括:
将数据从第一装置发送到第二装置;和
当在数据发送之后第一装置没有要发送的其它数据时将NULL帧发送到第二装置。
6、如权利要求5所述的方法,其中,步骤(c)还包括:
如果接收到NULL帧的第二装置有要发送到第一装置的数据,则将该数据发送到第一装置;和
如果第二装置没有数据,则发送由第一装置发送的数据的ACK帧。
7、如权利要求6所述的方法,其中,步骤(c)还包括:
如果接收到ACK帧的第一装置有要发送到第二装置的数据,则将该数据发送到第二装置;和
如果第一装置没有数据,则将NULL帧发送到第二装置。
8、如权利要求6所述的方法,其中,所述ACK帧是MAC层中的中间ACK帧。
9、如权利要求5所述的方法,其中,所述NULL帧仅由MAC头组成,并具有立即ACK策略。
10、如权利要求1所述的方法,其中,步骤(c)包括:
将数据从第一装置发送到第二装置;和
当在数据发送之后第一装置没有要发送的其它数据时将第一TOKEN帧发送到第二装置。
11、如权利要求10所述的方法,其中,步骤(c)还包括:
如果接收到所述TOKEN帧的第二装置有要发送到第一装置的数据,则将该数据发送到第一装置;和
如果第二装置没有数据,则发送用于由第一装置发送的数据的第二TOKEN帧。
12、如权利要求11所述的方法,其中,步骤(c)还包括:
如果接收到第二TOKEN帧的第一装置有要发送到第二装置的数据,则将该数据发送到第二装置;和
如果第一装置没有数据,则将TOKEN帧发送到第二装置。
13、如权利要求10所述的方法,其中,第一TOKEN帧仅由MAC头组成,并具有No ACK策略。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR10-2003-0076034 | 2003-10-29 | ||
KR20030076034 | 2003-10-29 | ||
KR1020030076034 | 2003-10-29 | ||
KR1020040049655A KR100772855B1 (ko) | 2003-10-29 | 2004-06-29 | 무선 pan상에서 디바이스 간에 효율적으로 데이터를송수신하는 방법 |
KR1020040049655 | 2004-06-29 | ||
KR10-2004-0049655 | 2004-06-29 | ||
PCT/KR2004/002663 WO2005041488A1 (en) | 2003-10-29 | 2004-10-18 | Method for exchanging data between devices on wireless personal area network |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1875575A true CN1875575A (zh) | 2006-12-06 |
CN1875575B CN1875575B (zh) | 2011-05-11 |
Family
ID=37242459
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2004800320589A Expired - Fee Related CN1875575B (zh) | 2003-10-29 | 2004-10-18 | 在无线个人域网上的装置之间交换数据的方法 |
Country Status (2)
Country | Link |
---|---|
KR (1) | KR100772855B1 (zh) |
CN (1) | CN1875575B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011023068A1 (zh) * | 2009-08-27 | 2011-03-03 | 中兴通讯股份有限公司 | 一种个人网设备获取业务内容的装置、方法及相关装置 |
CN101394249B (zh) * | 2007-09-19 | 2011-05-04 | 华为技术有限公司 | 传输控制方法、传输方法及装置 |
CN101795500B (zh) * | 2008-12-31 | 2014-04-09 | 英特尔公司 | 本地个域网上的移动设备中的社交联网和广告 |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100868474B1 (ko) * | 2006-12-04 | 2008-11-12 | 한국전자통신연구원 | 개인 무선 통신망에서의 타이머를 이용한 방송형 데이터수신 방법 |
KR100999686B1 (ko) | 2008-04-25 | 2010-12-08 | 금오공과대학교 산학협력단 | 하이브리드 네트워크를 위한 실시간 동기화 방법 |
US8917655B2 (en) | 2008-07-11 | 2014-12-23 | Samsung Electronics Co., Ltd. | Method and apparatus for allowing device supporting multiple PHY communication mode to communicate with device in wireless personal area network |
US8780869B2 (en) | 2009-04-15 | 2014-07-15 | Qualcomm Incorporated | Method and apparatus for efficient association procedure |
KR101995578B1 (ko) * | 2015-07-09 | 2019-10-01 | 한국전자통신연구원 | 무선 통신 방법 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2002362420A1 (en) * | 2001-10-03 | 2003-04-14 | Xtremespectrum, Inc. | Method of operating a media access controller |
ATE334531T1 (de) * | 2001-11-28 | 2006-08-15 | Freescale Semiconductor Inc | System und verfahren zur kommunikation zwischen mehreren punktkoordinierten drahtlosen netzwerken |
CA2474252A1 (en) * | 2002-01-22 | 2003-07-31 | Knut Odman | Method for transmission of isochronous and asynchronous data in a radio network |
-
2004
- 2004-06-29 KR KR1020040049655A patent/KR100772855B1/ko not_active IP Right Cessation
- 2004-10-18 CN CN2004800320589A patent/CN1875575B/zh not_active Expired - Fee Related
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101394249B (zh) * | 2007-09-19 | 2011-05-04 | 华为技术有限公司 | 传输控制方法、传输方法及装置 |
CN101795500B (zh) * | 2008-12-31 | 2014-04-09 | 英特尔公司 | 本地个域网上的移动设备中的社交联网和广告 |
WO2011023068A1 (zh) * | 2009-08-27 | 2011-03-03 | 中兴通讯股份有限公司 | 一种个人网设备获取业务内容的装置、方法及相关装置 |
Also Published As
Publication number | Publication date |
---|---|
KR100772855B1 (ko) | 2007-11-02 |
KR20050040692A (ko) | 2005-05-03 |
CN1875575B (zh) | 2011-05-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7122702B2 (ja) | 無線局、通信方法および集積回路 | |
US7489656B2 (en) | Bandwidth allocation | |
EP1528733A2 (en) | Method for exchanging data between devices on a wireless personal area network (WPAN) | |
CN1744553A (zh) | 在分配的信道时间期间源装置和目的装置间双向通信方法 | |
KR100555927B1 (ko) | 개인영역 네트워크에서 tcp 스트림의 전송방법 | |
KR101272965B1 (ko) | 메쉬 네트워크에서 멀티 채널을 이용한 전력 절약 방법 및장치 | |
JP4467619B2 (ja) | ワイヤレス通信ネットワークにおけるストリーム処理技術 | |
JP7072681B2 (ja) | トリガベースのマルチユーザ送信におけるダイレクトリンク及びダウンリンク送信に準拠した無線局のmac/phyインタフェース | |
CN1744609A (zh) | 在分配的时间期间双向发送和接收数据的方法及设备 | |
JP5080064B2 (ja) | 無線ネットワーク装置及びこれのためのリソース割当方法 | |
KR20070008587A (ko) | 호스트-디바이스 통신 방법 및 호스트 장치 | |
JP2005198305A (ja) | 無線個人領域ネットワークにおけるチャネル時間割当て方法 | |
US8340053B2 (en) | Wireless sensor network and method for performing communication therein | |
WO2010018523A2 (en) | Techniques for efficient data transfers in a body area network | |
JP7316427B2 (ja) | トリガに基づくマルチユーザ送信における直接リンク及び下りリンク送信 | |
US20220408409A1 (en) | Method and apparatus for choosing transmission parameters values in a multi-user transmission | |
US20140119257A1 (en) | Mac protocol in wireless body area network capable of processing emergency data and wireless network communication method using same | |
TWI337816B (en) | Apparatus and method for providing notification of allocation of communication resources in a radio communication system | |
JP5864254B2 (ja) | ワイヤレスネットワークの空間再利用を改善する技法 | |
EP4183208A1 (en) | Buffer status report signaling both buffered uplink traffic and buffered direct link traffic | |
JP4064394B2 (ja) | 周波数ホッピング方式のマルチバンド超広域通信方法 | |
CN1875575A (zh) | 在无线个人域网上的装置之间交换数据的方法 | |
JP5329555B2 (ja) | スケジューリング・アルゴリズムをバックグランド・アルゴリズムとフォアグランド・アルゴリズムとに分割すること | |
CN106658747B (zh) | 基于时段精简的太赫兹无线个域网公平接入方法 | |
TW201010487A (en) | A group shared distributed reservation protocol |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110511 Termination date: 20141018 |
|
EXPY | Termination of patent right or utility model |