特許 6336069 移動中の二重接続におけるＵＥの効率的状況報告

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6336069

(24)【登録日】2018年5月11日

(45)【発行日】2018年6月6日

(54)【発明の名称】移動中の二重接続におけるＵＥの効率的状況報告

(51)【国際特許分類】

   H04W 36/04 20090101AFI20180528BHJP

   H04W 72/04 20090101ALI20180528BHJP

   H04W 16/32 20090101ALI20180528BHJP

   H04L 1/16 20060101ALI20180528BHJP

   H04W 36/30 20090101ALI20180528BHJP

【ＦＩ】

   H04W36/04

   H04W72/04 111

   H04W16/32

   H04L1/16

   H04W36/30

【請求項の数】20

【全頁数】48

(21)【出願番号】特願2016-532300(P2016-532300)

(86)(22)【出願日】2014年7月24日

(65)【公表番号】特表2016-531506(P2016-531506A)

(43)【公表日】2016年10月6日

(86)【国際出願番号】EP2014065949

(87)【国際公開番号】WO2015018653

(87)【国際公開日】20150212

【審査請求日】2017年3月27日

(31)【優先権主張番号】13179909.0

(32)【優先日】2013年8月9日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100105050

【弁理士】

【氏名又は名称】鷲田 公一

(72)【発明者】

【氏名】バス マリック プラティーク

(72)【発明者】

【氏名】ロアー ヨアヒム

【審査官】 桑原 聡一

(56)【参考文献】

【文献】 特表２０１１−５２５３４３（ＪＰ，Ａ）

【文献】 Pantech，Consideration on UP Alternatives 2C and 3C[online]， 3GPP TSG-RAN WG2#82 R2-131797，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_82/Docs/R2-131797.zip＞，２０１３年 ５月２０日

【文献】 CATT，Discussion on U-plane delay[online]， 3GPP TSG-RAN WG2#82 R2-131873，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_82/Docs/R2-131873.zip＞，２０１３年 ５月２０日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４−７／２６

Ｈ０４Ｗ ４／００−９９／００

Ｈ０４Ｌ １／１６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

状況報告を送信する移動局であって、前記移動局は、少なくとも１つの無線ベアラを介してマスタ基地局に、および、少なくとも１つのデータ無線ベアラを介してソース二次基地局に接続され、前記移動局は、
前記移動局の前記少なくとも１つのデータ無線ベアラが前記ソース二次基地局から目標基地局に再設定されるときに、状況報告を送信するように適合された、プロセッサおよび送信器、
を備え、
前記状況報告は、前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのすべてを介して前記移動局によって受信されるデータパケットの受信状況の情報を含み、かつ、その情報が前記状況報告に含まれる前記少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む、
移動局。

【請求項2】

前記送信器は、前記移動局を前記マスタ基地局に直接接続する前記少なくとも１つの無線ベアラのうちの１つを介して、好ましくはデータ無線ベアラまたはシグナリング無線ベアラを介して、前記マスタ基地局に前記状況報告を送信するように適合された、
請求項１に記載の移動局。

【請求項3】

前記送信器は、
前記移動局を前記マスタ基地局に直接接続する前記少なくとも１つの無線ベアラのうちの１つのシグナリング無線ベアラを介して無線リソース制御（ＲＲＣ）メッセージの一部として、好ましくはＲＲＣ接続再設定完了メッセージ内で、または、
前記移動局を前記マスタ基地局に直接接続する前記少なくとも１つの無線ベアラのうちの１つのデータ無線ベアラを介するパケットデータ収束プロトコル（ＰＤＣＰ）制御パケットデータユニットとして、または、
メディアアクセス制御（ＭＡＣ）制御要素において、
前記状況報告を前記マスタ基地局に送信するように適合された、
請求項２に記載の移動局。

【請求項4】

前記状況報告はさらに、前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのうちの１つを介して受信されるデータパケットの受信状況の情報の後に少なくとも１つの拡張フラグを含み、前記拡張フラグは、前記少なくとも１つのデータ無線ベアラのうちの別の１つのデータ無線ベアラを介して受信されるデータパケットの受信状況のさらなる情報の存在を示す、
請求項１〜３のいずれか一項に記載の移動局。

【請求項5】

前記状況報告は、前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのすべてを介して前記移動局の受信器によって受信されるＰＤＣＰサービスデータユニットの受信状況の情報を含む、ＰＤＣＰ状況報告である、
請求項１〜４のいずれか一項に記載の移動局。

【請求項6】

前記状況報告は、前記移動局内の受信器によるＲＲＣ接続再設定メッセージの受信に応答して送信され、前記ＲＲＣ接続再設定メッセージは、前記ソース二次基地局から前記目標基地局への前記移動局の前記少なくとも１つのデータ無線ベアラの前記再設定の一部として受信される、
請求項１〜５のいずれか一項に記載の移動局。

【請求項7】

前記状況報告は、
制御またはデータＰＤＵとしてＰＤＣＰ制御ＰＤＵを識別するための１ビット長のＤ／Ｃフィールド、
前記ＰＤＣＰ制御ＰＤＵのタイプを識別するための３ビット長のタイプフィールド、
後続の第１の紛失した情報およびビットマップフィールドが参照する前記無線ベアラを識別するための無線ベアラ識別子フィールド、
前記先行する無線ベアラ識別子フィールドで識別される前記無線ベアラに関する、前記第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長のフィールド、
オプションで、前記先行する無線ベアラ識別子フィールドで識別される前記無線ベアラを介して正確に受信された、または受信されなかった前記第１の紛失したＰＤＣＰ ＳＤＵから始まるＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有するビットマップフィールド、
さらなる情報が前記ＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示するための１ビット長の拡張フラグフィールド、
を備えるＰＤＣＰ制御パケットデータユニット（ＰＤＵ）であり、
前記拡張フラグフィールドが、さらなる情報が含まれると指示する場合に、前記状況報告は、
前記後続の第１の紛失した情報およびビットマップフィールドが参照する前記無線ベアラを識別するための別の無線ベアラ識別子フィールド、
前記先行する別の無線ベアラ識別子フィールドにおいて識別される前記無線ベアラに関する前記第１の紛失したＰＤＣＰサービスデータユニット、ＳＤＵ、のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長の別のフィールド、
オプションで、前記先行する別の無線ベアラ識別子フィールドにおいて識別される前記無線ベアラを介して正確に受信された、または受信されなかった前記第１の紛失したＰＤＣＰ ＳＤＵから始まる前記ＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有する別のビットマップフィールド、
さらなる情報が前記ＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示するための１ビット長の別の拡張フラグフィールド、
を備える、請求項１〜６のいずれか一項に記載の移動局。

【請求項8】

前記マスタ基地局から状況報告を受信するように適合された受信器であって、前記状況報告は、前記マスタ基地局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのすべてを介して前記マスタ基地局によって受信されるデータパケットの受信状況の情報を含み、かつ、その情報が前記状況報告に含まれる前記少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む、受信器、
をさらに備える、請求項１〜７のいずれか一項に記載の移動局。

【請求項9】

移動局から送信される状況報告を処理するマスタ基地局であって、前記移動局は、少なくとも１つの無線ベアラを介して前記マスタ基地局に、および、少なくとも１つのデータ無線ベアラを介してソース二次基地局に接続され、前記基地局は、
前記ソース二次基地局から目標基地局へ前記移動局の前記少なくとも１つのデータ無線ベアラを再設定するときに、前記移動局から状況報告を受信および処理するように適合された受信器およびプロセッサであって、前記状況報告は、前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのすべてを介して前記移動局によって受信されるデータパケットの受信状況の情報を含み、かつ、その情報が前記状況報告に含まれる前記少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む、受信器およびプロセッサ、
を備える、マスタ基地局。

【請求項10】

移動局によって状況報告を送信する方法であって、前記移動局は、少なくとも１つの無線ベアラを介してマスタ基地局に、および、少なくとも１つのデータ無線ベアラを介してソース二次基地局に接続され、前記方法は、
前記ソース二次基地局から目標基地局へ前記移動局の前記少なくとも１つのデータ無線ベアラを再設定するとき、
状況報告を前記移動局によって送信するステップであって、前記状況報告が、
前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのすべてを介して前記移動局によって受信されるデータパケットの受信状況の情報を備え、かつ
その情報が前記状況報告に含まれる前記少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を備える、ステップ、
を含む、方法。

【請求項11】

前記状況報告は、前記移動局を前記マスタ基地局に直接接続する前記少なくとも１つの無線ベアラのうちの１つを介して、好ましくはデータ無線ベアラまたはシグナリング無線ベアラを介して、前記マスタ基地局に前記移動局によって送信される、
請求項１０に記載の方法。

【請求項12】

前記状況報告は、好ましくはＲＲＣ接続再設定完了メッセージ内で、前記移動局を前記マスタ基地局に直接接続する前記少なくとも１つの無線ベアラのうちの１つのシグナリング無線ベアラを介して無線リソース制御（ＲＲＣ）メッセージの一部として前記マスタ基地局に前記移動局によって送信される、
請求項１１に記載の方法。

【請求項13】

前記状況報告は、前記移動局を前記マスタ基地局に直接接続する前記少なくとも１つの無線ベアラのうちの１つのデータ無線ベアラを介してパケットデータ収束プロトコル（ＰＤＣＰ）制御パケットデータユニットとして前記マスタ基地局に前記移動局によって送信される、
請求項１１に記載の方法。

【請求項14】

前記状況報告は、メディアアクセス制御（ＭＡＣ）制御要素において送信される、
請求項１１に記載の方法。

【請求項15】

前記目標基地局は、前記移動局が接続された前記マスタ基地局、または別のマスタ基地局、または目標二次基地局のいずれかである、
請求項１０または１４に記載の方法。

【請求項16】

前記状況報告はさらに、前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのうちの１つを介して受信されるデータパケットの受信状況の情報の後に少なくとも１つの拡張フラグを含み、前記拡張フラグは、前記少なくとも１つのデータ無線ベアラのうちの別の１つのデータ無線ベアラを介して受信されるデータパケットの受信状況のさらなる情報の存在を示す、
請求項１０〜１５のいずれか一項に記載の方法。

【請求項17】

前記状況報告は、前記移動局を前記ソース二次基地局に接続する前記少なくとも１つのデータ無線ベアラのすべてを介して受信されるＰＤＣＰサービスデータユニットの受信状況の情報を含む、ＰＤＣＰ状況報告である、
請求項１０〜１６のいずれか一項に記載の方法。

【請求項18】

前記状況報告は、前記移動局におけるＲＲＣ接続再設定メッセージの受信に応答して送信され、前記ＲＲＣ接続再設定メッセージは、前記ソース二次基地局から前記目標基地局への前記移動局の前記少なくとも１つのデータ無線ベアラの再設定の一部として受信される、
請求項１０〜１７のいずれか一項に記載の方法。

【請求項19】

前記状況報告は、
制御またはデータＰＤＵとしてＰＤＣＰ制御ＰＤＵを識別するための１ビット長のＤ／Ｃフィールド、
前記ＰＤＣＰ制御ＰＤＵのタイプを識別するための３ビット長のタイプフィールド、
後続の第１の紛失した情報およびビットマップフィールドが参照する前記無線ベアラを識別するための無線ベアラ識別子フィールド、
前記先行する無線ベアラ識別子フィールドで識別される前記無線ベアラに関する、第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長のフィールド、
オプションで、前記先行する無線ベアラ識別子フィールドで識別される前記無線ベアラを介して正確に受信された、または受信されなかった前記第１の紛失したＰＤＣＰ ＳＤＵから始まるＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有するビットマップフィールド、
さらなる情報が前記ＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示するための１ビット長の拡張フラグフィールド、
を備えるＰＤＣＰ制御パケットデータユニット（ＰＤＵ）であり、
前記拡張フラグフィールドが、さらなる情報が含まれると指示する場合に、前記状況報告は、
前記後続の第１の紛失した情報およびビットマップフィールドが参照する前記無線ベアラを識別するための別の無線ベアラ識別子フィールド、
前記先行する別の無線ベアラ識別子フィールドにおいて識別される前記無線ベアラに関する前記第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長の別のフィールド、
オプションで、前記先行する別の無線ベアラ識別子フィールドにおいて識別される前記無線ベアラを介して正確に受信された、または受信されなかった前記第１の紛失したＰＤＣＰ ＳＤＵから始まる前記ＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有する別のビットマップフィールド、
さらなる情報が前記ＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示するための１ビット長の別の拡張フラグフィールド、
を備える、請求項１０〜１８のいずれか一項に記載の方法。

【請求項20】

前記データパケットは、前記マスタ基地局から前記二次基地局を介して前記移動局に転送され、また、状況報告機能を有する上位レイヤは、前記二次基地局にではなく前記マスタ基地局にある、
請求項１０〜１９のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動局によって状況報告を送信する方法に関する。また、本発明は、本明細書に記載された方法に参加しそれを実行する移動局および基地局を提供する。

【背景技術】

【0002】

ロングタームエボリューション（ＬＴＥ）

【0003】

ＷＣＤＭＡ（登録商標）無線アクセス技術をベースとする第３世代の移動通信システム（３Ｇ）は、世界中で広範な規模で配備されつつある。この技術を機能強化または発展・進化させるうえでの最初のステップとして、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）と、エンハンストアップリンク（高速アップリンクパケットアクセス（ＨＳＵＰＡ）とも称する）とが導入され、これにより、極めて競争力の高い無線アクセス技術が提供されている。

【0004】

ユーザからのますます増大する需要に対応し、新しい無線アクセス技術に対する競争力を確保する目的で、３ＧＰＰは、ロングタームエボリューション（ＬＴＥ）と称される新しい移動通信システムを導入した。ＬＴＥは、今後１０年間にわたり、データおよびメディアの高速伝送ならびに大容量の音声サポートに要求されるキャリアを提供するように設計されている。高いビットレートを提供する能力は、ＬＴＥにおける重要な方策である。

【0005】

ＬＴＥ（ロングタームエボリューション）に関する作業項目（ＷＩ）の仕様は、Ｅ−ＵＴＲＡ（Evolved UMTS Terrestrial Radio Access（ＵＴＲＡ）：進化したＵＭＴＳ地上無線アクセス）およびＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network（ＵＴＲＡＮ）：進化したＵＭＴＳ地上無線アクセスネットワーク）と称され、最終的にリリース８（ＬＴＥリリース８）として公開される。ＬＴＥシステムは、パケットベースの効率的な無線アクセスおよび無線アクセスネットワークであり、ＩＰベースの全機能を低遅延かつ低コストで提供する。ＬＴＥでは、与えられたスペクトルを用いてフレキシブルなシステム配備を達成するために、スケーラブルな複数の送信帯域幅（例えば、１.４ＭＨｚ、３.０ＭＨｚ、５.０ＭＨｚ、１０.０ＭＨｚ、１５.０ＭＨｚ、および２０.０ＭＨｚ）が指定されている。ダウンリンクには、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing：直交周波数分割多重）をベースとする無線アクセスが採用されている。なぜなら、かかる無線アクセスは、低いシンボルレートのため本質的にマルチパス干渉（ＭＰＩ）を受けにくく、また、サイクリックプレフィックス（ＣＰ）を使用しており、さらに、さまざまな送信帯域幅の構成に対応可能だからである。アップリンクには、ＳＣ−ＦＤＭＡ（Single-Carrier Frequency Division Multiple Access：シングルキャリア周波数分割多元接続）をベースとする無線アクセスが採用されている。なぜなら、ユーザ機器（ＵＥ）の送信出力が限られていることを考えれば、ピークデータレートを向上させるよりも広いカバレッジエリアを提供することが優先されるからである。ＬＴＥリリース８／９では、数多くの主要なパケット無線アクセス技術（例えば、ＭＩＭＯ（多入力多出力）チャネル伝送技術）が採用され、高効率の制御シグナリング構造が達成されている。

【0006】

ＬＴＥアーキテクチャ

【0007】

図１は、ＬＴＥの全体的なアーキテクチャを示し、図２は、Ｅ−ＵＴＲＡＮのアーキテクチャをより詳細に示している。Ｅ−ＵＴＲＡＮは、ｅＮｏｄｅＢから構成され、ｅＮｏｄｅＢは、ＵＥ向けの、Ｅ−ＵＴＲＡのユーザプレーン（ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルを終端処理する。ｅＮｏｄｅＢ（ｅＮＢ）は、物理（ＰＨＹ）レイヤ、メディアアクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、およびパケットデータ制御プロトコル（ＰＤＣＰ）レイヤ（これらのレイヤはユーザプレーンのヘッダ圧縮および暗号化の機能を含む）をホストする。ｅＮＢは、制御プレーンに対応する無線リソース制御（ＲＲＣ）機能も提供する。ｅＮＢは、無線リソース管理、アドミッション制御、スケジューリング、交渉によるアップリンクＱｏＳ（サービス品質）の実施、セル情報のブロードキャスト、ユーザプレーンデータおよび制御プレーンデータの暗号化／復号化、ダウンリンク／アップリンクのユーザプレーンパケットヘッダの圧縮／復元など、多くの機能を実行する。複数のｅＮｏｄｅＢは、Ｘ２インタフェースによって互いに接続されている。

【0008】

また、複数のｅＮｏｄｅＢは、Ｓ１インタフェースによってＥＰＣ（Evolved Packet Core：進化したパケットコア）、より具体的には、Ｓ１−ＭＭＥによってＭＭＥ（Mobility Management Entity：移動管理エンティティ）、Ｓ１−Ｕによってサービングゲートウェイ（ＳＧＷ：Serving Gateway）に接続されている。Ｓ１インタフェースは、ＭＭＥ／サービングゲートウェイとｅＮｏｄｅＢとの間の多対多関係をサポートする。ＳＧＷは、ユーザデータパケットをルーティングして転送する一方で、ｅＮｏｄｅＢ間のハンドオーバ時におけるユーザプレーンのモビリティアンカーとして機能し、さらに、ＬＴＥと別の３ＧＰＰ技術との間のモビリティのためのアンカー（Ｓ４インタフェースを終端させ、２Ｇ／３ＧシステムとＰＤＮ ＧＷとの間でトラフィックを中継する）として機能する。ＳＧＷは、アイドル状態のユーザ機器に対しては、ダウンリンクデータ経路を終端させ、そのユーザ機器へのダウンリンクデータが到着したときにページングをトリガーする。ＳＧＷは、ユーザ機器のコンテキスト（例えばＩＰベアラサービスのパラメータ、ネットワーク内部ルーティング情報）を管理および格納する。さらに、ＳＧＷは、合法傍受（lawful interception）の場合にユーザトラフィックの複製を実行する。

【0009】

ＭＭＥは、ＬＴＥのアクセスネットワークの主要な制御ノードである。ＭＭＥは、アイドルモードのユーザ機器の追跡およびページング手順（再送信を含む）の役割を担う。ＭＭＥは、ベアラのアクティブ化／非アクティブ化プロセスに関与し、さらには、最初のアタッチ時と、コアネットワーク（ＣＮ）ノードの再配置を伴うＬＴＥ内ハンドオーバ時とに、ユーザ機器のＳＧＷを選択する役割も担う。ＭＭＥは、（ＨＳＳと対話することによって）ユーザを認証する役割を担う。非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングはＭＭＥにおいて終端され、ＭＭＥは、一時的なＩＤを生成してユーザ機器に割り当てる役割も担う。ＭＭＥは、サービスプロバイダの公衆陸上移動網（ＰＬＭＮ：Public Land Mobile Network）に入るためのユーザ機器の認証をチェックし、ユーザ機器のローミング制約を実施する。ＭＭＥは、ＮＡＳシグナリングの暗号化／整合性保護においてネットワーク内の終端点であり、セキュリティキーの管理を行う。シグナリングの合法傍受も、ＭＭＥによってサポートされる。さらに、ＭＭＥは、ＬＴＥのアクセスネットワークと２Ｇ／３Ｇのアクセスネットワークとの間のモビリティのための制御プレーン機能を提供し、ＳＧＳＮからのＳ３インタフェースを終端させる。さらに、ＭＭＥは、ローミングするユーザ機器のためのホームＨＳＳに向かうＳ６ａインタフェースを終端させる。

【0010】

ＬＴＥにおけるコンポーネントキャリア構造

【0011】

３ＧＰＰ ＬＴＥシステムのダウンリンクコンポーネントキャリアは、いわゆるサブフレームにおける時間−周波数領域でさらに分割される。３ＧＰＰ ＬＴＥで、各サブフレームは、図３に示すように２つのダウンリンクスロットに分割され、そこにおいて、第１のダウンリンクスロットは、第１のＯＦＤＭシンボル内の制御チャネル領域（ＰＤＣＣＨ領域）を備える。各サブフレームは、時間領域内の所与の数のＯＦＤＭシンボルで構成され（３ＧＰＰ ＬＴＥ（リリース８）では１２個または１４個のＯＦＤＭシンボル）、各ＯＦＤＭシンボルはコンポーネントキャリアの帯域幅全体に広がる。したがって、ＯＦＤＭシンボルは、各々、図４にも示すように、Ｎ^ＤＬ_ＲＢ×Ｎ^ＲＢ_ｓｃ個のそれぞれのサブキャリアで送信されるいくつかの変調シンボルで構成される。

【0012】

例えば３ＧＰＰロングタームエボリューション（ＬＴＥ）において使用されるような、例えばＯＦＤＭを使用する、マルチキャリア通信システムを想定すると、スケジューラによって割り当てることができるリソースの最小単位は、１つの「リソースブロック」である。物理リソースブロック（ＰＲＢ）は、図４に例示されるように時間領域におけるＮ^ＤＬ_ｓｙｍｂ個の連続するＯＦＤＭシンボル（例えば、７つのＯＦＤＭシンボル）および周波数領域におけるＮ^ＲＢ_ｓｃ個の連続するサブキャリア（例えば、コンポーネントキャリアの１２個のサブキャリア）として定義される。したがって、３ＧＰＰ ＬＴＥ（リリース８）では、物理リソースブロックは、時間領域における１つのスロットおよび周波数領域における１８０ｋＨｚに対応する、Ｎ^ＤＬ_ｓｙｍｂ×Ｎ^ＲＢ_ｓｃ個のリソースエレメントで構成される（ダウンリンクリソースグリッドについてさらに詳しくは、例えば、３ＧＰＰのウェブサイトで入手可能であり、参照により本明細書に組み込まれている、非特許文献１の６.２節を参照）。

【0013】

１つのサブフレームは、２つのスロットで構成され、したがって、いわゆる「通常の」ＣＰ（サイクリックプレフィックス）が使用されるときにはサブフレーム内に１４個のＯＦＤＭシンボルが存在し、いわゆる「拡張」ＣＰが使用されるときにはサブフレーム内に１２個のＯＦＤＭシンボルが存在する。専門用語を目的として、以下で、サブフレーム全体に広がる同じＮ^ＲＢ_ｓｃ個の連続するサブキャリアと同等の時間−周波数リソースは、「リソースブロックペア」または同意義の「ＲＢペア」もしくは「ＰＲＢペア」と呼ばれる。

【0014】

「コンポーネントキャリア」という用語は、周波数領域におけるいくつかのリソースブロックの組合せを示す。ＬＴＥの将来のリリースでは、「コンポーネントキャリア」という用語はもはや使用されず、その代わりに、その専門用語はダウンリンクおよびオプションでアップリンクリソースの組合せを示す「セル」に変更される。ダウンリンクリソースのキャリア周波数とアップリンクリソースのキャリア周波数との間のリンク付けは、ダウンリンクリソースで送信されるシステム情報において指示される。

【0015】

コンポーネントキャリア構造についての同様の想定が、後のリリースにも適用される。

【0016】

より広い帯域幅のサポートのためのＬＴＥ−Ａにおけるキャリアアグリゲーション

【0017】

世界無線通信会議２００７（ＷＲＣ−０７）において、ＩＭＴ−Ａｄｖａｎｃｅｄの周波数スペクトルが決定された。ＩＭＴ−Ａｄｖａｎｃｅｄのための全体的な周波数スペクトルは決定されたが、実際に利用可能な周波数帯域幅は、地域や国によって異なる。しかしながら、利用可能な周波数スペクトルのアウトラインの決定に続いて、３ＧＰＰ（第３世代パートナーシッププロジェクト）において無線インタフェースの標準化が開始された。３ＧＰＰ ＴＳＧ ＲＡＮ ＃３９会合において、「Further Advancements for E-UTRA (LTE-Advanced)」に関する検討項目の記述が承認された。この検討項目は、Ｅ−ＵＴＲＡを進化・発展させるうえで（例えば、ＩＭＴ−Ａｄｖａｎｃｅｄの要求条件を満たすために）考慮すべき技術要素をカバーしている。

【0018】

ＬＴＥアドバンストシステムがサポートすることができる帯域幅は１００ＭＨｚであり、一方、ＬＴＥシステムは２０ＭＨｚのみをサポートすることができる。今日、無線スペクトルの欠如がワイヤレスネットワークの開発のボトルネックになり、結果として、ＬＴＥアドバンストシステムのために十分広いスペクトル帯域を見つけることは困難である。したがって、より広い無線スペクトル帯域を獲得するための方法を見つけることは急務であり、ここにおいて、可能性のある答えは、キャリアアグリゲーション機能である。

【0019】

キャリアアグリゲーションでは、最大で１００ＭＨｚの広い送信帯域幅をサポートする目的で、２つ以上のコンポーネントキャリアがアグリゲートされる。ＬＴＥ−Ａｄｖａｎｃｅｄシステムでは、ＬＴＥシステムにおけるいくつかのセルが、より広い１つのチャネルにアグリゲートされ、このチャネルは、たとえＬＴＥにおけるこれらのセルが異なる周波数帯域である場合でも１００ＭＨｚに対して十分に広い。

【0020】

少なくとも、アグリゲートされるコンポーネントキャリアの数がアップリンクとダウンリンクとで同じであるとき、すべてのコンポーネントキャリアをＬＴＥリリース８／９互換として設定することができる。ユーザ機器によってアグリゲートされるすべてのコンポーネントキャリアが必ずしもＬＴＥリリース８／９互換でなくてよい。リリース８／９のユーザ機器がコンポーネントキャリアにキャンプオンする（camp on）ことを回避するため、既存のメカニズム（例：バーリング（barring））を使用することができる。

【0021】

ユーザ機器は、自身の能力に応じて１つまたは複数のコンポーネントキャリア（複数のサービングセルに対応する）を同時に受信または送信することができる。キャリアアグリゲーションのための受信能力もしくは送信能力またはその両方を備えた、ＬＴＥ−Ａリリース１０のユーザ機器は、複数のサービングセル上で同時に受信する、もしくは送信する、またはその両方を行うことができ、これに対して、ＬＴＥリリース８／９のユーザ機器は、コンポーネントキャリアの構造がリリース８／９の仕様に従う場合、１つのみのサービングセル上で受信および送信を行うことができる。

【0022】

キャリアアグリゲーションは、連続するコンポーネントキャリアおよび不連続なコンポーネントキャリアの両方においてサポートされ、各コンポーネントキャリアは、３ＧＰＰ ＬＴＥ（リリース８／９）の計算方式（numerology）を使用して、周波数領域における最大１１０個のリソースブロックに制限される。

【0023】

同じｅＮｏｄｅＢ（基地局）から送信される、場合によってはアップリンクおよびダウンリンクにおいて異なる帯域幅の異なる数のコンポーネントキャリアをアグリゲートするように、３ＧＰＰ ＬＴＥ−Ａ（リリース１０）互換のユーザ機器を構成することが可能である。設定することのできるダウンリンクコンポーネントキャリアの数は、ユーザ機器のダウンリンクのアグリゲーション能力に依存する。逆に、設定することのできるアップリンクコンポーネントキャリアの数は、ユーザ機器のアップリンクのアグリゲーション能力に依存する。ダウンリンクコンポーネントキャリアよりもアップリンクコンポーネントキャリアが多くなるように移動端末を構成することはできない。

【0024】

一般的なＴＤＤ配備では、コンポーネントキャリアの数および各コンポーネントキャリアの帯域幅は、アップリンクとダウンリンクとで同じである。同じｅＮｏｄｅＢから送信されるコンポーネントキャリアは、必ずしも同じカバレッジを提供する必要はない。

【0025】

連続的にアグリゲートされるコンポーネントキャリアの中心周波数の間隔は、３００ｋＨｚの倍数である。これは、３ＧＰＰ ＬＴＥ（リリース８／９）の１００ｋＨｚの周波数ラスターとの互換性を保つと同時に、１５ｋＨｚ間隔のサブキャリアの直交性を維持するためである。アグリゲーションのシナリオによっては、連続するコンポーネントキャリアの間に少数の使用されないサブキャリアを挿入することによって、ｎ×３００ｋＨｚの間隔あけを容易にすることができる。

【0026】

複数のキャリアをアグリゲートする影響は、ＭＡＣ層に及ぶのみである。ＭＡＣ層には、アップリンクおよびダウンリンクの両方において、アグリゲートされるコンポーネントキャリアごとに１つのＨＡＲＱエンティティが要求される。コンポーネントキャリアあたりのトランスポートブロックは最大１個である（アップリンクにおけるＳＵ−ＭＩＭＯを使用しない場合）。トランスポートブロックおよびそのＨＡＲＱ再送信（発生時）は、同じコンポーネントキャリアにマッピングする必要がある。

【0027】

図５および図６は、それぞれ、ダウンリンクおよびアップリンクにおける、キャリアアグリゲーションが設定された第２層構造を示している。

【0028】

キャリアアグリゲーションが設定されているとき、移動端末はネットワークとの１つのＲＲＣ接続のみを有する。ＲＲＣ接続の確立／再確立時、１つのセルが、ＬＴＥリリース８／９と同様に、セキュリティ入力（１つのＥＣＧＩ、１つのＰＣＩ、および１つのＡＲＦＣＮ）と、非アクセス層（ＮＡＳ）モビリティ情報（例：ＴＡＩ）とを提供する。ＲＲＣ接続の確立／再確立の後、そのセルに対応するコンポーネントキャリアは、ダウンリンクプライマリセル（ＰＣｅｌｌ）と称される。接続状態では、ユーザ機器あたりつねに１つのダウンリンクＰＣｅｌｌ（ＤＬ ＰＣｅｌｌ）および１つのアップリンクＰＣｅｌｌ（ＵＬ ＰＣｅｌｌ）が設定される。コンポーネントキャリアの設定されたセットおいて、他のセルは２次セル（ＳＣｅｌｌ）と呼ばれ、ＳＣｅｌｌのキャリアはダウンリンク２次コンポーネントキャリア（ＤＬ ＳＣＣ）およびアップリンク２次コンポーネントキャリア（ＵＬ ＳＣＣ）である。ダウンリンクＰＣｅｌｌおよびアップリンクＰＣｅｌｌの特徴は以下のとおりである。
− 各ＳＣｅｌｌごとに、ダウンリンクリソースに加えてアップリンクリソースのユーザ機器による使用を設定することができる。したがって、設定されるＤＬ ＳＣＣの数はＵＬ ＳＣＣの数よりもつねに大きいかまたは等しく、アップリンクリソースのみを使用するようにＳＣｅｌｌを設定することはできない。
− アップリンクＰＣｅｌｌが、層１アップリンク制御情報の送信のために使用される。
− ダウンリンクＰＣｅｌｌは、ＳＣｅｌｌとは異なり非アクティブ化することはできない。
− ＵＥの観点からすると、各アップリンクリソースは、１つのサービングセルにのみ属する。
− 設定することができるサービングセルの数は、ＵＥのアグリゲーション能力によって決まる。
− ダウンリンクＰＣｅｌｌにおいてレイリーフェージング（ＲＬＦ）が発生すると再確立がトリガーされるが、ダウンリンクＳＣｅｌｌにＲＬＦが発生しても再確立はトリガーされない。
− ダウンリンクＰＣｅｌｌセルは、ハンドオーバとともに（すなわちセキュリティキー変更およびＲＡＣＨ手続きとともに）変化する。
− 非アクセス層情報はダウンリンクＰＣｅｌｌから取得される。
− ＰＣｅｌｌは、ハンドオーバ手順（すなわちセキュリティキー変更およびＲＡＣＨ手順）によってのみ変更することができる。
− ＰＣｅｌｌは、ＰＵＣＣＨの送信に使用される。

【0029】

コンポーネントキャリアの設定および再設定は、ＲＲＣによって行うことができる。アクティブ化および非アクティブ化は、ＭＡＣ制御要素を介して行われる。ＬＴＥ内ハンドオーバ時、ＲＲＣによって、ターゲットセルで使用するためのＳＣｅｌｌを追加、削除、または再設定することもできる。新しいＳＣｅｌｌを追加するときには、ＳＣｅｌｌのシステム情報（送信／受信に必要である）を送るために個別のＲＲＣシグナリングが使用される（ＬＴＥリリース８／９におけるハンドオーバ時と同様）。

【0030】

キャリアアグリゲーションを使用するようにユーザ機器が構成されているとき、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアの一対がつねにアクティブである。この対のうちのダウンリンクコンポーネントキャリアは、「ダウンリンクアンカーキャリア」と称されることもある。同じことはアップリンクについてもあてはまる。

【0031】

キャリアアグリゲーションが設定されているとき、同時に複数のコンポーネントキャリアについてユーザ機器をスケジューリングすることができるが、一度に行うことのできるランダムアクセス手順は最大で１つである。クロスキャリアスケジューリング（cross-carrier scheduling）では、コンポーネントキャリアのＰＤＣＣＨによって別のコンポーネントキャリアのリソースをスケジューリングすることができる。この目的のため、それぞれのＤＣＩフォーマットにコンポーネントキャリア識別フィールド（「ＣＩＦ」と称する）が導入されている。

【0032】

クロスキャリアスケジューリングが行われていないときには、アップリンクコンポーネントキャリアとダウンリンクコンポーネントキャリアとをリンクすることによって、グラントが適用されるアップリンクコンポーネントキャリアを識別することができる。アップリンクコンポーネントキャリアへのダウンリンクコンポーネントキャリアのリンクは、必ずしも１対１である必要はない。言い換えれば、同じアップリンクコンポーネントキャリアに複数のダウンリンクコンポーネントキャリアをリンクすることができる。一方で、１つのダウンリンクコンポーネントキャリアは、１つのアップリンクコンポーネントキャリアのみにリンクすることができる。

【0033】

ＯＳＩレイヤの一般的概要

【0034】

図７は、ＯＳＩモデルの簡単な概要を提供する。ＬＴＥアーキテクチャのさらなる論考はこのＯＳＩモデルに基づき、また、本発明も本明細書においてＯＳＩモデルに基づいて論じられる。

【0035】

開放型システム間相互接続参照モデル（ＯＳＩモデルまたはＯＳＩ参照モデル）は、通信およびコンピュータネットワークプロトコル設計の階層化された抽象的記述である。ＯＳＩモデルは、システムの機能を一連のレイヤに分ける。各レイヤは、下位のレイヤの機能のみを使用し、上位のレイヤにのみ機能をエクスポートするという特性を有する。一連のこれらのレイヤからなるプロトコル動作を実装するシステムは、「プロトコルスタック」または「スタック」として知られている。その主な特徴は、あるレイヤが別のレイヤとどのように対話するかの仕様を指示するレイヤ間のジャンクションである。これは、ある製造業者によって書かれたレイヤが別の製造業者からのレイヤと動作し得ることを意味する。本発明を目的として、最初の３つのレイヤのみが、以下にさらに詳しく説明される。

【0036】

物理レイヤまたはレイヤ１の主な目的は、特定の物理メディア（例えば、同軸ケーブル、ツイストペア、光ファイバ、無線インタフェースなど）を介する情報（ビット）の転送である。それは、通信チャネルを介して送信される信号（またはシンボル）にデータを変換または変調する。

【0037】

データリンクレイヤ（またはレイヤ２）の目的は、入力データをデータフレームに分割することによって特定の物理レイヤと互換性のある方法で情報フローを形成することである（セグメント化および再構築（ＳＡＲ：Re-assembly）機能）。さらに、データリンクレイヤ（またはレイヤ２）は、失われたフレームの再送信を要求することによって、潜在的送信エラーを検出および訂正することができる。データリンクレイヤ（またはレイヤ２）は、通常は、アドレス指定メカニズムを提供し、データ転送速度を受信器容量と合わせるために、フロー制御アルゴリズムを提供することができる。共用メディアが複数の送信器および受信器によって同時に使用される場合、データリンクレイヤは、通常は、物理メディアへのアクセスを調整および制御するためのメカニズムを提供する。

【0038】

データリンクレイヤによって提供される多数の機能が存在するため、データリンクレイヤは、しばしば、サブレイヤに細分される（例えば、ＵＭＴＳにおけるＲＬＣおよびＭＡＣサブレイヤ）。レイヤ２プロトコルの代表的な例は、固定回線ネットワークのＰＰＰ／ＨＤＬＣ、ＡＴＭ、フレームリレー、および、ワイヤレスシステムのＲＬＣ、ＬＬＣまたはＭＡＣである。レイヤ２のサブレイヤＰＤＣＰ、ＲＬＣおよびＭＡＣのさらに詳しい情報は、後に提供する。

【0039】

ネットワークレイヤまたはレイヤ３は、トランスポートレイヤによって要求されるサービスの質を維持しながら、１つまたは複数のネットワークを介してソースから宛先に可変長パケットを転送する機能的および手続き的手段を提供する。通常は、ネットワークレイヤの主な目的は、とりわけ、ネットワーク経路指定、ネットワークフラグメンテーションおよび輻輳制御機能を実行することである。ネットワークレイヤプロトコルの主な例は、ＩＰインターネットプロトコルまたはＸ.２５である。

【0040】

レイヤ４からレイヤ７に関して、レイヤ３より上で動作するアプリケーションおよびサービスは、しばしば、ＯＳＩモデルの異なるレイヤの属性とされることになるさまざまな機能を実装するため、アプリケーションおよびサービスに応じて、アプリケーションまたはサービスをＯＳＩモデルの特定のレイヤの属性とすることがときに困難であることに留意されたい。したがって、特にＴＣＰ（ＵＤＰ）／ＩＰベースのネットワークで、レイヤ４以上は、ときに、結合され、いわゆる「アプリケーションレイヤ」を形成する。

【0041】

レイヤサービスおよびデータ交換

【0042】

以下、本明細書で使用されるものとしてのサービスデータユニット（ＳＤＵ）およびプロトコルデータユニット（ＰＤＵ）という用語が、図８に関して定義される。ＯＳＩモデル内のレイヤ間のパケットの交換を一般的方法で正式に説明するために、ＳＤＵおよびＰＤＵエンティティが導入されている。ＳＤＵは、いわゆるサービスアクセスポイント（ＳＡＰ）を介してレイヤＮにあるプロトコルにサービスを要求するレイヤＮ＋１にあるプロトコルから送信される情報（データ／情報ブロック）の単位である。ＰＤＵは、同レイヤＮにある同プロトコルの送信器および受信器での同位プロセスの間で交換される情報の単位である。

【0043】

ＰＤＵは、レイヤＮ特有のヘッダが先行する、そしてオプションでトレーラによって終了させられる、受信されたＳＤＵの処理済みのバージョンからなるペイロード部分によって一般に形成される。これらの同位プロセスの間には直接物理接続は存在しない（レイヤ１を除く）ので、ＰＤＵは、処理のためにレイヤＮ−１に送られる。したがって、レイヤＮ ＰＤＵは、レイヤＮ−１の観点からするとＳＤＵである。

【0044】

ＬＴＥレイヤ２−ユーザプレーンおよび制御プレーンプロトコルスタック

【0045】

ＬＴＥレイヤ２ユーザ−プレーン／制御−プレーンプロトコルスタックは、図９に示すような３つのサブレイヤ、ＰＤＣＰ、ＲＬＣおよびＭＡＣ、を備える。前に説明したように、送信側で、各レイヤは、そのレイヤがサービスを提供する上位レイヤからＳＤＵを受信し、下位のレイヤにＰＤＵを出力する。ＲＬＣレイヤは、ＰＤＣＰレイヤからパケットを受信する。これらのパケットは、ＰＤＣＰの観点からはＰＤＣＰ ＰＤＵと呼ばれ、ＲＬＣの観点からはＲＬＣ ＳＤＵを表す。ＲＬＣレイヤは、下位のレイヤ、すなわちＭＡＣレイヤ、に提供されるパケットを作成する。ＲＬＣによってＭＡＣレイヤに提供されるパケットは、ＲＬＣの観点からはＲＬＣ ＰＤＵであり、ＭＡＣの観点からはＭＡＣ ＳＤＵである。

【0046】

受信側では、各レイヤが上位のレイヤにＳＤＵを渡して、それらはＰＤＵとして受信され、プロセスは反転される。

【0047】

物理レイヤは、ターボ符号化および周期的冗長検査（ＣＲＣ）によって保護されたビットパイプを基本的に提供するが、リンク−レイヤプロトコルは、さらに高い信頼性、セキュリティ、および完全性によって上位レイヤへのサービスを強化する。加えて、リンクレイヤは、マルチユーザメディアアクセスおよびスケジューリングの役割を担う。ＬＴＥリンク−レイヤ設計の主な課題のうちの１つは、広い範囲の異なるサービスおよびデータ転送速度を有するインターネットプロトコル（ＩＰ）データフローの要求される信頼性レベルおよび遅延を実現することである。特に、プロトコルオーバヘッドはスケール変更する必要がある。例えば、ボイスオーバＩＰ（ＶｏＩＰ）フローは、約１００ｍｓの遅延および１パーセントまでのパケット損失を許容し得ると、広く想定されている。他方で、ＴＣＰファイルダウンロードは、低い帯域幅−遅延の積を有するリンクを介してよりよく機能することが、よく知られている。したがって、非常に高いデータ転送速度（例えば、１００Ｍｂ／ｓ）でのダウンロードは、さらに低い遅延を要求し、加えて、ＶｏＩＰトラフィックよりもＩＰパケット損失に敏感である。

【0048】

概して、これは、部分的に絡み合ったＬＴＥリンクレイヤの３つのサブレイヤによって達成される。

【0049】

パケットデータ収束プロトコル（ＰＤＣＰ）サブレイヤは、主にＩＰヘッダ圧縮および暗号化の役割を担う。加えて、それは、ｅＮＢ間ハンドオーバの場合に無損失の移動をサポートし、上位レイヤ制御プロトコルに完全性保護を提供する。

【0050】

無線リンク制御（ＲＬＣ）サブレイヤは、主としてＡＲＱ機能性を備え、データセグメント化および連結をサポートする。後者の２つは、データ転送速度とは無関係にプロトコルオーバヘッドを最小化する。

【0051】

最後に、メディアアクセス制御（ＭＡＣ）サブレイヤは、ＨＡＲＱを提供し、スケジューリング動作およびランダムアクセスなど、メディアアクセスに必要とされる機能を担う。図１０は、リンク−レイヤプロトコルを介する物理レイヤまでのＩＰパケットのデータフローを例示的に示す。本図は、各プロトコルサブレイヤがそれ自体のプロトコルヘッダをデータユニットに追加することを示す。

【0052】

パケットデータ収束プロトコル（ＰＤＣＰ）

【0053】

ＰＤＣＰレイヤは、制御プレーンの無線リソース制御（ＲＲＣ）メッセージおよびユーザプレーンのＩＰパケットを処理する。無線ベアラ特性および関連するＲＬＣエンティティのモード（ＡＭ、ＵＭ、ＴＭ）に応じて、ＰＤＣＰレイヤのＰＤＣＰエンティティによって実行される主要な機能は、次の通りである。
− ヘッダ圧縮および解凍（例えば、ユーザプレーンデータ（ＤＲＢ）のローバストヘッダ圧縮（ＲＯＨＣ）を使用する）
− セキュリティ機能：
・ユーザプレーンおよび制御プレーンデータ（ＳＲＢおよびＤＲＢの）の暗号化および復号化
・制御プレーンデータ（ＳＲＢの）の完全性保護および検証
− ＳＲＢおよびＤＲＢのＰＤＣＰシーケンス番号のメンテナンス
− ハンドオーバサポート機能：
・ＡＭ ＤＲＢのハンドオーバでの上位レイヤのＰＤＵの順番通りの配信および並べ替え
・ＡＭ ＤＲＢの状況報告およびＡＭ ＤＲＢの下位レイヤＳＤＵの重複削除を含む、ＲＬＣ ＡＭ（Acknowledged Mode：確認応答モード）にマップされたユーザプレーンデータの無損失のハンドオーバ
− タイムアウト（ＳＲＢおよびＤＲＢの）によるユーザプレーンデータの破棄

【0054】

ＰＤＣＰレイヤは、個別制御チャネル（ＤＣＣＨ）または個別トランスポートチャネル（ＤＴＣＨ）のいずれかを使用する無線ベアラのみについて、ユーザプレーンにおいて、ならびに制御プレーンにおいて、データストリームを管理する。ＰＤＣＰレイヤのアーキテクチャは、ユーザプレーンデータと制御プレーンデータとによって異なる。２つの異なるタイプのＰＤＣＰ ＰＤＵ、具体的には、ＰＤＣＰデータＰＤＵおよびＰＤＣＰ制御ＰＤＵ、がＬＴＥにおいて定義される。ＰＤＣＰデータＰＤＵは、制御およびユーザプレーンデータの両方に使用される。ＰＤＣＰ制御ＰＤＵは、ヘッダ圧縮の、およびハンドオーバの場合に使用され、したがってユーザプレーン内でのみ使用されるＰＤＣＰ状況報告の、フィードバック情報を移送するためにのみ使用される。

【0055】

本発明との関連性が低いため、ヘッダ圧縮およびセキュリティの機能は詳しくは説明しない。それらに関する詳細は、参照により本明細書に組み込まれている、非特許文献２の４.２.２章、４.２.３章および４.２.４章で見ることができる。

【0056】

他方では、ハンドオーバ機能が、以下に詳細に説明される。ハンドオーバは、ＵＥが、ＲＣＣ＿ＣＯＮＮＥＣＴＥＤ状態で、あるセルのカバレッジから別のセルのカバレッジに移動するときに実行される。要求されるＱｏＳに応じて、シームレスまたは無損失のいずれかのハンドオーバが、以下に説明するように、各ユーザプレーン無線ベアラに適するように実行される。

【0057】

シームレスハンドオーバが、ＲＬＣ ＵＭ（Unacknowledged Mode：非確認応答）にマップされたユーザプレーン無線ベアラについて適用される。これらのタイプのデータは、通常は、損失にはかなり耐性があるが、遅延にはあまり耐性がない（例えば、音声サービス）。

【0058】

ＰＤＣＰデータＰＤＵに追加されたシーケンス番号に基づいて、ハンドオーバ中に順番通りの配信を確保することと、受信がハンドオーバに先立ってまだ確認応答されていないＰＤＣＰ ＳＤＵの再送信を実行することとによって、完全に無損失のハンドオーバ機能を提供することも可能である。この無損失のハンドオーバ機能は、１つのＰＤＣＰ ＳＤＵの損失が、伝送制御プロトコル（ＴＣＰ）の反応によりデータ転送速度の大幅な減少をもたらし得る、ファイルダウンロードなどの遅延耐性のあるサービスに使用される。

【0059】

無損失のハンドオーバは、ＲＬＣ ＡＭ（確認応答モード）にマップされたユーザプレーン無線ベアラ（すなわち、データ無線ベアラ）について適用される。簡潔性を理由として、ｅＮｏｄｅＢ間ハンドオーバおよびｅＮｏｄｅＢ内ハンドオーバは、ＬＴＥにおいて同じ方法で扱われる。

【0060】

通常の送信では、ＵＥがあるセルから別のセルにハンドオーバしていない間、ＵＥおよびｅＮｏｄｅＢ内のＲＬＣレイヤは順番通りの配信を確保する。ＲＬＣプロトコルによって再送信される、またはＨＡＲＱ送信における可変遅延により順番を外れて到達する、ＰＤＣＰ ＰＤＵは、ＲＬＣ ＳＮに基づいて並べ替えられる。ハンドオーバで、ＵＥ内のおよびｅＮｏｄｅＢ内のＲＬＣレイヤは、ヘッダ圧縮プロトコルがリセットされる前に、それらを解凍させるために、ＰＤＣＰレイヤに既に受信されたすべてのＰＤＣＰ ＰＤＵを配信することになる。いくつかのＰＤＣＰ SＤＵは、この時点で入手可能ではないことがあるので、順番通りに入手可能ではないＰＤＣＰ ＳＤＵは、ＵＥ内の上位レイヤにまたはネットワーク内のゲートウェイに直ちに配信されない。ＰＤＣＰレイヤで、順番を外れて受信されたＰＤＣＰ ＳＤＵは、並べ替えバッファに記憶される。送信されたがＲＬＣレイヤによってまだ確認応答されていないＰＤＣＰ ＳＤＵは、ＰＤＣＰレイヤ内の再送信バッファに記憶される。

【0061】

アップリンクにおける無損失のハンドオーバを確保するために、ＵＥは、ＰＤＣＰ再送信バッファに記憶されたＰＤＣＰ ＳＤＵを再送信する。例えば、ハンドオーバの後、ＵＥは、送信の成功がまだ確認応答されていないそれらのＰＤＣＰ ＳＤＵの目標ｅＮｏｄｅＢへの送信を再始動する。アップリンクにおける順番通りの配信を確保するために、ソースｅＮｏｄｅＢは、解凍の後に、ゲートウェイに順番通りに受信されたＰＤＣＰ ＳＤＵを配信し、順番を外れて受信されたＰＤＣＰ ＳＤＵを目標ｅＮｏｄｅＢに転送する。それにより、目標ｅＮｏｄｅＢは、ハンドオーバ中に保持されたＰＤＣＰ ＳＮに基づいて、ソースｅＮｏｄｅＢから受信された解凍されたＰＤＣＰ ＳＤＵと、ＵＥから受信された再送信されたＰＤＣＰ ＳＤＵとを並べ替え、正しい順番でそれらをゲートウェイに配信することができる。

【0062】

ダウンリンクにおける無損失のハンドオーバを確保するために、ソースｅＮｏｄｅＢは、受信がまだＵＥによって確認応答されていない圧縮されていないＰＤＣＰ ＳＤＵをダウンリンクにおける再送信のために目標ｅＮｏｄｅＢに転送する。ソースｅＮｏｄｅＢは、そのソースｅＮｏｄｅＢに送信された最後のパケットを指示するゲートウェイからの指示を受信する。目標ｅＮｏｄｅＢが、それがゲートウェイから受信されたパケットの送信をいつ開始することができるかを知るように、ソースｅＮｏｄｅＢはまた、目標ｅＮｏｄｅＢにこの指示を転送する。

【0063】

ＵＥは、ＳＮの昇順で目標ｅＮｏｄｅＢからのパケットを予期することになる。ソースｅＮｏｄｅＢから目標ｅＮｏｄｅＢにパケットが転送されない場合（すなわち、ＵＥが予期するパケットのうちの１つが、ハンドオーバ動作中に欠落したとき）、ＵＥは、そのパケットが失われたと直ちに結論を出し、既に順番に受信されたパケットを上位レイヤに転送することができる。これは、潜在的再送信を待つために、既に受信されたパケットをＵＥが保持する必要性を避ける。それにより、ネットワーク内のパケットの転送は、ＵＥに知らせることなしに、決定され得る。

【0064】

場合によっては、ＰＤＣＰ ＳＤＵは無事に受信されたが、対応するＲＬＣ確認応答が受信されないことが起こり得る。この場合、ハンドオーバの後、ＲＬＣレイヤによって受信された誤った状況に基づいて、ＵＥまたは目標ｅＮｏｄｅＢによって不必要な再送信が開始されることがある。これらの不必要な再送信を避けるために、ＰＤＣＰ状況報告が、ｅＮｏｄｅＢからＵＥにおよびＵＥからｅＮｏｄｅＢに送信され得る。加えて、ＰＤＣＰ状況報告は、正しく受信されたがヘッダ解凍に失敗したＰＤＣＰ ＳＤＵの再送信を要求することができる。ハンドオーバの後にＰＤＣＰ状況報告を送信するかどうかは、各無線ベアラについて独立して設定される。

【0065】

ＰＤＣＰ ＰＤＵフォーマット

【0066】

ＰＤＣＰには、２つのタイプのＰＤＵ、具体的にはＰＤＣＰデータＰＤＵおよびＰＤＣＰ制御ＰＤＵ、が存在する。ＰＤＣＰデータＰＤＵは、ＩＰパケットなどのユーザプレーンデータまたはＲＲＣ／ＮＡＳメッセージなどの制御プレーンデータを転送するために使用される。ユーザプレーンデータのＰＤＣＰ ＰＤＵは、そのフォーマットがそれぞれ図１１および１２に示された、データＰＤＵと制御ＰＤＵとを区別するために、「Ｄ／Ｃ」フィールドを備える。ＰＤＣＰデータＰＤＵは、７または１２ビットシーケンス番号（ＳＮ）を備える。ユーザプレーンデータのＰＤＣＰデータＰＤＵは、圧縮されていない（ヘッダ圧縮が使用されていない場合）または圧縮されたＩＰパケットのいずれかを含む。制御プレーンデータのＰＤＣＰデータＰＤＵ（例えば、ＲＲＣシグナリング）は、完全性保護のための３２ビット長のＭＡＣ−Ｉフィールドを備える。制御プレーンデータのＰＤＣＰデータＰＤＵは、１つの完全なＲＲＣメッセージを含む。

【0067】

ＰＤＣＰ制御ＰＤＵは、ユーザプレーンデータを処理するＰＤＣＰエンティティによって使用される。ＰＤＣＰヘッダ内のＰＤＵタイプフィールドによって区別される、現在定義されている２つのタイプのＰＤＣＰ制御ＰＤＵが存在する。ＰＤＣＰ制御ＰＤＵは、無損失のハンドオーバの場合のＰＤＣＰ「状況報告」、またはＲＯＨＣヘッダ圧縮プロトコルによって作成されるＲＯＨＣフィードバックのいずれかを運ぶ。ＲＯＨＣフィードバックを運ぶＰＤＣＰ制御ＰＤＵは、ＲＬＣ ＵＭまたはＲＬＣ ＡＭのいずれかにマップされたユーザプレーン無線ベアラのために使用され、一方、ＰＤＣＰ状況報告を運ぶＰＤＣＰ制御ＰＤＵは、ＲＬＣ ＡＭにマップされたユーザプレーン無線ベアラのためにのみ使用される。

【0068】

ＰＤＣＰ状況報告

【0069】

無損失のハンドオーバの場合のＰＤＣＰ状況報告（ＰＤＣＰ ＳＲ）を運ぶＰＤＣＰ制御ＰＤＵは、既に正確に受信されたＰＤＣＰ ＳＤＵの再送信を防ぐために使用され、正確に受信されたがヘッダ解凍が失敗したＰＤＣＰ ＳＤＵの再送信を要求するために使用することができる。状況報告を有するこのＰＤＣＰ制御ＰＤＵは、どのＰＤＣＰ ＳＤＵが再送信される必要があるかおよび参照ＳＮ、ＦＭＳ（First Missing SDU：最初に紛失したＳＤＵ）、を指示する、ビットマップを含む。すべてのＰＤＣＰ ＳＤＵが順番通りに受信された場合、このフィールドは、次の予期されるＳＮを指示し、ビットマップは含まれない。

【0070】

図１３は、１２ビットＳＮ長が使用されるときにＰＤＣＰ状況報告を運ぶＰＤＣＰ制御ＰＤＵのフォーマットを示し、そして、図１４は、非特許文献３の６.２.６章に定義されるような、１５ビットＳＮ長が使用されるときのＰＤＣＰ状況報告を運ぶＰＤＣＰ制御ＰＤＵのフォーマットを示す。このフォーマットは、ＲＬＣ ＡＭにマップされたＤＲＢについて適用可能である。

【0071】

図１３および図１４から明らかなように、ＰＤＣＰ状況報告のＰＤＣＰ制御ＰＤＵは、非特許文献３の６.３.７章〜６.３.１０章（参照により本明細書に組み込まれている）によって定義される以下のパラメータを備える。
− １ビット「Ｄ／Ｃ」フィールド、制御ＰＤＣＰ ＰＤＵおよびデータＰＤＣＰ ＰＤＵを区別することを可能にする
− ３ビットＰＤＵタイプフィールド、ＰＤＣＰ状況報告と散在するＲＯＨＣフィードバックパケットとを区別することを可能にし、ビット０１０〜１１１が予約される
− ＦＭＳフィールド、１２ビットＳＮが使用されるときに１２ビットの長さを有し、１５ビットＳＮが使用されるときに１５ビットの長さを有する、それは最初に紛失したＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮを示す
− 可変長のビットマップフィールド、長さは０でもよい、タイプ「ビットマップ」の最初のオクテットのＭＳＢは、ＳＮ（ＦＭＳ＋１）モジュロ（Ｍａｘｉｍｕｍ＿ＰＤＣＰ＿ＳＮ＋１）を有するＰＤＣＰ ＳＤＵが受信されたかどうか、およびオプションで正確に解凍されたかどうか、を示す。タイプ「ビットマップ」の最初のオクテットのＬＳＢは、ＳＮ（ＦＭＳ＋８）モジュロ（Ｍａｘｉｍｕｍ＿ＰＤＣＰ＿ＳＮ＋１）を有するＰＤＣＰ ＳＤＵが受信されたかどうか、およびオプションで正確に解凍されたかどうか、を示す。ＵＥは、どのＳＤＵが紛失したか（セットされていないビット−「０」）、すなわちＳＤＵが受信されていないかどうか、またはオプションで、受信されたが正確に解凍されなかったかどうか、ならびに、どのＳＤＵが再送信を必要としないか（セットされたビット−「１」）、すなわちＳＤＵが正確に受信されたかどうか、および正確に解凍されたかどうかを示す、ビットマップに記入する。

【0072】

ＰＤＣＰ状況報告は、参照により本明細書に組み込まれている、非特許文献３の５.３.５.３.１章でより詳細に説明されている。

【0073】

送信動作では、上位レイヤが、ＲＬＣ ＡＭにマップされた無線ベアラについて、ＰＤＣＰ再確立を要求するとき、ＵＥは、
− 無線ベアラが、アップリンクでＰＤＣＰ状況報告を送信するように下位レイヤによって設定された場合、下位レイヤの再確立により下位レイヤから受信されたＰＤＣＰデータＰＤＵを処理した後に、以下に示すように状況報告を編集し、これを、以下によって、すなわち、
・第１の紛失したＰＤＣＰ ＳＤＵのＰＤＣＰ ＳＮにＦＭＳフィールドをセットすること、
・少なくとも１つの、順番を外れたＰＤＣＰ ＳＤＵが記憶されている場合、次の８の倍数まで切り上げた、第１の紛失したＰＤＣＰ ＳＤＵを含まないそれ以降の、順番を外れた最後のＰＤＣＰ ＳＤＵまでの、ＰＤＣＰ ＳＮの数と等しいビットの長さのビットマップフィールドを割り当てること、
・下位レイヤによって指示された通りに受信されなかったすべてのＰＤＣＰ ＳＤＵ、および、オプションで、解凍が失敗したＰＤＣＰ ＳＤＵ、のビットマップフィールド内の対応する場所に「０」としてセットすること、
・すべての他のＰＤＣＰ ＳＤＵについてビットマップフィールド内で「１」として指示すること、
によって、送信のために第１のＰＤＣＰ ＰＤＵとして下位レイヤに提出する。

【0074】

受信動作では、ＲＬＣ ＡＭにマップされた無線ベアラについて、ＰＤＣＰ状況報告がダウンリンクで受信されるとき、
− もしあれば、「１」にセットされたビットマップ内のビットを有する、またはＦＭＳフィールドによって識別されるＰＤＣＰ ＳＤＵのカウント値より少ない関連カウント値を有する、各ＰＤＣＰ ＳＤＵについて、対応するＰＤＣＰ ＳＤＵの配信の成功が確認され、ＵＥはそのＰＤＣＰ ＳＤＵを処理することになる。

【0075】

言い換えれば、ＰＤＣＰ状況報告は、ＰＤＣＰレイヤが再確立される度に、編集され、送信される。

【0076】

確立されたすべての無線ベアラのＰＤＣＰ再確立は、例えば、ハンドオーバ中に、すなわち、参照により本明細書に組み込まれている非特許文献４の５.３.５.４章で定義されるように、ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎをＵＥによって受信するときに、実行される。参照により本明細書に組み込まれている非特許文献４の５.３.５.３章に定義されるように、ＲＲＣ接続再確立手続きが無事完了した後に、これが第１のＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージである場合に、ＵＥがｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏを含まないＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎを受信するときに、ＳＲＢ２のＰＤＣＰ再確立および確立されたすべてのＤＲＢが、実行される。さらに、ＰＤＣＰ再確立はまた、参照により本明細書に組み込まれている非特許文献４の５.３.７.５章に定義されるように、ＵＥがＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔを受信するとき、ＳＲＢ１のみについてであるが、実行される。

【0077】

ＲＲＣ

【0078】

無線リソース制御（ＲＲＣ）レイヤは、無線インタフェースでのＵＥとｅＮＢとの間の通信と、いくつかのセルにわたり移動するＵＥの移動とを制御する。ＲＲＣプロトコルはまた、ＮＡＳ情報の転送をサポートする。ＲＲＣ＿ＩＤＬＥにおけるＵＥについて、ＲＲＣは、入電のネットワークからの通知をサポートする。ＲＲＣ接続制御は、ページング、測定設定および報告、無線リソース設定、初期セキュリティ起動、シグナリング無線ベアラ（ＳＲＢ）の確立、ならびにユーザデータを運ぶ無線ベアラ（データ無線ベアラ、ＤＲＢ）の確立を含む、ＲＲＣ接続の確立、修正および解放に関するすべての手続きを対象とする。

【0079】

個別ＲＲＣメッセージは、ＰＤＣＰおよびＲＬＣレイヤを介して論理チャネル、具体的には接続確立中の共通制御チャネル（ＣＣＣＨ）またはＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおける個別制御チャネル（ＤＣＣＨ）のいずれか、にマップされる、シグナリング無線ベアラを横切って転送される。システム情報およびページングメッセージは、それぞれ、論理チャネル、ブロードキャスト制御チャネル（ＢＣＣＨ）およびページング制御チャネル（ＰＣＣＨ）に直接マップされる。

【0080】

ＳＲＢ１とＳＲＢ２との主な差は、ｅＮＢにおける優先順位処理であり、すなわち、ＳＲＢ２を介して送信されるＲＲＣメッセージは、ＳＲＢ１を介して送信されるＲＲＣメッセージよりも低い優先順位を有する。

【0081】

ＳＲＢ０は、ＣＣＣＨを使用するＲＲＣメッセージのために使用され、ＳＲＢ１はＤＣＣＨを使用するＲＲＣメッセージのために使用され、ＳＲＢ２は、ＮＡＳ個別情報のみを含むＤＣＣＨを使用する（より低い優先順位の）ＲＲＣメッセージを目的とする。ＳＲＢ２確立に先立って、ＳＲＢ１はまた、ＮＡＳ個別情報またはＭＤＴ（測定ドライブテスト）ログを取られた測定結果のみを含むＲＲＣメッセージのために使用される。加えて、ＳＲＢ１は、ＮＡＳ個別情報のみを含むより高い優先順位のＲＲＣメッセージのために使用される。

【0082】

ＤＣＣＨを使用するすべてのＲＲＣメッセージは、ＰＤＣＰレイヤによって完全性保護および暗号化される（セキュリティ起動の後）。ＣＣＣＨを使用するＲＲＣメッセージは、完全性保護されない。

【0083】

無線リンク制御（ＲＬＣ）

【0084】

ＲＬＣレイヤは、ＰＤＣＰレイヤ（ＲＬＣの観点から、「上位」レイヤ）とＭＡＣレイヤ（ＲＬＣの観点から、「下位レイヤ」）との間に置かれる。ＲＬＣレイヤは、サービスアクセスポイント（ＳＡＰ）を介してＰＤＣＰレイヤと通信し、論理チャネルを介してＭＡＣレイヤと通信する。ＲＬＣレイヤは、ＭＡＣレイヤによって指示されたサイズにＰＤＣＰ ＰＤＵ（すなわちＲＬＣ ＳＤＵ）を適合させるために、それらを再フォーマットする、すなわち、ＲＬＣ送信器はＰＤＣＰ ＰＤＵをセグメント化するおよび／または連結させ、ＲＬＣ受信器はＲＬＣ ＰＤＵを再構築してＰＤＣＰ ＰＤＵを再構成する。加えて、ＲＬＣ ＰＤＵが、ＭＡＣレイヤで実行されるＨＡＲＱ動作により順番を外れて受信された場合、ＲＬＣはそれらを並べ替える。

【0085】

ＲＬＣレイヤの機能は、「ＲＬＣエンティティ」によって実行される。ＲＬＣエンティティは、３つのデータ送信モード、すなわち、透過モード（ＴＭ）、非確認応答モード（ＵＭ）および確認応答モード（ＡＭ）、のうちの１つで設定される。ＡＭでは、特別な機能が、再送信をサポートするために定義される。

【0086】

ＵＭ ＲＬＣの主な機能は、次のように要約することができる。すなわち、ＲＬＣ ＳＤＵ（すなわちＰＤＣＰ ＰＤＵ）のセグメント化および連結、ＲＬＣ ＰＤＵの並べ替え、ＲＬＣ ＳＤＵの重複検出、ＲＬＣ ＳＤＵの再構築。

【0087】

ＡＭ ＲＬＣの主な機能は、次のように要約することができる。ＲＬＣデータＰＤＵの再送信、再送信されたＲＬＣデータＰＤＵの再セグメント化、ポーリング、状況報告、状況禁止。

【0088】

ＲＬＣのさらなる情報は、参照により本明細書に組み込まれている、非特許文献２の４.３.１章によって与えられる。

【0089】

ハンドオーバ手続き

【0090】

上記で説明したように、ＵＥがＰＤＣＰ状況報告のために設定されるとき、ハンドオーバがそのＵＥによって実行される度に、ＰＤＣＰ状況報告が編集され、送信される。

【0091】

３ＧＰＰ ＬＴＥハンドオーバ手続きは、３ＧＰＰのウェブサイトで入手可能であり、参照により本明細書に組み込まれている非特許文献５の１０.１.２節において特定されている。さらに、ＲＲＣ接続再設定に関するハンドオーバ手続きの詳細は、３ＧＰＰのウェブサイトで入手可能であり、参照により本明細書に組み込まれている非特許文献４に定義されている。

【0092】

接続モードにおけるＵＥのＥ−ＵＴＲＡＮ内アクセス移動サポートは、ソースネットワーク側での最終的ハンドオーバ（ＨＯ）決定に先行するプロセス（ある特定のＵＥ特有のエリア制約事項を考慮したＵＥおよびｅＮＢ測定結果の制御および評価）、目標ネットワーク側のリソースの準備、新しい無線リソースへのＵＥの指揮、および、（古い）ソースネットワーク側でのリソースの最終的な解放のような、ハンドオーバ手続きのすべての必要なステップを処理する。

【0093】

ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態でのＵＥのＥ−ＵＴＲＡＮ内ハンドオーバ（ＨＯ）は、Ｅ−ＵＴＲＡＮにおけるＨＯ準備シグナリングを有する、ＵＥ支援のネットワーク制御ＨＯである。
− ＨＯコマンドの部分は、目標ｅＮＢに由来し、ソースｅＮＢによって透過的にＵＥに転送される。
− ＨＯを準備するために、ソースｅＮＢは、すべての必要な情報を目標ｅＮＢに渡す。
− ソースｅＮＢおよびＵＥの両方が、ＨＯ失敗の場合にＵＥの復帰を可能にするための何らかのコンテキスト（例えば、Ｃ−ＲＮＴＩ）を保持する。
− ＵＥは、個別ＲＡＣＨプリアンブルを使用する無競合手続きに従って、または個別ＲＡＣＨプリアンブルが入手可能でない場合には競合ベースの手続きに従って、ＲＡＣＨを介して目標セルにアクセスする。
− そのＵＥは、ハンドオーバ手続きが終了する（無事にまたは失敗して）まで、個別プリアンブルを使用する。
− 目標セルに向けたＲＡＣＨ手続きがある一定の時間内に成功しなかった場合、ＵＥは、最良のセルを使用し、無線リンク障害復旧を開始する。

【0094】

ＨＯ手続きの準備および実行フェーズは、ＥＰＣの関与なしに実行され、すなわち、準備メッセージはｅＮＢの間で直接に交換される。ＨＯ完了フェーズ中のソース側でのリソースの解放は、ｅＮＢによってトリガーされる。

【0095】

以下、図１５に示すＭＭＥ／サービングゲートウェイ内ハンドオーバ（ＨＯ）手続きのより詳細な説明が与えられ、先行する番号は、図１５のシーケンス線図における対応するステップを指す。

【0096】

０ ソースｅＮＢ内のＵＥコンテキストは、接続確立または最後のＴＡ更新のいずれかで提供されたローミング制約事項に関する情報を含む。

【0097】

１ ソースｅＮＢは、そのエリア制約情報に従って、ＵＥ測定手続きを設定する。ソースｅＮＢによって提供される測定結果は、ＵＥの接続移動を制御する機能を支援することができる。

【0098】

２ 測定報告がトリガーされ、ｅＮＢに送信される。

【0099】

３ ソースｅＮＢは、測定報告およびＲＲＭ情報に基づいて、ＵＥをハンドオフする決定を行う。

【0100】

４ ソースｅＮＢは、目標側でＨＯを準備するために、必要な情報を渡す目標ｅＮＢにハンドオーバ要求メッセージを発行する（ソースｅＮＢでのＵＥ Ｘ２シグナリングコンテキスト参照、ＵＥ Ｓ１ ＥＰＣシグナリングコンテキスト参照、目標セルＩＤ、ＫｅＮＢ^＊、ソースｅＮＢにおけるＵＥのＣ−ＲＮＴＩを含むＲＲＣコンテキスト、ＡＳ設定、ソースセルのＥ−ＲＡＢコンテキストおよび物理レイヤＩＤ＋起こり得るＲＬＦ復旧のショートＭＡＣ−Ｉ）。ＵＥ Ｘ２／ＵＥ Ｓ１シグナリング参照は、目標ｅＮＢがソースｅＮＢおよびＥＰＣをアドレス指定することを可能にする。Ｅ−ＲＡＢコンテキストは、必要なＲＮＬおよびＴＮＬアドレス指定情報、およびＥ−ＲＡＢのＱｏＳプロファイルを含む。

【0101】

５ アドミッション制御が、リソースが目標ｅＮＢによって認可され得る場合、ＨＯ成功の可能性を増やすために、受信されたＥ−ＲＡＢ ＱｏＳ情報に応じて目標ｅＮＢによって実行され得る。目標ｅＮＢは、受信されたＥ−ＲＡＢ ＱｏＳ情報に従って、必要とされるリソースを設定し、Ｃ−ＲＮＴＩ、およびオプションでＲＡＣＨプリアンブルを予約する。目標セルで使用されることになるＡＳ設定は、独立して（すなわち「確立」）またはソースセルで使用されるＡＳ設定と比較した差分として（すなわち「再設定」）のいずれかで特定することができる。

【0102】

６ 目標ｅＮＢは、Ｌ１／Ｌ２でＨＯを準備し、ハンドオーバ要求確認応答をソースｅＮＢに送信する。ハンドオーバ要求確認応答メッセージは、ハンドオーバを実行するためのＲＲＣメッセージとしてＵＥに送信されることになる透過的コンテナを含む。そのコンテナは、新しいＣ−ＲＮＴＩ、選択されたセキュリティアルゴリズムの目標ｅＮＢセキュリティアルゴリズム識別子、を含み、個別ＲＡＣＨプリアンブル、および、場合によりいくつかの他のパラメータ、すなわちアクセスパラメータ、ＳＩＢなど、を含むことができる。ハンドオーバ要求確認応答メッセージはまた、必要に応じて、転送トンネルのためのＲＮＬ／ＴＮＬ情報を含むことができる。

【0103】

注：ソースｅＮＢがハンドオーバ要求確認応答を受信するとすぐに、または、ハンドオーバコマンドの送信がダウンリンクで開始されるとすぐに、データ転送が開始され得る。

【0104】

ステップ７から１６は、ＨＯ中のデータ損失を回避するための手段を提供し、３ＧＰＰのウェブサイトで入手可能であり参照により本明細書に組み込まれている非特許文献５の１０.１.２.１.２および１０.１.２.３でさらに詳述されている。

【0105】

７ 目標ｅＮＢは、ＵＥに向けてソースｅＮＢによって送信されることになる、ハンドオーバを実行するためのＲＲＣメッセージ、すなわちｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、を生成する。ソースｅＮＢは、メッセージの必要な完全性保護および暗号化を実行する。ＵＥは、必要なパラメータ（すなわち、新しいＣ−ＲＮＴＩ、目標ｅＮＢセキュリティアルゴリズム識別子、およびオプションで個別ＲＡＣＨプリアンブル、目標ｅＮＢ ＳＩＢなど）を有するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信し、ＨＯを実行するようにソースｅＮＢによって命令される。ＵＥは、ＨＡＲＱ／ＡＲＱ応答をソースｅＮＢに配信するためにハンドオーバ実行を遅らせる必要はない。

【0106】

８ ソースｅＮＢは、ＰＤＣＰ状況保存が適用される（すなわち、ＲＬＣ ＡＭの）Ｅ−ＲＡＢのアップリンクＰＤＣＰ ＳＮ受信器状況およびダウンリンクＰＤＣＰ ＳＮ送信器状況を伝播するために、目標ｅＮＢにＳＮ状況転送メッセージを送信する。アップリンクＰＤＣＰ ＳＮ受信器状況は、第１の紛失したＵＬ ＳＤＵのＰＤＣＰ ＳＮを少なくとも含み、そのようなＳＤＵが存在する場合に、ＵＥが目標セルにおいて再送信する必要がある順番を外れたＵＬ ＳＤＵの受信状況のビットマップを含み得る。ダウンリンクＰＤＣＰ ＳＮ送信器状況は、目標ｅＮＢが、まだＰＤＣＰ ＳＮを有しない、新しいＳＤＵに割り当てることになる、次のＰＤＣＰ ＳＮを示す。ソースｅＮＢは、ＵＥのＥ−ＲＡＢのいずれもＰＤＣＰ状況保存で扱われない場合に、このメッセージの送信を省略することができる。

【0107】

９ ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信した後、ＵＥは、目標ｅＮＢへの同期化を実行し、個別ＲＡＣＨプリアンブルがそのｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎで指示された場合には無競合手続きに続いて、または、個別プリアンブルが指示されなかった場合には競合ベースの手続きに続いて、ＲＡＣＨを介して目標セルにアクセスする。ＵＥは、目標ｅＮＢ特有のキーを導出し、目標セルで使用されることになる選択されたセキュリティアルゴリズムを設定する。

【0108】

１０ 目標ｅＮＢが、ＵＬ割当ておよびタイミングの前進で応答する。

【0109】

１１ ＵＥが目標セルに無事にアクセスしたとき、ＵＥは、可能であればいつも、アップリンクバッファ状況報告とともに、ハンドオーバを確認するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージ（Ｃ−ＲＮＴＩ）を目標ｅＮＢに送信して、そのハンドオーバ手続きがそのＵＥについて完了したことを指示する。目標ｅＮＢが、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージで送信されるＣ−ＲＮＴＩを確認する。目標ｅＮＢは、ここで、ＵＥへのデータの送信を開始することができる。

【0110】

１２ 目標ｅＮＢが、パス切替え要求メッセージをＭＭＥに送信して、ＵＥがセルを変更したことを知らせる。

【0111】

１３ ＭＭＥが、ベアラ修正要求メッセージをサービングゲートウェイに送信する。

【0112】

１４ サービングゲートウェイが、ダウンリンクデータパスを目標側に切り替える。サービングゲートウェイは、古いパスで１つまたは複数の「エンドマーカ」パケットをソースｅＮＢに送信し、次いで、ソースｅＮＢに向けて任意のＵプレーン／ＴＮＬリソースを解放することができる。

【0113】

１５ サービングゲートウェイが、ベアラ修正応答メッセージをＭＭＥに送信する。

【0114】

１６ ＭＭＥが、パス切替え要求確認応答メッセージでパス切替え要求メッセージを確認する。

【0115】

１７ ＵＥコンテキスト解放メッセージを送信することによって、目標ｅＮＢは、ソースｅＮＢにＨＯの成功を知らせ、ソースｅＮＢによるリソースの解放をトリガーする。目標ｅＮＢは、このメッセージをパス切替え要求確認応答メッセージがＭＭＥから受信された後に送信する。

【0116】

１８ ＵＥコンテキスト解放メッセージを受信したとき、ソースｅＮＢは、ＵＥコンテキストに関連する無線およびＣプレーン関連リソースを解放することができる。任意の進行中のデータ転送は、継続することができる。

【0117】

ＨｅＮＢを含むＸ２ハンドオーバが使用されるとき、および、ソースＨｅＮＢがＨｅＮＢ ＧＷに接続されるとき、明示的ＧＷコンテキスト解放指示を含むＵＥコンテキスト解放要求メッセージが、ＨｅＮＢ ＧＷが、そのＵＥコンテキストに関連するすべてのリソースを解放し得ることを指示するために、ソースＨｅＮＢによって送信される。

【0118】

スモールセル

【0119】

移動体データの爆発的需要は、いかに移動体事業者が、より大容量およびユーザ体験の品質（ＱｏＥ）の向上の難しい要件に応える必要があるかの変化を促している。現在、ロングタームエボリューション（ＬＴＥ）を使用する第４世代ワイヤレスアクセスシステムが、３Ｇ／３.５Ｇシステムよりも低いレイテンシおよび高い効率でより高速のアクセスを実現するために、多数の事業者によって世界中で配備されている。しかしながら、予想される将来のトラフィック成長は、驚異的であり、特にトラフィックの最高容量を生成する高トラフィックエリア（ホットスポットエリア）では、容量要件に対処するためのさらなるネットワーク高密度化の必要性が非常に高まっている。ネットワーク高密度化―ネットワークノードの数を増やし、それによりネットワークノードをユーザ端末に物理的により近づけること―は、トラフィック容量を改善するおよびワイヤレス通信システムの達成可能なユーザ−データ転送速度を高めるための鍵である。

【0120】

マクロ配備の直接的な高密度化に加えて、ネットワーク高密度化は、既存のマクロノード層のカバレッジの下でそれぞれスモールセルの補足的低電力ノードの配備によって達成することができる。そのような異種配備では、低電力ノードは、例えば屋内および屋外のホットスポットの場所において、ローカルに非常に高いトラフィック容量および非常に高いユーザスループットを提供する。その一方で、マクロ層は、カバレッジエリア全体にわたりサービスアベイラビリティおよびＱｏＥを確保する。言い換えれば、低電力ノードを含む層はまた、広いエリアをカバーするマクロ層とは対照的に、ローカルエリアアクセスを提供すると言うことができる。

【0121】

スモールセルそれぞれの低電力ノードの設置ならびに異種配備は、ＬＴＥの第１のリリース以降、可能であった。この関連で、いくつかの解決策が、ＬＴＥの最近のリリース（すなわち、リリース１０／１１）において特定された。より具体的には、これらのリリースは、異種配備における層間の干渉を処理するために、追加のツールを紹介した。パフォーマンスをさらに最適化し、コスト／エネルギー効率の高い動作を実現するために、スモールセルは、さらなる拡張を必要とし、多くの場合、既存のマクロセルと対話するまたは既存のマクロセルを補完する必要がある。そのような解決策は、ＬＴＥリリース１２以降のさらなる進化の間に調査されることになる。特に、低電力ノードおよび異種配備に関連するさらなる拡張が新しいリリース１２の研究事項（ＳＩ）「Ｅ−ＵＴＲＡおよびＥ−ＵＴＲＡＮのためのスモールセル拡張の研究（Study on Small Cell Enhancements for E-UTRA and E-UTRAN）」の下で検討されることになろう。これらの活動のうちのいくつかは、低電力層および二重層接続性へのマクロ支援の異なる形を含む、マクロ層と低電力層との間のさらに高度の相互作用の達成に重点的に取り組むことになろう。二重接続は、デバイスがマクロ層および低電力層の両方への同時接続を有することを暗示する。

【0122】

スモールセル拡張の本研究事項において想定されるいくつかの配備シナリオを以下に論じる。以下のシナリオでは、非特許文献６において理想的ではないバックホールとして分類されたバックホール技術が想定される。

【0123】

理想的バックホール（すなわち、光ファイバを使用する個別２地点間接続などの非常に高いスループットおよび非常に小さいレイテンシのバックホール）および非理想的バックホール（すなわち、ｘＤＳＬなどの市場で広く使用されている通常のバックホール、マイクロウェーブ、および中継のような他のバックホール）の両方が研究されるべきである。性能−コストのトレードオフが、考慮されるべきである。

【0124】

オペレータ入力に基づく非理想的バックホールの分類が、以下の表に記載される。

【0125】

【表1】

【0126】

ＲＲＨ（Remote Radio Head：遠隔無線ヘッド）を配備するために使用することができるファイバアクセスは、本研究では想定されていない。ＨｅＮＢは除外されないが、ＨｅＮＢの送信電力がピコｅＮＢのそれよりも低くても、配備シナリオおよび課題に関してピコｅＮＢと区別されない。以下の３つのシナリオが、考えられる。

【0127】

シナリオ＃１は、図１６に示され、同じキャリア周波数（周波数内）のマクロセルおよびスモールセルが理想的ではないバックホールを介して接続される配備シナリオである。ユーザは、屋外および屋内の両方に分散される。

【0128】

シナリオ＃２は、図１７および１８に示され、異なるキャリア周波数（周波数間）のマクロセルおよびスモールセルが理想的ではないバックホールを介して接続される配備シナリオを指す。ユーザは、屋外および屋内の両方に分散される。本明細書で２ａおよび２ｂと呼ばれる、２つの異なるシナリオ＃２が基本的に存在し、その差は、シナリオ２ｂでは、屋内スモールセル配備が考慮されるということである。

【0129】

シナリオ＃３は、図１９に示され、１つまたは複数のキャリア周波数のスモールセルのみが理想的ではないバックホールリンクを介して接続される配備シナリオを指す。

【0130】

配備シナリオに応じて、異なる課題／問題が存在し、さらなる調査を必要とする。研究事項フェーズの間に、そのような課題が、対応する配備シナリオについて識別され、非特許文献７において捉えられ、それらの課題／問題のさらなる詳細は、そこで見ることができる。

【0131】

非特許文献７の５節に記載された識別された課題を解決するために、以下の設計目標が、非特許文献６で特定された要件に加えて、本研究について検討される。

【0132】

移動性頑強性に関して、
− ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおけるＵＥについて、スモールセル配備によって達成される移動性パフォーマンスは、マクロのみのネットワークのそれに匹敵すべきである。

【0133】

頻繁なハンドオーバによるシグナリング負荷の増加に関して、
− いずれの新しい解決策も、コアネットワークに向けたシグナリング負荷の過度の増加をもたらしてはならない。しかし、スモールセル拡張によって引き起こされる追加のシグナリングおよびユーザプレーントラフィック負荷もまた、考慮されるべきである。

【0134】

ユーザごとのスループットおよびシステム容量の改善に関して、
− 理想的バックホール配備に似たユーザごとのスループットおよびシステム容量を達成するために、マクロセルおよびスモールセルにわたる無線リソースを使用し、一方で、ＱｏＳ要件が目標とされるべきであることを考慮する。

【0135】

二重接続

【0136】

３ＧＰＰ ＲＡＮ作業グループにおいて現在審議中の問題への１つの有望な解決策は、いわゆる「二重接続」コンセプトである。「二重接続」という用語は、非理想的バックホールを介して接続された少なくとも２つの異なるネットワークノードによって提供される無線リソースを所与のＵＥが消費する動作を示すために使用される。基本的に、ＵＥは、マクロセル（マクロｅＮＢ）およびスモールセル（２次または小型ｅＮＢ）の両方と接続される。さらに、ＵＥの二重接続に関与する各ｅＮＢは、異なる役割を想定することができる。それらの役割は、ｅＮＢの電力クラスに必ずしも依存せず、ＵＥの間で異なってもよい。

【0137】

本研究事項は、現在、非常に初期の段階にあるので、二重接続の詳細はまだ決定されていない。例えば、アーキテクチャはまだ合意されていない。したがって、多くの事項／詳細、例えばプロトコル拡張は、現在、まだ未決定である。図２０は、二重接続の例示的アーキテクチャを示す。それは単に１つの潜在的オプションとして理解されるべきであり、本発明は、この特定のネットワーク／プロトコルアーキテクチャに限定されず、広く適用され得る。アーキテクチャに関する以下の想定が、本明細書では行われる。
− 各パケットをどこに供するか、Ｃ／Ｕプレーン分割、のベアラレベルごとの決定
・例として、ＵＥ ＲＲＣシグナリングおよびＶｏＬＴＥなどの高いＱｏＳデータが、マクロセルによって提供可能であり、一方、ベストエフォート型データがスモールセルにオフロードされる。
− ベアラ間の結合はなく、マクロセルとスモールセルとの間に必要とされる共通のＰＤＣＰまたはＲＬＣはない。
− ＲＡＮノード間のルーザ調整
− ＳｅＮＢはＳ−ＧＷに接続しない、すなわち、パケットはＭｅＮＢによって転送される。
− スモールセルはＣＮに対して透過的である。

【0138】

最後の２つの箇条書きに関して、ＳｅＮＢがＳ−ＧＷと直接接続されること、すなわち、Ｓ１−ＵがＳ−ＧＷとＳｅＮＢとの間にあること、もまた起こり得ることに留意されたい。基本的に、ベアラマッピング／分割に関する３つの異なるオプションが存在する。
− オプション１：図２１ａに示され、Ｓ１−Ｕはまた、ＳｅＮＢにおいて終了する。
− オプション２：図２１ｂに示され、Ｓ１−ＵはＭｅＮＢにおいて終了し、ベアラはＲＡＮにおいて分割しない。
− オプション３：図２１ｃに示され、Ｓ１−ＵはＭｅＮＢにおいて終了し、ベアラはＲＡＮにおいて分割する。

【0139】

図２１ａ〜ｃは、Ｕプレーンデータのダウンリンク方向を一例として挙げる、それらの３つのオプションを示す。説明を目的として、オプション２は、本出願のために主として想定され、図２０のベースでもある。

【0140】

スモールセル拡張のためのユーザプレーンアーキテクチャ

【0141】

図２１ａ〜図２１ｃに示すようなＵプレーンデータの分割の論考に加えて、異なる代替も、ユーザプレーンアーキテクチャについて論じられた。

【0142】

Ｓ１−ＵインタフェースがＭｅＮＢで終了するとき（図２１ｂ、図２１ｃ）、ＳｅＮＢ内のプロトコルスタックは、ＲＬＣ（再）セグメント化を少なくともサポートしなければならないことは、共通に理解されていることである。これは、ＲＬＣ（再）セグメント化が、物理インタフェース（例えば、ＲＬＣ ＰＤＵのサイズを示すＭＡＣレイヤ、上記を参照）に密接に結合された動作であり、非理想的バックホールが使用されるとき、ＲＬＣ（再）セグメント化が、ＲＬＣ ＰＤＵを送信するものと同じノードで起こらなければならないという事実による。

【0143】

この想定に基づいて、ユーザプレーン代替の４つのファミリは、現在行われている論考において区別される。

【0144】

Ａ．独立ＰＤＣＰ：本オプションは、ベアラごとに完全に、現在定義されている無線インタフェースＵプレーンプロトコルスタックを終了させ、１つのノードによる１つのＥＰＳベアラの送信を実現するように適合されるが、追加のレイヤの助けとともにＭｅＮＢおよびＳｅＮＢによる送信のために単一のＥＰＳベアラの分割をサポートすることもできる。異なるベアラの送信はさらに、ＭｅＮＢおよびＳｅＮＢから同時に生じ得る。

【0145】

Ｂ．マスタ−スレーブＰＤＣＰ：本オプションは、Ｓ１−Ｕが、ＭｅＮＢ内に存在するＰＤＣＰレイヤの少なくとも一部を有するＭｅＮＢで終了すると想定する。ベアラ分割の場合、ＭｅＮＢで終了された、ＰＤＣＰベアラのＰＤＣＰ ＰＤＵを配信するように設定されたｅＮＢごとに、ＵＥ側にも、別個の独立したＲＬＣベアラが存在する。

【0146】

Ｃ．独立ＲＬＣ：本オプションは、Ｓ１−Ｕが、ＭｅＮＢ内に存在するＰＤＣＰレイヤを有するＭｅＮＢ内で終了すると想定する。ベアラ分割の場合、ＭｅＮＢで終了した、ＰＤＣＰベアラのＰＤＣＰ ＰＤＵを配信するように設定されたｅＮＢごとに、ＵＥ側にも、別個の独立したＲＬＣベアラが存在する。

【0147】

Ｄ．マスタ−スレーブＲＬＣ：本オプションは、Ｓ１−Ｕが、ＰＤＣＰレイヤおよびＭｅＮＢ内に存在するＲＬＣレイヤの一部を有するＭｅＮＢで終了すると想定する。ＥＰＳベアラのＵＥ内の１つのみのＲＬＣエンティティを要求する一方で、ネットワーク側で、ＲＬＣ機能は、ＳｅＮＢ内で動作する「スレーブＲＬＣ」を有する、関連するノードの間で分散される。ダウンリンクで、スレーブＲＬＣは、ＳｅＮＢで必要とされる遅延クリティカルなＲＬＣ動作の管理をする。スレーブＲＬＣは、マスタがスレーブによる送信のために割り当てた容易に構築されたＲＬＣ ＰＤＵ（マスタによって既に割り当てられたシーケンス番号を有する）をＭｅＮＢでマスタＲＬＣから受信し、それらをＵＥに送信する。これらのＰＤＵのＭＡＣスケジューラからの認可へのカスタムフィッティングは、現在定義されている再セグメント化メカニズムを再使用することによって、達成される。

【0148】

それに基づいて、図２２ａ〜図２２ｉに示される異なるアーキテクチャが提案され、これらは非特許文献８から引用された。

【0149】

図２２ａ〜図２２ｉに示すさまざまな代替の主な特性の概要は、以下に与えられ、ベアラ分割は複数のｅＮＢを介するベアラを分割する能力として理解されるものとする。Ｓ１インタフェースから出ると指示された、２つのみのベアラが想定されていることが、図から理解されよう。
− １Ａ：Ｓ１−Ｕは、ＳｅＮＢ＋独立ＰＤＣＰ（ベアラ分割なし）で終了する。
− ２Ａ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割なし＋ＳｅＮＢでの独立ＰＤＣＰで終了する。
− ２Ｂ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割なし＋マスタ−スレーブＰＤＣＰで終了する。
− ２Ｃ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割なし＋ＳｅＮＢでの独立ＲＬＣで終了する。
− ２Ｄ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割なし＋マスタ−スレーブＲＬＣで終了する。
− ３Ａ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割＋分割ベアラの独立ＰＤＣＰで終了する。
− ３Ｂ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割＋分割ベアラのマスタ−スレーブＰＤＣＰで終了する。
− ３Ｃ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割＋分割ベアラの独立ＲＬＣで終了する。
− ３Ｄ：Ｓ１−Ｕは、ＭｅＮＢ＋ＭｅＮＢにおけるベアラ分割＋分割ベアラのマスタ−スレーブＲＬＣで終了する。

【0150】

本論考で、さまざまな利点および欠点が、上記の代替の各々について識別される。

【0151】

ユーザプレーンアーキテクチャの欠点

【0152】

前のセクションにおいて説明したように、スモールセルおよび二重接続は、最近の成果であり、効率的システムを可能にするために対処する必要があるいくつかの問題をまだ引き起こす。

【0153】

例えば、図２２ｄおよび図２２ｅのそれら、そしてまた図２２ｈおよび図２２ｉのそれら、および、分散型のＰＤＣＰスレーブ−マスタ概念の後の実装形態に応じて図２２ｃおよび図２２ｇのそれらのアーキテクチャもまた、ＳｅＮＢにマップされたベアラのＰＤＣＰレイヤがＭｅＮＢ内に存在するプロトコルアーキテクチャに関するハンドオーバシナリオに関して問題が存在する。それに対応して、図２１ｂおよび図２１ｃに示すシナリオが、本発明について想定される。これは、以下で詳細に説明される。

【0154】

リリース８では、無損失の送信は、確認応答モード（ＡＭ）データ無線ベアラ、すなわちＲＬＣ ＡＭを使用しているデータ無線ベアラ、についてサポートされる。基本的に、ＡＭ ＲＬＣ受信器は、ＲＬＣ状況報告を使用し、正確に受信されなかったＲＬＣ ＰＤＵに否定的に確認応答する。すべてのＲＬＣ ＰＤＵが受信されるまで、または、ｅＮＢによって設定された再送信の最大数に到達するまで、再送信が繰り返し実行される。ハンドオーバでは、無損失の送信もサポートするために、ＰＤＣＰ再送信メカニズムが、リリース８で紹介されている。ＲＬＣ状況報告は通常は最新ではない、すなわち、ＵＥ受信状況は既に変化していることがあるので、これは必要である。

【0155】

この選択的ＰＤＣＰ再送信メカニズムは、ハンドオーバの前にＲＬＣエンティティによって確認応答されなかった目標ｅＮＢからのハンドオーバの後にＰＤＣＰ ＳＤＵを再送信する。ＰＤＣＰ再送信をサポートするために、ＰＤＣＰ受信器は、ＰＤＣＰ再確立の前にＲＬＣ再確立の結果として受信されたＰＤＣＰ ＰＤＵを処理することを要求される。受信器側の再構成されたＰＤＣＰ ＳＤＵは、それらが順番を外れている場合、または他の方法で上位レイヤに配信された場合、並べ替えバッファに記憶される。ハンドオーバの後、ハンドオーバの前に確認応答されなかったＰＤＣＰ ＳＤＵは、送信エンティティによって再送信され、ＰＤＣＰ受信器は、それらを並べ替えバッファに記憶されたＳＤＵとともに並べ替える。並べ替えが機能するために、カウントおよびまたＰＤＣＰシーケンス番号を含む、すべてのＰＤＣＰ状態変数は、ハンドオーバで保持される必要がある。

【0156】

ＰＤＣＰ再送信は、ＰＤＣＰ状況報告を使用することによって、さらに最適化することができる。前述のように、ＲＬＣ状況報告は最新ではないことがあり、すなわち、ＰＤＣＰ ＳＤＵの受信がＲＬＣ状況報告によって確認応答されていなかったとしても、そのＰＤＣＰ ＳＤＵがハンドオーバの前に無事に送信されていることが起こり得る。したがって、ハンドオーバの後にＰＤＣＰ ＳＤＵの不必要な再送信がいくらかある可能性がある。それらを避けるために、ＰＤＣＰ受信器は、ハンドオーバの後にＰＤＣＰ状況報告をＰＤＣＰ送信器に送信する。不必要な再送信が回避され得るように、ＰＤＣＰ状況報告は、ＰＤＣＰ受信器の最新の並べ替えバッファの状況を記載する。

【0157】

二重接続の範囲で、リリース８ハンドオーバまたはリリース１０キャリアアグリゲーション移動事象と比較して新しい移動事象が存在する。本発明の基礎にあるいくつかの問題を説明するために、ＵＥが二重接続する、すなわちＵＥがＭｅＮＢおよびＳｅＮＢにも接続を確立し、それのＳｅＮＢを変更する、移動事象に焦点を合わせる。これは、図２３に示される。ＳｅＮＢ変更で、すなわちＭｅＮＢは変更されず、ソースＳｅＮＢ（移動事象の前に接続されたＳｅＮＢ）を介して送信される無線ベアラ（本例ではＥＰＳベアラ＃１の部分としての無線ベアラ＃１）は、目標ＳｅＮＢ（ＳｅＮＢ変更の後に接続されるＳｅＮＢ）にマップされる。

【0158】

本発明はまた、例えば、二重接続するＵＥが単一接続に移る、すなわちマクロセルにのみ接続される、ことになる、他の移動シナリオにもまた適用可能であることに留意されたい。これは、図２４に示される。ソースＳｅＮＢに前にマップされたベアラは、その移動事象の後に、ＭｅＮＢによって供される。本発明はまた、ＵＥがＭｅＮＢならびにＳｅＮＢを変更する、そして単一の新しいＭｅＮＢの（すなわち新しいＳｅＮＢなしの）単一接続（図示せず）に変更し得る、ケースにも適用される。

【0159】

以下の説明では、図２３のシナリオが想定される。ＰＤＣＰレイヤはＭｅＮＢ内に存在する（例えば、図２２ｄを参照）ので、ＰＤＣＰレイヤは、ＳｅＮＢ変更について再確立されないことになる。それに対応して、ＭｅＮＢは、ＳｅＮＢ変更の後に、ＰＤＣＰ ＰＤＵを新しいＳｅＮＢ２に転送する。ＡＭ ＤＲＢのＳｅＮＢでの無損失の送信もまたサポートするために、ＲＬＣレイヤによって前に確認応答されなかったＰＤＣＰ ＳＤＵは、ＳｅＮＢ変更の後に、新しいＳｅＮＢ２によって再送信される。しかし、ＭｅＮＢは、ＳｅＮＢ変更の前にＲＬＣ／ＰＤＣＰ受信状況の最新の知識を有しないので、ＳｅＮＢ変更後の不必要なＰＤＣＰ ＳＤＵ再送信が結果となり得る。ＰＤＣＰ再確立は実行されないので、ＰＤＣＰ状況報告はトリガーされないことに留意されたい。

【先行技術文献】

【非特許文献】

【0160】

【非特許文献1】3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)"

【非特許文献2】LTE - The UMTS Long Term Evolution FROM THEORY TO PRACTICE, Edited by: Stefania Sesia, Issam Toufik, Matther Baker, Second Edition, ISBN 978-0-470-66025-6

【非特許文献3】3GPP TS 36.323 v11.2.0

【非特許文献4】3GPP TS 36.331: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification)”, version 11.4.0

【非特許文献5】3GPP TS 36.300: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocio Access Network (E-UTRAN); Overall description; Stage 2”, version 11.6.0

【非特許文献6】TR 36.932

【非特許文献7】TS 36.842

【非特許文献8】the Email Discussion Report on U-Plane Alternatives, 3GPP TSG-RAN WG2 Meeting #82, R2-131621 by Nokia Siemens Networks (Rapporteur)

【発明の概要】

【発明が解決しようとする課題】

【0161】

本発明の１つの目的は、移動局とソース二次基地局および目標基地局との間の接続の無損失の変更の改善された方法を提供することである。本目的は、独立請求項の主題によって解決される。有利な実施形態は、従属請求項の主題である。

【課題を解決するための手段】

【0162】

本発明の第１の態様について、移動局は二重接続し、したがって、マスタ基地局および二次基地局の両方にそれぞれの少なくとも１つの無線ベアラを介して接続されると想定する。移動局は、マスタ基地局から二次基地局を介して移動局に転送されるデータパケットを少なくとも受信している。状況報告を編集し、送信する機能を有する、上位レイヤ（例えば、ＰＤＣＰレイヤ）を含むプロトコルスタックは、二次基地局にではなく、マスタ基地局に置かれる。二次基地局はまた、プロトコルスタックを有するが、マスタ基地局の前記特定の上位レイヤ（例えば、ＰＤＣＰレイヤ）を有するのではなくて、それは、マスタ基地局の上位レイヤより下位のレイヤ（例えば、ＲＬＣレイヤ）である下位レイヤを有する。それに対応して、データパケットは、マスタ基地局の上位（例えば、ＰＤＣＰ）レイヤから二次基地局の下位（例えば、ＲＬＣ）レイヤに転送される。それに対応して、移動局は、それの二次基地局からデータパケットを受信し、その二次局は次にマスタ基地局から同じものを受信する。データパケットは、通常の方式では移動局によって確認応答される。

【0163】

例示のみを目的として、移動局が現在その中に位置する通信システムは少なくとも１つのマスタ基地局および少なくとも２つの二次基地局を有するとさらに想定する。移動局はさらに、ソース二次基地局から別の基地局、それがマスタ基地局、別の新しいマスタ基地局または目標二次基地局であっても、に移動し、ハンドオーバを最終的に実行するとさらに想定する。いずれの場合にも、少なくとも、移動局をソース二次基地局に接続している無線ベアラは、ハンドオーバを実行するときに、この他の目標基地局に再マップ／再設定される必要がある。

【0164】

本発明の第１の態様によれば、効率的で無損失のハンドオーバ手続きが実装されることになる。特に、ソース二次基地局を介して進む前記無線ベアラが、移動事象によりソース二次基地局から別の基地局に再設定される（されようとする）とき、その移動局は、以下のように状況報告を準備し、送信するものとする。状況報告は、ソース二次基地局を介して進むすべてのデータ無線ベアラを介して移動局によってこれまでに受信されたデータパケットの受信状況の情報を含む。状況報告は複数のデータ無線ベアラの情報を含み得ることを考えて、状況報告内の情報は、その情報が関連する無線ベアラの対応する無線ベアラ識別子を添付されてあるものとする。したがって、受信エンティティ、すなわち結局のところ状況報告の宛先としてのマスタ基地局は、どのデータ無線ベアラを介して送信されたどのデータパケットが移動局によって既に正確に受信され、どのデータパケットがされなかったかを推測することができる。それに対応して、マスタ基地局は、それにより、移動局によってまだ無事に受信されていない、目標二次基地局へのデータパケットのうちのそれらのみを転送することができる。

【0165】

第１の態様の一実装形態によれば、異なる無線ベアラに関する情報の連結は、受信状況および無線ベアラ識別子からなる、情報の各セットの後の拡張フラグの使用によって状況報告で指示および識別される。別の表現をすると、状況報告は、ソース二次基地局から離れて目標に再マップされることになる各データ無線ベアラについて、前記データ無線ベアラを介して進むデータパケットの受信状況情報、前記データ無線ベアラの対応する無線ベアラ識別子および拡張フラグを含む。拡張フラグは、別のデータ無線ベアラに関する受信状況情報および無線ベアラ識別子もその状況報告に含まれることを示す。

【0166】

第１の態様の特定の例示的な一実装形態によれば、状況報告は、移動局内のＰＤＣＰレイヤエンティティによって編集され、ソース二次基地局を介して進む少なくとも１つのデータ無線ベアラのすべてを介して移動局によって受信されるＰＤＣＰ ＳＤＵの受信状況の情報を含むＰＤＣＰ状況報告である。

【0167】

先行技術によれば、上記では、前記状況報告を編集し、送信する役割を担う上位レイヤ（例えば、ＰＤＣＰレイヤ）は、マスタ基地局内にあるが（ソース）二次基地局内にはないことにより、再確立されないので、状況報告が送信されないことになるシナリオが想定されている。しかし、本発明の第１の態様によれば、紛失したデータパケットの必要な情報をマスタ基地局に提供するために、そして、それにより移動局への目標基地局による既に正確に受信されたデータパケットの再送信を回避するために、状況報告は、やはり、編集され、送信されることになる。一実装形態によれば、移動局が状況報告の準備を開始し、最終的に送信するためのトリガーは、ＲＲＣプロトコルレイヤがある基地局、例えばマスタ基地局、から移動局によって受信されるＲＲＣ接続再設定メッセージである。

【0168】

しかし、その状況報告は、ソース基地局を介して進むデータ無線ベアラに関連するので、その状況報告は、通常は、前記データ無線ベアラを介して送信されることになり、したがって、望まれていないバックホール遅延を招く。重大であることがある、マスタ基地局と目標二次基地局との間のバックホール遅延を避けるために、状況報告は、例えば、それがシグナリング無線ベアラまたはデータ無線ベアラであっても、移動局とマスタ基地局との間に直接確立された少なくとも１つの無線ベアラのうちの１つを介して、直接にマスタ基地局に移動局によって有利には送信することができる。言い換えれば、特定のデータ無線ベアラ（ソース二次基地局を介して進む）に関する情報を基本的に含む、状況報告が、移動局から別の無線ベアラを介してマスタ基地局に送信される。

【0169】

例えば、状況報告が、シグナリング無線ベアラを介してマスタ基地局に送信される場合、これは、ＲＲＣメッセージ、例えば、一実装形態によれば前述のように状況報告を編集および送信する移動局によるトリガーとして使用することができるＲＲＣ接続再設定メッセージの応答メッセージであるＲＲＣ接続再設定完了メッセージ、の一部として行うことができる。

【0170】

状況報告が、データ無線ベアラを介してマスタ基地局に送信される場合、これは、上記で説明したように異なるフォーマットを有する第３のＰＤＣＰ制御ＰＤＵタイプとしてではあるが、先行技術から知られている通常のＰＤＣＰ状況報告と同様の方式で、ＰＤＣＰ制御ＰＤＵとしての特定の例示的な一実装形態により行われ得る。

【0171】

マスタ基地局に直接に状況報告を送信してバックホール遅延を回避する方法のさらなる代替で、状況報告は、ＭＡＣ制御要素として送信することができ、言い換えれば、状況報告（上記で説明したような内容を有する）を備えるＭＡＣ制御要素は、物理チャネル送信、すなわち任意の無線ベアラに関連しない下位レイヤ送信、として移動局によってマスタ基地局に直接送信される。

【0172】

状況報告は、マスタ基地局に別の無線ベアラ、再マップされていない無線ベアラ（マスタ基地局も変更されないことを条件として）、を介して送信されるので、状況報告は、ＳｅＮＢ変更が終了しないうちでも送信することができる。これは、ＰＤＣＰ状況情報が適時にマスタ基地局内のＰＤＣＰレイヤによって受信され、ＰＤＣＰレイヤが、どのＰＤＣＰ ＳＤＵを再送信のために目標ＳｅＮＢに転送するかを決定するときに、この情報を使用することができるという利点を有する。言い換えれば、これは、移動事象の前に移動局によって受信されなかったそれらのパケット（ＰＤＣＰ ＳＤＵ）のみをマスタｅＮＢが転送すること、すなわち、不必要なデータパケットの転送がそれにより回避されること、を可能にする。

【0173】

上記で、第１の態様は、二次基地局を介してマスタ基地局からデータパケットを受信し、ハンドオーバを実行するときに状況報告を編集および送信する、移動局の観点から主に説明されている。しかし、上記で説明したような原理は、状況報告編集および送信の機能を実装する上位レイヤの他方のエンドポイントであるマスタ基地局の観点から同等に適用可能である。同じ方式で、マスタ基地局は、それがソース二次基地局から別の目標基地局（それが別の二次基地局、そのマスタ基地局、または別のマスタ基地局であっても）への移動局のハンドオーバを決定したとき、ソース二次基地局を介して進むすべてのデータ無線ベアラのすべてを介してその移動局からそのマスタ基地局によってこれまでに受信されたデータパケットの受信状況の情報を含めることによって、状況報告を編集する。状況報告のフォーマットは、移動局によって準備される状況報告に関して上記で説明したのと同じでもよく、すなわち、ソース二次基地局を介して進むこれらのデータ無線ベアラの各々について、受信状況情報、対応する無線ベアラ識別子および拡張フラグ（上記詳細を参照）を含み得る。

【0174】

さらに、そしてまた上記で既に説明した原理に従って、マスタ基地局によって準備される状況報告は、有利には、移動局に直接送信されることになり、それにより、マスタ基地局と二次基地局との間の迂回および対応するバックホール遅延を回避する。既に述べたように、これは、それがシグナリングまたはデータ無線ベアラであっても、確立された、移動局に使用可能な無線ベアラのうちの１つを介するマスタ基地局からの状況報告の送信によって実現され得る。この場合もやはり、ＲＲＣメッセージは、シグナリング無線ベアラ、またはデータ無線ベアラに関連する第３のタイプのＰＤＣＰ制御ＰＤＵ、または状況報告を送信するためのＭＡＣ ＣＥに関連して使用され得る。

【0175】

本発明の第１の実施形態は、移動局によって状況報告を送信する方法を提供し、そこにおいて、移動局は、少なくとも１つの無線ベアラを介してマスタ基地局におよび少なくとも１つのデータ無線ベアラを介してソース二次基地局に接続される。ソース二次基地局から目標基地局へ移動局の少なくとも１つのデータ無線ベアラを再設定するとき、移動局によって状況報告を送信する。その状況報告は、移動局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのすべてを介して移動局によって受信されるデータパケットの受信状況の情報を含み、その情報が状況報告に含まれる少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む。

【0176】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、移動局をマスタ基地局に直接接続する少なくとも１つの無線ベアラのうちの１つを介して、好ましくはデータ無線ベアラまたはシグナリング無線ベアラを介して、マスタ基地局に移動局によって送信される。

【0177】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、好ましくはＲＲＣ接続再設定完了メッセージ内で、移動局をマスタ基地局に直接接続する少なくとも１つの無線ベアラのうちの１つのシグナリング無線ベアラを介して無線リソース制御（ＲＲＣ）メッセージの一部として移動局によってマスタ基地局に送信される。別法として、状況報告は、移動局をマスタ基地局に直接接続する少なくとも１つの無線ベアラのうちの１つのデータ無線ベアラを介してパケットデータ収束プロトコル（ＰＤＣＰ）制御パケットデータユニットとして移動局によってマスタ基地局に送信される。別法として、状況報告は、メディアアクセス制御（ＭＡＣ）制御要素で送信される。

【0178】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、目標基地局は、その移動局が接続されたマスタ基地局、または、別のマスタ基地局、または目標二次基地局のいずれかである。

【0179】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告はさらに、移動局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのうちの１つを介して受信されるデータパケットの受信状況の情報の後に少なくとも１つの拡張フラグを含み、その拡張フラグは、その少なくとも１つのデータ無線ベアラのうちの別の１つのデータ無線ベアラを介して受信されるデータパケットの受信状況のさらなる情報の存在を示す。

【0180】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、移動局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのすべてを介して受信されるＰＤＣＰサービスデータユニットの受信状況の情報を含む、ＰＤＣＰ状況報告である。

【0181】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、移動局におけるＲＲＣ接続再設定メッセージの受信に応答して送信され、そのＲＲＣ接続再設定メッセージは、ソース二次基地局から目標基地局への移動局の少なくとも１つのデータ無線ベアラの再設定の一部として受信される。

【0182】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、
制御またはデータＰＤＵとしてＰＤＣＰ制御ＰＤＵを識別するための１ビット長のＤ／Ｃフィールド、
ＰＤＣＰ制御ＰＤＵのタイプを識別するための３ビット長のタイプフィールド、
後続の第１の紛失した情報およびビットマップフィールドが参照する無線ベアラを識別するための無線ベアラ識別子フィールド、
先行する無線ベアラ識別子フィールドで識別される無線ベアラに関する、第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長のフィールド、
オプションで、先行する無線ベアラ識別子フィールドで識別される無線ベアラを介して正確に受信された、または受信されなかった第１の紛失したＰＤＣＰ ＳＤＵから始まるＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有するビットマップフィールド、
さらなる情報がＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示する１ビット長の拡張フラグフィールド、
を備えるＰＤＣＰ制御パケットデータユニット（ＰＤＵ）であり、
拡張フラグフィールドが、さらなる情報が含まれると指示する場合に、状況報告は、
後続の第１の紛失した情報およびビットマップフィールドが参照する無線ベアラを識別するための別の無線ベアラ識別子フィールド、
先行する別の無線ベアラ識別子フィールドにおいて識別される無線ベアラに関する第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長の別のフィールド、
オプションで、先行する別の無線ベアラ識別子フィールドにおいて識別される無線ベアラを介して正確に受信された、または受信されなかった第１の紛失したＰＤＣＰ ＳＤＵから始まるＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有する別のビットマップフィールド、
さらなる情報がＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示する１ビット長の別の拡張フラグフィールド、
を含む。

【0183】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、データパケットは、マスタ基地局から二次基地局を介して移動局に転送され、また、状況報告機能を有する上位レイヤは、二次基地局にではなくマスタ基地局にある。

【0184】

第１の実施形態はさらに、状況報告を送信する移動局を提供し、その移動局は、少なくとも１つの無線ベアラを介してマスタ基地局におよび少なくとも１つのデータ無線ベアラを介してソース二次基地局に接続される。移動局の少なくとも１つのデータ無線ベアラがソース二次基地局から目標基地局に再設定されるとき、その移動局のプロセッサおよび送信器は、状況報告を送信する。その状況報告は、その移動局をそのソース二次基地局に接続する少なくとも１つのデータ無線ベアラのすべてを介してその移動局によって受信されるデータパケットの受信状況の情報を含み、その情報が状況報告に含まれる少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む。

【0185】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、移動局の送信器は、移動局をマスタ基地局に直接接続する少なくとも１つの無線ベアラのうちの１つを介して、好ましくはデータ無線ベアラまたはシグナリング無線ベアラを介して、マスタ基地局に状況報告を送信する。

【0186】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、その送信器は、
− 移動局をマスタ基地局に直接接続する少なくとも１つの無線ベアラのうちの１つのシグナリング無線ベアラを介して無線リソース制御（ＲＲＣ）メッセージの一部として、好ましくはＲＲＣ接続再設定完了メッセージ内で、または、
− 移動局をマスタ基地局に直接接続する少なくとも１つの無線ベアラのうちの１つのデータ無線ベアラを介してパケットデータ収束プロトコル（ＰＤＣＰ）制御パケットデータユニットとして、または、
− メディアアクセス制御（ＭＡＣ）制御要素において、
状況報告をマスタ基地局に送信する。

【0187】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告はさらに、移動局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのうちの１つを介して受信されるデータパケットの受信状況の情報の後に少なくとも１つの拡張フラグを含み、その拡張フラグは、その少なくとも１つのデータ無線ベアラのうちの別の１つのデータ無線ベアラを介して受信されるデータパケットの受信状況のさらなる情報の存在を示す。

【0188】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、移動局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのすべてを介してその移動局の受信器によって受信されるＰＤＣＰサービスデータユニットの受信状況の情報を含む、ＰＤＣＰ状況報告である。

【0189】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、移動局内の受信器によるＲＲＣ接続再設定メッセージの受信に応答して送信され、そのＲＲＣ接続再設定メッセージは、ソース二次基地局から目標基地局へのその移動局の少なくとも１つのデータ無線ベアラの再設定の一部として受信される。

【0190】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、状況報告は、
− 制御またはデータＰＤＵとしてＰＤＣＰ制御ＰＤＵを識別するための１ビット長のＤ／Ｃフィールド、
− ＰＤＣＰ制御ＰＤＵのタイプを識別するための３ビット長のタイプフィールド、
− 後続の第１の紛失した情報およびビットマップフィールドが参照する無線ベアラを識別するための無線ベアラ識別子フィールド、
− 先行する無線ベアラ識別子フィールドで識別される無線ベアラに関する、第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長のフィールド、
− オプションで、先行する無線ベアラ識別子フィールドで識別される無線ベアラを介して正確に受信された、または受信されなかった第１の紛失したＰＤＣＰ ＳＤＵから始まるＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有するビットマップフィールド、
− さらなる情報がＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示する１ビット長の拡張フラグフィールド、
を備えるＰＤＣＰ制御パケットデータユニット（ＰＤＵ）であり、
拡張フラグフィールドが、さらなる情報が含まれると指示する場合、状況報告は、
− 後続の第１の紛失した情報およびビットマップフィールドが参照する無線ベアラを識別するための別の無線ベアラ識別子フィールド、
− 先行する別の無線ベアラ識別子フィールドにおいて識別される無線ベアラに関する第１の紛失したＰＤＣＰサービスデータユニット（ＳＤＵ）のＰＤＣＰシーケンス番号を識別するための１２または１５ビット長の別のフィールド、
− オプションで、先行する別の無線ベアラ識別子フィールドにおいて識別される無線ベアラを介して正確に受信された、または受信されなかった第１の紛失したＰＤＣＰ ＳＤＵから始まるＰＤＣＰ ＳＤＵをビットマップの使用によって識別するための可変ビット長を有する別のビットマップフィールド、
さらなる情報がＰＤＣＰ制御ＰＤＵに含まれるかどうかを指示する１ビット長の別の拡張フラグフィールド、
を含む。

【0191】

上記に加えてまたは代替で使用することができる本発明の第１の実施形態の有利な一変形形態によれば、移動局の受信器は、マスタ基地局から状況報告を受信し、その状況報告は、マスタ基地局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのすべてを介してマスタ基地局によって受信されるデータパケットの受信状況の情報を含み、その情報が状況報告に含まれる少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む。

【0192】

本発明の第１の実施形態はさらに、移動局から送信される状況報告を処理するマスタ基地局を提供し、そこにおいて、移動局は、少なくとも１つの無線ベアラを介してマスタ基地局におよび少なくとも１つのデータ無線ベアラを介してソース二次基地局に接続される。マスタ基地局の受信器およびプロセッサは、ソース二次基地局から目標基地局へ移動局の少なくとも１つのデータ無線ベアラを再設定するとき、移動局から状況報告を受信し、処理する。状況報告は、移動局をソース二次基地局に接続する少なくとも１つのデータ無線ベアラのすべてを介して移動局によって受信されるデータパケットの受信状況の情報を含み、その情報が状況報告に含まれる少なくとも１つのデータ無線ベアラの各々について１つの無線ベアラ識別子を含む。

【0193】

以下、添付の図面を参照して本発明をより詳細に説明する。

【図面の簡単な説明】

【0194】

【図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】第１の実施形態の他の実装形態による強化されたＰＤＣＰ状況報告のフォーマットを示す図である。

【発明を実施するための形態】

【0195】

移動局または移動ノードは、通信ネットワーク内の物理エンティティである。１つのノードは、いくつかの機能エンティティを有することができる。機能エンティティは、ノードまたはネットワークの他の機能エンティティに所定のセットの機能を実装および／または提供するソフトウェアまたはハードウェアモジュールを示す。ノードは、それを介してノードが通信することができる通信施設またはメディアにノードを接続する１つまたは複数のインタフェースを有することができる。同様に、ネットワークエンティティは、それを介してそのネットワークエンティティが他の機能エンティティまたは対応するノードと通信することができる通信施設またはメディアに機能エンティティを接続する論理インタフェースを有することができる。

【0196】

本特許請求の範囲においておよび本発明の説明をとおして、「マスタ基地局」という用語は、３ＧＰＰ ＬＴＥ−Ａの二重接続の分野で使用されるものとして解釈されるものとし、したがって、他の用語は、マクロ基地局、またはマスタ／マクロｅＮＢ、またはサービング基地局、または３ＧＰＰによって後から決定される任意の他の用語である。同様に、本特許請求の範囲においておよび本説明をとおして、「二次基地局」という用語は、３ＧＰＰ ＬＴＥ−Ａの二重接続の分野で使用されるものとして解釈されるものとし、したがって、他の用語は、スレーブ基地局、または二次／スレーブｅＮＢ、または３ＧＰＰによって後から決定される任意の他の用語である。

【0197】

本特許請求の範囲においておよび本発明の説明をとおして、「無線ベアラ」という用語は、３ＧＰＰ専門用語に関連して解釈されるものとし、２つのエンドポイント、すなわち移動局および基地局、の間の、それらの間でデータの移送のために使用される、仮想接続を指し、その仮想接続が「ベアラサービス」、すなわち特定のＱｏＳ属性を有する移送サービス、を提供するという事実を強調する用語である。データ無線ベアラはまた、ユーザプレーン無線ベアラと呼ばれることがあり、そして、シグナリング無線ベアラはまた、制御プレーン無線ベアラと呼ばれることがある。無線ベアラは、Ｓ１ベアラ、Ｅ−ＲＡＢ、Ｓ５／Ｓ８ベアラ、ＥＰＳベアラなど、３ＧＰＰによって定義されるものとしての他の専門用語とは区別されるものとする（参照により本明細書に組み込まれている非特許文献２の図２.８も参照）。

【0198】

本特許請求の範囲においておよび本発明の説明をとおして、「受信状況」という用語は、エンティティが、どのデータパケットが既に正確に受信されたか、および、どのデータパケットがまだ正確に受信されておらず、したがって再送信を必要とするかをそこから推測することができる情報を示す。ＰＤＣＰ状況報告を参照する特定の実施形態で、受信状況は、ＰＤＣＰ ＳＤＵ、および、特に、例えば、ＰＤＣＰ受信器の最新の並べ替えバッファの状況を示す。

【0199】

本特許請求の範囲においておよび本発明の説明をとおして、「無線ベアラ識別子」という用語は、無線ベアラの識別を提供する情報を示す。

【0200】

以下、本発明のいくつかの実施形態が詳細に説明される。例示のみを目的として、実施形態の多くは、上の背景技術のセクションで部分的に論じられた、３ＧＰＰ ＬＴＥ（リリース８／９）およびＬＴＥ−Ａ（リリース１０／１１）移動体通信システムによる無線アクセス方式との関連で概要を説明される。本発明は、例えば、上の背景技術のセクションで説明したような３ＧＰＰ ＬＴＥ−Ａ（リリース１２）通信システムなどの移動体通信システムで有利には使用され得ることに留意されたい。これらの実施形態は、３ＧＰＰ ＬＴＥおよび／またはＬＴＥ−Ａにおいて特定された機能に関する使用のおよび／またはその拡張の実装形態として記載される。この点において、３ＧＰＰ ＬＴＥおよび／またはＬＴＥ−Ａの専門用語が、本明細書をとおして使用される。さらに、例示的設定が、本発明の全容を詳述するために研究されている。

【0201】

本説明は、本発明を限定するものとして理解されるべきではなく、本発明をよりよく理解するための本発明の実施形態の単なる例として理解されたい。特許請求の範囲で提示される本発明の一般原則は、異なるシナリオに、本明細書で明示的に記載されない方法で適用することができることが、当業者には理解されよう。同様に、さまざまな実施形態の説明を目的とすることを前提とする以下のシナリオは、そのようなものとして、本発明を限定しないものとする。

【0202】

第１の実施形態

【0203】

本発明の第１の実施形態に関して、さまざまな実装形態が説明される。第１の実施形態の原理の説明を簡単にするために、いくつかの想定を行うが、これらの想定は、本特許請求の範囲によって広く定義されるものとしての本出願の範囲を限定するものとして解釈されるべきではないことに、留意されたい。

【0204】

本発明の第１の実施形態が、図２５から図３１を参照して説明される。ＵＥが、ＭｅＮＢおよびＳｅＮＢの両方に接続され、ＳＧＷからＭｅＮＢに、および最終的にはＳｅＮＢを介してＵＥに転送されるデータを少なくとも受信する、すなわちＥＰＳベアラ＃２に関連する図２１ｂおよび図２１ｃに例示的に示すような、スモールセル環境における二重接続シナリオが想定されている。図のように、ＥＰＳベアラ＃２（ＵＥとＭｅＮＢとの間の無線ベアラ＃２を含む）は、無線ベアラが必要に応じて両方のｅＮＢを介して送信され得る（図２１ｃを参照）ようにＭｅＮＢで分割され得る、または、ＭｅＮＢでは分割されないが、ＥＰＳベアラ＃１から別個に転送される（図２１ｂを参照）。

【0205】

３ＧＰＰにおけるスモールセルの審議によれば、異なるユーザプレーンアーキテクチャが、図２２を参照して背景技術のセクションで説明したように、審議中である。本発明の第１の実施形態では、ＰＤＣＰ状況報告機能を有するＰＤＣＰレイヤがＭｅＮＢにあるが、ＳｅＮＢにはない、図２２ｄ、図２２ｅのユーザプレーンアーキテクチャが主として想定されていると想定される。上記に拘わらず、図２２ｈ、図２２ｉのユーザアーキテクチャでは、ＵＥとＭｅＮＢとの間に直接接続が存在し、それにより、ＳｅＮＢを介する迂回によってもたらされるバックホール遅延なしにＭｅＮＢに直接に正規のＰＤＣＰ状況報告を送信することを可能にするように、対応するＥＰＳベアラ＃２はＭｅＮＢにおいて分割されるが、第１の実施形態の以下で説明するような原理はまた、図２２ｈ、図２２ｉのユーザアーキテクチャに適用することができる。さらに、第１の実施形態の以下で説明するような原理はまた、ＰＤＣＰレイヤがＭｅＮＢとＳｅＮＢとの間に分散される図２２ｃ、図２２ｇのユーザアーキテクチャに適用することができ、これらの場合、どの特定の機能がＭｅＮＢにおいて実際に実装されることになり、どれがＳｅＮＢにおいて実装されることになるかは、現在の標準化の観点からはまだ不明確である。

【0206】

ＵＥが、ＭｅＮＢのカバレッジ下につねにありながら、あるＳｅＮＢ１のカバレッジから別のＳｅＮＢ２に移動し、それによって、これらの２つのｅＮＢの間でハンドオーバを実行する、ハンドオーバシナリオを開示する、図２５に関連した、第１の実施形態がここで説明される。図２５は、第１の実施形態の原理の説明を容易にするためにいくつかの想定を行う。特に、基本的な通信システムは、２つのＳｅＮＢ、ＳｅＮＢ１およびＳｅＮＢ２、を有するＭｅＮＢを含むと想定する。さらに、２つのみのＥＰＳベアラ＃１および＃２が存在し、ＥＰＳベアラ＃２はＭｅＮＢを介して直接ＵＥに進み、そして、ＥＰＳベアラ＃１は、ＭｅＮＢおよびＳｅＮＢ１を介してＵＥに遠回りに進む、と想定する。それに対応して、ＳｅＮＢ１を介して進むＥＰＳベアラ＃１の部分のみ移動し、ハンドオーバを実行するとき、この特定の場合に、ＵＥとＳｅＮＢ１との間の無線ベアラ＃１（ＥＰＳベアラ＃１の一部である）は、目標ＳｅＮＢ２に再マップされなければならない。データ無線ベアラは、既に前述したようにＲＬＣ ＡＭについて設定されることに留意されたい。

【0207】

もちろん、図２５（および他の図）の例示的シナリオは、単に、合計で２つのＥＰＳベアラを想定するが、ＵＥ、ＭｅＮＢおよびＳｅＮＢの間にそれぞれより多数のベアラが確立されることがあり、本発明の第１の実施形態は、これらにも適用される。

【0208】

ＵＥは、大概はＭｅＮＢによって決定されるハンドオーバを最終的に実行することになると想定される。それに対応して、ＭｅＮＢ（ＳｅＮＢとは違い、ＵＥへのＲＲＣ接続を有するものとしての）は、図２７、図２８および図２９に示すように、ＲＲＣ接続再設定メッセージを送信することによって、通常の方式で切迫したハンドオーバに関してＵＥに知らせることになる（図１５に関する説明も参照）。第１の実施形態の例示的一実装形態で、ＵＥは、以下のような情報を含む、ＰＤＣＰ状況報告をまず編集して次に送信することのトリガーとしてＲＲＣ接続再設定メッセージを受け取る。第１の実施形態の例示的一実装形態によれば、指示、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎを含んでいない。ＳｅＮＢの変更（ソースＳｅＮＢから目標ＳｅＮＢに）の手続きおよび関連するシグナリングは、キャリアアグリゲーションの範囲内のＳセルの変更（解放および追加）の手続きと同様の本例示的実装形態による。しかし、別の（個別の）トリガーメッセージ（ＲＲＣＣｏｎｎ．Ｒｅｃｏｎｆ．メッセージではない）もまた、強化されたＰＤＣＰ状況報告をトリガーするために、ＭｅＮＢによって使用され得ることに、留意されたい。

【0209】

それに対応して、ＵＥのＰＤＣＰレイヤは、必要な情報を集め、第１の実施形態の強化されたＰＤＣＰ状況報告を準備する。ＰＤＣＰ受信器は、ＲＣＬ再確立の結果として受信されたＰＤＣＰ ＰＤＵを処理し、再構築されたＰＤＣＰ ＳＤＵを並べ替えバッファに記憶する。移動端末によって生成されるＰＤＣＰ状況情報は、ベアラの最新の並べ替えバッファの状況を表す。ＵＥからＭｅＮＢに送信されることになる関連情報は、特定のデータ無線ベアラ（この場合、ＳｅＮＢを介して進むデータ無線ベアラ）を参照する、通常のＰＤＣＰ状況報告、すなわちＦＭＳおよび（オプションで）１つまたは複数のビットマップオクテット、にあるのと基本的に同じ情報である。しかし、第１の実施形態の強化されたＰＤＣＰ状況報告は、ＳｅＮＢ１を介して進むすべてのデータ無線ベアラを参照するものとし、１つのみの無線ベアラが存在する（図２５および図２６で想定される例示的シナリオにおけるように）場合にも、強化されたＰＤＣＰ状況報告のフォーマットは、これをそれまでに考慮するものとする。したがって、１つのデータ無線ベアラからの状況報告情報（ＦＭＳ、ビットマップ）を別のデータ無線ベアラの強化されたＰＤＣＰ状況情報からの状況報告情報（ＦＭＳ、ビットマップ）と区別するために、無線ベアラＩＤが、その状況報告情報が関連する対応する無線ベアラを識別するために含まれ、そして、別のデータ無線ベアラの状況報告情報が続くかどうかを示す拡張フラグが含まれる。図３０は、第１の実施形態のそのような強化されたＰＤＣＰ状況報告のフォーマットを例示的に示す。理解されるように、本例では、ＲＢ ＩＤには、先行するＲＢ ＩＤフィールドによって識別されるデータ無線ベアラのデータフィールドＦＭＳが続き、さらに、１つまたは複数の対応する（オプションの）ビットマップが、そして、最後に拡張フラグが続く。拡張フラグが、さらなる状況報告情報の存在を示す場合、ＲＢ ＩＤのフォーマット、ＦＭＳおよびオプションでビットマップが、ｅＮＢに再マップされるものと同じ数の無線ベアラについて繰り返される。強化されたＰＤＣＰ ＳＲ内のフィールドの順番は、図３０および図３１に例示的に示すものと異なってもよい。

【0210】

現在、無線ベアラは、５ビットによって識別され、それにより３２までの異なる無線ベアラの区別を可能にすることに留意されたい。それに対応して、第１の実施形態の強化されたＰＤＣＰ状況報告内のＲＢ ＩＤフィールドもまた５ビットでもよいが、ＲＢ ＩＤフィールドはまた、任意の他の数のビット長（例えば、２、３、４、６、７、８など）でもよいことに留意されたい。

【0211】

以下に説明するように、ＵＥによって実行されることになる特定のステップに影響を及ぼす、第１の実施形態の強化されたＰＤＣＰ状況情報を送信する方法には異なる可能性が存在する。説明を目的として、これは現時点では区別されないが、後で詳細に説明される。あえて言うならば、前述のように、ＵＥは、対応するトリガーをＭｅＮＢから受信したときに、強化されたＰＤＣＰ状況報告を準備し、その強化されたＰＤＣＰ状況報告は、対応するＲＢ識別子をそれぞれ伴う目標ｅＮＢ（本例ではＳｅＮＢ２）に再マップされることになるＳｅＮＢ１を介して進むすべてのデータ無線ベアラ（本例では無線ベアラ＃１のみ）の状況報告情報を少なくとも含む。

【0212】

強化されたＰＤＣＰ状況報告は、次いで、ＭｅＮＢに直接に（詳細は後で説明する、例えば図２６を参照）または目標ＳｅＮＢ２を介して（図２５を参照）のいずれかでＭｅＮＢに送信される。いずれの場合にも、マクロｅＮＢ（ＰＤＣＰレイヤを有する）は、強化されたＰＤＣＰ状況報告を受信することになり、そこから、ハンドオーバの前にＵＥに既に無事に送信することができたまたは送信することができなかったＰＤＣＰ ＳＤＵを正確に推測することができる。受信されたＰＤＣＰ状況報告に基づいて、ＭｅＮＢは、ＵＥにさらに再送信されることになる、確認応答されていないＰＤＣＰ ＳＤＵ／ＰＤＵのみをＳｅＮＢ２に転送することになる。それに対応して、ハンドオーバの前にＵＥによって実際には無事に受信されなかったそれらのＰＤＣＰ ＳＤＵのみが、ＵＥに実際に再送信されるので、ＵＥの無損失のハンドオーバ手続きは、より効率的に行われ得る。

【0213】

第１の実施形態のより有利な一実装形態によれば、以下に説明するように、さらなる問題が解決される。無線ベアラのＰＤＰＣ状況報告は、ＰＤＣＰ制御ＰＤＵであり、したがって、ＭＡＣの観点から、無線ベアラの「正規のデータ」として扱われるので、ＵＥは、既に上記で説明されたように、次にＭｅＮＢにＰＤＣＰ状況報告を転送することになるＳｅＮＢ２に（ＳｅＮＢ変更の後に）ＰＤＣＰ状況報告を送信することになる（先行技術によれば）。詳細には、ＭＡＣにおける論理チャネル優先順位付け（ＬＣＰ）手続きは、ＳｅＮＢを介してマップされた無線ベアラのデータが、アップリンクでＳｅＮＢにのみ送信されることを確保することになる、すなわち、アップリンクにおいてＭｅＮＢに直接にＳｅＮＢにマップされた無線ベアラのデータを送信する可能性はない。しかし、これは、ＰＤＣＰ状況報告の利得を大きく低下させ、バックホール（すなわちＳｅＮＢとＭｅＮＢとの間のインタフェース）の、場合により長い遅延による問題を引き起こす。背景技術のセクションで説明したように、ＭｅＮＢとＳｅＮＢとの間のバックホールは、遅くなることがあり、一方向レイテンシは、大きい、例えば６０ｍｓ、ことがある。バックホールの６０ｍｓ遅延を想定すると、ＰＤＣＰ状況報告は、ＭｅＮＢでのＳｅＮＢ変更の後でどこかにおいて８０ｍｓで受信されることになる（ＵＥからＳｅＮＢへの送信のスケジューリング遅延が考慮される場合）。送信される必要があるＰＤＣＰ ＰＤＵがＳｅＮＢで受信されるまでに、さらに６０ｍｓを要することになる。

【0214】

したがって、第１の実施形態のこのより有利な実装形態によれば、強化されたＰＤＣＰ状況報告（上記で説明したような）は、ＳｅＮＢを介するのではなくて、ＭｅＮＢに直接に送信されるものとする。異なる無線ベアラが、移送、別の基地局に再マップされず、それによりＳｅＮＢ変更中にも使用することができる無線ベアラ、のために使用されるので、これは、ＳｅＮＢ変更が完了する前でも、強化されたＰＤＣＰ状況報告が送信され得るという利点も有する。これは、図２６に例示的に示される。

【0215】

これは、いくつかの方法で、すなわち、シグナリング無線ベアラを介して、データ無線ベアラを介してまたはＭＡＣ制御要素を介して、達成することができる。

【0216】

強化されたＰＤＣＰ状況報告が、ＵＥからシグナリング無線ベアラを介してＭｅＮＢに直接に送信される場合、ＵＥは、同じものを任意のＲＲＣメッセージにピギーバックし、同じものをＭｅＮＢに送信することができる。それに対応して、例えば、強化されたＰＤＣＰ状況報告が終了した直後に、ＵＥ（特に、それのＲＲＣレイヤ）は、ＲＲＣメッセージ（好ましくは短い）を準備し、それが、対応するＳＲＢを介して通常の方式でＭｅＮＢにＵＥによって送信される前に、強化されたＰＤＣＰ状況報告メッセージをＲＲＣメッセージに追加する（または、他の方法で含める）ことができる。

【0217】

別の例示的実装形態で、ＲＲＣ接続再設定完了メッセージは、第１の実施形態の強化されたＰＤＣＰ状況報告を運ぶために、ＵＥによって再使用され得る。これは、以下の説明で例示的に想定されているハンドオーバ手続きの一部を開示する、図２９に示される。図２９は、図１５で説明および図示されるものとしてのハンドオーバ手続きの編集された抜粋であることが、理解されよう。ＳｅＮＢ変更のために３ＧＰＰによって決定されるものとしてのハンドオーバ手続きは、図１５に関連して現在定義および説明されているものとしてのハンドオーバ手続きと同様であると、例示のみを目的として想定する。例えば、移動制御機能はＭｅＮＢにあり、すなわち、ＭｅＮＢがＳｅＮＢ変更のような移動事象に関して決定し、それにより、ＵＥにＲＲＣ接続再設定メッセージ（強化されたＰＤＣＰ状況報告を準備し、次いで送信するためのトリガーとして、ＵＥによって使用されるまたはされないことがある）を送信することになると想定する。これはまだ３ＧＰＰの議論の俎上にあるが、ランダムアクセス手続きは、ＵＥとｔｇｔ ＳｅＮＢとの間で実行されることになるとさらに想定する。同様に、ＲＲＣ接続再設定完了メッセージは、ＲＲＣレイヤの他方のエンドポイントとしてのＭｅＮＢにＵＥによって送信されると想定する。同想定は、図２７および図２８のシナリオおよび実装形態にも適用される。これらのすべては、単に想定であり、上記で説明したような第１の実施形態の上位概念を制限するものではないことに留意されたい。

【0218】

図２９に戻ると、そこからわかるように、強化されたＰＤＣＰ状況報告は、ＲＲＣ接続再設定完了メッセージ（ステップ１１）の一部としてＭｅＮＢに送信される。図３１は、強化されたＰＤＣＰ ＳＲの関連情報のフォーマットを示す。しかし、これは、データ転送（ステップ８）がＭｅＮＢと目標ＳｅＮＢとの間で実行された後に生じ、ＰＤＣＰ ＳＤＵ／ＰＤＵもまた、目標ＳｅＮＢに転送されてあることがあり、これは、後で受信される強化されたＰＤＣＰ状況報告によれば、ＳｅＮＢ変更の前に正確に受信したことによりＵＥでは必要とされないことになる。目標ＳｅＮＢがこれらの不必要なＰＤＣＰ ＳＤＵ／ＰＤＵをＵＥに再送信することを回避することをなお可能にするために、目標ＳｅＮＢが、次に、ＭｅＮＢによって転送されるＰＤＣＰ ＰＤＵのうちのどれがＳｅＮＢ変更の後にＵＥに再送信される必要がないかを推測することができるように、ＭｅＮＢは、例えば、目標ＳｅＮＢにＰＤＣＰ状況報告を転送することもできる。

【0219】

強化されたＰＤＣＰ状況報告がＵＥからデータ無線ベアラを介してＭｅＮＢに直接に送信される場合、これは、例えば、正規のＰＤＣＰ ＳＲを運ぶＰＤＣＰ制御ＰＤＵ（図１３、図１４を参照）と同様に、ＰＤＣＰ制御ＰＤＵとして行うことができる。前記を目的として、第３のＰＤＣＰ制御ＰＤＵタイプが、正規のＰＤＣＰ ＳＲとは異なるものとして第１の実施形態に関連して上記で論じられたような強化されたＰＤＣＰ状況報告を識別することになる対応する新しいＰＤＵタイプＩＤとともに導入され得る（既に定義された２つのＰＤＣＰ制御ＰＤＵタイプ、すなわち正規のＰＤＣＰ ＳＲおよびＲＯＨＣフィードバック、とは別に）。強化されたＰＤＣＰ ＳＲのこの第３のＰＤＣＰ制御ＰＤＵタイプのフォーマットの一例は、図３０に示される。

【0220】

強化されたＰＤＣＰ ＳＲを運ぶＰＤＣＰ制御ＰＤＵの送信は、図２７に示される。図示するように、ＭｅＮＢが、既に正確に受信されたＰＤＣＰ ＳＤＵ／ＰＤＵの強化されたＰＤＣＰ ＳＲ内の情報をそれまでに考慮し、それにより目標ＳｅＮＢにこれらを転送するのを避けることができるように、強化されたＰＤＣＰ ＳＲを有するＰＤＣＰ制御ＰＤＵは、ＭｅＮＢによるデータ転送がステップ８で実行される前に、送信することができる。それにより、不必要なデータの再送信は、ＭｅＮＢと目標ＳｅＮＢとの間でならびに目標ＳｅＮＢとＵＥとの間の無線インタフェースで回避される。

【0221】

強化されたＰＤＣＰ状況報告がＭＡＣ制御要素としてＵＥから送信される場合、その状況情報が送信されるべきＵＥ内のＰＤＣＰエンティティは、その状況情報に関してＭＡＣレイヤに知らせる必要がある。このレイヤ間通信は、プリミティブによって行うことができる。ＭＡＣレイヤは、次いで、前記強化されたＰＤＣＰ状況情報を有する対応するＭＡＣ制御要素を生成し、ＭｅＮＢに直接にそのＭＡＣ ＣＥを送信することになる。ＭｅＮＢは、そのＭＡＣ ＣＥを受信し、さらなる処理のためにそれのＰＤＣＰレイヤにそのＭＡＣ ＣＥ内の強化されたＰＤＣＰ ＳＲの情報を転送する。ＭＡＣ ＣＥの内容は、図３１に示され、強化されたＰＤＣＰ ＳＲがＲＲＣメッセージとピギーバックされる場合と基本的に同一である。

【0222】

ハンドオーバ手続きの文脈でのＭＡＣ ＣＥの送信が、図２８に例示的に示される。前に図２７に関連して既に説明したように、強化されたＰＤＣＰ ＳＲを有するＭＡＣ ＣＥは、それを編集したときに直ちに送信することができ、したがって、ＭｅＮＢがステップ８のデータ転送を実行する前に、ＭｅＮＢによって受信され得る。したがって、やはり、ＭｅＮＢは、既に正確に受信されたＰＤＣＰ ＳＤＵ／ＰＤＵの強化されたＰＤＣＰ ＳＲ内の情報をそれまでに考慮することができ、それによって、目標ＳｅＮＢにこれらを転送するのを回避することができる。したがって、不必要なデータの再送信は、ＭｅＮＢと目標ＳｅＮＢとの間でならびに目標ＳｅＮＢとＵＥとの間の無線インタフェースで回避される。

【0223】

第２の実施形態

【0224】

本発明の第２の実施形態によれば、ＰＤＣＰ状況報告によって起こるバックホール遅延の問題はまた、以下に説明するように異なるように解決することができる。

【0225】

前述のように、移動事象（ソースＳｅＮＢから目標ＳｅＮＢへのＳｅＮＢ変更など）でのＰＤＣＰ状況報告の遅延問題は、ＰＤＣＰ状況報告が、現在のＬＴＥ仕様によれば、ＰＤＣＰ状況情報が関連する無線ベアラを介して送信されるという事実から生じる。ＳｅＮＢの場合、それは、ＰＤＣＰ状況報告が、ＳｅＮＢ変更が行われた後で、受信されたＰＤＣＰ状況報告を次いでＭｅＮＢに（ＰＤＣＰレイヤはＭｅＮＢ内にあるので）転送する目標ＳｅＮＢに送信されることになることを意味する。

【0226】

ＳｅＮＢ変更などの移動事象でのＰＤＣＰ状況報告の遅延を減らすために、ＳｅＮＢとＵＥとの間に設定され、したがって、ＳｅＮＢ変更中に再設定される無線ベアラは、本実施形態のいくつかの例示的実装形態によれば、ＳｅＮＢ変更手続き中にＭｅＮＢとＵＥとの間で一時的に設定される。言い換えれば、一時的な期間、ソースＳｅＮＢとＵＥとの間で設定された無線ベアラは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの受信時に（ＳｅＮＢ）、目標ＳｅＮＢとＵＥとの間に次いで最終的に設定される前に、限られた期間にＭｅＮＢに最初に再マップされる（すなわち、ＭｅＮＢとＵＥとの間に設定される）。無線ベアラが一時的にＭｅＮＢにマップされる、この一時的期間中に、ＵＥは、対応する無線ベアラのＰＤＣＰ状況報告情報をＭｅＮＢに直接に送信する。ＰＤＣＰ状況報告は、ＭｅＮＢに一時的にマップされるそれぞれの無線ベアラでＰＤＣＰ制御ＰＤＵとして送信することができる。この第２の実施形態によれば、ＰＤＣＰ状況報告によって起こる遅延は、大幅に減らすことができる。特に、ＰＤＣＰ状況情報は、ＭｅＮＢによってそれまでに考慮することができるので、目標ＳｅＮＢへの不必要なＰＤＣＰ ＰＤＵの転送は、回避することができる。

【0227】

第３の実施形態

【0228】

本発明の第３の実施形態によれば、ＥＰＳベアラが図２２ｈ、図２２ｉに示すようにＭｅＮＢとＳｅＮＢとの間で分割されるユーザプレーンアーキテクチャのＰＤＣＰ状況報告が説明される。ＥＰＳベアラ＃２のパケット（図２２ｈ、図２２ｉの）は、ＭｅＮＢを介して、そしてまたＳｅＮＢを介して、直接送信することができるので、ＰＤＣＰ状況報告のようなアップリンクにおける制御情報報告のＵＥ動作は、制御情報がＭｅＮＢに直接報告されるものとする、本実施形態によることになる。本実施形態のいくつかの例示的実装形態によれば、ＭＡＣにおける論理チャネル優先順位付け手続きは、直接のＭｅＮＢへのＰＤＣＰ状況報告の送信をスケジュールすることになる。これは、ＰＤＣＰ制御情報が、ＳｅＮＢを介する迂回によってもたらされるバックホール遅延なしに、ＭｅＮＢで受信されることを実現する。ＰＤＣＰ状況情報と同様に、ＲＬＣ状況報告のような他の無線ベアラ特定の制御情報もまた、ＭｅＮＢに直接に送信されることになる、すなわち、これはＬＣＰ手続きによって管理される。

【0229】

本発明のハードウェアおよびソフトウェア実装

【0230】

本発明の他の実施形態は、ハードウェアおよびソフトウェアを用いて、上記したさまざまな実施形態を実施することに関する。これに関連して、本発明は、ユーザ機器（移動端末）およびｅＮｏｄｅＢ（基地局）を提供する。ユーザ機器は、本発明の方法を実行するようにされている。

【0231】

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

【0232】

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

【0233】

さらには、本発明の複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の本発明の主題とすることができることに留意されたい。

【0234】

具体的な実施形態に示した本発明には、広義に記載されている本発明の概念または範囲から逸脱することなく、さまざまな変更もしくは修正またはその両方を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限するものではないものとみなされる。

【図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】