(57)【要約】【課題】サービスフローの暗号化処理方法及びシステムを提供する。【解決手段】該方法は、認証・認可・アカウンティング（ＡＡＡ）サーバがＡＡＡクライアント側に、サービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信し（Ｓ１０２）、ＡＡＡクライアント側が、サービスフロー認可アンカー（アンカーＳＦＡ）に指示情報を送信し（Ｓ１０４）、アンカーＳＦＡが、指示情報を基地局に送信し（Ｓ１０６）、基地局が、指示情報に基づいてサービスフローに暗号化処理を行うか、又は非暗号化処理を行う（Ｓ１０８）ステップを含む。本発明の方法及びシステムによると、ユーザ情報及びＱｏＳ属性に基づくサービスフローのセキュリティ要請の配置を実現できる。【選択図】図１
2013512631.tif 000002
【特許請求の範囲】
【請求項１】
認証・認可・アカウンティング（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ａｃｃｏｕｎｔｉｎｇ  Ｓｅｒｖｅｒ、以下、ＡＡＡと略称）サーバが、ＡＡＡクライアントに、サービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信し、
前記ＡＡＡクライアントが、サービスフロー認可アンカー（Ａｎｃｈｏｒ  Ｓｅｒｖｉｃｅ  Ｆｌｏｗ  Ａｕｔｈｏｒｉｚａｔｉｏｎ、以下、アンカーＳＦＡと略称）に前記指示情報を送信し、
前記アンカーＳＦＡが、前記指示情報を基地局に送信し、
前記基地局が、前記指示情報に基づいて前記サービスフローに暗号化処理を行うか、又は非暗号化処理を行うステップを含むことを特徴とするサービスフローの暗号化処理方法。
【請求項２】
前記ＡＡＡサーバが前記ＡＡＡクライアントに前記指示情報を送信するステップは、
前記ＡＡＡサーバがアクセス許可（Ａｃｃｅｓｓ  Ａｃｃｅｐｔ）メッセージに前記指示情報を含ませるステップと、
前記ＡＡＡサーバが前記アクセス許可メッセージを前記ＡＡＡクライアントに送信するステップと、を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＡＡＡサーバが前記アクセス許可メッセージに前記指示情報を含ませるステップは、
前記アクセス許可メッセージのサービス品質記述子（ＱｏＳ−Ｄｅｓｃｒｉｐｔｏｒ）の「タイプ／長さ／数値」フォーマットのサブＴＬＶに、前記サービスフローに暗号化処理を行う必要があるか否かを指示するＴＬＶを追加するステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記ＡＡＡクライアントが前記アンカーＳＦＡに前記指示情報を送信するステップは、
前記ＡＡＡクライアントがリソース予約要請（ＲＲ−Ｒｅｑ）メッセージのサービスフローパラメータに前記指示情報を含ませるステップと、
前記ＡＡＡクライアントが前記ＲＲ−Ｒｅｑメッセージを前記アンカーＳＦＡに送信するステップと、を含むことを特徴とする請求項１又は３に記載の方法。
【請求項５】
前記アンカーＳＦＡが前記指示情報を前記基地局に送信するステップは、
前記アンカーＳＦＡが前記基地局に送信するデータルート登録要請（Ｐａｔｈ＿Ｒｅｇ＿Ｒｅｑ）メッセージのサービスフローパラメータに前記指示情報を含ませるステップを含むことを特徴とする請求項１又は３に記載の方法。
【請求項６】
前記基地局が前記指示情報に基づいて前記サービスフローに暗号化処理を行うステップは、
前記基地局が一つのセキュリティアライアンス（ＳＡ）を確定し、
前記基地局が前記ＳＡのマークＩＤ（ＳＡ−ＩＤ）と前記サービスフローを関連付け、前記サービスフローに関連付けられたＳＡのＳＡ−ＩＤを移動局に送信し、
前記基地局及び／又は移動局が前記ＳＡ−ＩＤに対応するＳＡを用いて前記サービスフローのデータストリームに暗号化処理及び／又は復号化処理を行うステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
ＡＡＡクライアントにサービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信するＡＡＡサーバと、
アンカーＳＦＡに前記指示情報を送信する前記ＡＡＡクライアントと、
前記指示情報を基地局に送信する前記アンカーＳＦＡと、
前記指示情報に基づいてサービスフローに暗号化処理を行うか、又は非暗号化処理を行う前記基地局と、を有することを特徴とするサービスフロー暗号化処理システム。
【請求項８】
前記ＡＡＡサーバが、
アクセス許可メッセージに前記指示情報を設定する第１の設定ブロックと、
前記アクセス許可メッセージを前記ＡＡＡクライアントに送信する第１の送信ブロックと、を有することを特徴とする請求項７に記載のシステム。
【請求項９】
前記第１の設定ブロックが、
前記アクセス許可メッセージのサービス品質記述子のサブＴＬＶに、前記サービスフローに暗号化処理を行う必要があるか否かを指示するＴＬＶを追加することを特徴とする請求項８に記載のシステム。
【請求項１０】
前記ＡＡＡクライアントが、
リソース予約要請メッセージのサービスフローパラメータに前記指示情報を含ませる第２の設定ブロックと、
前記リソース予約要請メッセージを前記アンカーＳＦＡに送信する第２の送信ブロックと、を有することを特徴とする請求項７又は９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信分野に関し、具体的には、サービスフローの暗号化処理方法及びシステムに関する。
【背景技術】
【０００２】
ワイマックス（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ、以下ＷｉＭＡＸと略称）は、新時代のブロードバンド無線アクセス技術として完全なセキュリティメカニズムを提供して経営者（プロバイダ）とユーザの利益を保証している。例えば、８０２．１６ｅプロトコルは、エアーによるデータ暗号化伝送メカニズムを提供し、開放式の無線環境でのデータ伝送の秘密性を保証し、敏感な情報の違法盗用を防止できる。
【０００３】
ＷｉＭＡＸシステムにおけるデータのエアーにおける伝送は、接続に基づくもので、各接続は特定のサービス品質（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ、以下ＱｏＳと略称）属性を有している。各アクティブのサービスフローとサービス伝送接続は逐一対応する。サービスフローのＱｏＳ属性は、アクセスする際に、認証・認可・アカウンティング（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ａｃｃｏｕｎｔｉｎｇ、以下ＡＡＡと略称）サーバ（Ｓｅｒｖｅｒ）によって割り当てられて基地局（Ｂａｓｅ  Ｓｔａｔｉｏｎ、以下ＢＳと略称）に送信され、ＢＳがサービスフローを構築する際に用いられる。
ユーザの或るサービスフローに対するセキュリティ要求が高い場合、データを暗号化して伝送しなければならず、例えば、予め二つのベストエフォート（Ｂｅｓｔ  Ｅｆｆｏｒｔ、以下ＢＥと略称）サービスフローが配置されたユーザＡと、予め二つのアンソリシテッドグラントサービス（Ｕｎｓｏｌｉｃｉｔｅｄ  Ｇｒａｎｔ  Ｓｅｒｖｉｃｅ、以下ＵＧＳと略称）サービスフローが配置されたユーザＢの場合、ユーザＡの方のデータのエアー伝送におけるセキュリティ要求が高く、ユーザＢは要求がない。又は、予め複数のサービスフローが配置されたユーザＣ（ＢＥとＵＧＳを含む）の場合、そのＵＧＳサービスを伝送するデータに高いセキュリティが要求され、ＢＥサービスフローで伝送するデータについてはセキュリティ要求がない。
【０００４】
既存のＮＷＧネットワークプロトコルにおいて、Ｒ３とＲ６メッセージインターフェースにおいてサービスフローのセキュリティ要求を説明しないので、接続に基づき暗号化データ伝送需要を実現するのに不便である。サービスフロー（接続）のセキュリティ要求がＢＳに説明又は配置されている場合、ＢＳは分布式のアクセス点として、ユーザ情報及びその接続のＱｏＳ属性を把握していないので、基地局はユーザの情報及びＱｏＳ属性に基づいて特定のユーザの特定のサービスフローのセキュリティ要求を配置することができない。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、従来の関連技術において基地局がユーザの情報及びＱｏＳ属性に基づいてサービスセキュリティ要求を配置できないという問題に鑑みなされたものであり、このような問題を解決できるサービスフローの暗号化処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を実現するために、本発明の一態様によると、サービスフローの暗号化処理方法を提供する。
本発明によるサービスフローの暗号化処理方法は、ＡＡＡサーバがＡＡＡクライアントに、サービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信し、ＡＡＡクライアントが、アンカーＳＦＡに指示情報を送信し、アンカーＳＦＡが、指示情報を基地局に送信し、基地局が、指示情報に基づいてサービスフローに暗号化処理を行うか、又は非暗号化処理を行うステップを含む。
【０００７】
ＡＡＡサーバがＡＡＡクライアントに指示情報を送信するステップは、ＡＡＡサーバがアクセス許可（Ａｃｃｅｓｓ  Ａｃｃｅｐｔ）メッセージに指示情報を含ませるステップと、ＡＡＡサーバがアクセス許可メッセージをＡＡＡクライアントに送信するステップと、を含むことが好ましい。
【０００８】
ＡＡＡサーバがアクセス許可メッセージに指示情報を含ませるステップは、アクセス許可メッセージのサービス品質記述子（ＱｏＳ−Ｄｅｓｃｒｉｐｔｏｒ）の「タイプ／長さ／数値」フォーマットのサブＴＬＶに、サービスフローに暗号化処理を行う必要があるか否かを指示するＴＬＶを追加するステップを含むことが好ましい。
【０００９】
ＡＡＡクライアントがアンカーＳＦＡに指示情報を送信するステップは、ＡＡＡクライアントがリソース予約要請（ＲＲ−Ｒｅｑ）メッセージのサービスフローパラメータに指示情報を含ませるステップと、ＡＡＡクライアントがＲＲ−ＲｅｑメッセージをアンカーＳＦＡに送信するステップと、を含むことが好ましい。
【００１０】
アンカーＳＦＡが指示情報を基地局に送信するステップは、アンカーＳＦＡが基地局に送信するデータルート登録要請（Ｐａｔｈ＿Ｒｅｇ＿Ｒｅｑ）メッセージのサービスフローパラメータに指示情報を含ませるステップを含むことが好ましい。
【００１１】
基地局が指示情報に基づいてサービスフローに暗号化処理を行うステップは、基地局が一つのセキュリティアライアンス（ＳＡ）を確定し、基地局がＳＡのマークＩＤ（ＳＡ−ＩＤ）とサービスフローを関連付け、サービスフローに関連付けられたＳＡのＳＡ−ＩＤを移動局に送信し、基地局及び／又は移動局がＩＤに対応するＳＡを用いてサービスフローのデータストリームに暗号化処理及び／又は解読処理を行うステップを含むことが好ましい。
【００１２】
上記目的を実現するため、本発明の他の一態様によると、サービスフローの暗号化処理システムを提供する。
本発明によるサービスフロー暗号化処理システムは、ＡＡＡクライアントにサービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信するＡＡＡサーバと、アンカーＳＦＡに指示情報を送信するＡＡＡクライアントと、指示情報を基地局に送信するアンカーＳＦＡと、指示情報に基づいてサービスフローに暗号化処理を行うか、又は非暗号化処理を行う基地局と、を有する。
【００１３】
ＡＡＡサーバが、アクセス許可メッセージに指示情報を設定する第１の設定ブロックと、アクセス許可メッセージをＡＡＡクライアントに送信する第１の送信ブロックと、を有することが好ましい。
【００１４】
第１の設定ブロックが、アクセス許可メッセージのサービス品質記述子のサブＴＬＶに、サービスフローに暗号化処理を行う必要があるか否かを指示するＴＬＶを追加することが好ましい。
【００１５】
ＡＡＡクライアントが、ＲＲ−Ｒｅｑメッセージのサービスフローパラメータに指示情報を含ませる第２の設定ブロックと、ＲＲ−ＲｅｑメッセージをアンカーＳＦＡに送信する第２の送信ブロックと、を有することが好ましい。
【発明の効果】
【００１６】
本発明によると、従来関連技術において基地局がユーザの情報及びＱｏＳ属性に基づいてサービスフローセキュリティ要求を配置できないという問題を解決し、ユーザ情報及びＱｏＳ属性に基づくサービスフローのセキュリティ要求の配置を実現できる。
本発明の他の特徴及びメリットは明細書における説明からさらに明確になり、又は本発明を実施することによって把握できるであろう。本発明の目的及び他のメリットは、明細書、特許請求の範囲、図面に特別に指摘された構造によって実現できる。
【図面の簡単な説明】
【００１７】
ここで説明する図面は、本発明を理解させるためのものであり、本発明の一部を構成し、本発明における実施例と共に本発明を解釈するためのものであって、本発明を不当に限定するものではない。図面において、
【図１】は、本発明の実施例に係るサービスフローの暗号化処理方法を示すフローチャートである。
【図２】は、本発明の実施例に係る暗号化されたサービスフローの構築を示すフローチャートである。
【図３】は、本発明の実施例に係るサービスフローの暗号化処理システムの構造を示すブロック図である。
【発明を実施するための形態】
【００１８】
ここで、互いに矛盾しない限り、本願に記載の実施例及び実施例に記載の特徴を互いに組み合わせることができる。以下、図面を参照しつつ実施例を結合して本発明を詳しく説明する。
【００１９】
以下の実施例において、図面におけるフローチャートに示すステップを例えばコンピューターによりコマンドの実行可能な１セットのコンピューターシステムにおいて実行でき、また、フローチャートには或るロジック順を示しているが、場合によっては他の順で図面に示した、又は説明したステップを実行できる。
【００２０】
本実施例において、サービスフローの暗号化方法を提供し、図１は、本発明の実施例に係るサービスフローの暗号化方法を示すフローチャートであり、図１に示すように、以下のステップＳ１０２〜ステップＳ１０８を含む。
【００２１】
ＡＡＡサーバは、ＡＡＡクライアントにサービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信する（ステップＳ１０２）。
【００２２】
ＡＡＡサーバ自体がユーザのＱｏＳ情報を記録する集中点であるので、ここで、ＡＡＡサーバに記録された情報に基づいてサービスに暗号化処理を行う必要があるか否かを設定できる。なお、ＡＡＡクライアントは、ＡＡＡサーバと相互に作用するブロックを、サービスフロー認可アンカー（Ａｎｃｈｏｒ  Ｓｅｒｖｉｃｅ  Ｆｌｏｗ  Ａｕｔｈｏｒｉｚａｔｉｏｎ、以下、アンカーＳＦＡと略称）の内部に設定できるが、他のネットワーク要素に設定することもできる。
【００２３】
ＡＡＡクライアントは、アンカーＳＦＡ（又は、アンカーデータルート機能エンティティ、略して、アンカーＤＰＦとも呼ばれる）に指示情報を送信する（ステップＳ１０４）。
【００２４】
アンカーＳＦＡは、当該指示情報を基地局に送信する（ステップＳ１０６）。
【００２５】
基地局は、当該指示情報に基づいて、サービスフローに暗号化処理を行うか、又は非暗号化処理を行う（ステップＳ１０８）。
【００２６】
上記ステップによって、ＡＡＡサーバにてサービスフローのセキュリティ要求を配置して基地局に送信することによって、従来関連技術において基地局がユーザの情報とＱｏＳ属性に基づいてサービスフローのセキュリティ要求を配置することができないという問題を解決した。
【００２７】
以下、サービスフローに暗号化処理を行う必要がある場合を例に、サービスフローの構築フローを結合して上記ステップを説明するが、以下の実施例は好適の実施例に過ぎない。
【００２８】
図２は、本発明の実施例に係る暗号化したサービスフローの構築を示すフローチャートで、図２に示すように、以下のステップを含む。
【００２９】
初期の拡張認証プロトコル（Ｅｘｔｅｎｓｉｂｌｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ、以下ＥＡＰと略称）の認証に成功した後、ＡＡＡサーバはＡＡＡクライアントにＲ３アクセス許可（Ａｃｃｅｓｓ  Ａｃｃｅｐｔ）メッセージを送信し（ステップＳ２０１）、該メッセージはサービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を含み、その中、ＡＡＡクライアントを認証者（Ａｕｔｈｅｎｔｉｃａｔｏｒ）とも呼ぶ。
【００３０】
ＡＡＡサーバがアクセス許可メッセージを介してＡＡＡクライアントにサービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を送信することができれば、他のメッセージ、例えば、新規に定義されたメッセージを介して該指示情報を送信できることが好ましい。ここで、アクセス許可メッセージは指示情報を含むことの可能のメッセージの例であり、これに限定されず、サービスフローに暗号化処理を行う必要があるか否かを指示する指示情報を含むことのできるメッセージであれば、いずれも同じ作用は果たす。アクセス許可メッセージを用いるとさらに容易である。
【００３１】
アクセス許可メッセージが上記指示情報を含む場合、アクセス許可メッセージのサービス品質記述子（ＱｏＳ−Ｄｅｓｃｒｉｐｔｏｒ）のサブＴＬＶに新しいＴＬＶセキュリティ・レベル（Ｓｅｃｕｒｉｔｙ  Ｌｅｖｅｌ）（通信分野において、「データタイプ、データ長さ、データ数値」の形にデータ形式をフォーマット化したものを英語で「Ｔｙｐｅ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ」と表し、ＴＬＶフォーマットと略称する）を追加でき、そのサイズは１ビットである。セキュリティ・レベルの意味は表１を参照することができ、０はユーザが当該サービスフローにて伝送するデータにセキュリティ要求がないことを示し、１はユーザが当該サービスフローにて伝送するデータにセキュリティ要求があることを示す。なお、当該メッセージにおける他のビットによってサービスフローに暗号化処理を行う必要があるか否かを指示することができる。以下、ＴＬＶセキュリティ・レベルを例に説明する。
【００３２】
【表１】
2013512631.tif 000003
【００３３】
本実施例をさらに説明するため、まず、セキュリティアライアンス（Ｓｅｃｕｒｉｔｙ  Ａｌｌｉａｎｃｅ、以下ＳＡと略称）トラフィック暗号化キー（Ｔｒａｆｆｉｃ  Ｅｎｃｒｙｐｔｉｏｎ  Ｋｅｙ、以下ＴＥＫと略称）について説明する。
【００３４】
ＳＡ−ＴＥＫの３ウェイハンドシェイク段階において、移動局（Ｍｏｂｉｌｅ  Ｓｔａｔｉｏｎ、以下ＭＳと略称）とＢＳは協議して暗号化属性を有するセキュリティアライアンスＳＡを生成し、その中、データ暗号化タイプ（ｄａｔａ  ｃｒｙｐｔ  Ｔｙｐｅ）において暗号化・復号化メカニズムを説明している。ＭＳはキー要請（Ｋｅｙ−Ｒｅｑｕｅｓｔ）、キー応答（Ｋｅｙ−Ｒｅｐｌｙ）メッセージを介して当該ＳＡのＴＥＫ交換を完成し、成功した後、ＭＳとＢＳは同一のＴＥＫキーを有する。ＴＥＫは、サービスフローデータを暗号化・復号化するキーである。
【００３５】
サービスフローの構築段階において、認証者（ＡＡＡクライアント）はＲＲ＿Ｒｅｑ（リソース予約要請）メッセージをアンカーＳＦＡ（以下、単にＳＦＡともいう）に送信し（ステップＳ２０２）、ＲＲ＿Ｒｅｑの各サービスフローパラメータは新しく追加されたＴＬＶセキュリティ・レベルを含む。ここで、該ステップにおいて、認証者は、ＲＲ＿Ｒｅｑメッセージに各サービスフローに暗号化処理を行う必要があるか否かを指示する指示情報（ＴＬＶセキュリティ・レベルは当該指示情報の例に過ぎない）を含めることができるが、他のメッセージに上記指示情報を含めることもできる。
【００３６】
ＳＦＡはデータルート登録要請（Ｐａｔｈ＿Ｒｅｇ＿Ｒｅｑ）メッセージをＢＳに送信し（ステップＳ２０３）、Ｐａｔｈ＿Ｒｅｇ＿Ｒｅｑにおける各サービスフローパラメータにＴＬＶセキュリティ・レベルが新しく追加される。該ステップにおいて、ＳＦＡはＰａｔｈ＿Ｒｅｇ＿Ｒｅｑメッセージに上記指示情報を含めることができるが、他のメッセージに上記指示情報を含めることもでき、本実施例において、Ｐａｔｈ＿Ｒｅｇ＿Ｒｅｑメッセージはその解釈例に過ぎない。
【００３７】
各サービスフローにおけるセキュリティ・レベル値について、セキュリティ・レベルが０である場合、該サービスフローにて伝送するデータに暗号化処理を行う必要がないことを示すので、該サービスフローに暗号化属性のセキュリティアライアンスＳＡを関連つける必要がなく、ＢＳからＭＳに向けて発信するＤＳＡ＿ＲｅｑにおけるＳＡのマークＩＤ（ＳＡ−ＩＤ）が０ｘＦＦＦＦ（暗号化されたＳＡと関連つけないことを示す）である。一方、セキュリティ・レベルが１である場合、該サービスフローにて伝送するデータに対するセキュリティ要求があることを示すので、暗号化して伝送しなければならない（ステップＳ２０４）。ＢＳは対策に基づいて、３ウェイハンドシェイク段階から協議して生成したＳＡからデータ暗号化タイプ（Ｄａｔｅ  Ｃｒｙｐｔ  Ｔｙｐｅ）が０ではないＳＡを選択し、そのＳＡ−ＩＤを該サービスフローと関連付け、ＤＳＡ＿Ｒｅｑメッセージを介してＭＳに知らせる。
【００３８】
セキュリティ属性のあるサービスフローを構築する他のステップは、既存のサービスフローの構築過程と一致するので、説明を省略する。その後、ＢＳがセキュリティ要求のある（即ち、暗号化処理が必要な）サービスフローのデータストリームを受信すると、当該サービスフローに関連付けられたＳＡ（対応するＴＥＫを含む）を調査し、その後、該ＳＡにおけるデータ暗号化タイプ（ｄａｔａ  ｃｒｙｐｔ  ｔｙｐｅ）により指定された暗号化アルゴリズムを用い、ＴＥＫ暗号化媒体データを採用し、ＭＡＣ  ＰＤＵを組み込み、ＰＤＵヘッドにおけるＥＣのビットを１に設定して該ＭＡＣ  ＰＤＵが暗号化後のものであることを示し、エアーを介してＭＳに送信する。ＭＳはＭＡＣ  ＰＤＵを受信した後、ＥＣのビットが１であると認識し、暗号化されたパケットであると判定する。ＰＤＵヘッドにおける接続情報に基づいて対応するＳＡを調査し、ＳＡにおけるデータ暗号化タイプによって指定される解読アルゴリズムによって、ＴＥＫ復号媒体データを用いる。同じ理由で、ＭＳはセキュリティ要求のあるサービスフローのデータストリームを受信した場合、類似の処理を行うことができるので、説明を省略する。
【００３９】
上記ステップＳ２０１〜ステップＳ２０４によって、ネットワーク要素ＡＡＡサーバにおいて、各サービスフローパラメータに配置されるセキュリティ・レベルによって、エアー伝送するデータに暗号化方式で伝送する必要があるか否かが決められる。ＡＡＡサーバにおいて、経営者はユーザに対して特定のＱｏＳ属性を配置することができ、同様にユーザの接続に基づいて特定のセキュリティ属性を配置することができる。
【００４０】
上記実施例に対応し、サービスフローの暗号化処理システムを提供し、上述において説明した内容の説明は省略する。該システムは、ＡＡＡサーバと、ＡＡＡクライアントと、アンカーＳＦＡと、基地局とを有し、該システムにおいて、ＡＡＡサーバはＡＡＡクライアントに、サービスフローに対する暗号化処理を行う必要があるか否かを指示する指示情報を送信する。ＡＡＡクライアントは、アンカーＳＦＡに指示情報を送信する。アンカーＳＦＡは、指示情報を基地局に送信する。基地局は、指示情報に基づいて、サービスフローに暗号化処理を行う、又は非暗号化処理を行う。
【００４１】
図３は、本発明の実施例に係るサービスフローの暗号化処理システムの構造を示すブロック図で、図３に示すように、ＡＡＡサーバは、アクセス許可メッセージに指示情報を設定する第１の設定ブロック３２と、アクセス許可メッセージをＡＡＡクライアントに送信する第１の送信ブロック３４と、を有する。
【００４２】
第１の設定ブロック３２が、アクセス許可メッセージのＱｏＳ−ＤｅｓｃｒｉｐｔｏｒのサブＴＬＶに、サービスフローに暗号化を行う必要があるか否かを指示するＴＬＶを追加することが好ましい。
【００４３】
図３に示すように、ＡＡＡクライアントは、リソース予約要請ＲＲ−Ｒｅｑメッセージのサービスフローパラメータに指示情報を含む第２の設定ブロック３６と、ＲＲ−ＲｅｑメッセージをアンカーＳＦＡに送信する第２の送信ブロック３８とを有する。該システムにおいて、ＡＡＡサーバと、ＡＡＡクライアントと、アンカーＳＦＡと、基地局との間の処理フローは上記実施例にて詳しく説明したので、ここでは省略する。
【００４４】
本実施例において、ＡＡＡサーバにより送信されるアクセス許可メッセージにおけるＱｏＳプロファイル（Ｐｒｏｆｉｌｅ）パラメータにセキュリティ・レベルパラメータを含めることができる。従って、サービスフローを構築中に、ユーザの各サービスフローはいずれも一つのセキュリティ・レベル値を有する。基地局はセキュリティ・レベル値に基づいて、対応するサービス伝送接続におけるデータを暗号化方式で伝送する必要があるか否かを決める。通常、ＱｏＳプロファイルｅをＡＡＡサーバにてユーザ及び接続に基づいて配置できるので、サービスフローを暗号化処理して伝送する必要があるか否かについてもユーザ及び接続に基づいて配置できる。
【００４５】
上述のように、上記実施例によると、従来関連技術において基地局がユーザの情報及びＱｏＳ属性に基づいてサービスフローセキュリティ要求を配置できないという問題を解決し、ユーザ情報及びＱｏＳ属性に基づくサービスフローのセキュリティ要求の配置を実現できる。
【００４６】
当業者にとって、上記の本発明の各ブロック又は各ステップは共通の計算装置によって実現でき、単独の計算装置に集中させること、又は複数の計算装置から構成されるネットワークに分布させることができ、さらに計算装置が実行可能なプログラムのコードによって実現できるので、それらを記憶装置に記憶させて計算装置によって実行でき、又は夫々集積回路ブロックに製作し、又はそれらにおける複数のブロック又はステップを単独の集積回路ブロックに製作して実現できることは明らかであろう。このように、本発明は如何なる特定のハードウェアとソフトウェアの組み合わせにも限定されない。
【００４７】
以上は、本発明の好適な実施例に過ぎず、本発明を限定するものではない。当業者であれば本発明に様々な修正や変形が可能であり、本発明の精神や主旨内での如何なる修正、置換、改良などは本発明の保護範囲内に含まれる。
【図１】
2013512631.tif 000004
【図２】
2013512631.tif 000005
【図３】
2013512631.tif 000006
【国際調査報告】
2013512631.tif 000007
2013512631.tif 000008
2013512631.tif 000009
2013512631.tif 000010