JP2011522488A

JP2011522488A - 非アクセス層再送の配信通知のための方法および装置

Info

Publication number: JP2011522488A
Application number: JP2011511803A
Authority: JP
Inventors: ソマスンダラムシャンカー; サムールモハメド; ピー．ムケルジーラジャ
Original assignee: インターデイジタルパテントホールディングスインコーポレイテッド
Priority date: 2008-05-30
Filing date: 2009-05-28
Publication date: 2011-07-28
Also published as: CN201440735U; CN103607263A; BRPI0909884B1; CN103607263B; EP2283600B1; DK2283600T3; AR071976A1; US20130070614A1; ES2674377T3; RU2010154413A; EP2283600A1; EP2685659A3; US8897229B2; KR101561720B1; KR101550161B1; EP2685659A2; US20100003982A1; KR20140088177A; KR20110030703A; US8331290B2

Abstract

ＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）におけるデータ配信確認のための方法および装置は、ＵＬ（UpLink：アップリンク）メッセージを送信するステップ、モビリティ動作を実行するステップ、ＵＬメッセージが肯定応答されていないことを判定するステップ、および、配信障害メッセージを生成するステップを含む。モビリティ動作は、ハンドオーバー、または、ＲＲＣ（Radio Resource Control：無線リソース制御）接続再確立である。配信障害メッセージを含むメッセージは、プロトコル・レイヤーの間で受け渡される。

Description

この出願は無線通信に関する。

３ＧＰＰ（3rd Generation Partnership Project：第３世代パートナーシップ・プロジェクト）は、改善されたスペクトル効率及びより速いユーザー体験を提供するために、ＬＴＥ（Long Term Evolution：長期進化型）プログラムを開始して、新技術、新しいネットワーク・アーキテクチャ、新しい構成、ならびに新しいアプリケーションおよびサービスを無線ネットワークにもたらしつつある。図１は、従来技術によるＥ−ＵＴＲＡＮ（Evolved ＵＭＴＳ（Universal Mobile Telecommunications System）Terrestrial Radio Access Network）１００の概観を示す。図１に示されるように、Ｅ−ＵＴＲＡＮ１００は、３つのｅＮＢ（eNodeB：ｅノードＢ）１０２を含むが、Ｅ−ＵＴＲＡＮ１００には任意の数のｅＮＢを含むことができる。ｅＮＢ１０２は、Ｘ２インタフェース１０８によって相互接続される。ｅＮＢ１０２はまた、Ｓｌインターフェイス１０６によってＥＰＣ（Evolved Packet Core）１０４に接続される。ＥＰＣ１０４は、ＭＭＥ（Mobility Management Entity）１０８およびＳ−ＧＷ（Serving Gateway：サービス提供ゲートウェイ）１１０を含む。

図２は、従来技術によるＬＴＥユーザー・プレーン・プロトコル・スタック２００を示す。プロトコル・スタック２００は、ＷＴＲＵ２１０中に位置し、そしてＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）２０２、ＲＬＣ（Radio Link Control：無線リンク制御）２０４、ＭＡＣ（Medium Access Control：媒体アクセス制御）２０６、およびＰＨＹ（PHYsical layer：物理レイヤー）２０８を含む。このプロトコル・スタック２００はまた、ｅＮＢ中に存在することができる（図示せず）。

図３は、図２のＷＴＲＵ２１０中のＬＴＥ制御プレーン・プロトコル・スタック３００を示す。制御プレーン・プロトコル・スタック３００は、ＮＡＳ（Non-Access Stratum：非アクセス層）３０２およびＲＲＣ（Radio Resource Control：無線リソース管理）３０４を含む。ＰＤＣＰ３０６、ＲＬＣ３０８、およびＭＡＣ３１０もまた含まれ、これらは一体としてレイヤー２のサブレイヤー３１２を形成する。

ハンドオーバーの間に、ＷＴＲＵ２１０は、ＰＤＣＰ（２０６）からＵＬ（UpLink：アップリンク）ＳＤＵ（System Data Unit：システム・データ・ユニット）を送信することができる。ＳＤＵが首尾よく配信されたという通知をＷＴＲＵ２１０が受信しない場合、ＷＴＲＵ２１０はＳＤＵを再送することができる。ＷＴＲＵ２１０は、ｅＮＢから受信されたＰＤＣＰ状態報告を使用して、どのアップリンクＰＤＣＰＳＤＵを再送するべきかを判定することができる。ＷＴＲＵ２１０はまた、状態報告によってＳＤＵが受信されていたかまたは肯定応答されていた場合、この報告を使用してそのＳＤＵを廃棄することができる。

ハンドオーバーの間にターゲットｅＮＢは、ソースｅＮＢによって転送されていたダウンリンクＰＤＣＰＳＤＵを、ＷＴＲＵ２１０に再送することができる。ＷＴＲＵ２１０は、ＰＤＣＰ状態報告をターゲットｅＮＢに送信することができる。ターゲットｅＮＢはそのＰＤＣＰ状態報告を利用して、ＷＴＲＵ２１０にどのＰＤＣＰＳＤＵを再送するべきかを判定することができる。ターゲットｅＮＢはまた、ＰＤＣＰ状態報告によってＳＤＵが受信されていたかまたは肯定応答されていた場合、ダウンリンクＰＤＣＰＳＤＵを廃棄することができる。一旦、ＷＴＲＵ２１０がＳＤＵを受信すると、ＷＴＲＵ２１０は、ＳＤＵを並べ替え、重複を排除する。ＷＴＲＵ２１０は次に、例えばフラッシュ・タイマー（flush timer）などのタイマーに基づいて何れの機能をも非活性化することができる。ＳＲＢ（Signaling Radio Bearer：信号方式無線ベアラ）に関しては、ハンドオーバーが生起したことをＲＬＣ２０４が表すことができ、そしてＰＤＣＰ２０２がＰＤＣＰＳＮ（Sequence Number：シーケンス番号）およびＨＦＮ（Hyper Frame Number：ハイパー・フレーム番号）などの状態変数を再初期化することができる。状態変数はまた、ゼロに設定することもできる。以前に格納されているすべてのＰＤＣＰＳＤＵおよびＰＤＣＰＰＤＵは、廃棄することができる。

ＮＡＳレベルの再送を実行するために、ＡＳ（Access Stratum：アクセス層）（図示せず）は、ハンドオーバーまたはセル選択に依って障害が生起した場合、ＮＡＳメッセージ送信障害のインジケーションを提供することができる。

ＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）におけるデータ配信確認のための方法および装置が開示される。これは、ＵＬ（UpLink：アップリンク）メッセージを送信するステップ、モビリティ動作を実行するステップ、ＵＬメッセージが肯定応答されていないことを判定するステップ、および配信障害メッセージを生成するステップを含む。モビリティ動作は、ハンドオーバー、または、ＲＲＣ（Radio Resource Control：無線リソース管理）接続再確立であることができる。配信障害メッセージを含むメッセージは、プロトコル・レイヤーの間で非アクセス層に渡すことができる。

添付図面に関連して例として与えられた以下の説明から、より詳細な理解を得ることができる。
従来技術によるＥ−ＵＴＲＡＮの概観を示す図である。従来技術によるＬＴＥユーザー・プレーン・プロトコル・スタックを示す図である。従来技術によるＬＴＥ制御プレーン・プロトコル・スタックを示す図である。一実施形態による、複数のＷＴＲＵおよび１つのｅＮＢを含む無線通信システムの一例を示す図である。図４のＷＴＲＵおよびｅＮＢのブロック図である。一実施形態による、ＲＲＣレベルの確認応答方法のブロック図である。代替の実施形態による、ＲＲＣレベルの確認応答方法のブロック図である。別の実施形態による、ＲＲＣレベルの確認応答方法のブロック図である。一実施形態による、配信の直接通知の方法のブロック図である。一実施形態による通知方法８００のブロック図である。別の実施形態による通知方法９００のブロック図である。

これ以後参照されると、用語「ＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）」は、限定的ではなく、ＵＥ（User Equipment：ユーザー機器）、移動局、固定型または移動型の加入者ユニット、ページャー、携帯電話、ＰＤＡ（Personal Digital Assistant：携帯情報端末）、コンピューター、または無線環境において動作する能力のある他の如何なる種別のユーザー・デバイスをも含む。これ以後参照されると、用語「基地局（base station）」は、限定的ではなく、ノードＢ、サイト制御装置、ＡＰ（Access Point：アクセス・ポイント）、または無線環境において動作する能力のある他の如何なる種別のインターフェイス・デバイスをも含む。さらに、用語「配信通知（delivery notification）」、「配信確認（delivery confirmation）」、「配信インジケーション（delivery indication）」、「送信確認（transmission confirmation）」、および「送信インジケーション（transmission indication）」は、これ以後、置き換え可能に使用される。

ここに使用されるように、用語「上位レイヤー（upper layer）」および「下位レイヤー（lower layer）」は相対的な用語である。ＮＡＳ、ＲＲＣ、ＰＤＣＰ、ＲＬＣ、およびＭＡＣを含むプロトコル・スタック中の各レイヤーは、プロトコル・スタック中の自身より下の何れのレイヤーに関しても上位レイヤーである。したがって例えば、ＲＬＣがＭＡＣレイヤーのみに関して上位レイヤーである一方、ＮＡＳはＲＲＣ、ＰＤＣＰ、ＲＬＣ、およびＭＡＣレイヤーに関して上位レイヤーである。

図４は、複数のＷＴＲＵ４１０および１つのｅＮｏｄｅＢ（ｅＮＢ）４２０を含む無線通信システム４００を示す。図４に示されるように、ＷＴＲＵ４１０は、ｅＮＢ４２０と通信状態にある。図４において３つのＷＴＲＵ４１０および１つのｅＮＢ４２０が示されるが、無線通信システム４００においては無線のおよび有線のデバイスの何れの組み合わせをも含むことができることに注意するべきである。

図５は、図４の無線通信システム４００のＷＴＲＵ４１０およびｅＮＢ４２０の機能的なブロック図５００である。図４に示されるように、ＷＴＲＵ４１０はｅＮＢ４２０と通信状態にある。ＷＴＲＵ４１０は、ユーザー・プレーン・プロトコル・スタック（図１の１００）および制御プレーン・プロトコル・スタック（図２の２００）の両方によって構成される。スタックにおけるそれぞれのコンポーネントは、スタック中にてその上およびその下のコンポーネントと通信するように構成される。その上、スタックにおけるそれぞれのコンポーネントは、ピア・プロトコル・スタック中の自身のピア・コンポーネントと通信するように構成される。

通常のＷＴＲＵにおいて見出すことができるコンポーネントに加えて、ＷＴＲＵ４１０は、処理装置５１５、受信機５１６、送信機５１７、およびアンテナ５１８を含む。ＷＴＲＵ４１０はまた、ユーザー・インターフェイス５１８を含み、このユーザー・インターフェイス５１８には、限定的ではなく、ＬＣＤまたはＬＥＤスクリーン、タッチ・スクリーン、キーボード、スタイラス・ペン、または他の如何なる通常の入力／出力デバイスをも含むことができる。ＷＴＲＵ４１０はまた、揮発性のおよび不揮発性の両方のメモリ５１９、ならびにＵＳＢポート、シリアル・ポート、および同様のものなどの、他のＷＴＲＵへのインターフェイス５２０を含むことができる。受信機５１６および送信機５１７は、処理装置５１５と通信状態にある。アンテナ５１８は、受信機５１６および送信機５１７の両方と通信状態にあり、無線データの送信および受信を容易にする。

通常のｅＮＢにおいて見出すことができるコンポーネントに加えて、ｅＮＢ４２０は、処理装置５２５、受信機５２６、送信機５２７、およびアンテナ５２８を含む。受信機５２６および送信機５２７は、処理装置５２５と通信状態にある。アンテナ５２８は、受信機５２６および送信機５２７の両方と通信状態にあり、無線データの送信および受信を容易にする。

ＷＴＲＵおよびｅＮＢは、ＡＭ（Acknowledge Mode：確認応答モード）またはＵＭ（Unacknowledged Mode：非確認応答モード）にて動作することができる。ＡＭにて動作するとき、ＰＤＵまたはＳＤＵなどのデータ・パケットが受信エンティティに首尾よく送信される場合、送信エンティティは肯定応答を受信することができる。例えばＲＬＣエンティティは、データ・パケットを発生させることができ、そしてそのパケットを送信することができる。受信ＲＬＣエンティティは、そのパケットを受信することができ、そしてＲＬＣ状態報告を発生させることができ、その報告を送信ＲＬＣエンティティに送信し戻すことができる。ＲＬＣ状態報告は、そのパケットの送信がうまくいったかを示すためのインジケーションを含むことができる。例えばＷＴＲＵが一組のＲＬＣＰＤＵを送信し、送信されたすべてのＲＬＣＰＤＵが受信エンティティによってＲＬＣ状態報告中にて肯定応答された場合には、配信がうまくいったと見なすことができる。しかしながら、ＲＬＣＰＤＵの１つが否定的に応答（negatively acknowledged）され、そしてそのパケットが再送されなく、または廃棄された場合には、送信エンティティは、不成功配信のインジケーションを含むＲＬＣ状態報告を受信することができる。

ＲＬＣＰＤＵが首尾よく配信されなかったというもう一つのインジケーションは、状態報告なしで送信ＲＬＣエンティティに提供されることができる。例えば、ＲＬＣエンティティがリセットされるかまたは再確立され、そして受信ＲＬＣによって少なくとも１つのＲＬＣパケットが、否定的に応答されたかまたは肯定的に応答されていない場合、送信ＲＬＣは、配信がうまくいかなかったと判定することができる。

ＰＤＣＰは、ＲＬＣにパケットを送ることができる。ＲＬＣはパケットを送ることができ、ＰＤＣＰにＲＬＣ配信確認を送ることができる。ＰＤＣＰが、例えばＲＲＣなどの上位レイヤーからパケットを元々受信している場合、ＰＤＣＰはその上位レイヤーに配信インジケーターを提供することができる。ＰＤＣＰパケットのうまくいった配信のインジケーションは、ＲＬＣエンティティによって提供されるインジケーターであることができる。ＰＤＣＰが、例えばＲＬＣなどの下位レイヤーから成功のインジケーションを受信した場合、ＰＤＣＰは、例えばＲＲＣなどの上位レイヤーにインジケーターを提供することができる。ＰＤＣＰが下位レイヤーから障害通知を受信した場合、ＰＤＣＰは不成功配信のインジケーションを送信することができる。その上、ＲＬＣレイヤーにパケットを送出する前にＰＤＣＰがそのパケットを廃棄した場合、配信障害のインジケーションをＰＤＣＰからＲＲＣに提供することができる。

ＰＤＣＰパケットの配信の状態を判定するために、ＰＤＣＰ状態報告機能を使用することができる。ＮＡＳメッセージを支援するＳＲＢはまた、ＰＤＣＰ状態報告の交換を支援することができる。欠けているまたは確認応答されたＰＤＣＰパケットに関する情報を伝達するために、ＳＲＢを使用することができる。

ハンドオーバーにおいて、ＰＤＣＰＳＤＵの配信の状態を判定するために、ＰＤＣＰ状態報告を使用することができる。それぞれのＰＤＣＰＳＤＵには、関連付けられたシーケンス番号がある。ハンドオーバーの後にターゲット・セルに送信されるべき最初のＳＤＵに関連付けられたＰＤＣＰＳＮ（Sequence Number：シーケンス番号）は、ハンドオーバーの前にソース・セルに配信された最後のＳＤＵのＳＮから継続することができる。言い換えればＳＮは、ターゲット・セルにおいて新規のＳＮにより開始するのではなく、むしろソースからターゲットに向けて継続される。ＳＲＢＵＬ（UpLink：アップリンク）および／またはＤＬ（DownLink：ダウンリンク）ＰＤＣＰＳＮ（Sequence Number：シーケンス番号）コンテキストは、ソースｅＮＢおよびターゲットｅＮＢの間で交換することができる。ＰＤＣＰＳＮはまた、ＷＴＲＵにおいて保有することができる。あるいはまた、ＷＴＲＵまたはｅＮＢは、ハンドオーバー前ＳＮを使用してＰＤＣＰ状態報告を作成することができる。別の代替手段として、ソースｅＮＢ中にてＰＤＣＰ状態報告を交換することができる。

ＳＲＢに対するＰＤＣＰ状態報告は、例えばＲＲＣまたはＮＡＳなどの、上位レイヤーに配信確認を提供する。上位レイヤーは次に、状態報告に基づいて適切な行動を取ることになる。

ＲＲＣはまた、上位レイヤーに配信通知サービスを提供することができる。図６Ａは、１つの実施形態によるＲＲＣレベルの確認応答方法のブロック図６００である。ＮＡＳ６０２は、メッセージ６０４をＲＲＣ６０６に渡す。ＲＲＣ６０６はメッセージ６０４を処理し、そしてＲＲＣメッセージ６０８をＰＤＣＰ６１０に渡す。ＰＤＣＰ６１０は、送信のためにＰＤＣＰＳＤＵ６１４を下位レイヤーに渡す。ＰＤＣＰ６１０は、ＰＤＣＰＳＤＵ６１４の配信がうまくいったかまたは不成功だったかのインジケーションを含む配信状態インジケーター６１２をＮＡＳ６０２に渡すことができる。インジケーター６１２は、ＰＤＣＰ６１０がＰＤＣＰＳＤＵ６１４の配信がうまくいったというインジケーションを受信している場合、うまくいった配信を示すことができる。しかしながらＰＤＣＰ６１０がＡＣＫ（ACKnowledgement：肯定応答）を受信せず、またはＮＡＣＫ（Non-ACKnowledgement：否定応答）を受信した場合、ＰＤＣＰ６１０は、ＰＤＣＰＳＤＵ６１４の配信がうまくいかなかったと判定することができ、そして配信状態インジケーター６１２は不成功配信を示すことになる。

図６Ｂは、別の実施形態によるＲＲＣレベルの確認応答方法６２０のブロック図である。図６ＡにおいてＲＲＣ６０６は、ＰＤＣＰ６０８に依存してＮＡＳ６０２に配信通知を提供する。図６Ｂに示されるようにＲＲＣ６０６はまた、ＮＡＳ６０２に配信通知を直接的に提供することができる。図６Ａと同様に、図６ＢにおいてはＮＡＳ６０２がメッセージ６０４をＲＲＣ６０６に渡す。しかしながら図６Ａとは異なり、図６Ｂにおいては、ＲＲＣ６０６はピアＲＲＣ６２２にメッセージ６２４を直接的に送る。直接転送メッセージ（direct transfer message）６２４に対して、ＲＲＣ６０６がＲＬＣＬａｙｅｒ２（Ｌ２：レイヤー２）ＡＣＫ（図示せず）を受信していない場合、ＲＲＣ６０６は、失敗した配信を示す配信通知６２６をＮＡＳ６０２に直接的に送ることができる。配信通知６２６に応答してＮＡＳ６０２は、すべてのタイマーを停止させ、そしてメッセージ６０４を再送することができる。ハンドオーバー・コマンドにおいて、または、ソース・セルもしくはターゲット・セルにおける追加的信号方式を通して、ＮＡＳメッセージを再送するためのインジケーションをＲＲＣ６０６が受信した場合、ＲＲＣ６０６はまた配信通知６２６をＮＡＳ６０２に提供することができる。

ハンドオーバー・コマンドを受信するか、または、ハンドオーバー、セル選択もしくはセル再選択を実行すると、ＲＲＣ６０６は、上位レイヤー例えばＮＡＳ６０２に、または下位レイヤー例えばＰＤＣＰ６１０に、配信通知６２６を提供することができる。この通知は、ＲＲＣ６０６が、ハンドオーバー・コマンドを受信したか、またはハンドオーバー、セル選択もしくはセル再選択を実行したという通知を含むことができる。ＲＲＣ６０６はまた、ＮＡＳ６０２の再送をトリガーすることができる別のイベントの通知、またはＮＡＳ６０２もしくはＰＤＣＰ６１０への配信通知を提供することができる。

図６Ｃは、代替の実施形態によるＲＲＣレベルの確認応答方法６３０のブロック図である。ＲＲＣ６０６は、ＲＲＣメッセージのヘッダー６３２中に、ピアＲＲＣエンティティ６２２からＲＲＣレベルの確認応答を要求するために１ビットを設定する。そしてピアＲＲＣエンティティ６２２は、ＲＲＣレベルの肯定応答６３６を送る。ある時間以内に肯定応答を受信しなかったなら、ハンドオーバーにおいて、送信が失敗した旨の配信通知６３４をＮＡＳ６０２に供給する。ピアＲＲＣエンティティ６２２からの肯定応答が無いことはまた、ＲＲＣレベル再送をトリガーするために使用することができる。

ＲＲＣピア・エンティティ６２２からのＲＲＣ肯定応答６３６は、単一または複数のＲＲＣメッセージに対するものであることができる。ＲＲＣヘッダー中に１ビットを設定することによってピアＲＲＣ６２２が肯定応答６３６を送るようにＲＲＣ６０６が要求することができ、あるいは、定義上またはデフォルトにより肯定応答６３６を必要とすることができる。ＲＲＣ肯定応答６３６は、特定のＲＲＣメッセージのどのインスタンスが肯定応答されているかを表すことができる。

ＳＤＵが首尾よく配信されたか、または、送信が失敗したかどうかについて最終的に判定されると、下位レイヤーによって上位レイヤーへの配信確認をトリガーすることができる。配信確認を遅らせるために、タイマーを使用することができる。例えば配信確認禁止タイマーを動作させることができる。タイマーが動作している間、配信確認は生起することができない。しかしながら、トリガーが生起し、そしてタイマーが満了したなら、配信確認を上位レイヤーに渡すことができる。

また、上位レイヤーへの配信確認は、例えばハンドオーバー、リセット、または再確立イベントなどのモビリティ・イベントに際し、下位レイヤーがトリガーすることができる。さらに上位レイヤーからの要求に際し、配信確認をトリガーすることができる。

図７は、一実施形態による配信の直接通知の方法７００のブロック図である。ＮＡＳ７０２は、メッセージ７０４をＲＲＣ７０６に送ることができる。メッセージ７０４を送る際にＮＡＳ７０２は、ＮＡＳ７０２が配信確認が欲するか否かをＲＲＣ７０６に表すことができる。ＮＡＳ７０２は、ＲＲＣ７０６および／またはＰＤＣＰ７０８から受信された通知に基づき、メッセージ７０４を直ちに再送するか、メッセージ７０４を元々送ったときに始動したタイマー７１２を停止させるか、または、タイマー７１２を減少させるかもしくは増加させることができる。メッセージ７０４の再送に際し、ＮＡＳ７０２は新しいタイマー７１４を始動することができる。

ＮＡＳ７０２からＮＡＳメッセージ７０４を受信すると、ＲＲＣ７０６はメッセージ７０４を精査する。メッセージ７０４は、配信確認がメッセージ７０４に対して必要であるか否か判定するための、配信状態要求インジケーター（図示せず）を含むことができる。配信確認が必要である場合、ＲＲＣ７０６は、配信確認要求を随意的に含むＮＡＳメッセージ７０４を含むＲＲＣメッセージ７２０、をＰＤＣＰ７０８に発出する。

ＰＤＣＰ７０８は、配信確認要求を含むことができるＲＲＣメッセージ７２０を受信し、そしてメッセージ７２０に対して配信確認が必要であるか否かを判定する。配信確認が必要である場合、ＰＤＣＰ７０８はＲＬＣ７２４にメッセージ７２２を発出する。ＰＤＣＰ７０８は、ＰＤＣＰ７０８が配信確認を必要とするか否かをメッセージ７２２により表す。ＰＤＣＰ７０８は、メッセージ７２２をＲＬＣ７２４に送り、そしてハンドオーバー命令が受信されている場合、ＰＤＣＰ７０８はまた、ハンドオーバーのためにＳＲＢに関係するピアＰＤＣＰ７２８とＰＤＣＰ状態報告７２６を交換することができる。セル選択またはセル再選択がある場合、ＰＤＣＰ７０８はまた、ピアＰＤＣＰ７２８とＰＤＣＰ状態報告７２６を交換することができる。あるいはまた、メッセージ７２２を送る場合、メッセージ７２２のＰＤＣＰヘッダー中に新規ポーリング・ビットを設定することができる。ポーリング・ビットは、ピアＰＤＣＰエンティティ７２８を促してＰＤＣＰ状態報告７２６を生成させることになる。

ＲＬＣ７２４は、ＰＤＣＰ７０８からメッセージ７２２を受信し、そして配信確認のための要件をメッセージ７２２が含むか否かを判定する。メッセージ７２２が配信確認要求を含むなら、ＲＬＣ７２４は、ＲＬＣ状態報告ポーリング・ビットをメッセージのＲＬＣヘッダー中に設定することになる。ＲＬＣ状態報告ポーリング・ビットは、状態報告７３２を生成するべきであることをピアＲＬＣエンティティ７３０に表すことになる。

図８は、一実施形態による通知方法８００のブロック図である。ＮＡＳ８０２は、ＲＲＣＳＤＵ８１２をＲＲＣ８０４に送る。ＲＲＣＳＤＵ８１２は、配信確認要求を含む。ＲＲＣ８０４はＲＲＣＳＤＵ８１２を処理し、そしてＰＤＣＰＳＤＵ８１４をＰＤＣＰ８０６に送る。ＰＤＣＰＳＤＵ８１４は、配信確認要求を含む。ＰＤＣＰ８０６はＰＤＣＰＳＤＵ８１４を処理し、そしてＲＬＣＳＤＵ８１６をＲＬＣ８０８に送る。ハンドオーバーが生起すると、ＰＤＣＰ８０６は、ターゲット・セル中のピアＰＤＣＰ８２４との間でＰＤＣＰ状態報告８２２を送りそして受信することになる。ＰＤＣＰＳＤＵ８１４の配信状態は、ＰＤＣＰ状態報告８２２中に含まれる。ＰＤＣＰ８０６は、配信状態報告８２６をＲＲＣ８０４に送る。そしてＲＲＣ８０４は、配信状態報告８２６をＮＡＳ８０２に転送する。

図９は、別の実施形態による通知方法９００のブロック図である。図９において、ＮＡＳ９０２はＲＲＣＳＤＵ９１２をＲＲＣ９０４に発出する。ＲＲＣＳＤＵ９１２は、配信確認要求を含む。ＲＲＣ９０４はＲＲＣＳＤＵ９１２を処理し、そしてＰＤＣＰＳＤＵ９１４を作成してＰＤＣＰ９０６に送出する。ＰＤＣＰＳＤＵ９１４は、配信確認要求を含むことができる。ＰＤＣＰ９０６はＰＤＣＰＳＤＵ９１４を処理し、そしてＲＬＣＳＤＵ９１６を作成してＲＬＣ９０６に送出する。ＲＬＣ９０８はＲＬＣＳＤＵ９１６を処理し、少なくとも１つのＭＡＣＳＤＵ９１８を作成してＭＡＣ９１０に送出する。ＲＬＣ９０８は、ＡＭモードで機能している間、ピアＲＬＣエンティティ９２２からＡＣＫ／ＮＡＣＫ９２０を受信することができる。そしてＲＬＣ９０８は、ＡＣＫ／ＮＡＣＫ９２０から導出される最新のＲＬＣ配信状態に基づきＰＤＣＰ９０６に配信状態報告９２４を提供する。ＰＤＣＰ９０６は、配信状態報告９２４をＲＲＣ９０４に提供する。ＲＲＣ９０４は、配信状態報告９２４をＮＡＳ９０２に提供する。

＜実施形態＞
１．ＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）におけるデータ配信確認の方法であって、ＵＬ（UpLink：アップリンク）メッセージを送信するステップと、モビリティ動作を実行するステップと、前記ＵＬメッセージが肯定応答されていないことを判定するステップと、配信障害メッセージを生成するステップとを具備する方法。

２．前記モビリティ動作が、ハンドオーバーである、実施形態１におけるような方法。

３．前記モビリティ動作が、ＲＲＣ（Radio Resource Control：無線リソース管理）接続再確立である、実施形態１におけるような方法。

４．前記配信障害メッセージを含むメッセージをプロトコル・レイヤーの間で渡すステップをさらに具備する、実施形態１〜３の何れか１つにおけるような方法。

５．前記配信障害メッセージを含むＲＲＣ（Radio Resource Control：無線リソース管理）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すステップをさらに具備する、実施形態４におけるような方法。

６．前記配信障害メッセージを含むＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すステップをさらに具備する、実施形態４におけるような方法。

７．ＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）状態報告を受信するステップをさらに具備する、実施形態１〜６の何れか１つにおけるような方法。

８．ＲＬＣ（Radio Link Control：無線リンク制御）状態報告を受信するステップをさらに具備する、実施形態１〜６の何れか１つにおけるような方法。

９．データの配信を確認するように構成されるＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）であって、ＵＬ（UpLink：アップリンク）メッセージを送信するように構成される送信機、ならびにモビリティ動作を実行し、前記ＵＬメッセージが肯定応答されていないことを判定し、かつ、配信障害メッセージを生成するように構成される処理装置を具備するＷＴＲＵ。

１０．前記モビリティ動作が、ハンドオーバーである、実施形態９におけるようなＷＴＲＵ。

１１．前記モビリティ動作が、ＲＲＣ（Radio Resource Control：無線リソース管理）接続再確立である、実施形態９におけるようなＷＴＲＵ。

１２．前記処理装置が、前記配信障害メッセージを含むメッセージをプロトコル・レイヤーの間で渡すようにさらに構成された、実施形態９〜１１の何れか１つにおけるようなＷＴＲＵ。

１３．前記処理装置が、前記配信障害メッセージを含むＲＲＣ（Radio Resource Control：無線リソース管理）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すようにさらに構成される、実施形態１２におけるようなＷＴＲＵ。

１４．前記処理装置が、前記配信障害メッセージを含むＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すようにさらに構成される、実施形態１２におけるようなＷＴＲＵ。

１５．ＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）状態報告を受信するように構成される受信機をさらに具備する、実施形態９〜１４の何れか１つにおけるようなＷＴＲＵ。

１６．ＲＬＣ（Radio Link Control：無線リンク制御）状態報告を受信するように構成される受信機をさらに具備する、実施形態９〜１４の何れか１つにおけるようなＷＴＲＵ。

特徴および要素が上で特定の組み合わせにて記述されているが、それぞれの特徴または要素は、他の特徴および要素なしで単独にて、または他の特徴および要素のあるなしに拘わらず様々な組み合わせにて使用可能である。ここに提供された方法またはフロー図は、汎用目的のコンピューターまたは処理装置による実行のための、コンピューターにて読み取り可能な記憶装置媒体に組み込まれたコンピューター・プログラム、ソフトウェア、またはファームウェアにて実施することができる。コンピューターにて読み取り可能な記憶装置媒体の例としては、ＲＯＭ（Read Only Memory：リード・オンリー・メモリ）、ＲＡＭ（Random Access Memory：ランダム・アクセス・メモリ）、レジスター、キャッシュ・メモリ、半導体メモリ・デバイス、内蔵ハード・ディスクおよび着脱可能ディスクなどの磁気媒体、磁気−光学媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（Digital Versatile Disk：デジタル多用途ディスク）などの光学媒体が含まれる。

適当な処理装置の例としては、汎用目的処理装置、専用目的処理装置、従来の処理装置、ＤＳＰ（Digital Signal Processor：デジタル信号処理装置）、複数のマイクロ処理装置、ＤＳＰコアに関連付けられた１つまたは複数のマイクロ処理装置、制御装置、マイクロ制御装置、ＡＳＩＣ（Application Specific Integrated Circuit：特定用途向けＩＣ）、ＦＰＧＡ（Field Programmable Gate Array）回路、他の何れかの種別のＩＣ（Integrated Circuit：集積回路）、および／または状態マシンが含まれる。

ＷＴＲＵ（Wireless Transmit Receive Unit：無線送受信ユニット）、ＵＥ（User Equipment：ユーザー機器）、端末、基地局（base station）、ＲＮＣ（Radio Network Controller：無線ネットワーク制御装置）、または任意のホスト・コンピューターにおいて使用するための無線周波数送受信機を実施するために、ソフトウェアに関連付けられた処理装置を使用することができる。ＷＴＲＵは、ハードウェアおよび／またはソフトウェアにて実施され、カメラ、ビデオ・カメラ・モジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロホン、テレビ送受信機、ハンズフリー受話器、キーボード、ブルートゥース（Bluetooth（登録商標））モジュール、ＦＭ（Frequency Modulated：周波数変調された）無線ユニット、ＬＣＤ（Liquid Crystal Display：液晶ディスプレイ）表示ユニット、ＯＬＥＤ（Organic Light-Emitting Diode：有機発光ダイオード）インジケーションユニット、デジタル音楽プレーヤー、メディア・プレーヤー、テレビゲーム・プレーヤー・モジュール、インターネット・ブラウザー、ならびに／または任意のＷＬＡＮ（Wireless Local Access Network：無線ＬＡＮ）モジュールもしくはＵＷＢ（Ultra Wide Band：超広帯域）モジュールなどのモジュールと連動して使用することができる。

Claims

ＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）におけるデータ配信確認の方法であって、
ＵＬ（UpLink：アップリンク）メッセージを送信するステップと、
モビリティ動作を実行するステップと、
前記ＵＬメッセージが肯定応答されていないことを判定するステップと、
配信障害メッセージを生成するステップと
を具備することを特徴とする方法。
前記モビリティ動作が、ハンドオーバーであることを特徴とする請求項１に記載の方法。
前記モビリティ動作が、ＲＲＣ（Radio Resource Control：無線リソース管理）接続再確立であることを特徴とする請求項１に記載の方法。
前記配信障害メッセージを含むメッセージをプロトコル・レイヤーの間で渡すステップをさらに具備することを特徴とする請求項１に記載の方法。
前記配信障害メッセージを含むＲＲＣ（Radio Resource Control：無線リソース管理）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すステップをさらに具備することを特徴とする請求項４に記載の方法。
前記配信障害メッセージを含むＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すステップをさらに具備することを特徴とする請求項４に記載の方法。
ＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）状態報告を受信するステップをさらに具備することを特徴とする請求項１に記載の方法。
ＲＬＣ（Radio Link Control：無線リンク制御）状態報告を受信するステップをさらに具備することを特徴とする請求項１に記載の方法。
データの配信を確認するように構成されるＷＴＲＵ（Wireless Transmit/Receive Unit：無線送受信ユニット）であって、
ＵＬ（UpLink：アップリンク）メッセージを送信するように構成される送信機と、
処理装置であって、
モビリティ動作を実行し、
前記ＵＬメッセージが肯定応答されていないことを判定し、かつ
配信障害メッセージを生成する、
ように構成される処理装置と
を具備することを特徴とするＷＴＲＵ。
前記モビリティ動作が、ハンドオーバーであることを特徴とする請求項９に記載のＷＴＲＵ。
前記モビリティ動作が、ＲＲＣ（Radio Resource Control：無線リソース管理）接続再確立であることを特徴とする請求項９に記載のＷＴＲＵ。
前記処理装置が、前記配信障害メッセージを含むメッセージをプロトコル・レイヤーの間で渡すようにさらに構成されることを特徴とする請求項９に記載のＷＴＲＵ。
前記処理装置が、前記配信障害メッセージを含むＲＲＣ（Radio Resource Control：無線リソース管理）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すようにさらに構成されることを特徴とする請求項１２に記載のＷＴＲＵ。
前記処理装置が、前記配信障害メッセージを含むＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）メッセージをＮＡＳ（Non-Access Stratum：非アクセス層）のプロトコル・レイヤーに渡すようにさらに構成されることを特徴とする請求項１２に記載のＷＴＲＵ。
ＰＤＣＰ（Packet Data Control Protocol：パケット・データ制御プロトコル）状態報告を受信するように構成される受信機をさらに具備することを特徴とする請求項９に記載のＷＴＲＵ。
ＲＬＣ（Radio Link Control：無線リンク制御）状態報告を受信するように構成される受信機をさらに具備することを特徴とする請求項９に記載のＷＴＲＵ。