(57)【特許請求の範囲】
【請求項１】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化する方法であって、
ゲートウェイとのユーザ専用トンネル接続を介して、前記複数のユーザ端末の１つに対する配信のための、トンネリングヘッダを含むトンネリングパケットとカプセル化されたデータパケットとを受信するステップと、
前記トンネリングパケットから前記データパケットをカプセル解除するステップと、
前記データパケットのヘッダを圧縮するステップと、
前記トンネリングヘッダのトンネル識別子から、前記データパケットが向けられているユーザ端末を判定するステップと、
前記ユーザ端末に対するユーザ専用トンネルを介する多重化バックホール無線ベアラを介して、前記圧縮されたヘッダを有する前記データパケットを前記ドナー基地局から前記リレーへ転送するステップと、
前記リレーへの送信の前に、前記ユーザ端末を該リレーが識別することを可能にするために、ユーザ専用識別子を前記データパケットのヘッダに挿入するステップと
を有することを特徴とする方法。
【請求項２】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化する方法であって、
ドナー基地局によって、多重化バックホール無線ベアラを介してリレーから圧縮されたヘッダを有するデータパケットを受信するステップと、
前記データパケットのヘッダを解凍するステップと、
前記ヘッダに含まれるユーザ専用識別子から、前記データパケットが向けられているユーザ端末を判定するステップと、
トンネリングパケットで前記データパケットをカプセル化し、前記ユーザ端末に対応するユーザ専用トンネルを介して、前記圧縮されたヘッダを有する前記トンネリングパケットをゲートウェイへ転送するステップと
を有することを特徴とする方法。
【請求項３】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化する方法であって、
前記リレーによって、前記複数のユーザ端末の１つからデータパケットを受信するステップと、
前記データパケットのヘッダを圧縮するステップと、
前記データパケットが向けられているユーザ端末を識別可能にするために、ユーザ専用識別子を前記データパケットのヘッダに挿入するステップと、
多重化バックホール無線ベアラにおけるトンネルを通じて、１つ以上の無線リンクプロトコルパケットで、前記圧縮されたヘッダを有する前記データパケットを前記リレーからドナー基地局へ転送するステップと
を有することを特徴とする方法。
【請求項４】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化する方法であって、
前記リレーによって、多重化バックホール無線ベアラにおけるトンネルを通じて、前記複数のユーザ端末の１つへ配信するための、圧縮されたトンネリングヘッダを有するデータパケットをドナー基地局から受信するステップと、
前記トンネリングヘッダを解凍するステップと、
前記ドナー基地局によって、前記トンネリングヘッダに挿入されているユーザ専用識別子から、前記データパケットが意図されているユーザ端末を判定するステップと、
前記ユーザ端末に対応するユーザ専用トンネルを判定するステップと、
前記ユーザ端末に対応するユーザ専用トンネルを介して、前記解凍されたデータパケットを前記ユーザ端末へ転送するステップと
を有することを特徴とする方法。
【請求項５】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化するためのドナー基地局であって、
処理回路と、
無線トランシーバとを備え、
前記処理回路は、
ゲートウェイとのユーザ専用トンネル接続を介して、前記複数のユーザ端末の１つに対する配信のための、トンネリングヘッダを含むトンネリングパケットとカプセル化されたデータパケットとを受信し、
前記トンネリングパケットから前記データパケットをカプセル解除し、
前記データパケットのヘッダを圧縮し、
前記トンネリングヘッダのトンネル識別子から、前記データパケットが向けられているユーザ端末を判定し、
前記ユーザ端末に対するユーザ専用トンネルを介する多重化バックホール無線ベアラを介して、前記圧縮されたヘッダを有する前記データパケットを当該ドナー基地局から前記リレーへ転送し、
前記リレーへの送信の前に、前記ユーザ端末を該リレーが識別することを可能にするために、ユーザ専用識別子を前記データパケットのヘッダに挿入する
ように構成されているドナー基地局。
【請求項６】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化するためのドナー基地局であって、
処理回路と
無線トランシーバとを備え、
前記処理回路は、
多重化バックホール無線ベアラを介してリレーから圧縮されたヘッダを有するデータパケットを受信し、
前記データパケットのヘッダを解凍し、
前記ヘッダに含まれるユーザ専用識別子から、前記データパケットが向けられているユーザ端末を判定し、
トンネリングパケットで前記データパケットをカプセル化し、前記ユーザ端末に対応するユーザ専用トンネルを介して、前記圧縮されたヘッダを有する前記トンネリングパケットをゲートウェイへ転送する
ように構成されている
ことを特徴とするドナー基地局。
【請求項７】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化するためのリレーであって、
無線トランシーバと、
ネットワークインタフェースと、
処理回路とを備え、
前記処理回路は、
前記複数のユーザ端末の１つからデータパケットを受信し、
前記データパケットのヘッダを圧縮し、
前記データパケットが向けられているユーザ端末を識別可能にするために、ユーザ専用識別子を前記データパケットのヘッダに挿入し、
多重化バックホール無線ベアラにおけるトンネルを通じて、１つ以上の無線リンクプロトコルパケットで、前記圧縮されたヘッダを有する前記データパケットを当該リレーからドナー基地局へ転送する
ように構成されている
ことを特徴とするリレー。
【請求項８】
マルチホップ通信システムにおけるドナー基地局とリレーとの間のバックホール上の単一の無線ベアラを介して、複数のユーザ端末に対するデータパケットを多重化するためのリレーであって、
無線トランシーバと、
ネットワークインタフェースと、
処理回路とを備え、
前記処理回路は、
多重化バックホール無線ベアラにおけるトンネルを通じて、前記複数のユーザ端末の１つへ配信するための、圧縮されたトンネリングヘッダを有するデータパケットをドナー基地局から受信し、
前記トンネリングヘッダを解凍し、
前記ドナー基地局によって、前記トンネリングヘッダに挿入されているユーザ専用識別子から、前記データパケットが意図されているユーザ端末を判定し、
前記ユーザ端末に対応するユーザ専用トンネルを判定し、
前記ユーザ端末に対応するユーザ専用トンネルを介して、前記解凍されたデータパケットを前記ユーザ端末へ転送する
ように構成されている
ことを特徴とするリレー。
【発明の詳細な説明】
【背景技術】
【０００１】
マルチホップ通信の導入は、ＬＴＥネットワークの通信範囲及び容量を改善するために、ロングタームエボリューション（ＬＴＥ）システムに対して提案されている。マルチホップセルラーシステムでは、基地局とユーザ端末（ＵＴ）との間の通信は、追加の中間ノード群の支援を伴うマルチホップを行うことができる。中間ノードには様々なタイプが存在する。リピータは、受信する信号を増幅することによってレイヤ１上で動作する。リレーは、転送前に受信したトランスポートブロックをデコードし、必要な場合、レイヤ２上で動作するＨＡＲＱ再送信をリクエストする。セルフバックホール処理（self-backhauling）は、ＬＴＥネットワークの通信範囲とデータ速度を改善するために、レイヤ３上でのリレー処理技術である。用語「リレー（relay）」と「リレー処理（relaying）」は、ここではそれぞれ、特に示さない限り、レイヤ２とレイヤ３上でのリレー処理の両方を指すために使用される。
【０００２】
リレー処理が配備される場合、複数のユーザ端末からのパケットが共通のバックホール無線ベアラにマッピングされる。このバックホール無線ベアラは、基地局（ｅＮＢ）とリレーとの間の多くのユーザ端末に対するトラフィックを搬送する。基地局とリレーとの間のバックホールリンク上で多重化することをユーザに可能にするためには、パケットが到達したら、リレーが、受信したパケット群をダウンリンク方向の正規のユーザに対して配信する必要がある。基地局とリレーとの間にトンネリングが配備される場合、ユーザベアラが、パケットのＧＴＰ−ｕヘッダから識別される。この方法の欠点は、無線リソース上の不必要なオーバヘッドを作成するバックホールリンク上でヘッダが送信されなければならないことである。また、既存のヘッダ圧縮メカニズム、例えば、ロバストヘッダ圧縮（ＲｏＨＣ）メカニズムは、ＧＴＰトンネリングによるオーバヘッドを削減するために適用することができない。ＧＴＰ−ｕヘッダとそれに関連するＵＴＰ／ＩＰヘッダによるオーバヘッドは、不十分な無線リソースの不必要な消費を招くことになる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、ＬＴＥリレー処理（レイヤ２とレイヤ３）に対するオーバヘッドを削減する、ユーザ端末とベアラの識別用の方法及び装置に関するものであり、これは、バックホールリンク上の無線リソースを節約することになる。オーバヘッドの削減は、ＧＴＰ−ｕヘッダとそれに関連するヘッダとを使用することに比べて、ユーザ端末とベアラの識別に対してより効率的なメカニズムを提供することによって達成される。
【課題を解決するための手段】
【０００４】
実施形態の１つでは、ユーザ端末とベアラの識別情報が、無線リンクのＵＰプロトコルレイヤ（ＰＤＣＰ、ＲＬＣ及びＭＡＣ）で、ユーザ端末と無線ベアラの識別子をシグナリングすることによって実現される。この実施形態では、ＧＴＰ−ｕヘッダとそれに関連するＵＤＰ／ＩＰヘッダを完全に削除し、かつバックホールリンク上での直接、エンドユーザＩＰパケットのヘッダ圧縮を許容することができる。
【０００５】
第２の実施形態では、ユーザ端末とベアラの識別情報は、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤより上位の無線リンク内の追加のＵＰプロトコルレイヤを導入することによって実現される。このパケットデータコンバージェンスプロトコル（ＰＤＣＰ）レイヤは、不必要なＧＴＰヘッダとそれに関連するＵＤＰ／ＩＰヘッダに関連するオーバヘッドを削減するために、それらのヘッダを専用のベアラアイデンティティフィールドに置換する。このプロトコルレイヤも、エンドユーザパケットのヘッダを圧縮することができる、あるいは、それらは、ヘッダ圧縮を通じて透過的にベアラアイデンティティフィールドを渡すことができるということを想定するバックホールリンクのＰＤＣＰレイヤによって圧縮することができる。
【０００６】
第３の実施形態では、ユーザ端末とベアラの識別情報は、エンドユーザＩＰパケットを圧縮することになるＧＴＰトンネル内にヘッダ圧縮レイヤを導入することによって実現される。この実施形態では、ＧＴＰ−ｕヘッダとそれに関連するＵＤＰ／ＩＰヘッダを使用することができ、また、全体のプロトコルオーバヘッドは、特に、ＵＤＰ／ＩＰレイヤのヘッダ圧縮がバックホールリンク上で使用される場合に、特に低くなる。
【図面の簡単な説明】
【０００７】
【図１】例示のマルチホップ通信システムを示す図である。
【図２】マルチホップ通信システム用の例示のプロトコルアーキテクチャを示す図である。
【図３】ユーザ専用ベアラ情報が、ＰＤＣＰ、ＲＬＣあるいはＭＡＣレイヤのような無線リンクプロトコルレイヤ内に含まれる場合の、マルチホップ通信システム用の例示のプロトコルアーキテクチャを示す図である。
【図４】ユーザ専用ベアラ情報が、ＰＤＣＰレイヤより上位のプロトコルレイヤに含まれる場合の、マルチホップ通信システム用の例示のプロトコルアーキテクチャを示す図である。
【図５】ユーザ専用ベアラ情報が、ドナー基地局とリレーとの間のＧＴＰトンネル内のヘッダ圧縮レイヤ内に含まれる場合の、マルチホップ通信システム用の例示のプロトコルアーキテクチャを示す図である。
【図６】ベアラ識別情報をダウンリンクパケットに挿入し、かつリレーによってユーザ端末へ送信するためのリレーへそのダウンリンクパケットを転送するための、マルチホップ通信システムにおけるドナー基地局によって実現される例示の手順を示す図である。
【図７】リレーから受信されるアップリンクパケットをマッピングし、かつコアネットワーク内のサービングゲートウェイへ転送するための、マルチホップ通信システムにおけるドナー基地局によって実現される例示の手順を示す図である。
【図８】ベアラ識別情報をアップリンクパケットに挿入し、かつコアネットワークのサービングゲートウェイへの送信のためのドナー基地局へそのアップリンクパケットを転送するための、マルチホップ通信システムにおけるリレーによって実現される例示の手順を示す図である。
【図９】ドナー基地局から受信されるダウンリンクパケットをユーザ端末へ転送するための、マルチホップ通信システムにおけるリレーによって実現される例示の手順を示す図である。
【図１０】ダウンリンクパケットを圧縮し、かつリレーによるユーザ端末への送信のためのリレーへ転送するための、マルチホップ通信におけるドナー基地局によって実現される例示の手順を示す図である。
【図１１】リレーから受信されるアップリンクパケットを解凍し、コアネットワーク内のサービングゲートウェイへ転送するための、マルチホップ通信システムにおけるドナー基地局によって実現される例示の手順を示す図である。
【図１２】アップリンクパケットを圧縮し、サービングゲートウェイへの送信用のドナー基地局へ転送するための、マルチホップ通信システムにおけるリレーによって実現される例示の手順を示す図である。
【図１３】ドナー基地局から受信されるダウンリンクパケットを解凍し、かつユーザ端末へ転送するための、マルチホップ通信システムにおけるリレーによって実現される例示の手順を示す図である。
【図１４】マルチホップ通信システム用の例示のドナー基地局とリレーを示す図である。
【発明を実施するための形態】
【０００８】
図１は、セルフバックホールリレー処理を配備する、参照番号１０によって示される例示の通信ネットワーク１０を示している。通信ネットワーク１０は、コアネットワーク１４と無線アクセスネットワーク１６とを備えている。コアネットワーク１４は、サービングゲートウェイノード（Ｓ−ＧＷ）１５を含み、これは、インターネットのようなパケットデータネットワークとの接続を提供する。Ｓ−ＧＷ１５は、通信ネットワーク１０内で動作するユーザ端末２０に対するトラフィックを転送する。無線アクセスネットワーク１６は、通信ネットワーク１０の各セル１２の無線通信範囲を提供する複数の基地局１８を備えている。図では２つの基地局１８が示されていて、１つは、セルフバックホール用の基地局あるいはいくつかの他のタイプのリレー処理デバイスであり、本明細書では、リレー１８ａと示している。もう１つは、ドナー基地局１８ｂである。リレー１８ａは、ドナー基地局１８ｂを介してコアネットワーク１４に無線で接続されている。リレー１８ａとドナー基地局１８ｂとの間のバックホールリンクのために使用される無線技術は、ユーザ端末２０との通信用に使用される無線技術と同一の無線技術に基づいていて、可能であれば、バックホールアプリケーション用に最適化するためにいくつかの追加の拡張を伴っている。例として、ドナー基地局１８ｂとリレー１８ａがセル内のユーザ端末２０と通信するためにＬＴＥ無線アクセスを使用する場合に、ＬＴＥベースの無線リンクあるいは少なくともＬＴＥと同等の無線リンクは、セルフ−バックホールリンクに対しても使用されるべきである。
【０００９】
本発明は、アップリンク通信とダウンリンク通信の両方に対して、ドナー基地局１８ｂを介してリレー１８ａによってサービスが提供されるユーザ端末２０を識別する方法を提供する。図２は、エンドツーエンドプロトコルスタックの一例を示していて、ここでは、ドナー基地局１８ｂは、コアネットワーク１４からリレー１８ａを隠蔽している。つまり、リレー１８ａによってサービスが提供されるユーザ端末１２は、ネットワーク１０の残りの部分から、ドナー基地局１８ｂを介して直接サービスが提供されるように見える。ダウンリンク（ＤＬ）送信は、図２の右から左へと進むことができる。ユーザ端末２０に対するダウンリンクパケットは、まず、コアネットワーク１４のサービングゲートウェイ（Ｓ−ＧＷ）１５からドナー基地局１８ｂ（ダウンリンク）へトンネルされるとみることができる。これは、Ｓ−ＧＷ１５は、ユーザ端末２０が基地局１８ｂに接続されているとみなすからである。ここで、ユーザ端末のベアラ毎に１つのＧＴＰトンネルが存在する。
【００１０】
パケットをユーザ端末２０へ転送するためのドナー基地局１８ｂに対する最も直接的な方法は、１対１のマッピングを用いて、着信ＧＴＰトンネルをリレー１８ａへ向かう発信ＧＴＰトンネルへ変換することである。即ち、バックホールリンク上でユーザ端末のベアラ毎に１つのＧＴＰトンネルが存在する。基地局１８ｂは、パケットを共通のバックホール無線ベアラへマッピングする。即ち、複数のユーザ端末２０のパケットはバックホールリンク上の同一の無線ベアラへ送信される。ここで、異なるＱｏＳクラスに対して複数のバックホール無線ベアラが存在していていも良い。パケットがリレー１８ａへ到達した後、リレー１８ａは、ＧＴＰトンネルＩＤ（ＴＥＩＤ）に基づいて、リレー１８ａとユーザ端末２０との間のリンク上の対応するユーザ端末の無線ベアラにパケットをマッピングする。
【００１１】
図２に示されるプロトコルアーキテクチャが本発明を理解するための基礎を提供する一方で、当業者は、記載される原理がセルフ−バックホールプロトコルアーキテクチャの他の実装にも適用可能であることを理解するであろう。本発明は、一般的には、任意の代替構成にも適用することができる。この代替構成では、トナー基地局１８ｂが着信バケットに属するユーザ端末のベアラを識別することができる。この識別を実行するために、図２に示されるように、ＳＧＷ１５から発生し、個々のユーザ端末のベアラに属するＧＴＰトンネルはドナー基地局１８ｂで終了することが必ずしも要求されない。例えば、トンネルがドナー基地局１８ｂを介して透過的に進むプロトコル実装において、基地局１８ｂは、バイパスされるトンネルＩＤを見つけ出すことによってユーザ端末のベアラを識別することができる。
【００１２】
基地局１８ｂからユーザ端末２０への通常のデータ送信中に、ユーザ端末２０は、ＤＬ送信とＵＬ送信の両方に対してＰＤＣＣＨ（物理ダウンリンク制御チャネル）を介してアドレス指定される。ドナー基地局１８ｂとリレー１８ａとの間でデータが送信される場合、ＰＤＣＣＨ上の個々のユーザ端末２０に代えて、リレー１８ａをアドレス指定することが有益である。そうでなければ、ＰＤＣＣＨ割当は、各ユーザ端末に対して別々に送信されるべきである。これは、ＰＤＣＣＨがＬＴＥシステム内の有限のリソースとなることが予想されるために受け付けることができないからである。
【００１３】
図２に示される転送のソリューションに対して、基地局１８ｂは、複数のユーザ端末２０からのパケットを共通のバックホール無線ベアラへマッピングする。リレー１８ａは、受信したパケットを正規のユーザ端末２０へ配信することができなければならない。ユーザ端末とそれに対応する無線ベアラは、ＧＴＰトンネルＩＤに基づいて識別することができる。ユーザ端末２０に、基地局１８ｂとリレー１８ａとの間のバックホールリンク上で多重化することを可能にするために、パケットが到達すると、リレー１８ａは、その受信したパケットを正規のユーザ端末２０と関連付けることが必要となる。１つのソリューションは、Ｓ−ＧＷ１５から受信されるパケットのＧＴＰ−ｕヘッダからユーザ端末アイデンティティを判定することである。この方法の欠点は、ヘッダがバックホールリンク上を送信されなければならない、つまり、無線リソース上に不必要なオーバヘッドを作成しなければならないことである。また、ロバストヘッダ圧縮（ＲｏＨＣ）メカニズムは、オーバヘッドビットには適用されない。それゆえ、ＧＴＰ−ｕヘッダとそれに関連するＵＤＰ／ＩＰヘッダからのオーバヘッドは、十分な無線リソースの不必要な消費を招くことになる。
【００１４】
本発明は、ＧＴＰ−ｕヘッダとそれに関連するＵＤＰ／ＩＰヘッダとを使用することに比べて、ユーザ端末とベアラの識別に対してより効率的なメカニズムを提供することによって、ＬＴＥリレー処理（レイヤ２とレイヤ３）に対するオーバヘッドを削減する。これによるオーバヘッドの削減は、バックホールリンク上の無線リソースを節約する。
【００１５】
図３に示される第１の実施形態では、ユーザ端末とベアラの識別は、ドナー基地局１８ｂとリレー１８ａとの間の無線リンク上のユーザプレーン（ＵＰ）プロトコルレイヤ群（ＰＤＣＰ、ＲＬＣ及びＭＡＣ）の１つにユーザ端末とベアラの識別子を含めることによって実現する。簡単のために、無線リンク上のＵＰプロトコルレイヤ群は、本明細書では、無線リンクプロトコルレイヤ群として参照する。これは、これらのレイヤ群が、適用可能なエアインタフェース仕様によって特定されるからである。第１の実施形態では、ＧＴＰトンネルはトナー基地局１８ｂで終端する。ドナー基地局１８ｂは、バックホールリンク上で直接にエンドユーザＩＰパケットのヘッダ圧縮を可能にするために、ＧＴＰ−ｕヘッダとそれに関連するＵＤＰ／ＩＰヘッダを完全に削除する。ドナー基地局１８ｂは、ユーザ端末とベアラの識別子を無線インタフェースユーザプレーン（ＵＰ）プロトコルレイヤ群の１つに含めることによって、リレー１８ａにおいて、着信バックホール無線ベアラからユーザ端末専用無線ベアラへのダウンリンクでのマッピングを実現し、かつ基地局１８ｂにおいて、バックホール無線ベアラからユーザ端末専用ＧＴＰトンネルへのアップリンクでのマッピングを実現する。
【００１６】
２つの異なる方法を、ユーザ端末とベアラの識別子をＰＤＣＰレイヤに挿入するために使用することができる。第１の方法では、個別のユーザ端末ベアラ識別フィールドがＰＤＣＰヘッダに導入される。このフィールドは、どのユーザ端末無線ベアラ上で、ダウンリンク通信に対してリレー１８ａによってパケットが送信されるべきか、また、どのＧＴＰトンネル上で、アップリンク通信に対して基地局１８ｂによってパケットが送信されるべきかを示している。この方法では、（ＰＤＣＰ以下を多重化する）ユーザ端末ベアラ毎の個別のＰＤＣＰマシーン（即ち、ヘッダ（逆）圧縮及び（逆）暗号マシーン）を実行すること、あるいは（ＰＤＣＰより上位を多重化する）バックホールベアラ毎の１つのＰＤＣＰマシーンを実行することのどちらかが可能である。この方法は、ＰＤＣＰプロトコルに対する標準化の変更を要求する場合がある。
【００１７】
ユーザ端末とベアラの識別子をＰＤＣＰレイヤに挿入するための第２の方法は、バックホールリンク内で、ヘッダ圧縮プロトコル内の既存のＣＩＤ（コンテキスト識別子）フィールドをユーザ端末ベアラ識別フィールドとして再使用することである。これは、どのユーザ端末専用ＧＴＰトンネル（アップリンク）及び無線ベアラ（ダウンリンク）に、バックホールリンク上で受信されるパケットにマッピングされるべきかを示すものである。ヘッダ圧縮プロトコル内のＣＩＤフィールドは、通常、アプリケーションフローを識別するために使用される。この方法では、ＣＩＤフィールドは、ユーザ端末無線ベアラを識別するためにバックホールリンク上のヘッダ圧縮プロトコルで使用され、これは、異なるユーザ端末無線ベアラ／ＧＴＰトンネルが常に異なるＣＩＤ値（〜６５０００値が可能である）に割り当てられることを要求する。ユーザ端末無線ベアラ／ＧＴＰトンネルとＣＩＤ群との間のマッピングは、ハードコーディングされる、例えば、ＲＢ  ｉｄ１がＣＩＤ１−２０を使用することができる、あるいはそのマッピングをリレー１８ａと基地局１８ｂとの間で明示的なシグナリングを行うことで実現することができる、あるいはそのマッピングをオペレーションメインテナンスシステムを使用して構成設定することができる。可能なシグナリングプロトコルは、Ｓ１／Ｘ２及びＲＲＣシグナリングが含まれる。ハードコーディングと明示的なシグナリングの代替としては、例えば、順序に基づいて、ＣＩＤ＜−＞ＲＢ／ＧＴＰマッピングを割り当てることである。ここで、ベアラ群はセットアップ（一揃い）あるいはいくつかの他のスキームである。この方法の利点は、ＰＤＣＰプロトコルに対する標準化の変更を命じないことである。
【００１８】
ドナー基地局１８ｂ（即ち、多重化がＰＤＣＰ以下で実行される）においてユーザ端末ベアラ毎に１つのＰＤＣＰマシーンが存在する場合、これは、ドナー基地局１８ｂにおける各ユーザ端末ベアラに対して暗号化及びヘッダ圧縮が独立して実行されることを意味するので、リレー１８ａはバックホール無線リンクとユーザ端末無線リンクとの間での転送を行う場合には復号／解凍を省略することができる。代わりに、リレー１８ａは、単にマッピングを実行し、かつ任意の更なるＰＤＣＰ処理を行うことなく、着信ベアラと発信ベアラとの間でのＰＤＣＰ  ＰＤＵ群を転送することができる。
【００１９】
上述のように、ユーザ端末とベアラの識別子は、ＲＬＣレイヤシグナリングに挿入することができる。この方法を用いると、個別のユーザ端末ベアラ識別フィールドがＲＬＣヘッダに導入される。このフィールドは、どのユーザ端末無線ベアラ上で、パケットがリレー１８ａ（ダウンリンク）によって送信されるべきか、あるいはどのＧＴＰトンネル上でパケットが基地局１８ｂ（アップリンク）によって送信されるべきかを示している。この方法は、個別のＰＤＣＰ−マシーン（即ち、ヘッダ（逆）圧縮及び（逆）暗号マシーン）と可能なＲＬＣマシーンとが（ＰＲＣＰあるいはＲＬＣ以下を多重化する）ユーザ端末ベアラ毎に使用されることを想定している。このソリューションは、ＲＬＣプロトコルに対する標準化の変更を要求する場合がある。
【００２０】
１つのＲＬＣ  ＰＤＵが、異なるユーザ端末無線ベアラから連結されている上位レイヤパケット群を含む場合があることに注意するべきである。それゆえ、ＲＬＣヘッダは、ＲＬＣ  ＰＤＵ内の異なるユーザ端末２０から連結される上位レイヤＰＤＵの数と同数の、ユーザ端末ベアラ識別フィールドを有するべきである。ヘッダサイズを小さくすることを維持するために、連結されている特定の上位レイヤＰＤＵに依存する各ＲＬＣ  ＰＤＵ内のユーザ端末ベアラ識別フィールドのサイズを動的に設定することを可能にするべきである。
【００２１】
ユーザ端末専用ベアラ識別子は、ＭＡＣレイヤシグナリングにも挿入することができる。この方法では、個別のユーザ端末無線識別フィールドはＭＡＣヘッダに挿入される。新規のフィールドをＭＡＣヘッダに導入することは、ＭＡＣヘッダ内の既存論理チャネル識別子フィールド（ＬＣＩＤ）をＵＥ専用端末識別子で拡張することによって解決することができる。このフィールドは、どのユーザ端末無線ベアラ上でパケットがリレー１８ａ（ダウンリンク）によって送信されるべきか、また、どのＧＴＰトンネル上でパケットが基地局１８ｂ（アップリンク）によって送信されるべきかを示している。このソリューションは、ＰＤＣＰ−マシーン（即ち、ヘッダ（逆）圧縮と（逆）暗号化マシーン）とＲＬＣマシーンとが別々にユーザ端末ベアラ（多重化がＭＡＣレイヤ上で実行される）毎に動作すると想定する。この方法は、ＭＡＣプロトコルに対する標準化の変更を要求する場合がある。
【００２２】
１つのＭＡＣ  ＰＤＵは、異なるユーザ端末無線ベアラから多重化される上位レイヤパケットを含む場合があることに注意すべきである。それゆえ、ＭＡＣヘッダは、異なるユーザ端末２０から所与のＭＡＣ  ＰＤＵへと多重化される上位レイヤＰＤＵの数と同数のユーザ端末ベアラ識別フィールドを保持することが必要となる。ヘッダ空間を節約するために、多重化される特定の上位レイヤＰＤＵ群に依存する各ＭＡＣ  ＰＤＵ内のユーザ端末ベアラ識別フィールドのサイズを動的に設定することを可能にするべきである。
【００２３】
図４に示される本発明の第２の実施形態では、ユーザ端末とベアラの識別は、ＰＤＣＰレイヤの上位に追加のＵＰプロトコルレイヤを導入することによって実現することができる。このＰＤＣＰレイヤは、ＧＴＰヘッダとそれに関連するＵＤＰ／ＩＰヘッダに関連するオーバヘッドを削減するために、これらのヘッダを専用ベアラ識別フィールドに置換する。オーバヘッドを更に削減するために、エンドユーザパケットのヘッダ圧縮を許容することが有用である。ヘッダ圧縮は、新規のＵＰプロトコルレイヤで実行することができる。選択的には、ヘッダ圧縮は、バックホールリンクのＰＤＣＰレイヤによって実行することができ、これは、ベアラ識別フィールドがヘッダ圧縮を通じて透過的に処理することができることを想定している。
【００２４】
新規のＵＰプロトコルレイヤ内のヘッダ圧縮は、バックホールリンクのＰＤＣＰレイヤ内のヘッダ圧縮を実行する必要性を回避する。その結果、ベアラアイデンティティフィールドは、ヘッダ圧縮ヘッダの一部として送信することができる。この方法は、ユーザ端末とベアラの識別情報を送信するためにＰＤＣＰレイヤを使用する第１の実施形態に類似している。その違いは、バックホールリンクの既存のＰＤＣＰレイヤは、この方法では変更される必要がないことである。
【００２５】
ヘッダ圧縮がＰＤＣＰレイヤで実行される場合、ＰＤＣＰレイヤは、より上位のレイヤによって追加されるベアラ識別子フィールドを無視するべきである。この問題に対する１つの方法は、ユーザ端末とベアラの識別情報を搬送する最後のＮバイトの先頭を無視するようにＰＤＣＰレイヤを明示的に構成設定することである。選択的には、ユーザ端末とベアラの識別情報は、ＩＰパケットのトレーラー（末尾）として付加することができる。一般的には、このトレーラーは、パケットの開始でより関心を向けるヘッダ圧縮アルゴリズムでは無視される。これは、ヘッダ圧縮アルゴリズムがＩＰパケット長に依存しないことを想定している。ヘッダ圧縮アルゴリズムがＩＰパケット長に依存する場合、上位レイヤがＩＰ長さフィールドを（例えば、固定バイト数を追加することによって）変更し、かつＩＰチェックサム、ＴＣＰ／ＵＤＰ長さフィールド等のような他のフィールドを変更することを要求する場合がある。
【００２６】
第２の実施形態では、異なるユーザ端末ベアラのすべての多重化が、ＰＤＣＰより上位で実行される。これは、ＰＤＣＰエンティティがバックホールベアラ単位（ユーザ端末のベアラ単位ではない）であることを意味する。
【００２７】
図５に示される第３の実施形態では、ユーザ端末とベアラの識別情報が、ヘッダ圧縮レイヤを、エンドユーザＩＰパケットを圧縮することになるＧＴＰトンネル内に導入することによって実現される。より詳しくは、ヘッダ圧縮ＰＤＣＰレイヤ（ＨＣ−ＰＤＣＰ）がＧＴＰ−ｕヘッダを圧縮するために導入される。ここで、追加のヘッダ圧縮レイヤが、新規のプロトコルヘッダ、例えば、ＰＤＣＰヘッダを必ずしも意味しているわけではないことに注意されたい。典型的な実施形態では、これは、リンクの両端上でプレーンＩＰヘッダ圧縮（例えば、ＲｏＨＣ）を実行することによって実現されることになり、これは、ＩＰヘッダのフィールド群（あるいはそれらの一部）をそれらの圧縮形態に置換する。この実施形態では、ＧＴＰ−ｕヘッダとそれに関連するＵＤＰ／ＩＰヘッダとを維持することができる。これは、バックホールリンク上のＨＣ−ＰＤＣＰエンティティがＧＴＰ／ＵＤＰ／ＩＰヘッダを圧縮することになるからである。リレー１８ａは、ＧＴＰトンネルとユーザ端末無線ベアラとの間のマッピング状態を判定するために、ＧＴＰ−ｕヘッダに依存することができる。ＧＴＰトンネル内のヘッダ圧縮を構成設定するための取り得るプロトコルは、ＧＴＰ−ｃあるいはＲＲＣシグナリング、または、Ｓシグナリングとすることができる。
【００２８】
この実施形態に対する別の潜在的な代替構成は、ＧＴＰトンネル内で追加のヘッダ圧縮レイヤ（ＨＣ−ＰＤＣＰ）を省略し、かつバックホールリンクＰＤＣＰプロトコルのヘッダ圧縮プロファイルを拡張することであり、そうすることで、ＧＴＰ／ＵＤＰ／ＩＰトンネリングヘッダとエンドユーザＩＰプロトコルヘッダとの圧縮を一緒に処理することができる。これは、ＲｏＨＣ（ロバストヘッダ圧縮）ヘッダ圧縮アルゴリズムに対する新規の圧縮プロファイルを要求することになる。ここで、このアルゴリズムは、圧縮中には、拡張ヘッダとしてＧＴＰヘッダと（エンドユーザ）ＴＣＰ／ＵＤＰヘッダとを処理することができるものである。
【００２９】
当業者は、図２−５に示されるネットワーク１０のノード群は、上述のように動作するようにプログラムされている、特別にプログラムされたコンピュータシステムを備えていても良い。このコンピュータシステムは、１つ以上のプロセッサ、マイクロコントローラ、ハードウェア、それらの組み合わせとともに、上述の動作のために必要とされるプログラミング命令とデータを記憶するメモリとを備えることができる。
【００３０】
図６と図７は、本発明の一実施形態におけるドナー基地局１８ｂの動作を示している。この実施形態では、識別情報は、ドナー基地局１８ｂとリレー１８ａとの間の多重化バックホールリンクを介して送信される無線リンクプロトコルパケットに挿入される。
【００３１】
図６は、ユーザ端末２０に対して向けられているダウンリンクパケットを転送するためのドナー基地局１８ｂによって実現される例示の手順１００を示している。手順１００は、ユーザ端末２０へ配信するためのユーザ専用トンネルを介してサービングゲートウェイ１５からデータパケットをドナー基地局１８ｂが受信する場合に開始する（ブロック１０２）。ドナー基地局１８ｂは、ユーザ専用トンネルに対するトンネル識別子を、リレー１８ａとドナー基地局１８ｂとの間のリンクで使用されるユーザ専用識別子にマッピングし（ブロック１０４）、そして、１つ以上の無線リンクプロトコルパケットで、多重化バックホールリンクを介してデータパケットをリレー１８ａへ転送する（ブロック１０６）。基地局１８ｂは、どのデータパケットがユーザ端末２０に対して向けられているかを識別するために、ユーザ専用識別子を少なくとも１つの無線リンクプロトコルパケットに挿入する。上述のように、ユーザ専用識別子は、ユーザ端末に割り当てられている専用無線ベアラを識別するユーザ専用無線ベアラ識別子を備えることができる。ユーザ専用無線ベアラ識別子は、無線リンクプロトコルパケットの、ＰＤＣＰヘッダ、ＲＬＣヘッダ、あるいはＭＡＣヘッダに挿入されていても良い。次に、リレー１８ａは、指示されているユーザ専用無線ベアラを介して、パケットをユーザ端末２０へ転送する。
【００３２】
図７は、アップリンクパケットをリレー１８ａからサービングゲートウェイ１５へ転送するためのドナー基地局１８ｂによって実現される例示の手順１５０を示している。この手順１５０は、１つ以上の無線リンクプロトコルパケットで、多重化バックホールリンクを介してリレー１８ａからデータパケットをドナー基地局１８ｂが受信する場合に開始する（ブロック１５２）。データパケットを送信する前に、リレー１８ａは、ユーザ専用識別子を少なくとも１つの無線リンクプロトコルパケットに挿入する。ドナー基地局１８ｂは、少なくとも１つの無線リンクプロトコルパケットのヘッダに挿入されているユーザ専用識別子からデータパケットを送信するユーザ端末を判定する（ブロック１５４）。ドナー基地局１８ｂは、ユーザ専用識別子に基づいてドナー基地局１８ｂとゲートウェイ１５との間のユーザ専用トンネルに対するトンネル識別子を判定し（ブロック１５６）、そして、識別されたユーザ端末に対するユーザ専用トンネルを介してデータパケットをゲートウェイ１５へ転送する（ブロック１５８）。
【００３３】
図８と図９は、本発明の一実施形態におけるリレー１８ａの動作を示している。この実施形態では、識別情報は、ドナー基地局１８ｂとリレー１８ａとの間の多重化バックホールリンクを介して送信される無線リンクプロトコルパケットに挿入される。
【００３４】
図８は、ドナー基地局１８ｂから受信されるダウンリンクパケットをユーザ端末２０へ転送するための例示の手順２００を示している。この手順２００は、リレー１８ａがユーザ端末２０からデータパケットを受信する場合に開始する（ブロック２０２）。リレー１８ａは、１つ以上の無線リンクプロトコルパケットで、多重化バックホールリンクを介してドナー基地局１８ｂへデータパケットを転送する（ブロック２０４）。リレー１８ａは、データパケットが向けられているユーザ端末を識別することをドナー基地局１８ｂに可能にするために、少なくとも１つの無線リンクプロトコルパケットにユーザ専用識別子を挿入する（ブロック２０６）。上述のように、ユーザ専用識別子は、ユーザ端末に割り当てられている専用無線ベアラを識別するユーザ専用無線ベアラ識別子を備えることができる。ユーザ専用無線ベアラ識別子は、無線リンクプロトコルパケットの、ＰＤＣＰヘッダ、ＲＬＣヘッダ、あるいはＭＡＣヘッダに挿入されていても良い。
【００３５】
次に、ドナー基地局１８ｂは、パケットをサービングゲートウェイ１５へ転送する。
【００３６】
図９は、ドナー基地局１８ｂから受信されるダウンリンクパケットをユーザ端末２０へ転送するためのリレー１８ａによって実現される例示の手順２５０を示している。この手順２５０は、１つ以上の無線リンクプロトコルパケットで、多重化バックホールリンクを介してドナー基地局１８ｂからデータパケットをリレー１８ａが受信する場合に開始する（ブロック２５２）。データパケットを送信する前に、リレー１８ａは、ユーザ専用識別子を、少なくとも１つの無線リンクプロトコルパケットに挿入する。リレー１８ａは、少なくとも１つの無線リンクプロトコルパケットのヘッダに挿入されているユーザ専用識別子からデータパケットを受信するためのユーザ端末を判定し（ブロック２５４）、そして、そのデータパケットを、識別されたユーザ端末へ転送する（ブロック２５６）。
【００３７】
図１０と図１１は、本発明の代替の実施形態におけるドナー基地局１８ｂの動作を示している。この実施形態では、サービングゲートウェイ１５からユーザ専用トンネルを介して送信されるデータパケットのトンネリングするヘッダは、ドナー基地局１８ｂとリレー１８ａとの間のバックホールリンクを介する送信のために圧縮される。
【００３８】
図１０は、サービングゲートウェイ１５から受信されるパケットをリレー１８ａへ転送するためのドナー基地局１８ｂによって実現される例示の手順３００を示している。この手順３００は、サービングゲートウェイ１５からＧＴＰトンネルを介してパケットをドナー基地局１８ｂが受信する場合に開始する（ブロック３０２）。ドナー基地局１８ｂは、データパケットをカプセル解除し、かつヘッダを圧縮する（ブロック３０４）。ドナー基地局は、ゲートウェイ１５から受信されるＧＴＰ−ｕヘッダのトンネルＩＤから、データパケットが向けられているユーザ端末を判定し、サービングゲートウェイ１５からの着信トンネルを介して受信されるデータパケットを、リレー１８ａに向けられている発信トンネルへマッピングする（ブロック３０６）。ドナー基地局１８ｂは、トンネルするパケットで、圧縮されたデータパケットをカプセル化し、そして、そのデータパケットをリレー１８ａへ転送する（ブロック３０８）。発信トンネルは、ドナー基地局１８ｂとリレー１８ａとの間の多重化バックホールリンクにおけるユーザ専用トンネルである。リレー１８ａへの送信の前に、ドナー基地局１８ｂは、ユーザ端末２０をリレーが識別することを可能にするために、ユーザ専用識別子をトンネルするヘッダに挿入する（ブロック３１０）。
【００３９】
図１１は、バックホールリンクを介してリレー１８ａから受信されるアップリンクパケットをサービングゲートウェイ１５へ転送するためのドナー基地局１８ｂによって実現される例示の手順３５０を示している。この手順３５０は、バックホール無線ベアラを介してリレー１８ａからデータパケットをドナー基地局１８ｂが受信する場合に開始する（ブロック３５２）。この実施形態では、トンネリング（トンネルする）プロトコル、例えば、ＧＴＰが、バックホールリンクを介するデータパケットの送信のために使用され、また、データパケットのヘッダが送信前にリレー１８ａによって圧縮されることを前提とする。データパケットの受信後、ドナー基地局１８ｂは、圧縮されたデータパケットをカプセル解除し（ブロック３５４）、そして、そのデータパケットのヘッダを解凍する（ブロック３５６）。ドナー基地局１８ｂは、サービングゲートウェイ１５に向けられている発信トンネルを判定し（ブロック３５８）、そのデータパケットを、ドナー基地局１８ｂとサービングゲートウェイ１５との間のユーザ専用トンネルを介して転送する（ブロック３６０）。ドナー基地局は、リレー１８ａから受信されるＧＴＰ−ｕヘッダに含まれるユーザ専用識別子から発信トンネルを判定することができる。
【００４０】
図１２は、サービングゲートウェイへの送信のために、アップリンクパケットを圧縮し、かつドナー基地局１８ｂへ転送するためのマルチホップ通信システムにおけるリレー１８ａによって実現される例示の手順を示している。この手順は、ユーザ端末２０からエアインタフェースを介してデータパケットをリレー１８ａが受信する場合に開始する（ブロック４０２）。リレー１８ａは、データパケットのヘッダを圧縮し（ブロック４０４）、そして、ドナー基地局１８ｂへの送信のためにデータパケットをＧＴＰパケットにカプセル化する（ブロック４０６）。リレー１８ａは、ユーザ専用識別子をＧＴＰヘッダへ挿入し（ブロック４０８）、そして、カプセル化され、かつ圧縮されたデータパケットをドナー基地局１８ｂへ転送する（ブロック４１０）。
【００４１】
図１３は、ドナー基地局から受信されるダウンリンクパケットを解凍し、ユーザ端末へ転送するためのマルチホップ通信システムにおけるリレー１８ａによって実現される例示の手順４５０を示している。リレー１８ａは、ＧＴＰパケットでカプセル化されているデータパケットをドナー基地局から受信する（ブロック４５２）。リレー１８ａは、データパケットをカプセル解除し、データパケットのヘッダを解凍する（ブロック４５４）。ドナー基地局１８ｂは、ＧＴＰヘッダからデータパケットを送信するユーザ端末２０を判定し（ブロック４５６）、そして、ゲートウェイ１５に向けられる対応するトンネルを判定する（ブロック４５８）。次に、ドナー基地局１８ｂは、解凍されたデータパケットを識別されたユーザ端末２０へエアインタフェースを介して転送する（ブロック４６０）。
【００４２】
図１４は、マルチホップ通信システムにおける例示の基地局１８ｂとリレー１８ａを示している。基地局１８ｂは、サービングゲートウェイ１５と通信するためのネットワークインタフェース２２と、無線バックホールリンクを介してリレー１８ａと通信するための無線トランシーバ２４と、本明細書で記載されるパケット転送プロトコルを実現するための処理回路２６とを備える。ネットワークインタフェース２２は、例えば、イーサネット（登録商標）インタフェースを備える。無線トランシーバ２４は、バックホールリンクを変更することなく、既知の無線通信プロトコル、例えば、ＬＴＥ、ＷＣＤＭＡ及びＷｉＭＡＸを実現するように構成することができる。処理回路２６は、１つ以上のプロセッサ、ハードウェア、あるいはそれらの組み合わせ、及び図６−７及び図１０−１１に示される転送手順を実現するためのメモリを備える。リレー１８ａも、無線トランシーバ２８及び処理回路３０を含んでいる。トランシーバは、ドナー基地局１８ｂとユーザ端末との両方と通信するために使用される。処理回路３０は、１つ以上のプロセッサ、ハードウェア、あるいはそれらの組み合わせ、及び図７−８及び図１２−１３に示される転送手順を実現するためのメモリを備える。
【００４３】
ＬＴＥリリース１０は、バックホールリンク上のオーバヘッドが小さいことが望ましい場合での、セルフバックホール処理ソリューションを含める可能性がある。本発明の例示の実施形態は、ＬＴＥシステムにおけるセルフバックホール処理あるいはリレー処理のソリューションに適用される場合に、プロトコルオーバヘッドを削減する。これは、無線リソースのより効率的な利用と、システム応答性能を改善することを意味する。オーバヘッドを削減することによって実現されるゲインの規模は、パケットサイズに関係する。かなり大規模なパケット群を送信する場合、いくつかの付加ビットは然程影響を与えない。しかしながら、より小さいＩＰパケット群を用いるＶｏＩＰのようなサービスに対しては、ゲインは著しくなる。
【００４４】
本発明は、もちろん、本発明の範囲及び本質的な特徴から逸脱することなく、本明細書で説明される方法以外の他の特別な方法で実行されても良い。それゆえ、本実施形態群は、あらゆる観点から例示であるみなされるべきであり、限定されるべきものではなく、そして、添付の請求項の意味及び等価の範囲内でのあらゆる変更が、本明細書で包含されることが意図されるものである。
【図１】
0005479571.tif 000002
【図２】
0005479571.tif 000003
【図３】
0005479571.tif 000004
【図４】
0005479571.tif 000005
【図５】
0005479571.tif 000006
【図６】
0005479571.tif 000007
【図７】
0005479571.tif 000008
【図８】
0005479571.tif 000009
【図９】
0005479571.tif 000010
【図１０】
0005479571.tif 000011
【図１１】
0005479571.tif 000012
【図１２】
0005479571.tif 000013
【図１３】
0005479571.tif 000014
【図１４】
0005479571.tif 000015