JP2023529951A - 安全な通信方法、関連する装置、およびシステム - Google Patents

Abstract

本出願の実施形態は、安全な通信方法、システム、および関連する装置を提供する。安全な通信方法では、送信側のSEPPデバイスが、SEPPデバイスと相互接続されたIPXデバイスのメッセージ変更ポリシーを取得し、次いで、第1のN32メッセージをIPXデバイスに送信することができ、ここで、第1のN32メッセージは、第1のシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。このようにして、IPXデバイスは、受信した第1のN32メッセージを受信側のSEPPデバイスへ送信することができ、受信側のSEPPデバイスは、第1のN32メッセージで搬送されたメッセージ変更ポリシーに従って、第1のN32メッセージを確認することができる。この実施形態で提供される安全な通信方法では、送信側のSEPPデバイスは、受信側のSEPPデバイスとメッセージ変更ポリシーをネゴシエートする必要はないが、送信側のSEPPデバイスと相互接続されたIPXデバイスと変更ポリシーをネゴシエートし、次いで、第1のN32メッセージを介して受信側のSEPPデバイスにIPXデバイスのメッセージ変更ポリシーを送信する。これにより、SEPPデバイス上で保持されるメッセージ変更ポリシーの数が減り、SEPPデバイスのリソースが節約される。

Description

本出願は、2020年6月12日に中国国家知識産権局に提出された「安全な通信方法、関連する装置、およびシステム」と題する中国特許出願第202010537382.7号の優先権を主張するものであり、同特許出願は、参照によりその全体が本明細書に組み入れられる、

本出願は、通信技術の分野に関し、詳細には、安全な通信方法、関連する通信装置、システム、および関連するコンピュータ可読記憶媒体に関する。

現在、第3世代パートナーシッププロジェクト（3rd Generation Partner Project，3GPP（登録商標））は、5Gコアネットワーク（5G Core，5GC）の境界セキュリティゲートウェイとしてセキュリティエッジ保護プロキシ（Security and Edge Protection Proxy，SEPP）デバイスを定義している。SEPPデバイスは、異なるキャリアのネットワーク間を相互接続するためのプロキシデバイスである。5Gコアネットワーク内のネットワーク機能（Network Function，NF）デバイスと別のキャリアのネットワークとの間のシグナリング交換では、シグナリング転送がSEPPデバイスによって実行される。

異なるキャリアネットワーク上のSEPPデバイスは、IP交換サービス（IP exchange service，IPX）ネットワークを用いてメッセージを転送することができる。SEPPデバイスは、送信メッセージの内容を変更する際に、IPXネットワーク上のIPXデバイスをサポートする。IPXデバイスは、ネットワークトポロジを外部から隠蔽し、ネットワークセキュリティを強化するために、事前定義されたメッセージ変更ポリシーに従って送信メッセージを変更することができる。

しかしながら、従来の技術では、ローカルネットワーク内のSEPPデバイスは、異なるIPXネットワークを通過するメッセージの変更ポリシーについて、異なるキャリア（ローミングパートナー）のネットワーク内のSEPPデバイスとネゴシエートする必要がある。ローカルネットワークが、大量のローミング・パートナー・ネットワークに相互接続され、ローカルネットワーク内のSEPPデバイスとローミング・パートナー・ネットワーク内のSEPPデバイスとの間に大量の任意選択の経路がある場合、すなわち、ローカルネットワーク内のSEPPデバイスおよびローミング・パートナー・ネットワーク内のSEPPデバイスが、異なるデバイスを介してメッセージを送信する可能性がある場合、SEPPデバイスは、大量のIPXメッセージ変更ポリシーを保持する必要があり、SEPPデバイスの大量のリソースを消費する必要があり、SEPPデバイスのコストが増加する。

本出願の実施形態は、安全な通信方法、システム、および関連する装置、ならびにコンピュータ可読記憶媒体を提供する。

第1の態様によれば、本出願の一実施形態は、以下の動作を含む安全な通信方法を提供する。

SEPPデバイスは、ネットワーク機能NFデバイスによって送信された第1のシグナリングメッセージを受信する。次いで、SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーを取得し、第1のN32メッセージをIPXデバイスに送信し、第1のN32メッセージは、第1のシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。

この実施形態で提供される技術的解決策では、送信側のSEPPデバイスは、送信側のSEPPデバイスと相互接続されたIPXデバイスのメッセージ変更ポリシーを取得し、次いで、第1のN32メッセージをIPXデバイスに送信することができ、第1のN32メッセージは、第1のシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。このようにして、IPXデバイスは、受信した第1のN32メッセージを受信側のSEPPデバイスへ送信することができ、受信側のSEPPデバイスは、第1のN32メッセージで搬送されたメッセージ変更ポリシーに従って、第1のN32メッセージを確認することができる。従来の技術と比較して、本実施形態で提供される安全な通信方法では、送信側のSEPPデバイスは、受信側のSEPPデバイスとメッセージ変更ポリシーをネゴシエートする必要はないが、送信側のSEPPデバイスと相互接続されたIPXデバイスと変更ポリシーをネゴシエートし、次いで、第1のN32メッセージを介して、IPXデバイスのメッセージ変更ポリシーを受信側のSEPPデバイスに送信する。これにより、送信側のSEPPデバイス上で保持されるメッセージ変更ポリシーの数が大幅に削減され、SEPPデバイスのリソースが節約され、SEPPデバイスのコストが削減される。

これに対応して、受信側のSEPPデバイスは、受信したN32メッセージから、受信側のSEPPデバイスと相互接続されたIPXデバイスのメッセージ変更ポリシーを取得することができ、異なるメッセージ送信経路に対応するメッセージ変更ポリシーをローカルに保持する必要がないので、その結果、受信側のSEPPデバイスのリソースが節約され、コストも削減される。

可能な解決策では、SEPPデバイスは、IPXデバイスのセキュリティ証明書を取得し、そのセキュリティ証明書を第1のN32メッセージのメッセージ本体に追加することができる。さらに、受信側のSEPPデバイスは、第1のN32メッセージからIPXデバイスのセキュリティ証明書を直接取得し、IPXデバイスのセキュリティ証明書をローカルに構成する必要がないので、その結果、受信側のSEPPデバイスの記憶空間が節約される。

可能な解決策では、SEPPデバイスは、対称鍵を用いてIPXデバイスのセキュリティ証明書を暗号化することができる。可能な解決策では、N32メッセージを受信するSEPPデバイスは、IPXデバイスのセキュリティ証明書を復号して取得するために、対称鍵を使用することができる。

可能な解決策では、SEPPデバイスは、IPXデバイスのセキュリティ証明書を取得する。SEPPデバイスによって送信される第1のN32メッセージは、IPXデバイスのセキュリティ証明書を搬送する。

可能な解決策では、メッセージ変更ポリシーは、第1のN32メッセージのメッセージヘッダ内の第1のフィールドを変更できることを含む。

可能な解決策では、メッセージ変更ポリシーは、第1のN32メッセージのメッセージヘッダ内の第2のフィールドを変更することができないことを含む。

可能な解決策では、SEPPデバイスは、以下の方法で第1のN32メッセージをIPXデバイスに送信することができる。
SEPPデバイスは、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを、第1のN32メッセージのメッセージ本体にカプセル化し、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを、IPXデバイスに送信する。メッセージ変更ポリシーは、既存のフィールドで搬送されてもよく、または新たに追加されたフィールドで搬送されてもよい。

可能な解決策では、SEPPデバイスは、第1のN32メッセージのメッセージ本体の平文部分でメッセージ変更ポリシーを搬送し、IPXデバイスにメッセージ変更ポリシーを送信できる。SEPPデバイスは、セキュリティを強化するために、他のデバイスが平文部分を変更することを防止するために、平文部分に対して完全性保護を実行できる。

可能な解決策では、SEPPデバイスは、対称鍵を用いてメッセージ変更ポリシーを暗号化し、次いで、暗号文を第1のN32メッセージのメッセージ本体に搬送し、暗号文をIPXデバイスに送信して、他のデバイスがメッセージ変更ポリシーを読み出したり変更したりするのを防止して、セキュリティを強化することができる。可能な解決策では、第1のN32メッセージを受信するSEPPデバイスは、IPXデバイスのメッセージ変更ポリシーを復号して取得するために、対称鍵を使用することができる。

可能な解決策では、SEPPデバイスは、ローカル構成からIPXデバイスのメッセージ変更ポリシーを取得し、次いで、第1のN32メッセージにIPXデバイスの変更ポリシーを追加することができる。

可能な解決策では、SEPPデバイスは、IPXデバイスによって送信された第2のN32メッセージを受信し、第2のN32メッセージは、第2のシグナリングメッセージおよびIPXデバイスの変更内容を搬送する。SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーに従って第2のN32メッセージ内の変更内容を確認し、確認が成功した場合、ネットワーク機能NFデバイスへ第2のシグナリングメッセージを送信することができる。確認が失敗した場合、SEPPデバイスは、IPXデバイスに失敗応答を送信し、第2のN32メッセージを破棄することができる。

第2の態様によれば、本出願の一実施形態は安全な通信方法を提供し、本方法は、
SEPPデバイスがN32メッセージを受信し、N32メッセージが、IPXデバイスのシグナリングメッセージおよびメッセージ変更ポリシーを搬送する、ことを含む。次いで、SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーに従ってN32メッセージを確認することができる。確認が成功した場合、SEPPデバイスは、N32メッセージ内のシグナリングメッセージをネットワーク機能NFデバイスに送信する。

この態様で提供される安全な通信方法では、N32メッセージを受信するSEPPデバイスは、N32メッセージからIPXデバイスのメッセージ変更ポリシーを取得し、変更ポリシーを用いてN32メッセージを確認することができる。SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーをローカルに構成する必要がないので、その結果、記憶空間が節約され、コストが削減される。

可能な解決策では、SEPPデバイスは、第2のIPXデバイスによって送信されたN32メッセージを受信し、N32メッセージは、第1のIPXデバイスを介してSEPPデバイスに送信される。

可能な解決策では、SEPPデバイスがN32メッセージの確認に失敗した場合、SEPPデバイスは、IPXデバイスに失敗応答を送信し、N32メッセージを破棄する。

可能な解決策では、SEPPデバイスによって受信されたN32メッセージは、IPXデバイスのセキュリティ証明書をさらに搬送する。SEPPデバイスは、以下の方法でN32メッセージを確認することができる。SEPPデバイスは、セキュリティ証明書に基づいて、N32メッセージ内のIPXデバイスの変更ブロック内の署名を確認する。確認が成功した場合、SEPPデバイスは、メッセージ変更ポリシーに従って変更ブロック内の変更内容を確認する。確認に失敗した場合、SEPPデバイスは、IPXデバイスに失敗応答を送信し、N32メッセージを破棄することができる。

可能な解決策では、IPXデバイスの変更ブロックは、IPXデバイスの変更内容を含む。

可能な解決策では、IPXデバイスの変更ブロックは、IPXデバイスの識別子を含む。

可能な解決策では、IPXデバイスの変更ブロックは、メタデータフィールドを含み、メタデータフィールドはIPXデバイスの識別子を含む。

可能な解決策では、SEPPデバイスは、N32メッセージのメッセージ本体からIPXデバイスのメッセージ変更ポリシーを取得する。

可能な解決策では、SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーを取得するために、N32メッセージのメッセージ本体を復号する。

可能な解決策では、SEPPデバイスは、N32メッセージのメッセージ本体を復号し、N32メッセージで搬送されたシグナリングメッセージを取得し、次いで、シグナリングメッセージを別のネットワークデバイスに送信することができる。

可能な解決策では、N32メッセージは、IPXデバイスの変更内容をさらに搬送する。SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーに従って、IPXデバイスの変更内容を確認することができる。

第3の態様によれば、本出願の一実施形態は安全な通信方法を提供し、本方法は、主に、
第1のSEPPデバイスが、第1のIPXデバイスによって送信されたN32メッセージを受信し、N32メッセージがシグナリングメッセージを搬送する、ことを含む。次いで、第1のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーを取得し、メッセージ変更ポリシーに従ってN32メッセージを確認する。確認が成功した場合、第1のSEPPデバイスは、ネットワーク機能NFデバイスにシグナリングメッセージを送信する。

この態様で提供される解決策では、第1のSEPPデバイスは、第1のSEPPデバイスに接続された第1のIPXデバイスのN32メッセージを受信し、N32メッセージを確認することができ、その結果、メッセージ送信セキュリティが向上する。

可能な解決策では、第1のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーをローカルに取得する。第1のIPXデバイスのメッセージ変更ポリシーは、SEPPデバイス上で構成することができる。

可能な解決策では、N32メッセージは、第1のIPXデバイスの変更内容をさらに搬送する。第1のSEPPデバイスは、以下の方法でN32メッセージを確認することができる。第1のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーに従って、N32メッセージ内の第1のIPXデバイスの変更内容を確認する。

可能な解決策では、第1のSEPPデバイスがN32メッセージの確認に失敗した場合、SEPPデバイスは第1のIPXデバイスに失敗応答を送信し、N32メッセージを破棄する。

可能な解決策では、N32メッセージは、第2のIPXデバイスのセキュリティ証明書、第2のIPXデバイスのメッセージ変更ポリシー、および第2のIPXデバイスの変更ブロックをさらに搬送する。第2のIPXデバイスは第2のSEPPデバイスに接続されている。

この場合、第1のSEPPデバイスは、セキュリティ証明書を用いて第2のIPXデバイスの変更ブロックを確認する。確認が成功した場合、第1のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシーに従って、第2のIPXデバイスの変更ブロックにおける変更内容を確認する。

この解決策では、第1のSEPPデバイスは、N32メッセージを2回確認し、具体的には、セキュリティ証明書を用いて第2のIPXデバイスの変更ブロックを確認し、第2のIPXデバイスのメッセージ変更ポリシーに従って第2のIPXデバイスの変更内容を確認するので、その結果、セキュリティがさらに強化される。

可能な解決策では、第2のIPXデバイスのセキュリティ証明書は、第2のIPXデバイスの公開鍵を含む。

可能な解決策では、第1のSEPPデバイスは、第2のSEPPデバイスによって送信された通知メッセージを受信し、通知メッセージは、第2のIPXデバイスのメッセージ変更ポリシーを搬送する。この場合、第1のSEPPデバイスによって受信されたN32メッセージは、第2のIPXデバイスの変更内容を搬送し、第2のIPXデバイスのメッセージ変更ポリシーを搬送する必要はない。

この場合、第1のSEPPデバイスは、通知メッセージ内のメッセージ変更ポリシーに従って、N32メッセージ内の第2のIPXデバイスの変更内容を確認する。

可能な解決策では、第2のSEPPデバイスは、第1のSEPPデバイスによって送信された通知メッセージを受信し、通知メッセージは、第1のIPXデバイスのメッセージ変更ポリシーを搬送する。この態様で提供される解決策では、第2のSEPPデバイスが、第1のSEPPデバイスによって送信されたN32メッセージを引き続き受信すると、第2のSEPPデバイスは、通知メッセージ内の第1のIPXデバイスのメッセージ変更ポリシーに従ってN32メッセージを確認することができ、その結果、メッセージ送信セキュリティが向上する。

可能な解決策では、通知メッセージは、第1のSEPPデバイスと第2のSEPPデバイスとの間でIPXデバイスに関する情報を交換するのに用いられる。

可能な解決策では、通知メッセージはN32-Cメッセージである。この解決策では、N32-Cメッセージを使用してIPXデバイスのメッセージ変更ポリシーが転送され、その結果、第1のSEPPデバイスと第2のSEPPデバイスとの間の通信のセキュリティが強化される。

可能な解決策では、第2のIPXデバイスのメッセージ変更ポリシーが第1のSEPPデバイスによって受信された通知メッセージで搬送される場合、第1のSEPPデバイスは、第2のIPXデバイスの識別子および第2のIPXデバイスのメッセージ変更ポリシーを保存する。この保存は、第2のIPXデバイスの識別子と第2のIPXデバイスのメッセージ変更ポリシーとの間の関連付けを確立することとして理解することができる。

第4の態様によると、本出願の一実施形態はコンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、コンピュータプログラムを格納する。コンピュータプログラムがプロセッサによって実行されると、第1の態様、第2の態様、第3の態様、または第4の態様のいずれか1つによる方法を実施することができる。

第5の態様によれば、一実施形態は、互いに接続された少なくとも1つのプロセッサおよびメモリを含む、セキュリティエッジ保護プロキシSEPPデバイスを提供する。メモリは、コンピュータプログラムコードを格納し、プロセッサは、メモリ内のコンピュータプログラムコードを呼び出して実行し、SEPPデバイスが第1の態様、第2の態様、第3の態様、または第4の態様のいずれか1つによる方法を実行することを可能にする。

第6の態様によれば、本出願の一実施形態は、安全な通信システムを提供し、本システムは、
コアネットワーク機能デバイスと、SEPPデバイスとを含み、
コアネットワーク機能デバイスは、第1のSEPPデバイスへ第1のシグナリングメッセージを送信するように構成され、SEPPデバイスは、第1の態様の実施態様のいずれか1つによる方法を実行するように構成される。

可能な解決策では、シグナリングメッセージはローミング・シグナリング・メッセージである。

第7の態様によれば、本出願の一実施形態はSEPPデバイスを提供する。デバイスは、第1の態様で提供される安全な通信方法で使用され得る。

この態様で提供されるSEPPデバイスは、主に、第1の受信ユニットと、第1の取得ユニットと、第1の送信ユニットとを含む。

第1の受信ユニットは、ネットワーク機能NFデバイスによって送信された第1のシグナリングメッセージを受信するように構成される。

第1の取得ユニットは、IP交換サービスIPXデバイスのメッセージ変更ポリシーを取得するように構成されている。

第1の送信ユニットは、第1のN32メッセージをIPXデバイスに送信するように構成され、第1のN32メッセージは、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを搬送する。

可能な解決策では、SEPPデバイス内の第1の取得ユニットは、IPXデバイスのセキュリティ証明書を取得するようにさらに構成されてもよい。この場合、第1の送信ユニットによって送信される第1のN32メッセージは、IPXデバイスのセキュリティ証明書を搬送する。

可能な解決策では、SEPPデバイスの第1の送信ユニットは、以下の方式で第1のN32メッセージを送信することができる。
第1の送信ユニットは、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを、第1のN32メッセージのメッセージ本体にカプセル化し、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーをIPXデバイスに送信する。

可能な解決策では、IPXデバイスのメッセージ変更ポリシーは、第1のN32メッセージのメッセージ本体の平文部分で搬送されてもよい。

可能な解決策では、第1の取得ユニットは、ローカル構成からIPXデバイスのメッセージ変更ポリシーを取得することができる。

可能な解決策では、SEPPデバイスの第1の受信ユニットは、IPXデバイスによって送信された第2のN32メッセージを受信するようにさらに構成され、第2のN32メッセージは、第2のシグナリングメッセージおよびIPXデバイスの変更内容を搬送する。

SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーに従って、第2のN32メッセージ内のIPXデバイスの変更内容を確認するように構成された、第1の確認ユニットをさらに含む。

第1の送信ユニットは、第1の確認ユニットによって実行された確認が成功した後に、第2のシグナリングメッセージをネットワーク機能NFデバイスにさらに送信する。

第8の態様によれば、本出願の一実施形態はSEPPデバイスを提供する。SEPPデバイスは、第2の態様で提供される安全な通信方法で使用されてもよい。SEPPデバイスは、主に、第2の受信ユニット、第2の確認ユニット、および第2の送信ユニットを含む。

第2の受信ユニットはN32メッセージを受信するように構成されており、N32メッセージは、IPXデバイスのシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。第2の確認ユニットは、IPXデバイスのメッセージ変更ポリシーに従ってN32メッセージを確認するように構成される。第2の送信ユニットは、第2の確認ユニットによってN32メッセージに対して実行された確認が成功した後に、シグナリングメッセージをネットワーク機能NFデバイスに送信するように構成される。

可能な解決策では、SEPPデバイス内の第2の受信ユニットによって受信されるN32メッセージは、IPXデバイスのセキュリティ証明書をさらに搬送する。第2の確認ユニットがメッセージ変更ポリシーに従ってN32メッセージを確認することは、
第2の確認ユニットが、IPXデバイスのセキュリティ証明書に基づいて、N32メッセージ内のIPXデバイスの変更ブロック内の署名を確認することを、含む。確認が成功した後で、第2の確認ユニットは、メッセージ変更ポリシーに従ってIPXデバイスの変更ブロックにおける変更内容をさらに確認する。

可能な解決策では、SEPPデバイスは、IPXデバイスのメッセージ変更ポリシーを取得するために、N32メッセージのメッセージ本体を復号するように構成された、復号ユニットをさらに含む。

可能な解決策では、SEPPデバイスの復号ユニットは、N32メッセージで搬送されるシグナリングメッセージを取得するために、N32メッセージのメッセージ本体を復号するようにさらに構成される。

第9の態様によれば、本出願の一実施形態は、第1のSEPPデバイスを提供する。デバイスは、第3の態様で提供される安全な通信方法で使用され得る。具体的な詳細および有益な効果については、前述の態様の内容を参照されたい。

この態様で提供される第1のSEPPデバイスは、主に、第3の受信ユニットと、第3の取得ユニットと、第3の確認ユニットと、第3の送信ユニットとを含む。

第3の受信ユニットは、第1のIPXデバイスによって送信されたN32メッセージを受信するように構成されており、N32メッセージはシグナリングメッセージを搬送する。

第3の取得ユニットは、第1のIPXデバイスのメッセージ変更ポリシーを取得するように構成されている。

第3の確認ユニットは、メッセージ変更ポリシーに従って、N32メッセージを確認するように構成される。

第3の送信ユニットは、第3の確認ユニットによって実行されたN32メッセージの確認が成功した後に、シグナリングメッセージをネットワーク機能NFデバイスに送信するように構成される。

可能な解決策では、第3の受信ユニットによって受信されたN32メッセージは、第1のIPXデバイスの変更内容をさらに搬送する。第3の確認ユニットは、以下の方法でN32メッセージを確認することができる。第3の確認ユニットは、メッセージ変更ポリシーに従って、N32メッセージ内の第1のIPXデバイスの変更内容を確認する。

可能な解決策では、第3の受信ユニットによって受信されたN32メッセージは、第2のIPXデバイスのセキュリティ証明書、第2のIPXデバイスのメッセージ変更ポリシー、および第2のIPXデバイスの変更ブロック、をさらに搬送する。この場合、第3の確認ユニットは、セキュリティ証明書を用いて第2のIPXデバイスの変更ブロックを確認するようにさらに構成されている。確認が成功すると、第3の確認ユニットは、第2のIPXデバイスのメッセージ変更ポリシーに従って、第2のIPXデバイスの変更ブロックにおける変更内容を確認する。

可能な解決策では、第1のSEPPデバイスの第3の受信ユニットは、第2のSEPPデバイスによって送信された通知メッセージを受信するようにさらに構成され、通知メッセージは第2のIPXデバイスのメッセージ変更ポリシーを搬送する。

可能な解決策では、第1のSEPPデバイスはcSEPPデバイスであり、第2のSEPPデバイスはpSEPPデバイスである。

第10の態様によれば、本出願の一実施形態は、少なくとも1つの入力端と、信号プロセッサと、少なくとも1つの出力端とを含む通信装置を提供する。信号プロセッサは、本出願の実施形態において、SEPPデバイスによって実行される任意の方法の一部または全部の動作を実行するように構成される。

第11の態様によれば、本出願の一実施形態は、入力インターフェース回路、論理回路、および出力インターフェース回路を含む通信装置を提供する。論理回路は、本出願の実施形態において、SEPPデバイスによって実行される任意の方法の一部または全部の動作を実行するように構成される。

第12の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータデバイス上で実行されると、コンピュータデバイスは、SEPPデバイスによって実行され得る任意の方法の一部または全部の動作を実行することが可能になる。

第13の態様によれば、本出願の一実施形態は、互いに接続されたメモリおよびプロセッサを含むSEPPデバイスを提供する。メモリはプログラムコードを格納し、プロセッサは、メモリ内のプログラムコードを呼び出して実行し、SEPPデバイスが前述の通信方法の一部またはすべての動作を実行することを可能にする。

第14の態様によれば、本出願の一実施形態は、少なくとも1つの入力端と、信号プロセッサと、少なくとも1つの出力端とを含む通信装置を提供する。信号プロセッサは、本出願の実施形態でIPXデバイスによって実行される任意の方法の一部または全部の動作を実行するように構成される。

第15の態様によれば、本出願の一実施形態は、入力インターフェース回路、論理回路、および出力インターフェース回路を含む通信装置を提供する。論理回路は、本出願の実施形態でIPXデバイスによって実行される任意の方法の一部または全部の動作を実行するように構成される。

第16の態様によれば、本出願の一実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータデバイス上で実行される場合、コンピュータデバイスは、IPXデバイスによって実行され得る任意の方法の一部または全部の動作を実行することが可能になる。

第17の態様によれば、本出願の一実施形態は、互いに接続されたメモリおよびプロセッサを含むIPXデバイスを提供する。メモリはプログラムコードを格納し、プロセッサは、メモリ内のプログラムコードを呼び出して実行し、IPXデバイスが前述の通信方法の一部または全部の動作を行うことを可能にする。

前述の態様のいずれか1つで提供される解決策では、N32メッセージはN32-fメッセージである。

前述の態様のいずれか1つにおいて提供される解決策において、SEPPデバイスは、消費者のSEPPデバイスまたは生産者のSEPPデバイスである。

前述の態様のいずれか1つで提供される解決策では、SEPPデバイスは訪問先SEPPデバイスまたはホームSEPPデバイスである。

前述の態様のいずれか1つで提供される解決策では、メッセージ変更ポリシーは、デフォルトポリシーまたはワイルドカードポリシーとすることができ、その結果、SEPPデバイスまたはIPXデバイス上で構成されるポリシーの数が削減される。

以下、本出願の実施形態で使用する必要がある添付の図面を簡単に説明する。

本出願の一実施形態による、5Gネットワークアーキテクチャの一例の概略図である。 本出願の一実施形態による、ローミングシナリオにおけるネットワークアーキテクチャの一例の概略図である。 本出願の一実施形態による、別のローミングシナリオにおけるネットワークアーキテクチャの一例の概略図である。 本出願の一実施形態による、別のローミングシナリオにおけるネットワークアーキテクチャの一例の概略図である。 本出願の一実施形態による、別のローミングシナリオにおけるネットワークアーキテクチャの一例の概略図である。 本出願の一実施形態による、通信方法の概略フローチャートである。 本出願の一実施形態による、通信方法の概略フローチャートである。 本出願の一実施形態による、別の通信方法の概略フローチャートである。 本出願の一実施形態による、別の通信方法の概略フローチャートである。 本出願の一実施形態による、別の通信方法の概略フローチャートである。 本出願の一実施形態で提供される通信方法による、IPXデバイスの変更ブロックを確認する概略フローチャートである。 本出願の一実施形態で提供される通信方法による、N32メッセージのメッセージ本体の概略図である。 本出願の一実施形態で提供される通信方法による、別のN32メッセージのメッセージ本体の概略図である。 本出願の一実施形態で提供される通信方法による、別のN32メッセージのメッセージ本体の概略図である。 本出願の一実施形態による、SEPPデバイスの機能の概略図である。 本出願の一実施形態による、別のSEPPデバイスの機能の概略図である。 本出願の一実施形態による、別のSEPPデバイスの機能の概略図である。 本出願の一実施形態による、通信装置の構造の概略図である。 本出願の一実施形態による、通信装置における基板のインターフェースの概略図である。および 本出願の一実施形態による、SEPPデバイスのハードウェアの構造の図である。

以下では、本出願の実施形態の添付の図面を参照して、本出願の実施形態の技術的解決策を説明する。

本出願の明細書、特許請求の範囲、および添付の図面において、「第1」、「第2」などの用語は、異なる対象を区別することを意図しているが、特定の順序を示すものではない。

図1-Aは、本出願の一実施形態による5Gネットワークアーキテクチャの一例の概略図である。5Gネットワークでは、4Gネットワーク内のいくつかの機能デバイス（例えば、モビリティ管理エンティティ（Mobility Management Entity，MME））が分割され、サービスベースのアーキテクチャが定義される。図1-Aに示すネットワークアーキテクチャでは、4GネットワークにおけるMMEと同様の機能は、アクセスおよびモビリティ管理機能（Access and Mobility Management Function，AMF）、セッション管理機能（Session Management Function，SMF）などに分割される。

以下では、5Gネットワークアーキテクチャにおけるいくつかの他の関連デバイス／ネットワーク要素／エンティティについて説明する。これらのデバイス／ネットワーク要素／エンティティは、それぞれの略語で呼ばれる場合があり、例えば、アクセスおよびモビリティ管理機能デバイスは、略してAMFと呼ばれる。

ユーザ機器（User Equipment，UE）は、キャリアネットワークにアクセスすることによってデータネットワークにアクセスし、データネットワーク（Data Network，DN）上でキャリアまたは第三者によって提供されるサービスを使用する。

説明を容易にするために、本出願の実施形態では、ユーザ端末、ユーザ機器、端末デバイス、またはモバイル端末は、まとめてUEと呼ばれ得る。すなわち、別段の指定がない限り、本出願の実施形態において以下で説明されるUEは、ユーザ端末、ユーザ機器、端末デバイス、モバイル端末、または端末と置き換えられてもよい。当然ながら、ユーザ端末、ユーザ機器、端末デバイス、モバイル端末、または端末も入れ替えることができる。

アクセスおよびモビリティ管理機能（AMF）は、3GPPネットワークにおける制御プレーン機能デバイスであり、UEがキャリアネットワークにアクセスするときのアクセス制御およびモビリティ管理を主に担当する。セキュリティアンカー機能（Security Anchor Function，SEAF）はAMFに配備されてもよいし、SEAFはAMF以外の別のデバイスに配備されてもよい。図1-Aでは、AMFにSEAFを配備する例を用いている。SEAFがAMF内に配備されると、SEAFおよびAMFは、一緒にAMFと呼ばれる場合がある。

セッション管理機能（SMF）は、3GPPネットワーク内の制御プレーン機能デバイスである。SMFは、主に、UEのパケットデータユニット（Packet Data Unit、PDU）セッションを管理するように構成される。PDU sessionは、PDUを送信するために使用されるチャネルであり、UEおよびDNは、PDU sessionを使用して互いにPDUを送信することができる。SMFは、PDUセッションの確立、維持、および削除などの管理タスクに関与する。

データネットワークは、パケットデータネットワーク（Packet Data Network，PDN）とも呼ばれ、3GPPネットワークの外部のネットワークである。複数のDNが3GPPネットワークに接続されてもよく、キャリアまたは第三者によって提供される複数のサービス、例えば、第三者によって提供されるオンラインビデオサービス、がDNに配備されてもよい。別の例では、DNはスマートファクトリのプライベートネットワークであり、スマートファクトリのワークショップに設置されたセンサはUEの役割を果たし、センサの制御サーバはDNに配備される。UEは制御サーバと通信する。制御サーバから命令を取得した後、UEは、命令に基づいて収集されたデータを制御サーバに転送することができる。別の例では、DNは企業の内部オフィスネットワークであり、企業の従業員によって使用される端末はUEの役割を果たすことができ、UEは企業の内部情報および他のリソースにアクセスすることができる。

統合データ管理（Unified Data Management，UDM）エンティティはまた、3GPPネットワーク内の制御プレーン機能デバイスである。UDMは、3GPPネットワーク内の加入者（UE）の加入者データ、資格情報（credential）、加入者永久識別子（Subscriber Permanent Identifier，SUPI）などを格納することを主に担当する。データは、UEがキャリアの3GPPネットワークにアクセスするときの認証および許可に使用されてもよい。さらに、UDMは、ホーム加入者サーバ（Home Subscriber Server，HSS）およびホーム・ロケーション・レジスタ（Home Location Register，HLR）の機能をネットワークにさらに統合してもよい。

認証サーバ機能（Authentication Server Function，AUSF）は、3GPPネットワーク内の制御プレーン機能デバイスでもある。AUSFは、主に第1レベルの認証（すなわち、3GPPネットワークにおける加入者認証）に使用される。

ネットワーク露出機能（Network Exposure Function，NEF）も、3GPPネットワークにおける制御プレーン機能デバイスである。NEFは、主に、3GPPネットワークの外部インターフェースを安全な方法で第三者に公開する役割を果たす。

ネットワークリポジトリ機能（Network Repository Function，NRF）は、3GPPネットワークにおける制御プレーン機能デバイスでもある。NRFは、主に、アクセス可能なネットワーク機能（NF）の構成サービスプロファイル（profile）を格納し、他のネットワーク要素にネットワーク機能発見サービスを提供する役割を果たす。

ユーザプレーン機能（User Plane Function，UPF）は、3GPPネットワークとDNとの間の通信のためのゲートウェイである。

ポリシー制御機能（Policy Control Function，PCF）は、3GPPネットワーク内の制御プレーン機能デバイスであり、SMFにPDUセッションのポリシーを提供するように構成される。ポリシーは、課金ポリシー、サービス品質（Quality of Service，QoS）ポリシー、認可関連ポリシーなどを含んでもよい。

アクセスネットワーク（Access Network，AN）は、3GPPネットワークのサブネットワークである。3GPPネットワークにアクセスするために、UEは最初にANにアクセスする必要がある。無線アクセスシナリオにおいて、ANは、無線アクセスネットワーク（Radio Access Network，RAN）とも呼ばれる。

5Gコアネットワーク（5GC）のエッジ・セキュリティ・ゲートウェイとして、SEPPデバイスは、主に、キャリアネットワーク間の相互接続のプロキシとして機能する。5Gコアネットワークの内部ネットワーク機能（NF）とローミングネットワークとの間のシグナリングメッセージは、SEPPによって転送される。

3GPPネットワークは、3GPP仕様に準拠したネットワークである。図1-Aでは、UEおよびDN以外の部分が、3GPPネットワークと見なされてもよい。3GPPネットワークは、5Gネットワークに限定されず、2Gネットワーク、3Gネットワーク、および4Gネットワークをさらに含んでもよい。通常、3GPPネットワークはキャリアによって運用される。加えて、図1-Aに示すアーキテクチャにおけるN1、N2、N3、N4、およびN6は、関連するエンティティ／ネットワーク機能間の基準点（Reference Point）を表す。Nausf、Namfなどは、関連するネットワーク機能のサービス指向インターフェースを表す。

確かに、3GPPネットワークおよび非3GPPネットワークが共存してもよく、5Gネットワーク内のいくつかのネットワーク要素はまた、いくつかの非5Gネットワーク内で使用されてもよい。

図1-Bを参照されたい。境界セキュリティゲートウェイとして、SEPPデバイスは、送信されたメッセージの完全性および機密性の保護をサポートするだけでなく、送信されたメッセージの内容の識別および変更、例えば、送信されたメッセージのメッセージヘッダの変更において、IPXネットワーク内のデバイス（IPXデバイスまたは略称IPX）もサポートする。

IPXネットワーク内のデバイスには、Diameter・ルーティング・エージェント（Diameter routing agent，DRA）デバイス、ドメイン・ネーム・サーバ（domain name server，DNS）などが含まれてもよい。IPXデバイスは、DRAデバイスまたはIPXネットワーク内のDNSであってもよい。また、IPXデバイスは、HTTP（Hyper Text Transfer Protocol，HTTP）プロキシと呼ばれることもある。

本出願のこの実施形態では、SEPPデバイスは、略してSEPPと呼ばれることもある（例えば、第1のSEPPデバイスは略して第1のSEPPと呼ばれ、第2のSEPPデバイスは略して第2のSEPPと呼ばれ、以下同様である）。すなわち、SEPPとSEPPデバイスとを入れ替えることができる。IPXデバイスは、略してIPXと呼ばれる（例えば、第1のIPXデバイスは略して第1のIPXと呼ばれ、第2のIPXデバイスは略して第2のIPXと呼ばれ、以下同様である。）。すなわち、IPXとIPXデバイスとを入れ替えることができる。

UEが異なるキャリアネットワーク間をローミングするとき、SEPPデバイスは、訪問先SEPPデバイス（visit SEPPデバイス、vSEPPデバイス）と、ホームSEPPデバイス（home SEPPデバイス、hSEPPデバイス）とに、分類することができる。

図1-Cおよび図1-Dを参照されたい。異なるキャリアネットワーク内のSEPPデバイスは、N32インターフェースを介して接続されてもよい。例えば、vSEPPデバイスとhSEPPデバイスとがN32-Cインターフェースを介して直接接続されている場合、vSEPPデバイスはN32-fインターフェースを介してIPXデバイスに接続されてもよく、その場合、IPXデバイスはN32-fインターフェースを介してhSEPPデバイスに接続される。SEPPデバイス間には、1つのIPXデバイス（例えば、図1-Dに示すように）、または複数のIPXデバイス（例えば、図1-Cに示すように）が存在することができる。

図1-Eを参照されたい。サービスを提供し、サービスを消費するという観点から、SEPPデバイスは、消費者のSEPPデバイス（（consumer's SEPPデバイス、cSEPPデバイス）と生産者のSEPPデバイス（producer's SEPPデバイス、pSEPPデバイス）とに、さらに分類することができる。vSEPPデバイスはpSEPPデバイスであってもよく、hSEPPデバイスはcSEPPデバイスであってもよい。あるいは、vSEPPデバイスはcSEPPデバイスであってもよく、hSEPPデバイスはpSEPPデバイスであってもよい。

SEPPデバイス間に複数のIPXネットワークが存在する場合、pSEPPデバイスに直接接続されたIPXネットワークをpIPXデバイスと呼び、cSEPPデバイスに直接接続されたIPXネットワークをcIPXデバイスと呼ぶ。

前述のネットワークアーキテクチャに基づいて、以下では、2つのSEPPデバイス間で安全な通信を実行するための実装ソリューションについて説明する。図2Aおよび図2Bは、本出願の一実施形態による安全な通信方法の概略フローチャートである。

本実施形態で提供される安全な通信方法は、図1-Dに記載されたシステムアーキテクチャに適用されてもよく、第1のSEPPデバイスと第2のSEPPデバイスとの間に複数の送信経路があってもよい。

本実施形態で提供される安全な通信方法は、主に以下の動作を含む。

201：第1のSEPPデバイスは、ネットワーク機能NFデバイスによって送信された第1のシグナリングメッセージを受信する。

この実施形態では、ローカルネットワーク内のNFデバイスは、第1のSEPPデバイスに第1のシグナリングメッセージを送信し、第1のSEPPデバイスは、接続されたIPXデバイスを介して、別のキャリアネットワーク、例えば、ユーザのホームキャリアネットワーク、にシグナリングメッセージを送信することができる。

第1のシグナリングメッセージはHTTP/2メッセージであってよく、具体的にはHTTP/2リクエスト／レスポンスであってよい。第1のシグナリングメッセージは、SMFから来てもよい。

202：第1のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーを取得する。

この実施形態では、第1のSEPPデバイスに接続された複数のIPXデバイスがあってもよく、これらのIPXデバイスは異なるIPXネットワークに属する。第1のSEPPデバイスは、第1のシグナリングメッセージの送信経路上の第1のIPXデバイスを判断し、次いで、第1のIPXデバイスのメッセージ変更ポリシーを取得することができる。

この実施形態では、第1のSEPPデバイスおよび第1のIPXデバイスは、メッセージ変更ポリシーを事前にネゴシエートしてもよく、次いで、第1のSEPPデバイスおよび第1のIPXデバイスは、メッセージ変更ポリシーをローカルに構成する。

この実施形態では、前述のメッセージ変更ポリシーは、メッセージ保護ポリシーと呼ばれてもよく、または略して変更ポリシーまたは保護ポリシーと呼ばれてもよい。

203：第1のSEPPデバイスは、第1のN32メッセージを第1のIPXデバイスに送信し、第1のN32メッセージは、第1のシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。

本実施形態では、第1のSEPPデバイスは、第1のシグナリングメッセージおよびメッセージ変更ポリシーに基づいて、第1のN32メッセージを生成することができる。第1のN32メッセージは、第1のIPXデバイスのメッセージ変更ポリシーおよび第1のシグナリングメッセージを搬送する。

その後、第1のSEPPデバイスは、第1のN32メッセージに対して、セキュリティ保護、例えば暗号化、を行うことができる。第1のSEPPデバイスは、第1のIPXデバイスに、セキュリティ保護を行うことによって取得された第1のN32メッセージを送信することができる。

この実施形態における第1のN32メッセージは、具体的には、第1のN32-fメッセージであってもよい。

204：第1のIPXデバイスは、第1のSEPPデバイスが送信した第1のN32メッセージを受信し、第1のN32メッセージを変更する。

この実施形態では、IPXデバイスは、ローカルに構成されたメッセージ変更ポリシーに従って、第1のN32メッセージを変更することができる。変更内容は変更ブロック（block）の形で第1のN32メッセージに付加され、第1のIPXデバイスの秘密鍵を用いて署名される。

IPXデバイスは複数のメッセージ変更ポリシーをローカルに保持することができ、これらのメッセージ変更ポリシーはそれぞれ異なるSEPPデバイス用である。IPXデバイスは、SEPPデバイスの識別子とメッセージ変更ポリシーとの間の対応関係を、ローカルに格納することができる。さらに、第1のSEPPデバイスによって送信された第1のN32メッセージを受信した後で、IPXデバイスは、第1のSEPPデバイスの識別子に対応するメッセージ変更ポリシーを判断する。

205：第1のIPXデバイスは、変更された第1のN32メッセージを第2のSEPPデバイスに送信する。

206：第2のSEPPデバイスは、変更された第1のN32メッセージ内のメッセージ変更ポリシー、変更ブロック、および第1のシグナリングメッセージを取得する。

本実施形態では、第1のIPXデバイスによって送信された変更された第1のN32メッセージを受信した後で、第2のSEPPデバイスは、変更された第1のN32メッセージで搬送されるメッセージ変更ポリシー、変更ブロック、および第1のシグナリングメッセージを取得することができる。例えば、第2のSEPPデバイスは、第1のシグナリングメッセージを取得するために、変更された第1のN32メッセージを復号する。

207：第2のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーに従って、第1のN32メッセージ内の変更ブロックを確認する。

本実施形態では、第2のSEPPデバイスは、変更ブロックがメッセージ変更ポリシーを満たすかどうか、例えば、メッセージ変更ポリシーに従って変更することができないフィールドが、第1のIPXデバイスによって変更されているかどうか、特に確認することができる。変更ブロックがメッセージ変更ポリシーを満たす場合、確認は成功する。確認に失敗した場合、SEPPデバイスは、第1のIPXデバイスにエラーメッセージを返信し、第1のN32メッセージを破棄する。

208：第2のSEPPデバイスは、確認が成功した後に、ローカルネットワーク内のネットワーク機能NFデバイスに、第1のシグナリングメッセージを送信する。

第2のSEPPデバイスは、第1のN32メッセージ内の変更ブロックの確認が成功した後に、ローカルネットワーク内のNFに第1のシグナリングメッセージを送信する。例えば、第2のSEPPデバイスは、第1のシグナリングメッセージをローカルコアネットワーク内のSMFまたはUDMに送信し、ローカルネットワーク内のNFは第1のシグナリングメッセージを処理する。

209：第2のSEPPデバイスは、ローカルネットワーク内のNFによって送信された第2のシグナリングメッセージを受信する。

この実施形態では、第1のシグナリングメッセージを処理した後、ローカルネットワーク内のNFは、第2のSEPPデバイスに第2のシグナリングメッセージを返信することができ、第2のシグナリングメッセージは、第1のSEPPデバイスに送信され得る。

加えて、第2のSEPPデバイスは、ローカルネットワーク内の別のNFによって能動的に送信されたシグナリングメッセージをさらに受信することもできる。第1のSEPPデバイスから第2のSEPPデバイスによって受信される第1のシグナリングメッセージと区別するために、ローカルネットワーク内のNFによって送信され、第2のSEPPデバイスによって受信されるシグナリングメッセージは、まとめて第2のシグナリングメッセージと呼ばれる。

210：第2のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシーを取得する。

この実施形態では、第2のシグナリングメッセージは、前述の同じIPXデバイス（すなわち、第1のIPXデバイス）を使用して第1のSEPPデバイスに送信されてもよく、別の経路上のIPXデバイス（例えば、第2のIPXデバイス）を介して、第1のSEPPデバイスに送信されてもよい。前述の同じIPXデバイスを介して第2のシグナリングメッセージを送信する処理論理と、別の経路の第2のシグナリングメッセージ上のIPXデバイスを使用して第2のシグナリングメッセージを送信する処理ロジックは、同じである。この実施形態は、第2のシグナリングメッセージが、異なるIPXデバイスを介して、第1のSEPPデバイスに送信される例を用いて説明される。

この実施形態では、第2のSEPPデバイスおよび第2のIPXデバイスは、メッセージ変更ポリシーを事前にネゴシエートしてもよく、次いで、第1のSEPPデバイスおよび第1のIPXデバイスは、メッセージ変更ポリシーをローカルに構成する。第2のシグナリングメッセージが第2のIPXデバイスを介して送信される必要があると判断した場合、第2のSEPPデバイスは、ローカル構成から第2のIPXデバイスのメッセージ変更ポリシーを取得してもよい。

211：第2のSEPPデバイスは、第2のIPXデバイスに第2のN32メッセージを送信し、第2のN32メッセージは第2のシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。

本実施形態では、第2のSEPPデバイスは、第2のシグナリングメッセージおよびメッセージ変更ポリシーに基づいて、第2のN32メッセージを生成することができる。第2のN32メッセージは、第2のIPXデバイスのメッセージ変更ポリシーおよび第2のシグナリングメッセージを搬送する。

その後、第2のSEPPデバイスは、第2のN32メッセージを暗号化し、暗号化された第2のN32メッセージを第2のIPXデバイスに送信することができる。この実施形態における第2のN32メッセージは、具体的には、第2のN32-fメッセージであってもよい。

212：第2のIPXデバイスは、第2のSEPPデバイスによって送信された第2のN32メッセージを受信し、第2のN32メッセージを変更する。

第2のIPXデバイスは、ローカルに構成されたメッセージ変更ポリシーに従って第2のN32メッセージを変更することができる。変更内容は、変更ブロックの形で第2のN32メッセージに付加される。

213：第2のIPXデバイスは、変更された第2のN32メッセージを第1のSEPPデバイスに送信する。

214：第1のSEPPデバイスは、変更された第2のN32メッセージ内のメッセージ変更ポリシー、変更ブロック、および第2のシグナリングメッセージを取得する。

本実施形態では、第2のIPXデバイスによって送信された変更された第2のN32メッセージを受信した後で、第1のSEPPデバイスは、変更された第2のN32メッセージで搬送される、メッセージ変更ポリシー、変更ブロック、および第2のシグナリングメッセージを取得することができる。例えば、第1のSEPPデバイスは、変更された第2のN32メッセージで搬送された第2のシグナリングメッセージを取得するために、変更された第2のN32メッセージを復号することができる。

215：第1のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシーに従って第2のN32メッセージ内の変更ブロックを確認する。

本実施形態では、第1のSEPPデバイスは、変更ブロックがメッセージ変更ポリシーを満たすかどうか、例えば、メッセージ変更ポリシーに従って変更することができないフィールドが、第2のIPXデバイスによって変更されているかどうかを、特に確認することができる。変更ブロックがメッセージ変更ポリシーを満たす場合、確認は成功する。確認に失敗した場合、SEPPデバイスは、第2のIPXデバイスにエラーメッセージを返信し、第2のN32メッセージを破棄する。

215：第1のSEPPデバイスは、確認が成功した後で、ローカルネットワーク内のネットワーク機能NFデバイスへ第2のシグナリングメッセージを送信する。

第1のSEPPデバイスは、第2のN32メッセージ内の変更ブロックの確認が成功した後に、ローカルネットワーク内のNFに第2のシグナリングメッセージを送信する。例えば、第1のSEPPデバイスは、第2のシグナリングメッセージをローカルコアネットワーク内のSMFまたはPCFに送信し、ローカルネットワーク内のNFは、第2のシグナリングメッセージを処理する。

この実施形態で提供される技術的解決策では、第1のSEPPデバイスは、第1のN32メッセージを送信するための送信側のSEPPデバイスとして機能してもよく、または、第2のN32メッセージを受信するための受信側のSEPPデバイスとして機能してもよい。同様に、第2のSEPPデバイスは、第2のN32メッセージを送信する送信側のSEPPデバイスとして機能してもよく、または、第1のN32メッセージを受信する受信側のSEPPデバイスとして機能してもよい。

第1のSEPPデバイスと第2のSEPPデバイスの両方は、相互接続されたIPXデバイスのメッセージ変更ポリシーを取得し、次いで、N32メッセージをIPXデバイスに送信することができる。N32メッセージは、IPXデバイスのメッセージ変更ポリシーを搬送する。このようにして、IPXデバイスは、受信したN32メッセージを第2のSEPPデバイスまたは第1のSEPPデバイスへ送信することができる。従来の技術と比較して、この実施形態で提供される安全な通信方法では、送信側のSEPPデバイスは、受信側のSEPPデバイスとメッセージ変更ポリシーをネゴシエートする必要はないが、送信側のSEPPデバイスと相互接続されたIPXデバイスと変更ポリシーをネゴシエートし、次いで、N32メッセージを介して受信側のSEPPデバイスにネゴシエートされたメッセージ変更ポリシーを送信する。これにより、送信側のSEPPデバイス上で保持されるメッセージ変更ポリシーの数が大幅に削減され、送信側のSEPPデバイスのリソースが節約され、送信側のSEPPデバイスのコストが削減される。

これに対応して、受信側のSEPPデバイスは、受信側のSEPPデバイスと相互接続されたIPXデバイスのメッセージ変更ポリシーを、受信したN32メッセージから直接取得することができ、異なるメッセージ送信経路に対応するメッセージ変更ポリシーをローカルに保持する必要がないので、その結果、受信側のSEPPデバイスのリソースが節約され、受信側のSEPPデバイスのコストも削減される。

可能な実施形態では、IPXデバイスのメッセージ変更ポリシーは、デフォルトポリシーであってもワイルドカードポリシーであってもよい。例えば、識別子「1」はデフォルトポリシーを表すために使用され、識別子「0」はワイルドカードポリシーを表すために使用される。この実施形態では、SEPPデバイスまたはIPXデバイス上で構成されるポリシーの数を減らすことができる。

図3は、本出願の一実施形態による別の安全な通信方法の概略フローチャートである。

本実施形態で提供される安全な通信方法は、図1-Cおよび図1-Eに記載されたシステムアーキテクチャに適用されてもよく、第1のSEPPデバイスと第2のSEPPデバイスとの間に複数の送信経路があってもよい。第1のIPXデバイスは、第1のSEPPデバイスに接続されている。第2のIPXデバイスは、第2のSEPPデバイスに接続されている。

この実施形態では、SEPPデバイスと、SEPPデバイスと相互接続されているIPXデバイスとは、メッセージ変更ポリシーをネゴシエートすることができ、次いで、SEPPデバイスおよびIPXデバイスは、メッセージ変更ポリシーをローカルに構成する。

本実施形態で提供される安全な通信方法は、主に以下の動作を含む。

301：第1のSEPPデバイスは、ネットワーク機能NFデバイスによって送信された第1のシグナリングメッセージを受信する。

302：第1のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーを取得する。

303：第1のSEPPデバイスは、第1のN32メッセージを第1のIPXデバイスに送信し、第1のN32メッセージは、第1のIPXデバイスの第1のシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。

304：第1のIPXデバイスは、第1のSEPPデバイスが送信した第1のN32メッセージを受信し、第1のN32メッセージを初めて変更する。

前述の動作301から304の実施プロセスは、前述の実施形態における動作201から204の実施プロセスと同様である。詳細については、前述の実施形態の説明を参照されたい。

305：第1のIPXデバイスは、第2のIPXデバイスに、初めて変更された第1のN32メッセージを送信する。

この実施形態では、第1のSEPPデバイスと第2のSEPPデバイスとの間のメッセージ送信経路は、2つのIPXデバイス、すなわち、第1のIPXデバイスと第2のIPXデバイスと、を含む。

306：第2のIPXデバイスは、第1のIPXデバイスによって送信された第1のN32メッセージを受信し、第1のN32メッセージを2回目に変更する。

この実施形態では、第1のN32メッセージを受信した後、第2のIPXデバイスは、第1のN32メッセージを第2のSEPPデバイスに送信する必要があると判断することができる。この場合、第2のIPXデバイスは、第2のSEPPデバイスに対応するメッセージ変更ポリシーを判断し、次いで、メッセージ変更ポリシーを用いて第1のN32メッセージを2回目に変更する。変更内容は変更ブロックの形で第1のN32メッセージに付加されてよく、第2のIPXデバイスの秘密鍵を用いて署名される。

第2のIPXデバイスは、SEPPデバイスの識別子とメッセージ変更ポリシーとの間のローカル対応関係に基づいて、第2のSEPPデバイスの識別子に対応するメッセージ変更ポリシーを判断することができる。

307：第2のIPXデバイスは、第2のSEPPデバイスへ、2回目に変更された第1のN32メッセージを送信する。

この実施形態では、第1のN32メッセージは2つのIPXデバイスによって変更されている。2回目に変更された第1のN32メッセージは、2つの変更ブロック、すなわち第1のIPXデバイスの変更ブロックと第2のIPXデバイスの変更ブロックと、を含む。

308：第2のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシー、および第2のIPXデバイスの変更ブロックを取得する。

この実施形態では、第2のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシーをローカルに取得することができる。

第2のIPXデバイスによって送信された第1のN32メッセージを受信した後で、第2のSEPPデバイスは、第1のN32メッセージに対してセキュリティ確認を行うことができる。セキュリティ確認が成功した後、第2のSEPPデバイスは、第1のIPXデバイスの変更ブロック、第2のIPXデバイスの変更ブロック、第1のシグナリングメッセージ、および第1のIPXデバイスのメッセージ変更ポリシーを取得する。

続いて、第2のSEPPデバイスは、第1のIPXデバイスの変更ブロックと第2のIPXデバイスの変更ブロックとを確認する。第2のSEPPデバイスは、最初に第1のIPXデバイスの変更ブロックを確認してもよく、最初に第2のIPXデバイスの変更ブロックを確認してもよい。本実施形態では、第2のIPXデバイスの変更ブロックが、最初に確認される例を説明に用いる。

309：第2のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシーを用いて、2回目に変更された第1のN32メッセージ内の第2のIPXデバイスの変更ブロックを確認する。

本実施形態では、第2のSEPPデバイスは、第2のIPXデバイスによって第1のN32メッセージに対して行われた変更（すなわち、第2のIPXデバイスの変更ブロック）が、第2のIPXデバイスのメッセージ変更ポリシーを満たすかどうかを、確認することができる。変更が第2のIPXデバイスのメッセージ変更ポリシーを満たす場合、確認は成功する。第2のSEPPデバイスはさらに、第1のN32メッセージ内の第1のIPXデバイスの変更ブロックを確認し、以下の動作310を行う。変更が第2のIPXデバイスのメッセージ変更ポリシーを満たさない場合、確認は失敗し、第2のSEPPデバイスは第2のIPXデバイスに失敗応答を返信する。第2のSEPPデバイスは、第1のN32メッセージを破棄することができる。

310：第2のSEPPデバイスは、第1のIPXデバイスのメッセージ変更ポリシーを用いて、第1のN32メッセージ内の第1のIPXデバイスの変更ブロックを確認する。

本実施形態では、第2のSEPPデバイスは、第1のN32メッセージに対して第1のIPXデバイスによって行われた変更（すなわち、第1のIPXデバイスの変更ブロック）が、第1のIPXデバイスのメッセージ変更ポリシーを満たすかどうかを、確認することができる。変更が第1のIPXデバイスのメッセージ変更ポリシーを満たす場合、確認は成功し、第2のSEPPデバイスは以下の動作を行う。変更が第1のIPXデバイスのメッセージ変更ポリシーを満たさない場合、確認は失敗し、第2のSEPPデバイスは失敗応答を返信する。第2のSEPPデバイスは、第1のN32メッセージを破棄することができる。

311：第2のSEPPデバイスは、確認が成功した後に、ローカルネットワーク内のネットワーク機能NFデバイスに、第1のシグナリングメッセージを送信する。

第2のSEPPデバイスは、第1のN32メッセージ内の第1のIPXデバイスの変更ブロックに対する確認が成功した後で、ローカルネットワーク内のNFに第1のシグナリングメッセージを送信する。例えば、第2のSEPPデバイスは、第1のシグナリングメッセージをローカルコアネットワーク内のSMFまたはUDMに送信し、ローカルネットワーク内のNFは第1のシグナリングメッセージを処理する。

この実施形態で提供される技術的解決策では、第1のSEPPデバイスは、N32メッセージを送信するための送信側のSEPPデバイスとして機能し得るか、またはN32メッセージを受信するための受信側のSEPPデバイスとして機能し得る。第1のSEPPデバイスが第2のSEPPデバイスによって送信されたN32メッセージを処理する手順は、前述の実施形態における第2のSEPPデバイスが第1のN32メッセージを処理する手順と同様である。例えば、第1のSEPPデバイスは、受信したN32メッセージ内の変更ブロックを確認することができる。具体的なプロセスについては、前述の関連動作を参照されたい。ここでは詳細を繰り返さない。

これに対応して、第2のSEPPデバイスは、N32メッセージを受信するための受信側のSEPPデバイスとして機能してもよく、またはN32メッセージを送信するための送信側のSEPPデバイスとして機能してもよい。第2のSEPPデバイスがN32メッセージを送信する手順は、前述の実施形態における第1のSEPPデバイスが第1のN32メッセージを送信する手順と同様である。例えば、第2のIPXデバイスのメッセージ変更ポリシーはN32メッセージで搬送される。具体的なプロセスについては、前述の関連動作を参照されたい。ここでは詳細を繰り返さない。

この実施形態で提供される技術的解決策では、送信側のSEPPデバイスは、受信側のSEPPデバイスと送信経路全体でメッセージ変更ポリシーをネゴシエートする必要はないが、送信側のSEPPデバイスと相互接続されたIPXデバイスとメッセージ変更ポリシーをネゴシエートし、次いでN32メッセージを介してIPXデバイスのメッセージ変更ポリシーを受信側のSEPPデバイスに送信する。これにより、SEPPデバイス上で保持されるメッセージ変更ポリシーの数が大幅に削減され、SEPPデバイスのリソースが節約される。

本実施形態で提供される技術的解決策では、メッセージ変更ポリシーは、N32-fメッセージを介して第1のSEPPデバイスと第2のSEPPデバイスとの間で送信される。N32-fメッセージの既存の保護メカニズムが使用されるので、メッセージ変更ポリシーの送信のセキュリティを強化することができ、リソースも節約される。

図4-A1および図4-A2は、本出願の一実施形態による安全な通信方法の概略フローチャートである。

本実施形態は、一例として図1-Eに示すシステムアーキテクチャを使用して説明される。cSEPPデバイスとpSEPPデバイスとの間の送信経路は、cIPXデバイスとpIPXデバイスとを含む。cSEPPデバイスおよびcSEPPデバイスと相互接続されたcIPXデバイスは、メッセージ変更ポリシー1をネゴシエートし、次いで、cSEPPデバイスおよびcIPXデバイスは、メッセージ変更ポリシー1をローカルに構成する。pSEPPデバイスおよびpSEPPデバイスと相互接続されたpIPXデバイスは、メッセージ変更ポリシー2をネゴシエートし、次いで、pSEPPデバイスおよびpIPXデバイスは、メッセージ変更ポリシー2をローカルに構成する。前述のネゴシエーションおよび構成プロセスは、オペレータ、SEPPデバイス、またはIPXデバイスによって実行されてもよい。

図4-A1および図4-A2を参照されたい。本実施形態における安全な通信方法は、以下の動作を含むことができる。

401：cSEPPデバイスは、コアネットワークデバイスによって送信されたHTTP/2リクエストを受信する。

この実施形態では、cSEPPデバイスが位置するローカルネットワーク内のコアネットワークデバイスは、cSEPPデバイスにHTTP/2リクエストを送信する。HTTP/2リクエストは、特定のローミング・シグナリング・メッセージ、例えば、ローミング課金メッセージを搬送してもよい。

402：cSEPPデバイスは、cIPXデバイスのメッセージ変更ポリシーを取得し、N32リクエストメッセージを生成する。

この実施形態では、cSEPPデバイスは、HTTP/2リクエストメッセージがcIPXデバイスを介してpSEPPデバイスに送信される必要があると判断することができる。この場合、cSEPPデバイスは、cIPXデバイスのメッセージ変更ポリシーをローカルに取得する。cSEPPデバイスは、HTTP/2メッセージ内のユーザ識別子やキャリア識別子といった情報に基づいて、HTTP/2リクエストメッセージはcIPXデバイスを介してpSEPPデバイスへ送信される必要があると判断することができる。

任意選択の実施形態では、メッセージ変更ポリシーは、メッセージヘッダ内にあり、変更可能なフィールド、および／または、メッセージヘッダ内にあり、変更不可能なフィールド、を特に含むことができる。例えば、N32リクエストメッセージのメッセージヘッダ内のheader valueフィールドは変更さえ得、メッセージヘッダ内のencBlockIndexフィールドは変更され得ず、メッセージヘッダ内のpayloadフィールドは変更され得る。

任意選択の実施形態では、N32リクエストメッセージは、cIPXデバイスの公開鍵またはセキュリティ証明書をさらに搬送する。cSEPPデバイスは、cIPXデバイスの公開鍵またはセキュリティ証明書を、N32リクエストメッセージのメッセージ本体またはメッセージヘッダに置き、cIPXデバイスにN32リクエストメッセージを送信することができる。

403：cSEPPデバイスは、cIPXデバイスにN32リクエストメッセージを送信する。

この実施形態では、N32リクエストメッセージのメッセージヘッダは、pSEPPデバイスの識別子、例えば、pSEPPデバイスのホスト名、を搬送することができる。加えて、N32リクエストメッセージは、cSEPPデバイスの識別子、例えば、cSEPPデバイスのホスト名、をさらに搬送することができる。

404：cIPXデバイスは、受信したN32リクエストメッセージを変更し、署名認証を行う。

この実施形態では、cIPXデバイスは、cSEPPデバイスによって送信されたN32リクエストメッセージを受信し、次いで、cSEPPデバイスに対応するメッセージ変更ポリシーをローカルに取得し、メッセージ変更ポリシーに従ってN32リクエストメッセージを初めて変更する。cIPXデバイスの変更内容は、変更ブロックの形でN32メッセージに付加される。

cIPXデバイスは、N32リクエストメッセージのメッセージヘッダを変更することができ、例えば、N32リクエストメッセージのメッセージヘッダ内のheader valueフィールドを変更することができる。

N32リクエストメッセージを変更した後で、cIPXデバイスは、秘密鍵を用いて変更ブロックに対して非対称署名を行うことができる。署名付き内容は、JSONウェブ署名（JSON Web Signature，JWS）を搬送する。最終的に生成される変更ブロックは、cIPXデバイスの識別子（cIPX ID）、cIPXデバイスの署名、およびJavaScriptオブジェクト表記（JavaScript Object Notation，JSON）パッチ（patch）を含む。JSONパッチは、cIPXデバイスの変更内容を含む。

405：cIPXデバイスは、pIPXデバイスに変更されたN32リクエストメッセージを送信する。

この実施形態では、変更内容に対する署名を完了したので、cIPXデバイスは、N32リクエストメッセージのメッセージ本体に変更ブロックを配置し、pIPXデバイスに変更ブロックを送信する。

406：pIPXデバイスは、受信したN32リクエストメッセージを変更し、署名認証を行う。

この実施形態では、pIPXデバイスは、cIPXデバイスによって送信されたN32リクエストメッセージを受信し、次いで、N32リクエストメッセージがpSEPPデバイスに送信される必要があることを知る。この場合、pIPXデバイスは、pSEPPデバイスに対応するメッセージ変更ポリシーを取得し、メッセージ変更ポリシーに従ってN32リクエストメッセージを2回目に変更する。pIPXデバイスの変更内容は、変更ブロックの形でN32メッセージのメッセージ本体にも付加される。

pIPXデバイスは、N32リクエストメッセージのメッセージヘッダを変更することができ、例えば、N32リクエストメッセージのメッセージヘッダ内のpayloadフィールドを変更することができる。N32メッセージのメッセージヘッダで搬送されたpSEPPデバイスの識別子に基づいて、N32メッセージがpSEPPデバイスに送信される必要があることを、pIPXデバイスは知ることができる。

N32リクエストメッセージを変更すると、pIPXデバイスは、秘密鍵を用いて変更ブロックに対して非対称署名を行うことができる。署名付き内容は、JSONウェブページ署名を搬送する。最終的に生成される変更ブロックは、pIPXデバイスの識別子（pIPX ID）、pIPXデバイスの署名、およびJSONパッチを含む。JSONパッチは、pIPXデバイスの変更内容を含む。

407：pIPXデバイスは、pSEPPデバイスに、変更されたN32リクエストメッセージを送信する。

本実施形態では、変更内容に対する署名を完了すると、pIPXデバイスは、N32リクエストメッセージのメッセージ本体に変更ブロックを配置し、pSEPPデバイスに変更ブロックを送信する。この場合、N32リクエストメッセージは、HTTP/2リクエストメッセージと、cIPXデバイスの変更ブロックと、pIPXデバイスの変更ブロックとを含む。

408：pSEPPデバイスは、N32リクエストメッセージを確認する。

本実施形態では、pIPXデバイスによって送信された変更されたN32リクエストメッセージを受信した後で、pSEPPデバイスは、cIPXデバイスの変更ブロックとpIPXデバイスの変更ブロックとを検証することができる。具体的な検証プロセスについては、図4-Bを参照されたい。

図4-Bの検証処理は、以下の動作を含む。

A1：pSEPPデバイスは、cIPXデバイスの変更ブロックにおける署名を検証する。

この実施形態では、pSEPPデバイスは、N32メッセージのメッセージ本体からcIPXデバイスの公開鍵を取得することができる。加えて、pSEPPデバイスは、代替として、変更ブロック内のcIPXデバイスの識別子に基づいて、cIPXデバイスの公開鍵をローカルに取得してもよい。

次に、pSEPPデバイスは、公開鍵を使用して、cIPXデバイスの変更ブロックを署名解除し、具体的には、変更ブロックがcIPXデバイスによって生成されたかどうかを検証する。cIPXデバイスによって変更ブロックが生成される場合、動作A2が行われ、具体的には、cIPXデバイスの変更ブロック内の変更内容がcIPXデバイスのメッセージ変更ポリシーを満たしているかどうかを、pSEPPデバイスがさらに検証する。cIPXデバイスによって変更ブロックが生成されない場合、検証は失敗し、pSEPPデバイスはcSEPPデバイスにエラーメッセージを送信する。pSEPPデバイスは、受信したN32リクエストメッセージを破棄することができる。

A2：pSEPPデバイスは、cIPXデバイスの変更内容がcIPXデバイスのメッセージ変更ポリシーを満たすかどうか検証する。

本実施形態では、pSEPPデバイスは、cIPXデバイスのメッセージ変更ポリシー、すなわち前述のメッセージ変更ポリシー1を、N32メッセージのメッセージ本体またはメッセージヘッダから取得することができる。続いて、pSEPPデバイスは、取得したcIPXデバイスのメッセージ変更ポリシーに従って、cIPXデバイスの変更内容を検証（または確認）する。例えば、pSEPPデバイスは、メッセージ変更ポリシーで変更できないフィールドが、cIPXデバイスによって変更されているかどうかを確認する。フィールドが変更されていない場合、検証は成功する。フィールドが変更された場合、検証は失敗し、pSEPPデバイスはcSEPPデバイスにエラーメッセージを送信する。pSEPPデバイスは、受信したN32リクエストメッセージを破棄することができる。

B1：pSEPPデバイスは、pIPXデバイスの変更ブロックにおける署名を検証する。

この実施形態では、pSEPPデバイスは、変更ブロック内のpIPXデバイスの識別子に基づいて、pIPXデバイスの公開鍵をローカルに取得することができる。

次いで、pSEPPデバイスは、公開鍵を使用して、pIPXデバイスの変更ブロックを署名解除し、具体的には、変更ブロックがpIPXデバイスによって生成されたかどうかを検証する。変更ブロックがpIPXデバイスによって生成される場合、動作B2が行われ、具体的には、pIPXデバイスの変更ブロック内の変更内容がpIPXデバイスのメッセージ変更ポリシーを満たしているかどうかを、pSEPPデバイスがさらに検証する。pIPXデバイスによって変更ブロックが生成されない場合、検証は失敗し、pSEPPデバイスはcSEPPデバイスへエラーメッセージを送信する。pSEPPデバイスは、受信したN32リクエストメッセージを破棄することができる。

B2：pSEPPデバイスは、pIPXデバイスの変更内容が、pIPXデバイスのメッセージ変更ポリシーを満たすかどうか検証する。

この実施形態では、pSEPPデバイスは、pIPXデバイスの識別子に基づいて、pIPXデバイスのメッセージ変更ポリシー、すなわち前述のメッセージ変更ポリシー2、をローカルに取得することができる。続いて、pSEPPデバイスは、取得したpIPXデバイスのメッセージ変更ポリシーに従って、pIPXデバイスの変更ブロック内の変更内容を検証（または確認）する。例えば、pSEPPデバイスは、メッセージ変更ポリシーで変更できないフィールドが、pIPXデバイスによって変更されているかどうか検証する。変更できないフィールドが変更されない場合、検証は成功する。変更できないフィールドが変更された場合、検証は失敗し、pSEPPデバイスは、cSEPPデバイスにエラーメッセージを送信する。pSEPPデバイスは、受信したN32リクエストメッセージを破棄することができる。

A2における検証とB2における検証の両方が成功した後、pSEPPデバイスは、ローカルネットワーク内の別のデバイスにN32メッセージ内のHTTP/2リクエストメッセージを送信できる、すなわち、動作409を実行できる。

前述の動作A1-A2およびB1-B2は、pSEPPデバイスによって連続的に実行されてもよく、または前述の動作A1-A2およびB1-B2は、pSEPPデバイスによって並行して実行されてもよい。しかしながら、いずれかの判断結果がnoである場合、pSEPPデバイスはエラーメッセージをcSEPPデバイスに送信する。pSEPPデバイスは、受信したN32リクエストメッセージを破棄することができる。

409：pSEPPデバイスは、ローカルネットワーク内のデバイスに、HTTP/2リクエストメッセージを送信する。

この実施形態では、N32リクエストメッセージを受信した後、pSEPPデバイスは、HTTP/2メッセージを取得するために、対称鍵Aを使用してN32メッセージのメッセージ本体を復号することができる。pSEPPデバイスは、cIPXデバイスの変更ブロックおよびpIPXデバイスの変更ブロックの検証に成功した後で、ローカルネットワーク内のコアネットワークデバイスへ、取得したHTTP/2リクエスト2メッセージを送信することができる。

この実施形態で提供される技術的解決策では、cSEPPデバイスは、pSEPPデバイスと送信経路全体でメッセージ変更ポリシーをネゴシエートする必要はないが、cSEPPデバイスと相互接続されたcIPXデバイスとメッセージ変更ポリシーをネゴシエートし、次いで、cIPXデバイスのメッセージ変更ポリシーを、N32メッセージを介してpSEPPデバイスに送信する。これは、cSEPPデバイス上で保持されるメッセージ変更ポリシーの数を減らし、cSEPPデバイスのリソースを節約する。

これに対応して、pSEPPデバイスは、cSEPPデバイスと相互接続されたcIPXデバイスのメッセージ変更ポリシーを、受信したN32メッセージから直接取得することができ、異なるメッセージ送信経路に対応するメッセージ変更ポリシーをローカルに保持する必要がないので、その結果、cSEPPデバイスのリソースが節約され、cSEPPデバイスのコストも削減される。

この実施形態では、cSEPPデバイスは、N32メッセージを生成するために、受信したHTTP/2リクエストメッセージに対して、フォーマット変換を実行することができる。例えば、cSEPPデバイスは、HTTP/2メッセージをN32メッセージのメッセージ本体にカプセル化することができる。カプセル化プロセスは、暗号化された情報要素（information element，IE）を取得するために、対称鍵AおよびJavaScriptオブジェクト署名暗号化（JavaScript object signing and encryption，JOSE）アルゴリズムを使用して、cSEPPデバイスがdevice HTTP/2メッセージを暗号化すること、を含むことができる。その後、cSEPPデバイスは、暗号化された情報要素、平文（clear text）部分、およびメタデータを、N32メッセージのメッセージ本体にカプセル化することができる。この場合、N32メッセージのメッセージ本体の構造については、図4-Cを参照されたい。N32メッセージのメッセージ本体は、検証ブロックとも呼ばれることもある。メッセージ本体の平文部分は、cIPXデバイスのメッセージ変更ポリシーを搬送することができる。暗号化された情報要素は、HTTP/2リクエストメッセージを搬送する。メタデータ部分は、次ホップの識別子（例えば、cIPXデバイスのID）を搬送することができる。cSEPPデバイスは、メッセージ本体内の平文部分に対して完全性保護を実行することができる。

別の任意選択の実施形態では、cSEPPデバイスは、代替として、暗号化された情報要素IEを取得するために、対称鍵AおよびJavaScriptオブジェクト署名暗号化JOSEアルゴリズムを用いて、cIPXデバイスのHTTP/2メッセージおよびメッセージ変更ポリシーを暗号化してもよい。この場合、暗号化された情報要素は、cIPXデバイスのHTTP/2リクエストメッセージおよびメッセージ変更ポリシーを含む。続いて、cSEPPデバイスは、暗号化された情報要素、平文部分、およびメタデータを、N32メッセージのメッセージ本体にカプセル化することができる（図4-Dに示す）。この場合、平文部分はcIPXの識別子を搬送するが、cIPXデバイスのメッセージ変更ポリシーは搬送しない。

別の任意選択の実施形態では、cSEPPデバイスは、代替として、2つの暗号化された情報要素を取得するために、対称鍵AおよびJavaScriptオブジェクト署名暗号化JOSEアルゴリズムを用いて、cIPXデバイスのHTTP/2メッセージおよびメッセージ変更ポリシーを別々に暗号化してもよい。この場合、2つの暗号化された情報要素は、cIPXデバイスのHTTP/2リクエストメッセージとメッセージ変更ポリシーとを別々に含む。続いて、cSEPPデバイスは、2つの暗号化された情報要素、平文部分、およびメタデータを、N32メッセージのメッセージ本体にカプセル化することができる（図4-Dに示す）。この場合、平文部分はcIPXの識別子を搬送するが、cIPXデバイスのメッセージ変更ポリシーは搬送しない。

以下では、いくつかの装置の実施形態について説明する。

図5は、本出願の一実施形態によるSEPPデバイスの機能の概略図である。

図に示すように、SEPPデバイス500は、主に、第1の受信ユニット510と、第1の取得ユニット520と、第1の送信ユニット530とを含む。

第1の受信ユニット510は、ネットワーク機能NFデバイスによって送信された第1のシグナリングメッセージを受信するように構成されている。

第1の取得ユニット520は、IP交換サービスIPXデバイスのメッセージ変更ポリシーを取得するように構成されている。

第1の送信ユニット530は、第1のN32メッセージをIPXデバイスに送信するように構成されており、第1のN32メッセージは、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを搬送する。

本実施形態で提供されるSEPPデバイスは、前述の方法実施形態で提供される安全な通信方法で使用することができる。具体的な詳細および有益な効果については、前述の実施形態を参照されたい。

第1の受信ユニット510と第1の取得ユニット520と第1の送信ユニット530との協働により、本実施形態で提供されるSEPPデバイスは、送信側のSEPPデバイスと受信側のSEPPデバイスとの間でIPXデバイスのメッセージ変更ポリシーの安全な送信を実現することができ、その結果、送信側のSEPPデバイスと受信側のSEPPデバイスとの間の通信のセキュリティが向上する。

可能な実施形態では、SEPPデバイス内の第1の取得ユニット520は、IPXデバイスのセキュリティ証明書を取得するようにさらに構成されてもよい。この場合、第1の送信ユニット530によって送信される第1のN32メッセージは、IPXデバイスのセキュリティ証明書を搬送する。

可能な実施形態では、SEPPデバイスの第1の送信ユニット530は、以下の方法で第1のN32メッセージを送信してもよい。
第1の送信ユニット530は、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを第1のN32メッセージのメッセージ本体にカプセル化し、第1のシグナリングメッセージおよびIPXデバイスのメッセージ変更ポリシーを、IPXデバイスに送信する。

可能な実施形態では、IPXデバイスのメッセージ変更ポリシーは、第1のN32メッセージのメッセージ本体の平文部分で搬送されてもよい。

可能な実施形態では、第1の取得ユニット520は、IPXデバイスのメッセージ変更ポリシーを、ローカル構成から取得してもよい。

可能な実施形態では、SEPPデバイスの第1の受信ユニット510は、IPXデバイスによって送信された第2のN32メッセージを受信するようにさらに構成されており、第2のN32メッセージは、第2のシグナリングメッセージおよびIPXデバイスの変更内容を搬送する。

引き続き図5を参照されたい。本実施形態で提供されるSEPPデバイスは、IPXデバイスのメッセージ変更ポリシーに従って、第2のN32メッセージ内のIPXデバイスの変更内容を確認するように構成された、第1の確認ユニット540をさらに含んでいてよい。さらに、第1の送信ユニット530は、第1の確認ユニット540による確認が成功した後に、第2のシグナリングメッセージをネットワーク機能NFデバイスに送信する。

図6は、本出願の一実施形態によるSEPPデバイスの機能の概略図である。

図に示すように、SEPPデバイス600は、主に、第2の受信ユニット610と、第2の確認ユニット620と、第2の送信ユニット630とを含む。

第2の受信ユニット610はN32メッセージを受信するように構成されており、N32メッセージはIPXデバイスのシグナリングメッセージおよびメッセージ変更ポリシーを搬送する。第2の確認ユニット620は、IPXデバイスのメッセージ変更ポリシーに従って、N32メッセージを確認するように構成されている。第2の送信ユニット630は、第2の確認ユニット620によってN32メッセージに対して行われた確認が成功した後に、ネットワーク機能NFデバイスにシグナリングメッセージを送信するように構成されている。

本実施形態で提供されるSEPPデバイスは、前述の方法実施形態で提供される安全な通信方法で使用することができる。具体的な詳細および有益な効果については、前述の実施形態を参照されたい。

本実施形態で提供されるSEPPデバイスは、第2の受信ユニット610と第2の確認ユニット620と第2の送信ユニット630とが協働することで、送信側のSEPPデバイスと受信側のSEPPデバイスとの間でIPXデバイスのメッセージ変更ポリシーを安全に送信することができ、その結果、送信側のSEPPデバイスと受信側のSEPPデバイスとの間の通信のセキュリティが向上する。

可能な実施形態では、SEPPデバイス内の第2の受信ユニット610によって受信されるN32メッセージは、IPXデバイスのセキュリティ証明書をさらに搬送する。第2の確認ユニット620がメッセージ変更ポリシーに従ってN32メッセージを確認することは、
第2の確認ユニット620が、IPXデバイスのセキュリティ証明書に基づいて、N32メッセージ内のIPXデバイスの変更ブロックにおける署名を確認することを、含む。確認が成功した後、第2の確認ユニット620は、メッセージ変更ポリシーに従って、IPXデバイスの変更ブロックにおける変更内容をさらに確認する。

引き続き図5を参照されたい。本実施形態で提供されるSEPPデバイスは、IPXデバイスのメッセージ変更ポリシーを取得するために、N32メッセージのメッセージ本体を復号するように構成された、復号ユニット640をさらに含むことができる。

可能な実施形態では、SEPPデバイスの復号ユニット640は、N32メッセージで搬送されるシグナリングメッセージを取得するために、N32メッセージのメッセージ本体を復号するようにさらに構成される。

図7は、本出願の一実施形態によるSEPPデバイスの機能の概略図である。

図に示すように、SEPPデバイス700は、主に、第3の受信ユニット710と、第3の取得ユニット720と、第3の確認ユニット730と、第3の送信ユニット740とを含む。

第3の受信ユニット710は第1のIPXデバイスによって送信されたN32メッセージを受信するように構成されており、N32メッセージはシグナリングメッセージを搬送する。

第3の取得ユニット720は、第1のIPXデバイスのメッセージ変更ポリシーを取得するように構成されている。

第3の確認ユニット730は、メッセージ変更ポリシーに従って、N32メッセージを確認するように構成される。

第3の送信ユニット740は、第3の確認ユニット730によって実行されたN32メッセージの確認が成功した後に、ネットワーク機能NFデバイスにシグナリングメッセージを送信するように構成される。

本実施形態で提供されるSEPPデバイスは、前述の方法実施形態で提供される安全な通信方法で使用することができる。具体的な詳細および有益な効果については、前述の実施形態を参照されたい。

第3の受信ユニット710と、第3の取得ユニット720と、第3の確認ユニット730と、第3の送信ユニット740とが協働することによって、本実施形態で提供されるSEPPデバイスは、送信側のSEPPデバイスと受信側のSEPPデバイスとの間でIPXデバイスのメッセージ変更ポリシーを安全に送信することを実現することができ、その結果、送信側のSEPPデバイスと受信側のSEPPデバイスとの間の通信のセキュリティが向上する。

可能な実施形態では、第3の受信ユニット710によって受信されるN32メッセージは、第1のIPXデバイスの変更内容をさらに搬送する。第3の確認ユニット730は、以下の方法でN32メッセージを確認することができる：第3の確認ユニット730は、メッセージ変更ポリシーに従って、N32メッセージ内の第1のIPXデバイスの変更内容を確認する。

可能な実施形態では、第3の受信ユニット710によって受信されるN32メッセージは、第2のIPXデバイスのセキュリティ証明書、第2のIPXデバイスのメッセージ変更ポリシー、および第2のIPXデバイスの変更ブロック、をさらに搬送する。この場合、第3の確認ユニット730は、セキュリティ証明書を用いて第2のIPXデバイスの変更ブロックを確認するように、さらに構成されている。確認が成功すると、第3の確認ユニットは、第2のIPXデバイスのメッセージ変更ポリシーに従って、第2のIPXデバイスの変更ブロックにおける変更内容を確認する。

可能な実施形態では、第1のSEPPデバイスの第3の受信ユニット710は、第2のSEPPデバイスによって送信された通知メッセージを受信するようにさらに構成されており、通知メッセージは第2のIPXデバイスのメッセージ変更ポリシーを搬送する。

可能な実施形態では、第1のSEPPデバイスはcSEPPデバイスであり、第2のSEPPデバイスはpSEPPデバイスである。可能な実施形態では、第1のSEPPデバイスはvSEPPデバイスであり、第2のSEPPデバイスはhSEPPデバイスである。

図8は、本出願の一実施形態による通信装置の構造の概略図であり、図9は、通信装置内の基板830のインターフェースの概略図である。

図に示すように、通信装置は、主に、キャビネット820と、キャビネット内に設置された基板830とを含む。基板は、チップおよび電子部品を含み、通信サービスを提供することができる。基板830の数量は、実際の要件に基づいて増減することができ、この実施形態では基板830の数量は限定されない。また、キャビネット820には、キャビネットドア821がさらに設置されている。

図9に示すように、基板830は、複数の入出力インターフェース、例えば、外部ディスプレイと接続するためのディスプレイインターフェース831と、通信ネットワークと接続するためのネットワークインターフェース832と、ユニバーサルシリアルバス（Universal Serial Bus，USB）インターフェース833とを備える。

また、基板830は、電源に接続されたパワーインターフェース835、および熱を放散するための放熱ポート834などをさらに含む。

通信装置は、異なる基板830を設置することで異なる機能を実現する。例えば、通信装置は、本出願の実施形態におけるSEPPデバイスの機能を実装することができる。基板830には、汎用プロセッサ、制御チップ、論理回路等の制御素子が搭載されている。また、記憶チップ等のメモリが基板830に搭載されてもよい。プロセッサおよびメモリは、関連する通信インターフェースと協働して、本出願の実施形態においてSEPPデバイスによって実行することができる任意の方法の一部または全部の動作を実行することができる。

図10は、本発明の一実施形態によるSEPPデバイスのハードウェアの構造の概略図である。

本実施形態で提供されるSEPPデバイスは、プロセッサ1001、メモリ1002、バス1003、入力デバイス1004、出力デバイス1005、およびネットワークインターフェース1006を含む、汎用コンピュータハードウェアを使用することができる。

具体的には、メモリ1002は、揮発性および／または不揮発性メモリ、例えば、読み出し専用メモリおよび／またはランダムアクセスメモリの形態のコンピュータ記憶媒体を含むことができる。メモリ1002は、オペレーティングシステム、アプリケーションプログラム、別のプログラムモジュール、実行可能コード、およびプログラムデータを格納することができる。

入力デバイス1004は、SEPPデバイスにコマンドおよび情報を入力するように構成されてもよい。入力デバイス1004は、例えば、キーボード、またはマウス、トラックボール、タッチパッド、マイクロフォン、ジョイスティック、ゲームパッド、衛星テレビアンテナ、スキャナなどのポインタデバイスであってもよい。これらの入力デバイスは、バス1003を介してプロセッサ1001に接続されてもよい。

出力デバイス1005は、SEPPデバイスによって情報を出力するように構成されてもよい。モニタに加えて、出力デバイス1005は、別の周辺出力デバイス、例えば、スピーカおよび／または印刷デバイスであってもよい。これらの出力デバイスはまた、バス1003を介してプロセッサ1001に接続されてもよい。

SEPPデバイスは、ネットワークインターフェース1006を介して、例えばLAN（Local Area Network，LAN）に接続された通信ネットワークに接続されてもよい。ネットワーク接続環境では、SEPPデバイスに記憶されたコンピュータ実行可能命令は、遠隔記憶デバイスに格納されてもよく、ローカルに格納されることに限定されない。

SEPPデバイス内のプロセッサ1001がメモリ1002に格納された実行可能コードまたはアプリケーションプログラムを実行すると、SEPPデバイスは、前述の方法実施形態におけるSEPPデバイス側の方法動作を実行することができ、例えば、動作201，202，301，307、および401から403を実行することができる。具体的な実行プロセスについては、前述の方法の実施形態を参照されたい。ここでは詳細を繰り返さない。

本出願の一実施形態は、コンピュータ可読記憶媒体をさらに提供する。コンピュータ可読記憶媒体は、コンピュータプログラムを格納する。コンピュータプログラムがハードウェア（プロセッサなど）によって実行される場合、本出願の実施形態においてSEPPデバイスによって実行することができる任意の方法の一部または全部の動作を実施することができる。

本出願の一実施形態は、命令を含むコンピュータプログラム製品をさらに提供する。コンピュータプログラム製品がコンピュータデバイス上で実行されると、コンピュータデバイスは、SEPPデバイスによって実行され得る任意の方法の一部または全部の動作を実行することが可能になる。

前述の実施形態の一部または全部は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせを使用して実施されてもよい。ソフトウェアを使用して実施形態を実装する場合は、実施形態の全部または一部がコンピュータプログラム製品の形で実装されてよい。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータ上でロードされて実行されるとき、本出願の実施形態による手順または機能の全部または一部が生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラム可能な装置であってよい。コンピュータ命令はコンピュータ可読記憶媒体に保管されてよく、またはあるコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体へ送信されてよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンタから別のウェブサイト、コンピュータ、サーバ、またはデータセンタへ、有線（例えば、同軸ケーブル、光ファイバ、デジタル加入者線）方式で、または無線（例えば、赤外線、電波、マイクロ波）方式で、送信されてよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な何らかの使用可能な媒体であってよく、または1つまたは複数の使用可能な媒体を統合したデータ記憶デバイス、例えばサーバまたはデータセンタであってよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、または磁気テープ）、光学媒体（例えば、光ディスク）、半導体媒体（例えば、ソリッドステートドライブ）などであり得る。前述の実施形態では、各実施形態の説明にはそれぞれの焦点がある。ある実施形態で詳細に説明されていない部分については、他の実施形態の関連する説明を参照されたい。

前述の実施形態では、各実施形態の説明にはそれぞれの焦点がある。ある実施形態で詳細に説明されていない部分については、他の実施形態の関連する説明を参照されたい。

この出願で提供されるいくつかの実施形態では、開示された装置が他の態様で実装され得ることが理解されるべきである。例えば、説明されている装置の実施形態は例にすぎない。例えば、ユニットへの分割は論理的機能の分割にすぎず、実際に実施する際には他の分割であってもよい。例えば、複数のユニットまたはコンポーネントが組み合わされるか、または別のシステムに統合されてもよく、またはいくつかの特徴は無視されてよく、または実行されなくてもよい。さらに、表示または説明された相互間接結合または直接結合または通信接続は、いくつかのインターフェースを使用して実装されてもよい。装置間またはユニット間の間接結合または通信接続は、電子的形態またはその他の形態で実施され得る。

分離されている部分として説明されている部位が物理的に分離されてもよいし、物理的に分離されなくてもよく、部位として表示されている部分が物理的部位であってもよいし、物理的部位でなくてもよいし、一箇所に位置してもよいし、複数のネットワークユニットに分散してもよい。ユニットの一部または全部は、実施形態の解決策の目的を達成するために実際の必要に従って選択されてもよい。

これに加えて、本出願の実施形態の機能ユニットが1つの処理部に組み込まれてもよいし、部位の各々が物理的に単独で存在してもよいし、2つ以上の部位が1つの部位に組み込まれる。統合ユニットは、ハードウェアの形態で実装されてもよく、またはソフトウェア機能ユニットの形態で実装されてもよい。

統合ユニットが、ソフトウェア機能ユニットの形態で実施され、独立した製品として販売または使用される場合、統合ユニットは、コンピュータ可読記憶媒体に格納されてもよい。そのような理解に基づいて、本出願の技術的解決策は本質的に、または従来の技術に寄与する部分は、または技術的解決策の全部または一部は、ソフトウェア製品の形態で実装されてもよい。コンピュータソフトウェア製品は、記憶媒体に格納され、本出願の実施形態における方法の動作の全部または一部を実行するようにコンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであってもよい）に命令するためのいくつかの命令を含む。

500 セキュリティエッジ保護プロキシSEPPデバイス
510 第1の受信ユニット
520 第1の取得ユニット
530 第1の送信ユニット
540 第1の確認ユニット
600 SEPPデバイス
610 第2の受信ユニット
620 第2の確認ユニット
630 第2の送信ユニット
640 復号ユニット
700 SEPPデバイス
710 第3の受信ユニット
720 第3の取得ユニット
730 第3の確認ユニット
740 第3の送信ユニット
820 キャビネット
821 キャビネットドア
830 基板
831 ディスプレイインターフェース
832 ネットワークインターフェース
833 インターフェース
834 放熱ポート
835 パワーインターフェース
1001 プロセッサ
1002 メモリ
1003 バス
1004 入力デバイス
1005 出力デバイス
1006 ネットワークインターフェース

214：第1のSEPPデバイスは、第2のIPXデバイスのメッセージ変更ポリシーに従って第2のN32メッセージ内の変更ブロックを確認する。

別の任意選択の実施形態では、cSEPPデバイスは、代替として、2つの暗号化された情報要素を取得するために、対称鍵AおよびJavaScriptオブジェクト署名暗号化JOSEアルゴリズムを用いて、cIPXデバイスのHTTP/2メッセージおよびメッセージ変更ポリシーを別々に暗号化してもよい。この場合、2つの暗号化された情報要素は、cIPXデバイスのHTTP/2リクエストメッセージとメッセージ変更ポリシーとを別々に含む。続いて、cSEPPデバイスは、2つの暗号化された情報要素、平文部分、およびメタデータを、N32メッセージのメッセージ本体にカプセル化することができる（図4-Eに示す）。この場合、平文部分はcIPXの識別子を搬送するが、cIPXデバイスのメッセージ変更ポリシーは搬送しない。

引き続き図6を参照されたい。本実施形態で提供されるSEPPデバイスは、IPXデバイスのメッセージ変更ポリシーを取得するために、N32メッセージのメッセージ本体を復号するように構成された、復号ユニット640をさらに含むことができる。

Claims (12)

1. 安全な通信方法であって、
   第2のセキュリティエッジ保護プロキシSEPPデバイスにより、第2のIP交換サービスIPXデバイスによって送信されたN32メッセージを受信するステップであって、前記N32メッセージは、第1のシグナリングメッセージ、第1のIPXデバイスの変更ブロック、および前記第2のIPXデバイスの変更ブロックを搬送する、ステップと、
   前記第2のSEPPデバイスにより、前記第1のIPXデバイスのメッセージ変更ポリシーを取得し、前記第2のSEPPデバイスにより、前記第1のIPXデバイスの前記メッセージ変更ポリシーに従って、前記N32メッセージ内の前記第1のIPXデバイスの前記変更ブロックを確認するステップと、
   前記第2のSEPPデバイスにより、前記第2のIPXデバイスのメッセージ変更ポリシーを取得し、前記第2のSEPPデバイスにより、前記第2のIPXデバイスの前記メッセージ変更ポリシーに従って、前記N32メッセージ内の前記第2のIPXデバイスの前記変更ブロックを確認するステップと、
   前記第2のSEPPデバイスにより、前記第1のIPXデバイスの前記変更ブロックの前記確認、および前記第2のIPXデバイスの前記変更ブロックの前記確認が成功した後で、前記第1のシグナリングメッセージをネットワーク機能NFデバイスに送信するステップと
   を含む方法。
2. 前記第2のSEPPデバイスにより、前記第1のIPXデバイスのメッセージ変更ポリシーを取得する前記ステップは、
   前記第2のSEPPデバイスにより、第1のSEPPデバイスから第1の通知メッセージを受信するステップであって、前記第1の通知メッセージは、前記第1のIPXデバイスの前記メッセージ変更ポリシーを搬送する、ステップと、
   前記第2のSEPPデバイスにより、前記第1の通知メッセージから前記第1のIPXデバイスの前記メッセージ変更ポリシーを取得するステップと
   を含む、請求項1に記載の方法。
3. 前記第2のSEPPデバイスにより、第2の通知メッセージを第1のSEPPデバイスに送信するステップであって、前記第2の通知メッセージは、前記第2のIPXデバイスの前記メッセージ変更ポリシーを搬送する、ステップ
   をさらに含む、請求項1または2に記載の方法。
4. 前記第2のSEPPデバイスにより、前記第2のIPXデバイスのメッセージ変更ポリシーを取得する前記ステップは、
   前記第2のSEPPデバイスにより、前記第2のIPXデバイスの前記メッセージ変更ポリシーを、ローカルで取得するステップ
   を含む、請求項1から3のいずれか一項に記載の方法。
5. 前記N32メッセージは、前記第1のIPXデバイスのセキュリティ証明書をさらに搬送し、
   前記第2のSEPPデバイスにより、前記第1のIPXデバイスの前記メッセージ変更ポリシーに従って、前記N32メッセージ内の前記第1のIPXデバイスの前記変更ブロックを確認する前記ステップの前に、前記方法は、
   前記第2のSEPPデバイスにより、前記セキュリティ証明書を用いて、前記第1のIPXデバイスの変更内容を確認するステップと、
   前記確認が成功した後で、前記第2のSEPPデバイスにより、前記第1のIPXデバイスの前記メッセージ変更ポリシーに従って、前記N32メッセージ内の前記第1のIPXデバイスの前記変更ブロックを確認する前記ステップを実行するステップと
   をさらに含む、請求項1から4のいずれか一項に記載の方法。
6. 前記第2のSEPPデバイスにより、前記ネットワーク機能NFデバイスから第2のシグナリングメッセージを受信するステップと、
   前記第2のSEPPデバイスにより、前記第2のシグナリングメッセージを前記第2のIPXデバイスに送信するステップと
   をさらに含む、請求項1から5のいずれか一項に記載の方法。
7. 前記第1のIPXデバイスの前記変更ブロックの前記確認および／または前記第2のIPXデバイスの前記変更ブロックの前記確認の失敗の後に、前記第2のSEPPデバイスにより、失敗応答を返信するステップ
   をさらに含む、請求項1から6のいずれか一項に記載の方法。
8. 安全な通信方法であって、
   第1のセキュリティエッジ保護プロキシSEPPデバイスにより、第1のIP交換IPXデバイスのメッセージ変更ポリシーを取得するステップと、
   前記第1のSEPPデバイスにより、前記第1のIPXデバイスの前記メッセージ変更ポリシーを第2のSEPPデバイスに送信するステップと、
   前記第1のSEPPデバイスにより、前記第2のSEPPデバイスから第2のIPXデバイスのメッセージ変更ポリシーを取得するステップと
   を含む方法。
9. 第1のセキュリティエッジ保護プロキシSEPPデバイスにより、第1のIP交換IPXデバイスのメッセージ変更ポリシーを取得する前記ステップは、
   前記第1のSEPPデバイスにより、前記第1のIPXデバイスの前記メッセージ変更ポリシーを、ローカルで取得するステップ
   を含む、請求項8に記載の方法。
10. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体はコンピュータプログラムを格納し、前記コンピュータプログラムがプロセッサによって実行されると、請求項1から9のいずれか一項に記載の方法が実施される、コンピュータ可読記憶媒体。
11. セキュリティエッジ保護プロキシSEPPデバイスであって、互いに接続された少なくとも1つのプロセッサおよびメモリを含み、前記メモリはコンピュータプログラムコードを格納し、前記プロセッサは、前記メモリ内の前記コンピュータプログラムコードを呼び出して実行し、前記SEPPデバイスが請求項1から9のいずれか一項に記載の方法を実行することを可能にする、SEPPデバイス。
12. 安全な通信のためのシステムであって、
    コアネットワーク機能デバイスと、セキュリティエッジ保護プロキシSEPPデバイスとを含み、
    前記コアネットワーク機能デバイスは、前記SEPPデバイスによって送信されたシグナリングメッセージを受信するように構成され、
    前記SEPPデバイスは、請求項1から9のいずれか一項に記載の方法を実行するように構成される、システム。

Images