[go: up one dir, main page]

JP2006054897A - 移動通信システムにおけるパケット受信結果報告方法 - Google Patents

移動通信システムにおけるパケット受信結果報告方法 Download PDF

Info

Publication number
JP2006054897A
JP2006054897A JP2005233762A JP2005233762A JP2006054897A JP 2006054897 A JP2006054897 A JP 2006054897A JP 2005233762 A JP2005233762 A JP 2005233762A JP 2005233762 A JP2005233762 A JP 2005233762A JP 2006054897 A JP2006054897 A JP 2006054897A
Authority
JP
Japan
Prior art keywords
packet
packets
bitmap
fragment
received
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
Application number
JP2005233762A
Other languages
English (en)
Other versions
JP4319654B2 (ja
Inventor
Keikun Cho
張 景訓
Jong-Ae Park
朴 鍾愛
Dong-Jun Lee
東俊 李
Jin-Bong Chang
眞逢 張
Young-Soo Kim
泳秀 金
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from KR1020040064049A external-priority patent/KR101075722B1/ko
Priority claimed from KR1020050044645A external-priority patent/KR100703501B1/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2006054897A publication Critical patent/JP2006054897A/ja
Application granted granted Critical
Publication of JP4319654B2 publication Critical patent/JP4319654B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809Selective-repeat protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

【課題】 本発明は、パケットの受信結果通報を充実に行いながらも、受信結果による情報が書込まれるフィールド(ビットマップフィールド)の大きさを著しく低減できるだけでなく、最適化できるビットマップ構造を提案する。
【解決手段】 このために、本発明は、ブロックACKで処理可能な最大許容パケットの各々に対して受信失敗の可否を確認できる識別子が書込まれるメッセージ領域を割り当てる。そして、受信失敗したパケットに対する受信結果のみが書込まれるようにメッセージ領域を割り当てる。受信側では、識別子により受信失敗したパケットを確認し、前記パケットに対する受信結果により受信失敗したパケットを再転送する。
【選択図】 図5

Description

本発明は移動通信システムにおける再転送技法の適用によるパケット受信結果を報告するためのビットマップ構造及びパケット受信結果を送受信するための方法に関する。
通常、無線チャンネルでは、多重経路フェーディング及びユーザー間の干渉やノイズ等により、転送されたパケットにエラーが発生する恐れがある。これを解決するための方法として、FEC(Forward Error Correction Code)方式、ARQ(Automatic Repeat Request)方式及び両方を結合したH−ARQ方式等がある。FEC方式は剰余の情報をさらに転送してエラー発生率を低減し、ARQ方式はエラー発生時にエラーの発生したパケットを再転送するように要請する。
ARQ方式では、ACK(AcKnowledgement)/NACK(NotAcKnowledgement)信号を使用する。ACK/NACK信号は、受信機が受信パケットにエラーがあるか否かを送信機に通知するために使用される。送信機は、ACK信号により受信機が当該パケットを受信したことを確認したり、NACK信号により受信機が当該パケットの受信に失敗したことを確認する。送信機は、NACK信号を受信すると、当該パケットを再転送する。
ARQ方式には、転送パケット別に受信結果が通報される一般のACK方式の以外に、ブロックACK方式がある。ブロックACK方式は、転送された複数のパケットに対する受信結果をブロックACKメッセージを通してグループに通報される方式である。
図1は、一般のブロックACK方式の基本概念を説明するための図であって、3つのパケット単位にブロックACK方式を適用した例を仮定している。
図1を参照すれば、送信機は3つのパケット(Packet#1、Packet#2、Packet#3)を順次転送する。3つのパケット(Packet#1、Packet#2、Packet#3)は同じDA(Destination Address)(一例としてDA2)を持つ。3つのパケット(Packet#1、Packet#2、Packet#3)の各々に対しては、SN(Sequence Number)及びFN(Fragmentation Number)が付与される。SNは上位階層からパケットが伝達される順序を意味する。同じSNを持つパケットであっても、必要に応じて複数のパケットに分割転送できる。FNは同じSNを持つパケットから分割された複数のパケットの転送順序を意味する。
受信機では、受信したパケットのSN、FNを以前に受信したパケットのSN、FNと比較することで、連続受信及び未受信のパケットを確認する。後述する説明では、SNレベルでのパケットを“SNレベルパケット”といい、SNレベルパケットから分割されたパケットを“フラグメントパケット(Fragmentation Packet)”という。SNレベルパケット或いはフラグメントパケットではなく“パケット”という場合は、前述した2類の形態のうちの一つを意味する。
3つのパケットのうち、第1及び第2パケット(Packet#1、Packet#2)は、同じSN(一例としてSN1)及び異なるFN(一例としてFrag1、Frag2)を持つフラグメントパケットである。第3パケット(Packet#3)は、第1及び第2パケット(Packet#1、Packet#2)と異なるSN(一例としてSN2)を持つSNレベルパケットである。
図1では、受信機により、第1及び第3パケット(Packet#1、Packet#3)の受信成功を、第2パケット(Packet#2)の受信失敗を例示している。
受信機は、前記受信結果に基づき、ブロックACKメッセージを構成して送信機に転送する。ブロックACKメッセージは、ヘッダとペイロードからなる。ヘッダには目的地アドレスDA1が書込まれる。目的地アドレスDA1は送信機のアドレスである。ペイロードには受信したパケットの各々に対する受信結果が書込まれる。
先の仮定を適用すれば、第1及び第3パケット(Packet#1、Packet#3)に対応する受信結果はACK情報が書込まれ、第2パケット(Packet#2)に対応する受信結果はNACK情報が書込まれる。受信結果には当該パケットのSNとFNとも書込まれる。
送信機はブロックACKメッセージを受信する。送信機は、ブロックACKメッセージにより、第1及び第3パケット(Packet#1、Packet#3)の正常受信を、第2パケット(Packet#2)の受信失敗を確認する。以後、図1では示さないが、送信機は第2パケット(Packet#2)を再転送する。
前述したように、一つのブロックACKメッセージに受信された全てのパケットに対する受信結果を書込む方法は、多様に具現できる。しかし、最小の長さのメッセージを使用するためにビットマップ方式が用いられる。
図2乃至図4は、ビットマップ(Bitmap)を用いて、受信結果を通報する例を示す図である。
図2を参照すれば、ブロックACKメッセージは、ブロックACK開始シーケンス(Block ACK Starting Sequence)フィールドとビットマップフィールドからなる。ビットマップフィールドはN個のACKリポートフィールドからなる。Nは最大SNに対応する値であって、ACK可能な最大シーケンスの個数を意味する。すなわち、Nは一つのブロックACKで処理可能なSNレベルパケットの最大許容個数として定義される。
ブロックACK開始シーケンスフィールドには、当該メッセージ内のビットマップが取扱う最初のSNレベルパケットのSNが書込まれる。ビットマップフィールドには、ブロックACK開始シーケンスフィールドに書込まれたSNを持つパケットから始まる連続するN個のパケットの各々に対する受信結果が書込まれる。
ビットマップフィールドを構成する各ACKリポートフィールドは、一つのSNレベルパケットから最大限に分割可能なフラグメントパケットの数(M×8)だけの領域(b0、b1、b2、…、b(n)、…、b(8×M−1)に区分される。以下、領域(b0、b1、b2、…、b(n)、…、b(8×M−1))を“受信結果情報フィールド”という。これは受信結果がフラグメントパケット別に通報されるためである。よって、前記受信結果が1ビットで表現されるとすれば、一つのSNレベルパケットに対する全ての受信結果情報フィールドとしてはMオクテット(octet)が必要である。そして、ビットマップフィールドの全体の長さはM×Nオクテットとなる。
例えば、ブロックACK開始シーケンスフィールドにSN1が書込まれると、SNが1でFNがn−1であるフラグメントパケットに対する受信結果は受信結果情報フィールドb(n)210に書込まれる。フラグメントパケットの受信成功であれば、受信結果情報フィールドb(n)210には“1”が書込まれ、フラグメントパケットの受信失敗であれば、受信結果情報フィールドb(n)210には“0”が書込まれる。これは、“1”は受信成功を、“0”は受信失敗を示す識別ビットであることを仮定する。他の例として、ブロックACK開始シーケンスフィールドに“5”が書込まれると、SNが6でFNが3であるフラグメントパケットが受信成功した場合、2番目のオクテットの3番目のビットを1にセッティングする。
図3は、前述した一般例をIEEE802.16標準を基にするシステムに適用した例を示し、図4は前述した一般例をIEEE802.11e標準を基にするシステムに適用した例を示す。
図3に示すブロックACKメッセージは、連結識別子(ConnectionID)フィールド、ACK制御(ACK Control)フィールド及び複数のACK MAPフィールドからなる。ACK制御フィールドは、開始SNが書込まれるフィールド(FSN)及びシーケンスの数(Number of ACK MAP(m))が書込まれるフィールドを含む。ACK MAPフィールドはシーケンスの数だけ存在する。各ACK MAPフィールドは図2のACKリポートフィールドと同様な構造を持つ。図3において、連結識別子フィールド、ACK制御フィールド及び複数のACK MAPフィールドの各々は2オクテットからなる。よって、ブロックACKメッセージは“(m+2)×2”の全体の長さを持つ。通常、802.16において、mは可変値であり、最大フラグメントパケットの数は16である。
図4に示すブロックACKメッセージは、BA開始シーケンス制御(BA Starting Sequence Control)フィールド及びBAビットマップフィールドを含む。BA開始シーケンス制御フィールドにはBAビットマップフィールドに書込まれた開始シーケンスを示す情報が書込まれる。BAビットマップフィールドは複数のACK MAPフィールドからなる。各ACK MAPフィールドは図2のACKリポートフィールドと同様な構造を持つ。例えば、802.11の場合、同時に最大64個のSNレベルパケットに対するACK処理が可能であり、一つのSNレベルパケットは最大16個のフラグメントパケットに分割できる。よって、ACK MAPフィールドの各々が2オクテットからなる場合、BAビットマップフィールドは128オクテットの大きさを保持すべきである。
前述したように、従来のビットマップを用いて受信結果を通報すれば、不要な資源のロスが発生する。すなわち、従来は、SNレベルパケットの各々が最大フラグメントパケットに分割されることを鑑みてビットマップを構成する。よって、フラグメントパケットに分割されなかったり、最大個数だけのフラグメントパケットに分割されないSNレベルパケットに対応する受信結果を転送する場合、ビットマップフィールドで使用しない受信結果情報フィールドが発生することになる。このような受信結果情報フィールドは不要な資源と言える。
したがって、本発明の目的は、以下の通りである。
受信結果情報を転送するメッセージの長さを最小化する方法を提供する。
受信失敗したパケットを迅速に確認可能にする識別ビット領域を、受信情報を転送するメッセージに割り当てる方法を提供する。
受信失敗したパケットのみに対して受信結果情報を転送する方法を提供する。
各パケットに対応する識別ビットを通して受信失敗したパケットを確認し、受信失敗したパケットに対する受信結果情報のみを受信する方法を提供する。
受信結果情報を転送するメッセージにおいて、受信結果情報が書込まれるビットマップフィールドの大きさを受信失敗したパケットの数により決定する方法を提供する。
受信失敗したパケットの数が既定のしきい値を越えるとき、受信結果情報を転送するためのメッセージ領域を拡張する方法を提供する。
ビットマップの大きさを予め打ち合わせにより最適化させるための方法を提供する。
ビットマップの大きさを予め打ち合わせにより最適化させるためのフレーム構造を提供する。
ビットマップの大きさを最適化させるために、送信側よりSNレベルパケットの数及び最大フラグメントパケットの数を、受信側に転送する方法を提供する。
SNレベルパケットの数及び最大フラグメントパケットの数により、ビットマップの大きさを最適化させる方法を提供する。
SNレベルパケットの数及び最大フラグメントパケットの数により、ビットマップの大きさを最適化させるためのフレーム構造を提供する。
前記目的を達成するために、第1態様において、本発明は、連続転送する複数のパケットの各々を複数のフラグメントパケットに分割転送する移動通信システムにおいて、前記メッセージの第1ビットマップフィールドに前記受信パケットの各々に対する受信成功の可否を表示する識別子を書込むステップと、前記受信パケットの中の受信失敗したパケットに対応して受信結果を書込む第2ビットマップフィールドを前記メッセージに生成し、前記第2ビットマップフィールドに前記受信失敗したパケットから分割転送されたフラグメントパケットの各々に対する受信成功の可否を表示する識別ビットを書込むステップとにより、受信機が受信パケットに対する受信結果を送信機に報告するメッセージを構成する方法を提案する。
また、第2態様において、本発明は、連続転送する複数のパケットの各々を複数のフラグメントパケットに分割転送する移動通信システムの送信機において、前記受信結果報告メッセージの第1ビットマップフィールドに書込まれた前記複数のパケットの各々の識別子により、受信失敗したパケットがあるか否かを確認するステップと、前記受信失敗したパケットがあると、前記受信失敗したパケットに対応して前記受信結果報告メッセージの第2ビットマップフィールド内にある識別ビットにより、受信失敗したフラグメントパケットを確認するステップと、前記受信失敗したフラグメントパケット、或いは前記受信失敗したフラグメントパケットを含むパケットを再転送するステップとにより、受信機からの受信結果報告メッセージによりパケットを再転送する方法を提案する。
また、第3態様において、本発明は、移動通信システムにおいて、連続受信されるパケットの数及び最大フラグメントパケットの数に関する情報を受信するステップと、前記連続受信されるパケットの数及び前記最大フラグメントパケットの数に関する情報に基づいて、ビットマップ構成方式を決定するステップとにより、ビットマップを構成する方法を提案する。
また、第4態様において、本発明は、移動通信システムにおいて、既定の数(m)のパケットの各々を一つまたはその以上のフラグメントパケットに分割して連続転送するステップと、前記連続転送されるパケットの数(m)及び最大フラグメントパケットの数(n)に関する情報を転送するステップとにより、転送パケットに対する受信結果を要請する方法を提案する。
また、第5態様において、本発明は、移動通信システムにおいて、一つまたはその以上のフラグメントパケットに分割されたm個のパケットを連続受信するステップと、前記連続受信されるパケットの数(m)及び最大フラグメントパケットの数(n)に関する情報を受信するステップと、前記連続受信されるパケットの数(m)及び前記最大フラグメントパケットの数(n)に関する情報に基づいてビットマップ構成方式を決定するステップと、前記決定されたビットマップ構成方式により、前記フラグメントパケットの各々に対する受信結果を含むビットマップを構成するステップと、前記ビットマップを転送するステップとにより、受信パケットに対する受信結果を報告する方法を提案する。
本発明は、転送されるパケットに対する受信結果を通報するために、階層的ビットマップ構造を提案することで、転送資源を效率よく使用できる。また、実環境を考慮してみれば、転送資源のゲインの向上、且つ、性能の向上を図ることができる。
又、予めブロックACK要請によりビットマップの大きさを打ち合わせることで、受信結果を報告するためのビット数を最適化できる。これは、転送資源を效率よく使用でき、且つ、移動通信システムの性能向上の側面における効果も著しい。
以下、添付図面に基づき、本発明の好適な実施の形態を詳細に説明する。後述する詳細な説明では、前述した技術的課題をなすために、本発明において代表的な実施の形態を提示する。そして、本発明により提示し得る他の実施の形態は本発明の構成の説明に代替する。
本発明では、パケットの受信結果通報を充実に行いながらも、受信結果による情報が書込まれるフィールド(ビットマップフィールド)の大きさを最適化できる構造のメッセージを提案する。また、ビットマップの大きさを著しく低減できる構造のメッセージを提案する。後述する詳細な説明では、受信失敗したパケットのみに対して受信結果を報告することで、ビットマップの大きさを低減するビットマップ構成方法を第1実施の形態として提案する。そして、送信側から提供される情報に基づいて受信結果を報告することで、ビットマップの大きさを最適化させるビットマップ構成方法を第2実施の形態として提案する。
本発明の第1実施の形態は、二つの側面を考慮することで、具現可能である。
第一は、一般の無線データ通信システムの場合、パケットエラー率(PER;Packet Error Rate)を10−2水準に設計しているという点であり、第二は、パケット損失は均一な分布より特定瞬間に集中して現れるという点である。
前述の二つの側面を考慮するとき、エラーが発生するパケットの数は極小であり、エラーが発生しても特定瞬間に集中して発生する。よって、大部分のパケットに対しては受信成功し、受信失敗しても一部パケットのみで発生することを予想できる。
もし、受信失敗したパケットのみに対して受信結果を通報するようにARQ方式を具現する場合、受信結果通報による情報の量を大幅低減できる。受信結果通報による情報の量の低減は、ビットマップの大きさが低減することを暗示する。
後述する詳細な説明では、SNレベルパケットから分割転送されるフラグメントパケットのうち、受信失敗したフラグメントパケットに対応する受信結果のみを報告するブロックACKメッセージを提案する。このために、ブロックACKで処理可能な最大許容SNレベルパケットの各々に対する受信失敗の可否を確認できる識別子を転送するフィールド(以下“SNレベルビットマップフィールド”という)を新たに定義する。そして、受信失敗したSNレベルパケットに対応して具体的な受信結果情報を転送するフィールド(以下“ACKリポートフィールド”という)を新たに定義する。ここで、具体的な受信結果情報は、一つのSNレベルパケットから分割転送される各フラグメントパケットの受信失敗の可否を確認できる識別子を意味する。
このために、送信側(パケットの受信側)では、SN別に受信失敗したパケットがあるかを検査する。以後、受信失敗したパケットに対しては、SNレベルビットマップフィールドにおいて前記受信失敗したパケットのSNに対応する識別子を‘受信失敗’で設定する。受信成功したパケットに対しては、SNレベルビットマップフィールドにおいて前記受信成功したパケットのSNに対応する識別子を‘受信成功’で設定する。
しかし、同じSNを持つ複数のフラグメントパケットが受信された場合、SNレベルビットマップフィールドのみではフラグメントパケットの受信結果を確認できない。このとき、受信失敗したフラグメントパケットを確認できる別途の情報が要求される。
したがって、第1実施の形態では、ACKリポートフィールドを受信失敗したSN別に生成する。ACKリポートフィールドでは、各フラグメントパケット即ちFN別に識別子が書込まれる。識別子は同じSNを持つフラグメントパケットの受信失敗の可否を示す。ACKリポートフィールドは一つのSNレベルパケットが最大に分割可能なフラグメントパケットの数を考慮して構成する。
送信側では、前述のように構成したブロックACKメッセージを受信側に転送する。
受信側(パケットの送信側)は、ブロックACKメッセージのSNレベルビットマップフィールドに書込まれた識別子を確認することで、SNレベルパケットの各々に対する受信失敗の可否を確認する。受信側は、受信失敗したSNレベルパケットがあると、SNレベルパケットに対応するACKリポートフィールドを確認する。受信側は、ACKリポートフィールドに書込まれた識別子により受信失敗したフラグメントパケットがわかる。
図5は、本発明で提案する階層的ビットマップ構造を示す図である。
図5を参照すれば、階層的ビットマップ構造を持つブロックACKメッセージは、ブロックACK開始シーケンス(Block ACK Starting Sequence)フィールド及びビットマップ(Bitmap)フィールドからなる。ビットマップフィールドは、SNレベルビットマップ(SN−level Bitmap)フィールド及び失敗SNパケットビットマップ(Erroneous SN Packet Bitmap)フィールドからなる。失敗SNパケットビットマップフィールドは複数(m個)のACKリポートフィールドを含む。ここで、mはSNレベルビットマップフィールドに設定された0の数である。即ち、mは受信失敗したSNレベルパケットの数である。
ブロックACK開始シーケンスフィールドには、当該メッセージ内のビットマップが取扱う最初のSNレベルパケットの持つSNが書込まれる。このとき、最初のSNレベルパケットは、ブロックACKメッセージを通して受信結果を通報する最初のSNレベルパケットとして定義される。ここで、最初のSNレベルパケットは受信失敗した最初のSNレベルパケットと解釈されないように注意すべきである。
SNレベルビットマップフィールドには、各SN別の受信結果(受信失敗の可否)を示す識別子(以下“SNクイックレファレンスビット(SN quick reference bit)”という)が書込まれる。SNレベルビットマップフィールドの長さは、ブロックACKで処理可能な最大許容SNレベルパケットの数により決定される。すなわち、ブロックACKで処理可能な最大許容SNレベルパケットの数が8×N個とすれば、SNレベルビットマップフィールドはNオクテット(8×Nビット)の長さを持つ。よって、SNレベルビットマップフィールドを構成する各ビットは、SN別のSNクイックレファレンスビットとして使用される。
失敗SNパケットビットマップフィールドはACKリポートフィールドを含む。ACKリポートフィールドは、受信失敗したパケットのSN別に生成されることで、受信失敗したSNレベルパケットの数(m)だけ必要である。よって、失敗SNパケットビットマップ(Erroneous SN Packet bitmap)フィールドはM×mオクテットの長さを持つ。ここで、MオクテットはACKリポートフィールドの全体の長さであって、固定値である。失敗SNパケットビットマップフィールドの全体の長さ(M×mオクテット)は、受信失敗したSNレベルパケットの数(m)により決定される。
例えば、受信失敗したSNレベルパケットの数(m)が大きいほど、失敗SNパケットビットマップフィールドの全体の長さ(M×mオクテット)は長くなり、受信失敗したSNレベルパケットの数(m)が小さいほど、失敗SNパケットビットマップフィールドの全体の長さ(M×mオクテット)は短くなる。極端的に、受信失敗したSNレベルパケットがなければ、失敗SNパケットビットマップフィールドはない。
一方、0(受信失敗)で設定されたクイックレファレンスビット(SN quick reference bit)及びACKリポートフィールドのマッピング関係は多様に定立できる。最も容易な例として、0で設定されたクイックレファレンスビットのSN順序に応じて、ACKリポートフィールドが順次マッピングされるようにする。
例えば、ブロックACK開始シーケンスフィールドの値が5であり、SNレベルビットマップフィールドの値が11101011であるとすれば、失敗SNパケットビットマップフィールド内には二つのACKリポートフィールドが存在する。二つのACKリポートフィールドのうち、一番目のACKリポートフィールドはSNが8であるSNレベルパケットのビットマップとなり、二番目のACKリポートフィールドはSNが10であるSNレベルパケットのビットマップとなる。また、ACKリポートフィールドに識別子を付与する方法によっても具現できる。
ACKリポートフィールドは、フラグメントパケット別の受信結果を報告するための識別子が書込まれる。よって、識別子は、一つのSNレベルパケットから最大に分割可能なフラグメントパケットの数(M×8)に対応して存在する。これは、受信結果がフラグメントパケット別に通報されるためである。図5では識別子を“b0、b1、b2、…、b(n)、…、b(8×M−1)”で表示する。例えば、識別子が1ビットで表現されるとすれば、一つのACKリポートフィールドはMオクテットからなる。
以下、図5の構造を持つブロックACKメッセージの実際の構成例について説明する。
SNがn+1であるSNレベルパケットから分割されたフラグメントパケットを全て受信成功した場合、SNレベルビットマップフィールドにおいてn+1番目のSNクイックレファレンスビット(b(n))を1で設定する。しかし、フラグメントパケットの一つでも受信失敗すれば、SNレベルビットマップフィールドにおいてn+1番目のSNクイックレファレンスビット(b(n))を0で設定する。すなわち、フラグメントパケットの一つでも受信失敗すれば、SNレベルビットマップフィールドにおいてフラグメントパケットのSNに対応するSNクイックレファレンスビットを“受信失敗”で設定する。この場合、受信失敗したフラグメントパケットを確認できる別途の情報が提供されるべきである。
例えば、SNとFNが各々n+1であるフラグメントパケットを受信失敗した場合を仮定すれば、SNレベルビットマップフィールドにおいてn+1番目のSNクイックレファレンスビットであるb(n)が0で設定される。そして、失敗SNパケットビットマップフィールドに、b(n)にマッピングされるACKリポートフィールド(以下、“m番目のACKリポートフィールド”という)を割り当てる。以後、m番目のACKリポートフィールド内のn+1番目の識別子(b(n))で受信失敗を表示するビットを設定する。このとき、m番目のACKリポートフィールド内のn+1番目の識別子(b(n))を除いた残りの識別子では受信成功を表示するビットを設定する。一例として、受信失敗を表示する識別子として0を使用し、受信成功を表示する識別子として1を使用する。
図6及び図7は、先で説明した本発明をIEEE802.11n標準を基にするシステムに適用するとき、受信結果を通報するためのメッセージの例を示す図である。図6に示す例と図7に示す例は受信失敗したパケットの数により区分される。すなわち、受信失敗したMAC service data unit(MSDU)の数が、既定のしきい値(一例として12)に達しないと図6に示すメッセージ構造を使用し、既定のしきい値(一例として12)と同一又は超えると図7に示すメッセージ構造を使用する。
図6を参照すれば、ブロックACKメッセージは、BA制御(BA Control)フィールド、BA開始シーケンス制御(BA Starting Sequence Control)フィールド及びBA失敗パケットビットマップ(BA Erroneous MSDUs' Bitmap)フィールドを含む。
BA制御フィールドは2オクテットの長さを持つ。BA制御フィールドはビットマップフィールド及びTIDフィールドからなる。ビットマップフィールドはSNレベルパケットの各々の受信成功の可否を表示するためのクイックレファレンスビットからなる。ビットマップ(BA MSDUs' bitmap)フィールドは、既存の802.11では使用しなかった領域であって、本発明のために再使用する。図6ではMSDUが12個未満の場合を対象としていることで、BA MSDUs' Bitmapフィールドは12ビットからなる。
一方、BA制御フィールド内で任意の一つのビットをメッセージ識別子として割り当てる。一例として、BA制御フィールドの最初の一つのビットをメッセージ識別子として割り当てる。メッセージ識別子はメッセージ形態を表示する。図6ではメッセージ識別子として1を使用する。
BA開始シーケンス制御フィールドには、当該メッセージ内のビットマップが取扱う最初のSNレベルパケットの持つSNが書込まれる。最初のSNレベルパケットは、ブロックACKのために連続転送されるパケットの中で最初に転送されるパケットであって、受信失敗した最初のSNレベルパケットではないことに注意すべきである。
BA失敗パケットビットマップ(BA Erroneous MSDUs' Bitmap)フィールドは11個を越えない複数のACK MAPフィールドからなる。BA失敗パケットビットマップフィールドの構造は先の図5を参照して説明した失敗SNパケットビットマップ(Erroneous SN Packet bitmap)フィールドと同様な構造及び機能を持つ。よって、BA失敗パケットビットマップフィールドについての具体的な説明は省略する。
図7を参照すれば、ブロックACKメッセージは、BA制御(BA Control)フィールド、BA開始シーケンス制御(BA Starting Sequence Control)フィールド、BA MSDUs' Bitmapフィールド及びBA失敗パケットビットマップ(BA Erroneous MSDUs' Bitmap)フィールドを含む。
BA制御フィールド内で任意の一つのビットをメッセージ識別子として割り当てる。一例として、BA制御フィールドの最初の一つのビットをメッセージ識別子として割り当てる。図7ではメッセージ識別子として0を使用する。そして、BA制御フィールド内でもう一つのビットを成功識別子として割り当てる。成功識別子は全てのパケット(図7では“64個のMSDUs”を仮定している)が受信成功したことを表示する(図面ではA)。もし、全てのSNレベルパケットが受信成功すれば、成功識別子は1の値で設定される。これに対し、SNレベルパケットの一つでも受信失敗すれば、成功識別子は0の値で設定される。もし、成功識別子が1の値で設定されると、BA MSDUs' Bitmapフィールド及びBA失敗パケットビットマップフィールドは不要である。
BA MSDUs' Bitmapフィールドは、図6のBA制御フィールドに存在するBA MSDUs' Bitmapフィールドと同様な機能を行うため、その具体的な説明は省略する。但し、図7のBA MSDUs' Bitmapフィールドは、64個のパケットに対する受信成功の可否を表示するために64ビット(8オクテット)の大きさを持つ。
BA失敗パケットビットマップフィールドは、受信失敗したパケットの数に対応するACK MAPフィールドからなる。BA失敗パケットビットマップフィールドの構造は、先の図5を参照して説明した失敗SNパケットビットマップフィールドと同様な構造及び機能を持つ。よって、BA失敗パケットビットマップフィールドについての具体的な説明は省略する。
本発明の第2実施の形態は、送信側において、連続的なデータフレームの転送と共にブロックACK要請フレームを転送するシステムを仮定する。ブロックACK要請フレームは各データフレームの受信結果を転送するために必要な情報を含む。ブロックACK要請フレームはデータフレームの転送前又は後に転送できる。勿論、ブロックACK要請フレームとデータフレームを同時に転送することもできる。
受信側は、連続的なデータフレームとブロックACK要請フレームを受信する。受信側は、ブロックACK要請フレームを通して受信した情報によりビットマップ構成方式を決定する。そして、ビットマップを決定された構成方式によりデータフレームの受信結果を含むように構成する。ビットマップはブロックACKフレームを通して送信側に通報される。
第2実施の形態では、ブロックACK要請フレームを通して、“連続転送するSNレベルパケットの数(m)”及び“最大フラグメントパケットの数(n)”に関する情報を転送する。通常、SNレベルパケットは必要に応じて複数のフラグメントパケットに分割転送される。最大フラグメントパケットの数(n)は、転送するSNレベルパケットの中で最も多く分割されたフラグメントパケットの数である。
後述する詳細な説明では、送信側において、ブロックACK要請フレームを転送するための動作と、ブロックACK要請フレームの構造とについて具体的に説明する。そして、受信側において、ブロックACKフレームを通してフラグメントパケット別の受信結果を報告する動作と、ブロックACKフレームの構造とについて具体的に説明する。
本発明の適用例では、連続転送するSNレベルパケットの数(m)及び最大フラグメントパケットの数(n)を任意に付与する時の動作を説明する。
以下、本発明の実施の形態による送信側と受信側の動作を具体的に説明すれば、次の通りである。
図8は本発明の実施の形態による送信側の動作を説明する制御の流れを示す図である。
図8を参照すれば、810段階において、転送するSNレベルパケットの数(m)を決定する。mの決定は連続転送したいSNレベルパケットの数により行われる。SNレベルパケットは複数のフラグメントパケットに分割転送されることができる。812段階において、各SNレベルパケットの分割状態を確認し、フラグメントパケットの最大個数を確認する。すなわち、各SNレベルパケットが分割されたフラグメントパケットの数を把握し、最も多く分割されたSNレベルパケットを探す。そして、探したSNパケットが分割されたフラグメントパケットの数を最大フラグメントパケットの数(n)として決定する。
814段階において、先に決定されたmとnを含むようにBAR(Block ACK Request)フレームを構成する。このとき、BARフレームのブロックACK開始シーケンス制御フィールドには最初に転送するSNレベルパケットのSN(Sequence Number)を書込む。送信側はBARフレームを受信側に転送する。BARフレームの構造は図10に例示する。図10を参照したBARフレームの構造に対する説明は後述する。
一方、図8には示さないが、m個のSNレベルパケットは当該BARフレームの転送前又は後に転送されることができる。勿論、同時に転送することもできる。そして、送信側はm個のSNレベルパケットのフラグメントパケットの各々に対応する受信結果を受信側より提供される。フラグメントパケット別の受信結果はBA(Block ACK)フレームを通して提供される。送信側はBAフレームを通して得た各フラグメントパケットの受信結果によりフラグメントパケットの再転送を行う。
図9は、本発明の実施の形態による受信側の動作を説明する制御の流れを示す図である。
図9を参照すれば、910段階において、BARフレームを受信する。912段階において、BARフレームからm、nを確認する。m、nを確認すれば、914段階乃至918段階において、ビットマップ構成方式を決定する。ビットマップ構成方式は、ビットマップの全体の大きさ、一つのSNレベルパケットに対するビットマップの大きさ及びパディング処理を行うビット数により決定される。
前記914段階において、ビットマップ全体の大きさを決定する。ビットマップ全体の大きさは先に確認したm、nにより決定される。下記式(1)はビットマップ全体の大きさを決定する一例を示す。
Figure 2006054897
上記式(1)において、ceiling[x]はxを越える整数の中の最小整数である。そして、オクテットを単位とするビットマップ全体の大きさに8を乗算してビットを単位とするビットマップ全体の大きさで表現できる。
例えば、mが2でnが7である場合を仮定すれば、ビットマップ全体の大きさは“ceiling[1.75x]”で表現される。“ceiling[1.75x]”は1.75より大きい整数の中の最小整数であるので、その結果は“2”となる。よって、ビットマップ全体の大きさは2オクテットとして決定される。
916段階において、SNレベルパケット別に指定されるビットマップの大きさを決定する。好ましくは、全てのSNレベルパケットに対してビットマップの大きさを同一に割り当てる。このように、ビットマップの大きさを同一に割り当てる場合は、一つのSNレベルパケットに対するビットマップの大きさを決定し、残りSNレベルパケットに対しても同一に適用できる。例えば、ビットマップの大きさは先に確認したnビットで決定される。これは、フラグメントパケット別に受信結果を通報すべきであるためである。
一方、前述したように、SNレベルパケット別に割り当てられるビットマップの大きさの和は、ビットマップ全体の大きさを超えない。すなわち、SNレベルパケット別にnビットのビットマップの大きさを割り当てる場合、ビットマップ全体の大きさと一致したり剰余ビット(Remaining bit)が発生したりする。918段階において、パディング処理を行う剰余ビット数を決定する。しかし、SNレベルパケット別に割り当てられたビットマップの大きさの和がビットマップ全体の大きさと一致すれば、パディング処理を行うビットが存在しない。パディング処理を行うビット数は、下記式(2)により一般化できる。
Figure 2006054897
上記式(2)での単位は、ビット(bit)である。
920段階において、ビットマップを構成する。ビットマップの構成方式は先に決定されたビットマップ全体の大きさ、SNレベルパケット別のビットマップの大きさ及びパディング処理を行うビット数により決定される。そして、各フラグメントパケット別の受信結果によるビット値を対応するビット位置に挿入する。このとき、ビット位置はフラグメントパケットが持つSNとFNを参照する。受信結果によるビット値は“1(success)”と“0(fail)”が使用される。
ビットマップの構造は図11に例示する。図11を参照したビットマップの構造についての説明は後述する。そして、各フラグメントパケットに対する受信結果によるビット値を対応するビット位置に挿入する例を、図12乃至図14に示す。これに対する具体的な説明も後述する。
922段階において、ビットマップを含むBA(Block ACK)フレームを構成し、これを送信側に転送する。
以下、本発明の第2実施の形態により、送信側から転送されるBARフレームの構造を具体的に説明する。
本発明の第2実施の形態で提案するBARフレームの構造は、連続転送したいSNレベルパケットの数(m)及び最も多く分割されたSNレベルパケットのフラグメントパケットの数(n)に関する情報を含むことに特徴がある。
図10では、前述した特徴が反映されたBARフレームの構造を例示する。
図10を参照すれば、BARフレームは、BAR制御(BAR Control)フィールド及びBA開始シーケンス制御(Block ACK Starting Sequence Control)フィールドを持つ。BAR制御フィールド及びBA開始シーケンス制御フィールドの大きさは2オクテットである。
BAR制御フィールドは、“Num of MSDUs”フィールド及び“Max.num of Frag.”フィールドを含む。“Num of MSDUs”フィールドには連続転送したいSNレベルパケットの数(m)値が書込まれる。“Max.num of Frag.”フィールドには最も多く分割されたSNレベルパケットのフラグメントパケットの数(n)値が書込まれる。“Num of MSDUs”フィールドの大きさは6ビットであり、“Max.num of Frag.”フィールドの大きさは4ビットである。
BA開始シーケンス制御フィールドには、連続転送したいSNレベルパケットの中の最初に転送されるSNレベルパケットの持つSNが書込まれる。
以下、本発明の第2実施の形態により、受信側から転送されるBAフレームの構造を具体的に説明する。
本発明で提案するBAフレームの構造は、送信側から提供されるm、nを用いて、最適のビットマップ構造を持つようにすることに特徴がある。
図11は、前述した特徴が反映されたBAフレームの構造を例示する。
図11を参照すれば、BAフレームは、BA開始シーケンス制御(Block ACK Starting Sequence Control)フィールド及びBAビットマップ(Block ACK Bitmap)フィールドを持つ。
BA開始シーケンス制御フィールドには、連続受信したSNレベルパケットのSNの中の最初のSNが書込まれる。
BAビットマップフィールド全体の大きさは上記式(1)により決定される。すなわち、BAビットマップフィールド全体の大きさはBARフレームを通して受信したm、nにより決定できる。BAビットマップフィールドはm個のビットマップからなる。m個のビットマップの各々はnビットからなる。ビットマップを構成する各ビットは当該フラグメントパケットの受信結果を表現する。各ビットマップは連続受信されたSNレベルパケットの一つに対応し、対応するSNレベルパケットのフラグメントパケットに対する受信結果が書込まれる。このとき、ビットマップ内でフラグメントパケットの受信結果を書込んだビット位置は、フラグメントパケットが持つSNとFNにより指定される。BAビットマップフィールドにおいてビットマップで使用されない剰余ビット(Remaining bits)はパディング処理が行われる。パディング処理を行うビット数は上記式(2)により求められる。
以下、本発明の第2実施の形態に対して事例別の動作を説明する。
図12a乃至図12cは、送信側から連続転送された全てのSNレベルパケットが正常受信された場合の動作例を説明するための図である。
図12aは、3つのSNレベルパケット(SN=10、11、12)が連続転送されることを示す。ここで、SNが10であるSNレベルパケットは4つのフラグメントパケット(10−1、10−2、10−3、10−4)に分割され、SNが11であるSNレベルパケットは3つのフラグメントパケット(11−1、11−2、11−3)に分割された。そして、SNが12であるSNレベルパケットは5つのフラグメントパケット(12−1、12−2、12−3、12−4、12−5)に分割された。よって、mは“3”で決定され、nは“5”で決定される。nが“5”で決定されることは、一つのSNレベルパケットから最大に分割されたフラグメントパケットの数が5であるためである。
図12bは、BAR制御フィールドにmが“3”、nが“5”で設定されたBARフレームの構造を示す。一方、連続転送される3つのSNレベルパケットの中の最初に転送されるSNレベルパケットのSNは10である。よって、BA開始シーケンス制御フィールドには10が書込まれる。
受信側は、図12bの構造を持つBARフレームを受信すれば、BAR制御フィールド及びBA開始シーケンス制御フィールドに書込まれた情報を確認する。これにより、受信側は10、11、12をSNとする3つのSNレベルパケットが連続転送され、その中の最大に分割されたフラグメントパケットの数は5であることを認知する。
以後、受信側では上記式(1)によりビットマップ全体の大きさを決定する。上記式(1)によれば、ビットマップ全体の大きさは2オクテット(16ビット)で決定される。そして、各SNレベルパケットに対応する受信結果表示ビットは5ビットで決定する。これは、SNが12であるSNレベルパケットが5つのフラグメントパケットに分割され、各フラグメントパケット別の受信結果を表示するには最小5ビットが必要なためである。
SNが10であるSNレベルパケットを構成する4つのフラグメントパケットは全て正常受信されている。よって、SNが10であるSNレベルパケットに対する受信結果表示ビットは“11110”で設定される(図12cの<1>で表示)。“1”で設定された上位4ビットは各フラグメントパケットが正常受信されたことを表示する。最後の1ビットは対応するフラグメントパケットが存在しなくて“0”で設定された。
SNが11であるSNレベルパケットを構成する3つのフラグメントパケットは全て正常受信されている。よって、SNが11であるSNレベルパケットに対する受信結果表示ビットは“11100”で設定される(図12cの<2>で表示)。“1”で設定された上位3ビットは各フラグメントパケットが正常受信されたことを表示する。下位2ビットは対応するフラグメントパケットが存在しなくて“0”で設定された。
SNが12であるSNレベルパケットを構成する5つのフラグメントパケットは全て正常受信されている。よって、SNが12であるSNレベルパケットに対する受信結果表示ビットは“11111”で設定される(図12cの<3>で表示)。“1”で設定された5ビットの受信結果表示ビットは各フラグメントパケットが正常受信されたことを表示する。
一方、各SNレベルパケット別に5ビットの受信結果表示ビットを割り当てると、全体の大きさが2オクテット(16ビット)で決定されたビットマップにおいて1ビットの剰余ビットが発生する。これは上記式(2)により決定される。受信側は剰余ビットに対してパディング処理を行う。すなわち、剰余ビットを“0”で設定する。
つまり、連続転送される3つのSNレベルパケットに対する受信結果は“11110 11100 11111 0”で決定される。決定された受信結果はBAフレームのBAビットマップフィールドに書込まれる。そして、BAフレームのBA開始シーケンス制御フィールドには10が書込まれる。
図13a乃至図13c及び図14a乃至図14cは、送信側から連続転送されたSNレベルパケットの中の一部のSNレベルパケットを正常受信しない場合の動作例を説明するための図である。
図13aは、3つのSNレベルパケット(SN=10、11、12)が連続転送されることを示す。ここで、SNが10であるSNレベルパケットは4つのフラグメントパケット(10−1、10−2、10−3、10−4)に分割され、SNが11であるSNレベルパケットは3つのフラグメントパケット(11−1、11−2、11−3)に分割されている。そして、SNが12であるSNレベルパケットは5つのフラグメントパケット(12−1、12−2、12−3、12−4、12−5)に分割されている。よって、mは“3”で決定され、nは“5”で決定される。nが“5”で決定されることは、一つのSNレベルパケットから最大に分割されたフラグメントパケットの数が5であるためである。そして、フラグメントパケットの中の11−2、12−2、12−4に該当するフラグメントパケットは受信失敗している。
図13bは、BAR制御フィールドにmが“3”、nが“5”で設定されたBARフレームの構造を示す。一方、最初に転送されるSNレベルパケットのSNは10である。よって、BA開始シーケンス制御フィールドには10が書込まれる。
受信側は、図13bの構造を持つBARフレームを受信すれば、BAR制御フィールド及びBA開始シーケンス制御フィールドに書込まれた情報を確認する。これにより、受信側は、10、11、12をSNとする3つのSNレベルパケットが連続転送され、その中の最大に分割されたフラグメントパケットの数は5であることを認知する。
以後、受信側では上記式(1)によりビットマップ全体の大きさを決定する。上記式(1)によれば、ビットマップ全体の大きさは2オクテット(16ビット)で決定される。そして、各SNレベルパケットに対応する受信結果表示ビットは5ビットで決定する。これは、SNが12であるSNレベルパケットが5つのフラグメントパケットに分割され、各フラグメントパケット別の受信結果を表示するには最小5ビットが必要なためである。
SNが10であるSNレベルパケットを構成する4つのフラグメントパケット(10−1、10−2、10−3、10−4)は全て正常受信されている。よって、SNが10であるSNレベルパケットに対する受信結果表示ビットは“11110”で設定される(図13cの<1>で表示)。“1”で設定された上位4ビットは各フラグメントパケットが正常受信されたことを表示する。最後の1ビットは対応するフラグメントパケットが存在しなくて“0”で設定された。
SNが11であるSNレベルパケットを構成する3つのフラグメントパケット(11−1、11−2、11−3)のうち、11−1、11−3に該当するフラグメントパケットは正常受信され、11−2に該当するフラグメントパケットは正常受信されなかった。よって、SNが11であるSNレベルパケットに対する受信結果表示ビットは“10100”で設定される(図13cの<2>で表示)。“1”で設定されたビットは当該フラグメントパケット(11−1、11−3)が正常受信されたことを表示する。ところで、“0”で設定されたビットは当該フラグメントパケット(11−2)が正常受信されなかったことを表示する。下位2ビットは対応するフラグメントパケットが存在しなくて“0”で設定された。
SNが12であるSNレベルパケットを構成する5つのフラグメントパケット(12−1、12−2、12−3、12−4、12−5)のうち、12−1、12−3、12−5に該当するフラグメントパケットは正常受信され、12−2、12−4に該当するフラグメントパケットは正常受信されなかった。よって、SNが12であるSNレベルパケットに対する受信結果表示ビットは“10101”で設定される(図13cの<3>で表示)。“1”で設定されたビットは該当フラグメントパケット(12−1、12−3、12−5)が正常受信されたことを表示する。ところが、“0”で設定されたビットは当該フラグメントパケット(12−2、12−4)が正常受信されなかったことを表示する。
一方、各SNレベルパケット別に5ビットの受信結果表示ビットを割り当てると、全体の大きさが2オクテット(16ビット)で決定されたビットマップにおいて1ビットの剰余ビットが発生する。これは上記式(2)により決定される。受信側は剰余ビットに対してパディング処理を行う。すなわち、剰余ビットを“0”で設定する。
つまり、連続転送される3つのSNレベルパケットに対する受信結果は“11110 10100 10101 0”で決定される。決定された受信結果はBAフレームのBAビットマップフィールドに書込まれる。そして、BAフレームのBA開始シーケンス制御フィールドには10が書込まれる。
図14aは、2つのSNレベルパケット(SN=10、11)が連続転送されることを示す。ここで、SNが10であるSNレベルパケットは7つのフラグメントパケット(10−1、10−2、10−3、10−4、10−5、10−6、10−7)に分割され、SNが11であるSNレベルパケットは5つのフラグメントパケット(11−1、11−2、11−3、11−4、11−5)に分割されている。よって、mは“2”で決定され、nは“7”で決定される。nが“7”で決定されることは、一つのSNレベルパケットから最大に分割されたフラグメントパケットの数が7であるためである。そして、フラグメントパケットの中の10−3、10−6、11−2に該当するフラグメントパケットは受信失敗した。
図14bは、BAR制御フィールドにmが“2”、nが“7”で設定されたBARフレームの構造を示す。一方、連続転送される2つのSNレベルパケットの中の最初に転送されるSNレベルパケットのSNは10である。よって、BA開始シーケンス制御フィールドには10が書込まれる。
受信側は、図14bの構造を持つBARフレームを受信すれば、BAR制御フィールド及びBA開始シーケンス制御フィールドに書込まれた情報を確認する。これにより、受信側は、10、11をSNとする2つのSNレベルパケットが連続転送され、その中の最大に分割されたフラグメントパケットの数は7であることを認知する。
以後、受信側では上記式(1)によりビットマップ全体の大きさを決定する。上記式(1)によれば、ビットマップ全体の大きさは2オクテット(16ビット)で決定される。そして、各SNレベルパケットに対応する受信結果表示ビットは7ビットで決定する。これは、SNが10であるSNレベルパケットが7つのフラグメントパケットに分割され、各フラグメントパケット別の受信結果を表示するには最小7ビットが必要なためである。
SNが10であるSNレベルパケットを構成する7つのフラグメントパケット(10−1、10−2、10−3、10−4、10−5、10−6、10−7)のうち、10−1、10−2、10−4、10−5、10−7に該当するフラグメントパケットは正常受信され、10−3、10−6に該当するフラグメントパケットは正常受信されなかった。よって、SNが10であるSNレベルパケットに対する受信結果表示ビットは“1101101”で設定される(図14cの<1>で表示)。“1”で設定されたビットは該当フラグメントパケット(10−1、10−2、10−4、10−5、10−7)が正常受信されたことを表示する。ところが、“0”で設定されたビットは当該フラグメントパケット(10−3、10−6)が正常受信されなかったことを表示する。
SNが11であるSNレベルパケットを構成する5つのフラグメントパケット(11−1、11−2、11−3、11−4、11−5)のうち、11−1、11−3、11−4、11−5に該当するフラグメントパケットは正常受信され、11−2に該当するフラグメントパケットは正常受信されなかった。よって、SNが11であるSNレベルパケットに対する受信結果表示ビットは“1011100”で設定される(図14cの<2>で表示)。“1”で設定されたビットは当該フラグメントパケット(11−1、11−3、11−4、11−5)が正常受信されたことを表示する。ところが、“0”で設定されたビットは当該フラグメントパケット(11−2)が正常受信されなかったことを表示する。下位2ビットは対応するフラグメントパケットが存在しなくて“0”で設定された。
一方、各SNレベルパケット別に7ビットの受信結果表示ビットを割り当てると、全体の大きさが2オクテット(16ビット)で決定されたビットマップにおいて2ビットの剰余ビットが発生する。これは上記式(2)により決定される。受信側は剰余ビットに対してパディング処理を行う。すなわち、剰余ビットを“0”で設定する。
つまり、連続転送される3つのSNレベルパケットに対する受信結果は“1101101 1011100 00”で決定される。決定された受信結果はBAフレームのBAビットマップフィールドに書込まれる。そして、BAフレームのBA開始シーケンス制御フィールドには10が書込まれる。
前述した本発明の第2実施の形態では、予め送信側のビットマップの大きさを打ち合わせるために、連続転送するSNレベルパケットの数及び最大フラグメントパケットの数を受信側に提供することを仮定している。しかし、受信側で連続転送されたSNレベルパケットを受信することで、連続転送されたSNレベルパケットの数及び最大フラグメントパケットの数を確認するように具現することもできる。このように具現すれば、送信側でブロックACK要請フレームを転送する必要がなくなる。
一般のブロックACK方式の基本概念を説明するための図である。 従来のビットマップ(Bitmap)を用いて受信結果を通報する例を示す図である。 従来のビットマップ(Bitmap)を用いて受信結果を通報する例を示す図である。 従来のビットマップ(Bitmap)を用いて受信結果を通報する例を示す図である。 本発明で提案する階層的ビットマップ構造を示す図である。 先に説明した本発明を802.11nに適用するとき、受信結果を通報するためのメッセージの例を示す図である。 先に説明した本発明を802.11nに適用するとき、受信結果を通報するためのメッセージの例を示す図である。 本発明の実施の形態による送信側の動作を説明する制御の流れを示す図である。 本発明の実施の形態による受信側の動作を説明する制御の流れを示す図である。 本発明の実施の形態によるブロックACK要請フレームの構造を示す図である。 本発明の実施の形態によるブロックACKフレームの構造を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。 本発明の実施の形態による動作例を示す図である。
符号の説明
b0 識別子
b1 識別子
b2 識別子
b(n) 識別子
b(8×M−1) 識別子

Claims (26)

  1. 連続転送する複数のパケットの各々を複数のフラグメントパケットに分割転送する移動通信システムにおける、受信機が受信パケットに対する受信結果を送信機に報告する受信結果報告メッセージを構成する方法において、
    前記受信結果報告メッセージの第1ビットマップフィールドに前記パケットの各々に対する受信成功の可否を表示する識別子を書込むステップと、
    前記パケットの中の受信失敗したパケットに対応して受信結果を書込む第2ビットマップフィールドを前記受信結果報告メッセージに生成し、前記第2ビットマップフィールドに前記受信失敗したパケットのフラグメントパケットの各々に対する受信成功の可否を表示する識別ビットを書込むステップと、
    を含むことを特徴とする前記方法。
  2. 前記第1ビットマップフィールドに書込まれる識別子の数は、連続受信されるパケットの数により決定されることを特徴とする請求項1に記載の前記方法。
  3. 前記受信パケットから分割されたフラグメントパケットの一つでも受信失敗すれば、前記第1ビットマップフィールドにおいて、前記受信パケットに対応する識別子を受信失敗を表示する値で設定することを特徴とする請求項2に記載の前記方法。
  4. 前記第2ビットマップフィールドの数は、受信失敗したパケットの数により決定されることを特徴とする請求項1に記載の前記方法。
  5. 前記第2ビットマップフィールドに書込まれる識別ビットの数は、一つのパケットから最大に分割されたフラグメントパケットの数により決定されることを特徴とする請求項4に記載の前記方法。
  6. 前記第2ビットマップフィールド内の識別ビットのうち、前記受信失敗したフラグメントパケットに対応する識別ビットを受信失敗を表示する値で設定することを特徴とする請求項3に記載の前記方法。
  7. 前記受信パケットが持つSN(Sequence Number)のうち、最初のSNを書込むフィールドを前記受信結果報告メッセージにさらに備えることを特徴とする請求項1に記載の前記方法。
  8. 連続転送する複数のパケットの各々を複数のフラグメントパケットに分割転送する移動通信システムの送信機における、受信機からの受信結果報告メッセージによりパケットを再転送する方法において、
    前記受信結果報告メッセージの第1ビットマップフィールドに書込まれた前記複数のパケットの各々の識別子を分析して、受信失敗したパケットがあるか否かを確認するステップと、
    前記受信失敗したパケットがあると、前記受信失敗したパケットに対応して前記受信結果報告メッセージの第2ビットマップフィールド内にある識別ビットを分析して、受信失敗したフラグメントパケットを確認するステップと、
    前記受信失敗したフラグメントパケットと前記受信失敗したフラグメントパケットを含むパケット中の一つを再転送するステップと、
    を含むことを特徴とする前記方法。
  9. 前記第1ビットマップフィールドの識別子の数は、前記複数のパケットの数と同一であることを特徴とする請求項8に記載の前記方法。
  10. 前記第1ビットマップフィールドの識別子は、前記識別子に対応する受信パケットから分割されたフラグメントパケットの一つでも受信失敗すれば、受信失敗を表示する値で設定されることを特徴とする請求項9に記載の前記方法。
  11. 前記第2ビットマップフィールドの数は、受信失敗したパケットの数と同一であることを特徴とする請求項8に記載の前記方法。
  12. 前記第2ビットマップの識別ビットの数は、一つのパケットから最大に分割されたフラグメントパケットの数と同一であることを特徴とする請求項11に記載の前記方法。
  13. 前記受信結果報告メッセージは、前記複数のパケットが持つSNのうち、最初のSNを書込むフィールドをさらに備えることを特徴とする請求項8に記載の前記方法。
  14. 移動通信システムにおける受信パケットに対する受信結果を報告するためのビットマップを構成する方法において、
    連続受信されるパケットの数(m)及び最大フラグメントパケットの数(n)に関する情報を受信するステップと、
    前記連続受信されるパケットの数(m)及び前記最大フラグメントパケットの数(n)に関する情報に基づいて、ビットマップ構成方式を決定するステップと、
    を含むことを特徴とする前記方法。
  15. 前記ビットマップ構成方式を決定するためのビットマップ全体の大きさは、下記式(1)により計算されることを特徴とする請求項14に記載の前記方法。
    Figure 2006054897
    ここで、ceiling[x]はxを越える整数の中の最小整数であり、mは連続受信されたパケットの数であり、nはフラグメントパケットの数である。
  16. 前記連続受信されるパケットの各々に対応するビットマップの大きさは、nビットで決定されることを特徴とする請求項15に記載の前記方法。
  17. 前記ビットマップ全体の大きさに該当するビットのうち、下記式(2)により計算されたビット数だけのビットに対してパディング処理を行うことを特徴とする請求項16に記載の前記方法。
    Figure 2006054897
    ここで、ceiling[x]はxを越える整数の中の最小整数である。
  18. 移動通信システムにおける転送パケットに対する受信結果を要請する方法において、
    所定の数(m)のパケットの各々を一つまたはその以上のフラグメントパケットに分割して連続転送するステップと、
    前記連続転送されるパケットの数(m)及び最大フラグメントパケットの数(n)に関する情報を転送するステップと、
    を含むことを特徴とする前記方法。
  19. 前記連続転送されるパケットの数(m)及び前記最大フラグメントパケットの数(n)に関する情報を転送後、前記フラグメントパケットを転送することを特徴とする請求項18に記載の前記方法。
  20. 前記フラグメントパケットを転送後、前記連続転送されるパケットの数(m)及び前記最大フラグメントパケットの数(n)に関する情報を転送することを特徴とする請求項18に記載の前記方法。
  21. 移動通信システムにおける受信パケットに対する受信結果を報告する方法において、
    一つまたはその以上のフラグメントパケットに分割されたm個のパケットを連続受信するステップと、
    前記連続受信されるパケットの数(m)及び最大フラグメントパケットの数(n)に関する情報を受信するステップと、
    前記連続受信されるパケットの数(m)及び前記最大フラグメントパケットの数(n)に関する情報に基づいて、ビットマップ構成方式を決定するステップと、
    前記決定されたビットマップ構成方式により、前記フラグメントパケットの各々に対する受信結果を含むビットマップを構成するステップと、
    前記ビットマップを転送するステップと、
    を含むことを特徴とする前記方法。
  22. 前記ビットマップ構成方式を決定するためのビットマップ全体の大きさは、下記式(3)により計算されることをを特徴とする請求項21に記載の前記方法。
    Figure 2006054897
    ここで、ceiling[x]はxを越える整数の中の最小整数であり、mは連続受信されたパケットの数であり、nはフラグメントパケットの数である。
  23. 前記連続受信されるパケットの各々に対応するビットマップの大きさは、nビットで決定されることを特徴とする請求項22に記載の前記方法。
  24. 前記受信したパケット別に分割されたk個のフラグメントパケットの各々に対する受信結果(kビット)を対応するnビットのビットマップに書き込み、前記kビットが前記nビットより小さい場合、残りビットに0を書込むことを特徴とする請求項23に記載の前記方法。
  25. 前記ビットマップ全体の大きさに該当するビットのうち、下記式(4)により計算されたビット数だけのビットに対してパディング処理を行うことを特徴とする請求項23に記載の前記方法。
    Figure 2006054897
    ここで、ceiling[x]はxを越える整数の中の最小整数である。
  26. 前記パケットに対応するビットマップは、前記全体ビットマップ内においてnビット間隔に整列されることを特徴とする請求項22に記載の前記方法。
JP2005233762A 2004-08-13 2005-08-11 移動通信システムにおけるパケット受信結果報告方法 Active JP4319654B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR1020040064049A KR101075722B1 (ko) 2004-08-13 2004-08-13 이동통신시스템에서의 패킷 처리 결과 통보방법
US60761004P 2004-09-07 2004-09-07
KR1020050044645A KR100703501B1 (ko) 2004-09-07 2005-05-26 이동통신시스템에서 블록 승인 프레임 구성방법

Publications (2)

Publication Number Publication Date
JP2006054897A true JP2006054897A (ja) 2006-02-23
JP4319654B2 JP4319654B2 (ja) 2009-08-26

Family

ID=35033434

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005233762A Active JP4319654B2 (ja) 2004-08-13 2005-08-11 移動通信システムにおけるパケット受信結果報告方法

Country Status (2)

Country Link
EP (2) EP3734879A1 (ja)
JP (1) JP4319654B2 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009118489A (ja) * 2007-11-08 2009-05-28 Samsung Electronics Co Ltd 中継方式を利用する無線通信システムにおける応答チャンネル伝送装置及び方法
WO2011155344A1 (ja) * 2010-06-08 2011-12-15 シャープ株式会社 無線通信システム、基地局装置、移動局装置、無線通信方法および集積回路
JP2012516102A (ja) * 2009-01-22 2012-07-12 サムスン エレクトロニクス カンパニー リミテッド Arq状態フィードバックメッセージを生成し読み取る方法及びシステム
WO2013076921A1 (ja) * 2011-11-21 2013-05-30 パナソニックモバイルコミュニケーションズ株式会社 無線通信端末装置及び再送制御方法
JP2016119687A (ja) * 2011-09-02 2016-06-30 クゥアルコム・インコーポレイテッドQualcomm Incorporated 低速ワイヤレスネットワークにおけるロングパケットのためのフラグメント化の向上
JP2016178649A (ja) * 2012-06-13 2016-10-06 ケイティー コーポレーションKt Corporation エンコードされたtim情報通信方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100907978B1 (ko) * 2007-09-11 2009-07-15 엘지전자 주식회사 이동통신 시스템에서 pdcp 계층의 상태보고 전송 방법 및 수신장치
EP2757724B1 (en) 2011-09-16 2016-11-09 Huawei Technologies Co., Ltd. Method for transmitting fragments and device for transmitting fragments
WO2016050260A1 (en) * 2014-09-29 2016-04-07 Telefonaktiebolaget L M Ericsson (Publ) Method and network node for handling a feedback procedure
WO2022170538A1 (zh) * 2021-02-09 2022-08-18 北京小米移动软件有限公司 通信方法和通信装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4564668B2 (ja) * 1999-04-07 2010-10-20 テレフオンアクチーボラゲット エル エム エリクソン(パブル) ビットマップを有効に使用する選択的繰り返しarq
US6658619B1 (en) * 2000-10-06 2003-12-02 Ericsson Inc. Systems and methods for implementing hierarchical acknowledgement bitmaps in an ARQ protocol
US20030135640A1 (en) * 2002-01-14 2003-07-17 Texas Instruments Incorporated Method and system for group transmission and acknowledgment
WO2006016745A1 (en) * 2004-08-12 2006-02-16 Samsung Electronics Co., Ltd. Method and apparatus for transmitting ack frame

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009118489A (ja) * 2007-11-08 2009-05-28 Samsung Electronics Co Ltd 中継方式を利用する無線通信システムにおける応答チャンネル伝送装置及び方法
US8248987B2 (en) 2007-11-08 2012-08-21 Samsung Electronics Co., Ltd. Apparatus and method for ACK channel transmission in wireless relay communication system
JP2012516102A (ja) * 2009-01-22 2012-07-12 サムスン エレクトロニクス カンパニー リミテッド Arq状態フィードバックメッセージを生成し読み取る方法及びシステム
US8917657B2 (en) 2009-01-22 2014-12-23 Samsung Electronics Co., Ltd. Method and system for generating and reading an automatic repeat request (ARQ) status feedback message
WO2011155344A1 (ja) * 2010-06-08 2011-12-15 シャープ株式会社 無線通信システム、基地局装置、移動局装置、無線通信方法および集積回路
JP2011259125A (ja) * 2010-06-08 2011-12-22 Sharp Corp 無線通信システム、基地局装置、移動局装置、無線通信方法および集積回路
JP2016119687A (ja) * 2011-09-02 2016-06-30 クゥアルコム・インコーポレイテッドQualcomm Incorporated 低速ワイヤレスネットワークにおけるロングパケットのためのフラグメント化の向上
WO2013076921A1 (ja) * 2011-11-21 2013-05-30 パナソニックモバイルコミュニケーションズ株式会社 無線通信端末装置及び再送制御方法
JP2016178649A (ja) * 2012-06-13 2016-10-06 ケイティー コーポレーションKt Corporation エンコードされたtim情報通信方法

Also Published As

Publication number Publication date
EP3734879A1 (en) 2020-11-04
EP1626518B1 (en) 2020-07-01
EP1626518A2 (en) 2006-02-15
EP1626518A3 (en) 2012-05-09
JP4319654B2 (ja) 2009-08-26

Similar Documents

Publication Publication Date Title
US8416809B2 (en) Apparatus for reporting reception result of packets in mobile communication system
JP4537410B2 (ja) 移動通信システムにおける自動再送要求のためのフィードバックメッセージ生成方法
CN100413241C (zh) 数据重传方法
US8397119B2 (en) Apparatus and method for generating automatic repeat request (ARQ) feedback message in wireless communication system
EP1281248B1 (en) Transmitting and receiving data according to radio link protocol in a mobile communications system
US8949682B2 (en) Apparatus and method for generating ARQ feedback message in wireless communication system
EP1211840A1 (en) Hybrid ARQ with parallel packet transmission
JP2003514486A (ja) マルチチャネル・ストップ・アンド・ウェイトarq通信のための方法および装置
JP4319654B2 (ja) 移動通信システムにおけるパケット受信結果報告方法
CN103999394B (zh) 数据重传、反馈方法,以及相应的装置
KR101075722B1 (ko) 이동통신시스템에서의 패킷 처리 결과 통보방법
KR100981541B1 (ko) 이동통신시스템에서 패킷 수신 결과 보고방법
US11463201B2 (en) HARQ TXOP frame exchange for HARQ retransmission using HARQ threads
KR101656999B1 (ko) 무선 랜의 협력 통신 방법 및 시스템
KR100651441B1 (ko) 비트맵 구성과 이를 이용한 패킷 재전송 방법
KR101338476B1 (ko) 무선 네트워크에서 멀티캐스트 송신을 위한 방법 및 장치
CN103078722A (zh) 一种请求数据重传的方法及装置
KR101201898B1 (ko) 무선통신시스템에서 자동 재전송 요청 피드백 메시지 생성 장치 및 방법
JP2006148784A (ja) 通信方法、及び通信装置
CN115664603A (zh) 一种报文的重传方法
US20170041101A1 (en) Re-transmission control method and communication device

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080304

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080521

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081014

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090507

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090528

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120605

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4319654

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120605

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130605

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250