特許 5771603 メディア独立ハンドオーバプロトコルセキュリティ

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

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

(11)【特許番号】5771603

(24)【登録日】2015年7月3日

(45)【発行日】2015年9月2日

(54)【発明の名称】メディア独立ハンドオーバプロトコルセキュリティ

(51)【国際特許分類】

   H04W 36/14 20090101AFI20150813BHJP

   H04W 12/06 20090101ALI20150813BHJP

   H04W 12/08 20090101ALI20150813BHJP

【ＦＩ】

   H04W36/14

   H04W12/06

   H04W12/08

【請求項の数】30

【全頁数】58

(21)【出願番号】特願2012-509876(P2012-509876)

(86)(22)【出願日】2010年5月3日

(65)【公表番号】特表2012-526454(P2012-526454A)

(43)【公表日】2012年10月25日

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

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

(87)【国際公開日】20101111

【審査請求日】2013年4月30日

(31)【優先権主張番号】61/221,551

(32)【優先日】2009年6月29日

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

(31)【優先権主張番号】61/175,016

(32)【優先日】2009年5月3日

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

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(73)【特許権者】

【識別番号】504473670

【氏名又は名称】テルコーディア・テクノロジーズ・インコーポレーテッド

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100091351

【弁理士】

【氏名又は名称】河野 哲

(74)【代理人】

【識別番号】100088683

【弁理士】

【氏名又は名称】中村 誠

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100095441

【弁理士】

【氏名又は名称】白根 俊郎

(74)【代理人】

【識別番号】100084618

【弁理士】

【氏名又は名称】村松 貞男

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(72)【発明者】

【氏名】ダス、スビア

(72)【発明者】

【氏名】大場 義洋

(72)【発明者】

【氏名】ドゥッタ、アシュトシュ

【審査官】 田部井 和彦

(56)【参考文献】

【文献】 米国特許出願公開第２００９／００６７６２３（ＵＳ，Ａ１）

【文献】 国際公開第２００８／１３９７０７（ＷＯ，Ａ１）

【文献】 特開２００８−０９９２４５（ＪＰ，Ａ）

【文献】 特開２００６−１７４１５２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００３／００２８８０５（ＵＳ，Ａ１）

【文献】 国際公開第２００９／０５１４００（ＷＯ，Ａ２）

【文献】 国際公開第２００８／１５３１６４（ＷＯ，Ａ２）

【文献】 特表２００８−５１７５１６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００７／０１０１４０６（ＵＳ，Ａ１）

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

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

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

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

【請求項1】

複数のメディア独立ハンドオーバサービスにセキュリティを提供するプロトコルを実装したコンピュータを有する装置であって、
複数の候補アクセスネットワークへの複数のサービングアクセスネットワークにアタッチされる複数のハンドオーバモバイル装置に前記複数のメディア独立ハンドオーバサービスを提供する独立したオーセンティケータを含むサービスポイントと、
認証サーバを介して前記複数のメディア独立ハンドオーバサービスを提供する前記サービスポイントで、アクセス認証を介してアクセス制御を行うアクセスコントローラと、を具備し、
前記独立したオーセンティケータは、前記複数の候補アクセスネットワークへの前記複数のサービングアクセスネットワークにアタッチされる複数のモバイル装置のハンドオーバに先立って前記複数の候補アクセスネットワークを認証し、前記複数のサービングアクセスネットワークと前記複数の候補アクセスネットワークは、異なるアクセス技術をサポートするために、それぞれ複数の異種メディアを有している複数の異種アクセスネットワークに属し、この技術では複数の異種メディアのそれぞれが特定のサービングメディアを有していて、
前記アクセス認証が前記サービスポイントと前記認証サーバとの間で確立される場合、前記モバイル装置が、前記複数のメディア独立ハンドオーバサービスに、前記複数のサービングアクセスネットワークと前記候補アクセスネットワークによってサポートされる異種メディア間でアタッチされる前記複数のモバイル装置に関する前記サービスポイントを介してアクセスする権限を与えられる装置。

【請求項2】

前記アクセス認証は、
前記複数のモバイル装置と前記認証サーバとの間で複数のキーを確立するキー確立プロトコルを含み、
少なくとも１つのキーは、前記サービスポイントと前記複数のモバイル装置との間で送信される複数のメディア独立ハンドオーバメッセージを保護するためにセッションキーを導き出す前記サービスポイントへ配送される請求項１の装置。

【請求項3】

メディア独立ハンドオーバプロトコル上で、前記サービスポイントと前記複数のモバイル装置との間でトランスポートレイヤセキュリティ（ＴＬＳ、transport layer security）ハンドシェイクを行うために使用される、前記アクセス認証および前記キー確立プロトコルのためのトランスポートレイヤセキュリティを具備し、
前記ＴＬＳハンドシェイクは、前記メディア独立ハンドオーバプロトコルの複数のメッセージを保護するために、前記複数のモバイル装置および前記サービスポイントを含む複数のピア間でのセキュリティアソシエーションまたはセキュアセッションを確立する請求項２の装置。

【請求項4】

前記セキュリティアソシエーションまたはセキュアセッションは、前記メディア独立ハンドオーバプロトコル内での複数のピア（モバイル装置およびサービスポイント）に結びつけられ、トランスポートレベルセキュリティが付加される場合には前記複数のメディア独立ハンドオーバメッセージはカプセル化されない請求項３の装置。

【請求項5】

前記複数のメディア独立ハンドオーバサービスは、前記複数のモバイル装置および、同じ前記認証サーバを有する複数の候補アクセスネットワークおよび前記複数のサービングアクセスネットワークを認証する請求項１の装置。

【請求項6】

メディア独立ハンドオーバキーイング材料は、ネットワークアクセスに関するプロアクティブ認証の間に確立されるキーイング材料からブートストラップされ、前記プロアクティブ認証は、前記複数のサ−ビングアクセスネットワークから前記複数の候補アクセスネットワークへの前記複数のモバイル装置のハンドオーバに関する前記ネットワークアクセスに先立って、前記複数の候補アクセスネットワークを認証することを具備する請求項５の装置。

【請求項7】

前記複数のメディア独立ハンドオーバサービスは、前記複数のモバイル装置および、異なる複数の認証サーバを有する複数の候補アクセスネットワークおよび前記複数のサービングアクセスネットワークを認証する請求項１の装置。

【請求項8】

メディア独立ハンドオーバキーイング材料は、前記複数のメディア独立ハンドオーバサービスに関するプロアクティブ認証の間に確立されるキーイング材料からブートストラップされ、前記プロアクティブ認証は、前記複数のサ−ビングアクセスネットワークから前記複数の候補アクセスネットワークへの前記複数のモバイル装置のハンドオーバに先立って、前記複数の候補アクセスネットワークを認証することを具備する請求項７の装置。

【請求項9】

前記認証サーバは拡張認証プロトコル（ＥＡＰ）サーバである請求項１の装置。

【請求項10】

前記認証サーバは認証、承認およびアカウンティング（ＡＡＡ）サーバである請求項１の装置。

【請求項11】

前記独立したオーセンティケータは、前記複数の異種のアクセスネットワークのぞれぞれの間で双方向通信を管理するための単一のサービスポイントである請求項１の装置。

【請求項12】

複数のメディア独立ハンドオーバサービスにセキュリティを提供するプロトコルを実装したコンピュータを有する装置であって、
複数の候補アクセスネットワークへの、複数のサービングアクセスネットワークにアタッチされる複数のハンドオーバモバイル装置に前記複数のメディア独立ハンドオーバサービスを提供する独立したオーセンティケータを含むサービスポイントを具備し、
前記独立したオーセンティケータは、複数の候補アクセスネットワークへの、前記複数のサービングアクセスネットワークにアタッチされる複数のモバイル装置のハンドオーバに先立って前記複数の候補アクセスネットワークを認証し、前記複数のサービングアクセスネットワークと前記複数の候補アクセスネットワークは、異なるアクセス技術をサポートするために、それぞれ複数の異種メディアを有している複数の異種アクセスネットワークに属し、この技術では複数の異種メディアのそれぞれが特定のサービングメディアを有していて、
前記サービスポイントおよび前記複数のモバイル装置は、相互認証およびキー確立を行う装置。

【請求項13】

前記複数のモバイル装置および前記サービスポイントは、前記複数のモバイル装置の同一性を、ネットワークに属している前記サービスポイントに確実に提供する（または逆の場合も同様）ために、複数の特定のキーの前記キー確立および前記相互認証を行い、
前記複数の特定のキーは、複数のメディア独立ハンドオーバメッセージを保護するために、１対の同一性を結びつける請求項１２の装置。

【請求項14】

メディア独立ハンドオーバプロトコル上で、前記サービスポイントと前記複数のモバイル装置との間でトランスポートレイヤセキュリティ（ＴＬＳ、transport layer security）ハンドシェイクを行うために使用される、前記相互認証および前記キー確立のためのトランスポートレイヤセキュリティを具備し、
前記ＴＬＳハンドシェイクは、前記メディア独立ハンドオーバプロトコルの複数のメッセージを保護するために、複数のピアモバイル装置間でのセキュリティアソシエーションまたはセキュアセッションを確立する請求項１３の装置。

【請求項15】

前記セキュリティアソシエーションまたはセキュアセッションは、前記メディア独立ハンドオーバプロトコル内での複数のピア（モバイル装置およびサービスポイント）に結びつけられ、トランスポートレベルセキュリティが付加される場合には前記複数のメディア独立ハンドオーバメッセージはカプセル化されない請求項１４の装置。

【請求項16】

前記相互認証は、予め共有されるキーまたは信頼される第三者機関に基づく請求項１３の装置。

【請求項17】

前記信頼される第三者機関は証明機関である請求項１６の装置。

【請求項18】

複数のメディア独立ハンドオーバサービスにセキュリティを提供するシステムであって、
複数のメディア独立アクセス機能を有するサービスポイントと、
それぞれ複数のメディア特定アクセス機能を有する複数の異種ネットワークと、
異なるアクセス技術をサポートするために、それぞれ複数の異種メディアを有している複数の異種アクセスネットワークに属する、複数のサービングアクセスネットワークと複数の候補アクセスネットワークと、
前記複数の異種ネットワークに接続される複数のモバイル装置と、
認証サーバと、
前記複数のメディア独立ハンドオーバサービスを前記認証サーバを介して提供する前記サービスポイントで、アクセス認証を介してアクセス制御を行うアクセスコントローラと、を具備し、
前記サービスポイントは、複数の候補アクセスネットワークへの、複数のサービングアクセスネットワークにアタッチされる複数のモバイル装置のハンドオーバに先立って前記複数の候補アクセスネットワークを認証し、
前記サービスポイントと前記認証サーバとの間で前記アクセス認証が確立される場合に、前記複数のモバイル装置は、前記複数のサービングアクセスネットワークと前記候補アクセスネットワークによってサポートされる異種メディア間でアタッチされた前記複数のモバイル装置に関する前記サービスポイントを介して、前記複数のメディア独立ハンドオーバサービスにアクセスする権限を与えられるシステム。

【請求項19】

前記アクセス認証は、
複数のモバイル装置と前記認証サーバとの間で複数のキーを確立するキー確立プロトコルを含み、
少なくとも１つのキーは、前記サービスポイントと前記複数のモバイル装置との間で送信される複数のメディア独立ハンドオーバメッセージを保護するためにセッションキーを導き出す前記サービスポイントへ配送される請求項１８のシステム。

【請求項20】

メディア独立ハンドオーバプロトコル上で、前記サービスポイントと前記複数のモバイル装置との間でトランスポートレイヤセキュリティ（ＴＬＳ、transport layer security）ハンドシェイクを行うために使用される、前記アクセス認証および前記キー確立プロトコルのためのトランスポートレイヤセキュリティを具備し、
前記ＴＬＳハンドシェイクは、前記メディア独立ハンドオーバプロトコルの複数のメッセージを保護するために、複数のピア（モバイル装置およびサービスポイント）間でのセキュリティアソシエーションまたはセキュアセッションを確立する請求項１９のシステム。

【請求項21】

前記セキュリティアソシエーションまたはセキュアセッションは、前記メディア独立ハンドオーバプロトコル内での複数のピアに結びつけられ、トランスポートレベルセキュリティが付加される場合には前記複数のメディア独立ハンドオーバメッセージはカプセル化されない請求項２０のシステム。

【請求項22】

前記複数のメディア独立ハンドオーバサービスは、前記複数のモバイル装置および、同じ前記認証サーバを有する複数の候補アクセスネットワークおよび前記複数のサービングアクセスネットワークを認証する請求項１８のシステム。

【請求項23】

メディア独立ハンドオーバキーイング材料は、ネットワークアクセスに関するプロアクティブ認証の間に確立されるキーイング材料からブートストラップされ、前記プロアクティブ認証は、前記複数のサ−ビングアクセスネットワークから前記複数の候補アクセスネットワークへの前記複数のモバイル装置のハンドオーバに関する前記ネットワークアクセスに先立って、前記複数の候補アクセスネットワークを認証することを具備する請求項２２のシステム。

【請求項24】

前記複数のメディア独立ハンドオーバサービスは、前記複数のモバイル装置および、異なる複数の認証サーバを有する複数の候補アクセスネットワークおよび前記複数のサービングアクセスネットワークを認証する請求項１８のシステム。

【請求項25】

メディア独立ハンドオーバキーイング材料は、前記複数のメディア独立ハンドオーバサービスに関するプロアクティブ認証の間に確立されるキーイング材料からブートストラップされ、前記プロアクティブ認証は、前記複数のサ−ビングアクセスネットワークから前記複数の候補アクセスネットワークへの前記複数のモバイル装置のハンドオーバに先立って、前記複数の候補アクセスネットワークを認証することを具備する請求項２４のシステム。

【請求項26】

複数のメディア独立ハンドオーバサービスにセキュリティを提供するシステムであって、
複数のメディア独立アクセス機能を有するサービスポイントと、
それぞれ複数のメディア特定アクセス機能を有する複数の異種ネットワークと、
異なるアクセス技術をサポートするために、それぞれ複数の異種メディアを有している複数の異種アクセスネットワークに属する、複数のサービングアクセスネットワークおよび複数の候補アクセスネットワークと、
前記複数の異種ネットワークに接続される複数のモバイル装置と、を具備し、前記サービスポイントは、複数の候補アクセスネットワークへ、複数のサービングアクセスネットワークにアタッチされる複数のモバイル装置のハンドオーバに先立って前記複数の候補アクセスネットワークを認証し、
前記サービスポイントおよび前記複数のモバイル装置は相互認証およびキー確立を行うシステム。

【請求項27】

前記複数のモバイル装置および前記サービスポイントは、前記複数のモバイル装置の同一性を、ネットワークに属している前記サービスポイントに確実に提供する（または逆の場合も同様）ために、複数の特定のキーの前記キー確立および前記相互認証を行い、
前記複数の特定のキーは、複数のメディア独立ハンドオーバメッセージを保護するために、１対の同一性を結びつける請求項２６のシステム。

【請求項28】

メディア独立ハンドオーバプロトコル上で、前記サービスポイントと前記複数のモバイル装置との間でトランスポートレイヤセキュリティ（ＴＬＳ、transport layer security）ハンドシェイクを行うために使用される、前記相互認証および前記キー確立のためのトランスポートレイヤセキュリティを具備し、
前記ＴＬＳハンドシェイクは、前記メディア独立ハンドオーバプロトコルの複数のメッセージを保護するために、複数のピア（モバイル装置およびサービスポイント）間でのセキュリティアソシエーションまたはセキュアセッションを確立する請求項２７のシステム。

【請求項29】

前記相互認証は、予め共有されるキーまたは信頼される第三者機関に基づいて、前記信頼される第三者機関は証明機関である請求項２７のシステム。

【請求項30】

複数のメディア独立ハンドオーバサービスにセキュリティを提供するための操作を、プロセッサが実行することが可能なエンコードされた複数の命令を有する、機械がアクセス可能な記録媒体であって、
前記命令は、
独立したオーセンティケータを含む前記複数のメディア独立ハンドオーバサービスを提供すること、前記独立したオーセンティケータは、複数の候補アクセスネットワークへの複数のサービングアクセスネットワークにアタッチされる複数のモバイル装置のハンドオーバに先立って前記複数の候補アクセスネットワークを認証し、複数のサービングアクセスネットワークと複数の候補アクセスネットワークは、異なるアクセス技術をサポートするために、それぞれ複数の異種メディアを有している複数の異種アクセスネットワークに属し、この技術では複数の異種メディアが特定のサービングメディアを有していて、
前記複数のメディア独立ハンドオーバサービスを認証サーバを介して提供するサービスポイントで、アクセス認証を介してアクセス制御を行うこと、
前記複数のモバイル装置が、前記複数のサービングアクセスネットワークと前記候補アクセスネットワークによってサポートされる異種メディア間にアタッチされる前記複数のモバイル装置に関するサービスポイントを介して前記複数のメディア独立ハンドオーバサービスにアクセスする権限が与えられるように、前記サービスポイントと前記認証サーバとの間で前記アクセス認証を確立することを具備する記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

この出願は、０５／０３／２００９にファイルされた米国仮出願Ｎｏ．６１／１７５，０１６、および０６／２９／２００９にファイルされた６１／２２１，５５１の利益を要求し、それらの全開示は参照することによってここに組込まれる。

【0002】

この発明は、異機種ネットワーク間でのセキュリティシグナリングに関し、特にＭＩＨプロトコルレベルでのセキュリティを提供する概念に関する。

【背景技術】

【0003】

ネットワークとインターネットプロトコル（Networks and Internet Protocol）：
最も悪評があるインターネットと共に、多くのタイプのコンピュータネットワークがある。インターネットはコンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万ものユーザに利用可能な、公共のかつ自立するネットワークである。インターネットは、複数のホストを接続するためにＴＣＰ／ＩＰ（つまりTransmission Control Protocol/ Internet Protocol）と呼ばれる１セットの通信プロトコルを用いる。インターネットはインターネットバックボーンとして知られる通信インフラを有している。インターネットバックボーンへのアクセスは、企業と個人へアクセスを転売するインターネットサービスプロバイダ（ＩＳＰ）によって大部分は制御される。

【0004】

ＩＰ（Internet Protocolインターネットプロトコル）に関して、これは、ある装置（例えば電話、ＰＤＡ［Personal Digital Assistant］、コンピュータなど）からネットワーク上の別の装置へデータを送ることができるプロトコルである。例えばＩＰｖ４、ＩＰｖ６などを含み、今日ＩＰの様々なバージョンがある。ネットワーク上のホスト装置にはそれぞれ、それ自身の一意の識別子である少なくとも１つのＩＰアドレスがある。ＩＰはコネクションレスのプロトコルである。通信中のエンドポイント間での接続は連続的ではない。ユーザがデータあるいはメッセージを送るか受信する場合、データあるいはメッセージはパケットとして知られる複数のコンポーネントに分割される。すべてのパケットはデータの独立したユニットとして扱われる。

【0005】

インターネットまたは同様の複数のネットワーク上でのポイント間で送信を標準化するために、ＯＳＩ（Open Systems Interconnection開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワークでの２ポイント間の通信プロセスを、それ自身の機能のセットを加える各レイヤを有する７つの積み重ねられたレイヤに分離する。それぞれの装置は、送信端ポイントでの各レイヤを通る下方の流れおよび受信端ポイントでのレイヤを通る上方の流れがあるように、メッセージを扱う。機能の７つのレイヤを提供するハードウェアおよび（または）プログラミングは、典型的に、装置オペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰおよび（または）他のトランスポートおよびネットワークプロトコル、および他のソフトウェアおよびハードウェアの組合せである。

【0006】

典型的には、メッセージがユーザから渡す、あるいはそのユーザに渡す場合に上部４つのレイヤが用いられ、メッセージが装置（例えばＩＰホスト装置）を通過する場合に下部３つのレイヤが用いられる。ＩＰホストは、サーバ、ルーターあるいはワークステーションのようなＩＰパケットを送受信することができるネットワーク上の任意の装置である。他のあるホスト用に予定された複数のメッセージは、上位レイヤまで渡されず、別のホストへ転送される。ＯＳＩモデルの複数のレイヤは以下に挙げられる。レイヤ７（つまりアプリケーションレイヤ）は、例えば、通信相手が識別される、サービス品質が確認される、ユーザ認証およびプライバシーが考慮される、データシンタックス上の拘束条件が確認されるレイヤである。レイヤ６（つまりプレゼンテーションレイヤ）は、例えば、ある提示フォーマットから別のフォーマットへ、入力および出力するデータを変換するレイヤである。レイヤ５（つまりセッションレイヤ）は、例えば、アプリケーションの間での会話、交換、対話を設定し調整し終了させるなどのレイヤである。レイヤ４（つまりトランスポートレイヤ）は、例えば、末端間制御、エラー検査などを管理するレイヤである。レイヤ３（つまりネットワークレイヤ）は、例えば、ルーティングおよびフォワーディングなどを扱うレイヤである。レイヤ２（つまりデータリンクレイヤ）は、例えば、物理レベルに同期を提供し、ビットスタッフィングを行い、伝送プロトコル知識および管理などを備えるレイヤである。電気電子技術者協会（ＩＥＥＥ）は、データリンクレイヤを細分して２つのさらなるサブレイヤ、データが物理レイヤに転送しおよび物理レイヤから転送するように制御するＭＡＣ（Media Access Control）レイヤ、ネットワークレイヤと整合させ、コマンドまたはプリミティブを解釈し、エラー回復を行うＬＬＣ（Logical Link Control）レイヤまたはＣＳ（convergence）サブレイヤにする。レイヤ１（つまり物理レイヤ）は、例えば、物理レベルでネットワークを通ってビットストリームを伝えるレイヤである。ＩＥＥＥは、物理レイヤを、ＰＬＣＰ（Physical Layer Convergence Procedure）サブレイヤおよびＰＭＤ（Physical Medium Dependent）サブレイヤへ細分する。

【0007】

ワイヤレスネットワーク（Wireless Networks）：
ワイヤレスネットワークは、セルラおよびワイヤレスの電話、ＰＣｓ（personal computers）、ラップトップコンピュータ、ウエアラブルコンピュータ、コードレス電話機、ページャー、ヘッドセット、プリンタ、ＰＤＡなどのモバイル装置の様々なタイプを組込むことができる。例えば、モバイル装置は、ボイスおよび（または）データの速い無線送信を安全にするために、デジタルシステムを含んでいてもよい。典型的なモバイル装置は、次のコンポーネントのうちのいくつかあるいはすべてを含んでいる：トランシーバ（つまり、送信機および受信機、例えば統合された送信機、受信機、および望むなら他の機能を有する単一チップトランシーバを含んでいる）；アンテナ；プロセッサ；１以上のオーディオトランスデューサ（例えば、オーディオ通信用の装置でのようなマイクロフォンまたはスピーカ）；電磁気データ記憶装置（例えば、データ処理が提供される装置中でのようなＲＯＭ、ＲＡＭ、デジタルデータ記憶装置などのような）；メモリ；フラッシュメモリ；フルチップセットか集積回路；インターフェース（例えばＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなどのような）；または同様なもの。

【0008】

モバイルユーザがワイヤレス接続によってローカルエリアネットワーク（ＬＡＮ）に接続することができる無線ＬＡＮ（ＷＬＡＮｓ）は、無線通信のために使用されてもよい。無線通信は、例えば光、赤外線、無線、マイクロ波のような電磁波を介して伝播する通信を含むことができる。例えばブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦのような、現在存在する様々なＷＬＡＮ規格がある。

【0009】

一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話、携帯型でハンドヘルドな装置、携帯情報端末（ＰＤＡｓ）、他のモバイル装置間でのリンクおよびインターネットへの接続性を提供するために使用されてもよい。ブルートゥースは、モバイル装置が容易に相互に接続されかつ非モバイル装置と接続されることが可能であるコンピュータおよび電気通信産業の仕様である。ブルートゥースは、ある装置から他の装置へデータが同期し矛盾しないままにしておく必要がある様々なモバイル装置の蔓延から引き起こるエンドユーザ問題を扱うためにディジタル無線プロトコルを生成し、その結果、異なるベンダーからの装置がシームレスに一緒に作動することを可能にする。ブルートゥース装置は共通の指定する概念によって指定されてもよい。例えば、ブルートゥース装置は、固有のブルートゥース装置アドレス（Bluetooth （登録商標）Device Address、ＢＤＡ）に関連した名称あるいはＢｌｕｅｔｏｏｔｈ Ｄｅｖｉｃｅ Ｎａｍｅ（ブルートゥース装置名、ＢＤＮ）を所有してもよい。ブルートゥース装置は、さらにインターネットプロトコル（ＩＰ）ネットワークに参加してもよい。ブルートゥース装置がＩＰネットワーク上で機能する場合、それにはＩＰアドレスおよびＩＰ（ネットワーク）名が提供されてもよい。したがって、ＩＰネットワーク上で参加するように構成されたブルートゥース装置は、例えばＢＤＮ、ＢＤＡ、ＩＰアドレス、ＩＰ名を含んでいてもよい。項目「ＩＰ名」はインターフェースのＩＰアドレスに対応する名を指す。

【0010】

ＩＥＥＥ規格、ＩＥＥＥ８０２．１１は、無線ＬＡＮと装置のための技術を指定する。８０２．１１を用いて、ワイヤレスネットワーキングは、いくつかの装置をサポートする各単一のアクセスポイント（基地局と等価）で遂行されてもよい。いくつかの例において、装置はあらかじめ無線ハードウェアを標準装備していてもよく、またはユーザが、アンテナを含んでもよい、カードのようなハードウェアの分離したピースを取り付けてもよい。一例として、８０２．１１で使用される装置は、装置がアクセスポイント（ＡＰ）、移動局（ＳＴＡ）、ブリッジ、ＰＣＭＣＩＡカードあるいは別の装置であるか否かにかかわらず、典型的に３つの顕著な要素を含む：無線トランシーバ；アンテナ；ネットワーク中のポイント間のパケットフローを制御するＭＡＣ（Media Access Control、媒体アクセス制御）レイヤ。

【0011】

さらに、多重インターフェース装置（ＭＩＤｓ、Multiple Interface Devices）はいくつかのワイヤレスネットワークで利用されてもよい。ＭＩＤは、ブルートゥースインターフェースおよび８０２．１１インターフェースのような２つの独立したネットワークインターフェースを含んでいてもよく、この結果ブルートゥース装置と連動することと同様に、２つの分離したネットワークにＭＩＤが参加することを可能にする。ＭＩＤは、ＩＰアドレスおよびＩＰアドレスに関連した共通のＩＰ（ネットワーク）名を持っていてもよい。

【0012】

ワイヤレスネットワーク装置は、ブルートゥース装置に限定されず、多重インターフェース装置（MIDs、Multiple Interface Devices）、８０２．１１ｘ装置（例えば８０２．１１ａ、８０２．１１ｂおよび８０２．１１ｇ装置を含むＩＥＥＥ８０２．１１装置、Ｗｉ−Ｆｉ（Wireless Fidelity）装置として一般に知られている）、ＨｏｍｅＲＦ（ホーム無線周波数）装置、汎用パケット無線システム（ＧＰＲＳ、General Packet Radio Service）装置を含んでいるＧＳＭ（登録商標）（Global System for Mobile Communications、移動通信用の広域のシステム）装置、３Ｇセルラ装置、２．５Ｇセルラ装置、ＥＤＧＥ（Enhanced Data for GSM Evolution、ＧＳＭ発展用の向上させられたデータ）装置、およびＴＤＭＡ型（Time Division Multiple Access、時分割多元接続方式）装置またはＣＤＭＡ２０００を含むＣＤＭＡ型（Code Division Multiple Access、符号分割多重アクセス方式）装置）を含んでいてもよい。ネットワーク装置はそれぞれ、ＩＰアドレスに限定されることなく、ブルートゥース装置アドレス（Bluetooth Device Address）、ブルートゥース一般名（Bluetooth Common Name）、ブルートゥースＩＰアドレス（Bluetooth IP address）、ブルートゥースＩＰ一般名（Bluetooth IP Common Name）、基地局識別子（base station identifier、ＢＳＩＤ）、８０２．１のＩＰアドレス、８０２．１のＩＰ一般名（例えばＳＳＩＤ（Service Set Identifier、サービスセット識別子））あるいはＩＥＥＥ ＭＡＣアドレスを含む様々な型のアドレスを含んでもよい。

【0013】

ワイヤレスネットワークは、例えばモバイルＩＰ（インターネットプロトコル）システムで、ＰＣＳシステムで、そして他の移動通信ネットワークシステムで見つかった方法とプロトコルをさらに含むことができる。モバイルＩＰに関して、これは、インターネット技術標準化委員会（Internet Engineering Task Force、ＩＥＴＦ）によって作成された標準の通信プロトコルを含んでいる。モバイルＩＰに関して、モバイル装置ユーザは、以前割り当てられた彼らのＩＰアドレスを維持しつつ、ネットワークを移動することができる。コメント（ＲＦＣ、Request for Comments）３３４４に関するリクエストを参照してください。注意：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ、Internet Engineering Task Force）の公式な文書である。モバイルＩＰは、インターネットプロトコル（ＩＰ、Internet Protocol）を向上させて、それらのホームネットワークの外部で接続する場合にモバイル装置へインターネットトラフィックを転送する手段を加える。モバイルＩＰは、各モバイルノードをそのホームネットワーク上のホームアドレス、およびネットワークとそのサブネット内の装置の現在のロケーションを識別するケアアドレス（care-of-address、ＣｏＡ）を割り当てる。装置が異なるネットワークに移動される場合、それは新しいケアアドレスを受信する。ホームネットワーク上のモビリティエージェントは、各ホームアドレスをそのケアアドレスに関連させることができる。モバイルノードは、それが例えばインターネットコントロールメッセージプロトコル（Internet Control Message Protocol、ＩＣＭＰ）を使用してそのケアアドレスを変更するごとに、ホームエージェントに拘束力のある最新版を送ることができる。

【0014】

基礎的なＩＰルーティング（例えばモバイルのＩＰの外側で）では、ルーティング機構は、ネットワークノードがそれぞれ、例えばインターネットへの一定のアタッチメントポイントを常に持っている仮定、かつそれがアタッチされるネットワークリンクをそれぞれのノードのＩＰアドレスが識別する仮定に依存する。この文書では、用語「ノード」は接続ポイントを含み、それは例えばデータ伝送のためのエンドポイントまたは再分配ポイントを含んでいて、さらにそれは、他のノードへの通信を認識する、処理する、および（または）転送することができる。例えば、インターネットルータは、例えばＩＰアドレスプレフィックまたは装置のネットワークを識別する同様なものを調べることができる。その後、ネットワークレベルでは、ルーターは、例えば特別なサブネットを識別する１組のビットを調べることができる。その後、サブネットレベルでは、ルーターは例えば特別な装置を識別する１組のビットを調べることができる。典型的なモバイルＩＰ通信では、ユーザがモバイル装置を例えばインターネットから分離して、新しいサブネットでそれを再接続しようとするならば、装置は新しいＩＰアドレス、適正なネットマスクおよびデフォルトルーターで再構成されなければならない。そうでなければ、ルーティングプロトコルはパケットを適切に運ぶことができないだろう。

【0015】

複数のメディア独立ハンドオーバサービス（Media Independent Handover Services）：
ローカルおよびメトロポリタンエリアネットワークのためのドラフト（Draft IEEE Standard for Local and Metropolitan Area Networks）：複数のメディア独立ハンドオーバサービス（Media Independent Handover Services）と題された２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９では、他のものの中で、文書は、８０２システムとセルラシステムとの間でのハンドオーバを最適化する８０２メディアアクセス独立機構を特定する。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は、異種の８０２システム間のハンドオーバの最適化を可能にし、８０２システムとセルラシステムの間のハンドオーバを促進する拡張可能なメディアアクセス独立機構を定義する。

【0016】

ＩＥＥＥ８０２．２１（Media Independent Handover、メディア独立ハンドオーバ）規格のスコープは、異種のメディア間のハンドオーバを最適化するために、上位レイヤへの他の関連するネットワーク情報およびリンクレイヤ情報を提供する仕様を開発することである。これは、３ＧＰＰ、３ＧＰＰ２、および規格のＩＥＥＥ８０２ファミリーでの有線および無線メディアによって指定されたリンクを含んでいる。この文書中で、他に記載していなければ、「メディア」は、通信の感覚的態様（例えば音声、映像など）とは対照的に、遠隔通信システム（例えばケーブル、無線、衛星など）にアクセスする方法／モードを示すことに注意する。ローカルおよびメトロポリタンエリアネットワークのためのドラフト（Draft IEEE Standard for Local and Metropolitan Area Networks）：複数のメディア独立ハンドオーバサービス（Media Independent Handover Services）と題された、２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９のうちの１．１を参照せよ。この文書の全内容は、ここに組み込まれ、この特許出願の一部として組み込まれる。さらに、優先権がここに請求される仮出願もまた、２００９年１月２１日に公表されたＩ．Ｅ．Ｅ．Ｅ．規格８０２．２１および前記規格のドラフト０５（ここではＤ０５と称す）を組み込む。ドラフトの全内容は再びここに参照によって組み込まれる。すなわち、例えばＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ０５．００、２００７年４月、ローカルおよびメトロポリタンエリアネットワークのための規格案（Draft Standard for Local and Metropolitan Area Networks）：複数のメディア独立ハンドオーバサービス（Media Independent Handover Services）。これは、Ｉ．Ｅ．Ｅ．Ｅ．コンピュータ協会およびローカルおよびメトロポリタンエリアネットワークに関するＩ．Ｅ．Ｅ．Ｅ．規格のＬＡＮ ＭＡＮ規格委員会から後援を受けている。２００９年１月２１日に公表された、パート２１：メディア独立ハンドオーバサービス。これは、Ｉ．Ｅ．Ｅ．Ｅ．コンピュータ協会のＬＡＮ ＭＡＮ規格委員会から後援を受けている。

【0017】

一般的なアーキテクチャ（General Architecture）：
イントロダクション（Introduction）：
ＩＥＥＥ８０２．２１規格は、様々なハンドオーバ方法を促進するように意図される。そのような方法は、モバイルノードとネットワークとの間のデータパケットの交換をサポートするデータ伝送設備に関してハンドオーバ手続が「作る前に壊す」または「壊す前に作る」のかに依存して、一般的に「ハード」または「ソフト」として分類される。

【0018】

一般に、ハンドオーバは、ネットワークオペレータとエンドユーザとのニーズを満たすために、モバイルノードとネットワークインフラストラクチャーの両方の協同の使用を含んでいる。ハンドオーバ意志決定に関与するハンドオーバ制御、ハンドオーバポリシおよび他のアルゴリズムは、ＩＥＥＥ８０２．２１規格の範囲以内にない通信システム要素によって一般に扱われる。しかしながら、全面的なハンドオーバプロセスでのＭＩＨイベントサービス、ＭＩＨコマンドサービス、ＭＩＨ情報サービス、およびＭＩＨＦの役割および目的が明らかなように、ハンドオーバ手続きの全体のある態様について記述することは有益である。

【0019】

一般的な設計原理（General Design Principles）：
ＩＥＥＥ８０２．２１規格は以下の一般的な設計原理に基づく。

【0020】

ａ）ＭＩＨ機能はハンドオーバ意志決定を支援し促進する論理エンティティである。上位レイヤは、ＭＩＨＦからの入力およびコンテキストに基づいて、ハンドオーバ判定およびリンクセレクションを行う。ハンドオーバが起こるべきであるという認識を促進することはＭＩＨＦの重要な目的のうちの１つである。有効なハンドオーバ判定を下す方法についての情報の発見もまた重要な要素である。

【0021】

ｂ）ＭＩＨＦは高次レイヤに抽出したサービスを提供する。これから、見込みのＭＩＨＦは、上位レイヤまで一体になったインターフェースを提示する。この一体になったインターフェースによって明らかにされるサービスプリミティブは、異なるアクセスネットワークの技術の特定のプロトコルエンティティに基づく。ＭＩＨＦは、特定の技術インターフェースを介してモビリティ管理プロトコルスタックの下位レイヤと通信する。

【0022】

下位レイヤとのＭＩＨＦインターフェースの仕様は、一般にこの規格の範囲以内にない。そのようなインターフェースは、ＩＥＥＥ８０２．１、ＩＥＥＥ８０２．３、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、ＷｉＭＡＸ、３ＧＰＰおよび３ＧＰＰ２のようなそれぞれのアクセス技術に関係する規格内でサービスアクセスポイント（ＳＡＰｓ）として既に指定されているかもしれない。この規格は、下位レイヤインターフェースの変更がＭＩＨＦ機能を可能にするまたは向上させるかもしれない場合、既存のアクセス技術特定規格を修正するための推奨を含んでいてもよい。

【0023】

ｃ）（ハンドオーバ実行および後の更新の一部としての）ハンドオーバシグナリングは規格の一部でなくともよい。異なるアクセスネットワークは、水平のハンドオーバ機構（モバイル主導、ネットワーク主導など）をサポートする。同種のスキームごとでのように行われなかった場合、ハンドオーバ開始トリガーは異種のハンドオーバに役立つかもしれない。

【0024】

ｄ）ＭＩＨＦは、ＭＡＣ／ＰＨＹトリガー上および他の関連するローカルイベント上での処理を行ってもよい。この処理の定義は規格のスコープの外にある。規格は、同様に遠隔のイベントに関するサポートを提供するものとする。イベントは事実上忠告的である。これらのイベントに基づいてハンドオーバを引き起こすかどうかの判定は、規格のスコープの外にある。

【0025】

ｅ）規格は、ＭＮ主導の、ＭＮ制御された、ネットワーク主導の、およびネットワーク制御された、ハンドオーバをサポートするために機構を指定するものとする。

【0026】

ｆ）規格は、レガシー設備を持った明白な相互ワーキングをサポートしてもよい。したがって、ＩＥＥＥ８０２．２１互換性をもつ設備は、レガシーの非ＩＥＥＥ８０２．２１準拠の設備と共存することができる。

【0027】

メディア独立ハンドオーバ参照フレームワーク（Media Independent Handover Reference Framework）：
以下のセクションは、クライアント装置（ＭＮ）およびネットワークでの異なるＭＩＨＦエンティティ間の通信に関する態様について記述する。

【0028】

ＭＩＨＦ機能は様々な目的のために互いに通信する。クライアント装置（モバイルノード）はそのＭＩＨサービスポイントを有するＭＩＨ情報を交換する。任意のネットワークエンティティ中のＭＩＨＦは、それがＭＮに基づいたＭＩＨＦで直接通信する場合、ＭＩＨ ＰｏＳになる。ＭＩＨネットワークエンティティは、ＭＮへの直接接続を持たなくてもよく、したがって特定のＭＮに関するＭＩＨ ＰｏＳを構成しない。同じＭＩＨネットワークエンティティは、異なるＭＮに関するＭＩＨ ＰｏＳとしての役割をまだ果たすかもしれない。ＭＩＨＦ通信は、ＭＩＨ対応のＭＮのすべてのＬ２インターフェース上で起こらないかもしれない。例として、３つのＬ２インターフェース、すなわち８０２．１１、８０２．１６および８０２．３を持ったＭＩＨ対応のＭＮにおいては、８０２．３のインターフェースはシステム管理および保守の運転にのみ用いられてもよく、一方、８０２．１１および８０２．１６のインターフェースはＭＩＨＦサービスの提供に従事していてもよい。ＭＮは、そのネットワークＰｏＡと同じネットワークエンティティに存在するＭＩＨ ＰｏＳでＭＩＨ情報を交換するためのＬ２トランスポートを用いるかもしれない。ＭＮは、そのネットワークＰｏＡと同じネットワークエンティティに存在してはならないＭＩＨ ＰｏＳでＭＩＨ情報を交換するためのＬ３トランスポートを用いるかもしれない。フレームワークは、ＭＩＨネットワークエンティティ中の通信へのＬ３あるいはＬ２の機構のいずれかの使用をサポートする。

【0029】

図３は、８０２．２１の規格からのＭＩＨ通信モデルを示す。モデルは異なる特殊な役割およびそれらの中での通信関係でのＭＩＨＦｓを示す。図３に示される通信関係は、ＭＩＨＦｓにのみに当てはまる。通信モデルでの通信関係の各々が特別のトランスポート機構を意味しないことは注目すべきである。もっと正確に言えば、通信関係は、ＭＩＨＦ関連情報通行が２つの特殊なＭＩＨＦの間で可能なことを単に示すつもりである。さらに、１）ＭＮ上でのＭＩＨＦ、２）ＭＮのサービングＰｏＡを含んでいるネットワークエンティティ上のＭＩＨ ＰｏＳ、３）ＭＮに関する候補ＰｏＡを含んでいるネットワークエンティティ上でのＭＩＨ ＰｏＳ（候補ＰｏＡは、ＭＮが気づいているが現在アタッチされていないＰｏＡであり；ハンドオーバが最終的に生じる場合、それはターゲットＰｏＡになる）、４）ＭＮに関するＰｏＡを含んでいないネットワークエンティティ上でのＭＩＨ ＰｏＳ、５）ＭＮに関するＰｏＡを含んでいないネットワークエンティティ上でのＭＨＩ 非ＰｏＳ。

【0030】

通信モデルはさらに、ＭＩＨＦｓの異なる事例間の以下の複数の通信基準ポイントを識別する。

【0031】

１）通信基準ポイントＲ１（Communication reference point R1）：基準ポイントＲ１は、サービングＰｏＡのネットワークエンティティ上のＭＩＨ ＰｏＳと、ＭＮ上のＭＩＨＦとの間のＭＩＨＦ手続きを示す。Ｒ１は、Ｌ２とＬ３及びそれ以上にかけて通信インターフェースを包含してもよい。Ｒ１上を通過したＭＩＨＦ内容は、ＭＩＩＳ、ＭＩＥＳあるいはＭＩＣＳと関連してもよい。

【0032】

２）通信基準ポイントＲ２（Communication reference point R2）：基準ポイントＲ２は、ＭＮ上のＭＩＨＦと、候補ＰｏＡのネットワークエンティティ上のＭＩＨ ＰｏＳとの間のＭＩＨＦ手続きを示す。Ｒ２は、Ｌ２とＬ３及びそれ以上にかけて通信インターフェースを包含してもよい。Ｒ２上を通過したＭＩＨＦ内容は、ＭＩＩＳ、ＭＩＥＳあるいはＭＩＣＳと関連してもよい。

【0033】

３）通信基準ポイントＲ３（Communication reference point R3）：基準ポイントＲ３は、ＭＮ上のＭＩＨＦと非ＰｏＡネットワークエンティティ上のＭＩＨ ＰｏＳとの間のＭＩＨＦ手続きを示す。Ｒ３は、Ｌ３及びそれ以上、恐らくイーサネット（登録商標）ブリッジＭＰＬＳ等のようなＬ２トランスポートプロトコルにかけて通信インターフェースを包含してもよい。Ｒ３上を通過したＭＩＨＦ内容は、ＭＩＩＳ、ＭＩＥＳあるいはＭＩＣＳと関連してもよい。

【0034】

４）通信基準ポイントＲ４（Communication reference point R4）：基準ポイントＲ４は、ネットワークエンティティでのＭＩＨ ＰｏＳと、別のネットワークエンティティでのＭＩＨ非ＰｏＳ事例との間のＭＩＨＦ手続きを示す。Ｒ４は、Ｌ３及びそれ以上にかけて通信インターフェースを包含してもよい。Ｒ４上を通過したＭＩＨＦ内容は、ＭＩＩＳ、ＭＩＥＳあるいはＭＩＣＳと関連してもよい。

【0035】

５）通信基準ポイントＲ５（Communication reference point R5）：基準ポイントＲ５は、別個のネットワークエンティティでの２つのＭＩＨ ＰｏＳ事例間でのＭＩＨＦ手続きを示す。Ｒ５は、Ｌ３及びそれ以上にかけて通信インターフェースを包含してもよい。Ｒ５上を通過したＭＩＨＦ内容は、ＭＩＩＳ、ＭＩＥＳあるいはＭＩＣＳと関連してもよい。

【0036】

ＭＩＨ通信モデルの実例（Illustration of the MIH Communication Model）：
ＭＩＨサービスを含むネットワークモデルは、ＭＩＨ通信基準ポイントのより大きな実例に関して図４に示される。右から左への移動にしたがって、モデルは、多重の有線及び無線アクセス技術オプションをサポートするＭＩＨ対応のモバイルノード（ＭＮ、一番右寄り）を含んでいる。モデルは、プロビジョニングサービスプロバイダが、相互ワーキングのサポートでのＳＬＡが確立された場合に、そのユーザが他のネットワークを動き回ることを許容するか、それとも多重アクセス技術を操作するか、を仮定する。ＭＮはインプリメントされたＭＩＨＦを有し、それによってそれが特定のＭＩＨクエリーを送信することを可能にする。ＭＮは部分的にインプリメントされた情報サービスを内部に有してもよい。

【0037】

モデルは、コアネットワーク（オペレータ１−３コア）へある程度緩やかに直列に接続されるアクセスネットワークを明らかにしている。よりきつく相互ワーキングされるかまたは結合されるアクセスネットワークもまた描かれている（アクセスネットワーク−３）。オペレータ１−３それぞれは、サービスプロバイダ、企業イントラネットプロバイダ、または訪問されるアクセスまたはホームアクセスのありきたりの部分、または一様なコアネットワークを表す。このモデルでは、プロビジョニングプロバイダは、コア（ラベルが付けられた訪問された／ホームのコアネットワーク）にＲ１によってつながれたアクセスネットワーク−３を操作している。訪問された及びホームという用語は、プロビジョニングサービスプロバイダまたは企業を示すために使用される。説明されたネットワークのうちのどれでも、ＭＮのプロビジョナーへのオペレータの関係に依存する、訪問されたかまたはホームのネットワークである。ネットワークプロバイダは、それらのネットワークへハンドオーバを促進するために、アクセスネットワーク（アクセスネットワーク１から４）でのＭＩＨサービスを提供する。アクセス技術はそれぞれ、そのＭＩＨ能力を宣伝するか、あるいはＭＩＨサービス発見に応答する。アクセスネットワークのためのサービスプロバイダはそれぞれ、１以上のＭＩＨサービスポイント（ＰｏＳ、通信モデル（Communication Model）と比較して）へのアクセスを許可する。これらのＰｏＳは、ＭＩＨ能力発見の間に決定されるように、いくつかまたは全てのＭＩＨサービスを提供してもよい。

【0038】

ＭＩＨ ＰｏＳのロケーションまたはノードは規格によって固定されない。ＰｏＳのロケーションは、オペレータ配備シナリオおよび技術が特殊なＭＩＨアーキテクチャに基づいて、によって変化してもよい。ＭＩＨ ＰｏＳは、アクセスネットワーク（アクセスネットワーク１，２，４が典型）でのアタッチメントポイント（ＰｏＡ）の隣に存在するか、または同じ場所に配置される。その代わりに、ＰｏＳは、アクセスあるいはコアネットワーク（アクセスネットワーク３が典型）の内部により深く存在してもよい。図４に示されるように、ＭＮでのＭＩＨエンティティは、任意のアクセスネットワーク上のＲ１、Ｒ２あるいはＲ３のいずれかによってＭＩＨネットワークエンティティと通信する。サービングアクセスネットワークでのＰｏＡが同じ場所を共用したＭＩＨ機能がある場合、Ｒ１参照接続は、さらにＰｏＳであるＰｏＡで終了する（モデルのアクセスネットワーク１、２、４へのＭＮはすべて、Ｒ１でありえる）。その場合、Ｒ３参照接続は、（さらにアクセスネットワーク１、２、４へのＭＮによって例証された）どんな非ＰｏＡでも終了するだろう。ＭＩＨイベントは活発なＲ１リンクの両側で起こるかもしれない。ＭＮは典型的にこれらのイベントに反応する最初のノードである。

【0039】

訪問されたネットワークとホームネットワークとの相互作用は、制御および管理目的であるか、またはデータ伝送目的であるかである。さらに、ローミングまたはＳＬＡの合意により、ホームネットワークはＭＮが、訪問されたネットワークを通って直接公的なインターネットにアクセスすることを許可してもよい。図示されるように、２つのＭＩＨネットワークエンティティがＲ４またはＲ５の参照接続によって互いに通信してもよい。ＭＩＨ対応のＰｏＡは、さらにＲ３とＲ４の基準ポイントを介して他のＭＩＨネットワークエンティティと通信してもよい。候補ネットワークに関する情報サービスを得るために、ＭＩＨ対応のＭＮは、Ｒ２基準ポイントを介して候補アクセスネットワークに他のＰｏＡとのＭＩＨ通信を持つことができる。

【0040】

ＭＩＨ情報サービス（ＭＩＩＳ）に関して、プロバイダは、ＭＩＨ ＰｏＳノード（上部一番左寄り）に位置する情報サーバにアクセスを提供する。オペレータは複数のモバイルノードにＭＩＩＳを提供し、その結果、それらは、新しいローミングリストに限定されず、コスト、プロバイダ識別情報、プロバイダサービス、優先順位、およびサービスを選択し利用することができる任意の他の情報を含む関連情報を得ることができる。図示されるように、モバイルノードがそのプロバイダによってＭＩＩＳデータが予め供給されていることが可能である。

【0041】

さらに、モバイルノードがそのプロバイダの任意のアクセスネットワークから複数のＭＩＨ情報サービスを得ることは可能である。さらにＭＩＩＳは、別のオーバーラップしているまたは近くのネットワークから、そのネットワークのＭＩＩＳサービスポイントを使用して、利用可能である。（ここではアクセスネットワーク３と結合しているとして図示されている）プロビジョナーのネットワークは、プロビジョナーのまたは訪問されたネットワークのＭＩＨ情報サーバのような他のＭＩＨエンティティにアクセスするために、Ｒ３およびＲ４のインターフェースを利用してもよい。

【0042】

ＭＩＨコマンドサービス（ＭＩＣＳ、MIH Command Service）に関して、情報データベースのうちのどれでもコマンドサービスＰｏＳとして用いられてもよい。ＭＮ ＭＩＨＦは、レイヤ３トランスポートを用いて、典型的にはこのサーバと通信する。

【0043】

ＭＩＨＦサービス（MIHF Services）：
ＭＩＨＦは、リンクレイヤおよびＭＩＨユーザに関するよく定義されたＳＡＰｓによって非同期および同期のサービスを提供する。任意タイプの多数のネットワークインターフェースを持ったシステムの場合には、上位レイヤが、根本的なインターフェースの状態を管理し、決定し、かつ制御するためにＭＩＨによって提供されるイベントサービス、コマンドサービスおよび情報サービスを用いてもよい。

【0044】

ＭＩＨによって提供されるこれらのサービスは、サービス連続性、サービス品質を変化させることへのサービス順応、バッテリ寿命保存、および、ネットワークの発見及びリンクの選択を維持している複数の上位レイヤを支援する。８０２タイプ、およびセルラの３ＧＰＰ、３ＧＰＰ２タイプの異種ネットワークインターフェースを含んでいるシステムでは、メディア独立ハンドオーバ関数（Media Independent Handover Function）は、異種ネットワークインターフェースに渡るサービスを連結する有効手続きを実行するために、上位レイヤを支援してもよい。複数の上位レイヤは、異種ネットワーク間のハンドオーバ動作に必要とされるリソースを問い合わせるために、異なるエンティティに渡るＭＩＨＦによって提供されるサービスを利用してもよい。

【0045】

モバイル装置中のＭＩＨサービスは、異種ネットワーク間のシームレスなハンドオーバを促進する。モビリティ管理プロトコル（例えばモバイルＩＰ）のようなＭＩＨユーザは、ハンドオーバおよびシームレスのセッション連続性のためにサポートされる。これは、ハンドオーバを最適化するためにＭＩＨサービスを利用することから、モバイルＩＰおよび他の上位レイヤさえも加えて他のプロトコルを排除しない。

【0046】

ＭＩＨサービスを使用するモバイルノードは、イベントサービスのような非同期操作のためのリンクレイヤから指示を受信する。コマンドサービス（Command service）および情報サービス（Information service）との相互作用は、機構の同期質問応答タイプを介している。

【0047】

ＭＩＨＦは、さらに同じメディアタイプのネットワーク及びホストのエンティティの間での情報の交換に関して機能性を提供する。そのような情報交換用機構が、与えられたタイプの（いくつかのセルラのメディアタイプのような）メディアで既に存在する場合は、可能な場合は常に、ＭＩＨＦは既存の機構を利用するだろうことに注意すること。

【0048】

ＭＩＨプロトコル（MIH Protocol）：
ＩＥＥＥ ８０２．２１規格は、メディア独立イベントサービス（Media Independent Event service）、メディア独立コマンドサービス（Media Independent Command service）およびメディア独立情報サービス（Media Independent Information service）をサポートする。ＭＩＨプロトコルは、遠隔の複数のＭＩＨＦエンティティの間で交換されるメッセージ（つまりヘッダーとペイロードを持ったＭＩＨＦパケット）のフォーマットと、メッセージの配達を支援するトランスポート機構とを定義する。トランスポート機構の選択は、ＭＩＨ ＰｏＳのロケーションおよびネットワークにＭＮを接続するアクセス技術に依存する。

【0049】

これらのサービス用のパケットペイロードは、Ｌ２管理フレーム、Ｌ２データフレーム、あるいは他の高次レイヤプロトコルにかけて運ばれてもよい。８０２．１１および８０２．１６のようなワイヤレスネットワークは、上記のペイロードを運ぶために適切に向上する管理プレーンおよび支援管理フレームがある。しかしながら、有線イーサネットネットワークは管理プレーンを持っておらず、データフレーム内でのみ上記のペイロードを運んでもよい。

【0050】

ＩＥＥＥ ８０２．２１規格は、規格ＴＬＶフォーマットでのメディア独立方法でパケットフォーマット及びペイロードを定義する。その後、これらのパケットは、ペイロードがイーサネットの場合でのようなノーマルデータフレームに渡って送信される必要がある場合に、ＭＩＨＦイーサタイプを用いてＬ２ ＭＩＨプロトコルでカプセル化されてもよい。他の場合では、ＴＬＶに基づいたメッセージおよびペイロードは、メディア特定管理フレームに直接カプセル化されてもよい。あるいはまた、ＭＩＨプロトコルメッセージは、下位レイヤ（Ｌ２）または高次レイヤ（Ｌ３及びそれ以上）のトランスポートを使用して、カプセル化されてもよい。

【0051】

ＩＥＥＥ ８０２．２１規格は、ＭＩＨプロトコルデータユニット（ＰＤＵ、Protocol data unit）ヘッダーおよびペイロードのフォーマットを定義する。規格ＴＬＶフォーマットは、ＰＤＵペイロード内容に関してメディア独立表現を提供する。ＭＩＨＦ ＰＤＵｓは８０２のリンクに関するＭＩＨＦイーサタイプを持ったデータフレームにカプセル化される。８０２．１１および８０２．１６のリンクにとっては、メディア特定管理フレームの拡張は、ＭＩＨメッセージを運ぶために推奨される。Ｌ２での３ＧＰＰ及び３ＧＰＰ２のアクセスリンクに渡るＭＩＨメッセージのトランスポートに関するこの規格では仮定はなされない。

【0052】

メディア独立情報サービス（Media Independent Information Service）：
イントロダクション：
メディア独立情報サービス（ＭＩＩＳ）は、モバイルノード及びネットワーク双方でのＭＩＨＦが、ハンドオーバを促進するために、ある地理的区域内のネットワーク情報を発見し取得してもよいフレームワークを提供する。目標は、これらのネットワークにわたってローミングする場合にシームレスなハンドオーバを促進するために、その領域のＭＮに関連するすべての異種ネットワークのグローバルな視野を得ることである。

【0053】

メディア独立情報サービス（Media Independent Information Service）は、様々な情報要素（ＩＥｓ、Information Elements）に関する支援を含んでいる。情報要素（Information Elements）は、ネットワーク選択器がインテリジェントハンドオーバ判定を下すために不可欠である情報を提供する。

【0054】

モビリティのタイプによって、異なるタイプの情報要素に関する支援はハンドオーバを行なうために必要であってもよい。例えば、同じアクセスネットワークの異なるＰｏＡｓにわたる水平のハンドオーバの場合には、アクセスネットワークの下部リンクレイヤからの利用可能な情報は十分であるとしてもよい。そのような場合、ハンドオーバの間に必要とされる他のリンクレイヤ情報及びイントラ技術隣接レポートのような情報要素は、アクセスネットワークから直接利用可能である。そのような場合、ネットワークによって提示された高次レイヤサービスの利用可能性は、異なるネットワークのアタッチメントポイントにわたって、目につくほどに変化しなくてもよい。

【0055】

他方、垂直のハンドオーバ中では、使用中のユーザアプリケーションに関するサービス及びセッション連結性を許可するために、適切な高次レイヤサービスの利用可能性と同様な両方の最適リンクレイヤ連結性に基づいて新しいネットワークでの適切なＰｏＡを選択する必要がある。

【0056】

メディア独立情報サービス（ＭＩＩＳ、Media Independent Information Service）は、ハンドオーバのために必要な情報を得るための能力を提供する。これは、インターネット接続性、ＶＰＮサービスの利用可能性などのような利用可能な高次レイヤサービスに関する情報と同様に、隣接地図および他のリンクレイヤパラメーターのような下位レイヤに関する情報を含んでいる。ＭＩＩＳによって提供される異なる高次レイヤサービスの集合は、絶えず発展してもよい。同時に、ＭＩＩＳに支援されるアクセスネットワークのリストもまた発展してもよい。そのため、ＭＩＩＳが異なる情報要素に支援を提供する点で、柔軟性と拡張性が必要である。このような目的で、ＭＩＩＳはスキーマを定義する。スキーマは、ＭＩＩＳのクライアントが、ＭＩＩＳの能力を発見し、かつさらに特別な実装によって支援されたＩＥｓ及び異なるアクセスネットワークの全集合を発見することを助ける。スキーマ表現は、さらにモバイルノードがより柔軟でより効率的なやり方で情報を尋ねることを可能にする。このスキーマを定義する部分として、ＭＩＩＳはさらにＭＩＩＳの異なる実装のコア機能性を規定してもよい、１セットの基礎的な情報要素を識別してもよい。それらが加えられるように、他の情報要素はＭＩＩＳ能力の拡張集合の一部になってもよい。

【0057】

ＭＩＩＳは、８０２のネットワーク、３ＧＰＰネットワークおよび３ＧＰＰ２ネットワークのような異なるアクセスネットワークに関する情報を提供する。ＭＩＩＳは、さらにこの集合的な情報が任意の単一ネットワークからアクセスされることを可能にする。

【0058】

したがって例えば８０２．１１アクセスネットワークを用いて、特別の領域でのすべての他の８０２のネットワークに関するだけでなく、同様に３ＧＰＰ及び３ＧＰＰ２のネットワークのそれに関する情報を得ることは可能でもよい。同様に３ＧＰＰ２インターフェースを用いて、ある領域での全ての８０２および３ＧＰＰのネットワークに関する情報にアクセスすることは可能でもよい。この能力は、モバイルノードがその現在活発なアクセスネットワークを用いることを可能にし、地理的領域での他の利用可能なアクセスネットワークを調査することを可能にする。したがって、モバイルノードは、そのそれぞれの無線通信の出力を上げる負荷から解放され、異種ネットワーク情報にアクセスする目的でネットワーク接続性を確立することから解放される。ＭＩＩＳによって、均一な方法を提供することによって全ての利用可能なアクセスネットワークにわたっての機能性が、どんな地理的区域でも異種ネットワーク情報を検索することができる。

【0059】

情報サービスエレメント（Information Service Elements）：
情報サービスの背後の主な目標は、モバイルノードとネットワークエンティティが、ハンドオーバの間に適切なネットワークの選択に影響を及ぼすかもしれない情報を発見することを可能にすることである。この情報は、この情報に基づいて有効なハンドオーバ判定を行ってもよいポリシエンジンエンティティによって主として用いられるように意図される。ネットワークコンフィギュレーション変更を説明しなければならないが、この情報サービスがほとんど静的なタイプの情報を提供すると予想される。現在の利用可能リソースレベル、状態パラメーター、動態統計などのような異なるアクセスネットワークに関する他の動的情報は、それぞれのアクセスネットワークから直接得られるべきである。情報サービスの背後の重要なモチベーションのうちのいくつかは以下のとおりである：
１）地理的区域でのアクセスネットワークの利用可能性に関する情報を提供する。さらに、この情報は、任意のワイヤレスネットワークを使用して、検索されるかもしれない。例えば近くのＷｉＦｉホットスポットに関する情報が、リクエスト／応答シグナリングを用いてか、またはこれらのセルラネットワーク上で特別または暗黙にブロードキャストされる情報を用いて、ＧＳＭ、ＣＤＭＡ、または他の任意のセルラネットワークを使用して得られるかもしれない。あるいは、ＭＮによって内部データベースにおいてこの情報を維持することができるかもしれない。

【0060】

２）適切なアクセスネットワークを選択する際にモバイル装置を支援することができる静的なリンクレイヤ情報パラメーターを提供する。例えば、セキュリティとＱｏＳが特別のアクセスネットワーク上で支援されるかどうかについての知識は、ハンドオーバの間にそのようなアクセスネットワークを選択する判定に影響を及ぼしてもよい。

【0061】

３）異なるＰｏＡｓの能力についての情報および隣接報告を備えるリンクレイヤ情報はまた、利用可能な／選択された、アクセスネットワークに接続するために、無線通信を最適に（可能な程度まで）構成することに役立つ。例えば、異なるＰｏＡｓによって支援されたチャネルについて知っていることは、走査、ビーコン等とは対照的にチャネルを最適に構成し、この情報を見つけ出すことに有用であってもよい。しかしながら、大部分については、ダイナミックリンクレイヤパラメーターが、アクセスネットワークとの直接の相互作用に基づいて、得られまたは選択されなければならない。そして情報サービスはその点で役立つことができなくてもよい。

【0062】

４）ハンドオーバ判定を下すのに役立つ可能性のある、異なるアクセスネットワークおよび他の関連情報によって支援された高次レイヤサービスの指示を提供する。そのような情報は、特定のアクセスネットワークのＭＡＣ／ＰＨＹレイヤから直接に利用可能でなくてもよく（または利用可能にしなくてもよい）、情報サービスの一部として提供されてもよい。例えば、ある場合に、公共、企業、ホーム、他のものなどのようなカテゴリーへの異なるネットワークの分類は、ハンドオーバ判定に影響を及ぼすかもしれない。ここに他の情報は、現実によりベンダー／ネットワークに特有であってもよく、その形式に定められていてもよい。

【0063】

情報サービスエレメントは３つのグループに分類される：
１）一般的なアクセスネットワーク情報（General Access Network Information）：これらの情報エレメントは、利用可能なネットワーク及びそれらの関連するオペレータのリスト、異なるオペレータ間でのローミング協定、ネットワークへの接続コスト、ネットワークセキュリティ及びサービス品質の能力、のようなエリア内の受信地域を提供する異なるネットワークの一般的な概略を与える。

【0064】

２）アタッチメントポイントに関する情報（Information about Points of Attachment）：これらの情報エレメントは、利用可能なアクセスネットワークの各々に関する異なるＰｏＡｓについての情報を提供する。これらのＩＥは、リンクレイヤ連結性を最適化するために、ＰｏＡアドレス指定情報、ＰｏＡロケーション、支援されたデータレート、ＰＨＹ及びＭＡＣレイヤのタイプ、および任意のチャネルパラメーターを含んでいる。これはさらに、異なるＰｏＡｓの個々の性能、および高次レイヤサービスを含んでいてもよい。

【0065】

３）他の情報は、ベンダー／ネットワークに特有であってもよく、適切に指定されればよい。

【0066】

メディア独立ハンドオーバプロトコル（Media Independent Handover Protocol）：
イントロダクション：
ＭＩＨＦは、下位レイヤと上位レイヤに関する明瞭なＳＡＰｓを介して、非同期及び同期のサービスを提供する。提供されるサービスは、イベントサービス（ＥＳ、Event Service）、コマンドサービス（ＣＳ、Command Service）および情報サービス（ＩＳ、Information Service）を含んでいる。ＭＩＨサービスについての詳細な記述は、８０２．２１のドラフト文書で見いだせる。ＭＩＨ ＳＡＰｓは、ＭＩＨ上位レイヤＳＡＰを含み（それはＭＩＨのユーザによって用いられ様々なサービスにアクセスする）、ＭＩＨ下位レイヤＳＡＰｓを含む（それらはＭＩＨＦによって使用され、様々なメディア依存の下位レイヤリソースを掌握しかつアクセスする）。

【0067】

ＭＩＨプロトコルは、ピアＭＩＨＦエンティティ間のメッセージの交換のためのフレームフォーマットを定義する。これらのメッセージは、メディア独立イベントサービス（Media Independent Event service）、メディア独立コマンドサービス（Media Independent Command service）およびメディア独立情報サービス（Media Independent Information service）の一部であるプリミティブに基づいている。ＩＥＥＥ ８０２．２１は、モバイルノードでのメディア独立ハンドオーバ機能（Media Independent Handover Function）およびネットワークを支援する。ＭＩＨプロトコルは、ピアＭＩＨＦエンティティが相互作用することを可能にする。

【0068】

モバイルノードのＭＩＨＦエンティティがＭＩＨプロトコル手続きを始めるために、モバイルノードのＭＩＨＦエンティティはそのピア遠隔ＭＩＨＦエンティティを発見してもよい。ピア遠隔ＭＩＨＦエンティティは、モバイルノードのＭＩＨＦがＭＩＨプロトコルメッセージを交換する、対応するＭＩＨＦエンティティである。ピア遠隔ＭＩＨＦエンティティがネットワークのいかなる場所にも存在するので、モバイルノードのＭＩＨＦエンティティは、ＭＩＨプロトコル手続きを始める前にネットワークでＭＩＨＦエンティティを発見するかもしれない。これはＭＩＨ機能発見手順（MIH Function Discovery procedure）を介してなされる。

【0069】

ＭＩＨ機能発見は、レイヤ２あるいはレイヤ３のいずれかで行うことができる。しかしながら、この文書は、両方のＭＩＨ機能が同じブロードキャストドメイン内にある場合、ＭＩＨ機能発見がレイヤ２でどのように行なわれるかを指定しているだけである。ＭＩＨ機能発見は、ＭＩＨプロトコルを介して（つまり、ＬＬＣのようなＬ２カプセル化を用いて）、あるいはメディア特定レイヤ２ブロードキャストメッセージ（つまり、８０２．１１のビーコン、８０２．１６のＤＣＤ）を介して行なわれてもよい。レイヤ３でのＭＩＨ機能発見は８０２．２１の範囲外である。

【0070】

一旦ピアＭＩＨＦが発見されたならば、ＭＮはピアＭＩＨＦの能力を発見する可能性がある。これはＭＩＨ能力発見手順（MIH Capability Discovery procedure）を介してなされる。ＭＩＨ能力発見は、ＭＩＨプロトコルを介して、あるいはメディア特定レイヤ２ブロードキャストメッセージ（つまり８０２．１１のビーコン、８０２．１６のＤＣＤ）を介して行なわれるかもしれない。

【0071】

ピアＭＩＨＦがＭＮと同じブロードキャストドメイン内に存在する場合、ＭＩＨ機能発見はＭＩＨ能力発見のみを用いて行なうことができる。

【0072】

実例となるアーキテクチャ（Illustrative Architecture）：
図１は、クライアント装置が通信する無線アクセスポイントを含むいくつかの実例となり制限しない実装で使用することができるいくつかの実例となるアーキテクチャのコンポーネントを描いている。この点では、図１は、一般に２１と呼ばれた無線ローカルエリアネットワーク（ＷＬＡＮ）に接続された実例となるワイヤ線ネットワーク２０を示す。ＷＬＡＮ ２１は、アクセスポイント（ＡＰ）２２と、多くのユーザ局２３、２４とを含んでいる。例えば、ワイヤ線ネットワーク２０はインターネットあるいは企業データ処理ネットワークを含むことができる。例えば、アクセスポイント２２は無線ルーターになりえる。また、ユーザ局２３および２４は、例えばポータブルコンピュータ、パーソナルデスクトップコンピュータ、ＰＤＡｓ、ポータブルのボイスオーバーＩＰ電話および（または）他の装置になりえる。アクセスポイント２２は、ワイヤ線ネットワーク２１にリンクされたネットワークインターフェース２５、およびユーザ局２３および２４との通信での無線トランシーバがある。例えば、無線トランシーバ２６は、ユーザ局２３、２５との無線またはマイクロ波周波数通信用のアンテナ２７を含むことができる。アクセスポイント２２にはさらにプロセッサ２８、プログラムメモリ２９、およびランダムアクセスメモリ３１がある。ユーザ局２３にはアクセスポイント局２２との通信用のアンテナ３６を含む無線トランシーバ３５がある。同様の方法で、ユーザ局２４は、アクセスポイント２２への通信用のアンテナ３９及び無線トランシーバ３８を持っている。一例として、いくつかの実施形態では、オーセンティケータがそのようなアクセスポイント（ＡＰ）のような中で使用される、および（または）嘆願者かピアがモバイルノードかユーザ局内で使用される。

【0073】

図２は、装置によって実行されるためにコンピュータ化されたプロセスステップを実行するために用いる、例えばいくつかの実施形態でのデスティネーションノードまたはソースノード、アクセスポイント、ユーザ局のような装置によって実行されるために用いることができる実例となるコンピュータか制御ユニットを示す。いくつかの実施形態では、コンピュータか制御ユニットは中央処理装置（ＣＰＵ）３２２を含んでいる。それは、バス３２６上での１セットの入出力（Ｉ／Ｏ）装置３２４で通信することができる。入出力装置３２４は例えば、キーボード、モニター、および（または）他の装置を含むことができる。ＣＰＵ３２２は、バス３２６上でのコンピュータ読取可能な媒体（例えば従来の揮発性または不揮発性のデータ記憶装置）３２８（以降「メモリ３２８」）で通信することができる。ＣＰＵ３２２と入出力装置３２４とバス３２６とメモリ３２８との間の相互作用は、当技術で知られているようなものでありうる。メモリ３２８は例えばデータ３３０を含むことができる。メモリ３２８はさらにソフトウェア３３８を記憶することができる。ソフトウェア３３８はプロセスのステップを実行するために多くのモジュール３４０を含むことができる。従来のプログラミング技術はこれらのモジュールを実行するために用いられてもよい。メモリ３２８はさらに上記のデータファイルおよび（または）他のデータファイルを記憶することができる。いくつかの実施形態では、ここに記述された様々な方法は、コンピュータシステムでの使用のためにコンピュータプログラムプロダクトを介して実行されてもよい。この実行は、例えば、コンピュータ読取可能な媒体（例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭなど）に固定された、またはコンピュータシステムへ送信可能な、一連のコンピュータ命令と、モデムなどのようなインターフェース装置とを含んでもよい。通信メディアは本質的に有形（例えば通信線）である、かつ（または）本質的に無形（例えばマイクロ波、光、赤外線などを用いる無線メディア）でもよい。コンピュータ命令は、様々なプログラミング言語で書くことができ、かつ（または）半導体素子（例えばチップまたは回路）、磁気装置、光学装置および（または）他のメモリ装置のようなメモリ装置に記憶することができる。様々な実施形態では、送信はどんな適切な通信技術を使用してもよい。

【0074】

一般的な背景文献（General Background References）：
参照を促進するために、以下の一般的な背景出願が参照文献（そのような出願はさらにここで参照によって背景参照に関する全ての以下の特許出願の全開示を組み込む）からできている。

【0075】

１）K. Taniuchiらの２００７年２月２３日に出願された米国仮出願No. 60/891 ,349；
２）Y. A. Chengらの２００６年９月１３日に出願された米国仮出願No. 60/825,567；
３）Y. Obaらの２００６年１２月５日に出願された米国出願No. 11 /567,134；
４）Y. Obaらの２００６年１１月２３日に出願された米国出願No. 11 /563,000；
５）Y. Obaらの２００６年１１月１２日に出願された米国出願No. 11 /558,922；
６）Y. Obaらの２００６年７月２７日に出願された米国出願No. 11 /460,616；
７）A. Duttaらのメディア独立プレ認証改良のフレームワーク（Framework Of Media-Independent Pre- Authentication Improvements）と題され２００６年４月１４日に出願された米国出願No. 11 /279,856；
８）失敗したスイッチングおよびスイッチバックに関する考慮（Considerations For Failed Switching And Switchback）を含んでいること；
９）Y. ObaらのPANAに関するメディア独立プレ認証サポートのフレームワーク（Framework of Media Independent Pre-Authentication Support for PANA）と題され２００６年３月９日に出願された米国出願No. 11 /308, 175；
１０）A. Duttaらのメディア独立プレ認証のフレームワーク（A Framework of Media-Independent Pre- authentication）と題され２００６年２月に出願された米国出願No. 11 /307,362；
１１）Y. Oba, et al.らの２００８年５月１２日に出願された米国出願No. 12/ 1 19,048；
上で述べたように、ハンドオーバに関するメディア独立解決法は、ＭＩＨプロトコルレベルでのセキュリティを扱わない。複数のメディア独立ハンドオーバはネットワークリソース、コストおよびユーザ経験に影響を及ぼすサービスを提供するので、ＭＩＨレベルセキュリティは、それらのネットワークでＭＩＨサービスを提供するネットワークプロバイダへの重要な要因である。例えば、ＭＩＨセキュリティの不足によって、社会での悪意のある要素によって攻撃することが脆弱のままにしておくので、例えば悪意あるユーザまたは悪意あるシステム管理者のような悪意のあるエンティティによって盗聴または改ざんすることによって障害が起きることから、ユーザが彼らの識別または彼らのプライベートの情報のことを心配すること無く安全かつセキュアにユーザがネットワークを使用することができることを保証することは、ネットワークプロバイダの利益のためである。

【発明の概要】

【0076】

いくつかの典型的な実施形態では、メディア独立ハンドオーバ（ＭＩＨ）プロトコルレベルでのセキュリティの不足の問題は、認証、認可、アクセス制御、機密性およびデータ保全性に関する特徴を提供することにより解決されてもよい。認証によって、ＭＩＨエンティティがＭＩＨネットワークへのアクセスを持つ前に、ＭＩＨエンティティの同一性を検証することができる。さらに、ＭＩＨエンティティは、与えられたＭＩＨメッセージのソースを認証することができる、つまり、それらはメッセージ発信エンティティを認証することができる。アクセスを制御することによって、公認のＭＩＨエンティティだけが、ＭＩＨサービスネットワークの内部から情報サーバ（ＩＳ）から情報にアクセスすることを許可されてもよい。されるかもしれない。機密性とデータ保全性を提供することによって、ＭＩＨプロトコルメッセージは、悪意のあるユーザまたは悪意のあるシステム管理者のようなある悪意のあるエンティティによって、アクセスされ、盗聴され、および（または）変更されることから保護されてもよい。機密性およびデータ保全性の特徴は、予め共有されているキーあるいは証明機関のような信頼できる第三者機関を使用してもよい。ＭＩＨプロトコルレベルセキュリティを実行するいくつかの典型的な実施形態は以下に要約される。

【0077】

典型的な実施形態の１つの態様では、メディア独立ハンドオーバサービスにセキュリティを提供するためのコンピュータ実行されるプロトコルを有する装置は、独立オーセンティケータを含む複数のメディア独立ハンドオーバサービスを提供するためのサービスポイントを含み、独立オーセンティケータは、サービングネットワークから候補アクセスネットワークまで、モバイル装置のハンドオーバより前に、複数の候補アクセスネットワークを認証する。ここでは、サービングアクセスネットワークおよび候補アクセスネットワークのそれぞれは、特定のサービングメディアを有する複数の異種のアクセスネットワークに属する。アクセスコントローラは、認証サーバを通って複数のメディア独立ハンドオーバサービスを提供するサービスポイントを持ったアクセス認証を通じてアクセス制御を適用し、認証サーバではアクセス認証がサービスポイントと認証サーバとの間で確立した場合には、モバイル装置は、異種メディア間でアタッチされるモバイル装置に関するサービスポイントを介して複数のメディア独立ハンドオーバサービスにアクセスする権限を与えられる。アクセス認証は、複数のモバイル装置と認証サーバとの間の複数のキーを確立するためのキー確立プロトコルを含んでいる；また、少なくとも１個のキーは、サービスポイントとモバイル装置の間で送信された複数のメディア独立ハンドオーバメッセージを保護するために、セッションキーを導きだすためのサービスポイントに配送される。アクセス認証およびキー確立プロトコルのためのトランスポートレイヤセキュリティ（ＴＬＳ）は、サービスポイントとメディア独立ハンドオーバプロトコル上のモバイル装置との間でＴＬＳハンドシェイクを行なうために使用される。ここでＴＬＳハンドシェイクは、複数のピア間でのセキュアセッションまたはセキュリティアソシエーションを確立し、メディア独立ハンドオーバプロトコルのメッセージを保護する。セキュリティアソシエーションまたはセキュアセッションは、トランスポートレベルセキュリティが付加された場合複数のメディア独立ハンドオーバメッセージがカプセル化されていないメディア独立ハンドオーバプロトコル内での複数のピア（モバイル装置およびサービスポイント（Point of Service））に結びつけられる。１つのシナリオでは、複数のモバイル装置および複数のサービングアクセスネットワークを認証するためのメディア独立ハンドオーバサービスと、同じ認証サーバを有する複数の候補アクセスネットワーク。メディア独立ハンドオーバキーイング材料は、ネットワークアクセスに関するプロアクティブ認証の間に確立されたキーイング材料からブートストラップされる。プロアクティブ認証は、複数のサービングアクセスネットワークから複数の候補アクセスネットワークへの複数のモバイル装置のハンドオーバに関するネットワークアクセスよりも前に複数の候補アクセスネットワークを認証する。別のシナリオでは、複数のモバイル装置と複数のサービングアクセスネットワークとを認証する複数のメディア独立ハンドオーバサービスと、異なる複数の認証サーバを有する複数の候補アクセスネットワーク。メディア独立ハンドオーバキーイング材料は、複数のメディア独立ハンドオーバサービスに関するプロアクティブ認証の間に、確立されたキーイング材料からブートストラップされる。プロアクティブ認証は、サービングアクセスネットワークから候補アクセスネットワークへのモバイル装置のハンドオーバの前に、複数の候補アクセスネットワークを認証することを含む。認証サーバは、拡張認証プロトコル（ＥＡＰ）サーバ、あるいは認証、承認、およびアカウンティング（ＡＡＡ）のサーバである。独立したオーセンティケータは、インターフェースを介する複数の異種のアクセスネットワークのそれぞれの間で双方向通信を管理するための単一のサービスポイントである。

【0078】

典型的な実施形態の別の態様では、複数のメディア独立ハンドオーバサービスにセキュリティを提供するためのコンピュータ実行されるプロトコルを有する装置は、独立したオーセンティケータを含んでいる複数のメディア独立ハンドオーバサービスを提供するためのサービスポイントを含んでいる。独立したオーセンティケータは、複数のサービングアクセスネットワークから複数の候補アクセスネットワークへ複数のモバイル装置のハンドオーバに先立って候補アクセスネットワークを認証する。ここで、複数のサービングアクセスネットワークおよび複数の候補アクセスネットワークのそれぞれは、特定のサービングメディアを有する複数の異種のアクセスネットワークに属している。またサービスポイントおよび複数のモバイル装置は、相互認証およびキー確立を行う。複数のモバイル装置およびサービスポイントは、モバイル装置の同一性をネットワークに属しているサービスポイントに確信して提供する（または逆の場合も同様）ために、相互認証および特定のキーのキー確立を行う；および特定の複数のキーは、複数のメディア独立ハンドオーバメッセージを保護するために、１対の同一性を拘束する。相互認証およびキー確立のためのトランスポートレイヤセキュリティ（ＴＬＳ）は、サービスポイントとメディア独立ハンドオーバプロトコル上の複数のモバイル装置との間のＴＬＳハンドシェイクを行なうために使用される。ここでＴＬＳハンドシェイクは、メディア独立ハンドオーバプロトコルの複数のメッセージを保護するために、複数のピア間でのセキュリティアソシエーションあるいはセキュアセッションを確立する。セキュリティアソシエーションまたはセキュアセッションは、トランスポートレベルセキュリティが付加される場合に複数のメディア独立ハンドオーバメッセージがカプセル化されないメディア独立ハンドオーバプロトコル内での複数のピア（モバイル装置およびサービスポイント）に結び付けられる。相互認証は、予め共有されているキーまたは証明機関のような信頼できる第三者機関を使用してもよい。

【0079】

さらに典型的な実施形態の別の態様では、セキュリティを複数のメディア独立ハンドオーバサービスに提供するためのシステムは、複数のメディア独立アクセス機能を有するサービスポイントを含む。複数の異種ネットワークには各々メディアの特定の複数のアクセス機能がある。ここで、複数の異種ネットワークがサービングアクセスネットワークおよび候補アクセスネットワークを含んでいる。複数のモバイル装置は、複数の異種ネットワークに接続し、かつ複数のサービングアクセスネットワークから複数の候補アクセスネットワークまでモバイル装置のハンドオーバに先立って候補アクセスネットワークを認証するサービスポイントに接続した。認証サーバおよびアクセスコントローラは、認証サーバを通って複数のメディア独立ハンドオーバサービスを提供するサービスポイントを有するアクセス認証を介してアクセス制御を適用する。認証サーバでは、アクセス認証がサービスポイントと認証サーバとの間で確立される場合、複数のモバイル装置は異種のメディア間でアタッチされたモバイル装置に関するサービスポイントを介してメディア独立ハンドオーバサービスにアクセスすることを認められる。アクセス認証は、複数のモバイル装置と認証サーバとの間の複数のキーを確立するためのキー確立プロトコルを含んでいる。；また、少なくとも１個のキーは、サービスポイントと複数のモバイル装置の間で送信された複数のメディア独立ハンドオーバメッセージを保護するために、セッションキーを導くためのサービスポイントに配信される。アクセス認証およびキー確立プロトコルに関するトランスポートレイヤセキュリティ（ＴＬＳ）は、サービスポイントとメディア独立ハンドオーバプロトコル上のモバイル装置との間でのＴＬＳハンドシェイクを行なうために使用される。ここでＴＬＳハンドシェイクは、メディア独立ハンドオーバプロトコルのメッセージを保護するために、複数のピア（モバイル装置およびサービスポイント（Point of Service））の間でのセキュリティアソシエーションまたはセキュアセッションを設立する。セキュリティアソシエーションまたはセキュアセッションは、トランスポートレベルセキュリティが加えられる場合、複数のメディア独立ハンドオーバメッセージがカプセル化されないメディア独立ハンドオーバプロトコル内での複数のピアに結び付けられる。あるシナリオでの、モバイル装置と、同じ認証サーバを有する複数の候補アクセスネットワークおよび複数のサービングアクセスネットワークとを認証するための複数のメディア独立ハンドオーバサービス。メディア独立ハンドオーバキー材料は、ネットワークアクセスに関するプロアクティブ認証中に確立されるキー材料からブートストラップされる。プロアクティブ認証は、複数のサービングアクセスネットワークから複数の候補アクセスネットワークへのモバイル装置のハンドオーバのためのネットワークアクセスに先立って、候補アクセスネットワークを認証することを備える。別のシナリオでの、モバイル装置と、異なる認証サーバを有する複数の候補アクセスネットワークおよび複数のサービングアクセスネットワークとを認証するための複数のメディア独立ハンドオーバサービス。メディア独立ハンドオーバキー材料は、複数のメディア独立ハンドオーバサービスのためのプロアクティブ認証中に確立されるキー材料からブートストラップされる。プロアクティブ認証は、複数のサービングアクセスネットワークから複数の候補アクセスネットワークへの複数のモバイル装置のハンドオーバに先立って複数の候補アクセスネットワークを認証することを含んでいる。

【0080】

典型的な実施形態の別の態様では、複数のメディア独立ハンドオーバサービスにセキュリティを提供するためのシステムは、複数のメディア独立アクセス機能があるサービスポイントを含んでいる。それぞれが複数のメディア特定アクセス機能を有する複数の異種ネットワーク。ここで、複数の異種ネットワークは複数のサービングアクセスネットワークおよび複数の候補アクセスネットワークを含んでいる。複数のモバイル装置は、複数の異種ネットワークに接続し、複数のサービングアクセスネットワークから複数の候補アクセスネットワークへのモバイル装置のハンドオーバに先立って候補アクセスネットワークを認証するためにサービスポイントに接続し、ここでサービスポイントおよび複数のモバイル装置は、相互認証とキー確立を導く。複数のモバイル装置およびサービスポイントは、複数のモバイル装置の同一性をネットワークに属しているサービスポイントに確実に提供する（または逆の場合も同様）ために、特定の複数のキーのキー確立および相互認証を行い；また、特定の複数のキーは、複数のメディア独立ハンドオーバメッセージを保護するために、１対の同一性を結び付ける。相互認証およびキー確立のためのトランスポートレイヤセキュリティ（ＴＬＳ）は、サービスポイントとメディア独立ハンドオーバプロトコル上の複数のモバイル装置との間のＴＬＳハンドシェイクを行なうために使用される。ここでＴＬＳハンドシェイクは、メディア独立ハンドオーバプロトコルの複数のメッセージを保護するために、複数のピア間でのセキュリティアソシエーションあるいはセキュアセッションを確立する。相互認証は、予め共有されているキーまたは信頼できる第三者機関に基づいてもよく、ここで信頼できる第三者機関は証明機関でもよい。

【0081】

さらに典型的な実施形態の別の態様では、プロセッサが複数のメディア独立ハンドオーバサービスにセキュリティを提供するための動作を実行することを可能にするために、それ上にエンコードされる複数の命令を有する機械アクセス可能な媒体であって、それは次のステップを含む：独立したオーセンティケータを含む複数のメディア独立ハンドオーバサービスを提供すること、ここで、独立したオーセンティケータは、複数のサービングアクセスネットワークから複数の候補アクセスネットワークへのモバイル装置のハンドオーバに先だって複数の候補アクセスネットワークを認証する。複数のサービングアクセスネットワークと複数の候補アクセスネットワークのそれぞれは特定のサービングメディアを有する複数の異種アクセスネットワークに属している。認証サーバを通って複数のメディア独立ハンドオーバサービスを提供するサービスポイントを持ったアクセス認証を介してアクセス制御を適用すること、サービスポイントと認証サーバとの間にアクセス認証を確立すること、その結果、複数のモバイル装置は、異種メディア間でアタッチされた複数のモバイル装置に関するサービスポイントを介して複数のメディア独立ハンドオーバサービスにアクセスすることを認められる。

【0082】

様々な実施形態の上記および（または）他の態様、特徴、および（または）利点は、付属の図面と関連して以下の記述の観点で、さらに評価されるだろう。様々な実施形態は、適用可能な、異なる態様、特徴、および（または）利点を含みおよび（または）除外することができる。さらに、様々な実施形態は、適用可能な他の実施形態の１つ以上の態様あるいは特徴を組み合わせることができる。

【0083】

特別の実施形態の、態様、特徴、および（または）利点は、他の実施形態または請求項を制限するとして解釈されるべきでない。

【図面の簡単な説明】

【0084】

本発明の実施形態の上記および他の特徴および利点は、以下の添付の図面に関しての典型的な実施形態について詳細に記述することによってより明白になるだろう：

【図1】クライアント装置が通信する無線アクセスポイントを含むいくつかの実例となり制限しない実装で使用することができるいくつかの実例となるアーキテクチャ上のコンポーネントを描く；

【図2】装置（例えば、いくつかの実施形態でのソースノード、デスティネーションノード、アクセスポイント、あるいはユーザ局）によって実行されるために、コンピュータ化されたプロセスステップを実装するために用いることができる実例となるコンピュータまたは制御ユニットを示す；

【図3】認証関連セキュリティシグナリングがいくつかの実施形態で実現されうるＩ．Ｅ．Ｅ．Ｅ８０２．２１の規格で開示されるような実例となるメディア独立ハンドオーバ機能通信モデルである；

【図4】認証関連セキュリティシグナリングがいくつかの実施形態で実現されうるメディア独立ハンドオーバサービス通信モデルを持ったネットワークモデルの例である；

【図5】ダイレクトプロアクティブ認証シグナリングの間に、異なる機能エンティティとそれらの関与との間の関係を例証する；

【図6】非ダイレクトプロアクティブ認証シグナリングの間に、異なる機能エンティティとそれらの関与との間の関係を例証する；

【図7】２つのアクセスネットワークが１つのメディア独立したオーセンティケータおよびキーホルダーによって管理される場合、プロアクティブ認証用の実例となる論理的なアーキテクチャを例証する；

【図8】２つのアクセスネットワークが２つの個別のメディア独立オーセンティケータおよびキーホルダーによって管理される場合、プロアクティブ認証用の実例となる論理的なアーキテクチャを例証する；

【図9】ＭＮと、ネットワーク主導のダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間での複数のメッセージフローを示す；

【図10】ＭＮと、モバイル主導のダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図11】ＭＮと、ネットワーク主導の非ダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図12】ＭＮと、モバイル主導の非ダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図13】ＭＮと、ネットワーク主導のダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図14】ＭＮと、モバイル主導のダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図15】ＭＮと、ネットワーク主導の非ダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図16】ＭＮと、モバイル主導の非ダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；

【図17】ＭＮと、ターゲットＭＳＡ−ＫＨと、ターゲットＭＩＡ−ＫＨとの間でのコールフローを示す；

【図18】ネットワーク主導およびモバイル主導両方のダイレクト終了手続に関するコールフローを示す；

【図19】ネットワーク主導およびモバイル主導両方の非ダイレクト終了手続に関するコールフローを示す；

【図20】複数のＭＩＨサービスおよびネットワークサービスは同じ認証サーバを使用する場合、統合されたシナリオに関するコールフローを示す；

【図21】統合されたシナリオでの成功した認証の結果としてＭＩＨセキュリティアソシエーション（ＳＡ）がブートストラップされ、かつＭＩＨサービスアクセス制御が適用される場合でのコールフローを示す；

【図22】成功した認証の結果としてＭＩＨ ＳＡがブートストラップされ、かつＭＩＨサービスアクセス制御が適用される場合でのコールフローを示す；

【図23】複数のＭＩＨサービスおよびネットワークアクセスサービスが異なる認証サーバを使用する場合に分割シナリオに関するコールフローを示す；

【図24】アクセス制御なしのＭＩＨセキュリティに関するコールフローを示す；

【図25】ＭＩＨ ＳＡに関するキー階層を示す；

【図26】ＭＩＨ ＳＡに関するキー階層を示す；

【図27】トランスポートレイヤセキュリティ（ＴＬＳ）ハンドシェイクの間にＭＩＨセキュリティパケットデータユニット（ＭＩＨＳ ＰＤＵ）に関するフレーム構造を示す；

【図28】ＭＩＨ ＳＡの存在している状態でＭＩＨＳ ＰＤＵに関するフレーム構造を示す；

【図29】トランスポートアドレス変更でのフレーム構造を示す。

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

【0085】

本発明は多くの異なる形式で具体化されてもよいが、多くの実例となる実施形態は、本開示は発明の原理の提供する例としてみなされるべきという理解、およびそのような例は発明をここに記述されるおよび（または）ここに例証された好ましい実施形態に限定しないという理解の下でここに記述される。

【0086】

用語（Terminologies）：
ＥＡＰ：Extensible Authentication Protocol 拡張認証プロトコル
ＥＲＰ：EAP Re-Authentication Protocol ＥＡＰ再認証プロトコル
ＳＡ：Serving Authenticator サービングオーセンティケータ
ＣＡ：Candidate Authenticator 候補オーセンティケータ
定義（Definitions）：
認証プロセス（Authentication Process）：暗号の動作および認証を行う支援するデータフレーム認証を行なう暗号の動作および支援するデータフレーム。

【0087】

メディア特定オーセンティケータおよびキーホルダー（Media Specific Authenticator and Key Holder）（ＭＳＡ−ＫＨ）：メディア特定オーセンティケータおよびキーホルダーは、メディアに特有のリンクの他端にアタッチされた他のエンティティの認証を促進するエンティティである。

【0088】

メディア独立オーセンティケータおよびキーホルダー（Media Independent Authenticator and Key Holder）（ＭＩＡ−ＫＨ）：メディア独立したオーセンティケータおよびキーホルダーは、ＭＳＡ−ＫＨと相互作用し、かつＭＳＡ−ＫＨのリンクの他端にアタッチされた他のエンティティのプロアクティブ認証を促進するエンティティである。

【0089】

プロアクティブ認証（Proactive Authentication）：ＭＳＡ−ＫＨのリンクの他端にアタッチされる他の複数のエンティティと、ＭＩＡ−ＫＨとの間で行なわれる認証プロセス。他の複数のエンティティが別のリンクへのハンドオーバを行なおうとする場合、このプロセスが生じる。

【0090】

サービングＭＩＡ−ＫＨ（Serving MIA-KH）：アクセスネットワークにアタッチされるモバイルノードに現在サービスしているＭＩＡ＿ＫＨ。

【0091】

候補ＭＩＡ−ＫＨ（Candidate MIA-KH）：潜在的な複数の候補アクセスネットワークのモバイルノードのリストに載っているアクセスネットワークにサービスするＭＩＡ−ＫＨ。

【0092】

ＭＩＨセキュリティアソシエーション（MIH Security Association）（ＳＡ）：ＭＩＨ ＳＡは複数のピアＭＩＨエンティティ間でのセキュリティアソシエーションである。

【0093】

参考文献（References）
次の参考文献のそれぞれ全ては、背景参照に関するそれらの全体におけるこの開示において参照によってここに組み込まれる：
［ＲＦＣ４７４８］H. Levkowetz, Ed. and et al, Extensible Authentication Protocol (EAP), RFC 3748；
［ＲＦＣ５２９６］V. Narayan and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)" RFC 5296；
［ＲＦＣ４３０６］C. Kaufman, Ed, "Internet Key Exchange (IKEv2) Protocol:", RFC 4306；
［ＲＦＣ５２４６］T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246；
［ＲＦＣ４３４７］E. Rescorla and N. Modadugu, "Datagram Transport Layer Security", RFC 4347；
［ＲＦＣ５２９５］J. Saloway, et al, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)" RFC 5295；および
［ＩＥＥＥ８０２．２１］IEEE P802.21 Std-2008, IEEE Standard for Local and Metropolitan Area Networks- Part 21: Media Independent Handover Services.
プロアクティブ認証（Proactive Authentication）
プロアクティブ認証は、メディア独立またはメディア依存のオーセンティケータおよび候補ネットワークをサービスしているキーホルダー（ＭＩＡ／ＭＳＡ−ＫＨ）で、アプリオリなネットワークアクセス認証をエンティティが行なうことができるプロセスである。エンティティは近隣のネットワークへのハンドオーバを予期してそのような認証を行なう。プロアクティブ認証は２つの方法で行なうことができる：ｉ）認証シグナリングがサービングＭＩＡ−ＫＨにトランスペアレントであるダイレクトプロアクティブ認証（図５）と、ｉｉ）サービングＭＩＡ−ＫＨが認証シグナリングを承知している非ダイレクトプロアクティブ認証（図６）。それぞれの場合では、ＥＡＰ（Extensible Authentication Protocol、拡張認証プロトコル）［ＲＦＣ４７９８］あるいはＥＲＰ（EAP Re-Authentication Protocol、ＥＡＰ再認証プロトコル）［ＲＦＣ５２９６］のいずれかは、認証プロトコルとして用いることができる。

【0094】

図５および図６は、プロアクティブ認証シグナリング中に異なる機能エンティティの間の関係と、プロアクティブ認証シグナリングの間でのそれらの関与とを例証する。ダイレクトプロアクティブ認証については、モバイルノードは、候補ＭＩＡ−ＫＨと直接通信する（図５）。また、非ダイレクトプロアクティブ認証については、モバイルノードは最初にサービングＭＩＡ−ＫＨと通信する。その後、サービングＭＩＡ−ＫＨはモバイルノードの代わりに、候補ＭＩＡ＿ＫＨと通信する。

【0095】

プロアクティブ認証アーキテクチャ（Proactive Authentication Architecture）
図７および図８での典型的な実施形態は、プロアクティブ認証用の２つの例の論理的なアーキテクチャを描いている。メディア独立したオーセンティケータおよびキーホルダー（ＭＩＡ−ＫＨ、Media Independent Authenticator and Key Holder）は、複数の候補ネットワークへのハンドオーバに先立って、認証を円滑にするエンティティである。このアーキテクチャでは、複数の認証機能はメディア独立ハンドオーバ機能（ＭＩＨＦ、Media Independent Handover Function）内に加えられる。また、新しいエンティティは向上されたＰＯＳ（例えばＰｏＳ＋）として呼ばれる。

【0096】

メディア特定オーセンティケータおよびキーホルダー（ＭＳＡ−ＫＨ、Media Specific Authenticator and key holder）は、特定のアクセスネットワークへのアクセス用の認証装置に関与している。また、提案されたアーキテクチャは、そのような既存の機構を変更しないと仮定する。図７と図８との間の差は、図７では、２つのアクセスネットワークが１つのＭＩＡ−ＫＨによって管理され、したがって１つのＰｏＳが存在するが、一方図８では、それぞれのアクセスネットワークがそれら自身のＭＩＡ−ＫＨを有していてしたがって２つの別個のＰｏＳが必要である。図８にはさらにＭＩＨ通信モデルについてＲＰ５と呼ばれる１つの追加のインターフェースがある［ＩＥＥＥ Ｓｔｄ ８０２．２１．２００８］。

【0097】

この開示は、ネットワーク主導およびモバイル主導の手続を含む、ダイレクトおよび非ダイレクトのプロアクティブ認証の両方をサポートする。動作のシーケンスは次のものを含んでいる：
−ＭＮはアクセス特定認証手続でアクセスネットワークにアタッチする；
−ハンドオーバ準備段階の間に、ＭＮは候補オーセンティケータを発見する；
−メディア独立したオーセンティケータの到達可能性に依存して、ＭＮは、ＲＰｌインターフェースを用いて、ダイレクトまたは非ダイレクトのいずれかのプロアクティブ認証を行なう；
−一旦メディア独立した認証が成功して行なわれれば、複数のメディア特定キーはＭＳＡ−ＫＨへ押されるか、あるいはＭＳＡ−ＫＨから引かれる。Ｉｎｔｅｒｆａｃｅ＿ＭＩＡ−ＫＨ−ＭＳＡ−ＫＨはこの動作を行なうために用いられる；
−ＭＮは、メディア特定セキュアアソシエーション（例えば８０２．１１に関する４方向のハンドシェイク）を行なうことにより、ハンドオーバを実行し、さらにターゲットとして知られている候補ネットワークのうちの１つへアタッチする；そして
−接続確立の後、ＭＮはＰｏＳで再登録する。

【0098】

次の仮定は、このセクションの残りにわたってなされる：
仮定（Assumptions）
−オーセンティケータはＭＩＨ ＰｏＳである；
−ＭＩＨプロトコルはＥＡＰとＥＲＰを運ぶために用いられる；
−ＭＮのＭＩＨＦ−ＩＤはＭＮのメディア独立した同一性として用いられる；
−オーセンティケータのＭＩＨＦ−ＩＤはオーセンティケータのメディア独立した同一性として用いられる；
−メディア独立したオーセンティケータ（Media Independent Authenticator）は、ＥＡＰによって生成されたｒＭＳＫ（再認証ＭＳＫ）あるいはＭＳＫ(Master Session Key)（マスターセッションキー）を保持する；
−ＭＳＫまたはｒＭＳＫはメディア独立した対のマスターキー（ＭＩ−ＰＭＫ）を導き出すために用いられる；および
−ＭＮがターゲットＭＳＡ−ＫＨにハンドオーバし、かつそれがターゲットＭＳＡ−ＫＨに関するＭＩ−ＰＭＫから導き出されたメディア特定ＰＭＫ（ＭＳ−ＰＭＫ）を有する場合、それはＭＳ−ＰＭＫを用いて、メディア特定なセキュアアソシエーションを実施する。

【0099】

ＥＡＰを用いたプロアクティブ認証（Proactive Authentication using EAP）
このセクションはプロアクティブ認証プロトコルとしてＥＡＰを用いる手続きについて記述する。

【0100】

ダイレクトプロアクティブ認証（Direct Proactive Authentication）
このシナリオでは、ＭＮは、メディア独立候補オーセンティケータで、認証を直接的に行なう。ここでの仮定はＭＮが、候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかである。候補オーセンティケータは、ＩＰリンクを介してＭＮから直接到達可能であるに違いない。

【0101】

コールフロー（Call Flows）
図９は、ネットワーク主導のダイレクトプロアクティブ認証に関して、ＭＮとメディア独立オーセンティケータとの間の複数のメッセージフローを記述する。それは例Ａおよび例Ｂのアーキテクチャの両方をカバーする。例Ｂアーキテクチャでは、サービングＭＩＡ−ＫＨ（Serving MIA-KH）および複数の候補ＭＩＡ−ＫＨオーセンティケータは、２つの別個のエンティティであり、またそれらは、互いに通信するためにインターフェースＲＰ５を用いる。２つの新しいＭＩＨメッセージタイプ：ｉ）ＭＩＨ Ｐｒｏ＿Ａｕｔｈリクエスト（ＥＡＰ）メッセージおよびｉｉ）ＭＩＨ Ｐｒｏ＿Ａｕｔｈ応答メッセージは、ＭＩＨ上の複数のＥＡＰメッセージを伝えるために提案されている。最初のＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージは、ＭＮからのＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージが続くＥＡＰ＿Ｉｄｅｎｔｉｔｙ＿Ｒｅｑｕｅｓｔメッセージを伝えるネットワークによって開始される。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤ同一性で複数のキーを安全に結びつけるために、最終リクエスト／応答メッセージにおいて必要である。

【0102】

図１０は、モバイル主導のプロアクティブ認証に関して、ＭＮと、メディア独立したオーセンティケータとの間の複数のメッセージフローを記述する。以前のものとの重要な差は、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔを生成し、かつそれを候補オーセンティケータに直接送るＭＮからトリガーが来るということである。残りのコールフローは、図９に記述されるようなネットワーク主導のダイレクトプロアクティブ認証に似ている。

【0103】

非ダイレクトプロアクティブ認証（Indirect Proactive Authentication）
このシナリオではＭＮは、メディア独立候補オーセンティケータで、認証を直接行なうことができない。サービングオーセンティケータは、ＭＮ（ネットワーク主導認証の場合）、または候補ＭＩＡ−ＫＨ（モバイル主導認証の場合）のどちらかへ向けて、複数のメッセージを転送することに参加する。ここでの仮定は、ＭＮが候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかであるが、ＭＮは候補オーセンティケータにＩＰリンクを介して直接到達することはできない。

【0104】

コールフロー（Call Flows）
図１１は、ネットワーク主導の非ダイレクトプロアクティブ認証に関して、ＭＮと、複数のメディア独立オーセンティケータとの間での複数のメッセージフローを記述する。以前に記述されているように、それは例Ａおよび例Ｂのアーキテクチャの両方をカバーする。また、例Ｂのアーキテクチャでは、サービングＭＩＡ−ＫＨおよび候補ＭＩＡ−ＫＨのエンティティは、２つの別個のエンティティである。またそれらは、互いに通信するためにインターフェースＲＰ５を用いる。最初のＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージは、候補ＭＩＡ−ＫＨによって始められ、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにそれを送った。

【0105】

ＭＮはＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを生成し、続く複数のＥＡＰメッセージはリクエストおよび応答のメッセージに関して運ばれる。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤ同一性で、キーを安全に結び付けるために用いられる。

【0106】

図１２は、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージを生成し、サービングＭＩＡ−ＫＨにそれを送るＭＮからトリガーが来る、モバイル主導の非ダイレクトプロアクティブ認証を描いている。候補ＭＩＡ−ＫＨは、サービングＭＩＡ−ＫＨからこのメッセージを受信し、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを送る。

【0107】

残りのコールフローは、図１１で記述されるようなネットワーク主導の非ダイレクトプロアクティブ認証に似ている。

【0108】

ＥＲＰを使用するプロアクティブ認証（Proactive Authentication using ERP）
このセクションはプロアクティブ認証プロトコルとしてＥＲＰを用いる手続きについて記述する。

【0109】

ダイレクトプロアクティブ認証（Direct Proactive Authentication）
このシナリオではＭＮは、メディア独立候補オーセンティケータで、認証を直接行なう。ここでの仮定はＭＮが、候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかである。候補オーセンティケータは、ＩＰリンクを介してＭＮから直接到達可能であるに違いない。

【0110】

コールフロー（Call Flows）
図１３は、ネットワーク主導のダイレクトプロアクティブ認証に関して、ＭＮとメディア独立オーセンティケータとの間の複数のメッセージフローを例証する。それは例Ａおよび例Ｂのアーキテクチャの両方をカバーし、例Ｂのアーキテクチャでは、サービングＭＩＡ−ＫＨ（Serving MIA-KH）および複数の候補ＭＩＡ−ＫＨオーセンティケータは、２つの別個のエンティティであり、またそれらは、互いに通信するためにインターフェースＲＰ５を用いる。ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｉｎｄｉｃａｔｉｏｎと呼ばれる新しいＭＩＨメッセージタイプが、ＭＩＨ上での複数のＥＲＰメッセージ交換を開始するために提案されている。これは、ＭＮを始動させ、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔ（ＥＲＰ）メッセージを生成する。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤ同一性で複数のキーを安全に結びつけるために、リクエスト／応答メッセージにおいて必要である。

【0111】

図１４は、モバイル主導のプロアクティブ認証に関して、ＭＮと、メディア独立したオーセンティケータとの間の複数のメッセージフローを例証する。以前のものとの主な差は、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔを生成し、かつそれを候補オーセンティケータに直接送るＭＮからトリガーが来るということである。最後に、候補ＭＩＡ−ＫＨは、認証成功または失敗を有するＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅを送る。

【0112】

非ダイレクトプロアクティブ認証（Indirect Proactive Authentication）
このシナリオではＭＮは、メディア独立候補オーセンティケータで、認証を直接行なうことができない。サービングオーセンティケータは、ＭＮ（ネットワーク主導認証の場合）、または候補ＭＩＡ−ＫＨ（モバイル主導認証の場合）のどちらかへ向けて、複数のメッセージを転送することに参加する。ここでの仮定は、ＭＮが候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかであるが、ＭＮは候補オーセンティケータにＩＰリンクを介して直接到達することはできない。

【0113】

コールフロー（Call Flows）
図１５は、ネットワーク主導の非ダイレクトプロアクティブ認証に関して、ＭＮと、複数のメディア独立オーセンティケータとの間での複数のメッセージフローを例証する。最初のＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージは、候補ＭＩＡ−ＫＨによって始められ、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにそれを送った。ＭＮはＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを生成し、続く複数のＥＡＰメッセージはリクエストおよび応答のメッセージに関して運ばれる。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤ同一性で、キーを安全に結び付けるために用いられる。

【0114】

図１６は、ＥＲＰを有するＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージを生成し、サービングＭＩＡ−ＫＨにそれを送るＭＮからトリガーが来る、モバイル主導の非ダイレクトプロアクティブ認証を例証する。候補ＭＩＡ−ＫＨは、サービングＭＩＡ−ＫＨからこのメッセージを受信し、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにＥＲＰを有するＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを送る。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤ同一性で複数のキーを安全に結びつけるために、リクエスト／応答メッセージにおいて必要である。

【0115】

ターゲットオーセンティケータへのアタッチメント（Attachment to Target Authenticator）
認証が行なわれ、かつモバイルノードがハンドオーバを実行することを決定した後に、それは複数の候補ネットワークのうちの１つを選択し、そのアクセスネットワークに切り替える。この候補ネットワークはターゲットネットワークになり、このアクセスネットワークにサービスするオーセンティケータは、ターゲットメディア特定オーセンティケータおよびキーホルダー（ＭＳＡ−ＫＨ）と呼ばれる。その後、ターゲットＭＳＡがモバイルノードに関してターゲットメディア独立オーセンティケータおよびキーホルダー(MIA-KH)からキーの正しいセットを得たと仮定して、モバイルノードはメディア特定セキュアアソシエーション（ＳＡ）を行う。

【0116】

コールフロー（Call Flows）
図１７は、ＭＮとターゲットＭＳＡ−ＫＨとターゲットＭＩＡ−ＫＨとの間のコールフローを描く。一旦プロアクティブ認証が成功して行なわれれば、ＭＩＡ−ＫＨは、ＭＳＡ−ＫＨへ押されるか、ＭＳＡ−ＫＨによって引かれることができる複数のモバイルノードメディア特定キーにつき生成する。一旦複数のキーがＭＳＡ−ＫＨで利用可能ならば、モバイルノードは、十分な認証を行う必要がなしにネットワークへそれが切り替えるとすぐに、メディア特定セキュリティアソシエーションを行うことができる。一旦セキュアアソシエーションが成功し、かつＩＰ接続が確立されれば、ＭＮは、ＭＩＡ−ＫＨが正確にモバイルノードをそのサービングノードとして登録するために、ＭＩＡ−ＫＨを登録する。

【0117】

プロアクティブ認証終了（Proactive Authentication Termination）
プロアクティブ認証終了の目的は、モバイルノードおよび候補／ターゲット／サービングのオーセンティケータがセッションを終了し、対応の複数の状態マシンが同期されることを保証することである。この時点で、ＭＩ−ＰＭＫおよびＭＳ−ＰＭＫはキャッシュされるかまたは削除されるかのいずれかである。

【0118】

ダイレクトプロアクティブ認証終了（Direct Proactive Authentication Termination）
ダイレクトプロアクティブ認証終了は、ネットワークおよびモバイルのノードの両方が認証状態を直接終了することを可能にする。

【0119】

コールフロー（Call Flows）
図１８は、ネットワーク主導およびモバイル主導の終了手続の両方に関するコールフローを例証する。保全性チェック（インテグリティチェック、integrity check）を含む目的は、終了のリクエストおよび応答の信頼性を確認することである。

【0120】

非ダイレクトプロアクティブ認証終了（Indirect Proactive Authentication Termination）
非ダイレクトプロアクティブ認証終了は、ネットワークとモバイルノードの両方がサービングＭＩＡ−ＫＨを介して認証状態を終了することを可能にする。

【0121】

コールフロー（Call Flows）
図１９は、ネットワーク主導およびモバイル主導の終了手続の両方に関するコールフローを例証する。保全性チェックを含むことの目的は、終了のリクエストおよび応答の信頼性を確認することである。両方の場合では、サービングＭＩＡ−ＫＨは、終了リクエストを、ＭＮまたは候補ＭＩＡ−ＫＨのいずれかへ転送する。

【0122】

プリミティブ（Primitives）
このセクションは、プロアクティブ認証を可能にするために要求されるプリミティブおよび対応するパラメーターを概説する。

【0123】

イベントプリミティブ（Event Primitives）
テーブル１は、複数のリンクイベントのリストを記述する。

【0124】

テーブル１：イベントプリミティブのリスト（List of Event Primitives）

【表1】

【0125】

Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿ｋｅｙ＿Ｉｎｓｔａｌｌ．ｉｎｄｉｃａｔｉｏｎ
機能：レイヤ２接続の確立が、サービスプリミティブの指定されたリンクインターフェースセマンティックス（Semantics）上で試みられる場合、この通知が配信される。

【0126】

Link_Pro_Auth_key_Install.indication （
Linkldentifler
）
パラメーター（Parameters）:

【表2】

【0127】

生成された場合（When generated）
指定されたリンクインターフェースに関してあるいは成功したプロアクティブ認証の完成の後に、レイヤ２接続が確立される場合、この通知が生成される。

【0128】

受信の影響（Effect of Receipt）
ＭＩＨＦは、この通知をサブスクライブしている（複数の）ＭＩＨユーザにこのリンク通知を渡すものとする。（複数の）ＭＩＨユーザは複数のメディア特定キーを押すか引く。

【0129】

ＭＩＨイベント（MIH Events）
テーブル２はＭＩＨイベントのリストを記述する。

【0130】

テーブル２：ＭＩＨイベントのリスト（List of MIH Events）

【表3】

【0131】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｓｕｌｔ．ｉｎｄｉｃａｔｉｏｎ
機能：ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｓｕｌｔは、ローカルイベントを彼らに通知するために、複数のローカルＭＩＨＦユーザに送られるか、またはこの遠隔イベントにサブスクライブしている複数の遠隔ＭＩＨＦユーザに示すためにＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｑｕｅｓｔメッセージの受信の結果である。

【0132】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Result.indication (
Sourceldentifier
Mobilenodeldentifier
Candidateldentifier(Optional)
MobileLinkldentifiers
PoALinkldentifiers
Status
)
パラメーター（Parameters）:

【表4】

【0133】

生成された場合（When Generated）
このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｑｕｅｓｔメッセージが受信された場合に、ローカルまたは遠隔のＭＩＨＦによって生成される。

【0134】

受信への影響（Effect on Receipt）
ＭＩＨＦは、この通知をサブスクライブした（複数の）ＭＩＨユーザへこのリンク通知を渡すものとする。

【0135】

コマンドプリミティブ（Command Primitives）
テーブル３はＭＩＨコマンドについて記述する。

【0136】

テーブル３：ＭＩＨコマンドのリスト（List of MIH Commands）

【表5】

【0137】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｑｕｅｓｔ
機能：プリミティブは、プロアクティブ認証のその意図についてローカルＭＩＨＦあるいはピアＭＩＨユーザに示すために、ＭＩＨユーザ（MIH User）によって呼び出される。

【0138】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Start.request (
Destinationldentifier,
MobileNodeldentifier(Optional)
Candidateldentifier(Optional)
)
パラメーター（Parameters）：

【表6】

【0139】

生成される場合（When Generated）
このプリミティブは、プロアクティブ認証のその意図についてのローカルＭＩＨＦまたは遠隔のＭＩＨユーザと通信するために、ＭＩＨユーザによって呼び出される。

【0140】

受信への影響（Effect on Receipt）
このプリミティブの受信に際して、ローカルＭＩＨＦは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージを生成し、かつデスティネーション識別子（Destination Identifier）によって識別される遠隔のＭＩＨＦへ送信する。遠隔のＭＩＨＦはＭＩＨユーザ（MIH User）へ指示としてリクエストを転送する。

【0141】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｉｎｄｉｃａｔｉｏｎ
機能：このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージが遠隔ＭＩＨＦから受信されたＭＩＨユーザ（MIH User）に示すために、ＭＩＨＦによって用いられる。

【0142】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Start.indication (
Sourceldentifier,
MobileNodeldentifier
Candidateldentifier
)
パラメーター（Parameters）:

【表7】

【0143】

生成される場合（When Generated）
このプリミティブは、ピアＭＩＨＦからＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｑｕｅｓｔメッセージを受信することについてＭＩＨＦによって生成される。

【0144】

受信への影響（Effect on Receipt）
この指示を受信するＭＩＨユーザ（MIH User）は、リクエストメッセージでのソース識別子（Source Identifier）によって示される遠隔ＭＩＨＦへのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｓｐｏｎｓｅプリミティブを呼び出すものとする。

【0145】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｓｐｏｎｓｅ
機能：このプリミティブは、ネットワークでの遠隔ＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｑｕｅｓｔメッセージへ応答するために、ＭＮでのＭＩＨＦによって使用される。

【0146】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_start.response (
Destinationldentifier,
MobileNodeldentifier (Optional),
Candidateldentifier (optional),
Status,
)
パラメーター（Parameters）:

【表8】

【0147】

生成される場合（When Generated）
遠隔のＭＩＨユーザ（MIH User）は、そのＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｓｐｏｎｓｅメッセージに応答してこのプリミティブを呼び出す。

【0148】

受信への影響（Effect on Receipt）
ＭＩＨＦは、デスティネーション識別子に示されるピアＭＩＨＦへＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｓｐｏｎｓｅメッセージを送信する。

【0149】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｃｏｎｆｉｒｍ
機能：このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｓｐｏｎｓｅメッセージがピアＭＩＨＦから受信されたことを確認するためにＭＩＨＦによって用いられる。

【0150】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Start.confirm(
Sourceldentifier,
MobileNodeldentifier(Optional),
Candidateldentifier(Optional),
Status,
)
パラメーター（Parameters）:

【表9】

【0151】

生成される場合（When Generated）
このプリミティブは、ピアＭＩＨＦからＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｓｐｏｎｓｅメッセージを受信するＭＩＨＦによって生成される。

【0152】

受信への影響（Effect on Receipt）
プリミティブを受信する際に、プロアクティブ認証リクエストを最初に開始するエンティティは、プロアクティブ認証を実行するか、またはプリミティブに基づいてそれを中止することを決定する。しかしながら、ステータス（Status）が「成功あるいは失敗（Success or Failure）」を示さない場合、受信者は任意の他の戻り値を無視し、代わりに、適切なエラー処理を行なう。

【0153】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｒｅｑｕｅｓｔ
機能：プリミティブは、プロアクティブ認証の終了についてピアＭＩＨユーザ（MIH User）に示すために、ＭＩＨユーザによって呼び出される。

【0154】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Termination.request (
Destinationldentifier,
MobileNodeldentifier(Optional)
Candidateldnetifier(Optional)
KeyCache
)
パラメーター（Parameters）:

【表10】

【0155】

生成される場合（When Generated）
このプリミティブは、プロアクティブ認証の終了について遠隔のＭＩＨユーザと通信するために、このプリミティブはＭＩＨユーザによって呼び出される。

【0156】

受信への影響（Effect on Receipt）
このプリミティブの受信に際して、ローカルＭＩＨＦは、デスティネーション識別子（Destination Identifier）によって識別された遠隔のＭＩＨＦへのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを生成し送る。遠隔のＭＩＨＦは、ＭＩＨユーザへの指示としてリクエストを転送する。

【0157】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｉｎｄｉｃａｔｉｏｎ
機能：このプリミティブは、MIH_Pro_Auth_Termination requestメッセージが遠隔ＭＩＨＦから受信されたことをＭＩＨユーザに示すために、ＭＩＨＦによって用いられる。

【0158】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Termination.indication (
Sourceldentifier,
MobileNodeldentifier(Optional)
Candidateldnetifier(Optional)
KeyCache
)
パラメーター（Parameters）:

【表11】

【0159】

生成される場合（When Generated）
このプリミティブは、ピアＭＩＨＦからＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを受信することについてのＭＩＨＦによって生成される。

【0160】

受信への影響（Effect on Receipt）
この指示を受信するＭＩＨユーザは、ソース識別子（Source Identifier）によって示されている遠隔ＭＩＨＦへのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｒｅｓｐｏｎｓｅを生成するものとする。

【0161】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｒｅｓｐｏｎｓｅ
機能：このプリミティブは、ネットワークでの遠隔ＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｑｕｅｓｔメッセージに応答するために、ＭＮ上でのＭＩＨＦによって使用される。

【0162】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Termination.response (
Destinationldentifier,
MobileNodeldentifler(optional),
Candidateldentifler(Optional),
Status,
)
パラメーター（Parameters）:

【表12】

【0163】

生成される場合（When Generated）
遠隔のＭＩＨユーザは、そのＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｉｎｄｉｃａｔｉｏｎに応じてこのプリミティブを呼び出す。

【0164】

受信への影響（Effect on Receipt）
ＭＩＨＦは、デスティネーション識別子に示されるピアＭＩＨＦへ、MIH_Pro_Auth responseメッセージを送る。

【0165】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｃｏｎｆｉｒｍ
機能：このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ｔｅｒｍｉｎａｔｉｏｎ ｒｅｓｐｏｎｓｅメッセージがピアＭＩＨＦから受信されたことを確認するために、使用される。

【0166】

サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Termination.confirm (
Sourceldentifier,
MobileNodeldentifier(Optional),
Candidateldentifier(Optional),
Status,
)
パラメーター（Parameters）:

【表13】

【0167】

生成された場合（When Generated）
このプリミティブは、ピアＭＩＨＦからMIH_Pro_Auth responseメッセージを受信するＭＩＨＦによって生成される。

【0168】

受信への影響（Effect on Receipt）
プリミティブを受信する際に、プロアクティブ認証リクエストを最初に開始するエンティティは、プロアクティブ認証を終了するか、またはプリミティブに基づいてそれを中止することを決定する。しかしながら、ステータスが「成功あるいは失敗（Success or Failure）」を示さない場合、受信者は任意の他の戻り値を無視し、代わりに、適切なエラー処理を行なう。

【0169】

ＬＩｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｒｅｑｕｅｓｔ
機能：プリミティブは、メディア特定オーセンティケータへ複数のメディア固有キーをインストールするローカルＭＩＨＦを示すために、ＭＩＨユーザによって呼び出される。

【0170】

サービスプリミティブのセマンティックス（Semantics of service primitive）
Link_Pro_Auth_Key_Install.request (
DestinationLinkldentifierwithKeys
)
パラメーター（Parameters）:

【表14】

【0171】

生成された場合（When Generated）
このプリミティブは、メディア特定オーセンティケータへ複数のキーをインストールするローカルの複数のレイヤを示すために、ＭＩＨＦによって呼び出される。

【0172】

受信への影響（Effect on Receipt）
このプリミティブの受信の際に、下位レイヤはＬｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｃｏｍｆｉｒｍプリミティブをＭＩＨＦへ生成する。

【0173】

Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｃｏｍｆｉｒｍ
機能：このプリミティブは、Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｒｅｑｕｅｓｔが受信されたことを確認するために、ＭＩＨＦによって使用される。

【0174】

サービスプリミティブのセマンティックス（Semantics of service primitive）
Link_Pro_Auth_Key_Install.confirm (
Status,
)
パラメーター（Parameters）:

【表15】

【0175】

生成された場合（When Generated）
このプリミティブは、Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｒｅｑｕｅｓｔをＭＩＨＦから受信する際に下位レイヤによって生成される。

【0176】

受信への影響（Effect on Receipt）
プリミティブを受信する際に、ＭＩＨＦは、ステータスに基づいて、複数のプロアクティブ認証状態を維持するか、またはそれを中止するかを決定する。

【0177】

キー生成アルゴリズム（Key Generation Algorithm）
・ＫＤＦ：ＲＦＣ５２４６で指定されるキー導出関数（Key derivation function）
−デフォルトＫＤＦ（すなわち、ＨＭＡＣ−ＳＨＡ−２５６に基づいたＩＫＥｖ２ ＰＲＦ＋）は、ピアＭＩＨＦ間で明示的に交渉されることなく、使用される。

【0178】

・MI-PMK = KDF(MK, "MI-PMK" | RAND_P | RAND_A | length)
−ＭＩ−ＰＭＫの長さ（Length）は６４オクテットである
−ＭＫ（マスターキー、Master Key）：ＭＳＫまたはｒＭＳＫ
−ＲＡＮＤ＿Ｐ：ピアによって生成される乱数
−ＲＡＮＤ＿Ａ：オーセンティケータによって生成される乱数
・MS-PMK =KDF(MI-PMK, "MS-PMK" | MN_LINK_ID | POA_LINK_ID | length)
−ＭＳ＿ＰＭＫの長さは各メディアに依存する。８０２．１１の場合には、長さ（Length）＝３２。

【0179】

−ＭＮ＿ＬＩＮＫ＿ＩＤ：ＬＩＮＫ＿ＩＤデータタイプとしてエンコードされる、ＭＮのリンク識別子
−ＰＯＡ＿ＬＩＮＫ＿ＩＤ：ＬＩＮＫ＿ＩＤデータタイプとしてエンコードされる、メディア特定のオーセンティケータのリンク識別子
・ＰＲＦ＋：ＩＫＥｖ２［ＲＦＣ４３０６］で指定されるキー展開
・PRF+ (K,S) = Tl | T2 | T3 | T4 | ...
・ここで：
・‘ | ’は連結（concatenation）を意味する
・T1 = PRF (K, S | 0x01)
・T2 = PRF (K, T1 | S | 0x02)
・T3 = PRF (K, T2 | S | 0x03)
・T4 = PRF (K, T3 | S | 0x04)
・...
・キー材料の要求される長さを計算する必要があるとして継続する。デフォルトＰＲＦは、ＨＭＡＣ−ＳＨＡ−２５６［ＳＨＡ２５６］として受け取られる。ＰＲＦ＋が単に２５５の反復に関して定義されるので、それは８１６０オクテット以内のキー物質を生成してもよい。

【0180】

キー分配機構（Key Distribution Mechanism）
いくつかの実施形態では、キー分配機構は、技術でのものによって確立することができる。例えば、これは規格を要求することができるか、あるいは配置仕様または実装選択として残すことができる。

【0181】

ＭＩＨプロトコルセキュリティ（MIH Protocol Security）
定義（Definition）
・ＭＩＨセキュリティアソシエーション（ＳＡ、MIH Security Association）
−ＭＩＨ ＳＡはピアＭＩＨエンティティ間でのセキュリティアソシエーションである。

【0182】

・ＭＩＨメッセージを保護するために確立された。

【0183】

−ＭＩＨ ＳＡはピアＭＩＨエンティティの認証された同一性に結び付けられる。

【0184】

・ＭＩＨプロトコル内でのＭＩＨ ＳＡ（MIH SA within MIH protocol）
−認証およびキー確立のプロトコルに関してＴＬＳを用いる。

【0185】

−ＴＬＳハンドシェイクは、ＭＩＨプロトコル上で実行される。

【0186】

−ＴＬＳは、暗号の機敏さを提供する暗号スイートネゴシエーション（cipher suites negotiation）を提供する。

【0187】

−既存の認証およびキー管理プロトコルの使用は、セキュリティの欠陥を取り込むリスクを著しく減少させるだろう。

【0188】

・利点：一旦ＭＩＨ ＳＡがＭＩＨプロトコル内に定義されると、ＭＩＨトランスポートレベルセキュリティを有する必要はない。

【0189】

ケース１：アクセス制御（Access Control）
・アクセス制御はアクセスコントローラを介して適用される。

【0190】

・アクセス制御は、認証サーバ（ＡＳ、Authentication Server）（例えばＥＡＰサーバまたはＡＡＡサーバ）を介してＭＩＨサービスプロバイダを持ったアクセス認証を通じて適用される。

【0191】

・成功した認証に際して、ＭＮは、複数のＰｏＳを介してＭＩＨサービスにアクセスすることを認められる。

【0192】

−アクセス認証は、複数のキーがＭＮと認証サーバとの間で確立されるように、キー確立手続を含む。

【0193】

ケース１の２つのシナリオ（Two Scenarios for Case 1）
・統合シナリオ：ＭＩＨサービスおよびネットワークアクセスサービスは、同じＡＳを使用する（図２０、図２１および図２２）。

【0194】

−ＭＩＨキー材料は、ネットワークアクセスサービスに関する最初またはプロアクティブな認証の間に確立されるＥＡＰキー材料からブーストラップされる。

【0195】

・分離シナリオ：ＭＩＨサービスおよびネットワークアクセスサービスは異なるＡＳを使用する（図２３）。

【0196】

−ＭＩＨキー材料は、ＭＩＨサービスに関する最初の認証中に確立されるＥＡＰキー材料からブートストラップされる。

【0197】

ケース２：アクセス制御なし（No Access Control）
・アクセス制御はどんなアクセスコントローラを介しても適用されない（図２４）。

【0198】

・相互認証は、予め共有されたキーまたは証明機関のような信頼された第３者機関に基づいてもよい。

【0199】

・認証はＭＩＨ仕様である。すなわち、相互の認証は、ある団体から別へのＭＩＨＦ同一性を保証する。

【0200】

−ＭＮおよびＰｏＳは、相互の認証および複数のＭＩＨ特定キーのキー確立を行う。

【0201】

セキュアなＭＩＨプロトコルメッセージ（Securing MIH Protocol Messages）
このセクションは、２つの利用ケースを使用してＭＩＨプロトコルメッセージセキュリティを概説する：
ｉ）ＭＩＨサービスアクセス制御が適用される場合；および
ｉｉ）セキュリティの欠陥を取り込むリスクを著しく減少させる認証およびキー管理に関する既存の複数のプロトコルを利用することによって、ＭＩＨサービスアクセス制御が適用されない場合。

【0202】

アプローチ（Approach）
アプローチは以下のステップからなる：
・ＭＩＨサービス認証に関するＭＩＨプロトコル上でＥＡＰを使用する。この場合、ＰｏＳはオーセンティケータとして働き、さらにＡＡＡクライアントを実行する。

【0203】

・認証、キー確立、および暗号化に関して、ＴＬＳ［ＲＦＣ５２４６］あるいはＤＴＬＳ［ＲＦＣ４３４７］を使用する。ＴＬＳハンドシェイクはＭＩＨプロトコル上に行なわれ、ＭＩＨ ＳＡは２つのＭＩＨＦピアの間で確立される。（Ｄ）ＴＬＳは暗号スイートネゴシエーション（cipher suites negotiation）を提供するだろう。一旦ＭＩＨ ＳＡがＭＩＨプロトコル内で定義されれば、ＭＩＨトランスポートレベルセキュリティを有する必要はない。

【0204】

アクセス制御を有したＭＩＨセキュリティ使用の場合（MIH Security Use case with access control）
ＭＩＨサービスアクセス制御はアクセスコントローラを介して適用される。アクセス制御は、認証サーバ（Authentication Server、ＡＳ）（例えばＥＡＰサーバまたはＡＡＡサーバ）を介してＭＩＨサービスプロバイダを持ったアクセス認証を通じて適用される。成功した認証に際して、ＭＮは、ＰｏＳを介してＭＩＨサービスにアクセスする権限を与えられる。複数のキーがＭＮと認証サーバ（Authentication Server）との間で確立されるように、アクセス認証はキー確立手続きを含んでいる。プロアクティブ認証が支援される場合、複数のＭＩＨサービスに関する認証およびプロアクティブ認証は同じＡＳを用いる。

【0205】

コールフロー（Call Flows）
図２２は、ＭＩＨサービスアクセス制御が適用され、次に、ＭＩＨ ＳＡが、成功した認証の後にブートストラップされる場合、コールフローを説明する。

【0206】

アクセス制御のないＭＩＨセキュリティ使用の場合（MIH Security Use Case without Access Control）
ＭＩＨサービスアクセス制御はどんなアクセスコントローラを介しても適用されない。相互の認証は、予め共有されているキーあるいは証明機関のような信頼できる第三者機関に基づいていてもよい。認証はＭＩＨ仕様である。ＭＮとＰｏＳは、ＭＩＨ特定キーの相互の認証およびキー確立を行うだろう。図２４は、ＭＩＨサービスへの任意のアクセス制御で、ＭＩＨセキュリティコールフローを記述する。

【0207】

セキュリティ性能発見（Security Capability Discovery）
次のセキュリティ関連の性能はＭＩＨ性能発見のために定義される。

【0208】

・データタイプ：MIH_SEC_CAP
・ＢＩＴＭＡＰ（１６）から導かれる：
○ビット０：直接の事前認証
○ビット１：非直接の事前認証
○ビット２：直接の再認証
○ビット３：非直接の再認証
○ビット４：アクセス制御を有するＭＩＨ ＳＡ
○ビット５：アクセス制御なしのＭＩＨ ＳＡ
○ビット６−１５：未使用
次のパラメーターはＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒ．｛ｒｅｑｕｅｓｔ，ｒｅｓｐｏｎｓｅ｝プリミティブに加えられる：

【表16】

【0209】

次のパラメーターはＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒ．｛ｉｎｄｉｃａｔｉｏｎ，ｃｏｎｆｉｒｍ｝プリミティブに加えられる。

【表17】

【0210】

キー階層および導出（Key Hierarchy and Derivation）
ＭＩＨ ＳＡに関するキー階層は図２５および２６に例証される。ＭＩＨサービスのためのアクセス制御が可能になる場合、（Ｄ）ＴＬＳ ＰＳＫは、ＥＡＰピアを演じるＭＩＨＦとＥＡＰサーバとの間で生成され、ＥＡＰオーセンティケータを演じる別のＭＩＨＦにトランスポートされるＭＳＫあるいはｒＭＳＫから導かれる。導出されるＰＳＫは、ＭＩＨＦピアを相互に認証しかつ複数のＭＩＨメッセージを（Ｄ）ＴＬＳを使用して保護するための（Ｄ）ＴＬＳキー材料を確立するために、（Ｄ）ＴＬＳハンドシェイクに関する（Ｄ）ＴＬＳ信用証明物になる。ＰＳＫは以下のように導出される：
PSK = KDF(MK, "TLS-PSK" | RAND_P | RAND_A | length)
ＭＫ（マスターキー、Master Key）は、ＥＡＰまたはＥＲＰがアクセス認証に用いられるかどうかに依存するｒＭＳＫかＭＳＫのいずれかである。ＲＡＮＤ＿Ｐは、ＥＡＰピアを演じるＭＩＨＦによって生成された乱数である。ＲＡＮＤ＿Ａは、ＥＡＰオーセンティケータを演じるＭＩＨＦによって生成された乱数である。長さはオクテットでＰＳＫの長さである。デフォルトの長さは６４である。ＫＤＦは［ＲＦＣ５２９５］に定義されたキー導出関数である。デフォルトＫＤＦ、つまりＨＭＡＣ−ＳＨＡ−２５６に基づいたＩＫＥｖ２ ＰＲＦ＋は、ピアＭＩＨＦ間で明示的にネゴーシエイトしないならば用いられる。

【0211】

ＭＩＨサービスのためのアクセス制御が可能にならない場合（ケース２を用いる）、予め構成されたＴＬＳ信用証明物は、ＭＩＨＦピアを相互に認証しかつ複数のＭＩＨメッセージを（Ｄ）ＴＬＳを使用して保護するための（Ｄ）ＴＬＳキー材料を確立するために、（Ｄ）ＴＬＳハンドシェイクに用いられる。図２５および２６はＭＩＨ ＳＡに関するキー階層である。

【0212】

ＭＩＨプロトコル拡張（MIH Protocol Extensions）
ＴＬＳまたはＤＴＬＳはＭＩＨプロトコルを安全にするために用いられる。この場合での（Ｄ）ＴＬＳのためのトランスポートプロトコルはＭＩＨプロトコル自体である。ＭＩＨプロトコルトランスポートが信頼できる場合、ＴＬＳが用いられる。そうでなければ、ＤＴＬＳが用いられる。ＴＬＳセッションに関連する複数のトランスポートプロトコルエンティティは、複数のＭＩＨＦピアであり、複数のＭＩＨＦ識別子によって識別される。したがって、ＭＩＨＦのトランスポートアドレスは、ＭＩＨＦのＭＩＨＦ識別子とトランスポートアドレスとの間のマッピングが維持される限り、ＴＬＳセッションの寿命を切り替えることができる。次のサブセクションは、（Ｄ）ＴＬＳの使用のためのＭＩＨプロトコルへの拡張について記述する。

【0213】

ＴＬＳ ＴＬＶ
ＴＬＳ（Transport Layer Security、トランスポートレイヤセキュリティ）ＴＬＶは、（Ｄ）ＴＬＳメッセージを伝えるタイプＯＣＴＥＴ＿ＳＴＲＩＮＧの新しいＴＬＶである。一旦、ＭＩＨ ＳＡが確立されれば、ソースおよびデスティネーションＭＩＨＦ識別子（Source and Destination MIHF Identifier）ＴＬＶｓを除外する全部の未加工のＭＩＨ ＰＤＵは、ＭＩＨ ＳＡのＴＬＳキー材料で保護されなければならず、さらにＴＬＳ応用データとしてＴＬＳ ＴＬＶのペイロードで伝えられなければならない。

【0214】

セッションＩＤ ＴＬＶ（Session ID TLV）
セッションＩＤ（識別子）ＴＬＶは、ＴＬＳハンドシェイクの結果として割り当てられる（Ｄ）ＴＬＳセッション識別子［ＲＦＣ ５２４６］を伝えるタイプＯＣＴＥＴ＿ＳＴＲＩＮＧの新しいＴＬＶである。

【0215】

セキュリティ性能ＴＬＶ（Security Capability TLV）
セキュリティ性能ＴＬＶは、ＭＩＨＦのセキュリティ性能を伝えるタイプＭＩＨ＿ＳＥＣ＿ＣＡＰの新しいＴＬＶである。このＴＬＶは、ＭＩＨ＿Ｃａｐａｂｉｌｉｔｙ＿Ｄｉｓｃｏｖｅｒリクエストおよび応答メッセージで伝えられる。

【0216】

ＭＩＨセキュリティＰＤＵ（MIH Security PDU）
ＭＩＨセキュリティ（ＭＩＨＳ）ＰＤＵは、ＭＩＨＳヘッダーを有するＭＩＨ ＰＤＵであり、続いてオプションのソースおよびデスティネーションのＭＩＨＦ−ＩＤ ＴＬＶｓがあり、続いてオプションのセッションＩＤ ＴＬＶがあり、続いてＴＬＳ ＴＬＶがある。ＭＩＨＳヘッダーは次の情報を含んでいるＭＩＨプロトコルヘッダである。

【0217】

・バージョン（Version）：ＭＩＨプロトコルのバージョン
・Ａｃｋ−Ｒｅｑ：０
・Ａｃｋ−Ｒｓｐ：０
・ＵＩＲ：０
・Ｍ：０
・ＦＮ：０
・ＳＩＤ：５（セキュリティサービス、Security Service）
・Ｏｐｃｏｄｅ：２（指示、Indication）
・ＴＩＤ：０
セッションＩＤ ＴＬＶは、ＭＩＨ ＳＡに関連したペアのＭＩＨＦに関係している。したがって、ソースおよびデスティネーションのＭＩＨＦ識別子ＴＬＶｓは、ＭＩＨ ＳＡの存在でのＭＩＨＳ ＰＤＵで伝えられる必要はなく、セッションＩＤ ＴＬＶは代わりに伝えられる。ソースおよびデスティネーションのＭＩＨＦ識別子ＴＬＶｓは、ＭＩＨ ＳＡがない状態、あるいは、送り手のトランスポートアドレスが変更された場合、ＭＩＨＳ ＰＤＵで伝えられる。後者の場合では、送信者のトランスポートアドレスとＭＩＨＦ識別子との間のマッピングは更新され、またＭＩＨ登録リクエストまたは応答メッセージはＴＬＳ ＴＬＶに含まれていてもよい。ＴＬＳハンドシェイクの間でのＭＩＨＳ ＰＤＵの構造は図２７に示される。ＭＩＨ ＳＡの存在でのＭＩＨＳ ＰＤＵの構造は、図２８に示される。トランスポートアドレス変更（Transport Address Change）でのＭＩＨＳ ＰＤＵの構造は図２９に示される。図２７はＴＬＳハンドシェイクの間でのＭＩＨＳ ＰＤＵを示す。図２８はＭＩＨ ＳＡの存在でのＭＩＨＳ ＰＤＵを示す。図２９は、トランスポートアドレス変更（Transport Address Change）でのＭＩＨＳ ＰＤＵを示す。

【0218】

ＭＩＨプロトコルメッセージ（MIH Protocol Messages）
メッセージタイプ（Message Types）
テーブル４は新しいＭＩＨメッセージタイプ［ＩＥＥＥ８０２．２１］を一覧表にしている。

【0219】

テーブル４：ＭＩＨ新しいメッセージタイプ（MIH New Message Types）

【表18】

【0220】

テーブル５は、拡張を必要とするメッセージを一覧表にしている。

【0221】

テーブル５：ＭＩＨメッセージ拡張（MIH Message Extension）

【表19】

【0222】

テーブル５での複数のメッセージについては、付加的な支援されたセキュリティキャップリスト（Supported Security Cap List）パラメーターは、タイプＭＩＨ＿ＳＥＣ＿ＣＡＰのセキュリティ性能リスト（Security Capability List）ＴＬＶで伝えられる。

【0223】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈリクエスト（MIH_Pro_Auth Request）

【表20】

【0224】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ応答（MIH_Pro_Auth Response）

【表21】

【0225】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ指示（MIH_Pro_Auth Indication）

【表22】

【0226】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎリクエスト

【表23】

【0227】

ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ応答

【表24】

【0228】

ＭＩＨ＿セキュリティ指示（MIH_Security Indication）

【表25】

【0229】

発明の例証となる実施形態がここに説明されかつ記述される一方、本発明は、様々な好ましいここで記述される実施形態に制限されず、本開示（例えばプロアクティブ認証が、下位レイヤおよび（または）ＭＩＨレイヤを使用してパラメーターを伝えるメディア特定オーセンティケータを介して発生することができる）に基づく技術でのものによって評価されるように、等価な要素、修正、省略、組合せ（例えば様々な実施形態に渡る態様の）、適応および（または）変更を有する任意かつ全ての実施形態を含んでいる。クレームでの（例えば、後で加えられるものを含んだ）限定は、クレームで使用され、現在の仕様に、あるいはアプリケーション（非独占的なものとして解釈されるために例はそれである）の遂行の間に述べられていた例に制限がない。クレームで使用される言語に基づいて広く解釈され、かつ本明細書にまたは出願の審査の間に、記述される複数の例に限定されないことになっている。複数の例は、非独占的に構成されている。例えば、現在の開示では、用語「好ましくは」は非独占的であり、「好ましくは、しかしこれに限定されない」を意味する。この開示およびこの出願の審査中では、ミーンズプラスファンクションまたはステッププラスファンクションの限定は、特定のクレーム限定に関して次の複数の条件の全てがその限定に現れる場合に、使用されるだけである：ａ）「手段」または「ステップ」が明確に記載され；ｂ）対応する機能が明確に記載され；およびｃ）その構造をサポートする構造、材料または動作が記載されていない。この開示およびこの出願の審査中では、用語「本発明」または「発明」は、本開示内での１以上の態様への参照文献として使用されてもよい。本発明または発明が重大さの識別として不適切に解釈されるべきでない言語は、全ての態様または実施形態に渡って適用されると不適切に解釈されるべきではなく（（すなわち、本発明が多くの態様および実施形態を有していると理解されるべきである）、出願またはクレームの範囲を限定するように不適切に解釈されるべきではない。この開示およびこの出願の審査中では、用語「実施形態」は、任意の態様、特徴、プロセスまたはステップ、それらの任意の組合せ、および／またはそれらの任意の部分を記述することに使用されうる。いくつかの例において、様々な実施形態は特徴をオーバーラップさせることを含んでいてもよい。この開示では、次の略した用語が使用されてもよい：「例えば（e.g.）」は「例えば（for example）」を意味する。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】