以下で参照されたときに、用語「HeNB」および「HNB」は、交換可能に使用され、および、これらのいずれかへの参照は、HeNBとHNBの両方を表す。
図1Aは、1または複数の説明されている実施形態を実装することができる例示的な通信システム100を示している。通信システム100は、音声、データ、ビデオ、メッセージング、および放送などのコンテンツを複数の無線ユーザに提供する多元接続システムであってもよい。通信システム100は、無線帯域を含む、システムリソースの共有を通じて複数の無線ユーザがそのようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、および、シングルキャリアFDMA(SC−FDMA)など、1または複数のチャネルアクセス方法を採用してもよい。
図1Aに示されているように、通信システム100は、WTRU102a、102b、102c、および102d、ならびに、無線アクセスネットワーク(RAN)104、コアネットワーク(CN)106、公衆交換電話網(PSTN)108、インターネット110、および他のネットワーク112を含んでもよいが、説明されている実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図していると理解されるであろう。WTRU102a、102b、102c、および102dのそれぞれは、無線環境において動作および/または通信するように構成された任意のタイプのデバイスであってもよい。例えば、WTRU102a、102b、102c、および102dは無線信号を送信および/または受信するように構成されてもよく、および、ユーザ機器(UE)、移動局、固定または移動加入者ユニット、ページャ、携帯電話、携帯情報端末(PDA)、スマートフォン、ラップトップ、ノートブック、パーソナルコンピュータ、無線センサー、および家庭用電化製品などを含んでもよい。
通信システム100はまた、基地局114aおよび基地局114bを含んでもよい。基地局114a、114bのそれぞれは、WTRU102a、102b、102c、および102dのうちの少なくとも1つと無線でインタフェースして、CN106、インターネット110、および/または他のネットワーク112などの1または複数の通信ネットワークへのアクセスを容易にするように構成された任意のタイプのデバイスであってもよい。例として、基地局114aおよび114bは、トランシーバ基地局(BTS)、NodeB、発展型NodeB(eNB)、ホームNodeB(HNB)、ホームeNB(HeNB)、サイトコントローラ、アクセスポイント(AP)、および無線ルータなどであってもよい。基地局114aおよび114bは、それぞれ、単一要素として示されているが、基地局114aおよび114bは任意の数の相互接続された基地局および/またはネットワーク要素を含んでもよいことは理解されるであろう。
基地局114aは、基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、および中継ノードなどの他の基地局および/またはネットワーク要素(図示せず)も含んでもよい、RAN104の一部であってもよい。基地局114aおよび/または基地局114bはまた、セル(図示せず)とも称されることもある、特定の地理的エリア内で無線信号を送信および/または受信するように構成されてもよい。セルは、いくつかのセルセクターにさらに分割されることがある。例えば、基地局114aに関連付けられているセルは、3つのセクターに分割されることもある。したがって、一実施形態において、基地局114aは、3つの送受信機、すなわち、セルの各セクターに対して1つを含んでもよい。別の実施形態において、基地局114aは、多入力多出力(MIMO)技術を採用してもよく、したがって、セルの各セクターに対して複数の送受信機を利用してもよい。
基地局114aおよび114bは、WTRU102a、102b、102c、および102dのうちの1または複数と、任意の適切な無線通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、および可視光など)とすることができるエアインタフェース116上で通信してもよい。エアインタフェース116は、任意の適切な無線アクセス技術(RAT)を使用して確立されてもよい。
より具体的には、上述したように、通信システム100は多元接続システムであってもよく、CDMA、TDMA、FDMA、OFDMA、およびSC−FDMAなどの1または複数のチャネルアクセス方式を採用してもよい。例えば、RAN104における基地局114a、ならびに、WTRU102a、102b、および102cは、広帯域CDMA(WCDMA(登録商標))を使用してエアインタフェース116を確立することができる、ユニバーサルモバイル通信システム(UMTS)地上波無線アクセス(UTRA)などの無線技術を実装してもよい。WCDMAは、高速パケットアクセス(HSPA)および/または発展型HSPA(HSPA+)などの通信プロトコルを含んでもよい。HSPAは、高速ダウンリンク(DL)パケットアクセス(HSDPA)および/または高速アップリンク(UL)パケットアクセス(HSUPA)を含んでもよい。
別の実施形態では、基地局114a、ならびに、WTRU102a、102b、および102cは、ロングタームエボリューション(LTE)および/またはLTE−Advanced(LTE−A)を使用してエアインタフェース116を確立することができる、発展型UTRA(E−UTRA)などの無線技術を実装してもよい。
他の実施形態では、基地局114a、ならびに、WTRU102a、102b、および102cは、IEEE802.16(すなわち、Worldwide Interoperability for Microwave Access(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000 evolution−data optimized(EV−DO)、Interim Standard2000(IS−2000)、Interim Standard95(IS−95)、Interim Standard856(IS−856)、Global System for Mobile communications(GSM(登録商標))、Enhanced data rates for GSM Evolution(EDGE)、およびGSM/EDGE RAN(GERAN)などの無線技術を実装してもよい。
図1Aにおける基地局114bは、例えば、無線ルータ、HNB、HeNB、またはAPであってもよく、ならびに、事業所、家庭、自動車、およびキャンパスなどの局所化されたエリアにおいて無線接続性を容易にするために最適なRATを利用してもよい。一実施形態では、基地局114b、ならびに、WTRU102cおよび102dは、IEEE802.11などの無線技術を実装して、無線ローカルエリアネットワーク(WLAN)を確立してもよい。別の実施形態では、基地局114b、ならびに、WTRU102cおよび102dは、IEEE802.15などの無線技術を実装して、無線パーソナルエリアネットワーク(WPAN)を確立してもよい。さらに別の実施形態では、基地局114b、ならびに、WTRU102cおよび102dは、セルラベースのRAT(例えば、WCDMA、CDMA2000、GSM、LTE、およびLTE−Aなど)を利用して、ピコセルまたはフェムトセルを確立してもよい。図1Aに示されているように、基地局114bは、インターネット110との直接接続を有してもよい。したがって、基地局114bは、CN106を介してインターネット110にアクセスことが要求されない。
RAN104は、CN106と通信していてもよく、当該CN106は、音声、データ、アプリケーション、および/またはボイスオーバインターネットプロトコル(VoIP)サービスをWTRU102a、102b、102c、および102dのうちの1または複数に提供するように構成された任意のタイプのネットワークであってもよい。例えば、CN106は、呼制御、課金サービス、モバイル位置情報サービス、プリペイドコーリング、インターネット接続機能、および映像配信などを提供し、ならびに/またはユーザ認証などの高水準のセキュリティ機能を実行してもよい。図1Aには示されていないが、RAN104および/またはCN106は、RAN104と同一のRATまたは異なるRATを採用する他のRANと直接的または間接的な通信していてもよいことが理解されるであろう。例えば、E−UTRA無線技術を利用していてもよいRAN104に接続されることに加えて、CN106は、GSM無線技術を採用する別のRAN(図示せず)と通信していてもよい。
CN106はまた、WTRU102a、102b、102c、および102dがPSTN108、インターネット110、および/または他のネットワーク112にアクセスするためのゲートウェイとしてサービスしてもよい。PSTN108は、アナログ音声通話のみ可能な旧来の電話サービス(POTS:plain old telephone service)を提供する回線交換電話網を含んでもよい。インターネット110は、TCP/IPスイートにおける伝送制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、およびインターネットプロトコル(IP)などの共通通信プロトコルを使用する相互接続されたコンピューターネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク112は、他のサービスプロバイダによって所有され、および/または運営される有線もしくは無線通信ネットワークを含んでもよい。例えば、ネットワーク112は、RAN104と同一のRATまたは異なるRATを採用することができる、1または複数のRANに接続された別のCNを含んでもよい。
通信システム100におけるWTRU102a、102b、102c、および102dのうちの一部またはすべては、マルチモード機能(multi−mode capabilities)を含んでもよく、すなわち、WTRU102a、102b、102c、および102dは、異なる無線リンク上で異なる無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図1Aに示されているWTRU102cは、セルラベースの無線技術を採用することができる、基地局114aと、IEEE802無線技術を採用することができる、基地局114bと通信するように構成されてもよい。
図1Bは、図1Aに例示されている通信システム100内で使用することができる例示的なWTRU102を示している。図1Bに示されているように、WTRU102は、プロセッサ118、送受信機120、送信/受信要素(例えば、アンテナ)122、スピーカ/マイクロホン124、キーパッド126、ディスプレイ/タッチパッド128、着脱不能メモリ130、着脱可能メモリ132、電源134、グローバルポジショニングシステム(GPS)チップセット136、および周辺機器138を含んでもよい。WTRU102は、実施形態との整合性を維持しながら前記の要素の部分的組合せを含んでもよいことが理解されるであろう。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタルシグナルプロセッサ(DSP)、マイクロプロセッサ、DSPコアとの関連性を持つ1または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、集積回路(IC)、および状態機械などであってもよい。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/またはWTRU102が無線環境において動作することを可能にする他の機能性を実行してもよい。プロセッサ118は、送信/受信要素122に結合することができる、送受信機120に結合されてもよい。図1Bは、プロセッサ118および送受信機120を別々のコンポーネントとして表しているが、プロセッサ118および送受信機120は、電子パッケージまたはチップにおいてまとめて集積化されてもよい。
送信/受信要素122は、エアインタフェース116上で基地局(例えば、基地局114a)に信号を送信し、または、基地局(例えば、基地局114a)から信号を受信するように構成されてもよい。例えば、一実施形態では、送信/受信要素122は、RF信号を送信および/または受信するように構成されたアンテナであってもよい。別の実施形態では、送信/受信要素122は、例えば、IR、UV、または可視光信号を送信および/または受信するように構成されたエミタ/ディテクタであってもよい。さらに別の実施形態では、送信/受信要素122は、RF信号および光信号の両方を送信し、ならびに、受信するように構成されてもよい。送信/受信要素122は、無線信号の組合せを送信および/または受信するように構成されてもよい。
加えて、図1Bでは送信/受信要素122は単一の要素として示されているが、WTRU102は、任意の数の送信/受信要素122を含んでもよい。より具体的には、WTRU102は、MIMO技術を採用してもよい。したがって、一実施形態において、WTRU102は、エアインタフェース116上で無線信号を送信し、および、受信するための2以上の送信/受信要素122(例えば、複数のアンテナ)を含んでもよい。
送受信機120は、送信/受信要素122によって送信されることになる信号を変調し、および、送信/受信要素122によって受信された信号を復調するように構成されてもよい。上述したように、WTRU102は、マルチモード機能を有してもよい。したがって、送受信機120は、例えば、UTRAおよびIEEE802.11などの複数のRATを介してWTRU102が通信することを可能にするための複数送受信機を含んでもよい。
WTRU102のプロセッサ118は、スピーカ/マイクロホン124、キーパッド126、および/またはディスプレイ/タッチパッド128(例えば、液晶ディスプレイ(LCD)表示ユニットまたは有機発光ダイオード(OLED)表示ユニット)に結合されてもよく、ならびに、それらからユーザ入力データを受信してもよい。プロセッサ118はまた、ユーザデータをスピーカ/マイクロホン124、キーパッド126、および/またはディスプレイ/タッチパッド128に出力してもよい。加えて、プロセッサ118は、着脱不能メモリ130および/または着脱可能メモリ132などの任意のタイプの適切なメモリにある情報にアクセスし、ならびに、データをそのようなメモリに格納してもよい。着脱不能メモリ130は、ランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)、ハードディスク、または他のタイプのメモリストレージデバイスを含んでもよい。着脱可能メモリ132は、加入者識別モジュール(SIM)カード、メモリスティック、およびセキュアデジタル(SD)メモリカードなどを含んでもよい。他の実施形態において、プロセッサ118は、サーバもしくはホームコンピュータ(図示せず)上など、WTRU102上に物理的に配置されていないメモリにある情報にアクセスしてもよく、および、データをそのようなメモリに格納してもよい。
プロセッサ118は、電源134から電力を受信してもよく、および、当該電力をWTRU102における他のコンポーネントに分配および/または制御するように構成されてもよい。電源134は、WTRU102に給電するための任意の適切なデバイスであってもよい。例えば、電源134は、1または複数の乾電池(例えば、ニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル水素(NiMH)、およびリチウムイオン(Li−ion)など)、太陽電池、ならびに燃料電池などを含んでもよい。
プロセッサ118はまた、WTRU102の現在位置に関する位置情報(例えば、経度および緯度)を提供するように構成することができる、GPSチップセット136に結合されてもよい。GPSチップセット136からの情報に加えて、またはその代わりに、WTRU102は、基地局(例えば、基地局114a、114b)からエアインタフェース116上で位置情報を受信してもよく、および/または、2以上の隣接する基地局から信号を受信するタイミングに基づいて、その位置を判定してもよい。WTRU102は、一実施形態との整合性を維持しながら任意の適切な位置判定方法によって位置情報を取得してもよい。
プロセッサ118はさらに、追加の特徴、機能性、および/または有線もしくは無線接続性を提供する1または複数のソフトウェアおよび/またはハードウェアモジュールを含むことができる、他の周辺機器138に結合されてもよい。例えば、周辺機器138は、加速度計、電子コンパス、衛星送受信機、デジタルカメラ(写真または動画用)、ユニバーサルシリアルバス(USB)ポート、バイブレーションデバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。
図1Cは、図1Aに示されている通信システム100内で使用することができる例示的なRAN104および例示的なCN106を示している。上述したように、RAN104は、E−UTRA無線技術を採用して、エアインタフェース116上でWTRU102a、102b、および102cと通信してもよい。RAN104はまた、CN106と通信してもよい。
RAN104は、eNB140a、140b、および140cを含んでもよいが、RAN104は、実施形態との整合性を維持しながら任意の数のeNBを含んでもよいことが理解されるであろう。eNB140a、140b、および140cは、それぞれ、エアインタフェース116上でWTRU102a、102b、および102cと通信するための1または複数の送受信機を含んでもよい。一実施形態において、eNB140a、140b、および140cは、MIMO技術を実装してもよい。したがって、eNB140aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信してもよく、および、WTRU102aから無線信号を受信してもよい。
eNB140a、140b、および140cのそれぞれは、特定のセル(図示せず)に関連付けられてもよく、ならびに、無線リソース管理決定、ハンドオーバ決定、およびULおよび/またはDLにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図1Cに示されているように、eNB140a、140b、および140cは、X2インタフェース上で互いに通信してもよい。
図1Cに示されているCN106は、モビリティ管理エンティティ(MME)142、サービングゲートウェイ144、およびパケットデータネットワーク(PDN)ゲートウェイ(GW)146を含んでもよい。前記の要素のそれぞれは、CN106の一部として示されているが、これらの要素のうちの任意の1つが、CNオペレータ以外のエンティティによって所有され、および/または運営されていてもよいことが理解されるであろう。
MME142は、S1インタフェースを介してRAN104におけるeNB140a、140b、および1420cのそれぞれに接続されてもよく、ならびに、制御ノードとしてサービスしてもよい。例えば、MME142は、WTRU102a、102b、および102cのユーザの認証、ベアラ活性化/非活性化、ならびに、WTRU102a、102b、および102cの初期アタッチ中の特定のサービングゲートウェイを選択することなどの担当をしてもよい。MME142は、RAN104と、GSMまたはWCDMAなどの他の無線技術を採用する他のRAN(図示せず)と野間で切り替えるための制御プレーン機能を提供してもよい。
サービングゲートウェイ144は、S1インタフェースを介してRAN104におけるeNB140a、140b、および140cのそれぞれに接続されてもよい。サービングゲートウェイ144は、概して、WTRU102a、102b、および102cへ/から、データパケットをルーティングおよび転送してもよい。サービングゲートウェイ144はまた、eNB間ハンドオーバの間にユーザプレーンをアンカリングすること、WTRU102a、102b、および102cに対してDLデータが利用可能になったときにページングをトリガすること、ならびに、WTRU102a、102b、および102cのコンテキストを管理および格納することなど、他の機能も実行してもよい。
サービングゲートウェイ144はまた、PDNゲートウェイ146に接続されたもよく、PDNゲートウェイ146は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、および102cに提供して、WTRU102a、102b、および102cとIP対応デバイスとの間の通信を容易にしてもよい。
CN106は、他のネットワークとの通信を容易にすることができる。例えば、CN106は、PSTN108などの回線交換ネットワークへのアクセスをWTRU102a、102b、および102cに提供して、WTRU102a、102b、および102cと従来の地上通信回線を使用する通信デバイスとの間の通信を容易にしてもよい。例えば、CN106は、CN106とPSTN108との間のインタフェースとしてサービスするIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含んでもよく、または、それと通信してもよい。加えて、CN106は、WTRU102a、102b、および102cに、他のサービスプロバイダによって所有され、および/または、運営されている他の有線もしくは無線ネットワークを含むことができる、他のネットワーク112へのアクセスを提供してもよい。
ローカルIPアクセス(LIPA)は、HeNBの無線アクセスを使用してローカルネットワーク(LN)へIP接続を提供してもよい。図2は、HeNB210上に同一位置に配置することができる、ローカルゲートウェイ(LGW)205を通じてローカルIPネットワークにアクセスするための例示的なシステム200を示している。ローカルIPネットワークは、例えば、ホームネットワーク207であってもよい。ローカルゲートウェイ(LGW)205は、例えば、パケットデータネットワーク(PDN)ゲートウェイ(PGW)または汎用パケット無線サービス(GPRS)サポートノード(GGSN)に類似する機能を有してもよい。
システム200は、セキュリティゲートウェイ(SeGW)242、サービングゲートウェイ(SGW)244、モビリティ管理エンティティ(MME)246、およびパケットデータネットワークゲートウェイ(PGW)248を含むことができるがそれらに限定されない、発展型パケットコア(EPC)240を含んでもよい。LGW205およびHeNB210は、ホームルータ/ネットワークアドレストランスレータ(NAT)220を使用して、IPバックホール230を通じてSeGW242と通信してもよい。特に、LGW205およびHeNB210は、SGW244と通信してもよく、ならびに、HeNBはまた、SeGW242を介してMME246と通信してもよい。
本明細書において上述したように、LGW205は、HeNB210と同一位置に配置されてもよい。したがって、WTRU215がHeNB210のカバレッジエリアから外へ移動する場合(アイドルモードまたは接続ノードのいずれかで)、LIPA PDN接続は非活性化されてもよい。さらに、接続モードにあるWTRU215、および、別のセルへのハンドオーバ(HO)を実行しようとしているWTRU215に対し、HeNB210は、最初に、HOに関してLGW205に通知することによって、LGW205がLIPA PDN接続を非活性化してもよい(このシグナリングはMME246に送信されてもよい)。LIPA PDN接続が非活性化された後、WTRU215は、別のセルにハンドオーバされてもよい。HOの間に、LIPAベアラ/PDN接続が非活性化されなかったことをMME246が検出した場合、MME246は、HOを拒絶してもよい。
図3は、複数のホーム発展型NodeB(HeNB)に対する例示的なスタンドアロンLGWアーキテクチャ300を示しており、これにより、WTRUがHeNB間を移動するときにLIPA PDN接続を継続させることを可能にする。同一のLGWに接続する複数のHeNBは、HeNBサブシステムと称されることがある。この例では、スタンドアロンLGWアーキテクチャ300は、それぞれがPDN323およびPDN327と通信している、ローカルHeNBネットワーク305およびローカルHeNBネットワーク310を含んでもよい。ローカルHeNBネットワーク305は、HeNB330、332、および334と通信することができるLGW310を含んでもよく、ならびに、ローカルHeNBネットワーク310は、HeNB336および338と通信することができるLGW327を含んでもよい。示されているように、LGW310および315は、これらが単一のHeNB上に同一位置に配置されないという点で、スタンドアロンエンティティである。HeNBサブシステムへのLIPA PDN接続を有するWTRU(図示せず)は、LIPA PDN接続を維持しながら接続されたすべてのHeNBにわたって移動してもよい。WTRUがHeNBサブシステムの外に完全に移動する場合(すなわち、LGWに接続するすべてのHeNBのカバレッジの外に移動する)、LIPAに対するWTRUのPDN接続は非活性化されてもよい。
図4は、複数のホーム発展型NodeB(HeNB)に対する別の例示的なスタンドアロンLGWアーキテクチャ400を示しており、これにより、WTRUがHeNB間を移動するときにLIPA PDN接続を継続させることが可能になる。上述したように、同一のLGWに接続する複数のHeNBは、HeNBサブシステムと称されることがある。この例では、スタンドアロンLGWアーキテクチャ400は、HeNB420、422、424、および426と通信するLGW410を含むことができる、ローカルHeNBネットワーク405を含んでもよい。示されているように、LGW410は、単一のHeNB上に同一位置に配置されないスタンドアロンエンティティである。HeNBサブシステム405へのLIPA PDN接続を有するWTRU430は、LIPA PDN接続を維持しながら接続されたすべてのHeNB420、422、424、および426にわたって移動してもよい。WTRUがHeNBサブシステム405の外に完全に移動する場合(すなわち、LGW410に接続するすべてのHeNB420、422、424、および426のカバレッジの外に移動する)、LIPAに対するWTRU430のPDN接続は非活性化されてもよい。
図5は、ネットワークオペレータがインターネットへのトラフィックをオフロードするPGWを選択することができる、セレクティドIPトラフィックオフロード(SIPTO)サービスを使用する無線通信システム500の例を示す。特に、WTRUの物理的ロケーションまたはIPトポロジロケーションは、コアネットワーク(CN)PGWと異なるPGWを選択することを有益とする。無線通信システム500は、SGW515と通信しているeNB510によって提供されるような無線アクセスネットワーク(RAN)505を含んでもよい。次いで、SGW515は、ローカルPGW520(L−PGW、またはLGWとして知られる)、ならびに、MME530およびPGW535を含むことができるCN525と通信してもよい。WTRU540は、SIPTO接続を使用して、LGW520を介してユーザデータをインターネット(図示せず)にオフロードしてもよい。SIPTOは、RANの上で、WTRUの無線接続がeNBまたはHeNBを介して取得されるか否かに関わらず、達成されてもよい。別のPGWの選択は、WTRUに知られていないことがあり、および、LGWへのWTRUのトラフィックのオフロードは、ユーザのサービス経験を低下させることがある。
図6は、HeNBサブシステム上にあるLGWを介したインターネットへのユーザデータのオフロードに対する例示的なアーキテクチャ600を示している。エンタープライズネットワーク605(すなわち、ローカルネットワーク)は、エンタープライズIPサービス614を介してインターネット612に接続されているHeNBサブシステム610を含んでもよい。HeNBサブシステム610は、HeNB617、HeNB618、およびHeNB619と通信することができるLGW616を含んでもよい。モバイルオペレータネットワーク(MNO)620は、MME622、PGW624、およびSGW626を含んでもよい。LTEマクロネットワーク630は、MME622およびSGW626と通信することができるeNB632を含んでもよい。MME622およびSGW626は、両方とも、HeNB617、HeNB618、およびHeNB619と通信してもよく、ならびに、SGW626はまた、LGW616と通信してもよい。WTRU640は、ハンドオーバの結果としてHeNB618または619と通信してもよい。このアーキテクチャ600では、LIPAとSIPTOとが両方とも可能であるが(すなわち、LGW616が使用されてローカルIPネットワーク(すなわち、LIPA)にアクセスすることができるが)、同一のLGW616を介してWTRU640のデータをインターネット612にオフロードすることも可能になる。
図7は、発展型パケットシステム(EPS)に対する例示的なスタンドアロンLGWアーキテクチャを示している。LGWアーキテクチャ700は、HeNB715と通信しているLGW710を含むことができるHeNBサブシステム705を含んでもよい。LGW710は、SeGW722を介してSGW720と通信していてもよい。HeNB715は、SeGW722およびHeNBゲートウェイ(GW)724を介して、SGW720およびMME726と通信していてもよい。WTRU730は、HeNB715と通信していてもよい。
図8は、EPSに対する例示的なスタンドアロンLGWアーキテクチャ800を示している。LGWアーキテクチャ800は、HNB815と通信しているLGW810を含むことができるHNBサブシステム805を含んでもよい。LGW810は、SeGW822を介してSGW820と通信していてもよい。HNB815は、SeGW822およびHNB GW824を介して、SGW820およびS4−サービングGPRSサポートノード(SGSN)826と通信していてもよい。WTRU830は、HNB815と通信していてもよい。
図9は、ユニバーサルモバイル通信システム(UMTS)に対する例示的なスタンドアロンLGWアーキテクチャ900を示している。LGWアーキテクチャ900は、HNB915と通信しているLGW910を含むことができるHNBサブシステム905を含んでもよい。LGW910は、SeGW922を介してSGSN920と通信していてもよい。HNB915は、SeGW922およびHNB GW924を介してSGSN920と通信していてもよい。WTRU930は、HNB915と通信していてもよい。
図10は、EPSに対するHeNBサブシステムにおけるS1/Iuパス上の例示的なスタンドアロンLGWアーキテクチャ1000を示している。LGWアーキテクチャ1000は、HeNB1015と通信しているLGW1010を含むことができるHeNBサブシステム1005を含んでもよい。LGW1010は、SeGW1020およびHeNB GW1024を介してSGW1020およびMME1026と通信していてもよい。WTRU1030は、HeNB1015と通信していてもよい。
図11は、EPSに対するHNBサブシステムにおけるIuhパス上の例示的なスタンドアロンLGWアーキテクチャ1100を示している。LGWアーキテクチャ1105は、HNB1115と通信しているLGW1110を含むことができるHNBサブシステム1105を含んでもよい。LGW1110は、SeGW1122およびHNB GW1124を介して、SGW1120およびS4−SGSN1126と通信していてもよい。WTRU1130は、HNB1115と通信していてもよい。
図12は、UMTSに対するHNBサブシステムにおけるIuhパス上の例示的なスタンドアロンLGWアーキテクチャ1200を示している。LGWアーキテクチャ1200は、HNB1215と通信しているLGW1210を含むことができるHNBサブシステム1205を含んでもよい。LGW1210は、SeGW1222を介して、または、SeGW1222およびHNB GW1224をも介して、SGSN1220と通信していてもよい。WTRU1230は、HNB1115と通信していてもよい。
データセッションの継続性は、ローカルネットワークカバレッジとマクロネットワークカバレッジとの間をユーザが移動するときに望ましい場合がある。図13は、モバイルオペレータコアネットワーク1305、マクロネットワーク1310、および、HeNBサブシステム1315を含むことができる例示的なアーキテクチャ1300を示している。モバイルオペレータコアネットワーク1305は、ネットワーク(NW)エンティティ1320を含んでもよく、マクロネットワーク1310は、eNB1330および1335を含んでもよく、および、HeNBネットワーク1315は、HeNB1337を含んでもよい。WTRU1340は、マクロネットワーク1310(すなわち、マクロセル、またはローカルネットワークの一部ではないHeNB)を介してローカルネットワーク1350に接続してもよい。このことは、マネージドリモートアクセス(MRA)またはリモートIPアクセス(RIPA)と称される。すなわち、MRAセッションは、実際のセル(マクロまたはHeNB)がローカルネットワークに接続していないときである。WTRU1340がローカルネットワーク1350のカバレッジエリア内に移動するときに、MRAセッションは、LIPAセッションとして継続されてもよい。この反対も同様に可能である。WTRU1340は、ローカルネットワーク1350においてLIPAセッションとして開始してもよく、および、マクロネットワーク1310に移動してもよく、当該マクロネットワーク1310では、LIPAセッションがMRAセッションとして継続される。すなわち、LIPAセッションを有するWTRUは、ローカルネットワークの一部ではないHeNBに移動してもよい。
図14は、モバイルオペレータCN1405、HeNBネットワーク1410、およびHeNBサブシステム1415を含むことができる例示的なアーキテクチャ1400を示している。モバイルオペレータCN1405は、NWエンティティ1420を含んでもよく、HeNBネットワーク1410は、HeNB1430を含んでもよく、および、HeNBサブシステム1415は、HeNB1435を含んでもよい。WTRU1440は、ローカルネットワーク1450に接続していないHeNB1430を使用してMRAセッションを有してもよい。WTRU1440がローカルネットワーク1450のカバレッジ内に移動し、および、ローカルネットワーク1450の一部であるHeNB1435にハンドオフするときに、MRAセッションは、LIPAセッションとして継続される。上記のLIPAに関係する例はまた、SIPTOに適用されてもよい。
ハンドオーバプロシージャの実施形態(CELL_FACHにおけるモビリティを含む)、および、アーキテクチャのオプションのコンテキストにおける関連する問題について以下で説明される。
非コアネットワークに関連するモビリティ(non-core network involved mobility)をサポートするHeNB拡張モビリティ(最適化されたモビリティとも称される)を説明する。このことは、HeNBと同一位置に配置されたLGWでLIPAおよびSIPTO、ならびに、HeNBおよびLGWが同一位置に配置されないアーキテクチャ構成に対するサポートを含んでもよい。
図15は、X2インタフェースを使用するHeNB間ハンドオーバプロシージャに対する例示的なシグナルフロー図1500である。シグナリングは、WTRU1505と、ソースHeNB1510と、ターゲットHeNB1515と、LGW1520と、MME1525と、SGW1530との間でフローしてもよい。ダウンリンクユーザプレーンデータは、LGW1520からソースHeNB1510へ、および、ソースHeNB1510からWTRU1505へ存在してもよい。汎用パケット無線サービス(GPRS)トンネリングプロトコル(GTP)ユーザプレーン(GTP−U)は、ソースHeNB1510とLGW1520との間で存在してもよい。X2インタフェースを介してリロケーションをトリガする決定がされてもよい(1)。ハンドオーバ要求が、ソースHeNB1510からターゲットHeNB1515に送信されてもよい(2)。ハンドオーバ要求肯定応答(ACK)が、ターゲットHeNB1515からソースHeNB1510に送信されてもよい(3)。データが、ソースHeNB1510からターゲットHeNB1515に転送されてもよい。WTRU1505が、ソースHeNB1510からデタッチし、および、ターゲットHeNB1515と同期してもよい。パス切替え要求が、ターゲットHeNB1515からMME1525に送信されてもよい(4)。修正ベアラ要求が、MME1525からSGW1530に送信されてもよく(5)、および、修正ベアラ応答が、SGW1530からMME1525に送信されてもよい(6)。パス切替え要求ACKが、MME1525からターゲットHeNB1515に送信されてもよい(7)。修正ベアラ要求が、ターゲットHeNB1515からLGW1520に送信されてもよく(8)、および、修正ベアラ応答が、LGW1520からターゲットHeNB1515に送信されてもよい(9)。ダウンリンクユーザプレーンデータは、LGW1520からターゲットHeNB1515に、および、ターゲットHeNB1515からWTRU1505に存在してもよい。GTP−Uが、ターゲットHeNB1515とLGW1520との間で存在してもよい。MME1525およびSGW1530がハンドオーバプロシージャに依然として関わっていないので、シグナルフロー図1500は、コアネットワークに対して完全に透過的ではない。
図16は、HNB−HNB間で最適化されたハンドオーバに対する例示的なシグナルフロー図1600である。シグナリングは、WTRU1605と、ソースHNB1610と、ターゲットHNB1615と、HNG−GW1620との間でフローしてもよい。無線ネットワークサブシステムアプリケーションパート(RNSAP)ユーザアダプテーション(RNA)リロケーション要求メッセージが、ソースHeNB1610からターゲットHeNB1615に送信されてもよい(1)。HNBアプリケーションパート(HNBAP)アクセス制御クエリが、ターゲットHeNB1615からHNB−GW1620に送信されてもよく(2a)、および、HNBAPアクセス制御クエリ応答が、HNB−GW1620からターゲットHeNB1615に送信されてもよい(2b)。HNBAPトランスポートネットワークレイヤ(TNL)更新要求が、ターゲットHeNB1615からHNB−GW1620に送信されてもよく(3a)、および、HNBAP TNL更新応答が、HNB−GW1620からターゲットHeNB1615に送信されてもよい(3b)。RNA直接転送/RNSAP拡張リロケーション応答が、ターゲットHNB1615からソースHNB1610に送信されてもよく(4)、および、RNA直接転送/RNSAPリロケーションコミットが、ソースHNB1610からターゲットHNB1615に送信されてもよい(5)。無線リソースコントローラ(RRC)無線ベアラ(RB)再構成メッセージが、ソースHNB1610からWTRU1605に送信されてもよい(6)。
ターゲットHNB1615は、WTRU1605同期試行を検出してもよい。RRC RB再構成完了メッセージが、WTRU1605からターゲットHNB1615に送信されてもよい(7)。HNBAPリロケーション完了メッセージが、ターゲットHNB1615からHNB−GW1620に送信されてもよい(8)。HNBAP WTRU登録解除メッセージが、HNB−GW1620からソースHNB1610に送信されてもよい(9)。RNA切断/RNSAP拡張リロケーションシグナリング転送メッセージが、ソースHNB1610からターゲットHNB1615に送信されてもよい(10)。UMTS地上無線アクセスネットワーク(UTRAN)の場合、Iurhインタフェースを通じてHNB−HNB間で最適化されたハンドオーバは、HNB−GW1620を通過する。
拡張モビリティ(非コアネットワークに関連するハンドオーバまたは透過的コアネットワークハンドオーバ(transparent core network handover))に対する実施形態及びプロシージャが、部分的ハンドオーバが存在する場合について説明される(すなわち、負荷条件または一部の他の理由に起因してターゲットシステムによって特定のベアラを許可することができない)。さらに、非コアネットワークに関連するモビリティのコンテキストにおける非WTRUに関連するモビリティ(サービング無線ネットワークサブシステム(SRNS)リロケーションなしのモビリティ)についても説明される。
HeNBおよびHNBが同一のLNまたはローカルホームネットワーク(LHN)において一緒に配置され、ならびに、同一のLGWに接続することができる配備シナリオが存在してもよい。この場合、HeNBとHNBとの間でサポートされることになるシームレスLIPAモビリティに対する実施形態についても説明される。これらの無線アクセス技術(RAT)間ハンドオーバ(inter-radio access technology handover)プロシージャは、ユーザプレーンデータにおいて途絶がなく、および、ユーザがハンドオーバの前後で同一のサービス品質(QoS)を受けることを保証する。
WTRUが一方のLGWと別のLGWと間でカバレッジエリアを移動するときのモビリティ(すなわち、LGW間モビリティ)のサポートに対する実施形態についても説明される。LGWにおいて変更がある場合、WTRUのIPアドレスは変更することが予期される。ユーザデータのフローに中断がなく、および、このような状況において一方のLGWサブシステムから別のLGWサブシステムにデータを転送するための実施形態についても説明される。
S1/Iuhインタフェース上の非WTRU関連プロシージャに対する実施形態についても説明される。これらの実施形態は、LHN毎に1または複数のLGWをサポートするという制限からの影響を考慮し、および、複数のLGWを通じてトラフィックをトンネリングすること、または、特定のタイプのトラフィックに対してLGWを完全にバイパスすることとは反対に、単一のLGWを通じてLHNにおけるすべてのHeNBからのトラフィックすべてをトンネリングするという問題を考慮している。
現在、WTRUがLHNから外へ移動するときに、LIPAサービスを非活性化する必要性がある。この要件を実装する実施形態が説明される。LHN識別子(LHN−ID)が使用されると仮定して、接続モードモビリティの間にLHN−IDを使用するための実施形態について説明される。
企業配備、ショッピングモール配備、または、空港ターミナルもしくは他の密集したホットスポット配備を検討するときの現在のアーキテクチャオプションは、セル密度、これらのセル間の近接(close proximity)、およびコアネットワークへのセル集約または集中(cell aggregation or concentration toward the core network)に対する機会を利用するようにさらに最適化されてもよい。
RAN共有のユースケース(use case)に対する実施形態についても説明される。RAN共有は、概して、RANネットワークを共有する2以上のオペレータに関するものである。例えば、第三世代(3G)ネットワークと配備しているロングタームエボリューション(LTE)の両方を有している2つのオペレータは、いくつかのエリアにおける取組みに、他のいくつかの地域に個別のRANを配備しながら、参加することを決定することがある。コアネットワークを有しているオペレータは、別のオペレータからRANをリースまたは共有することを決定することができる。HeNBのコンテキストにおいて、RAN共有は、エンタープライズまたはショッピングモールシナリオで行われてもよい。例えば、会社Xの従業員は、会社Xにフェムトセルサービスを提供するオペレータでないことがある、異なるオペレータからのセルラサービス加入を有することができる。このような場合、従業員は、ローミングアグリーメントを通じて会社Xの施設上にいる間に、フェムトセルからセルラサービスを受けることができる。しかし、このことは、ローミングアグリーメントが、従業員にさらなるコストとならないように、および、従業員が、サービスを会社Xに提供するフェムトセルネットワークプロバイダによって提供される優遇措置を得るような契約であると仮定している。
別のモデルは、オペレータ間でRAN共有を有することになる場合がある。従業員は、自分たちが選択したオペレータからサービスを自由に得ることができるが、オペレータ間のRAN共有アグリーメントを通じて限定加入者グループ(CSG)の優遇措置および課金方式の利益を得ることができる。
HeNBのコンテキストにおけるRAN共有の別のユースケースは、ショッピングモールシナリオである。モール全体に配置されたフェムトセルが一面を覆うことがある。数個のオペレータが、共通モールフェムトネットワークを通じてモールにおける小売店にサービスを提供することができる。
ここで考察されているRANの問題は、これが特にLIPA・SIPTOサービス、および、モビリティサポートに対する構成、複数のコアネットワークの間でLGWを共有することの予想される結果(implication)、ならびに、ローミングするときの予想される結果に関係するように、LIPA/SIPTOとRAN共有との間の相互のやり取りを含む。
同等のパブリックランドモバイルネットワーク(PLMN)(発展型PLMN(ePLMN))のサポートに対する実施形態は、ePLMNにおけるLIPA/SIPTOサービス(アウトバウンド/インバウンドハンドオーバを含むセッション管理およびモビリティ管理に対する影響)のサポートを含めて説明される。
これらの問題のうちの1つは、UTRANにおいて発生するCELL_FACHモビリティである。CELL_FACH状態は、RRC_CONNECTED状態の下位状態であり、そこでは、WTRUは接続モードにあるが、少量のデータを送信および/または受信することができる。CELL_FACH状態では、WTRUは、セル更新などの無線リソース制御(RRC)シグナリングプロシージャを実行することができる。このことは、RRC更新タイマの満了、データ量の報告を実行すること、または、WTRUが別のセルに再選択しおよび新たなセルの再選択/新たなセル内へのモビリティに関してネットワーク(RAN)に通知することを望んでいることなどのいくつかの理由によるものとしてもよい。CELL_FACHでは、WTRUは、別のセルに移動し、または、再選択する場合に、これは接続モードの間にそのようにする。このことは、アイドルモードセル再選択とは異なる。
CELL_FACH状態にいる間にWTRUが別のセルを再選択した後、ターゲットセル/無線ネットワークコントローラ(RNC)(ソースおよびターゲットRNCは同一であってもよい)は、WTRUに対するサービスが維持されるようにソースセルからWTRUのコンテキストをフェッチする必要がある場合がある。
WTRUがHNBに接続され、および、HNBにおいて確立されたLIPA PDN接続を有している場合、LGWは、HNBと同一位置に配置されてもよく、または、LGWはスタンドアロンである。LIPA PDN接続を有しているWTRUがCELL_FACHにおいて動作している場合、既存のプロシージャにより、WTRUが近隣における別のマクロセルへのセル再選択を実行する可能性がある。このことが発生する場合、WTRUは、先に説明されているように、そのモビリティ、したがって新たなセルの選択に関してRAN/ネットワークに通知するセル更新プロシージャを実行する。したがって、CELL_FACHモビリティは、接続モードにおいて発生するWTRUベースのモビリティであってもよい。LIPAモビリティ(すなわち、LIPA PDN接続が存在する場合のWTRUのハンドオーバ)に対して、ソースHNBは、任意のハンドオーバを実行する前に、最終的なハンドオーバに関してLGWに通知してもよく、および、LGWはMMEへのPDN接続のリリースをトリガする。しかし、HNBは、CELL_FACHにおいてWTRUのモビリティに気づかないことがある。
したがって、LIPA PDN接続およびリソースのリリースをトリガするHNBの振舞いは、CELL_FACHモビリティに使用されなくてもよい。したがって、WTRUがソースセルになくても、LIPA PDN接続はセットアップのままでいることができ、および、リソースは使用中のままでいることができる。SGSNは、WTRUがLIPA PDN接続が確立された元のセルから移動したことをSGSNが知っている可能性があるので、CELL_FACHモビリティは、このことが発生する場合は、SGSNをトリガしてLIPA PDN接続を非活性化することができるノンアクセスストラタム(NAS)プロシージャを必ずしもトリガしなくてもよい。したがって、LIPA PDN接続があるときに、CELL_FACHモビリティに対処する実施形態が説明される。LIPA PDN接続が確立されたHNBの外へのモビリティは、LIPA PDN接続の非活性化につながる場合がある。しかし、LGWがスタンドアロンであるとき、別のHNBもしくはマクロセルへのCELL_FACHにおけるモビリティが、必ずしも、LIPA PDNの非活性化を意味することではなく、または、非活性化につながるわけではない。
MRAツーLIPAハンドオーバ(MRA to LIPA handover)、またはその逆に対して、以下のシナリオが識別されてもよい。図17に示されている第1のシナリオ1700において、WTRU1705はセル1710にある(限定加入者グループ(CSG)のみの下で、またはハイブリッドモードのCSGの下で、マクロセルまたはHeNBセルのいずれか動作している)。セル1710の主な特性は、それがHeNB1725と同一位置に配置することができる1または複数のLGW1720によってサービスされるローカルネットワーク1715の一部でないという点である。MRAセッションは、ローカルネットワーク1715の外から、IPAパーミッションで、または、IPAパーミッションなしで開始されてもよい。
図18に示されている第2のシナリオ1800において、WTRU1805は、ローカルネットワーク1815の一部であるセル1810にあってもよい(CSGサービスを提供するHeNBセル、または、CSGサービスを提供するマクロセルのいずれか)。しかし、WTRU1805は、加入情報によりセル1810からLIPAアクセスを得ることを許可されない。WTRU1805は、依然として、オペレータのネットワークにアクセスし、および、通常のPGWを通じてPDN接続を確立してもよい。MRAセッションは、同一のローカルネットワーク1815内でLIPAパーミッションなしでCSGから開始されてもよい。
上記特定された2つのシナリオで多数の問題点が識別されてもよい。マクロセルまたはそのローカルネットワークの一部でないH(e)NBセルのいずれかに接続されているWTRU(図17に示されているように)は、MRA特性を通じてローカルサービスにアクセスすることを試みてもよい。生じうる問題の1つは、セルがLIPAサービスをサポートしないCSGで構成されている場合(すなわち、ソースCSGがLIPAサービスをサポートしない)にどのようにリモートアクセスを取り扱うかである。WTRUがMRAを通じてローカルサービスにアクセスすることを試みている間にハンドオーバが発生したとする場合、eNB/H(e)NBにおいて構成されているターゲットセルがCSGセルとして定義されている場合にとるべきステップ、および、CSGセルがWTRUに対するLIPAサービスを提供しない(すなわち、ターゲットCSGがLIPAサービスをサポートしない)ことは明らかである。WTRUは、図18においてCSG2 1830によって示されているように、このWTRUに対するLIPAサービスをサポートするCSGで構成されているH(e)NBに接続されたときに、ローカルネットワーク内でLGWを通じてLIPAサービスにアクセスすることができる。
同一のローカルネットワーク内に留まりながら、WTRU1805は、CSGで構成することができるが、WTRU1に対するLIPAサービスをサポートしないセル(例えば、CSG1 1825)に移動してもよい。WTRUがそのセル(例えば、CSG1 1825)におけるLIPAサービスを利用することを試みた場合、CSG1 1825がWTRU1805に対するLIPAサービスを許可しないので、その要求は拒絶されることがある。しかし、LIPAサービスの代わりにCSG1 1825に接続したままWTRU1805がMRAサービスを要求した場合に何が発生するか(すなわち、WTRU1805が許可されるべきか、および、この場合にシステムの振舞いがどのようなものか)は明確でない。加えて、WTRU1805がCSG2 1830においてLIPA接続を開始し、および、それがCSG1 1825へのハンドオーバを試みた場合に何が発生するか(すなわち、ハンドオーバが許可されるべきか、LIPA接続がMRA接続として扱われるべきかどうか、および、この場合にシステムの振舞いがどのようなものであるべきか)は明確でない。
本明細書では、いくつかのシステムエリア、例えば、システムアクセスおよびモビリティ管理、または、モビリティ管理およびハンドオーバに該当し得る例示的な方法を説明する。この目的のために、本明細書において以下で説明される方法は、これらのシステムエリアの下でグループ化されているが、これらがグループ化されるシステムエリアに限定されるべきでない。さらに、グルーピングは、方法の適用可能性を特定の問題/システムエリアに限定することを意図するものではない。したがって、方法は、いくつかのシステムエリア/プロシージャ(すなわち、RRC、ノンアクセスストラタム(NAS)、または、他の組合せもしくはレイヤ)に適用可能であり、他のシステムエリアの下にある他の方法と組み合わせても適用されてもよい。
本明細書では以下でLIPA PDN接続による拡張されたHeNBモビリティに対する実施形態について説明される。
上述のアーキテクチャ構成において、ユーザパスはHeNBからHeNBローカルネットワークに配置されたLGWに直接進む。さらに、LNの地理的エリア(企業、ショッピングモール、および、空港など)内で、ユーザは、HeNBのカバレッジエリア間を頻繁に移動してもよい。コアネットワーク上のシグナリング負荷を制限するために、そのようなローカルネットワーク内シグナリング(intra-local network signaling)またはフェムトネットワークのホスティングパーティ施設(hosting party premise)の境界内のシグナリングは、コアネットワークが関わることなくローカルノード内に含まれてもよい。WTRUが同一のLGWのカバレッジ内で一方のHeNBから他方に移動したときに、図15に示されているようにシグナリングがコアネットワーク(CN)を通ることなくハンドオーバプロシージャが実行されてもよい。
ソースHeNBは、ハンドオーバを要求するハンドオーバ要求メッセージをターゲットHeNBに送信してもよい。このメッセージにおいて、HeNBは、相関ID、LGW S5トンネルエンドポイント識別子(TEID)、または、ターゲットHeNBとLGWとの間で直接ユーザパスを可能にする他の情報とともに、ターゲットHeNBにおいて接続をセットアップするために必要なWTRUコンテキスト情報を送信してもよい。このメッセージを受信すると、ターゲットHeNBは、ハンドオーバ要求肯定応答で応答し、および、どのベアラを受け付けることができるかをHeNBに通知してもよい。次いで、ターゲットHeNBは、パス切替え要求を直接LGWに送信して、ダウンリンクデータパスをターゲットHeNBに変更してもよい。この場合、LGWは、レガシーパス切替えプロシージャの間に、モビリティ管理の役割およびMME−SGSNの対が行うローカルモビリティアンカリングポイントの役割の両方を行う。ターゲットHeNBはまた、ハンドオーバに関してHeNB GWに通知することによって、CNトラフィックに対するダウンリンクデータパスがターゲットHeNBに修正されてもよい。
HeNB GWが配備されていないケースでは、MME/SGWは、ハンドオーバに関して通知されることによって、CNダウンリンクトラフィックに対するデータパスを切り替えてもよい。このことは、LGWがパス切替え要求を受信したときに、LGWがメッセージをSGWに送信して、ユーザパスをターゲットHeNBに修正することによって達成されてもよい。LGWは、そのユーザパスをSGWが修正したことのインジケーションを受信した後に、パス切替え応答メッセージを送信してもよい。
別の代替的形態において、ならびに、LGWを通じてルーティングされるトラフィックが存在し(LIPAおよび非LIPAトラフィック)、および、CNに配置された別のPGWを通じてルーティングされるトラフィックが存在するシナリオについて、2つのパス切替えプロシージャが実行されてもよい(必要ならば同時に)。一方のパス切替えプロシージャがLGWに実行され、および、他方のパス切替えプロシージャがMMEに実行されてもよい。このことは、ベアラ修正プロシージャがSGWおよびPGWに実行されることにつながる。
拡張モビリティプロシージャは、LGWがS1パス上に配置されるアーキテクチャシナリオに適用されてもよい。このケースにおけるLGWは、HeNBのコンセントレータ(concentrator)として動作してもよい。パス切替え要求メッセージは、そのまま、LGWに進んでもよく、および、LGWは、LIPA PDN接続に対してデータパスを切り替えてもよい。LGWはS1パス上にあるので、これはまた、CNにおける任意のエンティティに通知することなくWTRUが有することができる他のCN PDN接続のユーザデータパスを変更してもよい。
HeNBとLGWとの間で直接的にパス切替えプロシージャが実行される場合、CN(すなわち、MME、SGW、およびSGSNなど)は、WTRUの新たなセルに気づかないことがある。このことは以下の問題を引き起こすことがある。CNは、CNがサービングセルを知らないので、セッション管理、および、WTRUにサービスを提供する正しいセルへのモビリティ管理プロシージャを実行することができない場合がある。この問題は、図7および8に関して説明されているスタンドアロンLGWのケースにおいて特に深刻である。
この問題に対処するための一実施形態では、サービング無線ネットワークサブシステム(SRNS)リロケーションなしのハンドオーバ、すなわち、WTRUのSRNSがそのハンドオーバまたは類似のハンドオーバプロシージャの前後において同一のままでいる、ハンドオーバプロシージャが実行されてもよい。図19は、SRNSリロケーションなしのハンドオーバ後のUプレーンおよびCプレーンの例示的なシグナリング図1900を示しており、そこでは、制御シグナリングパスは変更されないが、ユーザデータパスはターゲットHeNB1905へ切り替えられる。WTRU1910は、無線リソース割り当てに関してターゲットHeNB1905にハンドオーバされてもよく(すなわち、ターゲットHeNB1905はドリフト無線ネットワークサブシステム(DRNS)の役割を果たし、および、WTRU1910によって使用される無線リソースを制御する)、および、SRNS1915とWTRU1910との間の接続に対し、これらの無線リソースでSRNS1915をサポートする。ハンドオーバの後、SRNS1915は、WTRU1910とRAN(例えば、EUTRAN、およびUTRANなど)との間の無線接続を担当することを継続する。SRNS1915は、S1またはIu/Iuhを終了してもよい。この実施形態では、CN1920とRANとの間の制御プレーンにおけるシグナリング(S1−MME、およびIu/Iuh上のトラフィック)は、SRNS1915(ソースおよびサービングHeNB)を通じてルーティングされ続けてもよく、制御プレーンにおいてパス切替えは存在しない。ユーザトラフィック(S1−U、Iu/Iuh上のユーザプレーントラフィック)は、LGW1925から直接、ターゲットHeNBへルーティングされてもよい。
代わりに、図20は、SRNSリロケーションなしのハンドオーバ後のUプレーンおよびCプレーンの例示的なシグナリング図2000を示しており、そこでは、制御シグナリングおよびデータパスは両方とも同一のままであり、ならびに、SRNS/ソースHeNB2005を通じてルーティングされる。WTRU2010は、ターゲットHeNB2015にハンドオーバされてもよい。ハンドオーバの後、SRNS2005は、WTRU2010とRAN(例えば、EUTRAN、およびUTRANなど)との間の無線接続を担当することを継続する。SRNS2005は、S1またはIu/Iuhを終了してもよい。この実施形態では、CN2020とRANとの間の制御プレーンにおけるシグナリング(S1−MME、および、Iu/Iuh上のトラフィック)は、SRNS2005(ソースおよびサービングHeNB)を通じてルーティングされてもよく、制御プレーンにおいてパス切替えは存在しない。ユーザトラフィックは、SRNS2005(ソースおよびサービングHeNB)を通じて、LGW2025にルーティングされてもよい。
SRNSリロケーションなしのモビリティに対する実施形態および関連する実施形態は、図7〜図12に示されているアーキテクチャ構成に適用されてもよい。さらに、図10乃至図12に示されているアーキテクチャ構成のケースでは、制御プレーンパスおよびユーザプレーンパスは、CNが関わることなくLGWによって終了される単一のパス切替えプロシージャを使用して切り替えられてもよい。
別の実施形態では、図21は、SRNSリロケーションなしのハンドオーバ後のUプレーンおよびCプレーンのシグナリングの例示的なシグナリング図2100であり、そこでは、制御シグナリングパスは同一のままであるが、一部のデータパスは同一のままであり、および、一部のデータパスは切り替えられる。WTRU2110は、ターゲットHeNB2105にハンドオーバされる。ハンドオーバの後、SRNS2115は、WTRU2110とRAN(例えば、EUTRAN、およびUTRANなど)との間の無線接続を担当することを継続する。SRNS2110は、S1またはIu/Iuhを終了してもよい。この実施形態では、CN2120とRANとの間の制御プレーンにおけるシグナリング(S1−MME、およびIu/Iuhなどの上のトラフィック)は、SRNS2115(ソースおよびサービングHeNB)を通じてルーティングされ続けてもよく、制御プレーンにおいてパス切替えは存在しない。ユーザプレーンパスは、同一のままであり、および、LGW2125にルーティングされてもよく、または、またはCN2120に切り替えられてもよい。非SRNSリロケーション(WTRUは関わらない)ハンドオーバは、LIPAベアラまたはベアラの組(すなわち、ユーザプレーン2140)に対して実行されてもよく、一方、SRNSリロケーションハンドオーバは、他のベアラ(すなわち、ユーザプレーン2150)に対して実行されてもよい。このようなケースでは、2つのRNSは、SRNSの役割を実行しており、各RNSはベアラまたはPDN接続の所与のサブセットに対するものである。
LIPA PDNは、CSG毎の加入者ごとをベースに許可されてもよい。このケースでは、加入者チェックは、ハンドオーバプロシージャの前またはハンドオーバプロシージャの間にローカルで実行されてもよい。システムは、WTRU加入者情報がターゲットCSGにおいてLIPAサービスを許可することを保証する必要がない場合がある。加入者情報は、CSG内ハンドオーバのケースではチェックされなくてもよい。
ローカル加入者チェックは、以下の例示的な方法を使用して実行されてもよい。1つの例示的方法において、LGWは、LIPA PDN接続を確立すると、CNノードから加入者情報を取得してもよい。LGWは、パス切替え要求メッセージを受信したときに加入者をチェックしてもよい。LIPA接続がターゲットHeNBにおいて許可されない場合、パス切替え失敗メッセージがターゲットHeNBに送信されてもよい。別の例示的な方法では、加入者情報において更新がある場合、新たな情報がCNによってLGWに送信されてもよい。ソースまたはターゲットHeNBは、加入者情報を有していてもよい。これらのノードは、LGWが加入者情報を有している事象において、CNから直接的に、または、LGWからのいずれかで、この情報を取得してもよい。
図14に示されているハンドオーバプロシージャは、HNBがLGWに接続され、および、WTRUがアクティブなLIPA PDN接続を有しているときに修正されてもよい。ターゲットHNBが、ハンドオーバに対する要求を受信するときに、LIPAが(2a)および(2b)においてターゲットセルで許可されているかをHNBーGWにクエリしてもよい。このことは、HNB−GWがCNからのLIPA CSGおよびLIPA加入者情報をすでに有していると想定することができる。(3)では、ターゲットHNBは、TNL更新要求をLGWに送信して、ターゲットHNBとLGWとの間でトンネルを作成してもよい。(4−6)において、ソースHNBおよびWTRUは、ハンドオーバ、および、ターゲットHNBに転送されることになるベアラに関して通知されてもよい。LIPAベアラをターゲットHNBに転送することができない場合、WTRUは、(6)において通知されてもよく、および、LIPA PDPのコンテキストを非活性化するよう要求されてもよい。
WTRUが(6)でハンドオーバコマンドを受信した後、それはターゲットHNBに接続してもよい。次いで、ターゲットHNBは、リロケーションメッセージをHNB−GWに送信して、ユーザパスをターゲットHNBへ切り替えてもよい。LIPA PDPコンテキストがまたハンドオーバされるケースでは、パス切替えはLGWにおいて実行されてもよい。このことは、以下の例示的な方法によって実行されてもよい。1つの例示的方法では、ターゲットHNBは、(8)において、2つのリロケーション完了メッセージ、1つはHNB−GWに、および、他方はLGWに、を送信してもよい。LGWがこのメッセージを受信するときに、それはデータパスをターゲットHNBに変更してもよい。代わりに、HNB−GWがリロケーション完了メッセージを受信するときに、それは、このメッセージまたはインジケーションをSGSNに転送してもよい。次いで、SGSNが、パスをターゲットHNBへ切り替えるようにLGWに要求してもよい。
LIPAがアクセス可能でないときのモビリティの間にLIPAベアラの処理に対する実施形態が本明細書で説明される。モビリティの間に、および、LIPAベアラがターゲットセルにおいてサポートされていないときに、HeNBは、ノード内シグナリングを使用して、同一位置に配置されたLGWに、LIPA PDN接続を解放するよう要求してもよい。HeNBは、WTRUがLIPA PDN接続を有していることを、WTRU(発展型)無線アクセスベアラ((E)RAB)コンテキストにおける相関IDの存在から判定してもよい。次いで、LGWは、PGW開始ベアラ非活性化プロシージャを使用してLIPA PDN接続の解放を開始し、および、完了してもよい。HeNBは、WTRUの(E)RABコンテキストが相関IDに対して明確になるまで、ターゲットRANへのハンドオーバ準備プロシージャを続行しなくてもよい。同一位置に配置されないLGWのケースでは、非活性化は、ターゲットセル、LGW、またはCN(例えば、MME、SGSN、およびHeNB−GWなど)によって開始されてもよい。例えば、WTRUがLIPAサービスに対する認可されていないとき、WTRUがLHNの外へ移動し、または、ターゲットセルの中に移動するときに、LIPAベアラは、ターゲットセル、LGW、もしくはCN(例えば、MME、SGSN、およびH(e)NB−GWなど)によって非活性化されてもよい。WTRUがLHNの外へ移動したことの検出は、LHN識別の変更に基づいてもよい。
代替的実施形態において、ソースHeNB(またはターゲットHeNBもしくは任意の他のノード)は、ベアラがターゲットセルにおいてサポートされているかいないかに関わらず、LIPAベアラを非活性化しなくてもよい。代わりに、本明細書で以下において説明されているLIPAベアラサスペンションおよび再開に対する実施形態が使用されてもよい。
本明細書では、CELL_FACHにおけるLIPA PDN接続非活性化に対する例示的な方法が説明される。第1の例示的な方法は、CELL_FACH状態にあるWTRUが、LIPA PDN接続が存在するHNBの外へ移動するときに(例えば、マクロセルに)、LIPA PDN非活性化を求めてもよい。
ネットワーク(例えば、UTRANおよび/またはSGSN)は、セル更新プロシージャの間、または、CELL_FACHモビリティの間に、LIPA PDN接続を非活性化してもよい。代わりに、非活性化は、モビリティが実行された後に行われてもよい。
WTRUが、それがLIPA PDN接続を有していることを知っている場合、WTRUは、ルーティングエリア識別が変化していなかった場合でさえも、CELL_FACHモビリティの結果として、セル更新プロシージャの間にルーティングエリア更新(RAU)を実行してもよい(すなわち、セル更新の代わり、または、セル更新に加えてRAU送信する)。WTRUが、それがLIPA PDN接続を有していることを知っている場合(セッション管理メッセージ/プロシージャにおけるSGSNなどのネットワークから受信されたインジケーションに基づいて)、RAUは、CELL_FACHモビリティが発生し、および、WTRUが別のセル(マクロまたはHNB)を移動/再選択した後に、送信されてもよい。
SGSNは、RNCリロケーションプロシージャの結果として(リロケーションが完了しようとしている間、または、完了した後)、WTRUのモビリティに気がつくことがある。次いで、SGSNは、LIPA PDN接続の非活性化をトリガしてもよく、したがって、CNにおいて(すなわち、LGWへ)、またWTRUへリソースを解放してもよい。
SGSNが、ターゲットRNCからRNCリロケーションに対する要求を受信するときに、SGSNは、WTRUが新たなセルに移動しているかを検証してもよい(WTRUのコンテキストをチェックし、および、潜在的/ターゲットRNC/ターゲットセルとソースRNC/セルとを比較してこれが変化しているかを確認することによって)。代わりに、または、加えて、SGSNは、ターゲットセル識別(リロケーション要求を介して提供される)を、LIPA PDN接続が確立されたソースセルのセル識別と比較してもよい。これら2つの識別子が一致しない場合、SGSNは、WTRUが移動した(または移動している)と結論付けてもよい。あるいは、RNCのリロケーションに対する要求が、LGWおよびWTRUへのLIPA PDN接続を非活性化するようSGSNをトリガしてもよい。
代わりに、SGSNは、LGWアドレスがRNCリロケーション要求において提供されているかを検証してもよい。そうである場合は、SGSNは、LGWアドレスをWTRUのLIPA PDN接続に使用されているLGWと比較してもよい。これが同一で場合は、または、LGWのアドレスが提供されていなかった場合、SGSNは、WTRUがソースセルの外へ移動したと結論付けてもよい。LTEリリース10の仕様では、LGWアドレスは、RNCリロケーションを実行するためのSGSNに関する要求に含まれていない。一実施形態では、このようなメッセージ/要求はまた、ターゲットセル(例えば、ターゲットHNB)が接続するLGWアドレスを含んでもよい。SGSNに関するリロケーション要求は、ターゲットセル/RNCにおいてWTRUから受信されたセル更新(ソースへの、したがってSGSNへのリロケーション要求をトリガする)に起因して、ソースRNCによって送信されてもよい。実施形態は、SGSNへのリロケーション要求がソースRNCまたはターゲットRNCによって送信されるかに関わらず適用されてもよい。さらに、ターゲットセル/RNCは、ターゲットセルがLGWに接続しているかをソースに示してもよく、そうである場合は、LGWアドレスを提供してもよい。
さらに、ソースRNC/HNBが、ターゲットRNC/セルがLIPAモビリティをサポートしていないことを知っている場合、ソースRNC/HNBは、リロケーションプロシージャの一部としてSGSNにこのインジケーションを提供してもよい。ソースRNC/HNBはまた、ターゲットRNC/HNBがLGWに接続しているかをSGSNに示してもよく、および、場合によっては、ターゲットRNC/セル/HNBによって示されるようにLGWのアドレスを提供してもよい。
SGSNが、WTRUが移動し、または、移動していると結論付ける/気づいた場合(すなわち、RNCリロケーションを実行する要求の間に)、SGSNは、LIPA PDN接続を非活性化し、および、LGWおよび/またはHNB(LIPA PDN接続が確立されれた)にリソースを解放してもよい。あるいは、SGSNは、HNB(LIPA PDN接続が確立された)にリソースを解放してもよく、次いで、LGWにリソースを解放してもよい。SGSNはまた、RNCリロケーションが実行されている間、または、完了した後に、LIPA PDN接続を非活性化するようWTRUに要求してもよい。
本明細書全体を通じて、RNCリロケーション要求は、RNCリロケーションプロシージャを指す。RNCとSGSNとの間の実際のメッセージは、異なって識別されてもよいが、プロシージャは同一であってもよい。例えば、実際に使用されるRNCリロケーションメッセージは、「relocation required」と呼ばれてもよい。
代替的一実施形態では、ソースRNCは、Relocation RequiredメッセージをSGSNに送信する前に、最初に、潜在的モビリティについてLGWに通知してもよい。次いで、LGWは、LIPA PDN接続を非活性化してもよく、および、SGSNに、非活性化に対する理由が、ソースHNB/RNCによって示されるように、モビリティ、RNCリロケーション、または、セル更新に起因していることを示してもよい。
本明細書全体を通じて、ソースRNCは、ソースHNBを指してもよい(すなわち、これらは、同一のノードであり、および、ソースRNCは、ソースHNB、ソースHNB GW、またはソースRNCノードを指すために使用されてもよい)。本明細書全体を通じて、RNCを指すことは、ソースRNCが、あるメッセージをSGSNに送信している(例えば、「リロケーションが要求された」)実際のエンティティであってもよい、HNBに要求を往復して中継するかのように解釈されてもよい。したがって、ソースHNB GWは、ソースRNCであるが中継ノードとして動作していてもよい。あるいは、RNCの役割は、HNB GWによって引き受けられてもよく、当該HNB GWは、他のメッセージを介して、もしくは、同一のメッセージを使用することによって、進行中であるメッセージ/プロシージャについて、HNBが実際のRND、および、中継ノードであったHNB GWであったかのようにHNBに通知してもよい。HNBおよび/またはRNCは、ハンドオーバ/RNCリロケーションについて、ならびに、MMEへのLIPA PDN接続、および、LGWとソースHNB/RNC/HNB GWとの間のLIPA PDN接続を解放する必要性について、LGWに通知する役割を担ってもよい。
HNB/ソースRNCは、LIPA PDN接続を、接続モードハンドオーバが発生されることになるかのように扱ってもよい(すなわち、LIPA PDN接続はリロケーションの前に非活性化される)。さらに、LGWはまた、ソースHNB/RNC/HNB GWをトリガしてリロケーション要求を継続する非活性化の完了についてHNBに通知してもよい(すなわち、LIPA PDN非活性化が行われた後)。HNBは、リロケーション要求メッセージをSGSNに送信してもよい。SGSNは、リロケーション要求の受信がされると(LGWへの、および/または、S4インタフェースが存在する場合には、WTRUへの)、LIPA PDN接続を非活性化してもよく、したがって、ターゲットRNCへのLIPAコンテキストを含まなくてもよい。
あるいは、LIPA PDNの非活性化が、SGSNへのリロケーションに対する要求が送信される前に行われる場合、SGSNは、LIPA PDN接続がソースRNC/HNBによって解放されたかを検証してもよい。そうでない場合、SGSNはそのする動作を行ってもよく、または、リロケーションを拒絶し、および、ソースRNC/HNBに、拒絶の理由がLIPA PDN接続が非活性化されていないことであることを示してもよい。次いで、ソースRNC/HNBは、最初に、LIPA PDN接続を非活性化し(接続モードハンドオーバに使用されるのと同一のプロシージャにより)、および、ソースRNC/HNBは、SGSNへのリロケーションプロシージャを再試行してもよい。
あるいは、SGSNは、ソースRNCに、リロケーションコマンドを介して、LIPA PDN接続が非活性化されたことを示してもよく、および、HNBは、次いで、LIPAリソースを解放するようにLGWに通知してもよい。あるいは、SGSNは、ソースRNCに(またはソースHNB)、リロケーションコマンドを介して、LIPA PDN接続がハンドオーバの前に解放される必要があることを通知してもよく、および、HNBは、次いで、LIPA PDN接続を非活性化する必要性についてLGWに通知することを進めてもよい。あるいは、ソースRNC/HNB/SGSNは、最初に、LIPAコンテキストをターゲットRNCに含めることなく、ハンドオーバ/リロケーションを進めてもよく、次いで、リロケーションと並行して、またが、リロケーションが完了した後に、ソースHNB/RNCは、LIPA PDN接続を非活性化するようにLGWに通知してもよい。
WTRUのCELL_FACHモビリティが完了した後、SGSNは、WTRUへのLIPA PDN接続の非活性化をトリガしてもよい。例えば、SGSNがターゲットRNCからリロケーション完了メッセージを受信するときに、SGSNは、LGWへの接続を非活性化してもよく(すでにそうしていなければ)、および、WTRUへのLIPA PDN接続を非活性化してもよい。
CELL_FACHモビリティ(例えば、セル更新プロシージャ)が、SGSNの変更つながる場合、古い/ソースSGSNは、LIPAコンテキストをターゲット/新SGSNに転送しなくてもよく(例えば、リロケーション転送要求において)、および、ソースSGSNは、LIPAベアラまたはコンテキストを含まなくてもよい。
WTRUは、それがLIPA PDN接続が存在することを知っている場合にCELL_FACHモビリティを無効化してもよい。
あるいは、ソースRNC/HNBがRNCリロケーションを実行する要求を受信したときに、ソースRNC/HNBは、対象のWTRUに対するアクティブなLIPA PDN接続が存在する場合に、リロケーションを実行しないことを選択してもよい。したがって、ソースRNCは、制御パスとデータパスの両方に対するアンカリングポイントのままであってもよい。さらに、ソースRNCは、確立されたトンネルを介してLIPAデータをターゲットRNCに転送することを維持してもよく、および、LIPA PDN接続が維持されてもよい。SGSNは、例えば、リロケーション要求を拒絶し、ならびに、新たな原因コードを使用してソースRNC/HNBに、アンカリングポイントを維持し、および、LIPAデータをターゲットRNCへ転送するように通知することによって、ソースRNC/HNBにそうするように通知してもよい。
あるいは、WTRUが非LIPAベアラを有している場合、ネットワークは、RNCリロケーションが実行されていない場合でさえも、LIPAベアラを非活性化し、および、非LIPAベアラを維持することを決定してもよい。このことは、ソースRNC/HNBにおける決定/構成に基づいてもよく、または、SGSNにおける決定/構成に基づいていてもよい。
別の実施形態では、UPLINK SIGNALING TRANSFERメッセージが、ターゲットRNCによって使用されて、共通制御チャネル(CCCH)上で受信されたUuメッセージをサービングRNC(SRNC)に転送してもよい。セル更新は、これらのメッセージのうちの1つである。セル更新プロシージャの間に、UPLINK SIGNALING TRANSFERメッセージを受信すると、ソースRNCは、SRNC無線ネットワーク一時識別子(S−RNTI)を検証してもよく、および、ターゲットRNCに移動したWTRUがLIPAベアラを有していたかを判定してもよい。S−RNTIによって識別されたWTRUがLIPAベアラを有していた場合、ソースRNCは、これらのベアラをリリースすることができることを同一位置に配置されたLGWに通知してもよい。
実施形態は、選択されたアーキテクチャに依存してもよい。例えば、HNBは、Sxxインタフェースを使用して、LGWにおけるLIPAリソースを解放してもよい。図7乃至図9で表されているようなアーキテクチャソリューション1について、新たな制御プロトコルが導入されてもよく、または、IuhもしくはIuhrプロトコルが修正されてHNB GWまたはHNB自体がLGWにおけるLIPAリソースの開放を要求することを可能にすることができる。
上記の実施形態すべては、ソースRNCおよびターゲットRNCが同一のノードである場合、または、これらが異なるノードである場合に適用してもよい。
LTEリリース11では、LGWは、ローカルネットワーク(LN)においてスタンドアロンであってもよく、そのため、HeNB間のWTRUモビリティは、LIPA PDN接続の非活性化を必ずしもトリガしなくてもよい。WTRUがLNからマクロレベルに移動するときのケースについて、LIPAサービス継続性がそのマクロセルから提供されない場合、LIPA PDN接続非活性化が行われてもよい。このケースでは、LTEリリース10について本明細書において上述されたCELL_FACHモビリティに対する実施形態が実装されてもよい。
以下の実施形態は、WTRUがLN PDN接続においてLIPAまたはSIPTOを有していると仮定して、1つのHeNBから他方へのCELL_FACHモビリティに対して以下の実施形態が提供される。
WTRUが、それがLIPA PDN接続を有していることを知っている場合、WTRUは、このインジケーションをセル更新メッセージに含めてもよい(これは、セル更新がCELL_FACHにおけるモビリティに起因する場合であっても適用してもよい)。ターゲットセル(ソースセルがターゲットセルであってもよい)が、セル更新メッセージを受信するときに(単に、CELL_FACHにおけるモビリティに起因するものではなく)、ターゲットセル/HeNBは、CN(例えば、SGSN)に、WTRUがセル更新を送信するターゲットセルのセルIDについて通知してもよい。このことは、RNCを介して行われてもよい。次いで、CN/SGSNは、この情報を使用して、LIPAベアラ/サービスが例えば加入者情報に基づいて、ターゲットHeNBで継続されてもよいか否かを決定してもよい。ターゲットセルは、コンテキストのフェッチ(fetching)が実行される前に(例えば、必要であれば、HNB間のフォワードアクセスチャネル(FACH)モビリティに起因して)この情報をCNに送信してもよい。あるいは、このことは、WTRUコンテキストがソースHNBからフェッチされた後に行われてもよい。
セル更新プロシージャの間に(例えば、CELL_FACHにおけるWTRUのモビリティに起因して)、WTRUコンテキストがフェッチされ、および、ターゲットセルに転送される前に、ローカルネットワークサービスにおけるLIPA/SIPTOサービスをターゲットセルにおいて継続することができるか否かを検証してもよい。このチェックは、ソースセルと通信することによって、またはCN(SGSNであってもよい)と通信することによってターゲットセルにより行われてもよい。例えば、ターゲットHNBは、対象のWTRUに対してセル更新プロシージャが差し迫っていることをCN/SGSNに通知してもよい。次いで、SGSNは、LIPA/SIPTOサービスが、WTRUに対してそれがもし存在する場合は、ターゲットセルにおいて継続することができるか否かを検証してもよい。SGSNはまた、ターゲットHNBに応答してもよく、ならびに、セル更新を受け付けることができるかを示してもよく、または、LIPA/SIPTOサービスを継続することができるか否かを示してもよい。SGSNはまた、LGWアドレスおよび/またはLIPA/SIPTOサービスを継続するために必要な他の情報を提供してもよい。この情報は、例えば、相関IDであってもよい。CNによるこのチェックは、コンテキストがWTRUに対してフェッチされた後に実行されてもよい。SGSNからのこのようなアドレス情報の存在は、LIPA/SIPTOがWTRUに対して維持されてもよいことをターゲットセルに暗示するものであってもよい。CNは、サービスがLIPA、SIPTO、またはその両方であるかを示す情報をターゲットセルに提供してもよい。ルール/加入者が、WTRUがターゲットにおいてサービス継続性を有することができることを示す場合、CN/SGSNはセル更新を拒絶してもよい。このことは、プロシージャの失敗、または、WTRUをソースセルに戻すリダイレクションをつながってもよい。
CNは、セル更新プロシージャの前または後にチェックを実行してもよい。CNによって行われる検証は、ローカルネットワークにおけるLIPA/SIPTOがターゲットにおいて提供されてもよいかを判定することを含んでもよい。このことは、WTRU加入者情報、および/または、ターゲットセルがHNBに接続するか否かなどに基づいていてもよい。CNは、例えば、サービスをターゲットにおいて維持することができない場合に、LIPA/SIPTO PDN接続を非活性化することを決定してもよい。この非活性化は、セル更新プロシージャが完了する前または後に行われてもよい。
ソースセルは、ターゲットセルがWTRUに対してLIPA/SIPTOサービス継続性を提供することができるかを検証してもよい。このことは、ターゲットセルがLGWに接続するか、および/または、WTRUの加入者がターゲットセルにおけるこのサービス継続性を許可するかに基づいていてもよい。この情報は、ソースセルにおいてすでに利用可能であってもよい。あるいは、ソースセルは、CNノード(SGSNまたはLGWであってもよい)をプローブ(probe)して、このLIPA/SIPTO PDN接続をターゲットセルにおいて維持することができるかを検証してもよい。ソースは、このインジケーションをSGSNに送信し、ならびに、ターゲットセルおよびLGWの識別を提供することによって、SGSNがソースセルに応答し、ならびに、LIPA/SIPTOをターゲットセルにおいて維持することができるかを示すようにしてもよい。SGSN/CNが、このサービスを維持することができることを示す場合、ソースは、コンテキストをターゲットセルに提供し、および、LIPA/SIPTOコンテキスト/ベアラ/情報を含めてもよい。
あるいは、CN/SGSNが、サービスをターゲットセルにおいて維持することができないことを示す場合、ソースセルは、LIPA/SIPTO PDN接続を非活性化することをLGWに通知してもよい。SGSNはまた、この非活性化も実行し、および、それをソースHNBに示してもよい。ソース/ターゲットセルおよびCN/SGSNは、これらのノード間の通信に使用されるインタフェース上で既存のメッセージまたは新たなメッセージを使用することによって、本明細書で上述された要求/応答を介して情報を交換してもよい。このことは、本明細書で上述されているすべての実施形態に適用可能である。したがって、ソースセルは、ローカル情報またはCN/SGSNからの情報に基づいて、LIPA/SIPTOコンテキスト/ベアラ/情報をセル交信プロシージャの一部としてターゲットセルに含めるか、または、含めないかを決定してもよい。サービスを維持することができる場合、ターゲットセルは、LIPA/SIPTOトラフィックに対するトンネル/ユーザパスを作成することをLGWに通知してもよい。あるいは、CNまたはソースHNBは、サービスをターゲットセルにおいて維持することができるかの決定に基づいて、ターゲットHNBへのデータパスを更新することをLGWに通知してもよい。
LIPAベアラのサスペンションおよび再開に対する実施形態について以下で説明される。シームレスなLIPAモビリティは、LIPAベアラのサスペンションおよび再開を通じて遂行されてもよい。WTRUがLIPAカバレッジの外へ移動するときに、LIPAベアラはサスペンドされてもよい。LIPAベアラは、WTRUがLIPAをサポートする別のセルに戻るときに再開されてもよい。ソースセルが、LIPAベアラをターゲットセルにハンドオーバすることができないと判定したときのハンドオーバプロシージャの間に、ソースセルはこれらのベアラに対するコンテキストを取り除き、および、LIPA PDN接続を非活性化することをLGW、MME、または他のノードに通知しない。それは、PDN接続がまだアクティブであるが、ターゲットセルにおいてはベアラが現在セットアップされていないことを示す特別なインジケーションをLGWおよびCNノードに送信してもよい。このインジケーションを受信すると、LGWは、WTRUに対するすべてのダウンリンク(DL)トラフィックをバッファリングすることを開始してもよい。バッファリングされたトラフィックは、WTRUがLIPAカバレッジに入り、および、LIPAベアラがLIPAトラフィックに再開されるときに、WTRUに送信されてもよい。LIPAベアラがサスペンドされたときに開始するタイマがネットワークにおいて存在してもよく、および、WTRUが、タイマが満了する前にLIPAカバレッジに戻らない場合に、LIPA PDN接続は非活性化され、および、LGWにおいてバッファリングされているすべてのデータが破棄されてもよい。この実施形態はまた、WTRUがLN内で移動するときのシナリオに適用されてもよい。LIPAベアラは、WTRUがLNの外に移動し、または、マクロネットワークのカバレッジ内に移動するときに、非活性化されてもよい。
WTRUがアイドルモードに入り、および、それがLIPAベアラをサスペンドしている場合、以下のアクションのうちの1または複数が実行されてもよい。1つのアクションにおいて、タイマは停止されてもよく、および、WTRUが接続モードに戻ったときにそれは再開してもよい。別のアクションでは、WTRUがトラッキングエリア更新(TAU)/ルーティングエリア更新(RAU)を実行するときに、ネットワークは、WTRUがキャンプオンするセルがLIPAをサポートしているかをチェックしてもよい。そのセルがLIPAをサポートしている場合、ベアラは再開され、および、LGWはバッファリングされているデータをWTRUに送信してもよい。ネットワークは、WTRUがLNカバレッジの外へ移動したことを認識すると、LIPA PDN接続は非活性化されてもよい。別のアクションでは、ネットワークがページングメッセージを送信したとき、または、サービス要求が存在するときに、ネットワークは、現在のセルがLIPAをサポートしている場合にLIPAベアラを再開し、および、バッファリングされたデータを送信することを試みえもよい。ネットワークは、WTRUがLIPAカバレッジの外へ移動した場合にベアラを非活性化してもよい。
LIPAベアラのサスペンションに対するトリガは、WTRUがLNの外へ移動したことを検出すること、ターゲットセルがLIPAをサポートしていることを検出すること、ベースとなっているネットワークポリシ(network policy based)、ネットワークインジケーション、および、ユーザインジケーションなどを含んでもよいが、それらに限定されない。
LIPAベアラの再開に対するトリガは、WTRUがLNカバレッジに戻り、および、LNにおけるLIPAへのアクセス権を有していることを検出すること、ターゲットセルがLIPAをサポートしており、および、WTRUがターゲットセルにおいてLIPAへのアクセス権を有していることを検出すること、ベースとなっているネットワークポリシ、ネットワークインジケーション、LIPAベアラ再開タイマの満了、ならびに、ユーザインジケーションなどを含むが、これらに限定されない。
LIPAベアラのサスペンションのイニシエータは、ソースセルであってもよい。例えば、非コアネットワークが関わるモビリティの間に、ソースセルはLIPAのサスペンションを開始してもよい。LIPAサスペンション要求またはインジケーションは、ハンドオーバ要求メッセージの一部として、他のリロケーションメッセージもしくはコンテキスト転送応答メッセージの一部として、または、別のメッセージにおいてターゲットセルに送信されてもよい。次いで、ターゲットセルは、そのようなインジケーションを、例えば、パス切替え要求メッセージにおいて、LGWに中継してもよい。ソースセルは、WTRUコンテキストを保持し、ならびに、LIPAベアラ構成および/またはコアネットワーク(および/またはLGW)へ割り当てられたリソースを削除せずに、そのようなベアラをサポートしてもよい。ソースセルは、構成可能なタイマを開始してもよい。ソースセルがWTRUコンテキストおよび関連付けられたLIPAベアラを保持する期間は、そのようなタイマによって制御されてもよい。
LIPAベアラの一時停止のイニシエータは、ターゲットセルであってもよい。例えば、非コアネットワークが関わるモビリティにおいて、ターゲットセルは、例えば、WTRUがターゲットセルにおいてLIPAアクセス権を有していないと判定された後に、LIPAの一時停止を開始することができる。次いで、ターゲットセルは、そのような指示を、例えば、パス切替え要求メッセージに入れて、LGWに送信することができる。
LIPAベアラのサスペンションのイニシエータは、LGWであってもよい。LGWは、LIPAはベアラのサスペンションを開始するために、ユーザLIPA加入者情報を含む必要なすべての情報を有するように構成されてもよい。
LIPAベアラのサスペンションのイニシエータは、HeNB GWを含むコアネットワークであってもよい。例えば、コアネットワークが関わるハンドオーバ/リロケーションの間に、コアネットワークはベアラのサスペンションを開始してもよい。
ターゲットセルは、LIPAサスペンション要求またはインジケーションを受信してもよい。非コアネットワークが関わるモビリティの間に、LIPAベアラサスペンション要求/インジケーションを受信すると、ターゲットセルは、LIPAベアラリソースを割り当てなくてもよい。加えて、ターゲットセルは、WTRUへのこのような要求/インジケーションを(明示的に、または黙示的に)ハンドオーバコマンドコンテナ(ソースセルを介してWTRUに送信される)内に含めてもよい。ターゲットセルは、例えば、パス切替え要求メッセージにおいて、ベアラサスペンション要求/インジケーションをLGW(またはHeNB GWもしくはコアネットワークが関わるハンドオーバのケースではコアネットワーク)に中継してもよい。ターゲットセルは、その後のハンドオーバまたはリロケーションの間に、後続のターゲットセルにLIPAベアラ構成情報を転送してもよい。
WTRUは、他のRRCメッセージのようにハンドオーバコマンドの一部としてLIPAサスペンション要求/インジケーションを受信してもよい。LIPAベアラサスペンション要求/インジケーションを受信すると、WTRUは、アプリケーションレイヤに通知してもよい。そして、アップリンクLIPAベアラトラフィックがサスペンドされてもよい。WTRUはまた、コアネットワークまたはピアWTRUにそのようなサスペンションを通知してもよい。WTRUはまた、そのCSGホワイトリストを更新し、したがって、WTRUがターゲットセルにおいてLIPAアクセス権を有していないという事実を反映してもよい。
LGWは、Sxxインタフェース、S1インタフェース、Iuhインタフェース、S5インタフェース、または他のインタフェース上でLIPAベアラサスペンション要求/インジケーションを受信してもよい。LIPAベアラサスペンション要求/インジケーションを受信すると、LGWは、ダウンリンクLIPAベアラトラフィックをバッファリングしてもよい。LGWは、その後のハンドオーバまたはリロケーションの間に、後続のターゲットセルにLIPAベアラ構成情報を転送してもよい。LGWは、LIPAベアラをサスペンドすると、タイマを起動してもよい。
ソースセルは、LIPAベアラサスペンション要求/インジケーションを受信してもよい。LIPAベアラサスペンション要求/インジケーションを受信すると、ソースセルは、WTRUコンテキストを保持し、および、LIPAベアラ構成および/またはコアネットワーク(および/またはLGW)へ割り当てられたリソースを削除せず、そのようなベアラをサポートしてもよい。ソースセルは、構成可能なタイマを開始してもよい。ソースセルがWTRUコンテキストおよび関連付けられたLIPAベアラを保持する期間は、そのようなタイマによって制御されてもよい。
CNは、LIPAベアラサスペンション要求/インジケーションを受信してもよい。CNは、HeNB−GW、MME/S−GW/PGW、およびSGSN/GGSNなどを含んでもよいが、それらに限定されない
本明細書では、LIPA PDN接続によるRAT間ハンドオーバに対する実施形態について説明される。RAT間ハンドオーバは、HeNBおよびHNBが同一のLGWの下に配備されたときに、LIPA PDNで実行されてもよい。WTRUは、HeNBとHNBとの間を移動するときに、LGWを通してローカルネットワークまたはインターネットへのシームレスなデータ接続性を維持してもよい。このタイプのハンドオーバは2つの異なるシステムの間のハンドオーバなので、シグナリングはCNを通ってもよい。ソースセルがハンドオーバプロシージャをトリガすることに決めたときに、それはハンドオーバ要求メッセージをその各CNネットワークノードに送信する。例えば、HeNBは、メッセージをMMEに送信し、および、HNBは、メッセージをSGSNに送信する。このメッセージにおいて、ソースセルは、アクティブなLIPA PDN接続が存在し、および、LIPAベアラがターゲットセルに転送される必要があることを示してもよい。ソースシステムは、LIPAベアラをハンドオーバすることができるかを要求するメッセージをターゲットシステムに送信し(例えば、MMEはメッセージをSGSNに送信する)。ソースシステムは、WTRUコンテキスト情報を、相関IDまたはLGW S5トンネルエンドポイントID(TEID)とともにターゲットシステムに送信してもよい。LGWアドレスまたは一部の他のLGWIDはまた、両方のセルが同一のLGWに接続されていることを保証するためターゲットシステムに転送されてもよい。
ベアラ情報、相関ID、および/またはLGWアドレス(もしくはID)は、それがLIPAベアラを受け付けるか否かを決定することができる、ターゲットセルに送信されてもよい。そして、受け付けられたベアラ情報がソースシステムに送信されることによって、いくつかのベアラが受け付けられない場合に、ソースおよびLGWがベアラに対するリソースを解放してもよい。ターゲットセルは、LGWとのユーザプラン接続を作成し、および、アップリンク(UL)TEIDをULデータに対するLGWと交換してもよい。
HeNBからHNBへのハンドオーバのケースでは、LGWは、SGSNとの接続を作成してもよい。この接続は、直接LGW−SGSN間インタフェースを通じて、または間接的にSGWを介して作成されてもよい。第1のケースでは、新たなトンネルが、ハンドオーバの間にLGWとSGSNとの間に作成されてもよい。このトンネルに関して新たなLGW TEIDが存在してもよい。SGSNは、このTEIDを相関IDとして送信して、HNBとLGWとの間の直接ユーザパスを有効にしてもよい。第2のケースでは、LGWとSGWとの間のS5インタフェースはハンドオーバの間に変化せず、したがって同一のLGW S5TEIDは相関IDとして使用されてもよい。SGWは、そのそれぞれのHNBに転送するハンドオーバプロセスの間に、このTEIDをSGSNに転送してもよい。上述の2つの実施形態はまた、HNBからHeNBへのハンドオーバに適用してもよい。
LGW間モビリティに対する実施形態が本明細書において説明される。中断なしのモビリティは、WTRUが1つのLGWのカバレッジから別のLGWのカバレッジへと移動するときにサポートされてもよい。LGWに変化があるときに、WTRU IPアドレスまたはIPアクセスポイント(POP)は変化してもよい。このことは、ユーザプレーンデータにおける途絶を引き起こすことがある。これを回避するために、ソースLGWシステムからターゲットLGWシステムへのデータ転送がサポートされてもよい。
図22は、ソースLGW2205とターゲットLGW2210との間の直接インタフェース2200に対する実施形態を示している。特に、直接インタフェース2200は、シームレスなLGW間モビリティに対するデータ転送のために、ソースLGW2205とターゲットLGW2210との間で提供されてもよい。ハンドオーバプロシージャの間に、ソースHeNB2215は、異なるLGW、すなわち、LGW2210によってターゲットHeNB2225にサービスされることを気付いてもよい。ソースHeNB2215は、MME(図示せず)、LGW2205、またはターゲットHeNB2225からこの情報を取得してもよい。ソースHeNB2215はまた、ターゲットLGW2210のアドレスまたは一部の他のタイプの識別を取得してもよい。ターゲットHeNB2225は、ソースHeNB2215に、それがLIPAベアラとのLGW間ハンドオーバをサポートしているかを通知してもよい。ハンドオーバがサポートされ、および、ターゲットHeNB2225が2つのLGW間のトンネルの確立をサポートしている場合、ソースHeNB2215は2つのLGWの間の直接トンネルの確立を続行してもよい。ソースLGW2205は、ソースHeNB2215またはMMEによって提供されるターゲットLGW2210のアドレスを使用して、直接トンネルを確立してもよい。直接トンネルが確立された後、ソースLGW2205は、ユーザデータをターゲットLGW2210に転送してもよく、そして、ターゲットLGW2210はターゲットLGW2210とターゲットHeNB2225との間の直接パスを介してデータをWTRU2230に送信する。
ターゲットHeNB2225へ転送されたデータは、多数の方法を使用して行われてもよい。例えば、ソースLGW2205は、IP POPのままでもよい。WTRU2230が、新たなLGW(すなわち、ターゲットLGW2210)に移動するときに、WTRU2230のIPアドレスは変更しなくてもよい。ソースLGW2215がWTRU2230に対するデータを受信したときにはいつでも、それは、データをターゲットLGW2210に転送してもよい。ターゲットLGW2210は、元のLGW(すなわち、ソースLGW2205)とターゲットHeNB2225との間の中継器として動作してもよい。
あるいは、WTRU2230は、ターゲットLGW2210との新たなPDN接続を確立してもよい。ターゲットLGW2210は、新たなIPアドレスをWTRU2230に提供してもよく、したがって、このことはWTRU2300のIP POPとなってもよい。ソースLGW2205は、ターゲットLGW2210にデータを転送してもよく、および、ターゲットLGW2210は、このデータを新たなPDN接続を介してWTRU2230に送信してもよい。
図23は、X2/Iurhインタフェース2300を介してデータ転送が行われる別の実施形態を示している。特に、X2/Iurhインタフェース2300は、シームレスなLGW間モビリティに対するデータ転送に使用されてもよい。X2またはIurhインタフェース2300を介してのデータ転送は、システムのタイプに依存することがある。WTRU2305が異なるLGW2315でターゲットHeNB2310に移動するときに、ソースHeNB2320は、ターゲットHeNB2310に、それがX2またはIurhインタフェース2300を介してLIPA PDN接続に対してデータ継続性を維持することができるかを要求してもよい。ターゲットHeNB2310は、ハンドオーバ要求肯定応答メッセージにおいてソースHeNB2320からの問い合わせを通知/応答してもよい。そして、ターゲットHeNB2310は、パス切替え要求をCN(図示せず)に送信してもよく、および、LIPAベアラに対するパスを切り替えるためのパラメータを含まない。ハンドオーバプロシージャの完了のときに、ソースHeNB2320は、X2またはIurhインタフェース2300を介してLIPA PDN接続に対するデータをターゲットHeNB2310に転送するために必要なすべての情報を有してもよい。あるいは、データは、ソースHeNB2320からターゲットLGW2315に転送されてもよく、そして、ターゲットLGW2315からWTRU2305に、ターゲットHeNB2310を介して転送されてもよい。
上述の実施形態は、ターゲットHeNB2315がソースLGW2325またはターゲットLGW2315または任意のLGWに接続されることを必要とせず、および、当該実施形態は、HeNB2320とHeNB2310との間のX2/Iurhインタフェースを通じてソースLGW2325を介して、ローカルネットワークへのリモートアクセスを提供するために使用されてもよい。
別の実施形態では、データ転送は、シームレスなLGW間モビリティに対するSGWを通じて実行されてもよい。LGWとSGWとの間の既存のS5インタフェースは、ソースLGWシステムからターゲットLGWシステムにデータを転送するために使用されてもよい。この実施形態は、ソースおよびターゲットLGWの両方が同一のSGWによりサービスされることを仮定している。LGW間ハンドオーバの間に、ソースHeNBは、WTRUがソースLGWのカバレッジの外へ移動するときに、LIPA PDN接続を非活性化しなくてもよく、代わりに、ソースHeNBが、アクティブなLIPAベアラをターゲットHeNBに通知してもよい。ターゲットHeNBがLGW間ハンドオーバをサポートする能力を有している場合、それは、LGWとのセッションを、それが他のPGWとのセッションを作成するのと同様に作成することをSGWに要求してもよい。SGWは、WTRUトラフィックが直接パスを通じてルーティングされる代わりに、SGWを通じてルーティングされてもよいことをLGWに通知してもよい。
SGWの機能性は修正されてもよく、それは、現在、SGWがLGWからデータを受信したときに、それはダウンリンクデータ通知をMMEに送信することによって、MMEがWTRUをページングしてそれを接続モードにするようにできるからである。しかし、この実施形態では、SGWは、データを直接WTRUに転送してもよい。この問題は、S5インタフェースが確立されたときに、いくつかの情報要素(IE)を交換することによって解決されてもよい。これらのIEは、S5トンネルがユーザプレーン用であるか、またはネットワーク開始サービス要求プロシージャを容易にするためのものであるかをSGWおよびLGWに通知してもよい。
一部のLGWの機能性はまた、この実施形態をサポートするために変更されてもよい。現在、LGWはHeNBからULデータを受信するが、この実施形態では、LGWはまた、SGWからアップリンクデータも受信してもよい。したがって、データがHeNBによって送信されるか、または、SGWによって送信されるかを区別することが必要になることがある。このことは、2つの異なる相関IDを使用することによって達成されてもよい。1つの相関IDはHeNBとLGWとの間の直接的パスに対するものであり、および、他方の相関IDはSGWを通るデータに対するものである。
本明細書における上述の実施形態は、ターゲットHeNBがLGWに接続されることを必要としないことがある。したがって、この実施形態はまた、ソースLGWを介してローカルネットワークへのリモートアクセスを提供するためにも使用されてもよい。
本明細書において上述されているすべての実施形態では、ネットワークは、WTRUがアイドルモードに移行するとき、または、WTRUにおけるすべてのデータセッションが非アクティブであるときに、そのPDN接続をターゲットLGWに変更することを決定してもよい。
LIPA/SIPTO間のインタラクションに対する実施形態、および、同等のPLMNおよびRANの共有に対するサポートについて、本明細書で説明される。LIPAは、オペレータがCSG毎のユーザ加入者毎に、LIPAを有効化/無効化することができることが必要である。この要件は、現在、加入者ユーザプロファイルにおいてWTRUが特定のCSGに接続されるときに有効であるアクセスポイントネーム(APN)に対するLIPAのサポートを定義する、オペレータによって実装される。CSGは、PLMNベースで指定されている。現在、すべてのePLMNが、PLMN選択、セル選択/再選択、およびハンドオーバについて互いに同等であるものとみなされる。このことは、すべてのePLMNが、同一のCSGエントリを有するホワイトリストに格納されることを意味する。
すべてのePLMNがホワイトリストに格納されているわけではないことが仮定されている。これに基づいて、以下では、どれが同等のPLMNに対するサポートと必ずしも後方互換性を必要としなかの説明がなされた。WTRUベースのモビリティ(すなわち、IDLEおよびUMTS PCH)の間のメンバシップチェックに対し、WTRUは、すべてのブロードキャストPLMNのCSG−ID部分を考慮してもよい。適切なチェックは、登録されているPLMN(rPLMN)/サービングPLMN(sPLMN)/ePLMNが(rPLMN/sPLMN/ePLMN,CSG−ID)がホワイトリストに存在するかを考慮する。接続モードでは、WTRUが、それがメンバであるか、または、非メンバであるかを報告することを求められたときに、WTRUはそれ自体を、rPLMNがセルによってブロードキャストされ、および、(rPLMN,CSG−ID)がWTRUのホワイトリストにある場合にのみメンバであるとみなす。
一実施形態では、同等のPLMNへのサポートとの後方互換性を提供するために、WTRUベースのモビリティ(すなわち、IDLEおよびUMTS PCH)の間に、または、WTRUが接続モードである間のモビリティの間のメンバシップチェックについて、PLMN(sPLMN、rPLMN、他の任意のPLMN)がセルによってブロードキャストされ、および、WTRUがそのホワイトリスト上にこのPLMNを有していないが、むしろセルによってブロードキャストされるCSG IDに関連付けられているePLMNを有しているときに、WTRUはそれ自体をメンバであるとみなして、ePLMNを含むようにそのホワイトリストを更新してもよい。WTRUは、そのホワイトリストの更新をネットワーク(MME、SGSN、HeNB)に通知してもよい。WTRUは、トラッキングエリア識別子(TAI)、ルーティングエリア識別子(RAI)、またはTAU/RAUタイマの満了に変更がない場合であっても、ホワイトリストの更新の結果としてTAU/RAUを開始してもよい。ネットワークは、ホワイトリストの更新を元に戻すようWTRUに要求してもよい。
加えて、WTRUは、CSGセルによってブロードキャストされるPLMNの代わりに、同等のPLMNをWTRUが使用することを許可されるかに関するパーミッションでネットワークによって構成されてもよく、および、それ自体をCSGのメンバであるとみなしてもよい。格納されているリストにあるすべてのPLMNは、PLMNによってサポートされているすべてのアクセス技術において、PLMN選択、セル選択/再選択、およびハンドオーバに対して互いに同等であるものとみなされてもよい。このコンテキストでは、同等のPLMNは、CSGセルによってブロードキャストされるPLMNと同等であるとみなされてもよい。
加えて、パーミッションはまた、<CSG_ID,ePLMN>組合せをCSGセルによってブロードキャストされる<CSG_ID,PLMN>組合せの代わりに使用して、WTRUがそのメンバシップ状態を「メンバ」として報告することを許可されるかを示してもよい。図25は、このプロシージャを実行するために使用される例示的なWTRUのホワイトリスト2500を示している。
このパーミッションは、NASシグナリング(例えば、Attach Accept)、およびRRCシグナリング(例えば、システム情報メッセージ)などを使用してシグナリングされてもよい。このパーミッションはまた、さらに、ネットワークオペレータのサービスセンタで事前構成されてもよく、あるいは、オープンモバイルアライアンス(OMA)デバイス管理(DM)を通じて、または、アクセスネットワーク発見・選択機能(ANDSF)を使用して、このパーミッションをプッシュもしくはプルすることでオーバーザエア(OTA)プロシージャを介してオペレータによって構成されてもよい。このパーミッションはまた、ホーム加入者サーバ(HSS)/ホームロケーションレジスタ(HLR)に典型的に格納されている加入者プロファイルの一部であってもよい。例えば、このパーミッションは、移動先ネットワークによって検索(retrieve)されてもよく、および、例えば、ネットワークアタッチメントプロシージャの間にWTRUを構成するために使用されてもよい。
このパーミッションで構成されているWTRUは、それ自体をCSGセルによるCSGのブロードキャスト、および、同等のPLMNの任意の組合せのメンバとして(この組合せがそのホワイトリストの一部である限り)、みなしてもよい。ネットワークによってすでに構成されているCSG ID/ePLMNの組合せのメンバであると主張(claim)するWTRUに対してアクセスチェックおよびメンバシップ検証を実行する、関連するPLMN内のネットワークエンティティ(例えば、モビリティ管理エンティティ(MME)またはHeNB)は、この目的のためにすでに構成されている許可に基づいて、そのような組合せを提供するWTRUへのネットワークアクセスを許可してもよい。
加えて、セル再選択プロシージャの間に、WTRUは、<CSG_ID,PLMN>の組合せを、そのような組合せがWTRUのホワイトリストに含まれていない場合であっても、ブロードキャストするCSGセルに再選択してもよい。WTRUは、このプロシージャを、セルの<CSG_ID,ePLMN>の組合せがWTRUのホワイトリストに含まれている限り、実行してもよい。さらに、WTRUが、例えば、異なるトラッキングエリア(TA)/ロケーションエリア(LA)ルーティングエリア(RA)にアクセスすることに起因して、または定期的な更新の要件に起因して、ロケーション更新プロシージャを実行する必要がない場合であっても、WTRUは、ロケーション更新プロシージャを実行して、ネットワークがメンバシップ証明を検証し、したがって、WTRUのシステムアクセスの受け入れまたは拒絶を許可してもよい。
別の実施形態では、WTRUは、RAU/TAU(または他の適切なNASプロシージャ)を開始して、PLMNの変更およびこのPLMNへの登録をネットワークに通知してもよい。登録が受け付けられた場合、WTRUは、そのホワイトリストを、ePLMNとセルによってブロードキャストされたCSG IDとの間の関連付けで更新してもよい。RAN共有のコンテキストでは、セルは、複数のPLMN IDをブロードキャストしてもよい。一部のオペレータはCSGセルに対してLIPAを提供してもよく、一部のほかのオペレータは同一のCSGセル上でLIPAを提供しなくてもよい。さらに、ePLMNの間で、サービスの識別が存在してもよい。オペレータは、与えられたPLMNの下で与えられたAPN/CSGの組合せについてLIPAサービスを加入者に提供してもよく、その一方で、同一の加入者は、両方のPLMNがePLMNであるという事実があるにもかかわらず異なるPLMNの下で同一のAPN/CSGの組合せについてLIPAサービスへの認可がされない。WTRUがLIPAサービスに対するPDN接続要求を送信したときに、それはMMEへの要求において、セルにおいて可能なCSG_ID/PLMNまたはCSG/ePLMN組合せのリストをそのセルに含めてもよい。そして、MMEは、WTRUがそのHeNBからLIPAサービスにアクセスすることを許可するCSG_ID/PLMNを選択してもよい。
これらの可能性を考慮するために、一実施形態では、LIPAサービスアクセス認可は、APN、CSG、およびPLMNの組合せに基づいて、定義されてもよい。別の実施形態では、セルは、PLMN毎をベースに複数のCSG IDをブロードキャストしてもよい。例えば、セルを共有するPLMN毎に1つのCSG IDブロードキャストが存在する。
一実施形態では、非SRNSリロケーションハンドオーバが、リモートIPアクセス(RIPA)のサポートにおいて使用されてもよい。WTRUが所与のセルのカバレッジの下にあり、および、RIPAサービスを必要としているときに、接続は、WTRUのローカルネットワークに配置されているサービングRNS(HeNBサブシステム)、および、ドリフトRNS(HeNB、eNB、およびRNC/NBなど)を使用してセットアップされてもよく、WTRUにカバレッジを提供する。サービングRNSは、WTRUの接続を管理してもよく、ドリフトRNSは、無線リソースを提供してもよい。SRNSおよびDRNSの両方は、同一のLN内にあり、または、異なるLNにあってもよい。同様に、SRNSおよびDRNSの両方は、同一のLGWの下にあり、または、異なるLGWの下にあってもよい。
SRNSとDRNSとの間のアクセス制御ルールに関して、一実施形態では、WTRUは、WTRUがSRNS、DRNS、および/または関係するCSGにおいてアクセス証明を有する場合にアクセスすることを許可されてもよい。別の実施形態では、WTRUは、WTRUがSRNSおよび/または関係するCSGにおいてアクセス証明を有している限りアクセスすることを許可されてもよい。別の実施形態では、WTRUは、WTRUがSRNS/DRNSおよび/または関係するCSGにおいてアクセス証明を有している限りアクセスすることを許可されてもよい。別の実施形態では、WTRUは、WTRUがSRNSおよび/もしくは関係するCSG、またはDRNSおよび/もしくは関係するCSGにおいてアクセス証明を有している限りアクセスすることを許可されてもよい。
MRAおよびMRA−LIPA間転送を有効化する、ならびに、その逆が説明される。第1のプロシージャにしたがって、スタンドアロンまたはアタッチプロシージャの一部としてのいずれかのPDN接続性要求は、LIPAがWTRUに提供されないセルから送信されてもよい。したがって、LGWへの接続は、MRA接続として実装されてもよい。
WTRUが、MRAセッションに対するPDN接続要求を開始するときに、このPDN接続がMRAセッションに対するものであることを示すために、ローカルネットワークに対する適切に定義されたAPN、および、MRAインジケーションが含まれてもよい。PDN接続性要求を搬送するNASメッセージは、LGW IPアドレス(CNによって認識される)、または、LGW識別を含んでもよい。このアドレス/識別子は、適切なLGWを選択するためにMMEによって使用されてもよい。WTRUは、例えば、ユニバーサル加入者識別モジュール(USIM)においてこの情報で構成されてもよく、または、CNノード、例えば、ANDSF、ドメインネームサーバ(DNS)、もしくは、一部のほかのMRAアプリケーションサーバなどからこの情報を取得してもよい。識別は、例えば、ローカルホームネットワーク(LHN)IDであってもよい。あるいは、RANノードは、この情報で構成されてもよい。RANノードは、この情報をすべてのUL NASトランスポートメッセージ(S1AP)またはRANAPにおける同等のメッセージに含めてもよい。
MRAに対するPDN接続を受信すると、MMEはWTRUのMRA認可を実行して、WTRU加入者データおよびHeNB/HNBもしくはLGWのMRA能力に従って、WTRUがMRAサービスを使用することを許可されているかを判定してもよい。MMEは、MR認可が失敗した場合に、PDN接続性要求を拒絶してもよい。成功したMRA認可の後に、MMEは、LGWのアドレスまたは/およびローカルネットワークにおいてLGW選択するために提供されるLHN IDを使用してもよい。
セットアップされた各PDN接続に対し(アタッチプロシージャの一部として、またはスタンドアロンのPDN接続性要求プロシージャの間のいずれかで)、MME/SGSNは、接続が例えばLIPA接続、MRA接続、または、他のCN PDN接続であるかをLGW/GGSN/PGWに示すべきである。このことは、接続性タイプのIEまたは任意の他の形態のインジケーションを導入することによって行われてもよい。LTEに対して、このことはSGWを介して行われてもよい。接続性タイプ(または任意の他の同様のIE)は、MMEから、インジケーションをLGW/PGWへ転送するSGWに送信されるセッション作成要求に含まれてもよい。加えて、このインジケーションはまた、PDN接続性要求において、または、任意のシグナリングの間のいずれかにおいて、MMEによってSGWに送信されてもよい。例えば、それは、ハンドオーバプロシージャの一部として送信されてもよい。
このインジケーションは、HeNBまたはSGWのいずれかによって使用されるULトンネルエンドポイントを指定するために、相関IDまたはS5 PGW TEIDが提供される必要があるか否かを判定するために(例えばLGWによって)使用される。言い換えると、相関IDは、直接パスがLGWとHeNB/HNBとの間でセットアップされることになる場合にのみ、必要とされる。したがって、セッションがLIPAである場合、LGWは、セッション作成応答メッセージにおいて相関IDを提供すべきである。一方、セッションがMRAである場合、HeNB/NBとLGWとの間では直接パスは必要でない。そのため、相関IDは、セッション作成応答においてLGWによって提供される必要はなく、その代わりに、S5 PGE TEIDが提供される必要がある。
加えて、LGWは、セッションがLIPA/MRAであること(例えば、接続性タイプまたは任意の他の同等のIE)に関するインジケーションを使用して、WTRUがページングされるときにダミーパケットが使用されるべきか、または、コアネットワークPGWによって行われるように実際のダウンリンクデータがSGWに転送されるべきかを判定してもよい。
図24は、例示的なMRAのページングのシナリオ2400を示している。LN2405内のエンティティは、対象のWTRU2410に対するダウンリンクデータを送信してもよい(1)。LGW2415は、WTRU2410がアイドルモードに有ることを認識していると仮定される。LGW2415は、HeNB2417またはスタンドアロンエンティティと同一位置に配置されてもよい。PDN接続の確立の間に提供される、PDN接続がMRAであることに関するインジケーションに基づいて(例えば、接続性タイプを使用して)、LGW2415は、ユーザデータがS5 DLデータ接続上でSGW2420に送信されるべきかを判定してもよい(2)。このことは、LGW2415がダミーパケットをSGW2420に送信してページングをトリガすることができるLIPAセッションとは異なっていてもよい。そして、通常のページングプロシージャが、MME2422によって実行されてもよく、MME2422では、WTRUはマクロネットワークにおいて(またはLN2405のHeNB/HNB2417において)ページングされ、したがって、それが応答した場合(3〜4)、SGW2420は、WTRU2410宛てのバッファリングされているデータを転送してもよい(5)。
あるいは、少なくとも1つの相関IDがLGWによって提供されてもよい。このことは、MRAセッションがLIPAセッションとして継続される場合に使用されてもよい。このことは、例えば、LIPAセッションが対象のWTRUに対して許可されているLN/セル内に、MRAを有するWTRUが移動した後に発生してもよい。次いで、直接パスが、HeNB/HNBと、その後すでに割り当てられている相関IDを使用するLGWとの間で確立されてもよい。相関IDは、MRAセッションのセットアップの間に提供される場合、潜在的LIPAセッションが開始されるまで(すなわち、MRAセッションがLIPAセッションとして継続されるまで)、MME/SGSNに格納されることに留意されたい。その時点において、MME/SGSNは、相関IDを、ハンドオーバの一部として実行されるシグナリングメッセージにおいてHeNB/HNBに転送されてもよく、これについては以下で説明する。MRAセッションの間に相関IDの値が変化するケースでは、新たな相関IDがMME/SGSNに送信されてもよい。このことは、SGWが、変更することができる相関IDの一部であってもよいS5 TEIDを変更したときに発声してもよい。
MME/SGSNはまた、サービングセルに、そのセッションがMRAセッションであることを示してもよい。このインジケーションは、例えば、MRAセッションがLIPAセッションとして継続することができるセルを選択するために、ハンドオーバの間にセルによって使用されてもよい。隣接に関する情報が、すべてのセル(ソース、ターゲット、マクロ、およびHeNB/NBなど)に提供されてもよい。このことは、例えば、LIPAが全般にサポートされているか否か、または、特定のWTRUに対してサポートされているか否か、したがって、どのWTRUに対してサポートされているか、ならびに、MRAが全般にサポートされているか否か、または、特定のWTRUに対してサポートされているか否か、したがって、どのWTRUに対してサポートされているかを含んでもよい。この情報は、CNノード、例えば、MME/SGSN/HSS/LGWまたは他のノード、例えば、RNCまたはHNB GWによって提供されてもよい。
あるいは、CNによって認識されるようなローカルホームネットワーク(LHN)IDまたはLGWのアドレスはまた、LGWによって提供されてもよく、および、これは、WTRUが、LIPAを許可することができるLHN内に移動したときに、MRAセッションがLIPAセッションとして継続することを保証するために使用されるべきである。このLHN IDまたはLGWアドレスは、サービングMMEまたはサービングeNB/HeNBに格納されてもよい。これらのパラメータはまた、アクティブなMRAセッションが存在するハンドオーバの間にターゲットeNB/HeNBへのインジケーションとして使用されてもよい。また、ローカルネットワークへのハンドオーバのケースでは、ターゲットは、LHN IDまたはLGWのアドレスをそれらの自身のアドレスと比較し、および、それが一致すれば、MRAセッションは、以下で指定されているようなアクティブなLIPAセッションとして継続されてもよい。
ここでは、ローカルネットワークに入り、ローカルネットワークから出る(すなわち、MRAからLIPA/LIPAからMRAの)ハンドオーバについて説明される。考慮する2つのモビリティシナリオが存在する。第1のシナリオでは、ローカルネットワークにおけるWTRUは、LIPAセッションを有する。次いで、WTRUは、接続モードでLNの一部でないターゲットセルにハンドオーバされることによって、LIPAセッションを維持することができるが、MRAセッションとして維持することができる。第2のシナリオでは、WTRUは、LNの外にあるときにMRAセッションを有する。次いで、接続モードにおいて、WTRUは、WTRUに対してLIPAが許可されているLN内のセルにハンドオーバされる。こうして、MRAセッションは、LNにおけるLIPAセッションとして継続される。
第1のシナリオについて、LIPAツーMRAセッション転送(LtM:LIPA to MRA session transfer)は、S1もしくはX2ハンドオーバ、または3Gシステムにおける類似のモビリティに適用されてもよい。ハンドオーバの間に、ソースまたはターゲットMMEは、WTRUがターゲットセルにおいてMRAセッションを有することを許可されているかを検証する。ターゲットセルは、LNに属さない任意のセル、または、LNに属するが、例えば、LIPAが加入情報に起因して許可されていないセルであってもよい。MME間HOが存在してもよいが、MME内(intra-MME)に対しては、ターゲットはまたソースMMEである。
S1ハンドオーバの間に、ターゲットMMEは、MRAがターゲットセルにおけるWTRUに対して許可されているかを検証してもよい。この検証は、ハンドオーバの完了前に、または、MMEが、リソースがターゲットセルにおいてセットアップされるべきか否かを認識することができるようなハンドオーバシグナリングの間に行われてもよい。例えば、MMEがS1 HOプロシージャの一部としてソースセルから「handover required」メッセージを受信したときに、MMEは、進行中のLIPAセッションをターゲットセルにおいてMRAとして維持することができるかを検証してもよい。
MRAが許可される場合、MMEはハンドオーバを完了することを可能にするが、そうでなければ、MMEはハンドオーバを拒絶し、および、ソース/ターゲットセルに、拒絶の理由が進行中のセッションをMRAセッションとしてターゲットセルにおいて維持することができないことであることを通知してもよい。この情報は、対象のWTRUの今後のハンドオーバに対してソース/ターゲットセルによって使用されてもよい。拒絶原因はまた、MRAがすべてのWTRUに対してターゲットから許可されていないことも示してもよい。したがって、ソースセルは、この情報を今後のハンドオーバに対して考慮することによって、ターゲットセル上でMRAセッションが試みられないようにすることができる。
あるいは、MMEは、ハンドオーバおよびMRAセッションとしてのLIPAセッションの継続を許可してもよい。ハンドオーバの後、MMEは検証を実行して、WTRUがターゲットセルからのMRAセッションを有することを許可されているか否かを検証してもよい。そうでない場合、MMEは、他のCNノードおよび/またはRANノードへのMRAで必要とされるリソースの解放を開始してもよい。
SGSNなどのCNノードへのMME間ハンドオーバまたはRAT間ハンドオーバが存在する場合、LIPAセッションの存在に関してそれに通知するインジケーションが、ターゲットMMEに送信されてもよい。次いで、ターゲットMMEは、このインジケーションを使用して、LIPAセッションをターゲットセルにおいてLIPAまたはMRAとして維持することができるかを検証してもよい。
検証は、ソースまたはターゲットセルによって実行されてもよく、および、上記の他の提案すべても同様にソース/ターゲットセルに対して適用される。これがソース/ターゲットによって行われる場合、ソース/ターゲットセル(例えば、HeNB/HNB)は、WTRUがMRAセッションを有することが許可されている潜在的ターゲットセルに関する情報を提供されるべきである。この情報は、CN(MME/SGSN、またはLGW、またはOMAを介して)によって、または、それが対象のWTRUに対してそのような情報を有している場合にはターゲットセルそれ自体によって、ソース/ターゲットに提供されてもよい。例えば、ターゲットセルは、ソースセルに送り返されるそのような情報を、ハンドオーバシグナリングの間に提供してもよく、および、ソースセルはこの情報を今後のハンドオーバに使用してもよい。ハンドオーバの間に、ソース/ターゲットセルは、ターゲットセル/ターゲットMMEに、WTRUがMRAセッションとして維持されるべきLIPAセッションを有していることを示してもよい(新たなIEまたは既存のIEを介して)。次いで、ターゲットセル/ターゲットMMEは、このIEが、セッションがMRAセッションとして処理されるべきであり、および、リソースはLGWへの直接パスを有するのとは反対にSGWへセットアップされるべきであることを認識していることを検証してもよい。ターゲットは、別のLNの一部であるHeNB/HNBであってもよい。
ソースセルが、セッションがターゲットセルにおいてLIPAまたはMRAとして継続されるかを認識していない場合、ソースセルはそのまますべてのLIPA関連情報を保持してもよい。これは、LIPAベアラ、および相関IDなどをハンドオーバメッセージに含めてもよい。次いで、ターゲット/ソースMMEまたはターゲットセルは、そのセッションをLIPAとして保持し、または、それをMRAとして再開するか、もしくは、LIPAベアラのいずれもハンドオーバしないことを判定してもよい。LIPAベアラおよび関連するパラメータは、ターゲットセル/MMEが、どのベアラがLIPAまたはMRAとして継続すべきであるかを認識することができるように識別されてもよい。
MMEがハンドオーバの完了に関するインジケーションをターゲットセルから受信したときに、および、セッションがMRAセッションとして継続されることになる場合に、MMEは、LGWからの/LGWへのローカルネットワークデータの受信/送信を開始することをSGWに通知してもよい。これは、修正ベアラ要求メッセージまたは他のメッセージで示されてもよい。次いで、SGWは、ローカルネットワークデータに対するデータパスの変更に関して、それに通知するメッセージをLGWに送信してもよい。これは、修正ベアラ要求メッセージまたはその他を使用して行われてもよい。SGWはまた、ダウンリンクデータに対してLGWによって使用されることになるTEIDを含む。LGWはまた、アップリンクにおいてSGWによって使用されることになるTEIDで応答する。さらに、LGWは、古いセル(すなわち、直接パス)とともにリソースを解放する。次いで、MMEは、リソースのセットアップの完了に関して通知される。WTRUが、新たなセルに接続されている間にアイドルモードに入った場合、および、ユーザデータがこのWTRUに対して受信された場合、LGWは、本明細書で説明されているようなプロシージャを実行することが必要になることがある。例えば、LGWは、接続性タイプ(または他の同等のIE)に基づいて、ダミーパケット送信する代わりに、ユーザデータがSGWに転送されるべきであることを判定する必要があることがある。
ハンドオーバの前にWTRUに対してCNとLIPAとの両方のトラフィック(すなわち、2つのPDN接続)が存在することがある。そのため、ハンドオーバの間に、CNとのPDN接続に関連付けられているベアラは、現在のプロシージャに関してハンドオーバされる。LIPAベアラは、上記説明されているように処理される。さらに、MRAベアラ/PDN接続は、セッションをLIPAとして再開することができるLNへの今後のハンドオーバが、その後正しいベアラ上で、すなわち、MRAベアラ上で行われるように識別されてもよい。
上述のプロシージャおよびシナリオはまた、3GシステムにおけるX2ハンドオーバまたは類似のハンドオーバプロシージャのケースに適用されてもよい。X2ハンドオーバでは、MMEは、ターゲットセルからパス切替え要求を受信すると、本明細書で説明されている方法を実行してもよい。ソースセルは、LIPAベアラを含み、したがって、これがLIPAまたはMRAとして継続することができるかを検証することをMMEに依存するすべてのベアラを含み、ならびに、上述のような必要な処置を講じることができる。ソースセルは、LIPAベアラおよび関連する情報を識別してもよく、ならびに、ターゲットセルはまた、上述のように検証を実行してもよい。上述のプロシージャは、任意の組合せで適用してもよく、および、3G、または、類似のもしくは同一の機能性を有する他のシステムに適用可能であってもよい。
第2のシナリオでは、MRAツーLIPAセッション転送(MRA to LIPA session transfer)は、S1またはX2ハンドオーバ(HO)、または3Gシステムにおける類似のモビリティの両方に適用されてもよい。上述のプロシージャは、同様にこのケースにも適用することができる。しかし、ソースセルのセッションはMRAセッションであり、および、ターゲットセルのセッションはLIPAセッションである。
MRAセッションを有するWTRUの、LIPAをサポートすることができるターゲットセルへのハンドオーバの間に、ソース/ターゲットセルまたはMME/SGSNは、MRAがターゲットセルにおいてLIPAセッションとして継続されるようにWTRUに対してLIPAが許可されているかをチェックしてもよい。この判定は、上述のように実行されてもよい。MME間またはCN間HO(例えば、MMEツーSGSN、または、SGSNツーMME)が存在する場合、ソースMMEは、対応するターゲットノードに、WTRUのセッションがMRAセッションであり、および、MRAに使用されるベアラおよび他の必要なパラメータも識別されるべきであることを示してもよい。ターゲットMME/SGSNは、この情報を使用して、ターゲットセルがセッションをLIPA、MRAとして継続することができるか否かを検証してもよい。既存のMRAセッション、MRAベアラ、および他のMRAパラメータに関するインジケーションは、ハンドオーバメッセージにおいてソースセルからターゲットセルにも送信されてもよい。
LIPAセッションとして継続することができるMRAセッションのハンドオーバの間に(またはオプションで、ハンドオーバの後に)、ターゲットHeNB/HNBとLGWとの間のLIPAデータに対する直接パスがセットアップされるべきである。LGWとHeNBとの間における直接パスのセットアップはまた、WTRUがアイドルモードに入り、DLデータがこのWTRUに対して受信される場合に、実際のユーザプレーンパケットをSGWに転送する代わりに、LGWがS5 DLインタフェースを通じてダミーパケットまたは第1のパケットを送信する必要がある場合があることを意味する。さらに、ユーザプレーンに対するSGWとLGWとの間のリソースは、解放されるべきである。しかし、一部の通信およびリソースは、WTRUがアイドルモードにあるときに、現在のプロシージャに関して、これら2つのノードの間で維持されて、LIPAトラフィックに対するページングを有効化する。セッションは、短い時間の間、MRAセッションとして続行し、次いで、LIPAセッションに変換してもよい。すなわち、MRAセッションは、LIPAトラフィックがアップリンク方向ではそのままSGWおよびLGWを通り、ダウンリンクについてはその逆であることを意味する、WTRUのハンドオーバの間に、ターゲットセルで継続してもよい。ハンドオーバが完了した後、セッションは、LIPAに変更され、および、直接データパスがセットアップされてもよい。
ハンドオーバの間に、WTRUがターゲットセルにおいてLIPAを許可されている場合、ソースセル/MMEは、ターゲットセルに転送される、ハンドオーバ要求メッセージにインジケーションを含めてもよく、それによって、HeNB/HNBとLGWとの間で直接パスが確立される。少なくとも1つの相関IDがまた含まれてもよく、および、このIDは、WTRUに対する最初のPDN接続確立の間にLGWによって割り当てられてもよい。あるいは、MMEはまた、LGWとともに少なくとも1つの相関IDを割り当ててもよい。
あるいは、ターゲットMME/SGSNがハンドオーバ要求を受信するときに(例えば、S1 HOに対する「handover required」メッセージ、またはX2 HOプロシージャに対するパス切替え要求)、MME/SGSNは、LGWにコンタクトし、および、MRAの潜在的変更をLIPAセッションに示してもよい。このことは、SGWを介して実行されてもよい。したがって、LGWは、このインジケーションを受信すると、LIPAベアラに対する少なくとも1つの相関IDを、オプションでSGWを介して、MME/SGSNに提供してもよい。したがって、MMEは、少なくとも1つの相関IDをターゲットセルへのハンドオーバ要求またはパス切替え要求肯定応答メッセージ内に含めてもよい。ソースセル/MME/SGSNはまた、あるベアラがLIPAに関連していることを通知するためのターゲットセルへの明示的なインジケーションを含んでもよい。
ターゲットセルによってハンドオーバ要求またはパス切替え要求肯定応答メッセージを受信すると、ターゲットセルは、任意の相関IDまたは明示的なLIPAもしくはMRAインジケーションが存在するかを検証してもよい。少なくとも1つの相関IDが存在する場合、ターゲットセルはLGWにコンタクトして、LIPAトラフィックに使用されることになる直接パスに対するリソースをセットアップしてもよい。このインジケーションは、セッションがLIPAセッションであるべきであるというインジケーションを含んでもよい。LGWは、HeNB/HNBがそれとコンタクトして直接パスをセットアップした後に、直接パスを介してHeNB/HNBへのダウンリンクLIPAベアラの転送を開始してもよい。
あるいは、MMEは、SGWに、修正ベアラ要求メッセージまたは他のメッセージを使用して、セッションがLIPAセッションとして維持されるべきであることを示してもよい。次いで、このSGWは、LIPAトラフィックに使用されるリソースをクリアしてもよい。このことは、LGWとHeNB/HNBとの間の直接パスがセットアップされた後に行われてもよい。さらに、SGWはまた、対象のセッションがLIPAセッションとして継続されるべきであるということをLGWに転送/通知してもよい。LGWは、LIPAとしてセッションを継続するインジケーションを受信すると、直接パスをセットアップするために使用される少なくとも1つの相関IDを割り当ててもよい。この情報は、MME/SGSNに送信し返される。このことは、SGWを介して行われてもよい。MME/SGSNはまた、この情報をターゲットHeNB/HNBに転送してもよい。この明示的なインジケーションは、一部のベアラがLIPAセッションに対するものであることを指定してもよい。直接パスがセットアップされていない場合、HeNB/HNBは、少なくとも1つの相関IDまたはLIPAに対する他の明示的なインジケーションを受信すると、LGWで直接パスをセットアップしてもよい。
あるいは、LGWはまた、例えば、修正ベアラ要求メッセージを使用して、MME/SGSNによって提供されるTEID情報を使用してターゲットHeNB/HNBと直接コンタクトしてもよい。このことは、SGWを介して行われてもよい。MME/SGSN/SGWは、前のステップでターゲットHeNB/HNBから受信されたTEID情報を含んでもよい。これは、メッセージでLGWに送信されるLIPAに関するインジケーションとともに使用されてもよく、当該メッセージは修正ベアラ要求メッセージであってもよい。次いで、LGWは、この情報を使用してHeNB/HNBにコンタクトすることによって、直接パスがLIPAベアラに対してセットアップされるようにしてもよい。LGWはまた、LIPAトラフィックに使用されることになる相関IDを、ターゲットHeNB/HNBに直接提供してもよい(LGWはまた、この情報をMME/SGSNに提供してもよい)。これは、修正ベアラ応答メッセージを使用してSGWを介して行われてもよい。
上記のプロシージャのすべては、LTEシステム、3Gシステム、および、類似の機能性を有する任意の他のシステムに適用可能であってもよい。さらに、使用されているシグナリングメッセージおよび例は、LTEのコンテキストにおけるものであるが、同じことが類似のメッセージを使用する他のシステムにも適用可能であってもよい。本明細書で説明されているプロシージャは、LIPAに関して説明されているが、同一のプロシージャをローカルネットワークにおけるSIPTOに適用可能であってもよい。本明細書で説明されているすべての実施形態は、3G、LTEシステム、および任意の他の無線システムに等しく適用可能である。
実施形態
1.ローカルIPアクセス(LIPA)パケットデータネットワーク(PDN)接続モビリティのための、ターゲットホームNodeB(HNB)において実行される方法であって、無線送信/受信ユニット(WTRU)にハンドオーバするハンドオーバ要求メッセージをソースHNBから受信するステップを備える方法。
2.ハンドオーバ要求メッセージに応答して、ターゲットHNBへのダウンリンクデータパスを変更するパス切替え要求をローカルゲートウェイ(LGW)に送信するステップをさらに備え、LGWはハンドオーバに対するモビリティ管理およびローカルモビリティアンカとして動作する、実施形態1に記載の方法。
3.HNBゲートウェイ(GW)にハンドオーバに関して通知することによって、コアネットワーク(CN)トラフィックに対するダウンリンクデータパスがターゲットHNBに修正されるステップをさらに備える、上記実施形態のいずれかに記載の方法。
4.モビリティ管理エンティティ(MME)/サービングゲートウェイ(SGW)にハンドオーバに関するパス切替え要求を送信することによって、CNトラフィックに対するダウンリンクデータパスがターゲットHNBに修正されるステップをさらに備える、上記実施形態のいずれかに記載の方法。
5.サービング無線ネットワークサブシステム(SRNS)として動作するHNBは、ハンドオーバ後に、WTRUと無線アクセスネットワーク(RAN)との間の無線接続を担当するように継続する上記実施形態のいずれかに記載の方法。
6.制御プレーンシグナリングはSRNSとして動作するHNBにおいて維持される、上記実施形態のいずれかに記載の方法。
7.WTRUが限定加入者グループ加入者リスト上にないという条件で、HNBはSRNSとして動作する、上記実施形態のいずれかに記載の方法。
8.LIPA PDN接続がターゲットHNBによってサポートされないという条件で、LIPA PDNサスペンションを開始するステップをさらに備える、上記実施形態のいずれかに記載の方法。
9.CELL_FACHモビリティの間、ローカルIPアクセス(LIPA)パケットデータネットワーク(PDN)接続を処理するための、ネットワークノードにおいて実行される方法であって、無線送信/受信ユニット(WTRU)からセル更新メッセージを受信するステップを備える方法。
10.セル更新メッセージに応答して、ターゲットセルにおいてLIPA PDN接続のサポートを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
11.ターゲットセルがLIPA PDN接続をサポートしてないという条件で、LIPA PDN接続を非活性化するステップをさらに備える、上記実施形態のいずれかに記載の方法。
12.セル更新メッセージは、既存のLIPA PDN接続のインジケーションを含む、上記実施形態のいずれかに記載の方法。
13.LIPA PDNのサポートの判定は、ターゲットセル、ソースセル、または、コアネットワークのうちの少なくとも1つによって行われる、上記実施形態のいずれかに記載の方法。
14.WTRUは、アクティブなLIPA PDN接続の状態でのCELL_FACHモビリティを無効化する、上記実施形態のいずれかに記載の方法。
15.ローカルゲートウェイ(LGW)間モビリティのための、ソースホームNodeB(HNB)において実行される方法であって、ターゲットHNBがソースLGWに接続されていないと判定するステップを備える方法。
16.ソースLGWおよびターゲットLGWを接続することができることを検証するステップをさらに備える、上記実施形態のいずれかに記載の方法。
17.ソースLGWおよびターゲットLGWを接続することができるという条件で、ソースLGWとターゲットLGWとの間でトンネルを確立するステップをさらに備える、上記実施形態のいずれかに記載の方法。
18.トンネルが確立されるという条件で、データをターゲットLGWに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
19.X2またはIurhインタフェースを介して、ソースHNBからターゲットHNBにデータを転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
20.ネットワークノードは、WTRUからの情報に基づいて、ターゲットLGWを選択する、上記実施形態のいずれかに記載の方法。
21.メンバシップを検証するための、無線送信/受信ユニット(WTRU)において実行される方法であって、ブロードキャストパブリックランドモバイルネットワーク(PLMN)を受信するステップを備える方法。
22.ホワイトリスト上のブロードキャストPLMNの存在を判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
23.ブロードキャスト限定加入者グループ(CSG)IDがホワイトリスト上にあり、および、ホワイトリストCSG IDに関連付けられたPLMNがブロードキャストPLMNと同等であるという条件で、ブロードキャストPLMNを含むようにホワイトリストを修正するステップをさらに備える、上記実施形態のいずれかに記載の方法。
24.WTRUは、修正情報をネットワークに送信する、上記実施形態のいずれかに記載の方法。
25.マネージドリモートアクセス(MRA)セッションを有効化する方法であって、モビリティ管理エンティティ(MME)がMRAセッションに対するパケットデータネットワーク(PDN)接続要求を受信するステップを備える方法。
26.MMEが、PDN接続要求を送信した無線送信/受信ユニット(WTRU)がMRAサービスを使用することを許可されるか否かを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
27.PDN接続要求は、ローカルネットワークに対するアクセスポイントネーム(APN)を含む、上記実施形態のいずれかに記載の方法。
28.PDN接続要求は、ノンアクセスストラタム(NAS)メッセージによって伝達される、上記実施形態のいずれかに記載の方法。
29.NASメッセージは、ローカルゲートウェイ(LGW)識別情報のLGWインターネットプロトコル(IP)アドレスを含む、上記実施形態のいずれかに記載の方法。
30.LGW識別情報は、ローカルホームネットワーク(LHN)識別を含む、上記実施形態のいずれかに記載の方法。
31.MMEは、WTRUが、WTRU加入者データ、および、ホームNodeB(HNB)、ホーム発展型NodeBもしくはローカルゲートウェイ(LGW)のMRA能力に基づいて、MRAサービスを使用することを許可するか否かを判定する、上記実施形態のいずれかに記載の方法。
32.MMEがローカルゲートウェイ(LGW)のアドレスまたはローカルホームネットワーク(LHN)識別のうちの少なくとも1つを使用して、ローカルネットワークにおけるLGWを選択するステップをさらに備える、上記実施形態のいずれかに記載の方法。
33.MMEが、WTRUがMRAサービスを使用することを許可されると判定するという条件で、PDN接続を確立するステップをさらに備える、上記実施形態のいずれかに記載の方法。
34.MMEが、PDN接続がローカルインターネットプロトコル(IP)アクセス(LIPA)接続またはMRA接続であるかのインジケーションを送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
35.インジケーションは、接続性タイプ情報要素(IE)に含まれる、上記実施形態のいずれかに記載の方法。
36.ローカルゲートウェイ(LGW)がインジケーションを受信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
37.LGWが、相関識別(ID)を含む作成セッション応答メッセージを生成するステップをさらに備える、上記実施形態のいずれかに記載の方法。
38.ローカルホームネットワーク(LHN)が、WTRUに対するダウンリンクデータをサービングゲートウェイ(S−GW)に送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
39.LIPA接続のインジケーションがLGWによって受信されるという条件で、LGWがダミーパケットをサービングゲートウェイ(S−GW)に送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
40.ローカルホームネットワーク(LHN)が、WTRUに対するダウンリンクデータをLGWに送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
41.MRA接続のインジケーションがLGWによって受信されるという条件で、LGWがダウンリンクデータをサービングゲートウェイ(S−GW)に転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
42.マクロネットワークにある間に、WTRUをページングするステップをさらに備える、上記実施形態のいずれかに記載の方法。
43.WTRUがページングに応答するときに、ダウンリンクデータをWTRUに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
44.進行中のLIPAセッションによる無線送信/受信ユニット(WTRU)のハンドオーバの間に、ローカルインターネットプロトコル(IP)アクセス(LIPA)セッションを転送する方法であって、モビリティ管理エンティティ(MME)が、WTRUがターゲットセルにおいてマネージドリモートアクセス(MRA)セッションを有することを許可されるかを判定するステップを備える方法。
45.MMEが、ハンドオーバを完了し、または、拒絶するかを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
46.MMEが、進行中のLIPAセッションをターゲットセルにおいてMRAセッションとして継続することができるか否かを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
47.WTRUがターゲットセルにおいてMRAセッションを有することを許可されるという条件で、MMEがハンドオーバを完了することを許可するステップをさらに備える、上記実施形態のいずれかに記載の方法。
48.進行中のMRAセッションによる無線送信/受信ユニット(WTRU)のハンドオーバの間に、マネージドリモートアクセス(MRA)セッションを転送する方法であって、ソースモビリティ管理エンティティ(MME)が、WTRUがMRAセッションに加わっていることをターゲットMMEに示すステップを備える方法。
49.ターゲットMMEが、WTRUがターゲットセルにおいてローカルインターネットプロトコル(IP)アクセス(LIPA)セッションを有することを許可されると判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
50.ターゲットセルにおいてMRAセッションをLIPAセッションとして継続するステップをさらに備える、上記実施形態のいずれかに記載の方法。
51.マネージドリモートアクセス(MRA)セッションを有効化する方法であって、無線送信/受信ユニット(WTRU)がMRAセッションに対するパケットデータネットワーク(PDN)接続要求を開始するステップを備え、PDN接続要求はローカルネットワークに対するアクセスポイントネーム(APN)を含む方法。
52.モビリティ管理エンティティ(MME)が、PDN接続要求を受信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
53.WTRUがMRAサービスを使用することを許可されているか否かを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
54.ローカルIPアクセス(LIPA)パケットデータネットワーク(PDN)接続によるホームNodeB(HNB)モビリティのための方法であって、ソースHNBがWTRUに対するハンドオーバを要求するハンドオーバ要求メッセージをターゲットHNBに送信するステップを備え、ハンドオーバ要求メッセージは、ターゲットHNBとローカルゲートウェイ(LGW)との間で直接ユーザパスを有効化するUEコンテキスト情報を含む方法。
55.ハンドオーバ要求メッセージは、相関識別(ID)またはLGWトンネルエンドポイント識別(TEID)を含む、上記実施形態のいずれかに記載の方法。
56.LGWは、ソースHNBまたはターゲットHNBと同一位置に配置される、上記実施形態のいずれかに記載の方法。
57.LGWは、スタンドアロンデバイスである、上記実施形態のいずれかに記載の方法。
58.ターゲットHNBへダウンリンクデータパスを変更するパス切替え要求をLGWに送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
59.HNBゲートウェイ(GW)にハンドオーバに関して通知することによって、コアネットワーク(CN)トラフィックに対するダウンリンクデータパスがターゲットHNBに向かって修正されるステップをさらに備える、上記実施形態のいずれかに記載の方法。
60.モビリティ管理エンティティ(MME)/サービングゲートウェイ(S−GW)にハンドオーバに関して通知して、コアネットワーク(CN)ダウンリンクトラフィックに対するデータパスを切り替えるステップをさらに備える、上記実施形態のいずれかに記載の方法。
61.ハンドオーバの後、サービング無線ネットワークサブシステム(SRNS)が、UEと無線アクセスネットワーク(RAN)との間の無線接続を担当することを継続する、上記実施形態のいずれかに記載の方法。
62.SRNSは、S1またはIu/Iuhを終了する、上記実施形態のいずれかに記載の方法。
63.コアネットワークと無線アクセスネットワーク(RAN)との間の制御プレーンにおけるシグナリングは、サービング無線ネットワークサブシステムを通じてルーティングされることを継続する、上記実施形態のいずれかに記載の方法。
64.ハンドオーバ後に、ユーザプレーントラフィックは、LGWからターゲットHNBへルーティングされる、上記実施形態のいずれかに記載の方法。
65.ハンドオーバ後に、ユーザプレーントラフィックは、サービング無線ネットワークサブシステム(SRNS)を通じてルーティングされる、上記実施形態のいずれかに記載の方法。
66.ハンドオーバ後に、制御シグナリングパスおよびLIPAデータパスは同一のままであるが、非LIPAデータパスが切り替えられる、上記実施形態のいずれかに記載の方法。
67.ハンドオーバの前、または、ハンドオーバの間に、UEに対して加入者チェックを実行して、WTRUがターゲットセルにおいてLIPAサービスに対して許可されるかを保証するステップをさらに備える、上記実施形態のいずれかに記載の方法。
68.LGWは、LIPA PDN接続を確立すると、コアネットワーク(CN)ノードから加入者情報を取得する、上記実施形態のいずれかに記載の方法。
69.LGWは、それがパス切替え要求メッセージを受信したときに、サブスクリプションをチェックする、上記実施形態のいずれかに記載の方法。
70.LIPAベアラがターゲットセルにおいてサポートされない場合に、LIPA PDN接続を解放するステップをさらに備える、上記実施形態のいずれかに記載の方法。
71.ターゲットHNBが、WTRUがLIPA PDN接続を有していることを、WTRU無線アクセスベアラコンテキストにおける相関IDの存在から判定する、上記実施形態のいずれかに記載の方法。
72.LIPA PDN接続の解放は、ターゲットセル、LGW、または、コアネットワークによって開始される、上記実施形態のいずれかに記載の方法。
73.LIPAがターゲットセルにおいてサポートされているか否かでも、ソースHNBがLIPA PDN接続を非活性化しない、上記実施形態のいずれかに記載の方法。
74.WTRUがCELL_FACH状態にある、上記実施形態のいずれかに記載の方法。
75.ネットワークは、セル更新プロシージャに間に、または、CELL_FACHモビリティの間もしくはその後に、LIPA PDN接続を非活性化する、上記実施形態のいずれかに記載の方法。
76.WTRUがセル更新プロシージャの間に、ルーティングエリア更新(RAU)を実行するステップをさらに備える、上記実施形態のいずれかに記載の方法。
77.ルーティングエリア識別が変化しなかった場合でも、WTRUがRAUを実行する、上記実施形態のいずれかに記載の方法。
78.サービングGPRSサポートノード(SGSN)がLIPA PDN接続の非活性化をトリガするステップをさらに備える、上記実施形態のいずれかに記載の方法。
79.SGSNが無線ネットワークコントローラ(RNC)リロケーションに対する要求を受信した場合に、WTRUが新たなセルに移動したかを検証する、上記実施形態のいずれかに記載の方法。
80.SGSNが、ターゲットセル識別子を、LIPA PDN接続が確立されたソースセルのセル識別と比較する、上記実施形態のいずれかに記載の方法。
81.LGWのアドレスは、無線ネットワークコントローラ(RNC)リロケーションを実行するSGSNへの要求に含まれる、上記実施形態のいずれかに記載の方法。
82.要求は、ターゲットHNBが接続するLGWのアドレスを含む、上記実施形態のいずれかに記載の方法。
83.SGSNが、LGWのアドレスをLIPA PDN接続に使用されているLGWと比較する、上記実施形態のいずれかに記載の方法。
84.無線ネットワークコントローラ(RNC)のリロケーションに対する要求は、SGSNがLGWおよびWTRUへのLIPA PDN接続を非活性化するようにトリガする、上記実施形態のいずれかに記載の方法。
85.SGSNへのリロケーション要求が、ソース無線ネットワークコントローラ(RNC)によって送信される、前記実施形態のいずれかに記載の方法。
86.ソースHNBは、LIPA PDN接続を、接続モードのハンドオーバが行われるかのように処理する、上記実施形態のいずれかに記載の方法。
87.LIPA PDNの非活性化が、SGSNへのリロケーションに対する要求が送信される前に行われる場合、SGSNは、LIPA PDN接続がソースHNBによってリリースされているかどうかを検証する、上記実施形態のいずれかに記載の方法。
88.SGSNが、LIPA PDN接続が非活性化されているか、または、非活性化される必要があることをソース無線ネットワークコントローラ(RNC)に示す、上記実施形態のいずれかに記載の方法。
89.LIPA PDN接続が存在する場合に、WTRUがCELL_FACHモビリティを無効化する、上記実施形態のいずれかに記載の方法。
90.WTRUに対したアクティブなLIPA PDN接続が存在する場合に、ソースHNBがサービング無線ネットワークコントローラ(RNC)リロケーションを実行しない、上記実施形態のいずれかに記載の方法。
91.ソースRNCが、確立されたトンネルを介してLIPAデータをターゲットRNCに転送することを保持し、および、LIPA PDN接続が維持される、上記実施形態のいずれかに記載の方法。
92.無線ネットワークコントローラ(RNC)リロケーションが実行されない場合でも、LIPAベアラは非活性化され、および、非LIPAベアラは維持される、上記実施形態のいずれかに記載の方法。
93.UPLINK SIGNALLING TRANSFERメッセージがターゲット無線ネットワークコントローラ(RNC)によって使用されて、共通制御チャネル(CCCH)上で受信されたメッセージをサービングRNCに転送する、上記実施形態のいずれかに記載の方法。
94.ソースRNCは、SRNC無線ネットワーク一時識別(S−RNTI)を検証し、および、WTRUがLIPAベアラを有していたか否かを判定し、WTRUがLIPAベアラを有していた場合に、ソースRNCは、LIPAベアラを解放することをLGWに通知する、上記実施形態のいずれかに記載の方法。
95.UEが、WTRUがセル更新メッセージにLIPA PDN接続を有しているというインジケーションを含める、上記実施形態のいずれかに記載の方法。
96.WTRUコンテキストがフェッチされ、および、ターゲットセルに転送される前に、ローカルネットワークにおけるLIPAをターゲットセルにおいて継続することができるか否かを検証するステップをさらに備える、上記実施形態のいずれかに記載の方法。
97.ローカルIPアクセス(LIPA)パケットデータネットワーク(PDN)接続によるホームNodeB(HNB)モビリティのための方法であって、WTRUがLIPAカバレッジの外へ移動するときに、LIPAベアラをサスペンドするステップを備える方法。
98.UEがLIPAをサポートするセルに戻ったときに、LIPAベアラを再開するステップをさらに備える、上記実施形態のいずれかに記載の方法。
99.ソースセルが、LIPAベアラをターゲットセルにハンドオーバすることができないと判定した場合に、ソースセルはLIPAベアラに対するコンテキストを除去し、LIPA PDN接続を非活性化することを他のノードに通知しない、上記実施形態のいずれかに記載の方法。
100.ソースセルは、LIPA PDN接続がアクティブであるが、ターゲットセルにおいて現在LIPAベアラがセットアップされていないという特別なインジケーションを、ローカルゲートウェイ(LGW)およびコアネットワーク(CN)ノードに送信する、上記実施形態のいずれかに記載の方法。
101.特別なインジケーションを受信すると、LGWがWTRUに対するすべてのダウンリンクトラフィックをバッファリングするステップをさらに備える、上記実施形態のいずれかに記載の方法。
102.WTRUがLIPAカバレッジに入り、および、LIPAベアラが再開されたときに、バッファリングされたトラフィックがWTRUに送信される、上記実施形態のいずれかに記載の方法。
103.WTRUが、タイマが満了するまでLIPAカバレッジに戻らない場合に、バッファリングされているデータを破棄するステップをさらに備える、上記実施形態のいずれかに記載の方法。
104.WTRUがアイドルモードに入るステップをさらに備え、WTRUがサスペンドされたLIPAベアラを有している場合、バッファリングされているデータを破棄するためのタイマが停止される、上記実施形態のいずれかに記載の方法。
105.WTRUが接続モードに戻ったときに、タイマが再開する、上記実施形態のいずれかに記載の方法。
106.WTRUがトラッキングエリア更新(TAU)またはルーティングエリア更新(RAU)を実行するステップをさらに備える、上記実施形態のいずれかに記載の方法。
107.WTRUがキャンプオンしているセルがLIPAをサポートしているかをチェックするステップをさらに備える、上記実施形態のいずれかに記載の方法。
108.セルがLIPAをサポートしている場合に、LIPAベアラは再開され、および、ローカルゲートウェイ(LGW)はバッファリングされているデータをWTRUに送信する、上記実施形態のいずれかに記載の方法。
109.LIPAベアラのサスペンションは、ソースセル、ターゲットセル、ローカルゲートウェイ、またはコアネットワークによって開始される、上記実施形態のいずれかに記載の方法。
110.ローカルIPアクセス(LIPA)パケットデータネットワーク(PDN)接続によるホームNodeB(HNB)モビリティのための方法であって、LIPA PDN接続による無線アクセス技術(RAT)間ハンドオーバに対するハンドオーバ要求メッセージをコアネットワークノードに送信するステップを備える方法。
111.RAT間ハンドオーバは、ホームNodeB(HNB)とホーム発展型NodeB(HeNB)との間である、上記実施形態のいずれかに記載の方法。
112.RAT間ハンドオーバは、ホーム(発展型)NodeB(H(e)NB)とマクロネットワークNodeBとの間である、上記実施形態のいずれかに記載の方法。
113.ハンドオーバ要求メッセージは、アクティブなLIPA PDN接続が存在し、および、LIPAベアラはターゲットセルに転送される必要があることを示す、上記実施形態のいずれかに記載の方法。
114.WTRUコンテキスト情報は、相関IDまたはローカルゲートウェイ(LGW)トンネルエンドポイント識別(TEID)とともにターゲットセルに送信される、上記実施形態のいずれかに記載の方法。
115.LIPAベアラをターゲットセルにおいて受け付けることができるかを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。
116.ターゲットセルがローカルゲートウェイ(LGW)とのユーザプレーン接続を作成するステップをさらに備える、上記実施形態のいずれかに記載の方法。
117.ターゲットセルがLGWとトンネルエンドポイント識別子(TEID)を交換するステップをさらに備える、上記実施形態のいずれかに記載の方法。
118.LGWがサービングGPRSサポートノード(SGSN)との接続を作成するステップをさらに備える、上記実施形態のいずれかに記載の方法。
119.ローカルIPアクセス(LIPA)パケットデータネットワーク(PDN)接続によるホームNodeB(HNB)モビリティのための方法であって、ソースローカルゲートウェイ(LGW)からターゲットLGWにLIPA PDN接続によるハンドオーバに対するハンドオーバ要求メッセージを送信するステップを備える方法。
120.ソースLGWとターゲットLGWとの間の直接インタフェースを介してソースLGWからターゲットLGWにデータを転送するステップをさらに備える、実施形態65に記載の方法。
121.ソースHeNBが、モビリティ管理エンティティ(MME)、ターゲットLGW、または、ターゲットHNBからターゲットLGWに関する情報を取得する、上記実施形態のいずれかに記載の方法。
122.ソースHNBが、ターゲットHeNBがLIPAベアラとのLGW間ハンドオーバをサポートしているというインジケーションをターゲットHNBから受信する、上記実施形態のいずれかに記載の方法。
123.ソースLGWが、IPポイントオブプレゼンス(IP POP)に留まり、および、WTRUのIPアドレスはハンドオーバ後も変化しない、上記実施形態のいずれかに記載の方法。
124.UEが、ハンドオーバ後に、新たなIPアドレスを取得する、上記実施形態のいずれかに記載の方法。
125.X2またはIurhインタフェースを介してソースHNBからターゲットHNBにデータを転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
126.データをソースHNBからターゲットLGWに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
127.ターゲットLGWがターゲットHNBを介してデータをWTRUに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
128.サービングゲートウェイ(S−GW)を介してソースLGWからターゲットLGWにデータを転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。
129.WTRUがソースLGWのカバレッジの外へ移動するときに、ソースHNBがLIPA PDN接続を非活性化しない、上記実施形態のいずれかに記載の方法。
130.セルのパブリックランドモバイルネットワーク(PLMN)識別を含むセルからブロードキャストを受信するステップをさらに備える、上記実施形態のいずれかに記載の方法。
131.PLMN IDがWTRUのホワイトリストに含まれていないが、同等のPLMNである場合、WTRUがPLMNを含むようにホワイトリストを更新する、上記実施形態のいずれかに記載の方法。
132.WTRUが、ホワイトリストの更新の結果として、トラッキングエリア更新(TAU)またはルーティングエリア更新(RAU)を開始する、上記実施形態のいずれかに記載の方法。
133.トラッキングエリア識別(TAI)もしくはルーティングエリア識別(RAI)、または、TAU/RAUタイマの満了の変更がない場合であっても、WTRUがTAUまたはRAUを開始する、上記実施形態のいずれかに記載の方法。
134.LIPAサービスアクセス認可(authorization)は、アクセスポイントネーム(APN)、限定加入者グループ(CSG)、および、パブリックランドモバイルネットワーク(PLMN)の組合せに基づいて定義される、上記実施形態のいずれかに記載の方法。
135.セルは、パブリックランドモバイルネットワーク(PLMN)毎に複数の限定加入者グループ(CSG)識別子(ID)をブロードキャストする、上記実施形態のいずれかに記載の方法。
136.セルを共有する各PLMN毎に1つのCSG IDがブロードキャストされる、上記実施形態のいずれかに記載の方法。
特徴および要素が特定の組合せで上記説明されているが、当業者であれば、それぞれの特徴もしくは要素は単独で、または他の特徴および要素と組み合わせて使用してもよいことを理解するであろう。加えて、本明細書で説明されている実施形態は、コンピュータまたはプロセッサにより実行できるようにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにより実装されてもよい。コンピュータ可読媒体の例は、電子信号(有線で、または無線接続で送信される)およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリーメモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体(例えば、内蔵ハードディスクまたはリムーバブルディスク)、光磁気媒体、ならびに、コンパクトディスク(CD)またはデジタル多用途ディスク(DVD)などの光学媒体を含むが、それらに限定されない。ソフトウェアと関連するプロセッサは、WTRU、UE、端末、基地局、NodeB、eNB、HNB、HeNB、AP、RNC、無線ルータ、またはホストコンピュータにおいて使用するための無線周波送受信機を実装するために使用されてもよい。