JP2010525639A - プロトコル層のリセットを含んでいる手順時におけるプロトコルデータユニットの改良された送信方式 - Google Patents

Abstract

本発明は、プロトコル副層の再確立を含む、例えばハンドオーバー時において、移動ノードのプロトコル副層を介してデータを送信する方法に関する。移動ノードは、ハンドオーバーを予測し、したがって、プロトコル副層の送信バッファを空にするための多くの時間を有する。さらに、まもなく行われるハンドオーバーを検出した時点で、サービスデータユニット（ＳＤＵ）からプロトコルデータユニット（ＰＤＵ）へのセグメント化を停止する。次いで、バッファの中に残っている、ＡＣＫが返されていないＰＤＵを、対応するＳＤＵをソース基地局が再組み立てすることができるように、ソース基地局に再送する。さらに、ＵＥは、各無線ベアラの優先度に応じて、ＡＣＫが返されていないＰＤＵの再送を優先することができる。したがって、ＡＣＫが返されていないＰＤＵの再送が行われない場合のように、ターゲット基地局へのハンドオーバーを実行した後、前に送信されたＰＤＵをもう一度送信する必要がない。
【選択図】図１０

Description

本発明は、プロトコル副層の再確立を含んでいる手順時において移動ノードのプロトコル副層を介してデータを送信する方法に関する。本発明は、手順が移動ノードによって検出された時点においてプロトコル副層の送信バッファの中に依然として存在しているプロトコルデータユニットをＵＥが効率的に再送することを可能にするための複数の異なる方法ステップを提供する。さらには、本発明は、本発明に関与する移動ノードおよび基地局に関する。

Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access：広帯域符号分割多元接続）は、第３世代のワイヤレス移動通信システムとして使用する目的で標準化されたＩＭＴ−２０００システム（International Mobile Telecommunication system：国際移動通信システム）の無線インタフェースである。Ｗ−ＣＤＭＡは、音声サービスやマルチメディア移動通信サービスといったさまざまなサービスをフレキシブルかつ効率的に提供する。日本、欧州、米国、およびその他の国における標準化機関は、Ｗ−ＣＤＭＡの共通の無線インタフェース仕様を策定する目的で、３ＧＰＰ（第３世代パートナーシッププロジェクト）と呼ばれるプロジェクトを共同して組織した。

ＩＭＴ−２０００の欧州における標準化バージョンは、一般にＵＭＴＳ（Universal Mobile Telecommunication System：ユニバーサル移動通信システム）と呼ばれている。ＵＭＴＳ仕様の最初のリリースは、１９９９年に公開された（リリース９９）。その後、３ＧＰＰにより、リリース４、リリース５、リリース６において、この標準に対するいくつかの改良が標準化された。

最近になって、３ＧＰＰは、３Ｇの長期的な競争力を確保するため、３Ｇ標準の次の大きな前進または進化の検討を開始した。３ＧＰＰは、最近、「Evolved UTRA and UTRAN（Ｅ−ＵＴＲＡおよびＵＴＲＡＮ）」という研究項目（一般には「ロングタームエボリューション（ＬＴＥ：Long Term Evolution）」として公知である）に着手した。この研究では、サービスの提供を向上させることと、ユーザおよび事業者側のコストを低減することとを目的として、パフォーマンスの大幅な向上を達成する手段が検討される。一般には、移動制御にはインターネットプロトコル（ＩＰ）を使用し、将来的なサービスすべてがＩＰベースであるものと想定している。したがって、進化の中心的な課題は、従来のＵＭＴＳシステムのパケット交換（ＰＳ）ドメインの機能強化である。

今回の進化の主たる目的は、前述したように、サービスの提供をさらに向上させることと、ユーザおよび事業者側のコストを低減することである。より具体的には、ロングタームエボリューション（ＬＴＥ）における、いくつかの重要なパフォーマンス、能力、および配備上の要求条件は、特に、以下のとおりである。
・ ＨＳＤＰＡおよびＨＳＵＰＡと比較して、データレートが大幅に高いこと（想定されている目標ピークデータレートは、下りが１００Ｍｂｐｓ以上、上りが５０Ｍｂｐｓ以上である）
・ データレートが高く、エリアカバレッジが広いこと
・ 上位層プロトコル（例えば、ＴＣＰ）のパフォーマンスを向上させることと、制御プレーン手順（例えば、セッションの確立）に関連付けられる遅延を低減することとを目的として、ユーザプレーンにおける遅延を大幅に低減すること
・ １．２５ＭＨｚ〜２０ＭＨｚの範囲のさまざまなサイズのスペクトル割当てにおいてスタンドアロンシステムとして動作すること

ロングタームエボリューション研究のうち、配備に関連するさらなる要求条件は、これらの技術になめらかに移行できることである。

現在のアーキテクチャとＬＴＥ ＵＴＲＡＮアーキテクチャ
図１は、ユニバーサル移動通信システム（ＵＭＴＳ：Universal Mobile Telecommunication System）の高レベルリリース９９／４／５／６のアーキテクチャを示している（非特許文献１（http://www.3gpp.orgにおいて利用可能であり、この参照をもってその内容を本願に繰り入れるものとする）を参照）。ＵＭＴＳシステムは、それぞれが所定の機能を有する複数のネットワーク要素から構成されている。ネットワーク要素は、それぞれの機能によって定義されているが、各ネットワーク要素の物理的実装が類似していることも一般的であり、ただし必須条件ではない。

ネットワーク要素は、機能に基づいて、コアネットワーク（ＣＮ）１０１と、ＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ：UMTS Terrestrial Radio Access Network）１０２と、ユーザ機器（ＵＥ）１０３とにグループ化される。ＵＴＲＡＮ １０２は、無線に関連するすべての機能を処理する役割を担っているのに対し、ＣＮ １０１は、外部ネットワークへのデータ接続と呼のルーティングの役割を担っている。ＣＮとＵＴＲＡＮの間と、ＵＴＲＡＮとＵＥの間の相互接続は、オープンインタフェース（それぞれ、Ｉｕ、Ｕｕ）によって定義されている。なお、ＵＭＴＳシステムはモジュール方式であり、したがって、同じタイプのいくつかのネットワーク要素を備えることが可能である。

図２は、３ＧＰＰ ＬＴＥ移動通信ネットワークの例示的な概要を示している。このネットワークは、機能に基づいて、コアネットワーク（ＣＮ）と、無線アクセスネットワーク（ＲＡＮ）と、ユーザ機器（ＵＥ）または移動端末とにグループ化される、複数の異なるネットワークエンティティから構成されている。ＲＡＮは、無線に関連するすべての機能、特に、無線リソースのスケジューリングなどを処理する役割を担っている。ＣＮは、外部ネットワークへのデータ接続と呼のルーティングの役割を担うことができる。

このＬＴＥネットワークは、ユーザデータプレーンに関しては「２ノードアーキテクチャ」であり、いわゆるＳＡＥゲートウェイ（ＳＡＥ−ＧＷ）とエンハンストノードＢ（ｅＮｏｄｅＢまたはｅＮＢとも称する）とから構成されている。制御プレーン上には、上述したエンティティに加えて、移動管理エンティティ（ＭＭＥ）も存在しており、非アクセス階層（ＮＡＳ）シグナリングおよびその他の関連する制御シグナリング（例えば、認証、移動管理）を処理する。ＭＭＥおよびＳＡＥ−ＧＷは、コアネットワーク（ＣＮ）の機能、例えば、３ＧＰＰアクセスネットワーク間で移動するためのＣＮノード間のシグナリング、アイドルモードにあるＵＥのトラッキングおよび到達性、外部ネットワークへのデータ接続と呼のルーティングを処理する。ｅＮｏｄｅＢは、例えば、ヘッダ圧縮、暗号化／整合性保護、無線リソース制御（ＲＲＣ）、分割／連結、リソースのスケジューリングおよび割当て、多重化といった機能と、物理層の機能を処理することができる。

移動通信ネットワークは、一般にはモジュール方式であり、したがって、同じタイプのいくつかのネットワークエンティティを備えていることが可能である。ネットワーク要素の相互接続は、オープンインタフェースによって定義される。ＵＥは、Ｕｕインタフェースとして表されるエアインタフェースを介して、ｅＮｏｄｅＢに接続することができる。ｅＮｏｄｅＢは、いわゆるＳ１−Ｕインタフェースを介してＳＡＥ−ＧＷに接続することができる。ｅＮｏｄｅＢ自体は、いわゆるＸ２インタフェースを介して相互接続される。

３ＧＰＰと非３ＧＰＰの両方の統合は、外部パケットデータネットワーク（例えば、インターネット）とのＳＡＥ−ＧＷのインタフェースを介して処理することができる。

すでに上述したように、図２の例示的なネットワークアーキテクチャにおいては、セルのリソースの所有権は、各ｅＮｏｄｅＢにおいて処理されるものと想定している。セルのリソースの所有権がＳＡＥ−ＧＷの外側で処理されることによって、（ＣＰ／ＵＰフローの両方の）ＳＡＥ−ＧＷのプーリングをサポートすることが可能となり、複数の異なる端末について、１つのｅＮｏｄｅＢをいくつかのＳＡＥ−ＧＷに接続することができる（したがって、単一障害点が回避される）。

なお、上記の考察は一例に過ぎず、標準化委員会における現在の開発状況を表していることに留意されたい。標準は絶え間なく変化しており、上記の例示的なシステムとは一致しないかもしれない。しかしながら、当業者は、今後のシステムの変更された態様に本発明の原理を適用できるであろう。

ＯＳＩ層の概要
図３は、ＯＳＩモデルの簡潔な概要を示しており、本明細書においては、ＬＴＥアーキテクチャおよび本発明について、このＯＳＩモデルに基づいて説明してある。

開放型システム間相互接続参照モデル（ＯＳＩモデルまたはＯＳＩ参照モデル）は、通信ネットワークプロトコルおよびコンピュータネットワークプロトコルの設計を、階層式かつ抽象的に記述したものである。ＯＳＩモデルでは、システムの機能が一連の層に分割される。各層は、特性として、下の層の機能を使用するのみであり、自身の機能は上の層に提供するのみである。これらの一連の層から成るプロトコル挙動を実装しているシステムは、「プロトコルスタック」または「スタック」として知られている。プロトコルスタックの主たる特徴として、１つの層が別の層とどのようにインタラクトするかに関する仕様が、層間の接合部分によって決められている。すなわち、ある製造業者によって書かれた層が、別の製造業者による層と一緒に動作することができる。本発明の理解を目的として、以下では、最初の３つの層のみについてさらに詳しく説明する。

物理層または第１層の主たる目的は、特定の物理媒体（例えば、同軸ケーブル、ツイステッドペア、光ファイバ、エアインタフェースなど）を通じて情報（ビット）を伝送することである。この層は、データを、通信チャネルを通じて送信される信号（またはシンボル）に変換または変調する。

データリンク層（または第２層）の目的は、入力データをデータフレームに分割する（セグメンテーション・リアセンブリ（ＳＡＲ）機能）ことによって、特定の物理層と互換性があるように情報のフローを成形することである。さらに、この層は、失われたフレームの再送を要求することによって、潜在的な送信誤りを検出および訂正することができる。この層は、一般には、アドレッシングメカニズムを提供し、さらに、受信機の能力にデータレートを合わせる目的でフロー制御アルゴリズムを提供することができる。共有媒体が複数の送信機および受信機によって同時に使用される場合、データリンク層は、一般には、物理媒体へのアクセスを調整および制御するメカニズムを提供する。

データリンク層は、膨大な機能を提供するため、しばしば副層（例えば、ＵＭＴＳにおけるＲＬＣ副層およびＭＡＣ副層）に細分される。第２層プロトコルの代表的な例は、固定回線網用のＰＰＰ／ＨＤＬＣ、ＡＴＭ、フレームリレーと、無線システム用のＲＬＣ、ＬＬＣ、またはＭＡＣである。

ネットワーク層または第３層は、トランスポート層によって要求されるサービス品質を維持しながら、可変長のパケットを送信元から１つまたは複数のネットワークを介して送信先に伝送するための機能・手順上の手段を提供する。一般に、ネットワーク層の主たる目的は、特に、ネットワークルーティング機能、ネットワーク分割（network fragmentation）機能、および輻輳制御機能を実行することである。ネットワーク層のプロトコルの代表的な例は、ＩＰインターネットプロトコルまたはＸ．２５である。

第４層〜第７層に関しては、アプリケーションおよびサービスによっては、ＯＳＩモデルの特定の層にアプリケーションまたはサービスを帰属させることが難しいことがあり、なぜなら、第３層より上位で動作するアプリケーションおよびサービスが、ＯＳＩモデルの複数の異なる層に属するさまざまな機能をしばしば実施するためである。したがって、特に、ＴＣＰ（ＵＤＰ）／ＩＰベースのネットワークにおいては、場合によっては第４層以上を結合して、いわゆる「アプリケーション層」を形成する。

ＯＳＩ層モデルに関するさらなる情報は、例えば、非特許文献２に記載されており、この文書は参照によって本出願に組み込まれる。

ＬＴＥにおける層構造およびデータフロー
図４は、ＬＴＥベースのＵＴＲＡＮにおける例示的なユーザプレーンのプロトコルスタックを示している。第２層は、媒体アクセス制御（ＭＡＣ）と、無線リンク制御（ＲＬＣ）と、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）とに分割することができ、この場合、ＲＬＣ副層およびＰＤＣＰ副層は、ネットワーク側においてはｅＮｏｄｅＢにおいて終端している。ＮＡＳ層は、ネットワーク側においてはアクセスゲートウェイにおいて終端している。アクセスゲートウェイとｅＮｏｄｅＢとの間のＳ１−Ｃトランスポート層は、これらのエンティティ間の伝送媒体に特に適合化されている物理層およびＭＡＣ層と一緒にトランスポートネットワーク層を形成する。

移動ノード（ＭＮ、またはユーザ機器ＵＥとも称する）とコアネットワークとの間の制御シグナリングの大部分は、無線リソース制御（ＲＲＣ）メッセージによって行われる。ＲＲＣプロトコルは、第３層に位置しており、ＵＥに固有のシグナリングと、アイドルモードにあるＵＥのページングと、システム情報のブロードキャストの機能を提供する。さらに、ＲＲＣ層は、上位層からの制御情報の正しい送信を保証するための再送機能もサポートしている。

要約すれば、図４は、Ｅ−ＵＴＲＡの制御プレーンの無線インタフェースプロトコルスタックのアーキテクチャを示している。以下では、関連する機能の内容について説明する。
・ ＲＬＣ副層およびＭＡＣ副層（ネットワーク側ではｅＮＢにおいて終端している）は、ユーザプレーンの場合と同じ機能を実行する。
・ ＲＲＣ（ネットワーク側ではｅＮＢにおいて終端している）は、例えば以下に挙げる機能を実行する。
− ブロードキャスト
− ページング
− ＲＲＣ接続管理
− 無線ベアラ（ＲＢ）制御
− 移動機能
− ＵＥ測定レポートおよび制御

・ ＰＤＣＰ副層（ネットワーク側ではｅＮＢにおいて終端している）は、制御プレーンに対しては、例えば以下に挙げる機能を実行する。
− 整合性保護
− 暗号化

・ ＮＡＳ（ネットワーク側ではアクセスゲートウェイ（ａＧＷ）において終端している）は、特に以下の機能を実行する。
− ＳＡＥベアラ管理
− 認証
− アイドルモード時の移動処理
− ＬＴＥ＿ＩＤＬＥにおけるページングの開始
− アクセスゲートウェイとＵＥとの間のシグナリングにおいてと、ユーザプレーンにおいてのセキュリティ制御

層のサービスとデータ交換
以下では、本文書において使用している用語「サービスデータユニット（ＳＤＵ）」および「プロトコルデータユニット（ＰＤＵ）」について、図５を参照しながら定義しておく。ＯＳＩモデルにおける層間でのパケットの交換を一般的かつ形式的に記述する目的で、ＳＤＵエンティティおよびＰＤＵエンティティが導入された。ＳＤＵは、層Ｎに位置しているプロトコルに、いわゆるサービスアクセスポイント（ＳＡＰ）を介してのサービスを要求する、層Ｎ＋１におけるプロトコルから送られる情報の単位（データブロック／情報ブロック）である。ＰＤＵは、送信機および受信機において同じ層Ｎに位置する同じプロトコルのピアプロセス間で交換される情報の単位である。

ＰＤＵは、一般的には、受け取った（１つ以上の）ＳＤＵの処理後のバージョンから構成されるペイロード部分と、その前に位置する、層Ｎに固有のヘッダとによって形成されており、オプションとして、最後のトレイラを有する。これらのピアプロセスの間には、（第１層を除いて）直接的な物理接続が存在しないため、ＰＤＵを層Ｎ−１に転送して処理する。したがって、層ＮのＰＤＵは、層Ｎ−１の観点からはＳＤＵである。

送信機のセグメンテーション（セグメント化）および受信機のリアセンブリ（再組み立て）
図４を再び参照し、ＵＥは、例えば、ユーザからの音声信号を音声フレームに変換し、次いで、それら音声フレームをＩＰプロトコルを介して別のＵＥに送信するための手段を含んでいることができる。ＵＥにおいて、ＲＬＣ層は、上位層（ＰＤＣＰ）から受け取るＳＤＵを、無線チャネル上で送信するのに適するサイズまで、セグメント化、連結、またはパディングを行う。すなわち、ＲＬＣ層は、図６に示したように、セグメント化／連結／パディングに関する情報とシーケンス番号を、結果としてのデータに挿入することによって、無線チャネル上で送信するのに適するＲＬＣ ＰＤＵを構築し、そのＲＬＣ ＰＤＵを下位層（ＭＡＣおよび物理）に渡す。より詳細には、送信機のＲＬＣ層は、上位層から特定のサイズ（例：１００バイト）のＩＰパケットのＲＬＣ ＳＤＵを受け取る。無線チャネル上で送信可能なデータサイズが４０バイトである場合、ＲＬＣ層は、ＲＬＣ ＳＤＵを３つのＲＬＣ ＰＤＵにセグメント化する。各ＲＬＣ ＰＤＵは４０バイトを有し、ＲＬＣヘッダも含んでいる。ＲＬＣヘッダは、特に、シーケンス番号（ＳＮ）を含んでいる。このシーケンス番号は、ＲＬＣ ＰＤＵごとに連続的に１ずつ増大する。この場合、シーケンス番号は、３つのＲＬＣ ＰＤＵの順序を示している。

受信機においては、ＲＬＣ層は、下位層から受け取るＲＬＣ ＰＤＵのシーケンス番号とセグメント化／連結／パディングの情報を解釈することによって、データを回復し、送信機の動作に対応してデータを連結またはセグメント化することによって、ＲＬＣ ＳＤＵを再構築する。ＲＬＣ ＰＤＵを結合して対応するＲＬＣ ＳＤＵにするための正しい順序は、シーケンス番号によって与えられる。次いで、再構築されたＲＬＣ ＳＤＵを、上位層に提供する。

データを上り方向に送信する場合の、ＵＥの基本的なスケジューリング挙動は、主として、ＵＥにおける上りレート制御機能によって制御され、この機能は、無線ベアラ間での上りリソースの共有を管理する。ＲＲＣ層は、各ベアラに優先度および優先ビットレート（ＰＢＲ：Prioritized Bit Rate）を設定することによって、上りレート制御機能を制御する。さらに、ＲＲＣ層は、保証ビットレート（ＧＢＲ：Guaranteed BitRate）の各ベアラの最大ビットレート（ＭＢＲ：Maximum BitRate）を設定する。さらに、非保証ビットレート（Ｎｏｎ−ＧＢＲ）の無線ベアラの各グループに対して、平均最大可能ビットレート（ＡＭＢＲ：Averaged Maximum possible BitRate）を設定する。なお、使用される値は、Ｓ１を介してｅＮＢにシグナリングされる値には関連しなくてもよいことに留意されたい。

上りレート制御機能は、ＵＥが自身の（１つ以上の）無線ベアラを以下の順序において処理するようにする。
１．（１つ以上の）無線ベアラを、ＰＢＲを上限として優先度順位の高い順に処理する
２．前の許可によって割り当てられた残りのリソースについて、（１つ以上の）無線ベアラを優先度順位の高い順に処理する

さらに、上りレート制御機能は、ＭＢＲおよびＡＭＢＲを超えないことを保証する。ＰＢＲのすべてがゼロに設定されている場合、最初のステップを省き、（１つ以上の）無線ベアラを優先度のそのままの順序において処理し、この場合、ＵＥは、優先度の高いデータの送信を最大にする。

図７は、ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢへの、移動ノードのハンドオーバー手順の信号図を示している。現在、ＵＥはソースｅＮＢにアタッチされており、ゲートウェイ（図示していない）を介して別のＵＥとデータを交換しているものと想定する。移動ノードによって絶え間なく実行される測定を設定する目的で、ＵＥはソースｅＮＢから測定制御メッセージを受信する。測定制御メッセージは、例えば、測定の種類、あるいは特定のレポーティングモード（例：定期的またはイベントベース）を示すことができる。これに相応して、ＵＥは、ソースｅＮＢによって示された測定を実行し、結果をソースｅＮＢにレポートする。この測定レポートは、システム情報や仕様などによって設定されている規則に従って、ＵＥによって送られる。次いで、ソースｅＮｏｄｅＢは、この測定情報を使用して、別のネットワーク（すなわち、別のｅＮＢ）への、ＵＥのハンドオーバーを実行するかを、決定することができる。

ソースｅＮＢがハンドオーバーを決定した場合、ハンドオーバー要求メッセージがターゲットｅＮＢに送信され、ターゲット側においてハンドオーバーに対して準備するために必要な情報（ソースｅＮＢにおけるＵＥ Ｘ２シグナリングコンテキスト参照（signaling context reference）、ＵＥ Ｓ１ ＥＰＣシグナリングコンテキスト参照、ターゲットセルＩＤ、ＲＲＣコンテキスト、ＳＡＥベアラコンテキスト）が渡される。さらに、含まれているＵＥ Ｘ２シグナリング参照およびＵＥ Ｓ１シグナリング参照によって、ターゲットｅＮＢはソースｅＮＢをアドレッシングすることができる。

ターゲットｅＮＢによってリソースを許可することができる場合、ターゲットｅＮＢは、受信したＳＡＥベアラＱｏＳ情報に応じて、ハンドオーバーが正常に行われる可能性を高めるために受付制御を実行することができる。ターゲットｅＮＢは、受信したＳＡＥベアラＱｏＳ情報に従って、要求されるリソースを設定し、Ｃ−ＲＮＴＩ（セル無線ネットワーク一時識別子：Cell Radio Network Temporary Identifier）を予約し、このＣ−ＲＮＴＩは、ＲＲＣ接続を識別する、セルレベルにおけるＵＥの一意の識別情報を提供する。ターゲットネットワーク内のターゲットｅＮＢによってＵＥが受け付けられる場合、ターゲットｅＮＢは、第１層／第２層によってハンドオーバーの準備を行い、ハンドオーバー要求ＡＣＫ（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）をＸ２−ｃインタフェースを通じてソースｅＮＢに送る。このハンドオーバー要求ＡＣＫ（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、ハンドオーバーコマンドの一部としてＵＥに送られる透過的コンテナ（transparent container）を含んでいる。ポールビットは、ＲＬＣプロトコルの送信側エンティティが、受信側エンティティから送信フィードバックを送るように要求するために使用される。ポールビットが「１」に設定されているときには、受信側エンティティにフィードバックが配信される。この場合、ハンドオーバーコマンドメッセージを配信するためにＲＬＣ ＡＣＫモードが使用される場合、このメッセージに含まれているすべてのパケットの正常な送信が保証される。コンテナは、新しいＣ−ＲＮＴＩ（場合によっては何らかの別のパラメータ、すなわち、アクセスパラメータ、ＳＩＢなど）を含んでいることができる。さらに、ハンドオーバー要求ＡＣＫ（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）メッセージは、必要な場合、転送トンネルのＲＮＬ（無線ネットワーク層）／ＴＮＬ（トランスポートネットワーク層）情報を含んでいることもできる。

（ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ）（ＲＲＣメッセージ）を生成する。ハンドオーバーコマンド（ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ）は、ターゲットｅＮＢから受信された透過的コンテナを含んでいる。ソースｅＮｏｄｅＢは、必要な整合性保護とメッセージの暗号化とを実行する。ＵＥは、必要なパラメータ（すなわち、新しいＣ−ＲＮＴＩ、可能な開始時間、ターゲットｅＮＢのＳＩＢなど）を有するハンドオーバーコマンド（ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ）を受信し、ハンドオーバーを実行するようにソースｅＮＢによって命令される。多くの場合、ＵＥは、ハンドオーバーコマンド（ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ）の受信に対して、ＲＬＣ ＡＣＫ手順（図示していない）によってＡＣＫを返す必要がある。ハンドオーバーコマンド（ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ）に定義されている開始時間が経過した後、ＵＥは、ターゲットｅＮＢとの同期を実行し、次いで、上りタイミングアドバンス（uplink timing advance）の取得を開始する。これに対して、ネットワークは、上り無線リソース割当ておよびタイミングアドバンスによって応える。

ＵＥは、ターゲットセルに正常にアクセスすると、自身のハンドオーバー手順が完了したことを示すため、ハンドオーバー確認（ＨＡＮＤＯＶＥＲ ＣＯＮＦＩＲＭ）メッセージ（Ｃ−ＲＮＴＩ）を、ターゲットｅＮＢに送る。ターゲットｅＮＢは、ハンドオーバー確認（ＨＡＮＤＯＶＥＲ ＣＯＮＦＩＲＭ）メッセージにおいて送られたＣ−ＲＮＴＩを確認する。これに応じて、ゲートウェイは、下りデータ経路をターゲット側に切り換え、ソースｅＮＢに向かうユーザプレーンリソース／ＴＮＬリソースをすべて解放することができる。さらに、ターゲットｅＮＢは、リソース解放（ＲＥＬＥＡＳＥ ＲＥＳＯＵＲＣＥ）を送ることによって、ハンドオーバーの成功をソースｅＮＢに通知し、リソースの解放をトリガーする（図示していない）。ソースｅＮＢは、リソース解放（ＲＥＬＥＡＳＥ ＲＥＳＯＵＲＣＥ）メッセージを受信した時点で、ＵＥコンテキストに関連付けられている無線リソースと制御プレーンに関連するリソースとを解放することができる。

ハンドオーバーにおいて、ソースｅＮｏｄｅＢからターゲットｅＮｏｄｅＢにパケットを転送するために使用される単位は、ＰＤＣＰ ＰＤＵ（またはＰＤＣＰ ＳＤＵ）であり、なぜなら、ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間でＲＬＣコンテキストが伝送されないものと想定しているためである。すなわち、ソースｅＮｏｄｅＢは、ＵＥからＲＬＣ ＰＤＵを受信した後、それらＲＬＣ ＰＤＵを結合してＲＬＣ ＳＤＵとし、これらのＲＬＣ ＳＤＵを、ハンドオーバー手順時にターゲットｅＮＢに転送することができる。したがって、ソースｅＮＢが受信した１つ以上のＲＬＣ ＰＤＵが、何らかの理由でＲＬＣ ＳＤＵ（すなわち、ＰＤＣＰ ＰＤＵ）にまだ再組み立てされていない場合、これらのＲＬＣ ＰＤＵをターゲットｅＮＢに伝送することができず、したがって、ソースｅＮＢから削除され、これにより失われる。したがって、これらの削除されたＲＬＣ ＰＤＵ（すなわち、対応するＲＬＣ ＳＤＵ）を再び送信しなければならず、ただし、今回はターゲットｅＮＢに送信する。明らかに、この挙動は、無線送信の観点からは効率的ではなく、なぜなら、ハンドオーバー時におけるソースｅＮＢにおけるＲＬＣ ＳＤＵの再組み立てが不完全であるため、全体としてより多くのビットを送信しなければならないためである。

同様に、図８のトラフィックリダイレクト手順においても、ソースｅＮＢにおけるＲＬＣ ＳＤＵの再組み立てが不完全であるため無線送信が非効率的であるという上述した問題が存在する。以下では、トラフィックリダイレクト手順について簡単に要約しておく。トラフィックのロードバランシングは、ＬＴＥシステムにおける移動制御を駆動する主たるメカニズムの１つとすべきである。移動通信システムにおける共有チャネルの特性上の理由から、トラフィックのロードバランシングは不可欠である。すなわち、ユーザのスループットは、セル内のアクティブなＵＥの数が増大するにつれて低減し、負荷は、ユーザの使用感に直接的に影響する。この要求条件は、実際には、ソースｅＮＢにおけるトラフィック負荷が許容されないほど高く、その一方で、ターゲットｅＮＢにおけるトラフィック負荷が、少なくとも１つの端末について受付制御を肯定的に決定できるときに、端末をソースｅＮＢからターゲットｅＮＢに導くことであると言い換えられる。トラフィックリダイレクト手順は、負荷基準によってトリガーされるが（上述したハンドオーバー手順が無線チャネルの品質によってトリガーされるのとは異なる）、ソースｅＮＢにおいてＲＬＣ ＳＤＵに完全に再組み立てされていない、セグメント化されているＲＬＣ ＰＤＵが失われる問題は、図７によるハンドオーバー手順の場合の上述した問題と同じである。

トラフィックリダイレクト手順を実行する決定は、ソースｅＮＢによって行われ、ソースｅＮＢは、自身が制御するネットワークエリア内のトラフィック負荷に関する必要な情報を有する。ソースネットワーク内のトラフィック負荷が高くなりすぎている場合、ソースｅＮＢは、トラフィックリダイレクト手順が必要であるものと判定し、受付要求をターゲットｅＮＢに送信し、このターゲットｅＮＢは、ターゲット側においてハンドオーバーの準備を行うための必要な情報を備えている。そのターゲットｅＮＢは、利用可能なシステムリソースを超えることなしに、ターゲットネットワークにおいて追加のＵＥを処理担当できるかを判定する。受付応答を生成してソースｅＮＢに送信し、それと同時に、ハンドオーバーの準備を行い、対応するリソースを設定する。［ｅＲＲＣ］トラフィックリダイレクトコマンド（Traffic Redirection Command）をＵＥに提供することによって、トラフィックリダイレクトを行うという決定をＵＥに通知する。

したがって、ＵＥはソースセルからデタッチし、新しいターゲットセルとの同期を開始する。ソースｅＮＢは、未処理のパケットをターゲットｅＮＢに転送する、すなわち、すでに再組み立てされた上りＲＬＣ ＳＤＵを転送する。例えば、同じＲＬＣ ＳＤＵに属しているＲＬＣ ＰＤＵが欠落しているために、ソースｅＮＢがＲＬＣ ＳＤＵに結合できなかったＲＬＣ ＰＤＵは、破棄しなければならず、ターゲットセルにおいて再送する必要がある。

この状況について、図９を参照しながらさらに詳しく説明する。図９は、ハンドオーバーまたはトラフィックリダイレクト時におけるＵＥの送信バッファおよびソースｅＮＢの受信バッファの内容を示している。ＵＥにおいては、無線条件に応じて、ＰＤＣＰ ＰＤＵ（すなわち、ＲＬＣ ＳＤＵ）がＲＬＣ ＰＤＵにセグメント化され、したがって、ＲＬＣ ＰＤＵのサイズはフレキシブルである。すでに述べたように、ソースｅＮＢとターゲットｅＮＢとの間でのＲＬＣコンテキスト伝送が行われないものと想定する。ＰＤＣＰ送信バッファは、現時点においてＰＤＣＰ ＰＤＵ ３およびＰＤＣＰ ＰＤＵ ４を有し、このことは、ＰＤＣＰ ＰＤＵ １およびＰＤＣＰ ＰＤＵ ２はすでにＲＬＣ層に渡されたことを意味する。実際に、ＲＬＣ送信バッファは、ＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４を保持しており、この場合、ＰＤＣＰ ＰＤＵ １（ＲＬＣ ＳＤＵ １）がＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ２にセグメント化されており、ＰＤＣＰ ＰＤＵ ２（ＲＬＣ ＳＤＵ ２）がＲＬＣ ＰＤＵ ３およびＲＬＣ ＰＤＵ ４にセグメント化されている。ＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４はソースｅＮＢにすでに送信されており、しかしながら、ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３のみが正常に受信されている。例えば、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４は、干渉などのチャネルの問題に起因してエアインタフェースを通じて失われているものと想定する。

したがって、ソースｅＮＢは、ＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４が属している２つのＲＬＣ ＳＤＵのいずれも再組み立てすることができず、なぜなら、対応するＲＬＣ ＳＤＵを完成させるためにそれぞれ１つのＲＬＣ ＰＤＵが失われているためである。例えば、ＲＬＣ ＳＤＵ １は、ＲＬＣ ＰＤＵ １とＲＬＣ ＰＤＵ ２の両方を必要とする。この瞬間にハンドオーバーまたはリダイレクト手順が実行される場合、ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３をソースｅＮＢの受信バッファから削除しなければならず、なぜなら、ソースｅＮＢからターゲットｅＮＢに転送されるのは、ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）のみであるためである。これに相応して、ターゲットセルへのハンドオーバーが実行された後、ＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４がＵＥからターゲットｅＮＢに送信される。したがって、ハンドオーバー領域において実際に失われたのがＲＬＣ ＰＤＵ ２とＲＬＣ ＰＤＵ ４であっても、完全に受信されていないＲＬＣ ＳＤＵに属するＲＬＣ ＰＤＵすべてが削除されるため、実質的な消失はＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４になる。

3GPP TS 25.401: "UTRAN Overall Description" "Computer Networks", by Andrew S. Tanenbaum, fourth edition, 2002, Prentice Hall PTR, chapter 1.4

本発明の目的は、上に概説した問題の少なくとも１つを克服するメカニズムを提案することである。本発明のさらに具体的な目的は、データの送信に使用されるプロトコル副層がリセットされる手順時における、移動ノードからアクセスネットワークへのデータの送信を改良することである。

本発明のさらに具体的な目的は、移動ノードのハンドオーバー時において、追加の遅延が導入されることなしに、プロトコル層のプロトコルデータユニットを、移動ノードからソース基地局に、無線リソースに関して効率的に送信することを可能にすることである。

これらの目的の少なくとも１つは、独立請求項の主題によって解決される。本発明の有利な実施形態は、従属請求項の主題である。

本発明の一態様によると、移動ノードは、データをネットワークに送信するために使用されているプロトコル層がまもなくリセットされることを事前に認識することが可能であるようにされている。したがって、移動ノードは、プロトコル副層の送信バッファの実際のリセットが行われる前に、送信バッファを空にするための十分な時間を有する。結果として、プロトコル副層のリセットが行われる前および行われた後に、プロトコルデータが重複して送信されることがない。

より詳細には、プロトコル副層がまもなく再確立されることをＵＥが予測した時点で、プロトコルデータユニットのセグメント化をただちに停止する。その時点において、特定の数のサービスデータユニットがプロトコルデータユニットにセグメント化されており、プロトコル副層の送信バッファに入力されている。さらに、送信バッファは、アクセスネットワークにまだ送信されていないプロトコルデータユニットと、アクセスネットワークに送信されたがアクセスネットワークによってＡＣＫが返されていないプロトコルデータユニットとを、含んでいる。さらには、移動ノードの送信バッファの中には、アクセスネットワークに正常に送信され、したがって、移動ノードがアクセスネットワークからのＡＣＫをすでに受信したプロトコルデータユニット、が存在する。

すでに送信されたがまだＡＣＫが返されていないプロトコルデータユニットの送信を優先させることによって、送信バッファを空にする。さらに具体的には、アクセスネットワーク（例えば、基地局）に正常に送信されており、ＡＣＫが返されていないプロトコルデータユニットと同じサービスデータユニットに属しているプロトコルデータユニットは、欠落しているか正常に受信されていないプロトコルデータユニッに起因して、結合して対応するサービスデータユニットにすることができない。さらに、検出時において、１つのＳＤＵのいくつのＰＤＵはすでに送信されているが、同じＳＤＵの別のＰＤＵがまだ送信されていない場合もあり得る。したがって、ＳＤＵの再組み立てを終了するためには、ソースｅＮＢに各ＰＤＵを提供することが重要である。この方法では、データ送信の無線効率が最大となり、なぜなら、受信側においてサービスデータユニットを再組み立てすることができ、プロトコルデータユニットが無駄に送信されることがないためである。

本発明の別の態様（この態様は、ＡＣＫが返されていないプロトコルデータユニットの送信を優先させる態様と組み合わせることができ、これは有利である）は、送信の後、十分な時間および利用可能なリソースが存在するならば、移動ノードの送信バッファの中のプロトコルデータユニットのうち、上りにおいて以前に送信されていないプロトコルデータユニットを、プロトコル副層がリセットされる前に、この時点で受信側に送信することができる。

本発明のさらに別の態様は、プロトコル副層をリセットする、まもなく発行されるコマンドを早期に検出することを、内部的または外部的にトリガーできることに関連する。例えば、ＲＬＣ層の再確立を暗黙的に伴うハンドオーバー手順に関して、ＵＥは、ソースｅＮＢに送信される測定レポートによってハンドオーバーがトリガーされることを内部的に認識することができる。ＲＬＣプロトコルの再確立は、以下では、ＲＬＣプロトコルのリセットと等しい形態において使用される。その一方で、ハンドオーバーの決定についてＵＥにできるだけ早く通知するため、ソースｅＮＢにおけるハンドオーバーの決定の直後に、ソースｅＮＢから通知することができる。

同様に、トラフィックリダイレクト手順の場合、ソースｅＮＢにおける実際の決定の直後にＵＥに提供される新しいトラフィックリダイレクト事前メッセージを導入することによって、肯定的決定についてＵＥに通知することが可能である。

本発明の一実施形態は、移動ノードからのデータを、移動ノードのプロトコル副層を介して、移動通信システムのアクセスネットワークに送信する方法を提供する。この送信は、移動ノードのプロトコル副層のリセットを含んでいる手順時に行われる。移動ノードのプロトコル副層のリセットを含んでいる手順を実行するためのまもなく発行されるコマンドを、移動ノードにおいて検出した時点で、最初に、プロトコル副層のサービスデータユニットからプロトコル副層のプロトコルデータユニットへのセグメント化を停止する。さらに、ＡＣＫが返されていないプロトコルデータユニットを、移動ノードのプロトコル副層によってアクセスネットワークに再送する。

本発明の別の実施形態によると、ＡＣＫが返されていないプロトコルデータユニットをアクセスネットワークに再送するステップは、手順を実行するためのコマンドを受信した後、移動ノードがアクセスネットワークへの自身のアタッチを変更するまで継続される。これによる少なくとも１つの利点は、移動ノードが、受信側においてまだ再組み立てされていない、ＡＣＫが返されていないプロトコルデータユニットすべてを再送するタスクを達成するための、より多くの時間を有することである。

本発明のさらに有利な実施形態においては、手順を実行するためのまもなく発行されるコマンドを検出する前に、プロトコル副層における第２のプロトコル副層からサービスデータユニットを受け取った時点で、サービスデータユニットを、プロトコル副層のプロトコルデータユニットにセグメント化し、次いで、プロトコル副層のセグメント化されているプロトコルデータユニットを、プロトコル副層の送信バッファに入力する。

さらに、再送するステップは、前記アクセスネットワークに送信されたが前記アクセスネットワークによってＡＣＫが返されていない、プロトコル副層の送信バッファの中のセグメント化されているプロトコルデータユニット、を再送するステップ、を含んでいる。この形態の１つの利点として、このような、ＡＣＫが返されていないプロトコルデータユニットは、受信側において再組み立てしなければならない特定のサービスデータユニットに属しているため、それらＡＣＫが返されていないプロトコルデータユニットを受信した後に、受信側においてサービスデータユニットを生成することができる。これは、リソースに関して極めて効率的でもある。

本発明のさらに具体的な実施形態は、手順を実行するためのまもなく発行されるコマンドを検出した時点においてアクセスネットワークに送信されていない、セグメント化されているプロトコルデータユニットをさらに含んでいる、移動ノードのプロトコル副層の送信バッファに関する。プロトコル副層は、送信バッファの中のＡＣＫが返されていないプロトコルデータユニットすべてをアクセスネットワークに再送した後、アクセスネットワークに送信されていない、セグメント化されているプロトコルデータユニットを、アクセスネットワークに送信する。この優先化によって、利用可能なリソースを、より重要なプロトコルデータユニットのために効率的に使用することができ、より重要なプロトコルデータユニットとは、正常に受信されていないプロトコルデータユニットに起因して受信側において再組み立てできなかったサービスデータユニットに属しているプロトコルデータユニットである。

本発明の別の実施形態によると、プロトコル副層は、無線リンク制御副層である。さらに、手順を実行するためのまもなく発行されるコマンドを検出した時点において、アクセスネットワークに送信されたがアクセスネットワークによってＡＣＫが返されていない、無線リンク制御副層のプロトコルデータユニット、の送信は、アクセスネットワークに送信されていない、無線リンク制御副層のプロトコルデータユニット、の送信よりも、優先される。前と同様に、この優先化によって、移動ノードは自身のリソースを効率的に使用することが可能になる。

次に、本発明のさらに有利な実施形態を説明する。手順を実行するためのまもなく発行されるコマンドを検出した時点で、移動ノードは、所定の時間だけ待機してから、手順を実行するためのコマンドを受信する。移動ノードのプロトコル副層のリセットを含んでいる手順を実行するためのコマンドを移動ノードが受信する前に、所定の時間が経過した場合、移動ノードは、プロトコル副層のサービスデータユニットから、プロトコル副層のプロトコルデータユニットへのセグメント化を再び開始する。使用される所定の時間は、事業者によって自由に設定することができ、したがって、本発明の本実施形態は、フレキシブルに実施することができる。

本発明の別の実施形態によると、移動ノードのプロトコル副層は、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニット、をアクセスネットワークに再送するための限られたシステムリソースを有する。移動ノードのシステムリソースが、ＡＣＫが返されていないプロトコルデータユニットを再送するうえで十分ではない場合、移動ノードは、アクセスネットワークからの追加のシステムリソースを要求し、追加のシステムリソースに関する情報を、アクセスネットワークから受信する。

したがって、追加のシステムリソースを利用して、ＡＣＫが返されていないプロトコルデータユニットをアクセスネットワークに再送する。移動ノードは、最初は十分なリソースを保持していないことがあるが、本発明の本実施形態では、移動ノードは、ＡＣＫが返されていないプロトコルデータユニットの再送を履行する目的で、追加のリソースを要求することができる。

本発明のさらに有利な実施形態においては、移動ノードは、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニット、のデータ量を求める。次いで、ＡＣＫが返されていないプロトコルデータユニットの求められたデータ量に関する情報を含んでいる、追加のシステムリソースを要求する要求メッセージ、をアクセスネットワークに送信する。

本発明の代替実施形態においては、移動ノードは、データをアクセスネットワークに送信するために使用される各無線ベアラについて、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニット、のデータ量を求める。

本発明の上の実施形態に基づくと、追加のシステムリソースの要求を移動ノードから受信した時点で、各無線ベアラのために使用されるシステムリソースの量を、各無線ベアラの優先度に基づいて、決定する。次いで、この決定を移動ノードに通知する。この実施形態は、前の実施形態と比較すると、無線ベアラの優先度を考慮することができ、したがってよりフレキシブルに実施できるという利点を少なくとも有する。

本発明のさらに別の代替実施形態を説明する。移動ノードは、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニット、のデータ量と、ＡＣＫが返されていないプロトコルデータユニットが属しているサービスデータユニットのデータ量とを求める。次いで、求められたデータ量に関する情報を含んでいる、追加のシステムリソースを要求する要求メッセージ、をアクセスネットワークに送信する。要求メッセージにより多くの情報を含めることによって、アクセスネットワークは、どの移動ノードにどれだけのリソースを許可するかについて、より複雑な決定を行うことができる。

本発明のさらに詳細な実施形態においては、上の求める方法のうち、どれを使用するかの決定は、移動ノードからアクセスネットワークにデータを送信するための無線ベアラの確立時に行う。これに相応して、決定に関する情報を、無線ベアラの確立について移動ノードに通知するためにアクセスネットワークから移動ノードに送信されるメッセージの中に含める。

本発明の有利な実施形態によると、移動ノードが、移動ノードのプロトコル副層のリセットを含んでいる手順を実行するためのまもなく発行されるコマンドを検出した後、移動ノードは、利用可能なシステムリソースに基づいて、もしくは、ＡＣＫが返されていないプロトコルデータユニットを示している情報に基づいて、またはこれら両方に基づいて、各無線ベアラに優先度を割り当てる。

本発明の別の実施形態は、プロトコル副層が移動ノードの無線リンク制御副層であることに関する。さらに、無線リンク制御副層のサービスデータユニットは、移動ノードのパケットデータコンバージェンスプロトコル副層から受け取る。

本発明のさらに具体的な実施形態においては、移動ノードのプロトコル副層のリセットを含んでいる手順は、移動通信システムにおける第１の基地局から第２の基地局への移動ノードのハンドオーバー手順である。

本発明の上の実施形態の続きにおいては、移動ノードは、ハンドオーバーに関連して、移動ノードとアクセスネットワークとの間の無線チャネルに関する測定を実行する。測定によって、第１の基地局において、第２の基地局への移動ノードのハンドオーバーがトリガーされるものと移動ノードが判定する場合、移動ノードは、ハンドオーバー手順を実行するためのまもなく発行されるコマンドを検出する。移動ノードは、次のハンドオーバーを内部的に予測することができ、したがって、ＡＣＫが返されていないプロトコルデータユニットの再送を、十分な時間をもって開始することができ、これは有利である。

本発明の代替実施形態は、移動ノードのプロトコル副層のリセットを含んでいる手順が、移動通信システムにおける第１の基地局から第２の基地局への、移動ノードのためのトラフィックリダイレクト手順である場合に関する。

本発明の上の実施形態に基づくと、第１の基地局は、トラフィックリダイレクト手順を実行するかを、第１の基地局によって制御されているネットワークエリア内のトラフィック負荷に基づいて決定する。さらに、移動ノードは、移動ノードのためのトラフィックリダイレクト手順を実行するという、第１の基地局における決定、について移動ノードに通知する事前通知を、第１の基地局から受信することによって、トラフィックリダイレクト手順を実行するためのまもなく発行されるコマンドを検出する。この場合、移動ノードは、まもなく行われるイベントについて外部から通知され、このことは、移動ノードが追加の機能を必要とせず、したがって単純にすることができることを意味する。

本発明の一実施形態は、移動ノードのプロトコル副層のリセットを含んでいる手順時において、プロトコル副層のプロトコルデータユニットを移動通信システムのアクセスネットワークに送信する移動ノードを提供する。移動ノードにおけるプロセッサは、移動ノードのプロトコル副層のリセットを含んでいる手順を実行するためのまもなく発行されるコマンドを検出し、次いで、手順を実行するためのまもなく発行されるコマンドを検出した時点で、プロトコル副層のサービスデータユニットからプロトコル副層のプロトコルデータユニットへのセグメント化を停止する。移動ノードにおける送信機は、手順を実行するためのまもなく発行されるコマンドが検出された時点で、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットを、アクセスネットワークに再送する。

本発明の別の実施形態によると、プロセッサは、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットの再送を、手順を実行するためのコマンドを受信した後、移動ノードがアクセスネットワークへの自身のアタッチを変更するまで、続行する。

本発明のさらなる実施形態においては、プロトコル副層の送信バッファは、手順を実行するためのまもなく発行されるコマンドが検出された時点において、ＡＣＫが返されていないプロトコルデータユニットと、アクセスネットワークに送信されていない、セグメント化されているプロトコルデータユニットとを含んでいる。さらに、送信機は、ＡＣＫが返されていないプロトコルデータユニットすべてを再送し、その後、アクセスネットワークに送信されていない、セグメント化されているプロトコルデータユニットを送信する。

本発明の別の実施形態は、プロセッサが、手順を実行するためのまもなく発行されるコマンドを検出した時点において、アクセスネットワークに送信されたがアクセスネットワークによってＡＣＫが返されていない、プロトコル副層のプロトコルデータユニット、の送信を、アクセスネットワークに送信されていないプロトコルデータユニット、の送信よりも優先させることに関する。

本発明のさらに詳細な実施形態を説明する。手順を実行するためのまもなく発行されるコマンドをプロセッサが検出した時点で、プロセッサは、所定の時間だけ待機してから、プロトコル副層のリセットを含んでいる手順を実行するためのコマンドを受信する。移動ノードにおける受信機が、手順を実行するためのコマンドを受信する前に、所定の時間が経過した場合、プロセッサは、プロトコル副層のサービスデータユニットのセグメント化を再び開始する。

本発明の別の実施形態においては、プロセッサは、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニット、をアクセスネットワークに再送するうえで、プロトコル副層のシステムリソースが十分であるか否かを判定する。システムリソースが十分ではないものとプロセッサが判定した場合、送信機が、追加のシステムリソースを要求する要求メッセージをアクセスネットワークに送信する。移動ノードにおける受信機は、許可された追加のシステムリソースに関する情報をアクセスネットワークから受信する。さらに、次いで、プロセッサが、許可された追加のシステムリソースを利用して、ＡＣＫが返されていないプロトコルデータユニットをアクセスネットワークに再送する。

本発明の有利な実施形態によると、プロトコル副層のリセットを含んでいる手順は、移動通信システムにおける第１の基地局から第２の基地局への移動ノードのハンドオーバー手順である。この場合、移動ノードとアクセスネットワークとの間の無線チャネルに関する測定によって、第１の基地局において、第２の基地局への移動ノードのハンドオーバーがトリガーされるものとプロセッサが判定するとき、プロセッサは、ハンドオーバー手順を実行するためのまもなく発行されるコマンドを検出する。

本発明の代替実施形態においては、プロトコル副層のリセットを含んでいる手順は、移動通信システムにおける第１の基地局から第２の基地局への、移動ノードのためのトラフィックリダイレクト手順である。この場合、移動ノードのためのトラフィックリダイレクト手順を実行するという、第１の基地局における決定、についての事前通知を、受信機が第１の基地局から受信したとき、プロセッサは、トラフィックリダイレクト手順を実行するためのまもなく発行されるコマンドを検出する。

本発明の別の実施形態は、プロトコル副層のリセットを含んでいる手順時において、移動通信システムにおける移動ノードのプロトコル副層とデータを交換する基地局を提供する。基地局におけるプロセッサは、プロトコル副層のリセットを含んでいる手順を実行することを決定する。さらに、基地局における送信機は、プロセッサが決定を実行した時点で、手順を実行するという決定について移動ノードに通知する事前通知を、移動ノードに送信する。

本発明のさらに具体的な実施形態によると、プロトコル副層のリセットを含んでいる手順は、基地局から別の基地局への、移動ノードのためのトラフィックリダイレクト手順またはハンドオーバー手順である。

本発明の有利な実施形態においては、基地局における受信機は、ある量のデータを送信するために必要である追加のシステムリソースを要求するリソース要求メッセージを、移動ノードから受信し、このリソース要求メッセージは、データ量に関する情報を含んでいる。プロセッサは、そのデータ量を送信するために使用されるシステムリソースの量を、リソース要求メッセージの中の受信された情報に基づいて、さらに決定する。次いで、送信機が、決定されたシステムリソース量に関する情報を移動ノードに送信する。

本発明の詳細な実施形態によると、移動ノードは、移動ノードのプロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットのデータ量を求めることによって、または、プロトコルデータユニットを基地局に送信するために使用される各無線ベアラについて、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットのデータ量を求めることによって、または、プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットのデータ量と、ＡＣＫが返されていないプロトコルデータユニットが属しているサービスデータユニットのデータ量とを求めることによって、リソース要求メッセージの中に含めるデータ量を求める。次いで、プロセッサは、リソース要求メッセージの中に含まれるデータ量を移動ノードによって求める方法を決定し、送信機が、移動ノードによってデータ量を求める方法に関する決定について移動ノードに通知する設定メッセージを、移動ノードに送信する。

本発明のさらなる実施形態を説明する。設定メッセージは、プロトコル副層のリセットを含んでいる手順を実行するためのコマンドのメッセージである、または、無線ベアラの確立について移動ノードに通知するために基地局から移動ノードに送信されるメッセージである、または、プロトコル副層のリセットを含んでいる手順を実行するという決定について移動ノードに通知する事前通知のメッセージである。

以下では、本発明について、添付の図面を参照しながらさらに詳しく説明する。図面における類似または対応する細部は、同じ参照数字を用いて表してある。

ＵＭＴＳ Ｒ９９／４／５によるＵＭＴＳの高レベルアーキテクチャを示している。 ３ＧＰＰ ＬＴＥ研究プロジェクトによるＵＴＲＡＮの例示的なアーキテクチャを示している。 ＯＳＩ層モデルの概要を示している。 ＵＴＲＡＮの無線インタフェースプロトコルアーキテクチャの概要を示している。 ＯＳＩ層モデルにおけるサービスデータユニット（ＳＤＵ）とプロトコルデータユニット（ＰＤＵ）との関係を示している。 ＲＬＣ ＳＤＵからいくつかのＲＬＣ ＰＤＵへの例示的なセグメント化を示している。 ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間での移動ノードのハンドオーバー手順のシグナリング図である。 ソースｅＮｏｄｅＢとターゲットｅＮｏｄｅＢとの間での移動ノードのトラフィックリダイレクト手順のシグナリング図である。 移動ノードの送信バッファおよび基地局の受信バッファを示しており、移動ノードの送信バッファの中に、ＡＣＫが返されていないプロトコルデータユニットが存在する問題を説明するために使用する。 本発明の一実施形態によるハンドオーバー手順のシグナリング図である。 移動ノードの送信バッファおよび基地局の受信バッファを示しており、本発明の実施形態の恩恵を例示するために使用する。 別のシナリオの場合の、移動ノードの送信バッファおよび基地局の受信バッファをもう一度示している。 本発明の別の実施形態による、トラフィックリダイレクト手順のシグナリング図を示している。 ２つの異なる無線ベアラを有する移動ノードの送信バッファを示しており、バッファの中の各プロトコルデータユニットのデータ量をさらに示している。 ２つの移動ノードの送信バッファを示しており、バッファの中の各プロトコルデータユニットのそれぞれのデータ量を示している。 ハンドオーバー手順のシグナリング図と、ハンドオーバーが予測された時点における無線ベアラ送信のレベルとを組み合わせてあり、プロトコルデータユニットの再送における制限の影響について説明している。 優先度の異なる２つの無線ベアラを有する移動ノードの送信バッファと、送信バッファの対応する内容とを示している。

定義
以下に、本文書において頻繁に使用されるいくつかの用語の定義を示しておく。

「移動ノード」は、通信ネットワーク内の物理エンティティである。１つのノードが、いくつかの機能エンティティを有することができる。機能エンティティとは、所定の一連の機能を実施する、もしくは、ノードまたはネットワークの別の機能エンティティに、所定の一連の機能を提供する、またはその両方であるソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、自身を通信設備または通信媒体にアタッチする１つまたは複数のインタフェースを有することができ、ノードは、これら通信設備または通信媒体を通じて通信することができる。同様に、ネットワークエンティティは、機能エンティティを通信設備または通信媒体にアタッチする論理インタフェースを有することができ、ネットワークエンティティは、これら通信設備または通信媒体を通じて別の機能エンティティまたは対応するノードと通信することができる。

プロトコル（副）層の「リセット」は、その結果として、送信側および受信側におけるそのプロトコル（副）層の現在のプロトコルデータユニットが消去される。

以下の段落では、本発明のさまざまな実施形態について説明する。例示のみを目的として、ほとんどの実施形態は、上の［背景技術］における説明および後からの説明による３ＧＰＰ−ＬＴＥ通信システムおよび３ＧＰＰ−ＵＭＴＳ通信システムに関連して概説してある。なお、本発明は、例えば、３ＧＰＰ−ＬＴＥ通信システムおよび３ＧＰＰ−ＵＭＴＳ通信システムなどの移動通信システムに関連して有利に使用することができるが、本発明は、これら特定の例示的な通信ネットワークにおける使用に限定されないことに留意されたい。

上の［背景技術］のセクションに示した説明は、本明細書に説明されている、ほとんどが３ＧＰＰをベースとする例示的な実施形態を深く理解することを目的としており、移動通信ネットワークにおけるプロセスおよび機能の、説明した特定の実施形態に、本発明を制限するものではないことを理解されたい。しかしながら、本文書に提案されている改良・改善は、［背景技術］のセクションに説明されているアーキテクチャ／システムにただちに適用することができ、本発明のいくつかの実施形態においては、これらのアーキテクチャ／システムの標準の手順と、改良された手順とを利用することもできる。

以下では、関連するプロトコル副層は、ＵＥおよびソースｅＮＢの無線リンク制御副層であるが、別の（副）層も可能であり、当業者は、そのような（副）層の場合にも本発明の以下の原理を適用できるであろう。例えば、移動ノードが通信するピアエンティティは、プロトコル副層およびプロトコル副層の終端に応じて変化する。図４から理解できるように、ＰＤＣＰ副層は、ｅＮｏｄｅＢにおいて終端している。これに対して、ＮＡＳ層はアクセスゲートウェイ（ａＧＷ）において終端しており、このことは、受信側エンティティが、ＲＬＣ層の場合のように基地局ではなく、アクセスゲートウェイであることを意味する。同様に、本発明の以下の実施形態を、例示したＲＬＣ副層とは異なる副層に適用するときの、それ以外の変更も、当業者には明らかであろう。

無線リンク制御（ＲＬＣ）プロトコルは、セルラーシステムにおいて、アクセスゲートウェイにおけるＰＤＣＰ層から受け取る上位層のＰＤＵ（すなわち、ＩＰパケット）の伝送と、ユーザデータおよび制御データの両方における誤り回復のために使用される、第２層プロトコルである。

ＲＬＣ ＳＤＵは、例えば、ＰＤＣＰ ＰＤＵ（ＰＤＣＰヘッダを含む）とすることができる。ＲＬＣ層は、すでに前述したように、セグメント化と連結の機能を含んでいる。したがって、ＲＬＣ ＰＤＵは、１つ（またはいくつかの）ＲＬＣ ＳＤＵの１つ（またはいくつかの）セグメントである（または含んでいる）ことができる。

ＲＬＣの動作モードは、透過モード（ＴＭ：Transparent Mode）と、非ＡＣＫモード（ＵＭ：Unacknowledged Mode）と、ＡＣＫモード（ＡＭ：Acknowledged Mode)の３つが存在する。各ＲＬＣエンティティは、これらのモードの１つにおいて動作するように、ＲＲＣによって設定される。制御プレーンにおいてＲＬＣ層が提供するサービスを、シグナリング無線ベアラ（ＳＲＢ）と称する。ユーザプレーンにおいては、ＲＬＣ層が提供するサービスを無線ベアラ（ＲＢ）と称する。

透過モードにおいては、上位層から受け取るＲＬＣ ＳＤＵにプロトコルオーバーヘッドは加えられない。特殊な場合には、セグメント化／再組立て（セグメンテーション／リアセンブリ）の能力が限られている送信を達成することができる。無線ベアラの確立手順において、セグメント化／再組立てを使用するかを交渉しなければならない。透過モードは、例えば、会話など、遅延の影響を極めて受けやすいサービスに使用される。

非ＡＣＫモードにおいては、再送プロトコルが使用されないため、データの配信が保証されない。ＰＤＵ構造は、上位層における整合性監視のためのシーケンス番号を含んでいる。データに追加されるヘッダフィールドによって、セグメント化および連結が提供される。非ＡＣＫモードにおけるＲＬＣエンティティは一方向性であり、なぜなら、上りと下りの間にアソシエーションが定義されていないためである。誤りのあるデータが受信された場合、対応するＰＤＵは、設定に応じて破棄またはマークされる。送信機においては、タイマーによって指定される特定の時間内に送信されないＲＬＣ ＳＤＵは、破棄され、送信バッファから削除される。上位層から受け取るＲＬＣ ＳＤＵは、送信側においてセグメント化／連結されてＲＬＣ ＰＤＵにされる。受信側においては、それに相応して再組立てを実行する。非ＡＣＫモードは、例えば、特定のＲＲＣシグナリング手順において使用される。ユーザサービスの例は、セルブロードキャストサービス（例：ＭＢＭＳ）およびボイスオーバーＩＰ（ＶｏＩＰ：voice over IP）である。

ＡＣＫモードにおいては、ＲＬＣ層は、自動再送要求（ＡＲＱ：Automatic Repeat Request）プロトコルによる誤り訂正をサポートする。ＲＬＣ再送は、例えば、ピアＲＬＣ受信側エンティティ（この場合には基地局）から受信されるＲＬＣステータスレポート（すなわち、ＡＣＫ／ＮＡＣＫ）に基づく。ＡＣＫモードは、エアインタフェースのビット誤り率が高い場合に、再送を通じてパケットデータが高い信頼性にて伝送されるように設計されている。ＰＤＵに誤りがある、または失われた場合、受信機からのステータスレポートを受信した時点において、送信側によって再送が行われる。

ＡＲＱは、誤りのあるＰＤＵまたは欠落しているＰＤＵを再送するための再送方式として使用される。ステータスレポートは、例えば、送信側によってポーリングすることができる、または、自己トリガーする、すなわち、シーケンス番号の順序の途切れを検出した時点でトリガーすることができる。受信機は、トリガーされたときにステータスレポートを送信側に送る。このレポートは、一般には、受信ウィンドウ内、最後に受信されたＰＤＵまでの受信ステータス（ＡＣＫまたはＮＡＣＫのいずれか）を示す。

ＡＣＫモードのＲＬＣは、上位層への順次配信および非順次配信の両方を提供するように設定することができる。すでに前述したように、データＰＤＵの配信に加えて、ステータス制御およびリセット制御のＰＤＵを、ピアエンティティ間でシグナリングすることができる。ＡＣＫモードは、パケットタイプのサービス（例えば、インタラクティブサービス、バックグラウンドサービス）におけるデフォルトモードである。

要約すれば、ＲＬＣ副層の主たるサービスおよび機能として、以下が挙げられる。
・ 上位層ＰＤＵの伝送（ＡＣＫモード（ＡＭ）、非ＡＣＫモード（ＵＭ）、または透過モード（ＴＭ）でのデータ伝送をサポートする）
・ ＡＲＱによる誤り訂正
・ 伝送ブロック（ＴＢ）のサイズに従ってのセグメント化
・ 必要なときの再セグメント化（例えば、無線品質、すなわち、サポートされる伝送ブロックサイズが変化するとき）
・ 同じ無線ベアラがＦＦＳである場合のＳＤＵの連結
・ 上位層ＰＤＵの順次配信
・ 重複の検出
・ プロトコル誤りの検出および回復
・ ＳＤＵの破棄
・ リセット

以下の説明においては、ＲＬＣ層が非ＡＣＫモードに設定されているものと想定する。

本発明の第１の態様は、移動ノードのプロトコル副層が再起動されるコマンドを早期に検出することに基づいている。本発明の一実施形態について、図１０を参照しながらさらに詳しく説明する。図１０は、本発明のこの実施形態による、ＵＥのハンドオーバー手順のシグナリング図を示している。さらに詳細には、ＵＥは、ハンドオーバーを目的として実施される測定によって、自身が現在アタッチしているソースｅＮｏｄｅＢにおいてハンドオーバーがトリガーされるかを判定することができる。言い換えれば、ハンドオーバーが必要であるかを決定する唯一のエンティティは、通常ではｅＮｏｄｅＢである。本発明のこの実施形態によると、ソースｅＮｏｄｅＢにおける、まもなく行われる決定を事前に検出する目的で、同じ機能を備えている。このことは、ＵＥおよびソースｅＮｏｄｅＢにおける決定が同じパラメータに基づいているべきであることも意味する。したがって、ソースｅＮｏｄｅＢにおけるハンドオーバーの決定をＵＥが正しく予測することができるように、決定パラメータ／しきい値を同期させる必要がある。例えば、事業者が、ソースｅＮｏｄｅＢにおけるハンドオーバーの決定のためのパラメータを設定するとき、ＵＥにも同じパラメータを提供しなければならない。このことは、ソースｅＮｏｄｅＢによって動的ベースにおいて行う、または、事業者による半静的な設定に基づいて行うことができる。

すでに前述したように、ＵＥは、無線チャネル（例：品質）に関する測定を絶え間なく実行し、次いで、測定について測定レポートメッセージによってソースｅＮＢに通知する。本実施形態においては、ＵＥは、ソースｅＮＢにおいてハンドオーバー手順がトリガーされるしきい値を、測定値が上回っている／下回っているかを判定する能力を備えているため、ＵＥは、特定の無線チャネルパラメータの測定時に、まもなく行われるハンドオーバーの決定を最終的に検出する。例えば、無線チャネルの品質が、エアインタフェースを通じての正常かつ効率的な送信が保証される最小値を下回った時点で、ＵＥは、そのことをソースｅＮＢにレポートし、それと同時に、無線チャネルの不良な品質に起因してソースｅＮＢがハンドオーバーを実際にトリガーするであろうことを自身で判定することができる。

本発明のこの実施形態によると、その場合、ＵＥは、ＲＬＣ ＳＤＵからＲＬＣ ＰＤＵへの進行中のセグメント化を停止する。これにより、ＲＬＣ副層においてＰＤＵがそれ以上生成されず、ＵＥにおけるＲＬＣ層の対応する送信バッファにもはや入力されない。本質的にこれと同時に、ＲＬＣプロトコル副層は、自身の送信バッファを空にするステップを開始する。このステップには、特に、ＡＣＫが返されていないＰＤＵと、まだ送信されていないＰＤＵとを含む、送信バッファの中に存在するすべてのＲＬＣ ＰＤＵをソースｅＮＢに送信するステップが含まれる。図１０には、ＡＣＫが返されていないＲＬＣ ＰＤＵの再送をＵＥが実行することのできる期間である時間Ｔｒｔｒを示してある。この時間Ｔｒｔｒは、ＵＥがその無線セルから実際にデタッチするまで存続するように設定する（図示していない）、または、図１０に実際に示してあるように、ハンドオーバーコマンドを受信するまで延ばすことができる。

本発明のさらに有利な実施形態によると、ＵＥは、誤りのあるＲＬＣ ＰＤＵに起因してソースｅＮＢにおいて再組み立てできなかったＲＬＣ ＳＤＵに属している、ＡＣＫが返されていない残っているＲＬＣ ＰＤＵの送信を、優先させる。これにより、システムリソースの最良の使用がもたらされるため、この方策は有利であり、なぜなら、ＲＬＣ ＳＤＵの一部はソースｅＮＢにおいてすでに正常に受信されており、それら同じＲＬＣ ＳＤＵに属している、ＡＣＫが返されていないＲＬＣ ＰＤＵを再送することによって、それらＲＬＣ ＳＤＵを正しく再組み立てすることができ、リソースが無駄にならないためである。

この状況について、図９を参照しながら例示的に説明する。ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３は、ソースｅＮＢにおいて正常に受信されているのに対し、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４は、ソースｅＮＢにおいて正常に受信されていない。したがって、ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３はＡＣＫが返されており、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４はＡＣＫが返されていないままである。本発明のこの実施形態によると、この時点で、ＰＤＣＰ ＰＤＵからＲＬＣ ＰＤＵへのセグメント化を停止し、ＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４のみが送信バッファの中に残っている。

これに相応して、受信側（ソースｅＮＢ）の受信バッファは、ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３によってのみ構成されている。したがって、ＲＬＣ ＳＤＵ １およびＲＬＣ ＳＤＵ ２を再組み立てすることができず、なぜなら、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４が依然として欠落しているためである。本発明のこの実施形態によると、次いで、ハンドオーバーを実行する（したがって、ＲＬＣ副層をリセットする）ためのまもなく発行されるコマンドを検出した時点で、ＵＥは、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４を、これらがソースｅＮＢによって正常に受信され、したがってＡＣＫが返されるまで、再送する。この再送には、ＲＬＣ ＰＤＵがソースｅＮＢに再び正常に送信されなかった場合には、さらなる再送を含めることができる。このステップは、再送されたＲＬＣ ＰＤＵに関するソースｅＮＢからのＡＣＫを受信するまでＵＥが待機する所定の時間期間が設定されたタイマーによって、達成することができる。

結果として、ソースｅＮＢは、４つのＲＬＣ ＰＤＵを結合してＲＬＣ ＳＤＵ １およびＲＬＣ ＳＤＵ ２を形成することができる。従来技術におけるように、ソースｅＮＢにおいてＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３を消去する必要がない。これに相応して、次いで、ＲＬＣ ＳＤＵ １およびＲＬＣ ＳＤＵ ２が、ＰＤＣＰ ＰＤＵ １およびＰＤＣＰ ＰＤＵ ２としてＰＤＣＰ層に転送され、ソースｅＮＢにおけるＲＬＣ層の受信バッファが空になる。

図１１は、ＵＥにおけるＲＬＣ副層の送信バッファの、わずかに異なる構成を示している。すなわち、ＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ３がソースｅＮＢに正常に送信されており、したがって、肯定応答（ＡＣＫ）が返されている。ＲＬＣ ＰＤＵ ４のみがソースｅＮＢによってＡＣＫが返されていない。したがって、ソースｅＮＢにおいては、ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ２から成るＲＬＣ ＳＤＵ １を、再組み立てしてからＰＤＣＰ層に転送することができる。対照的に、ＲＬＣ ＳＤＵ ２は、ＲＬＣ ＰＤＵ ４が欠落しているため生成することができない。本発明によると、測定によってソースｅＮＢにおいてハンドオーバー手順がトリガーされるものとＵＥが判定した時点で、セグメント化を停止し、ＲＬＣ ＰＤＵ ４をソースｅＮＢに再送する。

図１２は、さらに別の例を示しており、ＵＥにおけるＲＬＣ副層の送信バッファには、前に送信されておらず、したがってソースｅＮＢにおいて受信されてもいないＰＤＵも保持されている。言い換えれば、ＲＬＣ副層が再起動される、まもなく発行されるコマンドに起因して、ＵＥがセグメント化を停止した時点において、ＰＤＣＰ ＰＤＵ ３もすでにセグメント化されている。ＲＬＣ ＰＤＵ５およびＲＬＣ ＰＤＵ６がＰＤＣＰ ＰＤＵ ３を構成しており、残りのＲＬＣ ＰＤＵ １〜ＲＬＣ ＰＤＵ ４（このうちＲＬＣ ＰＤＵ ４のみがＡＣＫが返されていない）と一緒に送信バッファの中に存在している。したがって、ＰＤＣＰ ＰＤＵ １は、正常に受信されたＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ２からすでに組み立てられて、現時点では、例えばアクセスゲートウェイにさらに送信できるようにＰＤＣＰ層の送信バッファの中に存在している。

有利な送信の優先化によって、ＲＬＣ ＰＤＵ５およびＲＬＣ ＰＤＵ６を初めて送信するより前に、最初にＲＬＣ ＰＤＵ ４を再送する。したがって、この優先化は、少なくとも次の２つの部分に分割することができる。
１．ＵＥは、割り当てられている上りリソースを、ソースｅＮＢにおいてＲＬＣ ＳＤＵに再組み立てされていない、ＡＣＫが返されていない１つ以上のＲＬＣ ＰＤＵ（ＰＤＵ ４）の間で分配する。
２．ＵＥは、割り当てられている上りリソースを、以前に送信されていない１つ以上のＲＬＣ ＰＤＵの間で分配する。

さらには、ＰＤＵをソースｅＮＢに提供するための複数の無線ベアラが存在していることがある。すなわち、ＰＤＵには、それぞれをソースｅＮＢに送信するための無線ベアラが割り当てられる。複数の異なる無線ベアラは、ＲＬＣ ＰＤＵを送信するための上りリソースを割り当てるときに考慮および配慮される優先度を持つ。本実施形態の場合、このことは、ＵＥが、ＡＣＫが返されていないＲＬＣ ＰＤＵの間で、複数の異なる無線ベアラに、無線ベアラの優先度に従って（例えば、優先度の高い順に）最初に上りリソースを分配することを意味する。

一般的には、［技術分野］において説明したように、ＭＢＲおよびＡＭＢＲに関する制限が無線ベアラにも適用されるものと想定する。

結果として、ＰＤＣＰ ＰＤＵ １、ＰＤＣＰ ＰＤＵ ２、およびＰＤＣＰ ＰＤＵ ３は、実際のハンドオーバーが行われる前にソースｅＮｏｄｅＢに送信される。ハンドオーバーの後、ＵＥからターゲットｅＮＢに送信しなければならないのは、ＰＤＣＰ ＰＤＵ ４のみである。

一般には、ＡＣＫが返されていないＲＬＣ ＰＤＵは、実際のハンドオーバーコマンドがＵＥによって受信される前にソースｅＮＢに再送されているため、［ｅＲＲＣ］ハンドオーバーコマンドのデフォルトのアクティブ化タイミングは、「ただちに」である。すなわち、ハンドオーバー手順に追加の遅延が導入されない。しかしながら、前に想定したように、本発明の実施形態によると、ハンドオーバーコマンドを受信した後、アタッチ先がソースセルからターゲットセルに実際に変更されるまでは、ＡＣＫが返されていないＲＬＣ ＰＤＵの再送を続行することも可能である。

以下では、本発明の別の実施形態によるトラフィックリダイレクト手順について、図１３に関連して詳しく説明する。ＲＬＣ層が再確立される、まもなく発行されるコマンドをＵＥが検出する目的で、トラフィックリダイレクト事前メッセージをソースｅＮＢからＵＥに送信する。さらに詳細には、ソースｅＮＢは、トラフィックのロードバランシングに起因して、最終的にＵＥのためのトラフィックリダイレクト手順を決定するものと想定する。このような場合、ソースｅＮＢは、決定を行った直後に、その決定についてＵＥに通知するが、この通知はリダイレクトの実際のコマンドではなく、なぜなら、最初に、ターゲットｅＮＢによる受付制御を実行する必要があるためである。

残りの手順は、ハンドオーバープロセスに関して前述したプロセスに極めて似ている。さらに具体的には、ＵＥは、トラフィックリダイレクト事前メッセージを受信すると、ただちに、ＰＤＣＰ ＰＤＵからＲＬＣ ＰＤＵへのセグメント化を一時停止するようにＲＬＣ層に命令する。トラフィックリダイレクト事前メッセージを受信した時点において、ＵＥにおけるＲＬＣ層の送信バッファは、図９の実例に一致しているものと想定する。前述したように、ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ ３がソースｅＮＢにおいて正常に受信されており、しかしながら、これらを結合して各ＲＬＣ ＳＤＵを形成することはできず、なぜなら、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４が正常に送信されていないためである。ＲＬＣ層は、この時点で、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４を再送することができ、したがって、ソースｅＮＢは、ＲＬＣ ＳＤＵ １およびＲＬＣ ＳＤＵ ２を再組み立てし、さらに使用できるようにそれらをＰＤＣＰ層に渡すことができる。

この場合も、ＲＬＣ ＰＤＵ ２およびＲＬＣ ＰＤＵ ４の送信に使用される各無線ベアラの優先度に応じて（すなわち、割り当てられている優先度の高い順に）、利用可能な上りシステムリソースを、ＲＬＣ ＰＤＵ ２とＲＬＣ ＰＤＵ ４との間で分配することができる。

図１３に示してある時間Ｔｒｔｒの間、ＵＥは、ソースｅＮＢにおいてＲＬＣ ＳＤＵにまだ再組み立てされておらず、ＡＣＫが返されていないＲＬＣ ＰＤＵを、ソースｅＮＢに再送することができる。あるいは、図１３には示してないが、時間Ｔｒｔｒは、例えば、トラフィックリダイレクトコマンドの受信までのみの期間となるとなるように、事業者によって設定することができる。

ハンドオーバーの場合およびトラフィックリダイレクトの場合に、対応する決定は行われたがハンドオーバー／トラフィックリダイレクトが実際には行われない可能性がある。例えば、最終的な決定は、ターゲットｅＮＢにおいて実行される受付制御にも依存する。したがって、ターゲットｅＮＢにおいて受付制御が肯定的に決定されない場合、このターゲットｅＮＢへのハンドオーバー／トラフィックリダイレクトを行うことができない。この問題を軽減する目的で、ＲＬＣ層がリセットされる、まもなく発行されるコマンドが検出された時点で（内部的または外部的のいずれかにおいて）トリガーされるタイマーが端末において実施される。前述した所定の時間（例えば事業者によって自由に設定することができる）の間、ＵＥは、ＲＬＣ層のリセットを含んでいる手順を実行するための実際のコマンドを待機する。所定の時間枠内においてコマンドが受信されず、したがってタイマーが切れた場合、通常の動作モードが再開される、すなわち、セグメント化が再び開始され、前のようにＲＬＣ ＰＤＵがソースｅＮＢに送信される。

さらに、ここまでの説明においては、まもなく行われるハードハンドオーバー手順またはトラフィックリダイレクト手順がＵＥにおいて検出された時点で、ＡＣＫが返されていないＲＬＣ ＰＤＵの上り再送を実行するための十分なリソースを端末が有するものと想定してきた。しかしながら、現実のシナリオにおいては、この想定があてはまらない場合がある。ＡＣＫが返されていないＲＬＣ ＰＤＵのすべてをソースｅＮＢに送信することができない、あるいは、少なくともＵＥがソース無線セルからデタッチするまでには送信できないという問題が生じうる。以下では、このようなシナリオの場合に可能なソリューションを提示する。

一般的に言えば、ＵＥは、ネットワークからの追加のリソースを要求する必要がある。すなわち、ＵＥは、自身に許可されている利用可能なシステムリソースが、少なくとも、ＡＣＫが返されていないＲＬＣ ＰＤＵすべての再送を実行するうえで十分ではないものと判定した時点で、ただちに、新しいリソースがＵＥに許可されるように求める要求メッセージをｅＮＢに送信する必要がある。ソース無線セルが過負荷になっていなければ、すべてのＲＬＣ ＰＤＵを期限までにソースｅＮＢに送信するために使用できる追加のリソースが、ＵＥに許可される。

さらに詳細には、本発明のさまざまな実施形態によると、端末は、使用する上り再送に追加のリソースを割り当てるためには、［ｅＭＡＣ］ ＲＥＳＯＵＲＣＥ ＲＥＱＵＥＳＴ（リソース要求）メッセージを使用しなければならない。ソースｅＮｏｄｅＢは、このメッセージを受信した後、ＵＥまでの第１層／第２層の制御チャネルにおいて対応するリソース情報をスケジューリングすることによって、上り送信のための追加のリソースを端末に供給することができる。

本発明のさらに具体的な実施形態によると、ソースｅＮＢに要求するシステムリソースの量を求めるためには、いくつかの方法を使用することができる。基本的なリソース要求メッセージには、端末におけるＲＬＣ層の送信バッファの中で送信待ち状態にある、セグメント化されていないＲＬＣ ＳＤＵの量のみが含まれる。以下の説明では、リソース要求メッセージの内容の拡張を提案する。

本発明の実施形態によると、ソースｅＮｏｄｅＢにおいてＲＬＣ ＳＤＵに再組み立てされていない、ＡＣＫが返されていないＲＬＣ ＰＤＵの量［バイト］を含んでいるメッセージとして、リソース要求タイプ１（ＲＲタイプ１）メッセージを定義することができる。したがって、ソースｅＮｏｄｅＢは、ソースｅＮｏｄｅＢにおいてＲＬＣ ＳＤＵに再組み立てされていない、すべての無線ベアラの、ＡＣＫが返されていないＲＬＣ ＰＤＵ、を送信するために必要なリソースの量を許可することができる。図１４は、優先度の異なる２つの無線ベアラの場合の、ＲＲタイプ１メッセージの内容を説明するための例示的なシナリオを示している。

４５バイト（無線ベアラ＃１：ＲＬＣ ＰＤＵ ２）＋２５バイト（無線ベアラ＃１：ＲＬＣ ＰＤＵ ３）＋１５バイト（無線ベアラ＃２：ＲＬＣ ＰＤＵ １）＋４５バイト（無線ベアラ＃２：ＲＬＣ ＰＤＵ ４）＝１３０バイト

上の計算の結果として、リソース要求タイプ１メッセージの内容は１３０バイトとなり、この値が、ソースｅＮＢがＵＥに許可する必要がある量である。

本発明の別の実施形態によると、各無線ベアラの優先度に応じたときの、各無線ベアラの、ＡＣＫが返されていないＲＬＣ ＰＤＵの量［バイト］を含んでいるメッセージとして、リソース要求タイプ２（ＲＲタイプ２）メッセージを定義することができる。十分なリソースが存在しない場合、ソースｅＮｏｄｅＢは、優先度が最高の無線ベアラに属しているパケットに対してのみ、いくらかのシステムリソースを許可することができる。さらに詳細には、図１４の例示的なシナリオをもう一度使用して、優先度の異なる２つの無線ベアラの場合のＲＲタイプ２メッセージの内容を説明する。

［４５バイト（無線ベアラ＃１：ＲＬＣ ＰＤＵ ２）＋２５バイト（無線ベアラ＃１：ＲＬＣ ＰＤＵ ３）］＋［１５バイト（無線ベアラ＃２：ＲＬＣ ＰＤＵ １）＋４５バイト（無線ベアラ＃２：ＲＬＣ ＰＤＵ ４）］＝７０バイト（無線ベアラ＃１）＋６０バイト（無線ベアラ＃２）

したがって、無線ベアラ＃１が無線ベアラ＃２よりも優先度が高いならば、ソースｅＮＢは、無線ベアラ＃１の７０バイトを送信するためのシステムリソースを許可し、その後、無線ベアラ＃２の６０バイトを送信するために残りのリソースを許可する。

さらに、ソースｅＮｏｄｅＢにおいてＲＬＣ ＳＤＵに再組み立てされていない、ＡＣＫが返されていないＲＬＣ ＰＤＵを送信するためにＵＥに許可されるリソースが十分に存在しない場合、ソースｅＮｏｄｅＢは、ターゲットｅＮｏｄｅＢ下で相当なバイト量のＲＬＣ ＳＤＵを送信しなければならない場合にのみ、リソースを許可することができる。したがって、本発明の別の実施形態によると、ソースｅＮｏｄｅＢにおいてＲＬＣ ＳＤＵに再組み立てされていない、ＡＣＫが返されていないＲＬＣ ＰＤＵの量［バイト］と、これらのＲＬＣ ＰＤＵ（ＳＤＵ）が失われている場合にターゲットｅＮｏｄｅＢ下で送信するべきＲＬＣ ＳＤＵの量［バイト］とを含んでいるメッセージとして、リソース要求タイプ３（ＲＲタイプ３）メッセージを定義することができる。

図１５は、バッファに格納されているパケットの量が異なる２つの端末の場合における、ＲＲタイプ３メッセージの内容と、サービングｅＮｏｄｅＢの決定プロセスの可能な実施形態とを説明するための、例示的なシナリオを示している。第１の端末の場合、ＲＲタイプ３メッセージの内容は、４５バイト（ＲＬＣ ＰＤＵ ２）＋２５バイト（ＲＬＣ ＰＤＵ ３）＝７０バイトとして導くことができ、一方で、ＲＬＣ ＳＤＵ １＋ＲＬＣ ＳＤＵ ２＝１４５バイトである。第２の端末の場合のＲＲタイプ３メッセージの内容は、１５バイト（ＲＬＣ ＰＤＵ １）＋１５バイト（ＲＬＣ ＰＤＵ ４）＝３０バイトとして導くことができ、一方で、ＲＬＣ ＳＤＵ ３＋ＲＬＣ ＳＤＵ ４＝６０バイトである。第１の端末を観察すると、失われるＲＬＣ ＳＤＵの量は相当であり、したがって、ソースｅＮｏｄｅＢは、ＵＥ １の、７０バイトのＡＣＫが返されていないＲＬＣ ＰＤＵを送信するためのリソースを許可する。それに対して、第２の端末を観察すると、失われるＲＬＣ ＳＤＵの量はさほどではなく、したがって、ｅＮｏｄｅＢは、３０バイトのＡＣＫが返されていないＲＬＣ ＰＤＵを送信するためのリソースを許可しない。

さらには、ハンドオーバーまたはトラフィックリダイレクトの手順をトリガーする前に十分なリソースが設定されていない場合、各タイプのリソース要求メッセージを使用するものと想定する。特定のリソース要求メッセージタイプは、自由に決定することができる。何らの制約も存在しておらず、したがって、この決定は、例えば、事業者の選択によってのみ決まる。また、この決定は、端末の種類、すなわち、端末が、例えばリソース要求タイプ１を使用することのできる単純なＵＥであるか、に依存させることができる。したがって、より複雑なＵＥの場合、ＲＲタイプ２またはＲＲタイプ３を使用することができる。しかしながら、すでに述べたように、上の例は本発明の範囲を制限するようには解釈されないものとし、単に説明を目的として提示してある。

ＵＥには、どのタイプのＲＲメッセージかの決定について、例えば、［ｅＲＲＣ］ ＲＢ ＳＥＴＵＰ（無線ベアラ確立）または［ｅＲＲＣ］ ＲＢ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ（無線ベアラの再設定）時に通知することができる。あるいは、どのタイプのリソース要求メッセージかの決定を、各手順のメッセージに含めることもできる。例えば、ハンドオーバーの場合、［ｅＲＲＣ］ ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ（ハンドオーバーコマンド）メッセージを使用することができる。同様に、本発明の実施形態によるトラフィックリダイレクト手順が実行される場合、リソース要求メッセージのタイプに関する情報を、［ｅＲＲＣ］ ＰＲＥ−ＴＲＡＦＦＩＣ ＲＥＤＩＲＥＣＴＩＯＮ（トラフィックリダイレクト事前）メッセージに含めることができる。

各システムにおいて、ＵＥは、既存の許可量について、保証ビットレート（ＧＢＲ：Guaranteed Bit Rate）無線ベアラ（ＲＢ：Radio Bearer）それぞれに対しては、観察されるＧＢＲ ＲＢのＭＢＲ（最大ビットレート：Maximum Bit Rate）に等しいデータ送信速度を上限とし、および、非ＧＢＲ ＲＢの各グループそれぞれに対しては、観察される非ＧＢＲ ＲＢのグループのＡＭＢＲに等しいデータ送信速度を上限とし、自身のシステムリソースを分配するべきである。このことは、観察される無線ベアラのすべてのＲＬＣ ＰＤＵを期限内に送信するためには、送信速度を超えなければならないという状況につながる。当然ながら、この状況は、ＡＣＫが返されていないＲＬＣ ＰＤＵを再送するための時間が、ＲＬＣ層のリセットを含んでいる手順を実行するためのコマンド（すなわち、［ｅＲＲＣ］ ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ（ハンドオーバーコマンド）メッセージまたは［ｅＲＲＣ］ ＴＲＡＦＦＩＣ ＲＥＤＩＲＥＣＴＩＯＮ（トラフィックリダイレクト）メッセージ）を受信するまでとして選択されているかにも依存する。あるいは、ＵＥは、自身のＲＬＣ送信バッファを空にするための時間として、自身がソースセルから実際にデタッチするまでとすることができる。

したがって、端末の挙動の以下の修正を提案する。ハンドオーバーをトリガーする［ｅＲＲＣ］ ＭＥＡＳＵＲＥＭＥＮＴ ＲＥＰＯＲＴ（測定レポート）が送信された時点で、または、本発明の実施形態による［ｅＲＲＣ］ ＰＲＥ−ＴＲＡＦＦＩＣ ＲＥＤＩＲＥＣＴＩＯＮ（トラフィックリダイレクト事前）メッセージが受信された時点で、端末は、観察されるＧＢＲ ＲＢのＭＢＲ、および非ＧＢＲ ＲＢのグループのＡＭＢＲを超えることが許される。

図１６は、提案する変更の恩恵を示している。たとえ現在の許可量が、ＡＣＫが返されていないＲＬＣ ＰＤＵをソースｅＮＢに送信するうえで十分であっても、この送信を、ＭＢＲ／ＡＭＢＲを超えることなく時間Ｔｒｔｒ以内に行うことができない。したがって、［ｅＲＲＣ］ ＨＡＮＤＯＶＥＲ ＣＯＭＭＡＮＤ（ハンドオーバーコマンド）を受信した後、ハンドオーバーがＴｄだけ遅延する、または、残っているパケットが失われる。本発明の実施形態によると、端末は、パラメータＭＢＲ’＞ＭＢＲおよびＡＭＢＲ’＞ＡＭＢＲを使用することが許可される。したがって、ＡＣＫが返されていないＲＬＣ ＰＤＵの送信を、パケットが失われることなく、あるいはハンドオーバー手順が遅延することなく、Ｔｒｔｒ以内に行うことができる。

さらに詳細には、ソースｅＮＢにデータパケットを提供するために、３つの無線ベアラがＵＥによって使用されている。３つの無線ベアラのそれぞれにおいて、一部がソースｅＮＢによって正常に受信されておらず、もう一度送信しなければならない。いま、無線ベアラ＃１はＭＢＲによって制限されており、無線ベアラ＃２および無線ベアラ＃３は無線ベアラのグループを形成しており、したがって、全体としてＡＭＢＲによって制限されているものと想定する。図１６の下部に示したように、ＭＢＲおよびＡＭＢＲによって与えられる制限に従うことによって、ＡＣＫが返されていないＲＬＣ ＰＤＵのすべてを、Ｔｒｔｒによって与えられる時間枠内にソースｅＮＢに送信することは不可能である。この制限値を増大させることによってのみ、時間枠内でのＲＬＣ ＰＤＵの再送が保証される。

さらに、無線ベアラの優先度は、通常、ユーザプレーンの確立の開始時に［ｅＲＲＣ］ ＲＡＤＩＯ ＢＥＡＲＥＲ ＳＥＴＵＰ（無線ベアラ確立）メッセージによって設定される。しかしながら、端末が、ＡＣＫが返されていないＲＬＣ ＰＤＵを送信するのに十分ではない許可量が指定された［ｅＭＡＣ］ ＲＥＳＯＵＲＣＥ ＧＲＡＮＴ（リソース許可）メッセージを受信した場合、その端末は、結果としてリソース効率のより高い無線送信につながるならば、以前に設定された無線ベアラの優先度を変更できるものとする。この配慮は、トラフィックリダイレクトプロセスおよびハンドオーバー手順における端末の挙動に適用される。

この状況について、図１７を参照しながらさらに詳しく説明する。より高い優先度の無線ベアラ＃１については、ＡＣＫが返されていないＲＬＣ ＰＤＵ（ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ５）がソースｅＮｏｄｅＢ下で正常に送信されない場合、ターゲットｅＮｏｄｅＢ下ではＲＬＣ ＳＤＵ １およびＲＬＣ ＳＤＵ ３のみを再送すればよい。

これに対して、より低い優先度の無線ベアラ＃２については、ＡＣＫが返されていないＲＬＣ ＰＤＵ（ＲＬＣ ＰＤＵ １、ＲＬＣ ＰＤＵ ４、およびＲＬＣ ＰＤＵ５）がソースｅＮｏｄｅＢ下で正常に送信されない場合、ターゲットｅＮｏｄｅＢ下ではＲＬＣ ＳＤＵ １、ＲＬＣ ＳＤＵ ２、およびＲＬＣ ＳＤＵ ３を再送しなければならないものと推測される。より効率的な無線送信をサポートする目的で、ＵＥは、無線ベアラ＃２のＲＬＣ ＰＤＵをより高い優先度において送信することと、無線ベアラ＃１のＲＬＣ ＰＤＵをより低い優先度において送信することを決定することができる。したがって、２つの無線ベアラの優先度を適切に変更した後、送信の順序は、無線ベアラ＃２（ＲＬＣ ＰＤＵ １、ＲＬＣ ＰＤＵ ４、およびＲＬＣ ＰＤＵ５）、次いで、無線ベアラ＃１（ＲＬＣ ＰＤＵ １およびＲＬＣ ＰＤＵ５）となる。

本発明のさまざまな実施形態によって提供される利点の１つは、プロトコル副層のリセットを含んでいる手順（すなわち、ハンドオーバープロセスまたはトラフィックリダイレクトプロセス）に、追加の遅延が導入されないことである。それと同時に、手順中にパケット消失が発生せず、なぜなら、例えばハンドオーバーイベントに起因して送信バッファが消去される前に、一般的には、送信バッファの中に残っているＰＤＵすべてを送信するための十分な時間が存在するためである。

さらに、すでに上に簡潔に述べたように、本明細書中にさまざまな例示的な実施形態において概説した本発明のコンセプトは、例えば、図１または図２に例示したアーキテクチャを備えていることのできる、［背景技術］のセクションに説明した移動通信システムにおいて有利に使用できることに留意されたい。

本発明の別の実施形態は、上述したさまざまな実施形態を、ハードウェアおよびソフトウェアを使用して実施することに関する。本発明のさまざまな実施形態は、コンピューティングデバイス（プロセッサ）を使用して実施または実行できることが認識される。コンピューティングデバイスまたはプロセッサは、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスとすることができる。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行あるいは具体化することもできる。

さらに、本発明のさまざまな実施形態は、ソフトウェアモジュールによって実施することもでき、これらのソフトウェアモジュールは、プロセッサによって実行される、あるいはハードウェアにおいて直接実行される。さらに、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。

ここまでの段落では、本発明のさまざまな実施形態およびそのバリエーションを説明してきた。本発明には、具体的な実施形態に示したように、広義に記載されている本発明の概念または範囲から逸脱することなく、膨大なバリエーションもしくは変更形態を創案できることが、当業者には理解されるであろう。

さらに、ほとんどの実施形態は、３ＧＰＰをベースとする通信システムに関連して概説してあり、ここまでの説明において使用されている専門用語は、主として３ＧＰＰの専門用語に関連していることに留意されたい。しかしながら、専門用語と、さまざまな実施形態の説明とが、３ＧＰＰをベースとするアーキテクチャに関連していることは、本発明の原理および発想をそのようなシステムに限定することを意図するものではない。

さらに、上の［背景技術］のセクションに示した詳細な説明は、本明細書中に説明した、ほとんどが３ＧＰＰに固有な例示的な実施形態を深く理解することを意図したものであり、移動通信ネットワークにおけるプロセスおよび機能の、説明した特定の実施形態に、本発明を制限するものではないことを理解されたい。しかしながら、本文書に提案されている改良・改善は、［背景技術］のセクションに説明したアーキテクチャにただちに適用することができる。さらに、本発明のコンセプトは、３ＧＰＰによって現在討議されているＬＴＥ ＲＡＮにおいても、ただちに使用することができる。

Claims (43)

1. 移動ノードのプロトコル副層のリセットを含んでいる手順時において、前記移動ノードから前記移動ノードの前記プロトコル副層を介して移動通信システムのアクセスネットワークにデータを送信する方法であって、
   前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するためのまもなく発行されるコマンドを前記移動ノードにおいて検出した時点において、
   前記プロトコル副層のサービスデータユニットから前記プロトコル副層のプロトコルデータユニットのセグメント化を停止するステップと、
   ＡＣＫが返されていないプロトコルデータユニットを、前記移動ノードの前記プロトコル副層によって前記アクセスネットワークに再送するステップと、
   を含んでいる、方法。
2. ＡＣＫが返されていないプロトコルデータユニットを前記アクセスネットワークに再送する前記ステップが、前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記コマンドを受信した後、前記移動ノードが前記アクセスネットワークへの自身のアタッチを変更するまで継続される、請求項１に記載の方法。
3. 前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを検出する前に実行されるステップとして、
   前記プロトコル副層における第２のプロトコル副層から前記サービスデータユニットを受け取った時点で、前記サービスデータユニットを、前記プロトコル副層のプロトコルデータユニットにセグメント化するステップと、
   前記プロトコル副層の前記セグメント化されているプロトコルデータユニットを、前記プロトコル副層の送信バッファに入力するステップと、
   をさらに含んでおり、
   再送する前記ステップが、前記アクセスネットワークに送信されたが前記アクセスネットワークによってＡＣＫが返されていない、前記プロトコル副層の前記送信バッファの中のセグメント化されているプロトコルデータユニット、を再送するステップ、を含んでいる、
   請求項１または請求項２のいずれかに記載の方法。
4. 前記移動ノードの前記プロトコル副層の前記送信バッファが、前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを検出した時点において前記アクセスネットワークに送信されていない、セグメント化されているプロトコルデータユニット、をさらに含んでおり、前記方法が、
   前記送信バッファの中のＡＣＫが返されていない前記プロトコルデータユニットすべてを前記アクセスネットワークに再送した後、前記アクセスネットワークに送信されていない、前記セグメント化されているプロトコルデータユニットを、前記プロトコル副層によって前記アクセスネットワークに送信するステップ、
   をさらに含んでいる、請求項３に記載の方法。
5. 前記プロトコル副層が無線リンク制御副層であり、
   前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを検出した時点において、前記アクセスネットワークに送信されたが前記アクセスネットワークによってＡＣＫが返されていない、前記無線リンク制御副層のプロトコルデータユニット、の前記送信を、前記アクセスネットワークに送信されていない、前記無線リンク制御副層のプロトコルデータユニット、の前記送信よりも、優先させるステップ、
   をさらに含んでいる、請求項１または請求項２に記載の方法。
6. 前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを検出した時点で、前記移動ノードが、所定の時間だけ待機してから、前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記コマンドを受信し、前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記コマンドを前記移動ノードが受信する前に、前記所定の時間が経過した場合、前記移動ノードが、前記プロトコル副層のサービスデータユニットから、前記プロトコル副層のプロトコルデータユニットへの前記セグメント化を再び開始する、
   請求項１から請求項５のいずれかに記載の方法。
7. 前記移動ノードの前記プロトコル副層が、前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニット、を前記アクセスネットワークに再送するための限られたシステムリソースを有し、前記方法が、
   前記移動ノードの前記システムリソースが、ＡＣＫが返されていない前記プロトコルデータユニットを再送するうえで十分ではない場合、前記アクセスネットワークからの追加のシステムリソースを前記移動ノードによって要求するステップと、
   前記追加のシステムリソースに関する情報を、前記アクセスネットワークから、前記移動ノードにおいて受信するステップと、
   前記追加のシステムリソースを利用して、ＡＣＫが返されていない前記プロトコルデータユニットを前記アクセスネットワークに再送するステップと、
   をさらに含んでいる、請求項１から請求項６のいずれかに記載の方法。
8. 追加のシステムリソースを前記移動ノードによって要求する前記ステップが、
   前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニット、のデータ量を、前記移動ノードによって求めるステップと、
   ＡＣＫが返されていない前記プロトコルデータユニットの前記求められたデータ量に関する情報を含んでいる、追加のシステムリソースを要求する要求メッセージ、を前記アクセスネットワークに送信するステップと、
   を含んでいる、
   請求項７に記載の方法。
9. 追加のシステムリソースを前記移動ノードによって要求する前記ステップが、
   データを前記アクセスネットワークに送信するために使用される各無線ベアラについて、前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニット、のデータ量を、前記移動ノードによって求めるステップと、
   各無線ベアラについての、ＡＣＫが返されていない前記プロトコルデータユニットの前記求められたデータ量に関する情報を含んでいる、追加のシステムリソースを要求する要求メッセージ、を前記アクセスネットワークに送信するステップと、
   を含んでいる、請求項７に記載の方法。
10. 各無線ベアラが優先度を有し、前記方法が、
    追加のシステムリソースの前記要求を前記移動ノードから受信した時点で、各無線ベアラのために使用されるシステムリソースの量を、各無線ベアラの前記優先度に基づいて決定するステップと、
    各無線ベアラのためのシステムリソースの前記量について前記移動ノードに通知するステップと、
    をさらに含んでいる、請求項９に記載の方法。
11. 追加のシステムリソースを前記移動ノードによって要求する前記ステップが、
    前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニットのデータ量と、ＡＣＫが返されていない前記プロトコルデータユニットが属している前記サービスデータユニットのデータ量とを、前記移動ノードによって求めるステップと、
    ＡＣＫが返されていない前記プロトコルデータユニットの前記求められたデータ量と、ＡＣＫが返されていない前記プロトコルデータユニットが属している前記サービスデータユニットの前記求められたデータ量とに関する情報を含んでいる、追加のシステムリソースを要求する要求メッセージ、を前記アクセスネットワークに送信するステップと、
    を含んでいる、請求項７に記載の方法。
12. 前記移動ノードからの前記要求メッセージを前記アクセスネットワークの基地局において受信した時点で、ＡＣＫが返されていない前記プロトコルデータユニットのそれぞれを再送するために使用されるシステムリソースの量を、前記要求メッセージ内の前記受信された情報に基づいて決定するステップと、
    各プロトコルデータユニットのためのシステムリソースの前記量について前記移動ノードに通知するステップと、
    をさらに含んでいる、請求項１１に記載の方法。
13. 請求項８、請求項９、または請求項１１による前記方法ステップを使用するかについて前記移動ノードに通知するステップ、
    をさらに含んでいる、請求項８、請求項９、または請求項１１に記載の方法。
14. 前記移動ノードに通知する前記ステップが、
    前記移動ノードから前記アクセスネットワークにデータを送信するための無線ベアラの確立時に、請求項８、請求項９、または請求項１１による前記方法ステップを使用するかについて決定するステップと、
    前記決定に関する情報を、前記無線ベアラの確立について前記移動ノードに通知するために前記アクセスネットワークから前記移動ノードに送信されるメッセージの中に含めるステップと、
    を含んでいる、
    請求項１３に記載の方法。
15. 前記移動ノードに通知する前記ステップが、
    請求項８、請求項９、または請求項１１による前記方法ステップを使用するかについて決定するステップと、
    前記決定に関する情報を、前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記コマンドに、含めるステップと、
    を含んでいる、
    請求項１３に記載の方法。
16. 前記移動ノードに通知する前記ステップが、
    請求項８、請求項９、または請求項１１による前記方法ステップを使用するかについて決定するステップと、
    前記決定に関する情報を、前記プロトコル副層の前記リセットを含んでいる前記手順を実行するという前記決定について前記移動ノードに通知する事前通知メッセージに含めるステップと、
    を含んでいる、
    請求項１３に記載の方法。
17. ＡＣＫが返されていない前記プロトコルデータユニットを前記アクセスネットワークに再送するために利用される各無線ベアラに、最大量のシステムリソースが割り当てられ、前記方法が、
    各無線ベアラのための前記最大量のシステムリソースが、ＡＣＫが返されていない前記プロトコルデータユニットすべてを、前記プロトコルサブレイヤがリセットされる前に前記アクセスネットワークに再送するうえで十分ではない場合、前記移動ノードが、各無線ベアラのための前記最大量のシステムリソースを超えるステップ、
    をさらに含んでいる、請求項１から請求項１６のいずれかに記載の方法。
18. 前記移動ノードが、前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを検出した後、前記移動ノードが、利用可能なシステムリソースに基づいて、もしくは、ＡＣＫが返されていない前記プロトコルデータユニットを示している情報に基づいて、またはこれら両方に基づいて、各無線ベアラに優先度を割り当てるステップ、
    を含んでいる、請求項１から請求項１７のいずれかに記載の方法。
19. 前記プロトコル副層が前記移動ノードの無線リンク制御副層であり、前記無線リンク制御副層の前記サービスデータユニットが、前記移動ノードのパケットデータコンバージェンスプロトコル副層から渡される、請求項１から請求項１８のいずれかに記載の方法。
20. 前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順が、前記移動通信システムにおける第１の基地局から第２の基地局への前記移動ノードのハンドオーバー手順である、請求項１から請求項１９のいずれかに記載の方法。
21. ハンドオーバーに関連して、前記移動ノードと前記アクセスネットワークとの間の前記無線チャネルに関する測定を、前記移動ノードによって実行するステップ、
    を含んでおり、
    前記測定によって、前記第１の基地局において、前記第２の基地局への前記移動ノードのハンドオーバーがトリガーされるものと、前記移動ノードが判定する場合、前記移動ノードが、前記ハンドオーバー手順を実行するための前記まもなく発行されるコマンドを検出する、
    請求項２０に記載の方法。
22. 前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順が、前記移動通信システムにおける第１の基地局から第２の基地局への、前記移動ノードのためのトラフィックリダイレクト手順である、請求項１から請求項１９のいずれかに記載の方法。
23. 前記トラフィックリダイレクト手順を実行するかを、前記第１の基地局によって制御されているネットワークエリア内のトラフィック負荷に基づいて、前記第１の基地局において決定するステップ、
    を含んでおり、
    前記移動ノードが、前記移動ノードのための前記トラフィックリダイレクト手順を実行するという、前記第１の基地局における決定、について前記移動ノードに通知する事前通知を、前記第１の基地局から受信することによって、前記トラフィックリダイレクト手順を実行するための前記まもなく発行されるコマンドを検出する、
    請求項２２に記載の方法。
24. 前記移動ノードから前記プロトコルデータユニットを前記アクセスネットワークに送信するために少なくとも１つの無線ベアラが使用されており、各無線ベアラに優先度が割り当てられており、ＡＣＫが返されていない前記プロトコルデータユニットを再送する前記ステップが、各無線ベアラの前記優先度に基づいて実行される、
    請求項１から請求項２３のいずれかに記載の方法。
25. 前記プロトコル層が、前記移動通信システムの基地局またはアクセスゲートウェイにおいて終端している場合に、前記再送するステップは、ＡＣＫが返されていない前記プロトコルデータユニットを、前記基地局または前記アクセスゲートウェイに再送するステップを含んでいる、
    請求項１から請求項２４のいずれかに記載の方法。
26. 移動ノードのプロトコル副層のリセットを含んでいる手順時において、前記プロトコル副層のプロトコルデータユニットを移動通信システムのアクセスネットワークに送信する移動ノードであって、
    前記移動ノードの前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを検出するようにされているプロセッサであって、
    前記手順を実行するための前記まもなく発行されるコマンドを検出した時点で、前記プロトコル副層のサービスデータユニットから前記プロトコル副層のプロトコルデータユニットへのセグメント化を停止するようにさらになされている、前記プロセッサと、
    前記手順を実行するための前記まもなく発行されるコマンドが検出された時点で、前記プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットを、前記アクセスネットワークに再送するようになされている送信機と、
    を備えている、移動ノード。
27. 前記プロセッサが、前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニットの前記再送を、前記手順を実行するための前記コマンドを受信した後、前記移動ノードが前記アクセスネットワークへの自身のアタッチを変更するまで続行するように、さらになされている、請求項２６に記載の移動ノード。
28. 前記プロトコル副層の送信バッファが、前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドが検出された時点において、ＡＣＫが返されていないプロトコルデータユニットと、前記アクセスネットワークに送信されていない、セグメント化されているプロトコルデータユニットと、を含んでおり、
    前記送信機が、ＡＣＫが返されていない前記プロトコルデータユニットすべてを再送した後、前記アクセスネットワークに送信されていない、前記セグメント化されているプロトコルデータユニットを送信するようになされている、
    請求項２６または請求項２７に記載の移動ノード。
29. 前記プロセッサが、前記手順を実行するための前記まもなく発行されるコマンドを検出した時点において、前記アクセスネットワークに送信されたが前記アクセスネットワークによってＡＣＫが返されていない、前記プロトコル副層のプロトコルデータユニット、の前記送信を、前記アクセスネットワークに送信されていないプロトコルデータユニット、の前記送信よりも優先させるように、さらになされている、請求項２６から請求項２８のいずれかに記載の移動ノード。
30. 前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記まもなく発行されるコマンドを前記プロセッサが検出した時点で、前記プロセッサが、所定の時間だけ待機してから、前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記コマンドを受信し、
    前記移動ノードにおける受信機が、前記手順を実行するための前記コマンドを受信する前に、前記所定の時間が経過した場合、前記プロセッサが、前記プロトコル副層のサービスデータユニットの前記セグメント化を再び開始するようになされている、
    請求項２６から請求項２９のいずれかに記載の移動ノード。
31. 前記プロセッサが、前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニット、を前記アクセスネットワークに再送するうえで、前記プロトコル副層のシステムリソースが十分であるか否かを判定するようにされており、
    前記システムリソースが十分ではないものと前記プロセッサが判定した場合、前記送信機が、追加のシステムリソースを要求する要求メッセージを前記アクセスネットワークに送信するようにされており、
    受信機が、許可された追加のシステムリソースに関する情報を前記アクセスネットワークから受信するようにされており、
    前記プロセッサが、前記許可された追加のシステムリソースを利用して、ＡＣＫが返されていない前記プロトコルデータユニットを前記アクセスネットワークに再送するようになされている、
    請求項２６から請求項３０のいずれかに記載の移動ノード。
32. 前記プロセッサが、前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニット、のデータ量を求めるようにされており、
    前記送信機が、前記求められたデータ量に関する情報を含める、
    請求項３１に記載の移動ノード。
33. ＡＣＫが返されていない前記プロトコルデータユニットを前記アクセスネットワークに再送するために利用される各無線ベアラに、最大量のシステムリソースが割り当てられ、各無線ベアラのための前記最大量のシステムリソースが、ＡＣＫが返されていない前記プロトコルデータユニットすべてを、前記プロトコルサブレイヤがリセットされる前に前記アクセスネットワークに再送するうえで十分ではない場合、
    前記送信機が、各無線ベアラのための前記最大量のシステムリソースを超えるようになされている、
    請求項２６から請求項３２のいずれかに記載の移動ノード。
34. 前記プロトコル副層の前記リセットを含んでいる前記手順が、前記移動通信システムにおける第１の基地局から第２の基地局への前記移動ノードのハンドオーバー手順であり、前記移動ノードと前記アクセスネットワークとの間の前記無線チャネルに関する測定によって、前記第１の基地局において、前記第２の基地局への前記移動ノードのハンドオーバーがトリガーされるものと前記プロセッサが判定するとき、前記プロセッサが、前記ハンドオーバー手順を実行するための前記まもなく発行されるコマンドを検出するようになされている、請求項２６から請求項３３のいずれかに記載の移動ノード。
35. 前記プロトコル副層の前記リセットを含んでいる前記手順が、前記移動通信システムにおける第１の基地局から第２の基地局への、前記移動ノードのためのトラフィックリダイレクト手順であり、前記移動ノードのための前記トラフィックリダイレクト手順を実行するという、前記第１の基地局における決定、についての事前通知を、受信機が前記第１の基地局から受信したとき、前記プロセッサが、前記トラフィックリダイレクト手順を実行するための前記まもなく発行されるコマンドを検出するようになされている、請求項２６から請求項３３のいずれかに記載の移動ノード。
36. 請求項９から請求項１６、請求項１８、請求項１９、請求項２４、または請求項２５による前記方法の前記ステップを実行する、または参加するための手段、をさらに備えている、請求項２６から請求項３５のいずれかに記載の移動ノード。
37. プロトコル副層のリセットを含んでいる手順時において、移動通信システムにおける移動ノードの前記プロトコル副層とデータを交換する基地局であって、
    前記プロトコル副層の前記リセットを含んでいる前記手順を実行することを決定するようになされているプロセッサと、
    前記プロセッサが前記決定を実行した時点で、前記手順を実行するという前記決定について前記移動ノードに通知する事前通知を、前記移動ノードに送信するようになされている送信機と、
    を備えている、基地局。
38. 前記プロトコル副層の前記リセットを含んでいる前記手順が、前記基地局から別の基地局への、前記移動ノードのためのトラフィックリダイレクト手順またはハンドオーバー手順である、請求項３７に記載の基地局。
39. ある量のデータを送信するために必要である追加のシステムリソースを要求するリソース要求メッセージを、前記移動ノードから受信するようになされている受信機であって、前記リソース要求メッセージが、前記データ量に関する情報を含んでいる、前記受信機、
    をさらに備えており、
    前記プロセッサが、前記データ量を送信するために使用されるシステムリソースの量を、前記リソース要求メッセージの中の受信された情報に基づいて決定するように、さらにされており、
    前記送信機が、前記決定されたシステムリソース量に関する情報を前記移動ノードに送信するように、さらになされている、
    請求項３７または請求項３８に記載の基地局。
40. 前記移動ノードが、前記リソース要求メッセージの中に含める前記データ量を、
    前記移動ノードの前記プロトコル副層の、ＡＣＫが返されていないプロトコルデータユニットのデータ量を求めることによって、または、
    前記プロトコルデータユニットを前記基地局に送信するために使用される各無線ベアラについて、前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニットのデータ量を求めることによって、または、
    前記プロトコル副層の、ＡＣＫが返されていない前記プロトコルデータユニットの前記データ量と、ＡＣＫが返されていない前記プロトコルデータユニットが属しているサービスデータユニットのデータ量とを求めることによって、
    求め、
    前記プロセッサが、前記リソース要求メッセージの中に含まれる前記データ量を前記移動ノードによって求める方法を決定するように、さらにされており、
    前記送信機が、前記移動ノードによって前記データ量を求める方法に関する前記決定について前記移動ノードに通知する設定メッセージを、前記移動ノードに送信するように、さらになされている、
    請求項３９に記載の基地局。
41. 前記設定メッセージが、
    前記プロトコル副層の前記リセットを含んでいる前記手順を実行するための前記コマンドのメッセージである、または、
    無線ベアラの確立について前記移動ノードに通知するために前記基地局から前記移動ノードに送信されるメッセージである、または、
    前記プロトコル副層の前記リセットを含んでいる前記手順を実行するという前記決定について前記移動ノードに通知する事前通知のメッセージである、
    請求項４０に記載の基地局。
42. 請求項１から請求項２５による前記方法の前記ステップを実行する、または参加するための手段、をさらに備えている、請求項３７から請求項４１のいずれかに記載の基地局。
43. 請求項２６から請求項３６のいずれかによる移動ノードを備えており、請求項３７から請求項４２のいずれかによる基地局を備えている、通信システム。
    

Images