JP5453539B2 - 電気通信システムにおける方法および装置 - Google Patents

Description

本発明はＲＡＴ間ハンドオーバ手順に関する。

本発明は、通信ネットワーク内のＲＡＴ（無線アクセス技術）間ハンドオーバに関する。３ＧＰＰ ＥーＵＴＲＡＮ（ロングタームエヴォリューション：ＬＴＥとも呼ばれる）の標準化において、ＲＡＴ間ハンドオーバについての解決策が合意に達した。本明細書で用いられる場合、ＥーＵＴＲＡＮは３ＧＰＰによって開発および標準化されたセルラ無線システムを示し、ｅＮｏｄｅＢ（ｅＮＢ）はＥーＵＴＲＡＮ無線基地局ノードを示す。そのようなｅＮｏｄｅＢは複数のＥーＵＴＲＡＮセルを受け持つかもしれない。

ユーザモビリティを処理する機能はセルラネットワークの根本的な構成である。サービス品質の見地からは、そのような機能は、アクティブセッション中に無線通信機器のユーザがあるセルから別のセルに移動した場合でもサービス継続性が維持されること、また新しいセッションの各々が十分に良好な無線環境で確立されることを保証しなければならない。スペクトル効率の見地からは、そのような機能は、アクティブなユーザが常に、１つ以上の（ＥーＵＴＲＡＮではｅＮｏｄｅＢ、ＵＴＲＡＮではＲＮＣ（無線ネットワーク制御装置）といった）最適なリモート無線ユニット（無線という観点からは最も距離の近いリモート無線ユニットを意味するであろう）によってサービスを提供されることを保証すべきである。そのため、例えば無線通信機器が異なるセル間を移動する場合に、無線通信機器が最初のセルの範囲外に出たときの呼の切断を回避するため、ハンドオーバを時々実行する必要があるだろう。

ＵＴＲＡＮからＥーＵＴＲＡＮへのＲＡＴハンドオーバ手順は、ネットワークがハンドオーバの実行を決定した際に行われる。ＵＴＲＡＮからＥーＵＴＲＡＮへのＰＳハンドオーバを実行する決定は、ＵＴＲＡＮ在圏ＲＮＣ（ＳＲＮＣ）によってなされ、この決定はユーザ機器，ＵＥによってＳＲＮＣに報告される無線状況測定に基づいてもよい。

３ＧＰＰ ＴＳ２３．４０１、5.5.2.2章は、ＵＴＲＡＮからＥーＵＴＲＡＮへのハンドオーバ準備およびハンドオーバ実行シグナリングの概要を与えている。

ＥーＵＴＲＡＮへのハンドオーバを決定する前に、ＳＲＮＣはＵＥがＥーＵＴＲＡと互換性を有するかチェックするであろう。さらに、そのようなＵＥは、ＳＲＮＣによってＥーＵＴＲＡセル上で測定を実行するように設定されてよく、そのような目的のために圧縮モードが設定される必要があるかもしれない（ＵＥの能力に依存する）。圧縮モードは別の周波数（周波数間）または別の無線技術（ＲＡＴ間）で測定を行う際に必要である。圧縮モードでは、送信および受信を短時間停止し、その間に他の周波数またはＲＡＴ上で測定を実施する。測定が終わった後、送信および受信が再開する。データが失われないことを確保するため、フレーム内でデータを圧縮し、測定を実行することが可能な空き時間を生成する。

これは、ハンドオーバが開始される際、それに先立って無線リソース再設定、測定再設定、測定および測定報告といった複数の工程が行われることを意味する。ＥーＵＴＲＡへのハンドオーバがある理由によって許されない場合、これらの工程は無駄になるであろう。代わりに、ＵＥがＥーＵＴＲＡセルで測定するように構成されているが、他の代わりの工程（例えば、別の無線技術、別のＵＲＴＡ周波数での測定）が禁止されているかもしれない。可能性のあるＵＥ制限および／またはＵＴＲＡＮ制限のため、ＵＥから受信したＵＥ測定結果が例えば現在のＵＴＲＡセル／周波数における悪い無線状況を示す際に、ＳＲＮＣは何をすべきかを選択しなければならない。さらに、無線状況に起因してハンドオーバが開始された場合、ハンドオーバは成功する見込みが十分に高い必要がある。さもなければ、呼が切断されるかもしれない。

ＵＴＲＡアクセスシステムで動作するユーザは、例えばＳＩＭタイプのＵＭＴＳ集積回路カード(UICC)を用いるＧＳＭサブスクリプションまたはＵＳＩＭ(汎用加入者識別モジュール）タイプのＵＩＣＣを用いるＵＭＴＳサブスクリプションのいずれかを有することができる。ＵＩＣＣタイプに応じて、異なる認証／暗号鍵配送方式（ＡＫＡ）アルゴリズムが用いられる。ＡＫＡ手順は、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）とＵＥ内のＵＩＣＣとの間で実行される。ＡＫＡ手順を開始するのはＳＧＳＮであり、通常はアタッチごと、すなわち在圏ネットワークへの最初の登録ごと（例えば電源オン時）に行われる。ＡＫＡ手順は、ＵＥが既にアタッチされている際にも行われてよい。典型的な場合は、新たなＳＧＳＮにおけるルーティングエリア更新時である。実行されるＡＫＡのタイプは、ユーザのホーム環境のユーザのＨＬＲ／ＡｕＣ（ホームロケーションレジスタ／認証センタ）からＳＧＳＮが受信しているセキュリティ情報に依存する。ＨＬＲ／ＡｕＣから受信するセキュリティ情報は、ユーザがＧＳＭサブスクリプションを有する場合には暗号鍵Ｋｃを含んでおり、ユーザがＵＭＴＳサブスクリプションを有する場合には暗号鍵ＣＫおよび完全性保護鍵ＩＫを含んでいる。ＳＩＭタイプのＵＩＣＣでサポートされているＧＳＭ ＡＫＡにおいて、暗号鍵Ｋｃ（６４ビット）は、ＳＩＭによって生成される。ＵＳＩＭタイプのＵＩＣＣでサポートされる、対応するＵＭＴＳ ＡＫＡにおいて、暗号鍵ＣＫ（１２８ビット）および完全性保護鍵ＩＫ（１２８ビット）はＵＳＩＭによって生成される。

異なるＡＫＡアルゴリズム（例えば生成される鍵やセキュリティ鍵の長さの相違）は、ＳＩＭタイプのＵＩＣＣを装着するＵＥのセキュリティレベルを、ＵＳＩＭタイプのＵＩＣＣを備えるＵＥよりも低くするものと考えられる。

ＳＧＳＮは、ユーザＨＬＲ／ＡｕＣ（ホームロケーションレジスタ／認証センタ）から受信した情報に基づいて、関連するＡＫＡをＵＥに向けて開始する。ＡＫＡ手順はＵＥとＳＧＳＮとの間でのシグナリングを用いて実行され、ＵＴＲＡＮを通じて透過的である。

ユーザデータおよび制御データの暗号化および完全性保護はＵＥとＳＲＮＣとの間で実行される。すなわち、暗号化および完全性アルゴリズムはＵＥおよびＳＲＮＣに割り振られている。

ＵＴＲＡアクセスについて規定されている暗号化および完全性保護アルゴリズムは、１２８ビット長のセキュリティ鍵を用いる。ＧＳＭサブスクリプション（ＳＩＭ）を有するユーザもまたＵＴＲＡＮでサービスをうけるためのサポートを提供するため、ＵＭＴＳ暗号鍵および完全性保護鍵（ＣＫおよびＩＫ）を６４ビットＧＳＭ暗号鍵（Ｋｃ）から得る、３ＧＰＰによって規定される以下の２つの変換関数がある。ｃ４はＣＫを得るための変換関数であり、ｃ５はＩＫを得るための変換関数である。
CK[UMTS] = Kc || Kc; (c4)
IK[UMTS] = Kc1 xor Kc2 || Kc || Kc1 xor Kc2; (c5)
ｃ５において、Ｋｃ１およびＫｃ２はいずれも３２ビット長であり、Ｋｃ＝Ｋｃ１||Ｋｃ２である。

このように、ＧＳＭサブスクリプションを有する（すなわちＳＩＭタイプのＵＩＣＣを保持する）ユーザ／ＵＥがＵＴＲＡＮにアタッチされる際、ＵＥは、ＵＴＲＡアクセスに対して有効なＵＭＴＳ暗号鍵ＣＫおよび完全性保護鍵ＩＫをＧＳＭ暗号鍵Ｋｃから変換関数ｃ４およびｃ５を用いて導出する。セキュリティ鍵はＵＥとＳＲＮＣとの間で送信されるユーザデータおよび制御シグナリングの暗号化および完全性保護のために用いられる。

ＳＧＳＮによっても同じ変換関数が用いられる。ＵＥとＳＲＮＣとの間で暗号化および完全性保護の開始を要求する際に、接続モード(connected mode)のＵＥについて、これら得られたＣＫおよびＩＫがＳＧＳＮからＳＲＮＣへ送信される。

ＵＭＴＳにおけるセキュリティ機能についてのより詳細な情報は、３ＧＰＰ ＴＳ３３．１０２に提供されている。

３ＧＰＰリリース８は、ＵＳＩＭタイプのＵＩＣＣを装着していないＵＥに対するＥーＵＴＲＡ内でのサービス提供をサポートしていない。そのため、ＵＥがＥーＵＴＲＡＮ互換性を有していても、ＵＳＩＭを装着していなければ、ＵＴＲＡネットワークに送信されるそのＵＥの機能情報(capability information)内にＥーＵＴＲＡに関するサポートは全く示されないであろう。その結果、ＵＴＲＡＮはそのＵＥにＥーＵＴＲＡ測定の実施を要求せず、またそのＵＥにＥーＵＴＲＡへのハンドオーバを要求しないであろう。従って、３ＧＰＰリリース８では、ＵＳＩＭを持たないＵＥは上述したように自身のＥーＵＴＲＡＮ互換性を無効化するため、ＵＴＲＡＮからＥーＵＴＲＡＮへハンドオーバすることができない。この無効化は、ＵＥがＥーＵＴＲＡアクセス能力を有していても、ＳＩＭタイプのＵＩＣＣを装着している場合には、アタッチ時にネットワークにＥーＵＴＲＡ非互換性を通知しているであろうことを意味する。これはＵＥがアタッチしている限り変化しないであろう。

しかし、３ＧＰＰリリース９では、通常サービスモードと限定サービスモードの両方について、すなわちＵＥが装着しているＵＩＣＣのタイプとは無関係に、あるいはＵＥがＵＩＣＣを装着していなくても、ＩＭＳ緊急ベアラサービスがサポートされている。3GPP SA WG1 LS 文書 R2-094143、“リリース９におけるＩＭＳ緊急呼に対するUICCレスUEアクセス” (R2-094107 )へのReply LSは、ＵＳＩＭを持たず、ＩＭＳ緊急呼を行うＵＥは、ＵＴＲＡＮからＥーＵＴＲＡＮへのハンドオーバが許可されるべきであると述べている。

そのようなハンドオーバを実現するための、以下のような様々な方法が検討されている（R2-094569 ”ＵＳＩＭレスＵＥに関するＵＴＲＡＮからＥＵＴＲＡＮへのIMS 緊急呼ハンドオーバ”参照）。

選択肢＃１はネットワークベースの方法であり、ＵＥが有効なＵＩＣＣ、すなわち非緊急呼についてＥーＵＴＲＡＮへのハンドオーバを許可するＵＳＩＭ、を有するかどうかを、ＳＧＳＮがＲＮＣに通知する。ＵＳＩＭを持たないＵＥがＩＭＳ緊急呼に関与していればそのＵＥがハンドオーバを許されるよう、ＲＮＣはＵＳＩＭレスＵＥについてＥーＵＴＲＡＮへのハンドオーバを行うべきかどうかの決定に、この情報を用いる。

しかし、選択肢＃１はＳＧＳＮとＲＮＣとの間のシグナリングプロトコル（ＲＡＮＡＰ、３ＧＰＰ ＴＳ２５．４１３）の更新を必要とする。リリース８仕様は凍結されているが、リリース８プロトコル仕様に基づくＲＮＣは何としてもリリース９のＥーＵＴＲＡ互換ＵＥをサポート可能となるべきである。

選択肢＃２はＵＥベースの方法であり、ＵＳＩＭレスＵＥが、ＵＥからＳＲＮＣに送信されるＵＥ機能情報の一部である情報要素ＩＥのうち「ＥーＵＴＲＡ ＦＤＤへのＲＡＴ間ＰＳハンドオーバのサポート」および「ＥーＵＴＲＡ ＴＤＤへのＲＡＴ間ＰＳハンドオーバのサポート」を無効化し、緊急呼のセットアップ時にのみそれらを有効化するが、呼が切断したら再度無効化するというものである。つまり、ＵＳＩＭレスＵＥは、自身のＥーＵＴＲＡＮ能力をＲＲＣ状態と緊急呼が存在するか否かとに基づいて切り替える。

しかし、選択肢＃２は、緊急呼を実行する都度、さらに緊急呼が終わる都度、ＵＥがネットワークに新たなＵＥ機能情報を送信する必要があるため、ＵＥとネットワークとの間で多くのシグナリングが行われる原因となり得る。将来的には緊急呼以外のサービスもＥーＵＴＲＡＮへのハンドオーバを許可されうるため、この方法は不整合の原因となりうるのみならず、柔軟性に欠ける方法であろう。このように、ネットワーク（ＵＴＲＡＮ）がＵＩＣＣタイプを知る必要がある場合、将来的に他の必要性や他のタイプの制限が存在しうる。

従って、ネットワークベースの方法が好ましく、可能なら、ネットワークノード間でのシグナリングプロトコルを変更する必要のない方法が好ましい。

従って、上述した既知の方法の課題を解決又は緩和する方法および装置を提供することが望ましい。

ＵＴＲＡＮにおいては、ＳＲＮＣがＥーＵＴＲＡセルでの測定を開始するとともに、ハンドオーバの決定を行う。ＳＲＮＣはあるＵＥについて設定されている呼／ベアラのタイプについての知見を有している。例えば、ＳＲＮＣはＵＥについて緊急呼が設定されるとき、あるいは設定されないときに関する知見を有している。

ＥーＵＴＲＡＮへのハンドオーバの実行が許可されていないＵＥ、すなわちＵＳＩＭのようなＥーＵＴＲＡについて有効なＵＩＣＣを持たないＵＥでのＥーＵＴＲＡ測定をＳＲＮＣが開始させないよう、また、そのようなＵＥについてネットワーク内でハンドオーバリソース割り当てシグナリングが開始されないよう、ＵＥがどのタイプのＵＩＣＣを有するか、例えばＵＥにＵＳＩＭが存在するか否かを、ＳＲＮＣが知る必要がある。

現状、ＵＥ内のＵＩＣＣのタイプをＲＮＣがどのようにして特定可能かに関する情報は存在しないため、本発明の実施形態はこの問題に対する解決策を提供することを目的とする。

本発明の実施形態の第１の見地は、在圏無線ネットワーク制御装置（ＳＲＮＣ）を有する在圏ネットワーク内で動作するＥーＵＴＲＡ互換ＵＥのＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを制御する、前記ＳＲＮＣにおける方法に関する。前記ＳＲＮＣは、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）から、前記ＵＥが前記在圏ネットワークにアタッチした際に認証および鍵配送方式（ＡＫＡ）で生成されたセキュリティ鍵を受信する。前記方法は以下のステップを有する。
- 前記ＳＧＳＮから受信した前記セキュリティ鍵を解析して、前記ＵＥがどのタイプのＵＩＣＣを備えるかを判別するステップと、
- 前記ＵＥのＥーＵＴＲＡＮへのハンドオーバを許可するか否かの決定の根拠として、前記ＵＥがどのタイプのＵＩＣＣを備えるかの知見を用いるステップ。

特定の実施形態によれば前記方法は、前記ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有するか、前記ＵＥで進行中のサービスのタイプに関する少なくとも１つの条件が満たされる場合に前記ＵＥのＥーＵＴＲＡＮへのハンドオーバが開始されるように、前記ＵＥのＥーＵＴＲＡＮへのハンドオーバを許可するステップを有する。

特定の実施形態において、前記方法は以下のステップを有する。
前記ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有する
前記ＵＥで緊急呼が進行中である
という条件の少なくとも１つが満たされた場合に前記ＵＥのＥーＵＴＲＡＮへのハンドオーバが開始されるよう、前記ＵＥのＥーＵＴＲＡＮへのハンドオーバを許可するステップと、
前記条件がいずれも満たされない場合、前記ＵＥのＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを許可しないステップ。

従って、特定の実施形態によれば、ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有さない場合、ＳＲＮＣはＵＥにおいて、ＥーＵＴＲＡＮへのハンドオーバを許可されるサービス、例えば緊急呼が進行中かどうかを調べる。

特定の実施形態によれば、前記ＳＧＳＮから受信した前記セキュリティ鍵は前記ＳＲＮＣに既知の変換関数を適用することによって解析され、前記変換関数は前記在圏ネットワークにアクセスするための有効なセキュリティ鍵を無効なセキュリティ鍵から得るように規定されている。

特定の実施形態では、前記ＲＡＴ間ハンドオーバがＵＴＲＡＮからＥーＵＴＲＡＮへのハンドオーバである。

本発明の実施形態の第２の見地は、無線ネットワーク制御装置（ＲＮＣ）を有する在圏ネットワーク内で動作する、ＥーＵＴＲＡ互換ＵＥのＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを制御可能な、前記ＲＮＣにおける装置であって、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）用のインタフェースを有し、前記インタフェースが、前記在圏ネットワークに前記ＵＥがアタッチした際に認証および鍵配送方式（ＡＫＡ）で生成されたセキュリティ鍵を前記ＳＧＳＮから受信するように構成されている装置に関する。前記装置は処理ユニットを有し、前記処理ユニットは、
- 前記ＳＧＳＮから受信した前記セキュリティ鍵を解析して、前記ＵＥがどのタイプのＵＩＣＣを備えるかを判別し、
- 前記ＵＥのＥーＵＴＲＡＮへのハンドオーバを許可するか否かの決定の根拠として、前記ＵＥがどのタイプのＵＩＣＣを備えるかの知見を用いる、ことが可能である。

従って、特定の実施形態は在圏無線ネットワーク制御装置（ＳＲＮＣ）における、ＵＥ内のＵＭＴＳＩＣカード（ＵＩＣＣ）のタイプを、ＣＫおよびＩＫのようなセキュリティ鍵と、指定された変換関数とを用いて判別する方法を提供する。変換関数は、ＧＳＭ ＡＫＡのような認証および鍵配送方式（ＡＫＡ）が実行されている場合に、前記ＵＥがどのタイプのＵＩＣＣ、例えばＵＳＩＭまたはＳＩＭを有するかを判別するために適用されるものである。

本発明の特定の実施形態においては、ＳＩＭを有するＵＥはＵＴＲＡアクセスにおけるＥーＵＴＲＡ互換を示すことが許可されているものとする。

ＵＩＣＣタイプに関する情報は、ＥーＵＴＲＡＮ互換ＵＥがＥーＵＴＲＡセル測定を実行すべきかどうか、およびＥーＵＴＲＡセルへのハンドオーバを開始させてよいかどうかをＳＲＮＣが決定するために用いられてよい。これにより、ＥーＵＴＲＡ互換で、かつ（ＥーＵＴＲＡリリース９について定められる緊急呼のような）ＥーＵＴＲＡＮへのハンドオーバが許されるタイプのサービスが進行中であるＵＥや、非緊急呼のような任意のタイプのサービスが進行中の、ＵＳＩＭを有するＵＥに対する、ＥーＵＴＲＡセル測定およびＵＴＲＡからＥーＵＴＲＡへのハンドオーバの設定をＳＲＮＣが制限できるようになる。従って、例えばＳＩＭタイプのＵＩＣＣを有するＵＥは、ＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを準備したり開始したりすることを禁止されてよい。あるいは、例えば緊急呼が進行中の場合には、ＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを準備したり開始したりすることを許可されてよい。

本発明の特定の実施形態の別の見地は、ＲＮＣであって、前記ＲＮＣにアタッチしているＵＥに対して在圏ＲＮＣ（ＳＲＮＣ）として振る舞うことが可能なＲＮＣに関する。本発明の特定の実施形態に係る前記ＲＮＣは、ＣＫおよびＩＫのようなセキュリティ鍵と、ＧＳＭ ＡＫＡのような認証および鍵配送方式（ＡＫＡ）が実行されている場合に適用される、指定された変換関数とを用いて、ＵＥ内のＵＭＴＳＩＣカード（ＵＩＣＣ）のタイプを判別するように構成されたプロセッサを有する。

本発明の他の目的、利点および新規な機能は、以下の発明の詳細な説明を添付図面とともに検討することにより明らかになるであろう。

本発明の実施形態を適用可能なシグナリングフローを示す図である。 本発明の実施形態に係る方法を示すフローチャートである。 本発明に係るＲＮＣの構成を模式的に示す図である。

本発明は、以下の、本発明の実施形態の非限定的な説明において例示可能である。以下の説明では、在圏ＲＮＣがＵＭＴＳ暗号鍵ＣＫおよび完全性保証鍵ＩＫを在圏ＧＰＲＳサポートノードから受信する、ＵＴＲＡＮからＥーＵＴＲＡＮへのハンドオーバに関するシナリオについて説明する。しかし、本発明はこのような特定の鍵に限定されるものと解されるべきではない。別のシナリオでは、ＵＥが在圏ネットワークにアタッチする際に認証および鍵配送方式によって生成される他の鍵について、本発明の特定の実施形態に係る原理を適用することができる。

図１は、以下の、本発明の特定の実施形態の詳細な説明において参照されるシグナリングを模式的に示している。

図１のステップ６で示される認証手順に先立って、ＵＥをネットワークにアタッチする際の接続設定に関する既知のステップ１〜５が行われる。これらの先行するステップは本発明に直接関係しないため、これ以上の説明は行わない。

例えば３ＧＰＰ ＴＳ３３．１０２に代表される従来技術によれば、ＵＥコネクションについてのセキュリティ機能の開始時、すなわちＵＥとＳＲＮＣとの間におけるユーザデータおよび制御データの暗号化ならびに制御データの完全性保護で、ＳＧＳＮはＵＭＴＳ暗号鍵ＣＫとＵＭＴＳ完全性保護鍵ＩＫとをセキュリティモードコマンドでＳＲＮＣへ送信する（図７、ステップ７．１）。新たなＡＫＡ手順の後、ＵＥがＵＥとＳＧＳＮとの間のシグナリングコネクションを持つと、セキュリティ機能が開始される。鍵ＣＫ，ＩＫはいずれも１２８ビット長である。暗号化および完全性保護アルゴリズムはＳＲＮＣおよびＵＥで実行される。ＣＫおよびＩＫとともに、ＳＲＮＣはさらに、使用すべき許可されているセキュリティについての情報をＳＧＳＮから受信する。従来技術では、ＵＥがどのタイプのＵＩＣＣを備えているかについての情報がＳＧＳＮからＳＲＮＣへ提供されることはない。

本発明の特定の実施形態によれば、ＳＧＳＮから鍵ＣＫ，ＩＫを受信した後、ＳＲＮＣは SECURITY MODE COMMANDメッセージでＳＧＳＮから受信したセキュリティ鍵ＣＫおよびＩＫを用いて、ＵＥが備えるＵＩＣＣのタイプをＵＥコネクションのために特定する。これは、ＳＲＮＣに既知の鍵変換関数の特性を用いて行うことができる。この鍵変換関数はＳＧＳＮによって既に用いられていてもよく、またＵＥは在圏ネットワークに有効な鍵を得る。鍵変換関数は３ＧＰＰ ＴＳ３３．１０２に規定されているＧＳＭからＵＭＴＳへの鍵変換関数であってよい。

本発明の特定の実施形態によれば、ＳＲＮＣはＵＥをＥーＵＴＲＡセル測定を行うように設定（図１のステップ１１、１２参照）すべきかどうか、および／または測定報告（図１のステップ９参照）が低品質を示すことに基づいてＥーＵＴＲＡＮへのハンドオーバを開始させる（図１のステップ１３参照）べきかどうかの決定に、ＵＥがＵＳＩＭを有するか否かに関する知見を、ＵＥ能力および進行中の呼のタイプといった他の情報とともに用いる。なお、ＥーＵＴＲＡへのハンドオーバが開始される前のＥーＵＴＲＡセル測定は必ずしも行わなくてもよい。このようなハンドオーバの決定は、例えばＵＴＲＡセルおよびＥーＵＴＲＡセルが重複したカバー範囲を有する場合、ＵＴＲＡセル測定に基づいてなされてもよい。

本発明の実施形態に係る、在圏ＲＮＣ（ＳＲＮＣ）で実行される方法を、図２を参照して説明する。なお、方法のステップは参照数字が示唆するものとは多少異なる時系列で実行されてもよく、その一部、例えばステップ２０２と２０３は順序を入れ替えた時系列で実行されてもよい。

ステップ２０１で、ＳＲＮＣはＵＭＴＳ暗号化鍵ＣＫおよびＵＭＴＳ完全性保護鍵ＩＫをＳＧＳＮからSecurity Control Commandで受信する。これらの鍵はＵＥとＳＲＮＣとの間で送信されるユーザデータおよび制御シグナリングの暗号化および完全性保護のために用いるべきものである。

ステップ２０２でＳＲＮＣは、ＳＧＳＮから受信したセキュリティ鍵を解析して、ＵＥがどのタイプのＵＩＣＣを備えているかを判別する。これは、ＳＲＮＣに既知の鍵変換関数の特性を用いることで実現できる。

ＴＳ３３．１０２、第６．８．２．４節によれば、Ｒ９９＋ ＶＬＲ／ＳＧＳＮ（ここで、Ｒ９９＋は、３ＧＰＰリリース９９以降の仕様に準拠したネットワークノードまたはＵＥであることを示す）および、ＳＩＭが挿入されたＵＥは、以下の変換関数を用いてＧＳＭ暗号鍵からＵＭＴＳ暗号化鍵／完全性鍵ＣＫおよびＩＫを得なければならない。
CK[UMTS] = Kc || Kc; （式ｃ４）
IK[UMTS] = Kc1 xor Kc2 || Kc || Kc1 xor Kc2; （式ｃ５）
ｃ５において、Ｋｃ１およびＫｃ２はいずれも３２ビット長であり、Ｋｃ＝Ｋｃ１||Ｋｃ２である。

ＵＩＣＣタイプのＩＤの導出のため、ＳＲＮＣは以下のチェックを行う。
・ ＳＧＳＮから受信したＣＫが、２つの同一な６４ビットＫｃから構成されているか（式ｃ４）、すなわち、ＣＫの下位６４ビットがＣＫの上位６４ビットと同一か？
もし、「ＮＯ」なら、ＵＥにはＵＳＩＭが挿入されている。
もし「ＹＥＳ」なら、ＩＫをＫｃから算出するための式（すなわち、式ｃ５）に従って、以下のようにテスト値を算出する。テスト値= Kc1 xor Kc2 || Kc || Kc1 xor Kc2
ここで、Kc = Kc1 || Kc2は上述した２つの同一な６４ビットＫｃの一方であり、Ｋｃ１およびＫｃ２はいずれも３２ビット長である。
・ テスト値がＳＧＳＮから受信したＩＫと等しければ、
・ ＵＥにはＳＩＭが挿入されており、
・ さもなければ
・ ＵＥにはＵＳＩＭが挿入されている。
上述の通り、ＵＳＩＭは、ＥーＵＴＲＡＮに有効なＵＩＣＣである。

ステップ２０３でＳＲＮＣはＵＥから、例えば測定報告において、ＵＥが置かれている無線品質が悪いという、ハンドオーバが必要かもしれないことを示す情報を受信する。

ＥーＵＴＲＡＮへのハンドオーバが最適な選択肢であり、ＵＥがＥーＴＲＡＮ互換であれば、ＳＲＮＣはステップＳ２０４においてＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを装着しているかチェックする。これは、ＳＧＳＮから受信したセキュリティ鍵を、例えば上述した変換関数ｃ４およびｃ５を用いて解析することにより実現される。

ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを装着していれば、ＳＲＮＣはステップ２０５に従ってＥーＵＴＲＡＮへのハンドオーバを開始してよい。

ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを備えていない場合、特定の実施形態においてＳＲＮＣは、ステップ２０６において、ＵＥで進行中のサービスがＵＥの備えるＵＩＣＣのタイプに関わらずＥーＵＴＲＡＮへのハンドオーバを許されているタイプかどうかをさらにチェックする。そのようなサービスは例えば緊急呼であって良い。

ＵＥが利用中のサービスが、ＵＥで進行中のサービスがＵＥの備えるＵＩＣＣのタイプに関わらずＥーＵＴＲＡＮへのハンドオーバを許されているタイプであれば、ステップ２０５でＳＲＮＣはＥーＵＴＲＡＮへのハンドオーバを開始させてよい。

さもなければ、ステップ２０７に従ってＳＲＮＣはそのＵＥについてＥーＵＴＲＡＮへのハンドオーバを開始させず、それによって、ＵＥがＥーＵＴＲＡ測定が行われた場合に消費するであろうリソースを節約することができる。

図３は本発明の特定の実施形態に係るＲＮＣにおける装置３００を模式的に示している。このＲＮＣは、セルラ通信ネットワークにおいて、ＥーＵＴＲＡ互換性を有するＵＥに対して在圏ＲＮＣとして振る舞うことができる。このＲＮＣはＥーＵＴＲＡ互換性を有するＵＥの、ＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを制御可能である。なお、図３においては、簡潔さのために、発明の実施形態に係る方法および装置の理解に不要な内部構成は省略してあることに留意されたい。また、装置３００が備える図示されたユニットは、論理エンティティと見なされるべきものであって、別個の物理エンティティである必要はない。

装置３００は、在圏ＧＰＲＳサポートノード（ＳＧＳＮ）と通信するためのインタフェース３０１を有する。インタフェース３０１は、ＳＧＳＮから、ＵＥが在圏ネットワークにアタッチした際に認証および鍵配送方式（ＡＫＡ）によって生成されたセキュリティ鍵を受信するように構成されている。このセキュリティ鍵はＵＭＴＳ暗号化鍵ＣＫおよびＵＭＴＳ完全性保護鍵ＩＫであってよい。

装置はさらに、暗号化および完全性保護部３０２を有する。暗号化および完全性保護部３０２は、ＲＮＣがＵＥに対する在圏ＲＮＣとして振る舞う際に、受信したセキュリティ鍵を用い、ＲＮＣとＵＥとの間で送信されるユーザデータおよび制御シグナリングの暗号化および完全性保護を受け持つ。

装置はさらに、処理部３０３を備える。処理部３０３は、ＵＥがどのタイプのＵＩＣＣを装着しているかを、ＳＧＳＮから受信したセキュリティ鍵を解析することによって判別することができ、ＵＥにＥーＵＴＲＡＮへのハンドオーバを許可するかどうかの決定に、ＵＥがどのタイプのＵＩＣＣを装着しているかの知見を用いることができる。

図２に示した方法について説明したように、これは、ＳＲＮＣに既知の鍵変換関数の特性を用いることによって上述の通り行うことができる。

このように本発明の実施形態は、緊急呼のような所定のタイプの呼が進行中のＥーＵＴＲＡ互換性を有するＵＥや、非緊急呼のような任意のタイプの呼が進行中のＥーＵＴＲＡ互換かつＵＳＩＭを有するＵＥに対する、ＥーＵＴＲＡセル測定（図１のステップ１１〜１２）およびＵＴＲＡからＥーＵＴＲＡＮへのハンドオーバ（図１のステップ１３）の設定をＳＲＮＣが制限する可能性を提供する。

本発明の実施形態はＵＴＲＡＮがどのようにＵＥ内のＵＩＣＣのタイプを特定しうるかについての解決策を提供し、この知見は、進行中のＵＥ呼／サービスのタイプに基づいて、ネットワークがＥーＵＴＲＡ互換ＵＥについてＵＥ測定およびＵＴＲＡからＥーＵＴＲＡＮへのハンドオーバを開始することについての柔軟性を提供する。

この可能性は、レイヤ３（Ｌ３）シグナリングを変更することなく、すなわち３ＧＰＰリリース８仕様に基づいて提供することが可能である。

もちろん、本発明はその本質的な特性を維持したまま、ここで説明した方法とは別の方法で実行されてもよい。本実施形態はいかなる意味においても例示的なものであって、本発明を限定するものと解されるべきではない。

略語
3GPP 第３世代パートナシッププロジェクト
AKA 認証および鍵配送方式
AUC 認証センタ
CK 暗号鍵
E-UTRA エヴォルブドUTRA
E-UTRAN エヴォルブドUTRAN
GSM グローバルシステムフォーモバイルミュニケーションズ
HLR ホームロケーションレジスタ
IK 完全性鍵
Kc 暗号鍵
MME 移動管理エンティティ
PS パケットサービス
RAT 無線アクセス技術
RNC 無線ネットワーク制御装置
RRC 無線リソース制御
SRNC 在圏ＲＮＣ
SGSN 在圏ＧＰＲＳサポートノード
SGW 在圏ゲートウェイ
SIM GSM加入者ＩＤモジュール
UE ユーザ端末
UICC ＵＭＴＳＩＣカード
UMTS ユニバーサルモバイルテレコミュニケーションズシステム
USIM 汎用加入者ＩＤモジュール
UTRA ＵＭＴＳ陸上無線アクセス
UTRAN ＵＭＴＳ陸上無線アクセスネットワーク
VLR ビジタロケーションレジスタ

Claims (14)

1. 在圏無線ネットワーク制御装置（ＳＲＮＣ）を有する在圏ネットワーク内で動作するＥーＵＴＲＡ互換ユーザ機器（ＵＥ）の、ＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを制御するための、前記ＳＲＮＣにおける方法であって、
   前記ＳＲＮＣが在圏ＧＰＲＳサポートノード（ＳＧＳＮ）から、前記ＵＥが前記在圏ネットワークにアタッチした際に認証および鍵配送方式（ＡＫＡ）で生成されたセキュリティ鍵を受信するものであって、
   前記方法が、
   前記ＳＲＮＣに既知の鍵変換関数の特性を用いて、前記ＳＧＳＮから受信した前記セキュリティ鍵を解析し、前記ＵＥがどのタイプのＵＩＣＣを備えるかを判別するステップ(202)と、
   前記ＵＥのＥーＵＴＲＡＮへのハンドオーバを許可するか否かの決定(204)の根拠として、前記ＵＥがどのタイプのＵＩＣＣを備えるかの知見を用いるステップと、
   を有することを特徴とする方法。
2. 前記ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有する場合か、前記ＵＥで進行中のサービスのタイプに関する少なくとも１つの条件が満たされる場合に、前記ＵＥのＥーＵＴＲＡＮへのハンドオーバの開始を許可するステップ(206)をさらに有することを特徴とする請求項１記載の方法。
3. 前記ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有する
   前記ＵＥで緊急呼が進行中である
   という条件の少なくとも１つが満たされた場合に、前記ＵＥのＥーＵＴＲＡＮへのハンドオーバの開始を許可するステップと、
   前記条件がいずれも満たされない場合には、前記ＵＥのＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを許可しないステップ(207)と、
   をさらに有することを特徴とする請求項１または請求項２に記載の方法。
4. 前記ＳＧＳＮから受信した前記セキュリティ鍵は前記ＳＲＮＣに既知の変換関数を適用することによって解析され、前記変換関数は前記在圏ネットワークにアクセスするための有効なセキュリティ鍵を無効なセキュリティ鍵から得るように規定されていることを特徴とする請求項１乃至請求項３のいずれか１項に記載の方法。
5. 前記ＲＡＴ間ハンドオーバがＵＴＲＡＮからＥーＵＴＲＡＮへのハンドオーバであることを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
6. ＵＳＩＭタイプのＵＩＣＣによって生成される、ＵＲＴＡアクセス用に規定されるセキュリティ鍵は、１２８ビットの暗号鍵（ＣＫ）と１２８ビットの完全性保護鍵（ＩＫ）であり、ＳＩＭタイプのＵＩＣＣによって生成される暗号鍵（Ｋｃ）が以下の変換関数
   CK = Kc || Kc （式ｃ４）
   IK = Kc1 xor Kc2 || Kc || Kc1 xor Kc2 （式ｃ５）
   に従って、前記ＵＲＴＡアクセス用に規定されるセキュリティ鍵に変換可能であることを特徴とする請求項５記載の方法。
7. ＥーＵＴＲＡ互換のＵＥがどのタイプのＵＩＣＣ備えるかを判別する前記ステップが、
   前記ＳＧＳＮから受信した前記ＣＫが２つの同一な６４ビットのＫｃから構成されるかどうかを前記式ｃ４に従ってチェックするステップと、
   前記ＳＧＳＮから受信した前記ＣＫが２つの同一な６４ビットのＫｃから構成されていない場合、前記ＵＥがＵＳＩＭタイプのＵＩＣＣを備えていると判別するステップと、
   前記ＳＧＳＮから受信した前記ＣＫが２つの同一な６４ビットのＫｃから構成されている場合に、テスト値を前記式ｃ５に従って算出し（Kc= Kc1 || Kc2は前記２つの同一な６４ビットＫｃの１つであり、Ｋｃ１およびＫｃ２はいずれも３２ビット長である）、前記テスト値が前記ＳＧＳＮから受信したＩＫに等しい場合には前記ＵＥがＳＩＭタイプのＵＩＣＣを備えていると判別し、前記テスト値が前記ＳＧＳＮから受信したＩＫに等しくない場合には前記ＵＥがＵＳＩＭタイプのＵＩＣＣを備えていると判別するステップと、
   を有することを特徴とする請求項６記載の方法。
8. 無線ネットワーク制御装置（ＲＮＣ）を有する在圏ネットワーク内で動作するＥーＵＴＲＡ互換のユーザ機器（ＵＥ）の、ＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを制御可能な前記ＲＮＣ内の装置(300)であって、
   在圏ＧＰＲＳサポートノード（ＳＧＳＮ）から、前記ＵＥが前記在圏ネットワークにアタッチした際に認証および鍵配送方式（ＡＫＡ）で生成されたセキュリティ鍵を受信するように構成された、前記ＳＧＳＮと通信するためのインタフェース(301)と、
   処理手段(303)とを有し、
   前記処理手段が、
   前記ＳＲＮＣに既知の鍵変換関数の特性を用いて、前記ＳＧＳＮから受信した前記セキュリティ鍵を解析し、前記ＵＥがどのタイプのＵＩＣＣを備えるかを判別し、
   前記ＵＥのＥーＵＴＲＡＮへのハンドオーバを許可するか否かの決定の根拠として、前記ＵＥがどのタイプのＵＩＣＣを備えるかの知見を用いる、ことが可能であることを特徴とする装置(300)。
9. 前記処理手段(303)が、前記ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有する場合か、前記ＵＥで進行中のサービスのタイプに関する少なくとも１つの条件が満たされる場合に、前記ＵＥのＥーＵＴＲＡＮへのハンドオーバの開始を許可するように構成されることを特徴とする請求項８記載の装置(300)。
10. 前記処理手段(303)が、
    前記ＵＥがＥーＵＴＲＡＮに有効なＵＩＣＣを有する
    前記ＵＥで緊急呼が進行中である
    という条件の少なくとも１つが満たされた場合に、前記ＵＥのＥーＵＴＲＡＮへのハンドオーバの開始を許可し、
    前記条件がいずれも満たされない場合には、前記ＵＥのＥーＵＴＲＡＮへのＲＡＴ間ハンドオーバを許可しない、
    ように構成されることを特徴とする請求項８または請求項９記載の装置(300)。
11. 前記処理手段(303)が、前記ＳＧＳＮから受信した前記セキュリティ鍵を前記ＳＲＮＣに既知の変換関数を適用することによって解析するように構成され、前記変換関数は前記在圏ネットワークにアクセスするための有効なセキュリティ鍵を無効なセキュリティ鍵から得るように規定されていることを特徴とする請求項８乃至請求項１０のいずれか１項に記載の装置(300)。
12. ＵＴＲＡＮからＥーＵＴＲＡＮへの前記ＲＡＴ間ハンドオーバを制御可能であることを特徴とする請求項８乃至請求項１１のいずれか１項に記載の装置(300)。
13. ＵＳＩＭタイプのＵＩＣＣによって生成される、ＵＲＴＡアクセス用に規定されるセキュリティ鍵は、１２８ビットの暗号鍵（ＣＫ）と１２８ビットの完全性保護鍵（ＩＫ）であり、ＳＩＭタイプのＵＩＣＣによって生成される暗号鍵（Ｋｃ）が以下の変換関数
    CK = Kc || Kc （式ｃ４）
    IK = Kc1 xor Kc2 || Kc || Kc1 xor Kc2 （式ｃ５）
    に従って、前記ＵＲＴＡアクセス用に規定されるセキュリティ鍵に変換可能であることを特徴とする請求項１２記載の装置(300)。
14. ＥーＵＴＲＡ互換のＵＥがどのタイプのＵＩＣＣ備えるかを判別可能な前記処理手段(303)が、
    前記ＳＧＳＮから受信した前記ＣＫが２つの同一な６４ビットのＫｃから構成されるかどうかを前記式ｃ４に従ってチェックし、
    前記ＳＧＳＮから受信した前記ＣＫが２つの同一な６４ビットのＫｃから構成されていない場合、前記ＵＥがＵＳＩＭタイプのＵＩＣＣを備えていると判別し、
    前記ＳＧＳＮから受信した前記ＣＫが２つの同一な６４ビットのＫｃから構成されている場合に、テスト値を前記式ｃ５に従って算出し（Kc= Kc1 || Kc2は前記２つの同一な６４ビットＫｃの１つであり、Ｋｃ１およびＫｃ２はいずれも３２ビット長であり）、前記テスト値が前記ＳＧＳＮから受信したＩＫに等しい場合には前記ＵＥがＳＩＭタイプのＵＩＣＣを備えていると判別し、前記テスト値が前記ＳＧＳＮから受信したＩＫに等しくない場合には前記ＵＥがＵＳＩＭタイプのＵＩＣＣを備えていると判別する、
    ように構成されることを特徴とする請求項１３記載の装置(300)。

Images