JP4842830B2 - データパケットの伝送 - Google Patents

Description

本発明は、データパケットが送信局から受信局へ送信されるか又は両局間で交換されるようなデータ伝送の分野に関する。特に、本発明は、データパケットを送信局から受信局へ送信する方法、データパケットを送信局から受信局へ送信するデータ通信システム、通信システム用の送信局、通信システム用の受信局、及び送信局から受信局へのデータパケットの送信を実行するソフトウェアプログラム製品に関する。

データパケットを送信機と受信機との間で伝送する方法及び対応するデータ伝送システムは、例えば、3GPP TS 25.308 V5.2.0 (2002-03)、技術仕様、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；高速ダウンリンクパケットアクセス(HSDPA)；全体記述；ステージ２（リリース５）、及び3GPP TS 25.321 V5.2.0 (2002-09)、技術仕様、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；ＭＡＣプロトコル仕様（リリース５）に記載されており、これら文献は共に参照により本明細書に組み込まれるものとする。

この方法によれば、データはダウンリンクにおいて、即ち高速ダウンリンク共有チャンネル（HS-DSCH）を介してノードＢにおけるＵＭＴＳ送信機からＵＭＴＳ移動局における受信機又はＵＥ（ユーザ装置）へ高速で送信される。ＭＡＣ層のサブレイヤ、所謂ＭＡＣ-hsレイヤ（hsは高速）においては、ＨＡＲＱ再送信プロトコル制御がＭＡＣ-hs ＰＤＵの再送信を制御する。移動局の受信機においては、再送信されたＭＡＣ-hs ＰＤＵのソフトビットが、このＭＡＣ-hs ＰＤＵの以前の送信のソフトビットとソフト合成される。ＭＡＣ-hsレイヤはノードＢ上に位置する。ＨＡＲＱ再送信プロトコルのピア（peer）エンティティは、従って、ノードＢ及び移動局又はＵＥ上に位置する。

ＨＡＲＱ再送信プロトコル（以下においては、第２再送信プロトコルと称す）に加えて、本発明においては当該状況に関連する他のプロトコルが存在する。これは、所謂無線リンク制御（ＲＬＣ）プロトコル（以下においては、第１再送信プロトコルと称す）であり、そのピアエンティティは移動局のサービス中のＲＮＣ（無線ネットワークコントローラ）及び移動局上に位置する。無線リンク制御プロトコル（ＲＬＣプロトコル）の詳細、例えば肯定応答モード（ＡＭ）及び非肯定応答モード（ＵＭ）データ送信、に関しては、3GPP TS 25.322 V5.2.0 (2002-09)、技術仕様、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク（参照により、本明細書に組み込まれるものとする）を参照されたい。

このＲＬＣプロトコルは：
− ＲＬＣ ＳＤＵ（サービスデータ単位、即ちＲＬＣレイヤより上の次に高いレイヤから受信されるデータ単位）の、ＲＬＣ ＰＤＵ（プロトコルデータ単位、即ちＲＬＣレイヤが次に低いレイヤ（ここではＭＡＣレイヤ）に渡すデータ単位）の一部として送信されるようなフラグメントへの区分化、及び、該当するなら、異なるＲＬＣ ＳＤＵ又は異なるＲＬＣ ＳＤＵのフラグメントのＲＬＣ ＰＤＵへの連結を実行する、
− （それに応じて構成されているなら）、受信機が送信機に対して正しく受信されなかったと示すＲＬＣ ＰＤＵの再送信を制御する、
ことの責務を負う。

データがＨＳ−ＤＳＣＨを介して送信される場合、このデータも常にＲＬＣプロトコルエンティティによりＨＡＲＱプロトコル上で処理され、この場合（即ち、データがＨＳ−ＤＳＣＨを介して送信される場合）、このＲＬＣプロトコルエンティティは：
− 肯定応答モード（ＡＭ）データ送信、又は
− 非肯定応答モード（ＵＭ）データ送信、
用に構成することができる。

“肯定応答モードデータ”も、ＡＭＤと略称され、“非肯定応答モードデータ”はＵＭＤと略称される。

ＵＭＤ及びＡＭＤの両送信において、ＲＬＣ ＰＤＵはシーケンス番号を有し、ここで、該シーケンス番号を符号化するためにＵＭは７ビットを定め、ＡＭは１２ビットを定める。これは、ＵＭにとり０〜１２７のシーケンス番号範囲、ＡＭにとり０〜４０９５のシーケンス番号範囲に相当する。ＡＭＤ送信用に構成された場合、ＲＬＣプロトコルはＲＬＣ ＳＤＵのＲＬＣ ＰＤＵへの区分化（及び、当てはまるなら連結）を実行すると共に、再送信を実行することによりデータ送信の信頼性を改善する。ＵＭＤ送信用に構成された場合、ＲＬＣプロトコルは区分化及び、当てはまるなら、連結のみを実行する。

送信側では、ＲＬＣ ＰＤＵはＭＡＣレイヤ（又は、より正確にはＭＡＣ-dレイヤ）により更に処理され、該レイヤは論理チャンネルが区別されねばならないならＭＡＣヘッダを追加することができる。このＭＡＣヘッダは、ＲＬＣ ＰＤＵが送信される論理チャンネルを識別する。次いで、ＭＡＣ-d ＰＤＵ（即ち、ＭＡＣ-dレイヤにより生成されたプロトコルデータ単位）が、ＵＭＴＳのノードＢに配置されたＭＡＣ-hsレイヤに供給される。ここで、同一の移動局を宛先とする１以上のＭＡＣ-d ＰＤＵがＭＡＣ-hs ＰＤＵに編集される。これらのＭＡＣ-d ＰＤＵは異なる論理チャンネルに属する、即ち異なるＭＡＣヘッダを有する可能性がある。従って、ＭＡＣ-hs ＰＤＵは、異なる論理チャンネルのものであるが、同一の受信移動局に対するＭＡＣ-d ＰＤＵを多重化する。これとは対照的に、１つのＭＡＣ-d ＰＤＵは常に正確に１つのＲＬＣ ＰＤＵを含む。

１以上のＭＡＣ-d ＰＤＵから編集されたＭＡＣ-hs ＰＤＵは、更に物理レイヤにより処理される。一般的に、物理レイヤがＨＳ−ＤＳＣＨ状況において処理するデータ単位は、トランスポートブロックと呼ばれる。即ち、ＭＡＣ-hs ＰＤＵもトランスポートブロックであり、トランスポートブロック（即ち、ここではＭＡＣ-hs ＰＤＵ）を形成するビットの計数はトランスポートブロックサイズと呼ばれる。ＭＡＣ-hs ＰＤＵタイプのトランスポートブロックの物理レイヤの処理は以下の通りである。

物理レイヤは、（２４ビットの）巡回冗長性チェック（ＣＲＣ）サムを追加し、この追加後に、（タイプＭＡＣ-hs ＰＤＵの）トランスポートのビット及びＣＲＣビットにレート1/3ターボ符号化を適用する（即ち、ターボ符号化から結果として得られるパリティビットを追加する）。これは、3GPP TS 25.212 V5.2.0 (2002-09)、第３世代パートナーシップ・プロジェクト；技術仕様グループアクセスネットワーク；多重化及びチャンネル符号化（ＦＤＤ）（リリース５）に記載されており、該文献は参照により本明細書に組み込まれるものとする。

更に、TS 25.212 V5.2.0に記載されているようにレートマッチングが適用され、該レートマッチングは、レート1/3ターボコーダの出力であるビットの数を、エアインターフェースを介して２ｍｓ内に送信することが可能なビット数に調整する。エアインターフェースを介して２ｍｓ内に送信することが可能なビット数は、選択されたチャンネル化コード（１〜１５を使用することができ、これらは全て１６なる拡散係数を有する）に、及びＱＰＳＫ（４位相偏移変調）又は１６ＱＡＭ（直交振幅変調）とすることが可能な選択された変調方法に依存する。例えば、１６ＱＡＭで２ｍｓ内に送信することが可能なビット数は、ＱＰＳＫで送信することが可能なビット数より２倍大きい。

レートマッチングは、例えばパンクチャ処理を、即ちレート1/3ターボコーダの出力であるビットのシーケンスにおける所定のビットを、結果としてのビット数が２ｍｓ内にエアインターフェース上で送信することが可能なビット数に正確に合致するように削除する処理を意味することができる。受信側は、パンクチャ処理されたビットの位置が分かり、これらビットを復号処理において、例えば値零のビットと見なす。

パンクチャ処理が適用されるべき場合、順方向エラー保護（ＦＥＣ）は、パンクチャ処理無しよりも必然的に弱くなる。パンクチャ処理は、例えばエアインターフェース上での送信のために１以上の追加チャンネル化コードが使用される場合は回避することができる。

考察されるＭＡＣ-hs ＰＤＵに対しては、特定のタイプのレートマッチングが適用されると共に、変調方法ＱＰＳＫ及び１６ＱＡＭの一方を選択することができる。このレートマッチング及び変調方法の組み合わせは、符号化及び変調方法と称すこともできる。

TS 25.212 V5.2.0はＭＡＣ-hsタイプのトランスポートブロックの物理レイヤ処理についての幾つかの更なるステップを記載しているが、これらは本発明の状況においては重要ではないであろう。

上記２ｍｓの期間は、ＨＳ−ＤＳＣＨの送信時間間隔（ＴＴＩ）とも呼ばれる。これは、（ＭＡＣ-hsタイプの）トランスポートブロックが物理レイヤにより無線インターフェース上で伝送される周期性に等しいから、物理レイヤにおける（ＭＡＣ-hsタイプの）トランスポートブロックの到達間時間、即ちＭＡＣレイヤと物理レイヤとの間でのデータの連続する供給の間の時間にも相当する。言い換えると、物理レイヤは２ｍｓなるＴＴＩ内で或るコンテナのビット、即ちＭＡＣ-hs ＰＤＵのビットを処理し、２ｍｓ後に次のコンテナのビットを処理する準備が整う。原理的に、ＣＲＣの付加及びターボ符号化によるチャンネル符号化により、この場合にエアインターフェース上で送信されるビット数は上記コンテナのビット数より大きい。物理レイヤが２ｍｓなるＴＴＩ内でエアインターフェース上を送信することができる（ターボ符号化後に）ビット数Ｘが、異なるサイズ（即ち、異なるビット数）の２つのコンテナに対して一定に維持される場合（この場合、コンテナのサイズはＸ−２４（２４のＣＲＣビットに相当する）より小さい）、小さい方のコンテナのＦＥＣは、例えば該小さい方のコンテナには少ないパンクチャ処理しか適用されないので、大きい方のコンテナのものより強くなる。同様に、所与のサイズＳのコンテナが物理レイヤ処理の後に一度はエアインターフェース上をＸビット（Ｘ＞Ｓ＋２４）で送信され、一度はエアインターフェース上をＹ＞Ｘビットで送信された場合、ＦＥＣは、Ｙビットがエアインターフェース上での送信に使用される場合の方が通常は強い。

以下においては、ＵＭＴＳとの関連では、“コンテナ”なる用語はＭＡＣ-hs ＰＤＵの、即ちＭＡＣ-hs ＰＤＵタイプのトランスポートブロックのビットを示す。

先に引用したリリース５におけるＵＭＴＳのＭＡＣ-hsにおけるＨＡＲＱプロトコルによれば、最後の再送信においても成功しないで、即ち受信されたＭＡＣ-hs ＰＤＵをエラー無しで復号することができずに最大再送信数に到達したような、ＭＡＣ-hs ＰＤＵ（プロトコルデータ単位、即ちプロトコルレイヤから下側のプロトコルレイヤに渡されるデータパケット）のロスを許容すると仮定されている。その場合、このＭＡＣ-hs ＰＤＵの送信は中止され、該ＰＤＵに含まれる全てのＲＬＣ−ＰＤＵは破棄される。結果として、これらの失われたＲＬＣ−ＰＤＵはＲＬＣプロトコルレベルで再送信されねばならず（これは、再送信がＲＬＣプロトコルにより実行され、再送信されるＰＤＵがＲＬＣ ＰＤＵであることを意味する）、結果的に大きな遅延になる。何故なら、ノードＢとＤＲＮＣとの間及びＤＲＮＣとＳＲＮＣとの間の各々のＩｕｂ及びＩｕｒインターフェースを通過しなければならないからである。ＤＲＮＣはドリフトＲＮＣ（無線ネットワークコントローラ）とも呼ばれる。自身の対応するサービス中のＲＮＣ（ＳＲＮＣ）のサービス領域から離れた移動局は、他のＲＮＣによりサービスされるセル内に位置する。この場合、この他のＲＮＣは考察中の移動局のドリフトＲＮＣと称される。

ＵＭＴＳのＲＬＣ（無線リンク制御）プロトコルは、ＡＭ（肯定応答モード）ＲＬＣエンティティがＲＬＣ ＰＤＵ（ＲＬＣプロトコルデータ単位）を送信するためにタイプに応じて２つの論理チャンネルを使用する、即ちＲＬＣデータＰＤＵの送信のために１つの論理チャンネルを設ける一方、ＲＬＣ制御ＰＤＵの送信のために１つの論理チャンネルを設ける、ように構成するのを許容している。斯かる論理チャンネルは異なるＦＥＣ（順方向エラー訂正）を持つトランスポートチャンネルにマッピングすることができるので、再送信にさらされず、同時にＲＬＣプロトコルの正しい動作にとり最も重要であるようなＲＬＣ制御ＰＤＵのために、或る論理チャンネルに、より強いＦＥＣ（順方向エラー訂正）を付与することが可能となる。

データが、動作しているＡＭ ＲＬＣプロトコルでＨＳ−ＤＳＣＨ（高速ダウンリンク共有チャンネル）を介して送信されねばならない場合、タイプＨＳ−ＤＳＣＨのトランスポートチャンネルは１つしかないので、論理チャンネルは、異なるトランスポートチャンネル（例えば異なるＦＥＣを持つ）にはマッピングすることはできず、ノードＢ上のＭＡＣ-hsエンティティにおける異なる優先度分類にしかマッピングすることができない。ノードＢ上のＭＡＣ-hsは、この優先度情報のみを有し、データパケットの重要度に関する情報は有さず、かくして、これはノードＢに対し、一層強固なＭＣＳ（変調及び符号化方法）を適用する必要性を示す。より強いＦＥＣを達成するために“優先度”属性を使用する結果、優先化された処理となり、かくして、ＲＬＣ制御ＰＤＵはＲＬＣデータＰＤＵを追い抜きそうである。結果として、ＲＬＣプロトコル処理は重大に妨害され得る（例えば、ＭＲＷ制御ＰＤＵが送信され、又はＲＬＣ ＲＥＳＥＴ手順が起動された場合）。何故なら、該処理は制御及びデータＰＤＵの順番通りの供給に頼るからである。

本発明の目的は、制御情報を含むデータパケットの改善された伝送法を提供することにある。

請求項１に記載の本発明の一実施例によれば、送信局から受信局へ第１データパケット及び第２データパケットを送信する方法が提供される。上記第１データパケットは特には制御命令等の第１データを有し、上記第２データパケットは第２データを有する。更に、上記第１データパケット及び第２データパケットは送信局から受信局へコンテナ内で送信される。本発明の該実施例によれば、第１コンテナは、少なくとも１つの第１データパケットを有すると共に、第１エラー符号化が提供される。一方、第２コンテナは少なくとも１つの第２データパケットを有するが、第１データパケットは有さず、該第２コンテナには第２エラー符号化が提供される。前記第１エラー符号化は該第２エラー符号化より強い。

言い換えると、２つのタイプのコンテナが設けられ、これらコンテナにおいて第１及び第２データパケットを送信することができる。第１タイプのコンテナには第２タイプのコンテナよりも強いエラー符号化が付与され、制御命令を有するデータパケットは、より強いエラー訂正を備える第１タイプのコンテナにおいてのみ送信される。制御命令は、第１再送信プロトコルに関係する制御命令とすることができる。

特に制御命令を含むような第１データパケットを、第２タイプのコンテナよりも強いエラー符号化及びエラー訂正を備える第１タイプのコンテナにおいてのみ送信することは、制御命令を有するデータパケット、即ち第１データパケットのエラー無し送信の率を上昇させ得る。

異なるタイプの制御命令が存在し得、幾つかのものは失われないことが重要なものであり、他のものは、時よりは又は上記重要な制御命令よりも高頻度でロスが耐えられ得るものであって、一層頻繁に送信され得るものである。

本発明の他の実施例によれば、上記第２データパケットはデータを有するのみならず、時にはロスが耐えられるものであって、一層頻繁に送信され得るような制御命令も有する。

ＵＭＴＳリリース99,4及び5においては、ロスが可能な限り避けられるべき斯かる最も重要な制御命令は、以下のものである：
− RESET PDU及びRESET ACK PDU；
− MRW SUFI（ムーブ受信ウィンドウスーパーフィールド）を含むSTATUS PDU、及びMRW_ACK（ムーブ受信ウィンドウ肯定応答スーパーフィールド）を含むSTATUS PDU；並びに
− WINDOW SUFI（即ち、ＲＬＣプロトコルの受信者が送信者に送信ウィンドウを変更するよう、特にそのサイズを減少するよう告げるスーパーフィールド）を含むSTATUS PDU。

ロスが時には又は重要な制御命令のロスよりも高頻度で耐えられ得るような余り重要でない制御命令はTS 25.322に規定された残りのＲＬＣ制御ＰＤＵ、即ち、特には、MRW SUFI又はMRW SUFI ACKを含まないが、STATUS PDUを送信したＲＬＣエンティティが正しく受信したか又は送信されるのを依然として期待しているＲＬＣ ＰＤＵについての情報を帯びているSTATUS PDUである。

請求項２に記載の本発明の他の実施例によれば、第１コンテナで送信される第１データペイロードが第２コンテナで送信される第２データペイロードより小さくなるように、第１コンテナ内の第１及び第２データパケットの数は第２コンテナ内の第２データパケットの数よりも少ない。

言い換えると、第１データパケットは第２データパケットと一緒に、第２データパケットを専ら含む第２コンテナのエラー保護よりもエラー保護が強い第１コンテナで送信される。本発明の該実施例によれば、この改善されたエラー保護は、第１コンテナに含まれる第１及び第２データパケットの数を減少させる一方、この第１コンテナに関してチャンネル符号化及びレートマッチング後にエアインターフェースを介して送信される全体のビット数を一定に維持することにより達成される。言い換えると、含まれるデータペイロードが減少され、且つ、例えばパリティ情報ビット（パリティビット）の数が増加される。無線インターフェースを介して送信される符号化ビットが一定の場合、ペイロードビット（第１又は第２データパケットに含まれる）当たりのパリティビットの数は、従ってＦＥＣは、ペイロードビットが減少するにつれて増加する。

データペイロードなる用語は、実際に送信されるデータに関するもので（制御命令又は例えばユーザデータに関する）、この送信を達成するために使用されるビット、即ちエアインターフェースを介して送信されるパリティビットを含む物理レイヤビットに関するものではない。

請求項３に記載された本発明の他の実施例によれば、第１再送信プロトコルは第１及び第２データパケットにおける第３データパケットの送信又は再送信を制御し、第２再送信プロトコルは第１及び第２コンテナの送信又は再送信を制御する。更に、第１コンテナ及び第２コンテナには対応するコンテナシーケンス番号が設けられ、第２データパケットにおける各データパケットには対応するデータパケットシーケンス番号が設けられる。本発明の該実施例によれば、第１及び第２データパケットが第１及び第２コンテナで送信される際に得られる第１及び第２データパケットの第１順序又はシーケンスは、第１及び第２データパケットが第２再送信プロトコルにより受信される場合の第１及び第２データパケットの第２順序又はシーケンスと較べて変化しないままとなる。

言い換えると、第１及び第２コンテナは第１及び第２データパケットを常に、第１及び第２データパケットが第２再送信プロトコルによりエアインターフェースを介して送信される進行過程において順序の変化が発生しないように含む。しかしながら、これにより、第２データパケットは失われ得る。何故なら、第２データパケットは、場合によっては、不利なチャンネル条件により失われるからである。

請求項４に記載の本発明の他の実施例によれば、第２再送信プロトコルは、第２再送信プロトコルが該第２再送信プロトコルより上に位置する第１再送信プロトコルから受信する第４データパケットが第１データパケットであるか又は第２データパケットであるかを決定する。

請求項５に記載の本発明による他の実施例によれば、第２再送信プロトコルは、第４データパケットが、第１再送信プロトコルにより該第４データパケットに関連付けられたヘッダ情報を解析することにより第１データパケットであるか又は第２データパケットであるかの判定を実行する。この判定はスケジューラにより実行することができ、該スケジューラは受信される全ての第１及び第２データパケットのヘッダ情報を読み取り、このヘッダの第１ビットに基づいて当該データパケットが制御命令を含む第１データパケットであるか又はデータを含む第２データパケットであるかを決定する。

請求項６に記載の本発明による他の実施例によれば、第４データパケットは、第２送信プロトコルより上に位置する第１送信プロトコルから該第２送信プロトコルに伝達される際に、該第４データパケットが第１データパケットであればラベル付けされる。

言い換えると、本発明の該実施例によれば、第１データパケットは第２データパケットとは異なる論理チャンネルで送信することができ、従って、第１送信プロトコルを実施するネットワークノードと第２送信プロトコルを実施するネットワークノードとの間のデータパケットの送信のためのフレームプロトコル又は同様のエンティティは、対応する論理チャンネルから、当該データパケットが制御命令を有するか又は非制御データを有するかを決定することができる。この場合、上記フレームプロトコルは制御情報を有するデータパケット（定義により、第１データパケットである）に、第２送信プロトコルがヘッダの解析無しで受信データパケットのどれが第１データパケットであり、どれが第２データパケットであるかを即座に認識することができるように、マークを付す。

請求項７に記載の本発明の他の実施例によれば、本方法は、ＵＭＴＳにおける高速ダウンリンク共有チャンネル上でのデータ送信に適用される。

請求項８に記載の本発明の他の実施例によれば、第１データパケットはＲＬＣ制御ＰＤＵであり、第２データパケットはＲＬＣデータＰＤＵである。

請求項９に記載の本発明の他の実施例によれば、第１再送信プロトコルは第１及び第２データパケットにおける第３データパケットの送信又は再送信を制御し、第２再送信プロトコルは第１及び第２コンテナの送信又は再送信を制御する。第１コンテナ及び第２コンテナには対応するコンテナシーケンス番号が設けられる一方、第２データパケットの各データパケットには対応するデータパケットシーケンス番号が設けられ、第１再送信プロトコルの受信側エンティティは、シーケンス番号が受信ウィンドウの外となる第２データパケットを破棄する。本発明の該実施例によれば、第１再送信プロトコルの２つのピアエンティティのうちの第１エンティティは両ピアエンティティのリセットを開始することができ、該リセットは第１データパケットの第１及び第２リセットメッセージにより実行され、該リセットは第１エンティティに第２エンティティに対する第１リセットメッセージを送信させると共に、該第１リセットメッセージに応答して第２エンティティに第１エンティティに対する第２リセットメッセージを送信させ、第１リセットメッセージは第２エンティティの受信ウィンドウの下側エッジを、第１エンティティの送信ウィンドウの、当該リセット前に使用されていた下側エッジに等しく設定し、第２リセットメッセージは第１エンティティの受信ウィンドウの下側エッジを、第２エンティティの送信ウィンドウの、第１リセットメッセージの受信前に使用されていた下側エッジに等しく設定する。この実施例によれば、ピアエンティティは再送信プロトコルの受信側エンティティ又は送信側エンティティとすることができることに注意しなければならない。

上述した態様によって第１再送信プロトコルをリセットメッセージによりリセットするため、第１データパケット、特にはリセットメッセージを含む第１データパケット（又は複数のパケット）が第２データパケットに追いついても、第１再送信プロトコルの受信側エンティティは、リセット後に第１再送信プロトコルの送信側エンティティにより送信されなかった第２データパケットはどれも受け付けないようになり得る。これは、リセットの妨害が最小に維持されることを、特に、第１再送信プロトコルを実施するレイヤのサービスデータ単位が、リセット前に送信され該リセットにより古くなったが該リセット後に受信されるような第２データパケットに含まれる無効なセグメントから再組立されるのを可能にすることができる。

請求項１０に記載の本発明の他の実施例によれば、第１データパケット及び第２データパケットを送信局から受信局へ送信する通信システムが提供され、上記第１データパケットは第１データ、特には制御命令を有し、上記第２データパケットは第２データを有する。また、本発明の該実施例の一態様によれば、第１データパケット及び第２データパケットは送信局から受信局へ第１コンテナ及び第２コンテナで送信され、第１コンテナは少なくとも１つの第１データパケットを有し、第２コンテナは少なくとも１つの第２データパケットを有するが、第１データパケットは有さない。更に、第１コンテナには第１エラー符号化が提供される一方、第２コンテナには第２エラー符号化が提供され、第１エラー符号化は第２エラー符号化よりも強い。

請求項１１に記載の本発明の他の実施例によれば、自身から受信局へ第１データパケット及び第２データパケットを送信する送信局が提供され、第１及び第２データパケットを有する第１及び第２コンテナの送信を可能にし、第１コンテナは少なくとも１つの第１データパケットを有し、第２コンテナは少なくとも１つの第２データパケットを有するが、第１データパケットは有さず、第１コンテナには第２コンテナより強いエラー符号化が付与される。

請求項１２に記載の本発明の他の実施例によれば、送信局から第１データパケット及び第２データパケットを受信する受信局が提供され、該受信局は異なる強さのエラー符号化が付与されるような異なるタイプのコンテナを受信するように構成される。

請求項１３に記載の本発明の他の実施例によれば、例えば通信システムにおけるデータプロセッサが送信局から受信局への第１データパケット及び第２データパケットの送信を実行するためのソフトウェアプログラム製品が提供される。本発明による該ソフトウェアプログラム製品は、好ましくは、データプロセッサのワーキングメモリにロードされる。該データプロセッサは、例えば請求項１に記載したような本発明の方法を実行するように構成される。当該ソフトウェアプログラム製品は、ＣＤ−ＲＯＭ等のコンピュータ読み取り可能な媒体上に記憶することができる。また、当該コンピュータプログラムはワールドワイドウェブ等のネットワークを介して提供することもでき、斯様なネットワークから上記データプロセッサのワーキングメモリにダウンロードすることができる。

データパケットが送信される２つのタイプのコンテナが設けられ、第１タイプのコンテナには第２タイプのコンテナより強いエラー符号化が付与され、当該送信又はシステムのための制御命令を有するデータパケットは一層強いエラー訂正を備える第１タイプのコンテナでのみ送信されることが、本発明の実施例の骨子であると見ることができる。このため、本発明の一実施例によれば、ＡＭデータがＨＳ−ＤＳＣＨを介して送信される場合、ＵＭＴＳのＡＭ ＲＬＣプロトコルの制御ＰＤＵに対する改善された順方向エラー訂正を提供することができる。

本発明の上記及び他の態様は、以下に述べる実施例から明らかとなり、斯かる実施例を参照して解説されるであろう。

以下、本発明の実施例を、図面を参照して説明する。

図１は、本発明による伝送システムの一実施例に適用することができる、本発明の一実施例による送信機又は受信機のレイヤの簡略図を示す。本発明の好ましい実施例によれば、データ伝送システム並びに該システムに伴う本発明の実施例による送信機及び受信機は、3GPP TS 25.308 V5.4.0 (2003-03)、技術仕様、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；高速ダウンリンクパケットアクセス(HSDPA)；全体記述；ステージ２（リリース５）、及び3GPP TS 25.321 V5.5.0 (2003-06)、技術仕様第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；ＭＡＣプロトコル仕様（リリース５）に従って構成されており、上記文献は共に参照により本明細書に組み込まれるものとする。

上記技術仕様に従い、ＨＳ−ＤＳＣＨ（高速ダウンリンク共有チャンネル）において異なるコンテナサイズが定義される。言い換えると、該コンテナサイズは、物理レイヤがＭＡＣレイヤから受信し、次いで上記技術仕様に規定されているようにＣＲＣの付加、並びにパリティ又はエラー保護ビットの追加を含むエラー訂正符号化及びレートマッチングの適用の後にエアインターフェースを介して送信されるビット数を示す。無線チャンネル上に良好なチャンネル条件が存在する場合、相対的に大きなコンテナを送信機から受信機へ高い確率でエラー無しで送信することができる。しかしながら、困難な又は悪いチャンネル条件が存在する場合は、成功する送信の確率を最大化するために、より小さなコンテナサイズを選択しなければならない。

ＲＮＣ（無線ネットワークコントローラ）上のＲＬＣプロトコルにおいては、ＲＬＣレイヤより上のレイヤから受信されたＲＬＣ ＳＤＵ（サービスデータ単位）等のデータパケットは、所定の区分化サイズを持つ部分に区分化される。一般的に、考察中のプロトコルレイヤのサービスデータ単位（ＳＤＵ）は、関連文献では、この考察中のプロトコルレイヤが次に高いプロトコルレイヤから受信するデータ単位と定義されている。考察中のプロトコルレイヤはＳＤＵを処理し、これは、ＲＬＣプロトコルの場合には、例えば該ＳＤＵがフラグメントに区分化されることを意味する。プロトコル処理の結果として、ＳＤＵは１以上のＰＤＵ（プロトコルデータ単位）に変換され、これらＰＤＵは、ＲＬＣプロトコルの場合には、例えば区分化されたＳＤＵの各々の１つのフラグメントを含む。連結が可能な場合には、２以上のフラグメントが含まれる。これらのフラグメントは、少なくともシーケンス番号を含むＲＬＣヘッダを備えると共に、ＲＬＣ ＰＤＵのペイロード又はコンテンツを形成する。一般的に、考察中のプロトコルレイヤのＰＤＵは、該考察中のプロトコルレイヤが次に低いプロトコルレイヤに供給するデータ単位として定義されている。これらのＲＬＣ ＰＤＵは、ＭＡＣ-dレイヤで処理され、該レイヤにおいて上記ＰＤＵには例えばＭＡＣヘッダを設けることができる。次いで、ＲＬＣ ＰＤＵ（ＭＡＣヘッダを伴う又は伴わない）は、ＭＡＣ-d ＰＤＵとして下に隣接するプロトコルレイヤに渡される。ＨＳ−ＤＳＣＨを介するデータ送信の場合、該下に隣接するプロトコルレイヤはＭＡＣ-hsレイヤであり、該ＭＡＣ-hsレイヤは、図２から分かるように、ノードＢ上に位置する。

図１から分かるように、ＭＡＣ-hsレイヤは、各々が正確に１つのＲＬＣ-ＰＤＵを含むような（図１はＡＭの場合を考察しているが、ＵＭに関しても同様のことが成り立つ）受信されたＭＡＣ-d ＰＤＵを処理すると共に、これらを、ＨＳ−ＤＳＣＨを介して、次いで無線インターフェース又はエアインターフェースを介して送信するためにＭＡＣ-hs ＰＤＵに投入する。例えば、ＭＡＣ-hsレイヤはチャンネル品質推定に基づいて、エアインターフェースを介してＨＳ−ＤＳＣＨ上で送信される次のＭＡＣ-hs ＰＤＵに対して、どのコンテナサイズ、即ちどのＭＡＣ-hs ＰＤＵサイズが選択されるべきかを決定することができる。ＲＬＣ-ＰＤＵサイズ（これは、各ＭＡＣ-d ＰＤＵのサイズも決定する）が与えられると、ＭＡＣ-hs ＰＤＵは、コンテナの選択されたサイズに応じて、複数のＭＡＣ-d ＰＤＵ（及び、これに伴いＲＬＣ-ＰＤＵ）を含むことができる。

区分化サイズは、所謂ＲＬＣ ＰＤＵサイズからＲＬＣ ＰＤＵのヘッダのためのビットを引くことにより与えられる。ＭＡＣ-d ＰＤＵのサイズは、ＲＬＣ ＰＤＵサイズとＭＡＣヘッダのサイズとの和から決定することができる。ＨＳ−ＤＳＣＨを除く他のチャンネルにおいては、ＭＡＣ-d ＰＤＵのサイズは通常はコンテナのサイズと等しいが、ＨＳ−ＤＳＣＨの場合は、この同一サイズなる要件は存在しない。むしろ、ＨＳ−ＤＳＣＨの場合、ＭＡＣ-hs ＰＤＵのサイズがコンテナサイズに対応し、ＭＡＣ-hs ＰＤＵは幾つかのＭＡＣ-d ＰＤＵからなることができる。

ＨＳ−ＤＳＣＨを介してＭＡＣ-hs ＰＤＵを送信するために使用されるべきコンテナサイズ又はＭＡＣ-hs ＰＤＵサイズは、当該ＭＡＣ-hs ＰＤＵのエラー無し送信をなす合理的な高い確率を達成するために、現チャンネル条件に従って調整されねばならない（即ち、良好なチャンネル条件に対してはコンテナサイズを大きくすることができる一方、悪いチャンネル条件に対してはコンテナサイズは小さくなければならない）。以下の理由により、チャンネル条件を考慮するために、通常は、ＡＭ又はＵＭにおいてＲＬＣ ＰＤＵのサイズを変更することは可能ではない。

０〜４０９５の範囲のシーケンス番号を伴うＲＬＣ ＰＤＵで送信及び再送信が実行されるようなＡＭにおいてデータを送信する場合、ＲＬＣ ＰＤＵのサイズは、送信側及び受信側のＲＬＣマシン又はＲＬＣエンティティの相対的に時間の掛かる再コンフィギュレーションによってのみ変化させ又は変更することができる。このような再コンフィギュレーションは、１００ｍｓと２００ｍｓとの間の時間が掛かり得る。再送信が実行されず、０〜１２７の範囲のシーケンス番号を持つコンテナが使用されるようなＵＭでデータパケットを送信する場合、ＲＬＣ ＰＤＵのサイズは、斯様な時間の掛かる再コンフィギュレーション無しで変更することができる。しかしながら、ＵＴＲＡＮにおけるＲＬＣプロトコルは、通常はＤＲＮＣを介してノードＢに接続されるようなＲＮＣ上に位置する。ＤＲＮＣはドリフトＲＮＣである。この場合、図２から分かるように、２つのインターフェースを通過しなければならない。即ち、ＳＲＮＣとＤＲＮＣとの間に位置するＩｕｒ、及びＤＲＮＣとノードＢとの間に位置するＩｕｂである。これは遅れを生じ得る。

更に、ＲＮＣからノードＢにデータを送信するためには、通常、往復時間の半分が必要である。全往復時間は、ＲＮＣからＵＥ又は移動局へのデータの送信から、該ＲＮＣにおける応答の受信までの時間に関係する。通常、全往復時間は１００ｍｓ（最悪の場合）の範囲内である。言い換えると、ＲＮＣとノードＢとの間のデータ送信は５０ｍｓまでの時間を要し得る。このような長いデータ送信時間により、ＵＭデータ送信の場合、ＲＬＣ ＰＤＵサイズは非常に高速では変更することができない。ＳＲＮＣ上の対応するＲＬＣマシンに対して例えば今から２倍のＲＬＣ ＰＤＵサイズが可能になるということを示すような、ノードＢからＳＲＮＣへ送信される制御メッセージは、該ＲＬＣマシンに５０ｍｓまでもの時間後にのみ到達するであろう。また、これは、この変更されたサイズを持つＲＬＣ ＰＤＵ（ＭＡＣ-d ＰＤＵにパケット化された）がＭＡＣ-hsレイヤにおいて受信されるまでに、５０ｍｓまでの更なる時間を要するであろう。

しかしながら、無線チャンネルは一層速く劇的に変化し得るので、コンテナサイズの調整、即ちＭＡＣ-hs ＰＤＵのサイズの実際のチャンネル条件への調整は、ＵＭ又はＡＭに対してＲＬＣ ＰＤＵのサイズを変更することにより可能な限り速く完了しなければならない。さもなければ、当該コンテナにおいて伝送されるべき１以上のＲＬＣ ＰＤＵのＲＬＣ ＰＤＵサイズが過度に大きく選定されたためにコンテナサイズが過度に大きく選択されると、ＭＡＣ-hsレベル上での再送信の量が著しく増加する。

上述した理由により、肯定応答モード（ＡＭ）及び非肯定応答モード（ＵＭ）においてもＲＬＣ ＰＤＵサイズを、単一のＲＬＣ ＰＤＵ又は非常に少数のＲＬＣ ＰＤＵが、非常に悪いチャンネル条件においても合理的なほど高い確率の成功する送信が推定され得るような最小のコンテナに収容することができるように、選択することも有利であり得る。

ＭＡＣ-hs ＰＤＵは優先度指示子（８つの異なる優先度値）を持つ無線インターフェースを介して送信される。即ち、この指示子（インジケータ）はチャンネル状バンドリングを表し、これにより、これらの斯様に定義された８個のチャンネルは優先度のみが互いに相違する。ノードＢ上のＭＡＣ-hsがＭＡＣ-d ＰＤＵを受信するＭＡＣ-dフロー及びＭＡＣ-dフロー内の論理チャンネルと、これら優先度等級との間のマッピングの定義により、スケジューラは個々の論理チャンネルのＭＡＣ-d ＰＤＵを個々の優先度等級に割り当てると共に、これらを必要な優先度のＭＡＣ-hs ＰＤＵで送信する。ＲＬＣ ＡＭにおけるデータ送信の間においては、ＲＬＣデータＰＤＵに加えて、ＲＬＣ制御ＰＤＵも送信機と受信機との間で交換され、斯かる制御ＰＤＵにより送信機及び受信機の両者からのＲＬＣプロトコルを制御することができる。例えば、送信機はＲＬＣ ＲＥＳＥＴ ＰＤＵの送信によりＲＬＣ ＲＥＳＥＴを開始することができる。即ち、受信機はコンフィギュレーション可能なパラメータを自身の初期値に割り当て、全ての残りのＲＬＣ ＰＤＵ及びＲＬＣ ＳＤＵをキャンセルする。同様に、同様の手順を送信機の側でも実行することができる。

ＲＬＣプロトコルは、サブレイヤがＰＤＵを、送信機の側で送信された順序で受信側に送信するとの仮定で開発された。ＲＬＣ制御ＰＤＵは、ＡＭ ＲＬＣプロトコルの正しい動作にとり非常に重要である。このような理由により、ＲＬＣ制御ＰＤＵが無線インターフェースにおいて失われないことが極めて重要である。かくして、ＵＭＴＳリリース９は、ＲＬＣ ＰＤＵは２つの異なる論理チャンネル上で送信することができ、これにより一方の論理チャンネルは専らＲＬＣ制御ＰＤＵのために使用され、この論理チャンネルは特に良好なＦＥＣ（順方向エラー訂正）のトランスポートチャンネルによりもたらされると規定している。送信されるＲＬＣ制御ＰＤＵ及びＲＬＣデータＰＤＵの元の順序の変化を防止するために、両論理チャンネルは同一の優先度を有さなければならない。これにより、これらはＲＬＣレイヤからＭＡＣレイヤへ２つの異なるサービスアクセスポイントを介して送信されるが、それにも拘わらず、これらはＭＡＣレイヤに該優先度で規定されたのと同じ行列で挿入される。ＲＬＣレイヤはＲＬＣデータＰＤＵ及びＲＬＣ制御ＰＤＵをＭＡＣレイヤに対応するサービスアクセスポイントを介して順に送信されるとの仮定で、ＲＬＣデータＰＤＵ及びＲＬＣ制御ＰＤＵは、ＲＬＣレイヤからＭＡＣレイヤに送信された実際の順序で待ち行列に現れることを保証することができる。

順番の変化の結果としての問題を解説するための例：
ＨＳ−ＤＳＣＨ（高速ダウンリンク共有チャンネル）により以下において解説されるように、例えば前に送信されたＲＬＣデータＰＤＵにＲＬＣ ＲＥＳＥＴ ＰＤＵが追いつかねばならなかった場合、順番の変化から困難さが生じ得る：
（なかでも）ＲＬＣ ＲＥＳＥＴの場合：
− 全ＲＬＣリセットパラメータは、それらのコンフィギュレーションされたパラメータにより初期化され（即ち、シーケンス番号は再び０から開始し、送信及び受信機ウィンドウは下限が０となるように、即ち受信ウィンドウがシーケンス番号０，１，…，Configured_Rx_Window_Size−１を有するように設定される）、ここでConfigured_Rx_Window_Sizeはコンフィギュレーションされた受信ウィンドウサイズを示し、送信ウィンドウはシーケンス番号０，１，…，VT(WS)−１を有し、ここでVT(WS)は送信ウィンドウ状態変数であり、該変数は現在コンフィギュレーションされている送信ウィンドウサイズを記憶する。
− ＡＭ ＲＬＣマシンにおける（及び受信されたＡＭ ＲＬＣマシンにおける）全てのＲＬＣ ＰＤＵは削除される；
− 当該リセットの前に送信された残りのＲＬＣ ＰＤＵは、送信機及び受信機の側で削除される。

これらのステップは、ＲＬＣマシンがＲＥＳＥＴ ＰＤＵを受信すると起動されるであろう。更に、これらのステップはＲＥＳＥＴを開始したＲＬＣマシンにおいて、該マシンがＲＥＳＥＴ ＰＤＵに応答してＲＥＳＥＴ ＡＣＫ ＰＤＵを受信すると起動されるであろう。開始したＲＬＣマシンは、ＲＥＳＥＴ ＰＤＵを送信した後には、更なるＲＬＣ ＰＤＵは送信しない。

ＲＬＣリセットの開始の１つの理由は、或るＲＬＣ ＰＤＵに対する送信繰り返しの最大数に到達したことであり得る。解放するＲＬＣマシン及びそのピアエンティティの両者が上述したステップを実行しなければならないので、上述した問題にとり、当該ＲＬＣリセットがＳＲＮＣ上の又はＵＥ上のＲＬＣマシンにより開始されるかは重要ではない。

ＲＬＣ ＲＥＳＥＴ手順の成功裏の完了の後、ＵＭＴＳシステムが考察されている本実施例においてはＨＳ−ＤＳＣＨを介してデータを受信する送信側及び受信側ＲＬＣマシンは、ＲＬＣ ＲＥＳＥＴに先行する時間から、記憶されたＲＬＣ ＰＤＵを削除する。殆どの場合、既に送信されたが、肯定応答が受信されていない（ＲＬＣ ＲＥＳＥＴ後に）ような、これらＲＥＳＥＴ ＰＤＵの幾つかは、未だエラー無しでＭＡＣ-hsレベルに送信され得なかった限りにおいて、そして正確には、通常のようにＲＬＣ制御ＰＤＵ（ＲＥＳＥＴ ＰＤＵ及びＲＥＳＥＴ ＡＣＫ ＰＤＵを含む）が他の一層高い優先度の論理チャンネルを介しＲＬＣデータＰＤＵとして送信され、かくしてＲＥＳＥＴ ＰＤＵ又はＲＥＳＥＴ ＡＣＫ ＰＤＵが記憶されたデータＰＤＵに追いつく場合、依然としてノードＢ上のＭＡＣ-ｈｓレイヤに記憶されている。しかしながら、ＲＬＣ ＲＥＳＥＴ後は、ＭＡＣ-ｈｓに依然として記憶されているＲＬＣ ＰＤＵは、データ送信に関して如何なる価値もない。何故なら、受信機は、最早、これらを期待していないからである。ここでは、これらは“孤児ＲＬＣ ＰＤＵ”と定義する。ＲＬＣ ＲＥＳＥＴの後、通常、斯かる“孤児ＲＬＣ ＰＤＵ”はＨＳ−ＤＳＣＨを介して送信される。これらのシーケンス番号がＲＥＳＥＴにより初期化された受信ウィンドウの外側である場合は、これらは規定されたエラー処理により受信側ＲＬＣマシンにより拒絶されるであろう。一方、これらが受信ウィンドウ内である場合、受信側ＲＬＣマシンは、これらを誤って有効なＲＬＣ ＰＤＵとして受け付ける。しかしながら、これらは孤児ＲＬＣ ＰＤＵであるので、これらはＲＥＳＥＴ後には決して送信側ＲＬＣマシンから送信されることはない。しかしながら、ＲＬＣ ＲＥＳＥＴの後、ＳＲＮＣ上の送信側ＲＬＣマシンは“真性の”ＲＬＣ ＰＤＵを同一のシーケンス番号の下で送信し、これらは“孤児ＲＬＣ ＰＤＵ”後にのみ受信機側に到達する。この場合、これら“真性の”ＲＬＣ ＰＤＵは受信機側により二重写しと解釈され、従って拒絶される。受信ウィンドウの残りのシーケンス番号の中で、受信機側は“真性の”ＲＬＣ ＰＤＵを受信する。しかしながら、ＲＬＣ ＰＤＵにおいて受信されたＳＤＵセグメントのＲＬＣ ＰＤＵへの再組み立ては失敗する。何故なら、“孤児ＲＬＣ ＰＤＵ”は有効なＳＤＵセグメントを含まないからである。多くの場合における結果は、ＲＬＣ ＲＥＳＥＴ後に送信されたＲＬＣ ＳＤＵのうちの幾つかの喪失であり、事実、ＲＬＣ ＲＥＳＥＴにより既に喪失されたＲＬＣ ＳＤＵを遙かに超える。ＲＬＣ ＲＥＳＥＴ後に付加的に喪失される、これらＲＬＣ ＳＤＵの数は、受信ウィンドウのサイズに大きく依存する。何故なら、斯かるサイズは、一方においては、“孤児ＲＬＣ ＰＤＵ”の中の幾つかがＲＥＳＥＴ後に初期化された受信ウィンドウ内のシーケンス番号を有するであろう危険性を決定するからである。他方において、送信ウィンドウ（ＳＲＮＣ上の送信ＲＬＣマシン）のサイズは、可能性のある“孤児ＲＬＣ ＰＤＵ”の数を決定し、通常は、同じサイズの受信及び送信ウィンドウが選択される。

更に、ＲＥＳＥＴにより初期化された受信ウィンドウ内のシーケンス番号を持つ“孤児ＲＬＣ ＰＤＵ”の受信の後、ステータスレポートが“孤児ＲＬＣ ＰＤＵ”の正しい受信を確認する一方、送信側は該“孤児ＲＬＣ ＰＤＵ”のシーケンス番号を持つ“真正なＲＬＣ ＰＤＵ”を未だ送信していないということ、即ちステータスレポートが、送信側が未だ送信していないＲＬＣ ＰＤＵのエラー無し受信を示すということが起こり得る。規定されたエラー処理によれば、幾つかの場合においては、これは、TS 25.322の10.1節に記載されている“誤ったシーケンス番号”の評価基準に従って送信側により更なるＲＥＳＥＴ手順が開始されることにつながり得、ＡＭ ＲＬＣ ＰＤＵを伝送する論理チャンネルに関し更なるデータ送信の中断を生じる。

ＭＲＷ ＳＵＦＩ（スーパーフィールド）を含むＳＴＡＴＵＳ ＰＤＵは、該ＰＤＵが通常のＲＬＣデータＰＤＵに追いつき得る場合に、同様の問題は生じないであろう。

ＭＲＷ ＳＵＦＩを含むＳＴＡＴＵＳ ＰＤＵは、“明示的な通知でのＳＤＵ破棄”手順の状況では使用されない。この手順は、ＡＭにおいて、送信側（言い換えると、ＡＭ ＲＬＣプロトコルの送信機）でＲＬＣ ＰＤＵを破棄し、該破棄情報を受信側（言い換えると、ＡＭ ＲＬＣプロトコルの受信機）におけるピアエンティティへ転送するために使用される。この手順によれば、送信機は或る期間又は或る数の送信にわたり成功裏に送信されなかったＲＬＣ ＳＤＵを破棄し、受信機に対してムーブ受信ウィンドウ（ＭＲＷ）ＳＵＦＩを送信する。受信されたＭＲＷ ＳＵＦＩ（受信側で破棄されるべきＲＬＣ ＰＤＵのシーケンス番号を含む。何故なら、これらは破棄されたＳＤＵのフラグメントしか含まないからである）により、受信機は当該ＳＤＵを伝送するＡＭＤ ＰＤＵを破棄すると共に、受信ウィンドウを更新する（即ち、受信ウィンドウの下縁を、破棄されたＳＤＵのフラグメントを含んだＲＬＣ ＰＤＵのシーケンス番号が、最早、当該受信ウィンドウ内とならないように進める）。

ダウンリンクにおいて送信されたＭＲＷ ＳＵＦＩを含むＳＴＡＴＵＳ ＰＤＵが、このＳＴＡＴＵＳ ＰＤＵより前に送信されたＲＬＣデータＰＤＵに追いついた場合、追いつかれたＲＬＣデータＰＤＵに対して下記が成り立つ。これらの幾つかがＳＤＵ破棄手順により破棄されるべきＲＬＣ ＰＤＵに等しいか、又はこれらの何れもがそうでないかである。等しいものは、ＳＤＵ破棄手順が完了した後に受信された時に破棄される。何故なら、該手順は、これらＲＬＣ ＰＤＵのシーケンス番号が、これらＲＬＣ ＰＤＵがＳＤＵ破棄手順の完了後に受信されるなら受信ウィンドウの外側であることを確かめるからである。

従って、ＲＬＣ ＲＥＳＥＴ ＰＤＵ又はＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵがＲＬＣデータＰＤＵに追いつく場合のみに注意すれば充分である。

ＨＳ−ＤＳＣＨの特別なフィーチャ：
正確に１つのＨＳ−ＤＳＣＨトランスポートチャンネルしか存在しないので、両論理チャンネルは同一のＨＳ−ＤＳＣＨ上でのみ伝達される（又は、規格が言うように、“マッピングされる”）。即ち、ＦＥＣの観点からは、ＲＬＣ制御ＰＤＵ及びＲＬＣデータＰＤＵは同一に扱われる、即ちＦＥＴ制御ＰＤＵがＲＬＣデータＰＤＵよりも良いＦＥＣで送信されることを保証することはできない。

本発明の一実施例によれば、ＲＬＣ制御ＰＤＵはＲＬＣデータＰＤＵと一緒に、エラー保護が、専らＲＬＣデータＰＤＵを含むＭＡＣ-hs ＰＤＵのエラー保護よりも良好なＭＡＣ-hs ＰＤＵにおいて送信される。この改善されたエラー保護は、ＭＡＣ-hs ＰＤＵに含まれるＲＬＣ ＰＤＵの数を減少させる一方、チャンネル符号化及びレートマッチング後のＭＡＣ-hs ＰＤＵ内の全ビット数を一定に保つ（即ち、同数の物理レイヤビットが２ｍｓなるＴＴＩ内でエアインターフェースを介して送信される）ことにより達成することができる。

ＭＡＣ-hs ＰＤＵは、常に、全ＭＡＣ-hs ＰＤＵにおいて全体として送信されるＲＬＣ ＰＤＵの進行過程において順番の変更がないような形態でＲＬＣ ＰＤＵから作成される。しかしながら、これによりＲＬＣデータＰＤＵが失われる可能性がある。何故なら、これらは、場合によっては不利なチャンネル条件により、最早、送信されないかも知れないからである。

ノードＢ上のＭＡＣ-hsのスケジューラは、受信される各ＲＬＣ ＰＤＵにおけるＲＬＣ ＰＤＵの最初のビットを読み取り、これがＲＬＣ制御ＰＤＵか又はＲＬＣデータＰＤＵであるかを決定することができる。

他の例として、ＲＬＣ制御ＰＤＵはＲＬＣデータＰＤＵに対して異なる論理チャンネル上で送信することができ、従って、ＲＮＣとノードＢとの間のデータの送信のためのフレームプロトコルは、対応する論理チャンネルから該チャンネルがＲＬＣ制御ＰＤＵを有するか又はＲＬＣデータＰＤＵを有するかを決定すると共に、ノードＢが、ＲＬＣ ＰＤＵの最初のビットを解析することなく、受信されたＲＬＣ ＰＤＵのどれがＲＬＣ制御ＰＤＵであり、どれがＲＬＣデータＰＤＵであるかを即座に認識することができるようにＲＬＣ制御ＰＤＵにマークを付すことができる。

本発明の他の実施例によれば、ＭＡＣ-hs ＰＤＵを構築するノードＢ上のＭＡＣ-hsのエンティティ（例えば、スケジューラ）は、ＲＥＳＥＴ ＰＤＵ、ＲＥＳＥＴ ＡＣＫ ＰＤＵ及びＭＲＷ ＳＵＦＩ（スーパーフィールド）を含むＳＴＡＴＵＳ ＰＤＵ等の少なくともＲＬＣ制御ＰＤＵの所与の部分集合が一層良好なＦＥＣのＭＡＣ-hs ＰＤＵで送信されることを保証する。これは、これら制御ＰＤＵが通常はまれにしか送信されないので有利であり得る。これとは対照的に、例えばステータスレポートを含むＳＴＡＴＵＳ ＰＤＵは一層頻繁に送信され、これらの送信を非常に強いＦＥＣの一層小さなＭＡＣ-hs ＰＤＵに限定することは、ＨＳ−ＤＳＣＨを介してのダウンリンク送信のスループットを低減させることになりかねない。

実際には、ＲＬＣ制御ＰＤＵ用の改善されたＦＥＣのための方法は以下のように適用される。データをＨＳ−ＤＳＣＨを介して移動局に送信するＳＲＮＣ上のＲＬＣマシン用のＲＬＣデータＰＤＵ及びＲＬＣ制御ＰＤＵのためには、２つの論理チャンネルがコンフィギュレーションされ、これによれば、第１のものは専らＲＬＣ制御ＰＤＵの伝送を意図し、両論理チャンネルはＭＡＣ論理優先度（ＭＬＰ）を有する。ＭＡＣ-dレイヤにおいては、ＲＬＣデータＰＤＵ及びＲＬＣ制御ＰＤＵは、これにより異なるＭＡＣヘッダを持つＭＡＣ-d ＰＤＵに投入される。同一のＭＡＣ優先度の結果、これらのＲＬＣ ＰＤＵはＭＡＣ-dレイヤ内の同一の行列内に集められ、次いで、Ｓ−ＲＮＣとノードＢとの間のフレームプロトコルを介して、ＭＡＣ-dレイヤの行列におけるものと同一の順番でノードＢ上のＭＡＣ-hsレイヤに伝達され、そこでは、順番を変えることなく、ＨＳ−ＤＳＣＨを介しての送信まで他の行列に記憶される。ＭＡＣ-hs ＰＤＵに、この行列に一時的に記憶されたＭＡＣ-d ＰＤＵを詰める場合、ＭＡＣ-hsレイヤのスケジューラは、これらＭＡＣ-d ＰＤＵの各々を、当該ＲＬＣマシンのＲＬＣ制御ＰＤＵの伝送に関係する第１論理チャンネルに属するかについて分析する。特別に良好なＦＥＣが得られるような、特別に強い変調及び符号化方法（ＭＣＳ）を達成するために、スケジューラは、同一のＭＡＣ-hs優先度等級に属する所与のＭＡＣ-d ＰＤＵが個々のＭＡＣ-hs ＰＤＵにＭＡＣ-d ＰＤＵの順番を変えずに挿入され、ＲＬＣ制御ＰＤＵを含むＭＡＣ-d ＰＤＵが少数の他のＭＡＣ-d ＰＤＵのみとＭＡＣ-hs ＰＤＵを共有する（又はＭＡＣ-hs ＰＤＵ内で単独で送信される）のを保証する。何故なら、ＭＡＣ-hs ＰＤＵのためにチャンネル符号化及びレートマッチングの後に最終的に無線インターフェースを介して送信される符号化ビット数が一定の場合、ユーザビット（ユーザビットは、第１又は第２データパケットのビットである）当たりのパリティビットの数、従ってＦＥＣは、ユーザビットの数が減少するにつれて増加するからである。

優先等級のフローにおいて送信されるべき非常に多数のＲＬＣ制御ＰＤＵが存在する（例えば、ＲＬＣ ＰＤＵの百個置きではないが、十個置きが制御ＰＤＵである）場合、これは、ＭＡＣ-d ＰＤＵ（この場合、ＲＬＣ制御ＰＤＵ及びＲＬＣデータＰＤＵを含む）の順番は変化されないままでなければならないという制約により、ＭＡＣ-hs ＰＤＵ当たり少数のＲＬＣデータＰＤＵのみが大幅に改善されたＦＥＣで送信されるが、ＨＳ−ＤＳＣＨを経るダウンリンクのスループットの低下が予測され得るという事実につながり得る。しかしながら、通常、ＲＬＣ制御ＰＤＵの数は、送信されるべきＲＬＣマシンのＲＬＣ ＰＤＵの極小さな割合（例えば、１％）しか示さないので、この対策によりフローレートが著しく低下されることはない。

一方、このダウンリンクスループットの制限は、重要なＲＬＣ制御ＰＤＵ（例えば、ＲＬＣ ＲＥＳＥＴ ＰＤＵ、ＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵ、ＭＲＷ ＳＵＦＩ又はＭＲＷ＿ＡＣＫ ＳＵＦＩを伴うＲＬＣ ＳＴＡＴＵＳ ＰＤＵ）のみが、この第１論理チャンネルを介して伝送され、これらＰＤＵのパケットをスケジューラが一層強いＦＥＣのＭＡＣ-hs ＰＤＵに含める一方、残りのＲＬＣ制御ＰＤＵ及びＲＬＣデータＰＤＵは第２論理チャンネルを介して伝送される場合に、防止され得る。重要なＲＬＣ制御ＰＤＵは非常にまれにしか送信されないから、第１論理チャンネルを介して伝送されるデータ単位を、強いＦＥＣの且つ小さなサイズのＭＡＣ-hs ＰＤＵにのみに組み込む制限規則が、スループットを目立って減少させることはない。

同一のＭＡＣ-hs ＰＤＵで送信されるべきＭＡＣ-d ＰＤＵを選択するエンティティ（例えば、スケジューラ）が、ＭＡＣ-d ＰＤＵがＲＬＣ制御ＰＤＵを含むか又はＲＬＣデータＰＤＵを含むかを判定するのを可能にする他の可能性は、該エンティティに（ＭＡＣ-hsの行列内のＭＡＣ-d ＰＤＵに含まれる）全ての単一のＲＬＣ ＰＤＵの第１ビットを分析させることである。ＲＬＣ ＰＤＵのこの最初のビットは、該ＰＤＵがＲＬＣ制御ＰＤＵを有するか又はＲＬＣデータＰＤＵを有するかを示す。勿論、このエンティティ（例えば、スケジューラ）は、ＭＡＣ-dレイヤにおいて当該ＲＬＣ ＰＤＵを含むＭＡＣ-d ＰＤＵにＭＡＣヘッダが設けられたか否か、即ち、この論理チャンネルにＭＡＣ多重化が適用されたか否かが分かる場合にのみ、ＲＬＣ ＰＤＵの上記第１ビットをエラー無しで決定することができる。ＭＡＣ多重化とは、ここでは、幾つかの論理チャンネルが同じＭＡＣ-dフロー上に多重化されることを意味する。この場合、ＭＡＣ-dレイヤはＲＬＣレイヤにより受信されたＲＬＣ ＰＤＵにＭＡＣヘッダを付加し、ＭＡＣ-d ＰＤＵを形成する。このＭＡＣヘッダは４ビットからなる。ＭＡＣヘッダは、正確に１つの論理チャンネルがＭＡＣ-dフロー上にマッピングされるなら省略することができる。この第２の場合の例では、ＲＬＣ ＰＤＵの第１ビットを正確に識別するために、このエンティティ（例えば、スケジューラ）はＭＡＣ-dフローが正確に１つの論理チャンネルを伝送するか又は幾つかの論理チャンネルを伝送するかを知らなければならない。第２の場合においては、ＭＡＣヘッダは常に存在するので、スケジューラは、ＲＬＣデータＰＤＵを有するか又はＲＬＣ制御ＰＤＵを有するかを決定するために、ＭＡＣ-d ＰＤＵの第５ビットを評価しなければならない。

ＭＡＣ-dフローが正確に１つの論理チャンネルを伝送する特別な場合においては、ＭＡＣヘッダは失われる可能性があるので、ここでは、ＭＡＣ-d ＰＤＵの第１ビットが、当該ＭＡＣ-d ＰＤＵがＲＬＣデータＰＤＵを含むか又はＲＬＣ制御ＰＤＵを含むかを示す。この場合、余り好ましくないコンフィギュレーションは、それを依然として含む可能性があるので、スケジューラは、同様に、当該事実に気がつくようにされねばならない。何故なら、ＲＬＣデータＰＤＵを含むか又はＲＬＣ制御ＰＤＵを含むかを決定するためにＭＡＣ-d ＰＤＵの第５ビットを評価しなければならないからである。

更に、同一のＭＡＣ-hs ＰＤＵで送信されるべきＭＡＣ-d ＰＤＵを選択するエンティティは、どちらの論理チャンネルがＵＭ ＲＬＣ ＰＤＵを伝送し、どちらのものがＡＭ ＲＬＣ ＰＤＵを伝送するかを知らなければならない。これは、例えば該エンティティに、ＵＭ ＲＬＣ ＰＤＵを伝送する全論理チャンネルのリストを設けることにより達成することができる。同じことは、ＡＭ ＲＬＣ ＰＤＵを伝送する全論理チャンネルのリストを設けることによっても達成することができる。何故なら、ＨＳ−ＤＳＣＨを介しての送信は、ＡＭ ＲＬＣ ＰＤＵ又はＵＭ ＲＬＣ ＰＤＵを送信する論理チャンネルに関してのみコンフィギュレーションすることができるからである。更に、重要なＲＬＣ制御ＰＤＵと余り重要ではないＲＬＣ制御ＰＤＵとの間を区別するために、このエンティティ（例えば、スケジューラ）が重要なＲＬＣ制御ＰＤＵ（例えば、ＲＬＣ ＲＥＳＥＴ ＰＤＵ、ＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵ、ＭＲＷ ＳＵＦＩを含むＳＴＡＴＵＳ ＰＤＵ、ＭＲＷ_ＡＣＫ ＳＵＦＩを含むＳＴＡＴＵＳ ＰＤＵ）を確かめることができるように、当該ＲＬＣ制御ＰＤＵにおける“ＰＤＵタイプ”フィールド（ＲＬＣ ＰＤＵがＲＬＣ制御ＰＤＵであることを決定する、第１ビットに続く３ビット）のどのビット組み合わせが、これらの重要なＲＬＣ制御ＰＤＵを識別するかを知らなければならない。例えば、TS 25.322は下記のマッピングを規定している。

このマッピングは、ＳＴＡＴＵＳ ＰＤＵがＭＲＷ ＳＵＦＩを含むか又はＭＲＷ ＳＵＦＩ_ＡＣＫを含むかを未だ識別することはできない。このような情報は、TS25.322に記載されたＳＴＡＴＵＳ ＰＤＵの構造を更に解析することにより取り出すことができる。他の例は、上記５つの予備ビット組み合わせのうちの２つを、ＭＲＷ ＳＵＦＩ又はＭＲＷ ＳＵＦＩ_ＡＣＫフィールドを含むＳＴＡＴＵＳ ＰＤＵが含まれることを示すために使用することであり得る。

上記情報は、以下のようにして、どのＭＡＣ-d ＰＤＵをノードＢ上のＭＡＣ-hs ＰＤＵ内で送信すべきかについて決定するエンティティに対して利用可能とすることができる。

データがＨＳ−ＤＳＣＨを介して伝送されるべきＡＭ論理チャンネルを設定する場合、ＳＲＮＣはＲＮＳＡＰ手順を介して、これら情報の１以上をＤＲＮＣに通知し、次いで、該ＤＲＮＣは該情報をＮＢＡＰ手順によりノードＢに供給する。これに最も適したＲＮＳＡＰ手順及びＮＢＡＰ手順は同一の名前を有し：
− 無線リンク設定手順（ＳＲＮＣからＤＲＮＣへ又はＤＲＮＣからノードＢに送信される対応するメッセージは“無線リンク設定”と呼ばれる）；
− 同期無線リンク再コンフィギュレーション準備手順（ＲＮＳＡＰの場合にＳＲＮＣからＤＲＮＣへ、又はＮＢＡＰの場合にＤＲＮＣからノードＢへ送信される対応するメッセージは、“無線リンク再コンフィギュレーション準備”と呼ばれる）；
と呼ばれる。

ＲＮＳＡＰ（無線ネットワーク・システム・アプリケーション・パート）は、3GPP TS 25.423 V5.3.0 (2002-9)、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；ＵＴＲＡＮ ＩｕｒインターフェースＲＮＳＡＰ通知（リリース５）に記載されている。

ＮＢＳＡＰ（ノードＢアプリケーション・パート）は、3GPP TS 25.433 V5.2.0 (2002-9)、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；ＵＴＲＡＮ ＩｕｂインターフェースＮＢＡＰ通知（リリース５）に記載されている。全体のＵＴＲＡＮアーキテクチャは、3GPP TS 25.401 V6.1.0 (2003-06)、第３世代パートナーシップ・プロジェクト；技術仕様グループ無線アクセスネットワーク；ＵＴＲＡＮ全体説明（リリース６）に記載されている。これらの仕様は、参照により本明細書に組み込まれるものとする。

図３は、本発明の一実施例による通信システムを示している。該通信システムは、ネットワークユニットを備える送信局３０、受信局３１及び計算手段３４を有している。計算手段３４は、送信局３０から受信局３１へのデータパケットの送信を実行するためのソフトウェアプログラム製品を実行するために使用される。送信局３０から受信局３１へのデータパケットの送信は、無線通信リンク３２を介して実行することができる。受信局３１にも計算手段を設けることができる。図３に図示された通信システムは、本発明の一実施例による改善されたＦＥＣを実行するように構成される。

図４は、本発明の一実施例による方法の概念図を示す。図１及び図２を参照して詳細に説明したように、ＭＡＣ-dレイヤ２９は、ＲＬＣ制御ＰＤＵ２１、２２及び２７を含む第１データパケット即ちＭＡＣ-d ＰＤＵと、ＲＬＣデータＰＤＵ２３、２４、２５、２６及び２８を含む第２データパケット即ちＭＡＣ-d ＰＤＵとを有し、ＲＬＣ制御ＰＤＵ及びＲＬＣデータＰＤＵはＭＡＣ-dレイヤより上のレイヤにおける同一のＲＬＣエンティティにより送信されたものである。処理ステップにおいて、ＲＬＣ ＰＤＵ２１、２２、２３、２４、２５、２６、２７及び２８を含むＭＡＣ-d ＰＤＵはＭＡＣ-hsレイヤ１２に渡され、該レイヤは斯かるＭＡＣ-d ＰＤＵからＭＡＣ-hs ＰＤＵ１、２、３、４、５、６、７及び８を構築する。

第１コンテナ９及び１１は制御情報（ＲＬＣ制御ＰＤＵ）を有するＭＡＣ-d ＰＤＵ１、２及び７を含み、第１コンテナ１１はデータ（ＲＬＣデータＰＤＵ）を有するＭＡＣ-d ＰＤＵ８も含んでいる。一方、第２コンテナ１０はデータのみを有するＭＡＣ-d ＰＤＵ３、４、５及び６のみを含み、制御情報を持つＰＤＵは含んでいない。

ＭＡＣ-hs ＰＤＵは、常に、実際に送られるＭＡＣ-hs ＰＤＵにおいて送信されるＲＬＣ ＰＤＵの進行過程において順番の変更がないような態様で、ＭＡＣ-d ＰＤＵ（常に正確に１つのＲＬＣ ＰＤＵを含む）から作成され得ることに注意されたい。しかしながら、実際に送信されるＭＡＣ-hs ＰＤＵにおいては、ＲＬＣデータＰＤＵが失われるかも知れない。というのは、悪いチャンネル条件により、これらのＲＬＣデータＰＤＵ（ＭＡＣ-d ＰＤＵに含まれる）が伝送されたＭＡＣ-hs ＰＤＵのエラー保護が、ＲＬＣ制御ＰＤＵ（ＭＡＣ-d ＰＤＵに含まれる）を伝送したＭＡＣ-hs ＰＤＵのエラー保護ほど強くはなかった可能性があるからである。

第１及び第２データパケットの正しい順序を得るために、本発明の一実施例によれば少なくとも第２データパケットに、対応するデータパケットシーケンス番号を設けることができる。更に、第１及び第２コンテナの正しい順序を得るために、第１及び第２コンテナに、対応するコンテナシーケンス番号を設けることができる。

請求項１に記載された実施例との組み合わせで、即ち異なるエラー符号化を持つコンテナとの組み合わせで実施化することができるが、請求項１の解決策とは別個にも実施化することが可能な、本発明の他の実施例によれば、前述した課題は、ＲＬＣプロトコルを、ＲＬＣ ＲＥＳＥＴ手順が完了した後に、送信及び受信ウィンドウが、それらの下縁はシーケンス番号０に等しくなるように初期化されないが、これらウィンドウの下縁が上記ＲＬＣ ＲＥＳＥＴ手順が開始される直前の送信ウィンドウの下縁と等しく設定されるように変更することにより解決することができる。これにより、ＲＥＳＥＴ手順後に、“孤児ＲＬＣ ＰＤＵ”は常に受信ＲＬＣウィンドウの外側となり、従ってＲＬＣプロトコルのエラー処理により破棄されるようにすることができる。言い換えると、シーケンス番号が受信ウィンドウの外側であるようなＲＬＣデータＰＤＵは破棄される。

このＲＬＣプロトコルの変更は、ＲＬＣ ＲＥＳＥＴ ＰＤＵに１２ビットの他のフィールドを組み込み、該フィールドが、ＲＬＣ ＲＥＳＥＴ ＰＤＵが送信される直前の送信ウィンドウの下縁の値を含み、かくしてＲＬＣリセット手順を起動する（即ち、送信ウィンドウの下縁を０に初期化することなく）ようにすることにより達成することができる。このＲＬＣ ＲＥＳＥＴ ＰＤＵを受信側ＲＬＣエンティティが受信すると、該エンティティは上記フィールドも読み取り、その受信ウィンドウを下縁値が該フィールドに含まれる値に等しくなるように更新する。同様に、ＲＬＣ ＲＥＳＥＴ ＰＤＵを受信するＲＬＣエンティティは、該ＲＬＣ ＲＥＳＥＴ ＰＤＵに応答して送信されるべきＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵに他の１２ビットのフィールドを含め、該フィールドは該ＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵを送信する直前の自身の送信ウィンドウの下縁の値を含み、その送信ウィンドウを維持する（即ち、該送信ウィンドウの下縁を０に初期化しない）。上記ＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵが、ＲＬＣ ＲＥＳＥＴ ＰＤＵを送信することにより当該ＲＬＣ ＲＥＳＥＴ手順を起動したＲＬＣエンティティにより受信されると、該エンティティは、ＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵを送信したＲＬＣエンティティの送信ウィンドウの下縁を含む前記１２ビットのフィールドを読み取り、自身の受信ウィンドウを、その下縁が該フィールドに含まれる値に等しくなるように更新する。従って、TS 25.322に記述されたＲＥＳＥＴ ＰＤＵ及びＲＥＳＥＴ ＡＣＫ ＰＤＵに、例えばＨＦＮＩ（ハイパー・フレーム番号指示子）フィールドの後に、他の１２ビットフィールドを追加することができ、該フィールドは図５に示すように詰め込み（padding）フィールドのうちの１２ビットを占める。ＬＥＷＩ（“ウィンドウの下縁”指示子）が、この新しいフィールドを示し、他のものはTS 25.322に記述されたものである。

この実施例によれば、ＲＬＣデータＰＤＵに使用される論理チャンネルよりも高い優先度を持つ論理チャンネルでＲＬＣ制御ＰＤＵを送信することが可能となる。何故なら、ＲＬＣデータＰＤＵに追いつくＲＬＣ制御ＰＤＵが、最早、問題を生じさせることがないからである。この場合、ＲＬＣデータＰＤＵと比較して良好なＲＬＣ制御ＰＤＵのＦＥＣは、ＲＬＣ制御ＰＤＵが、ノードＢ上のＭＡＣ-hsではＲＬＣデータＰＤＵのものとは異なる行列において収集され、該行列が一層高い優先度を持つスケジューラにより処理され、該スケジューラは、この行列に記憶されたＲＬＣ制御ＰＤＵを伝送するために使用されるコンテナ即ちＭＡＣ-hs ＰＤＵが充分に強いＦＥＣにより保護される、即ち、この強いＦＥＣを達成するために充分に低減された数のＲＬＣ制御ＰＤＵを含むことを保証することができるという事実により得ることができる。

本発明がＵＭＴＳシステムの実施例を参照して説明されたという事実にも拘わらず、本発明は同様の課題を持つ及び同様の構成の他のシステムにも適用することができることに注意すべきである。

図１は、本発明によるデータ伝送システムの送信機又は受信機のレイヤの一実施例を示す。 図２は、本発明によるデータ伝送システムにおいて（例えば、ＵＭＴＳにおいて）使用することができるノードＢ、ＤＲＮＣ及びＳＲＮＣの簡略図を示す。 図３は、本発明の一実施例による通信システムを示す。 図４は、本発明の一実施例による方法の概念図を示す。 図５は、現在TS 25.322に含まれるＲＬＣ ＲＥＳＥＴ ＰＤＵ及びＲＬＣ ＲＥＳＥＴ ＡＣＫ ＰＤＵの変形例の一実施例を示す。

Claims (13)

1. 第１データパケット及び第２データパケットを送信局から受信局へ送信する方法であって、前記第１データパケットは制御命令を有し、前記第２データパケットはユーザデータを有し、前記第１データパケット及び第２データパケットは前記送信局から前記受信局へコンテナ内で送信され、第１コンテナは少なくとも１つの第１データパケットを有し、前記第１コンテナには第１エラー符号化が付与され、第２コンテナは少なくとも１つの第２データパケットは有するが第１データパケットは有さず、該第２コンテナには第２エラー符号化が付与され、前記第１エラー符号化が前記第２符号化よりも強く、
   第１再送信プロトコルが前記第１及び第２データパケットのうちの少なくとも１つのデータパケットの送信及び再送信を制御し、
   第２再送信プロトコルが前記第１及び第２コンテナの送信及び再送信を制御し、
   前記第１及び第２データパケットが前記第２再送信プロトコルにより前記第１及び第２コンテナ内で送信される結果としての前記第１及び第２データパケットの第１順序は、前記第１再送信プロトコルにより送信された前記第１及び第２データパケットが前記第２再送信プロトコルにより受信されるときの該第１及び第２データパケットの第２順序と比較して変更されないままとなる、
   ことを特徴とする方法。
2. 請求項１に記載の方法において、前記第１コンテナにおける前記第１及び第２データパケットの数は前記第２コンテナにおける前記第２データパケットの数よりも、前記第１コンテナにおいて送信される第１データペイロードが前記第２コンテナにおいて送信される第２データペイロードよりも低くなるように小さいことを特徴とする方法。
3. 請求項１に記載の方法において、前記第１コンテナ及び第２コンテナには対応するコンテナシーケンス番号が付与され、前記第２データパケットにおける各データパケットには対応するデータパケットシーケンス番号が付与されることを特徴とする方法。
4. 請求項１に記載の方法において、前記第２再送信プロトコルは、この第２再送信プロトコルが該第２再送信プロトコルより上に位置する前記第１再送信プロトコルから受信する受信データパケットが第１データパケットであるか又は第２データパケットであるかを判定することを特徴とする方法。
5. 請求項４に記載の方法において、前記第２再送信プロトコルは、前記受信データパケットが第１データパケットであるか又は第２データパケットであるかの判定を、前記第１再送信プロトコルにより前記受信データパケットに関連付けられたヘッダ情報を解析することにより実行することを特徴とする方法。
6. 請求項４に記載の方法において、前記受信データパケットが第１データパケットである場合、該受信データパケットは、第２送信プロトコルより上に位置する第１送信プロトコルから該第２送信プロトコルに伝送される場合にラベル付けされることを特徴とする方法。
7. 請求項１に記載の方法において、当該方法がＵＭＴＳにおける高速ダウンリンク共有チャンネル上でのデータ送信に適用されることを特徴とする方法。
8. 請求項７に記載の方法において、前記第１データパケットがＲＬＣ制御ＰＤＵであり、前記第２データパケットがＲＬＣデータＰＤＵであることを特徴とする方法。
9. 請求項１に記載の方法において、前記第１コンテナ及び第２コンテナには対応するコンテナシーケンス番号が付与され、前記第２データパケットにおける各データパケットには対応するデータパケットシーケンス番号が付与され、前記第１再送信プロトコルの受信側エンティティはシーケンス番号が受信ウィンドウの外側であるような第２データパケットを破棄し、前記第１再送信プロトコルの２つのピアエンティティのうちの第１ピアエンティティは両ピアエンティティのリセットを開始するように構成され、該リセットは前記第１データパケットに含まれる第１及び第２リセットメッセージにより実行され、前記リセットは、前記第１エンティティに前記第２エンティティに対して第１リセットメッセージを送信させる一方、前記第２エンティティに前記第１エンティティに対し前記第１リセットメッセージに応答して第２リセットメッセージを送信させ、前記第１リセットメッセージは前記第２エンティティの受信ウィンドウの下縁を前記リセットの前に使用された前記第１エンティティの送信ウィンドウの下縁に等しく設定し、前記第２リセットメッセージは前記第１エンティティの受信ウィンドウの下縁を前記第１リセットメッセージの受信の前に使用された前記第２エンティティの送信ウィンドウの下縁に等しく設定することを特徴とする方法。
10. 第１データパケット及び第２データパケットを送信局から受信局へ送信する通信システムであって、前記第１データパケットは制御命令を有し、前記第２データパケットはユーザデータを有し、前記第１データパケット及び第２データパケットは前記送信局から前記受信局へコンテナ内で送信され、第１コンテナは少なくとも１つの第１データパケットを有し、前記第１コンテナには第１エラー符号化が付与され、第２コンテナは少なくとも１つの第２データパケットは有するが第１データパケットは有さず、該第２コンテナには第２エラー符号化が付与され、前記第１エラー符号化が前記第２符号化よりも強く、
    第１再送信プロトコルが前記第１及び第２データパケットのうちの少なくとも１つのデータパケットの送信及び再送信を制御し、
    第２再送信プロトコルが前記第１及び第２コンテナの送信及び再送信を制御し、
    前記第１及び第２データパケットが前記第２再送信プロトコルにより前記第１及び第２コンテナ内で送信される結果としての前記第１及び第２データパケットの第１順序は、前記第１再送信プロトコルにより送信された前記第１及び第２データパケットが前記第２再送信プロトコルにより受信されるときの該第１及び第２データパケットの第２順序と比較して変更されないままとなる、
    ことを特徴とする通信システム。
11. 第１データパケット及び第２データパケットを受信局へ送信する送信局であって、前記第１データパケットは制御命令を有し、前記第２データパケットはユーザデータを有し、前記第１データパケット及び第２データパケットは当該送信局から前記受信局へコンテナ内で送信され、第１コンテナは少なくとも１つの第１データパケットを有し、前記第１コンテナには第１エラー符号化が付与され、第２コンテナは少なくとも１つの第２データパケットは有するが第１データパケットは有さず、該第２コンテナには第２エラー符号化が付与され、前記第１エラー符号化が前記第２符号化よりも強く、
    第１再送信プロトコルが前記第１及び第２データパケットのうちの少なくとも１つのデータパケットの送信及び再送信を制御し、
    第２再送信プロトコルが前記第１及び第２コンテナの送信及び再送信を制御し、
    前記第１及び第２データパケットが前記第２再送信プロトコルにより前記第１及び第２コンテナ内で送信される結果としての前記第１及び第２データパケットの第１順序は、前記第１再送信プロトコルにより送信された前記第１及び第２データパケットが前記第２再送信プロトコルにより受信されるときの該第１及び第２データパケットの第２順序と比較して変更されないままとなる、
    ことを特徴とする送信局。
12. 第１データパケット及び第２データパケットを送信局から受信する受信局であって、前記第１データパケットは制御命令を有し、前記第２データパケットはユーザデータを有し、前記第１データパケット及び第２データパケットは前記送信局から当該受信局へコンテナ内で送信され、第１コンテナは少なくとも１つの第１データパケットを有し、前記第１コンテナには第１エラー符号化が付与され、第２コンテナは少なくとも１つの第２データパケットは有するが第１データパケットは有さず、該第２コンテナには第２エラー符号化が付与され、前記第１エラー符号化が前記第２符号化よりも強く、
    第１再送信プロトコルが前記第１及び第２データパケットのうちの少なくとも１つのデータパケットの送信及び再送信を制御し、
    第２再送信プロトコルが前記第１及び第２コンテナの送信及び再送信を制御し、
    前記第１及び第２データパケットが前記第２再送信プロトコルにより前記第１及び第２コンテナ内で送信される結果としての前記第１及び第２データパケットの第１順序は、前記第１再送信プロトコルにより送信された前記第１及び第２データパケットが前記第２再送信プロトコルにより受信されるときの該第１及び第２データパケットの第２順序と比較して変更されないままとなる、
    ことを特徴とする受信局。
13. コンピュータ上で実行されたときに該コンピュータに請求項１から請求項９のいずれか一項に記載の方法を実行させる命令を有するソフトウェアプログラム。

Images