JP2023548370A - 受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体 - Google Patents

受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体 Download PDF

Info

Publication number
JP2023548370A
JP2023548370A JP2023527034A JP2023527034A JP2023548370A JP 2023548370 A JP2023548370 A JP 2023548370A JP 2023527034 A JP2023527034 A JP 2023527034A JP 2023527034 A JP2023527034 A JP 2023527034A JP 2023548370 A JP2023548370 A JP 2023548370A
Authority
JP
Japan
Prior art keywords
network
network node
message
identifier
rate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023527034A
Other languages
English (en)
Other versions
JPWO2022098404A5 (ja
Inventor
ラジプット，ジャイ
マハランク，シャシキラン・バラチャンドラ
ジェイン，アミット
Original Assignee
オラクル・インターナショナル・コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/129,487 external-priority patent/US11528251B2/en
Priority claimed from US17/134,635 external-priority patent/US11943616B2/en
Application filed by オラクル・インターナショナル・コーポレイション filed Critical オラクル・インターナショナル・コーポレイション
Publication of JP2023548370A publication Critical patent/JP2023548370A/ja
Publication of JPWO2022098404A5 publication Critical patent/JPWO2022098404A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体について開示する。１つの方法は、第１のネットワークの第１のネットワークノードにおいて実行され、第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第２のネットワークノードまたは第２のネットワークを識別する識別子を取得することと、第２のネットワークノードまたは第２のネットワークからリクエストメッセージを受信することと、識別子を利用して、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断することと、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行することとを含む。

Description

優先権の主張
本願は、２０２０年１２月２８日に出願された米国特許出願第１７／１３４，６３５号、２０２０年１２月２１日に出願された米国特許出願第１７／１２９，４８７号、２０２０年１１月１３日に出願されたインド仮出願第２０２０４１０４９６１４号、および２０２０年１１月６日に出願されたインド仮出願第２０２０４１０４８５５２号の優先権の利益を主張するものであり、これらのすべての開示内容を引用により本明細書に援用する。
技術分野
本明細書において説明する主題は、５Ｇ通信ネットワークにおけるセキュリティを向上させることに関する。特に、本明細書において説明する主題は、受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体に関する。
背景
５Ｇ電気通信ネットワークでは、サービスを提供するネットワークノードは、プロデューサーＮＦ（ネットワーク機能）と称される。サービスを利用するネットワークノードは、コンシューマーＮＦと称される。ネットワーク機能は、サービスを利用しているかサービスを提供しているかに応じて、プロデューサーＮＦにもコンシューマーＮＦにもなり得る。
所与のプロデューサーＮＦは、多くのサービスエンドポイントを有し得る。ここで、サービスエンドポイントとは、プロデューサーＮＦがホストする１つ以上のＮＦインスタンスの接続ポイントである。サービスエンドポイントは、ＩＰ（インターネットプロトコル）アドレスとポート番号との組合せ、またはプロデューサーＮＦをホストするネットワークノード上のＩＰアドレスおよびポート番号に変換される完全修飾ドメイン名によって識別される。ＮＦインスタンスは、サービスを提供するプロデューサーＮＦのインスタンスである。所与のプロデューサーＮＦは、２つ以上のＮＦインスタンスを含み得る。なお、複数のＮＦインスタンスが同じサービスエンドポイントを共有できる。
プロデューサーＮＦは、ＮＲＦ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｒｅｐｏｓｉｔｏｒｙ Ｆｕｎｃｔｉｏｎ）に登録される。ＮＲＦは、各ＮＦインスタンスがサポートするサービスを識別する利用可能なＮＦインスタンスのサービスプロファイルを保持する。コンシューマーＮＦは、ＮＲＦに登録されているプロデューサーＮＦインスタンスについての情報を受信するようにサブスクライブできる。コンシューマーＮＦに加えて、ＮＦサービスインスタンスについての情報を受信するようにサブスクライブできる別の種類のネットワークノードは、ＳＣＰ（Ｓｅｒｖｉｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｘｙ）である。ＳＣＰは、ＮＲＦを介してサブスクライブし、プロデューサーＮＦサービスインスタンスに関するリーチャビリティとサービスプロファイル情報とを取得する。コンシューマーＮＦは、Ｓｅｒｖｉｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｘｙに接続し、Ｓｅｒｖｉｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｏｘｙは、要求されたサービスを提供するプロデューサーＮＦサービスインスタンス間でトラフィックの負荷を分散する、または、宛先であるプロデューサーＮＦインスタンスにトラフィックを直接ルーティングする。
ＳＣＰに加えて、プロデューサーＮＦとコンシューマーＮＦとの間でトラフィックをルーティング中間プロキシノードまたはネットワークノード群のその他の例として、ＳＥＰＰ（セキュリティエッジ保護プロキシ）、サービスゲートウェイ、および５Ｇサービスメッシュにあるノードなどが挙げられる。ＳＥＰＰは、異なる５Ｇ ＰＬＭＮ（公衆陸上移動体通信網）間で交換されるコントロールプレーンのトラフィックを保護するために用いられるネットワークノードである。このように、ＳＥＰＰは、すべてのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅメッセージについてメッセージフィルタリング、ポリシング、およびトポロジ隠蔽を実行する。
しかしながら、１つ以上のＮＦにおけるセキュリティ対策の改善が必要とされている。
概要
受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体について開示する。受信メッセージレート制限のための１つの例示的な方法は、第１のネットワークの第１のネットワークノードにおいて実行され、第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第２のネットワークノードまたは第２のネットワークを識別する識別子を取得することと、第２のネットワークノードまたは第２のネットワークからリクエストメッセージを受信することと、識別子を利用して、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断することと、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行することとを含む。
受信メッセージレート制限のための１つの例示的なシステムは、少なくとも１つのプロセッサと、メモリとを備える、第１のネットワークの第１のネットワークノードを備える。第１のノードは、第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第２のネットワークノードまたは第２のネットワークを識別する識別子を取得し、第２のネットワークノードまたは第２のネットワークからリクエストメッセージを受信し、識別子を利用して、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断し、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行するように構成される。
１つの例示的な非一時的なコンピュータ読み取り可能な媒体は、コンピュータにより実行可能な命令を含み、非一時的なコンピュータ読み取り可能な媒体に含まれる当該コンピュータにより実行可能な命令は、少なくとも１つのコンピュータの少なくとも１つのプロセッサによって実行されると、当該少なくとも１つのコンピュータにステップを実行させ、当該ステップは、第１のネットワークの第１のネットワークノードにおいて、第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、第２のネットワークノードまたは第２のネットワークを識別する識別子を取得するステップと、第２のネットワークノードまたは第２のネットワークからリクエストメッセージを受信するステップと、識別子を利用して、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断するステップと、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行するステップとを含む。
本明細書において説明する主題の態様によると、ＴＬＳメッセージから識別子を取得することは、ＴＬＳメッセージに含まれる証明書（たとえば、Ｘ．５０９ｖ３証明書）から識別子を取得することを含んでもよい。たとえば、ＴＬＳメッセージにあるＸ．５０９ｖ３証明書は、送信者のアイデンティティに対応付けられたＦＱＤＮを含むサブジェクトフィールドまたはサブジェクトの別名フィールドを含んでもよい。この例では、ＦＱＤＮは、ネットワークノード識別子またはネットワーク識別子を含むまたは表してもよく、たとえば、ネットワーク識別子は、「５ｇｃ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐ（登録商標）ｎｅｔｗｏｒｋ．ｏｒｇ」のようなフォーマットで格納されてもよい。ここで、「＜ＭＮＣ＞」および「＜ＭＣＣ＞」フィールドは、事業者のＰＬＭＮのＭＮＣおよびＭＣＣに対応する。
本明細書において説明する主題の態様によると、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断することは、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートを取得することと、第２のネットワークノードまたは第２のネットワークに対応付けられた現在の受信メッセージレートを取得することと、現在の受信メッセージレートが許容受信メッセージレートを満たすまたは上回ると判断するために現在の受信メッセージレートと許容受信メッセージレートとを比較することとを含んでもよい。
本明細書において説明する主題の態様によると、第２のネットワークノードまたは第２のネットワークに対応付けられた現在の受信メッセージレートを取得することは、第２のネットワークにある複数のＳＥＰＰのメッセージレートを追跡または導出して、第２のネットワークに対応付けられた現在の受信レートを判断することを含んでもよい。たとえば、レート制限が送信元のネットワーク識別子に基づくと仮定すると、ＳＥＰＰ１２６は、複数のＮ３２－ｆインタフェース接続をまたいで受信メッセージレートを追跡してもよく、同じネットワーク識別子に対応付けられた複数のＳＥＰＰの受信メッセージレートを複合してもよく、ネットワーク識別子に対応付けられた複合受信メッセージレートをネットワーク識別子に対応付けられた所定の許容受信メッセージレートと比較してもよい。
本明細書において説明する主題の態様によると、レート制限動作は、リクエストメッセージを破棄すること、メッセージの一部を破棄するためにスロットルレートを生成もしくは変更すること、または、ネットワーク事業者または管理システムに通知することを含んでもよい。
本明細書において説明する主題は、ハードウェア、ソフトウェア、ファームウェア、または、それらの任意の組合せで実現されてもよい。このように、「機能」、「ノード」、または「モジュール」という用語は、本明細書において用いられる場合、記載の特徴を実現するためのハードウェア（ソフトウェアおよび／またはファームウェアコンポーネントも含んでもよい）を指す。一例示的な実施態様では、本明細書において説明する主題は、コンピュータにより実行可能な命令を記憶したコンピュータ読み取り可能な媒体を用いて実現されてもよい。当該命令は、コンピュータのプロセッサによって実行されると、本発明のいずれか１つ以上のステップを実行させるようにコンピュータを制御する。本明細書において説明する主題を実現するのに適した例示的なコンピュータ読み取り可能な媒体として、ディスク記憶装置、チップ記憶装置、プログラム可能な論理回路、および特定用途向け集積回路など、非一時的なコンピュータ読み取り可能な媒体などが挙げられる。これに加えて、本明細書において説明する主題を実現するコンピュータ読み取り可能な媒体は、１つのデバイスまたは１つのコンピューティングプラットフォーム上に位置してもよいし、複数のデバイスまたは複数のコンピューティングプラットフォーム間で分散されてもよい。これに加えて、本明細書において説明する主題を実現するコンピュータ読み取り可能な媒体は、１つのデバイスまたは１つのコンピューティングプラットフォーム上に位置してもよいし、複数のデバイスまたは複数のコンピューティングプラットフォーム間で分散されてもよい。
ここで、添付の図面を参照して本明細書において説明する主題について説明する。
例示的な５Ｇネットワークアーキテクチャを示すネットワーク図である。 ＴＬＳ（トランスポートレイヤーセキュリティ）を用いたＮ３２－ｆインタフェース接続を示す図である。 受信メッセージレート制限のための例示的なノードを示す図である。 Ｎ３２－ｆインタフェースに関連するＴＬＳハンドシェイクを示すメッセージフロー図である。 例示的なメッセージレート関連データを示す図である。 受信メッセージレート制限の例を示すメッセージフロー図である。 受信メッセージレート制限のための例示的な工程を示すフローチャートである。
詳細な説明
本明細書において説明する主題の様々な実施の形態について、今から詳細に説明し、その例を添付の図面に示す。可能な限り、同一の要素には同一の参照番号を付す。可能な限り図面全体で同じまたは同一の部品には同じ参照番号を付す。
図１は、例示的な５Ｇシステムネットワークアーキテクチャを示すブロック図である。図１のアーキテクチャは、同じＨＰＬＭＮ（ホーム側公衆陸上移動体通信網）に位置し得るＮＲＦ１００とＳＣＰ１０１とを備える。上述したように、ＮＲＦ１００は、利用可能なプロデューサーＮＦサービスインスタンスのプロファイルおよびこれらがサポートするサービスを保持し、コンシューマーＮＦまたはＳＣＰが新しい／更新されたプロデューサーＮＦサービスインスタンスをサブスクライブすることまたは新しい／更新されたプロデューサーＮＦサービスインスタンスの登録について通知されることを可能にする。また、ＳＣＰ１０１は、サービス検出およびプロデューサーＮＦインスタンスの選択をサポートし得る。ＳＣＰ１０１は、コンシューマーＮＦとプロデューサーＮＦとの接続の負荷分散を行い得る。これに加えて、本明細書に記載の技法を用いて、ＳＣＰ１０１は、ＮＦの位置に基づいた、好ましい選択およびルーティングを行い得る。
ＮＲＦ１００は、ＮＦまたはプロデューサーＮＦインスタンスのサービスプロファイルのリポジトリである。プロデューサーＮＦインスタンスと通信を行うために、コンシューマーＮＦまたはＳＣＰは、ＮＦもしくはサービスプロファイル、またはプロデューサーＮＦインスタンスをＮＲＦ１００から取得しなければならない。ＮＦまたはサービスプロファイルは、３ＧＰＰ（登録商標）（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ＴＳ（技術仕様書）２９．５１０で規定されたＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）データ構造である。ＮＦまたはサービスプロファイルの規定は、ＦＱＤＮ（完全修飾ドメイン名）、ＩＰｖ４（ＩＰ（インターネットプロトコル）バージョン４）アドレスまたはＩＰｖ６（ＩＰバージョン６）アドレスのうち、少なくとも１つを含む。図１では、すべてのノード（ＮＲＦ１００以外）は、要求側サービスであるか提供側サービスであるかに応じて、コンシューマーＮＦまたはプロデューサーＮＦのいずれかであり得る。図示した例では、これらのノードは、ネットワークにおけるポリシー関連の操作を実行するＰＣＦ（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）１０２と、ユーザデータを管理するＵＤＭ（Ｕｓｅｒ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）機能１０４、アプリケーションサービスを提供するＡＦ（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）１０６とを含む。図１に示すノードは、ＡＭＦ（Ａｃｃｅｓｓ Ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１０とＰＣＦ１０２との間のセッションを管理するＳＭＦ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１０８をさらに含む。ＡＭＦ１１０は、４ＧネットワークにおいてＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）が実行するモビリティ管理操作と同様のモビリティ管理操作を実行する。ＡＵＳＦ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）１１２は、ネットワークにアクセスしたいＵＥ（ユーザ機器）１１４など、ＵＥ（ユーザ機器）の認証サービスを実行する。
ＮＳＳＦ（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ）１１６は、ネットワークスライスに関連する特定のネットワーク機能および特性にアクセスしたいデバイスのためのネットワークスライシングサービスを提供する。ＮＥＦ（Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）１１８は、ネットワークにアタッチされているＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）デバイスおよびその他のＵＥについての情報を取得したいアプリケーション機能のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供する。ＮＥＦ１１８は、４ＧネットワークにおけるＳＣＥＦ（Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ）と同様の機能を実行する。
ＲＡＮ（無線アクセスネットワーク）１２０は、ワイヤレスリンクを経由してＵＥ（ユーザ機器）１１４をネットワークに接続する。無線アクセスネットワーク１２０には、ｇＮＢ（ｇ－ＮｏｄｅＢ）（図１に図示せず）またはその他のワイヤレスアクセスポイントを用いてアクセスされ得る。ＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２２は、ユーザプレーンサービスに関する様々なプロキシ機能をサポートできる。このようなプロキシ機能の一例は、ＭＰＴＣＰ（Ｍｕｌｔｉｐａｔｈ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）プロキシ機能である。ＵＰＦ１２２は、パフォーマンス測定機能もサポートし得る。パフォーマンス測定機能は、ネットワーク性能の測定値を取得するためにＵＥ１１４によって用いられ得る。図１には、ＵＥがインターネットサービスなどのデータネットワークサービスにアクセスするＤＮ（データネットワーク）１２４も示されている。
ＳＥＰＰ（Ｓｅｃｕｒｉｔｙ Ｅｄｇｅ Ｐｒｏｔｅｃｔｉｏｎ Ｐｒｏｘｙ）１２６は、別のＰＬＭＮからの受信トラフィックをフィルタリングし、ホーム側ＰＬＭＮから出るトラフィックのトポロジ隠蔽を実行する。ＳＥＰＰ１２６は、外部ＰＬＭＮのセキュリティを管理する、外部ＰＬＭＮにあるＳＥＰＰと通信し得る。よって、それぞれ異なるＰＬＭＮにおけるＮＦ間のトラフィックは、ホーム側ＰＬＭＮのためのＳＥＰＰ機能および外部ＰＬＭＮのためのＳＥＰＰ機能という２つのＳＥＰＰ機能を横断し得る。
ＳＥＰＰ１２６は、Ｎ３２－ｃインタフェースと、Ｎ３２－ｆインタフェースとを利用し得る。Ｎ３２－ｃインタフェースは、最初のハンドシェイク（たとえば、ＴＬＳハンドシェイク）を実行するためと、Ｎ３２－ｆインタフェース接続および関連するメッセージ転送に関する様々なパラメータをネゴシエーションするために使用できる２つのＳＥＰＰ間のコントロールプレーンのインタフェースである。Ｎ３２－ｆインタフェースは、アプリケーションレベルのセキュリティ保護を適用した後にコンシューマーＮＦとプロデューサーＮＦとの間で様々な情報（たとえば、５ＧＣリクエスト）を転送するために使用できる２つのＳＥＰＰ間の転送インタフェースである。
一般に、ＳＥＰＰ間のＮ３２－ｆインタフェース接続は、ＴＬＳ保護モードを利用するが、ＳＥＰＰ間で１つ以上のＩＰ交換がある場合は、ＰＲＩＮＳベースの保護モードを利用する場合がある。ＰＲＩＮＳベースの保護モードを用いたＮ３２－ｆインタフェース接続をセットアップする際は、ハンドシェイク手順の一部としてＮ３２－ｆコンテキスト識別子が作成されるが、ＴＬＳ保護モードを用いたＮ３２－ｆインタフェース接続をセットアップする際は、Ｎ３２－ｆコンテキスト識別子は作成されない。さらには、ＴＬＳ保護モードを用いたＮ３２－ｆインタフェース接続を介して送られた転送メッセージは、ＨＴＴＰ／２メッセージであり、送信元ＳＥＰＰのアイデンティティを含んでいない可能性がある。
既存の５Ｇアーキテクチャの潜在的な問題は、外部ＰＬＭＮにあるＳＥＰＰが、ホームＰＬＭＮにある別のＳＥＰＰにかなりの数のＰＬＭＮ間メッセージを送ることによってシグナリングストームを生じさせてしまう可能性がある点である。受信側ＳＥＰＰまたはホームＰＬＭＮがグローバルメッセージレート制限手順を開始してシグナリングストームによる影響を抑制または軽減できる一方で、グローバルメッセージレート制限は、シグナリングストームの原因ではないまたはシグナリングストームに関連しないネットワークまたはＳＥＰＰＳからのメッセージを破棄できる。
図２は、ＴＬＳを用いたＮ３２－ｆインタフェース接続を示す図である。図２では、ＳＥＰＰ１２６は、それぞれ異なるＭＮＯ（モバイルネットワーク事業者）が管理するネットワークにある様々なＳＥＰＰに接続され得る。図２に示すように、ＳＥＰＰ１２６は、ＴＬＳ保護モードを用いたＮ３２－ｆインタフェース接続を介して「ＭＮＯ－１」ネットワークにあるＳＥＰＰ２００に接続される。ＳＥＰＰ１２６は、ＴＬＳ保護モードを用いたＮ３２－ｆインタフェース接続を介して「ＭＮＯ－２」ネットワークにあるＳＥＰＰ２０２に接続される。ＳＥＰＰ１２６は、ＴＬＳ保護モードを用いたＮ３２－ｆインタフェース接続を介して「ＭＮＯ－３」ネットワークにあるＳＥＰＰ２０４に接続される。
いくつかの実施の形態では、ＳＥＰＰ１２６は、３ＧＰＰ ＴＳ ３３．５０１において定義されている機能、たとえば、メッセージ保護、相互認証、キー管理、トポロジ隠蔽、アクセス制御、不正なＮ３２シグナリングメッセージの破棄、レート制限、なりすまし防止メカニズムを含み得る。たとえば、「ＭＮＯ－１」ネットワークにあるＳＥＰＰ２００および／またはその他のＳＥＰＰがかなりの量のトラフィック（たとえば、シグナリングストーム）を送信しており、そのホームネットワークにあるＳＥＰＰ１２６またはノードがネットワーク輻輳および／もしくはその他の問題を被っている場合、ＳＥＰＰ１２６は、グローバルメッセージレート制限手順を実行し得る。グローバルメッセージレート制限手順は、グローバル受信メッセージレートを抑えようとして受信メッセージを破棄するまたは抑制（スロットル）し得る。しかしながら、このような手順は、概して、どのネットワークのメッセージが抑制されるまたは破棄されるかについて見境がない。
グローバルメッセージレート制限がシグナリングストームのマイナスの影響を軽減できる一方で、このようなレート制限は、シグナリングストームの原因でないまたはシグナリングストームに関連しないネットワーク（たとえば、「ＭＮＯ－２」および「ＭＮＯ－３」ネットワーク）に関連するトラフィックも不当に破棄または抑制してしまう場合がある。
選択的な受信メッセージレート制限を行うために効果的な識別子は、様々な要因により、容易に利用可能ではないであろう。たとえば、Ｎ３２－ｆコンテキストのＩＤは、ＰＲＩＮＳベースの保護を利用するＮ３２－ｆインタフェース接続で利用できるが、このようなＩＤは、ＴＬＳ保護を利用するＮ３２－ｆインタフェース接続では利用できない。さらには、送信者の識別子は、構文解析されたり、個々のＰＬＭＮ間メッセージから導出されたりし得る一方で、ＴＬＳ保護を利用するＮ３２－ｆインタフェース接続を通常横断するＨＴＴＰ／２メッセージは、送信元ＳＥＰＰのアイデンティティを含んでいない可能性があり、送信元のＩＰアドレスを利用することは、ネットワークアドレスの変換ならびにＳＥＰＰインスタンスおよび／または接続が複数あるという理由で、面倒であろう。また、このような構文解析を必要とするレート制限ソリューションは、多くのリソースを必要とする可能性があり、スケーラビリティに欠け、および／または望ましくない。
本明細書において説明する主題は、たとえば、問題の原因であるネットワークからの過剰なＰＬＭＮ間メッセージのみを破棄することによってＰＬＭＮまたはその中にあるノード当たりの効率的かつ選択的な受信メッセージレート制限を行う方法および技術を提供することによって、このような問題に対処する。さらには、このような方法および技術は、オーバーヘッドをほとんど増やすことなくＰＬＭＮ間メッセージの受信メッセージレート制限を行うことができ、ＰＬＭＮの識別子を取得するためにＰＬＭＮ間メッセージを構文解析することも回避できる。たとえば、本明細書に記載の受信メッセージレート制限方法または技術は、ハンドシェイク手順の間に受信したＴＬＳメッセージまたはＸ．５０９証明書から送信元または送信者の識別子（たとえば、ＦＱＤＮまたはネットワークドメインの識別子）を取得した後、その識別子に基づいて受信メッセージのレート制限を行い得る。
図３は、受信メッセージレート制限のための例示的なノード３００を示す図である。ノード３００は、受信メッセージレート制限の態様を実行するための任意の適切な１つのエンティティまたは複数のエンティティを表し得る。いくつかの実施の形態では、ノード３００は、１つ以上の５ＧＣ ＮＦ、たとえば、ＳＥＰＰ、ＮＲＦ、ＰＣＦ、ＮＳＳＦ、ＮＥＦ、ＵＤＭ、ＡＵＳＦ、ＵＤＲ、ＢＳＦ（Ｂｉｎｄｉｎｇ Ｓｕｐｐｏｒｔ Ｆｕｎｃｔｉｏｎ）、もしくはＵＤＳＦ（Ｕｎｓｔｒｕｃｔｕｒｅｄ Ｄａｔａ Ｓｔｏｒａｇｅ Ｆｕｎｃｔｉｏｎ）を表すまたは含んでもよい。いくつかの実施の形態では、ノード３００は、ネットワークゲートウェイ、ネットワークプロキシ、エッジセキュリティデバイス、もしくは関連機能を表すまたは含んでもよい。
いくつかの実施の形態では、ノード３００または関連モジュールは、ＰＬＭＮ間メッセージに対して、これらの送信元ＰＬＭＮに基づいて受信メッセージレート制限を行うように（たとえば、プログラミングロジックを介して）構成されることにより、ホームネットワークにあるノードまたはその他のダウンストリームのＮＦに対するコントロールプレーンのシグナリングストームの影響を抑制または軽減し得る。たとえば、ノード３００または関連モジュールは、ＴＬＳハンドシェイクの間に受信したデジタル証明書からＰＬＭＮのＩＤを識別するように構成され得、その後、ＰＬＭＮのＩＤに関連する受信メッセージに対してレート制限を行い得る。
図３を参照すると、ノード３００は、通信環境、たとえば、ホーム５ＧＣネットワークを経由してメッセージを伝えるための１つ以上の通信インタフェース（複数可）３０２を備え得る。いくつかの実施の形態では、通信インタフェース（複数可）３０２は、第１のネットワークにある１つ以上のＳＥＰＰと通信するための第１の通信インタフェース、第２のネットワークにある１つ以上のＳＥＰＰと通信するための第２の通信インタフェース、ならびに、ホームネットワーク、たとえば、ホーム５ＧＣネットワークにある１つ以上のＳＥＰＰと通信するための第３の通信インタフェースを含み得る。
ノード３００は、ＲＬＭ（レート制限マネージャ）３０４を備え得る。ＲＬＭ３０４は、受信メッセージレート制限の１つ以上の態様を実行するための任意の適切なエンティティ（たとえば、少なくとも１つのプロセッサ上で実行されているソフトウェア）であり得る。いくつかの実施の形態では、ＲＬＭ３０４は、ネットワークノードまたは関連ネットワークを識別する識別子をネットワークノードからのＴＬＳメッセージから取得し、この識別子を利用して受信メッセージレート制限を行うための機能を備え得る。たとえば、ＴＬＳメッセージから識別子を取得することは、ＴＬＳメッセージに含まれている証明書（たとえば、Ｘ．５０９ｖ３証明書）から識別子を取得することを含み得る。この例では、ＴＬＳメッセージにあるＸ．５０９ｖ３証明書は、送信者のアイデンティティに対応付けられたＦＱＤＮを含むサブジェクトフィールドまたはサブジェクトの別名フィールドを含み得る。この例では、ＦＱＤＮは、ネットワークノード識別子またはネットワーク識別子を含むまたは表し得、たとえば、ネットワーク識別子は、「５ｇｃ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ」のようなフォーマットで格納されたＰＬＭＮのＩＤまたはネットワークドメインであり得る。ここで、「＜ＭＮＣ＞」および「＜ＭＣＣ＞」フィールドは、事業者のＰＬＭＮのＭＮＣおよびＭＣＣに対応する。
いくつかの実施の形態では、たとえば、特定のＮ３２－ｆインタフェース接続に対応付けられた識別子を特定した後、ＲＬＭ３０４は、ＰＬＭＮ間メッセージ（たとえば、ＨＴＴＰ／２メッセージ）についてＮ３２－ｆインタフェース接続を監視するように構成され得る。この例では、受信したＰＬＭＮ間メッセージごとに、ＲＬＭ３０４は、識別子を利用して、識別子に対応付けられた許容受信メッセージレートに達したまたは上回ったかどうかを判断し得、識別子に対応付けられた許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、ＲＬＭ３０４は、レート制限動作を実行し得る。レート制限動作として、リクエストメッセージを破棄すること、受信メッセージの一部を破棄するためにスロットルレートを生成もしくは変更すること、および／または受信メッセージレートもしくは関連イベントに関するネットワーク事業者または管理システムに通知することなどが挙げられ得る。
いくつかの実施の形態では、ネットワークノードまたはネットワークノードを含んだネットワークに対応付けられた許容受信メッセージレートを取得し、ネットワークノードまたはネットワークに対応付けられた現在の受信メッセージレートを取得し、現在の受信メッセージレートと許容受信メッセージレートとを比較することによって、ＲＬＭ３０４は、受信メッセージレート制限を行うかどうかを判断するように構成され得る。現在の受信メッセージレートが許容受信メッセージレートを満たすまたは上回る場合、レート制限動作が実行され得る。現在の受信メッセージレートが許容受信メッセージレートを満たすまたは上回る場合、ＲＬＭ３０４は、たとえば、受信メッセージレート制限なしで、メッセージを取り扱いまたは処理させる。
いくつかの実施の形態では、ＲＬＭ３０４は、複数のノードまたは関連する接続のメッセージレートを追跡または導出するように構成され得る。たとえば、レート制限が送信元のネットワーク識別子に基づくと仮定すると、ＲＬＭ３０４は、複数のＮ３２－ｆインタフェース接続をまたいで受信メッセージレートを追跡し得、同じネットワーク識別子に対応付けられた複数のＳＥＰＰの受信メッセージレートを複合し得、ネットワーク識別子に対応付けられた複合受信メッセージレートをネットワーク識別子に対応付けられた所定の許容受信メッセージレートと比較し得る。
ノード３００は、データストレージ３０６にアクセスし得る（たとえば、情報を読み出すおよび／または書き込む）。データストレージ３０６は、様々なデータを格納するための任意の適切なエンティティ（たとえば、コンピュータ読み取り可能な媒体またはメモリ）であり得る。いくつかの実施の形態では、データストレージ３０６は、ＴＬＳメッセージおよび／またはデジタル証明書の識別子を取得するためのロジックと、受信メッセージレート制限を行うかどうかをチェックするためのロジックと、レート制限動作を実施またはトリガするためのロジックと、様々な接続（たとえば、Ｎ３２－ｆインタフェース接続）および／または送信元エンティティ（たとえば、ＰＬＭＮのＩＤまたはＦＱＤＮ）に対応付けられた現在の受信メッセージレートを追跡するためのロジックと、１つ以上の外部ネットワークおよび／またはその中にあるノードについての所定の許容メッセージレートとを含み得る。
いくつかの実施の形態では、データストレージ３０６は、メッセージレート制限データを含み得る。たとえば、データストレージ３０６は、様々なＰＬＭＮもしくはその中にあるネットワークノードの現在のメッセージレート、許容メッセージレート、および／またはメッセージスロットルレートを識別するための情報を含み得る。この例では、関連するメッセージレートおよびスロットルレートは、索引付けされ得、そうでない場合、ＴＬＳメッセージまたはその中にあるＸ．５０９証明書から取得した識別子を利用して識別され得る。
図３およびその関連する説明が例示を目的としていること、ならびにノード３００が追加のおよび／もしくは異なるモジュール、構成要素、または機能を備えてもよいことが分かるであろう。
図４は、ＳＥＰＰ２００とＳＥＰＰ１２６との間でＮ３２－ｆインタフェース接続をセットアップすることに関連するＴＬＳハンドシェイクを示すメッセージフロー図である。いくつかの実施の形態では、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、Ｎ３２－ｆインタフェース接続をセットアップまたは構成するときに、開始側ＳＥＰＰ２００に対応付けられた識別子を取得または特定するように構成され得る。たとえば、開始側ＳＥＰＰ２００と応答側ＳＥＰＰ１２６は、Ｎ３２－ｃインタフェース上でＴＬＳハンドシェイクメッセージを交換してＴＬＳ接続を確立する。ＴＬＳハンドシェイクは、ＣｌｉｅｎｔＨｅｌｌｏメッセージとＳｅｒｖｅｒＨｅｌｌｏメッセージとの交換、続いて、証明書メッセージの交換を含み得る。各証明書メッセージには、送信者のＸ．５０９証明書が含まれ得る。送信者のアイデンティティは、Ｘ．５０９証明書に含まれ得、なりすますことは困難である。なぜならば、認証局によってＸ．５０９証明書に署名されているためである。
ＴＬＳハンドシェイクプロトコルは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）５２４６において規定されており、ＴＬＳ接続の両エンドによる証明書メッセージの交換を含む。ＩＥＴＦ ＲＦＣ５２４６において規定されているＴＬＳハンドシェイクメッセージの構造（証明書メッセージを含む）は、以下のように表示される。
Figure 2023548370000002
上述したＴＬＳハンドシェイクメッセージの構造によって示されているように、規定されたハンドシェイクメッセージの種類の１つは、証明書メッセージである。証明書メッセージは、送信者がクライアントとして機能しているかサーバとして機能しているかに応じて、クライアントの証明書またはサーバの証明書を含む。Ｎ３２－ｃインタフェースでセキュアなＴＬＳ通信を確立する際、ＴＬＳ接続の両エンドが他方のエンドのＸ．５０９証明書を受信および検証する共通のＴＬＳまたはｍ－ＴＬＳが使用される。ＩＥＴＦ ＲＦＣ５２４６は、明らかにネゴシエーションされない限り、証明書の種類がＸ．５０９ｖ３でなければならないことを示す。本明細書に記載の実施例では、例としてＸ．５０９ｖ３証明書を用いるが、本明細書において説明する主題は、Ｘ．５０９ｖ３から抽出した送信者のアイデンティティを用いて送信者のＮ３２－ｃアイデンティティを検証することだけに限られない。Ｘ．５０９ｖ３証明書のフォーマットは、ＩＥＴＦ ＲＦＣ３２８０で規定されている。ＩＥＴＦ ＲＦＣ３２８０によると、Ｘ．５０９ｖ３証明書が含み得る拡張子またはパラメータは、サブジェクトの別名拡張である。サブジェクトの別名拡張は、次のように定義される。
サブジェクトの別名拡張により、証明書のサブジェクトに追加のアイデンティティをバインドできるようになる。定義済みオプションは、インターネット電子メールアドレスと、ＤＮＳ名と、ＩＰアドレスと、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）とを含む。完全にローカルな定義を含む、その他のオプションも存在する。複数の名前形式、および各名前形式の複数のインスタンスが含まれてもよい。このようなアイデンティティが証明書にバインドされる時はいつも、サブジェクトの別名（発行者の別名）拡張を使わなければならない。しかしながら、ＤＮＳ名は、４．１．２．４節に記載されているように、ｄｏｍａｉｎＣｏｍｐｏｎｅｎｔ属性を用いてサブジェクトフィールドで表されてもよい。
サブジェクトの別名は、最終的に公開鍵にバインドされると考えられるので、サブジェクトの別名のすべての部分をＣＡによって確認しなければならない。
いくつかの実施の形態では、上記の通り、Ｘ．５０９ｖ３証明書のサブジェクトの別名拡張は、証明書のサブジェクトを識別する、認証局によって確認されるＤＮＳ名、ＩＰアドレス、またはＵＲＩを含み得る。サブジェクトの別名は認証局によって確認されるので、サブジェクトの別名をなりすますことは困難である。
図４を参照すると、ステップ４０１では、ＴＬＳハンドシェイクを開始するためのＣｌｉｅｎｔＨｅｌｌｏメッセージがＳＥＰＰ２００からＳＥＰＰ１２６に送られ得る。
ステップ４０２では、たとえば、ＣｌｉｅｎｔＨｅｌｌｏメッセージに応答して、様々なハンドシェイク関連メッセージ（たとえば、ＳｅｒｖｅｒＨｅｌｌｏメッセージ、Ｃｅｒｔｉｆｉｃａｔｅメッセージ、ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージ、ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージ、およびＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージ）がＳＥＰＰ１２６からＳＥＰＰ２００に送られ得る。
ステップ４０３では、たとえば、ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージに応答して、様々なハンドシェイク関連メッセージ（たとえば、Ｃｅｒｔｉｆｉｃａｔｅメッセージ、ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージ、ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージ、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ、およびＦｉｎｉｓｈｅｄメッセージ）がＳＥＰＰ２００からＳＥＰＰ１２６に送られ得る。
ステップ４０４では、Ｃｅｒｔｉｆｉｃａｔｅメッセージからクライアント関連の識別子を抽出し、たとえば、データストレージ３０６に格納し得る。たとえば、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、関連性のある識別子を、ＣｅｒｔｉｆｉｃａｔｅメッセージのＸ．５０９ｖ３証明書に格納されたＦＱＤＮから抽出または導出し得る。この例では、ＦＱＤＮは、ネットワークノード識別子またはネットワーク識別子を含むまたは表し得、たとえば、ネットワーク識別子は、「５ｇｃ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ」のようなフォーマットで格納され得る。ここで、「＜ＭＮＣ＞」および「＜ＭＣＣ＞」フィールドは、事業者のＰＬＭＮのＭＮＣおよびＭＣＣに対応する。
ステップ４０５では、たとえば、Ｆｉｎｉｓｈｅｄメッセージに応答して、様々なハンドシェイク関連メッセージ（たとえば、ＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ、およびＦｉｎｉｓｈｅｄメッセージ）がＳＥＰＰ１２６からＳＥＰＰ２００に送られ得る。
ステップ４０６では、Ｎ３２－ｆインタフェース接続に関連するクライアント関連の識別子（たとえば、ＰＬＭＮのＩＤ）を識別した後、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、受信メッセージレート制限の目的で、Ｎ３２－ｆインタフェース接続を介して受信したＰＬＭＮ間メッセージ（たとえば、ＨＴＴＰ／２メッセージ）を監視し得る。たとえば、Ｎ３２－ｆインタフェース接続を介して特定のＰＬＭＮのＩＤに関連するＨＴＴＰ／２リクエストメッセージが受信された場合、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、クライアント関連の識別子に対応付けられた現在のメッセージレートが、ＰＬＭＮ間メッセージを処理、転送、および／または応答する前のクライアント関連の識別子に対応付けられた許容メッセージレートを満たすまたは上回るかどうかを判断し得る。
図４が例示を目的としていること、ならびに異なるおよび／または追加のメッセージおよび／または動作が用いられてもよいことが分かるであろう。また、本明細書に記載の様々なメッセージおよび／もしくは動作が、異なる順序またはシーケンスで実行されてもよいことが分かるであろう。
図５は、例示的なメッセージレート関連データ５００を示す図である。データ５００は、様々なＰＬＭＮもしくはその中にあるネットワークノードの現在のメッセージレート、許容メッセージレート、および／またはメッセージスロットルレートを識別するための情報を含み得る。たとえば、データ５００にある各レートは、一定期間、たとえば、ＴＰＳ（１秒あたりのトランザクション数）当たりのメッセージ数、リクエスト数、またはトランザクション数を表し得る。
図５を参照すると、データ５００を示す表は、ネットワークおよび／もしくはノードＩＤ、現在のメッセージレート、許容メッセージレート、ならびにメッセージスロットルレートのカラムおよび／またはフィールドを含む。ＮＥＴ ＩＤフィールドは、ＰＬＭＮを表すための情報を格納し得る。ネットワークＩＤとして、ＰＬＭＮの識別子、ＭＣＣ（Ｍｏｂｉｌｅ Ｃｏｕｎｔｒｙ Ｃｏｄｅ）、ＭＮＣ（Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｃｏｄｅ）、ＬＡＣ（Ｌｏｃａｔｉｏｎ Ａｒｅａ Ｃｏｄｅ）、ネットワーク識別子、ＣＧＩ（Ｃｅｌｌ Ｇｌｏｂａｌ Ｉｄｅｎｔｉｆｉｅｒ）、ＢＳＩＤ（Ｂａｓｅ Ｓｔａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）、アクセスノード識別子、ＣＩ（Ｃｅｌｌ Ｉｄｅｎｔｉｔｙ）、ＳＡＣ（Ｓｅｒｖｉｃｅ Ａｒｅａ Ｃｏｄｅ）、ＲＡＩ（Ｒｏｕｔｉｎｇ Ａｒｅａ Ｉｄｅｎｔｉｔｙ）、ＲＡＣ（Ｒｏｕｔｉｎｇ Ａｒｅａ Ｃｏｄｅ）、ＴＡＩ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｉｄｅｎｔｉｔｙ）、ＴＡＣ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｃｏｄｅ）、ＥＧＣＩ（ｅＵＴＲＡＮ ＣＧＩ）、位置座標（たとえば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）情報）、および／または相対的位置情報などが挙げられる。ノードＩＤとして、ＦＱＤＮ、ＵＲＩ、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）名、またはＩＰアドレスなどが挙げられる。
現在のメッセージレートフィールドは、１つ以上のメッセージ、メッセージの種類、またはトランザクションに対応付けられた測定または追跡メッセージレートを表すための情報を格納し得る。たとえば、現在のメッセージレート（たとえば、５０ＴＰＳ）は、特定のＰＬＭＮから受信したＰＬＭＮ間リクエストメッセージまたはトランザクションの測定レートを示し得る。
許容メッセージレートフィールドは、１つ以上のメッセージ、メッセージの種類、またはトランザクションに対応付けられた所定の許容メッセージレートを表すための情報を格納し得る。たとえば、許容メッセージレート（たとえば、４０ＴＰＳ）は、ＳＥＰＰ１２６が、たとえば、レート制限動作を実行しないで許可するように構成された特定のＰＬＭＮからのＰＬＭＮ間リクエストメッセージまたはトランザクションのレートを示し得る。
メッセージスロットルレートフィールドは、１つ以上のメッセージ、メッセージの種類、またはトランザクションに対応付けられたメッセージスロットルレートを表すための情報を格納し得る。たとえば、メッセージスロットルレートは、ＳＥＰＰ１２６が抑制するまたは破棄する特定のＰＬＭＮからのＰＬＭＮ間リクエストメッセージまたはトランザクションのレートを示し得る。この例では、スロットルレートは、現在のメッセージレートと許容メッセージレートとの差、たとえば、５０ＴＰＳ－４０ＴＰＳ＝１０ＴＰＳに基づき得る。
また、データ５００が例示を目的としていること、ならびに、特定のデータ部分のデフォルト値またはその他の情報を示すために、図５に示したデータ以外に、異なるおよび／または追加のデータが用いられてもよいことが分かるであろう。さらには、データ５００は、様々なデータ構造および／またはコンピュータ読み取り可能な媒体を用いて（たとえば、データストレージ３０６に）格納されてもよく、管理されてもよい。
図６は、受信メッセージレート制限の例を示すメッセージフロー図である。いくつかの実施の形態では、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、Ｎ３２－ｆインタフェース接続をセットアップまたは構成するときに交換されたＴＬＳベースの証明書から取得または導出された開始側ＳＥＰＰに対応付けられた識別子を利用して、受信メッセージレート制限を行うように構成され得る。Ｎ３２－ｆインタフェース接続に対応付けられた送信者の識別子（たとえば、ＰＬＭＮ ＩＤ）を識別した後、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、送信者の識別子に対応付けられた受信ＰＬＭＮ間メッセージ（たとえば、ＨＴＴＰ／２メッセージ）を監視し得、送信者の識別子に対応付けられた現在のメッセージレートがＰＬＭＮ間メッセージを処理、転送、および／または応答する前の送信者の識別子に対応付けられた許容メッセージレートを満たすまたは上回るかどうかを判断し得る。現在のメッセージレートが許容メッセージレートを満たすまたは上回るとＳＥＰＰ１２６またはＲＬＭ３０４が判断した場合、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、ＰＬＭＮ間メッセージのうち１つ以上を破棄し得、または別のレート制限動作を実行し得る。現在のメッセージレートが許容メッセージレートを満たさないまたは上回らないとＳＥＰＰ１２６またはその中にあるＲＬＭ３０４が判断した場合、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、ＰＬＭＮ間メッセージを許可し得る。
図６を参照すると、ステップ６０１では、ＳＥＰＰ２０２とＳＥＰＰ１２６とのＴＬＳハンドシェイクがＮ３２－ｃインタフェースを介して行われ得る。たとえば、ＳＥＰＰ２０２は、ＳＥＰＰ１２６とのＴＬＳハンドシェイクを開始し得、ＴＬＳハンドシェイクの間、ＳＥＰＰ２０２とＳＥＰＰ１２６は、識別子を含んだデジタル証明書（たとえば、Ｘ．５０９ｖ３証明書）を交換し得る。
いくつかの実施の形態では、ＴＬＳハンドシェイクの間、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、ＳＥＰＰ２０２に対応付けられたアイデンティティを含んだデジタル証明書を受信し得る。このような実施の形態では、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、デジタル証明書から識別子を抽出、導出、そうでない場合、判断し、その識別子を受信メッセージレート制限機能のために使用し得る。
ステップ６０２では、ＴＬＳハンドシェイクの後、ＴＬＳ保護モードを利用するＮ３２－ｆインタフェースを介して５ＧＣリクエスト（たとえば、ＨＴＴＰ／２メッセージ）がＳＥＰＰ２０２からＳＥＰＰ１２６に送信され得る。たとえば、外部ネットワークにあるプロデューサーＮＦは、ＳＥＰＰ２０２およびＳＥＰＰ１２６を経由して別のネットワークにあるコンシューマーＮＦに転送される５ＧＣリクエストを生成し得る。
ステップ６０３では、たとえば、レート制限を行わないと判断した後、Ｎ３２－ｆインタフェースを介して５ＧＣレスポンス（たとえば、ＨＴＴＰ／２メッセージ）がＳＥＰＰ１２６からＳＥＰＰ２０２に送られ得る。たとえば、ホームネットワークにあるコンシューマーＮＦが、ＳＥＰＰ１２６およびＳＥＰＰ２０２を経由して外部ネットワークにあるプロデューサーＮＦに転送される５ＧＣレスポンスを生成し得る。
ステップ６０４では、ＳＥＰＰ２００とＳＥＰＰ１２６とのＴＬＳハンドシェイクがＮ３２－ｃインタフェースを介して行われ得る。たとえば、ＳＥＰＰ２００は、ＳＥＰＰ１２６とのＴＬＳハンドシェイクを開始し得、ＴＬＳハンドシェイクの間、ＳＥＰＰ２００とＳＥＰＰ１２６は、識別子を含んだデジタル証明書（たとえば、Ｘ．５０９ｖ３証明書）を交換し得る。
いくつかの実施の形態では、ＴＬＳハンドシェイクの間、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、ＳＥＰＰ２００に対応付けられたアイデンティティを含んだデジタル証明書を受信し得る。このような実施の形態では、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、デジタル証明書から識別子を抽出、導出、そうでない場合、判断し、その識別子を受信メッセージレート制限を行う目的に使用し得る。
ステップ６０５では、ＴＬＳハンドシェイクの後、５ＧＣリクエスト（たとえば、ＨＴＴＰ／２メッセージ）がＴＬＳ保護モードを利用するＮ３２－ｆインタフェースを介してＳＥＰＰ２００からＳＥＰＰ１２６に送られ得る。たとえば、外部ネットワークにあるプロデューサーＮＦが、ＳＥＰＰ２００およびＳＥＰＰ１２６を経由して別のネットワークにあるコンシューマーＮＦに転送される５ＧＣリクエストを生成し得る。
ステップ６０６では、たとえば、レート制限を行わないと判断した後、５ＧＣリクエストを破棄し得る。たとえば、ＳＥＰＰ１２６またはその中にあるＲＬＭ３０４は、ＳＥＰＰ２００が転送した５ＧＣリクエストをコンシューマーＮＦに受信させないようにし得る。
図６が例示を目的としていること、ならびに異なるおよび／または追加のメッセージおよび／または動作が用いられてもよいことが分かるであろう。また、本明細書に記載の様々なメッセージおよび／または動作が、異なる順序またはシーケンスで実行されてもよいことが分かるであろう。
図７は、受信メッセージレート制限の例示的な工程７００を示す図である。いくつかの実施の形態では、本明細書に記載の例示的な工程７００またはその一部は、ノード３００、ＲＬＭ３０４、および／または別のモジュールもしくはノードにおいて実行されてもよく、ノード３００、ＲＬＭ３０４、および／または別のモジュールもしくはノードによって実行されてもよい。
例示的な工程７００を参照すると、態様（たとえば、処理ステップまたは動作）は、第１のネットワークのネットワークノード（たとえば、ホーム５ＧＣネットワークにあるＳＥＰＰ１２６またはＲＬＭ３０４を備えるノード３００）において実行され得る。
ステップ７０２では、第２のネットワークノードまたは第２のネットワークを識別する識別子を、第２のネットワークの第２のネットワークノードからのＴＬＳメッセージから取得し得る。たとえば、「ＭＮＯ－１」ネットワークのＳＥＰＰ２００は、ホームネットワークにあるＳＥＰＰ１２６とのＴＬＳハンドシェイクを開始し得、ＴＬＳハンドシェイクの間、ＳＥＰＰ２００に対応付けられた識別子を有する証明書を含んだＴＬＳメッセージを提供し得る。
いくつかの実施の形態では、ＴＬＳメッセージから識別子を取得することは、ＴＬＳメッセージに含まれる証明書（たとえば、Ｘ．５０９ｖ３証明書）から識別子を取得することを含んでもよい。たとえば、ＴＬＳメッセージにあるＸ．５０９ｖ３証明書は、送信者のアイデンティティに対応付けられたＦＱＤＮを含むサブジェクトフィールドまたはサブジェクトの別名フィールドを含んでもよい。この例では、ＦＱＤＮは、ネットワークノード識別子またはネットワーク識別子を含むまたは表してもよく、たとえば、ネットワーク識別子は、「５ｇｃ．ｍｎｃ＜ＭＮＣ＞．ｍｃｃ＜ＭＣＣ＞．３ｇｐｐｎｅｔｗｏｒｋ．ｏｒｇ」のようなフォーマットで格納されてもよい。ここで、「＜ＭＮＣ＞」および「＜ＭＣＣ＞」フィールドは、事業者のＰＬＭＮのＭＮＣおよびＭＣＣに対応する。
ステップ７０４では、第２のネットワークノードまたは第２のネットワークからリクエストメッセージを受信し得る。たとえば、ＴＬＳハンドシェイクの後、「ＭＮＯ－１」ネットワークのＳＥＰＰ２００が、ＴＬＳ保護モードを利用するＮ３２－ｆインタフェースを介して、（たとえば、プロデューサーＮＦからの）１つ以上の５ＧＣリクエストをホームネットワークにあるＳＥＰＰ１２６に転送し得る。
ステップ７０６では、識別子を利用して、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断し得る。たとえば、ＳＥＰＰ１２６は、開始側ＳＥＰＰに対応付けられた識別子を利用して、ＳＥＰＰが受信メッセージレートに達しているまたは上回っているかどうかを判断し得る。この例では、ＳＥＰＰ１２６は、現在の受信メッセージレートと、関連性のある識別子（たとえば、ＰＬＭＮ識別子および／またはＳＥＰＰ識別子）で索引付けまたは対応付けられた許容メッセージレートとを含んだデータストアまたはデータベースに照会し得る。
いくつかの実施の形態では、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断することは、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートを取得することと、第２のネットワークノードまたは第２のネットワークに対応付けられた現在の受信メッセージレートを取得することと、現在の受信メッセージレートが許容受信メッセージレートを満たすまたは上回ると判断するために現在の受信メッセージレートと許容受信メッセージレートとを比較することとを含んでもよい。
いくつかの実施の形態では、第２のネットワークノードまたは第２のネットワークに対応付けられた現在の受信メッセージレートを取得することは、第２のネットワークにある複数のＳＥＰＰのメッセージレートを追跡または導出して、第２のネットワークに対応付けられた現在の受信レートを判断することを含んでもよい。たとえば、レート制限が送信元のネットワーク識別子に基づくと仮定すると、ＳＥＰＰ１２６は、複数のＮ３２－ｆインタフェース接続をまたいで受信メッセージレートを追跡してもよく、同じネットワーク識別子に対応付けられた複数のＳＥＰＰの受信メッセージレートを複合してもよく、ネットワーク識別子に対応付けられた複合受信メッセージレートをネットワーク識別子に対応付けられた所定の許容受信メッセージレートと比較してもよい。
ステップ７０８では、第２のネットワークノードまたは第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行し得る。
いくつかの実施の形態では、レート制限動作は、リクエストメッセージを破棄すること、メッセージの一部を破棄するためにスロットルレートを生成もしくは変更すること、または、ネットワーク事業者または管理システムに通知することを含んでもよい。
工程７００が例示を目的としていること、ならびに異なる動作および／または追加の動作が用いられてもよいことがわかるであろう。また本明細書に記載の様々な動作が、異なる順序またはシーケンスで実行されてもよいことがわかるであろう。
本明細書に記載の主題のいくつかの態様を、５Ｇネットワークを例に説明したが、本明細書に記載の主題のいくつかの態様は、様々なその他のネットワークによって利用されてもよいことがわかるであろう。たとえば、送信者または関連ネットワークを識別する証明書を利用する任意のネットワークは、本明細書に記載の特徴、仕組み、および技術を利用し、たとえば、送信元ノードまたはネットワークに基づいて、より選択的な受信メッセージレート制限を実行してもよい。
なお、本明細書に記載のノード３００、ＲＬＭ３０４、および／または機能によって、特定用途のコンピューティングデバイスが構成されてもよい。さらには、本明細書に記載のノード３００、ＲＬＭ３０４、および／または機能は、ＳＥＰＰまたはその他のネットワークノードにおけるネットワークセキュリティおよび／またはメッセージレート制限の技術分野を向上させることができる。たとえば、ネットワーク識別子および／またはノード識別子に基づいて受信メッセージレート制限を行うことによって、悪意のある行為（たとえば、シグナリングトラフィックストーム）ならびにそのマイナスの影響（たとえば、ネットワーク輻輳、サービス障害、および／またはユーザエクスペリエンスの低下）を軽減および／または防ぐことができる。
下記文献の各々の開示内容のすべてを、本明細書と矛盾しない程度に、そして本明細書において採用した方法、技術、および／またはシステムを補足、説明、その背景を提供する、または、教示する程度に引用により本明細書に援用する。
文献
1. IETF RFC 5246; The Transport Layer Security (TLS) Protocol, Version 1.2; August 2008.
2. IETF RFC 3280; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.
3. 3GPP TS 23.003; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 16), V16.4.0 (2020-09).
4. 3GPP TS 29.573; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.3.0 (2020-07).
5. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.3.0 (2020-07).
6. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16), V16.4.0 (2020-07).
今回開示した主題の様々な詳細は、今回開示した主題の範囲を逸脱することなく変更してもよいことが理解されるであろう。さらには、上記の説明は、あくまで例示にすぎず、限定ではない。

Claims (20)

  1. 受信メッセージレート制限のための方法であって、第１のネットワークの第１のネットワークノードにおいて、
    第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、前記第２のネットワークノードまたは前記第２のネットワークを識別する識別子を取得することと、
    前記第２のネットワークノードまたは前記第２のネットワークからリクエストメッセージを受信することと、
    前記識別子を利用して、前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断することと、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行することとを含む、方法。
  2. 前記ＴＬＳメッセージから前記識別子を取得することは、前記ＴＬＳメッセージに含まれる証明書から前記識別子を取得することを含む、請求項１に記載の方法。
  3. 前記証明書は、Ｘ．５０９証明書を含む、請求項２に記載の方法。
  4. 前記識別子を取得することは、前記Ｘ．５０９証明書のサブジェクトフィールドまたはサブジェクトの別名フィールドから前記第２のネットワークノードのＦＱＤＮ（完全修飾ドメイン名）を抽出することを含む、請求項３に記載の方法。
  5. 前記識別子を取得することは、前記第２のネットワークを識別するためのネットワーク識別子を前記ＦＱＤＮから取得することを含む、請求項４に記載の方法。
  6. 前記第１のネットワークノードまたは前記第２のネットワークノードは、ＳＥＰＰ（Ｓｅｃｕｒｉｔｙ Ｅｄｇｅ Ｐｒｏｔｅｃｔｉｏｎ Ｐｒｏｘｙ）、５Ｇコアネットワーク機能、ネットワークプロキシ、またはネットワークゲートウェイを含む、先行する請求項のいずれか１項に記載の方法。
  7. 前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記許容受信メッセージレートに達したまたは上回ったと判断することは、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記許容受信メッセージレートを取得することと、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた現在の受信メッセージレートを取得することと、
    前記現在の受信メッセージレートが前記許容受信メッセージレートを満たすまたは上回ると判断するために前記現在の受信メッセージレートと前記許容受信メッセージレートとを比較することとを含む、先行する請求項のいずれか１項に記載の方法。
  8. 前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記現在の受信メッセージレートを取得することは、前記第２のネットワークにある複数のＳＥＰＰについての複合メッセージレートを追跡または導出し、前記第２のネットワークに対応付けられた前記現在の受信レートを判断することを含む、請求項７に記載の方法。
  9. 前記レート制限動作は、前記リクエストメッセージを破棄すること、受信メッセージの一部を破棄するためにスロットルレートを生成もしくは変更すること、またはネットワーク事業者または管理システムに通知することを含む、先行する請求項のいずれか１項に記載の方法。
  10. 受信メッセージレート制限のためのシステムであって、
    少なくとも１つのプロセッサと、メモリとを備える、第１のネットワークの第１のネットワークノードを備え、
    前記第１のネットワークノードは、
    第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、前記第２のネットワークノードまたは前記第２のネットワークを識別する識別子を取得し、
    前記第２のネットワークノードまたは前記第２のネットワークからリクエストメッセージを受信し、
    前記識別子を利用して、前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断し、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行するように構成される、システム。
  11. 前記第１のネットワークノードは、前記ＴＬＳメッセージに含まれる証明書から前記識別子を取得することによって前記ＴＬＳメッセージから前記識別子を取得するように構成される、請求項１０に記載のシステム。
  12. 前記証明書は、Ｘ．５０９証明書を含む、請求項１１に記載のシステム。
  13. 前記第１のネットワークノードは、前記Ｘ．５０９証明書のサブジェクトフィールドまたはサブジェクトの別名フィールドから前記第２のネットワークノードのＦＱＤＮ（完全修飾ドメイン名）を抽出するように構成される、請求項１２に記載のシステム。
  14. 前記第１のネットワークノードは、前記第２のネットワークを識別するためのネットワーク識別子を前記ＦＱＤＮから取得するように構成される、請求項１３に記載のシステム。
  15. 前記第１のネットワークノードまたは前記第２のネットワークノードは、ＳＥＰＰ（Ｓｅｃｕｒｉｔｙ Ｅｄｇｅ Ｐｒｏｔｅｃｔｉｏｎ Ｐｒｏｘｙ）、５Ｇコアネットワーク機能、ネットワークプロキシ、またはネットワークゲートウェイを含む、請求項１０～１４のいずれか１項に記載のシステム。
  16. 前記第１のネットワークノードは、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記許容受信メッセージレートを取得し、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた現在の受信メッセージレートを取得し、
    前記現在の受信メッセージレートが前記許容受信メッセージレートを満たすまたは上回ると判断するために前記現在の受信メッセージレートと前記許容受信メッセージレートとを比較するように構成される、請求項１０～１５のいずれか１項に記載のシステム。
  17. 前記第１のネットワークノードは、前記第２のネットワークにある複数のＳＥＰＰのメッセージレートを追跡または導出し、前記第２のネットワークに対応付けられた前記現在の受信レートを判断するように構成される、請求項１６に記載のシステム。
  18. 前記レート制限動作は、前記リクエストメッセージを破棄すること、受信メッセージの一部を破棄するためにスロットルレートを生成もしくは変更すること、またはネットワーク事業者または管理システムに通知することを含む、請求項１０～１７のいずれか１項に記載のシステム。
  19. 実行可能な命令を記憶した非一時的なコンピュータ読み取り可能な媒体であって、前記命令は、コンピュータのプロセッサによって実行されると、ステップを実行するように前記コンピュータを制御し、前記ステップは、第１のネットワークの第１のネットワークノードにおいて、
    第２のネットワークの第２のネットワークノードからのＴＬＳ（トランスポートレイヤーセキュリティ）メッセージから、前記第２のネットワークノードまたは前記第２のネットワークを識別する識別子を取得するステップと、
    前記第２のネットワークノードまたは前記第２のネットワークからリクエストメッセージを受信するステップと、
    前記識別子を利用して、前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた許容受信メッセージレートに達したまたは上回ったと判断するステップと、
    前記第２のネットワークノードまたは前記第２のネットワークに対応付けられた前記許容受信メッセージレートに達したまたは上回ったと判断したことに応答して、レート制限動作を実行するステップとを含む、非一時的なコンピュータ読み取り可能な媒体。
  20. 前記ＴＬＳメッセージから前記識別子を取得することは、前記ＴＬＳメッセージに含まれる証明書から前記識別子を取得することを含む、請求項１９に記載の非一時的なコンピュータ読み取り可能な媒体。
JP2023527034A 2020-11-06 2021-07-21 受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体 Pending JP2023548370A (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
IN202041048552 2020-11-06
IN202041048552 2020-11-06
IN202041049614 2020-11-13
IN202041049614 2020-11-13
US17/129,487 US11528251B2 (en) 2020-11-06 2020-12-21 Methods, systems, and computer readable media for ingress message rate limiting
US17/129,487 2020-12-21
US17/134,635 2020-12-28
US17/134,635 US11943616B2 (en) 2020-11-13 2020-12-28 Methods, systems, and computer readable media for utilizing network function identifiers to implement ingress message rate limiting
PCT/US2021/042660 WO2022098404A1 (en) 2020-11-06 2021-07-21 Methods, systems, and computer readable media for ingress message rate limiting

Publications (2)

Publication Number Publication Date
JP2023548370A true JP2023548370A (ja) 2023-11-16
JPWO2022098404A5 JPWO2022098404A5 (ja) 2024-02-16

Family

ID=81458176

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2023527034A Pending JP2023548370A (ja) 2020-11-06 2021-07-21 受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体
JP2023527049A Pending JP2023548372A (ja) 2020-11-06 2021-07-21 ネットワーク機能識別子を利用して受信メッセージレート制限を実施するための方法、システム、およびコンピュータ読み取り可能な媒体

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023527049A Pending JP2023548372A (ja) 2020-11-06 2021-07-21 ネットワーク機能識別子を利用して受信メッセージレート制限を実施するための方法、システム、およびコンピュータ読み取り可能な媒体

Country Status (4)

Country Link
EP (2) EP4241420A1 (ja)
JP (2) JP2023548370A (ja)
CN (1) CN116438779A (ja)
WO (2) WO2022098405A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11553342B2 (en) 2020-07-14 2023-01-10 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming security attacks using security edge protection proxy (SEPP)
US11751056B2 (en) 2020-08-31 2023-09-05 Oracle International Corporation Methods, systems, and computer readable media for 5G user equipment (UE) historical mobility tracking and security screening using mobility patterns
US11825310B2 (en) 2020-09-25 2023-11-21 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
US11832172B2 (en) 2020-09-25 2023-11-28 Oracle International Corporation Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
US11622255B2 (en) 2020-10-21 2023-04-04 Oracle International Corporation Methods, systems, and computer readable media for validating a session management function (SMF) registration request
US11943616B2 (en) 2020-11-13 2024-03-26 Oracle International Corporation Methods, systems, and computer readable media for utilizing network function identifiers to implement ingress message rate limiting
US11528251B2 (en) 2020-11-06 2022-12-13 Oracle International Corporation Methods, systems, and computer readable media for ingress message rate limiting
US11770694B2 (en) 2020-11-16 2023-09-26 Oracle International Corporation Methods, systems, and computer readable media for validating location update messages
US11895501B2 (en) 2020-12-08 2024-02-06 Oracle International Corporation Methods, systems, and computer readable media for automatic key management of network function (NF) repository function (NRF) access token public keys for 5G core (5GC) authorization to mitigate security attacks
US11818570B2 (en) 2020-12-15 2023-11-14 Oracle International Corporation Methods, systems, and computer readable media for message validation in fifth generation (5G) communications networks
US11812271B2 (en) 2020-12-17 2023-11-07 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming attacks for internet of things (IoT) devices based on expected user equipment (UE) behavior patterns
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation
US11516671B2 (en) 2021-02-25 2022-11-29 Oracle International Corporation Methods, systems, and computer readable media for mitigating location tracking and denial of service (DoS) attacks that utilize access and mobility management function (AMF) location service
US11553524B2 (en) 2021-03-04 2023-01-10 Oracle International Corporation Methods, systems, and computer readable media for resource object level authorization at a network function (NF)
US11689912B2 (en) 2021-05-12 2023-06-27 Oracle International Corporation Methods, systems, and computer readable media for conducting a velocity check for outbound subscribers roaming to neighboring countries
US11843546B1 (en) * 2023-01-17 2023-12-12 Capital One Services, Llc Determining resource usage metrics for cloud computing systems

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9860390B2 (en) * 2011-08-10 2018-01-02 Tekelec, Inc. Methods, systems, and computer readable media for policy event record generation

Also Published As

Publication number Publication date
WO2022098405A1 (en) 2022-05-12
JP2023548372A (ja) 2023-11-16
EP4241420A1 (en) 2023-09-13
EP4241419A1 (en) 2023-09-13
WO2022098404A1 (en) 2022-05-12
CN116438779A (zh) 2023-07-14

Similar Documents

Publication Publication Date Title
JP2023548370A (ja) 受信メッセージレート制限のための方法、システム、およびコンピュータ読み取り可能な媒体
US11528251B2 (en) Methods, systems, and computer readable media for ingress message rate limiting
US11825310B2 (en) Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
US11832172B2 (en) Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
US11818570B2 (en) Methods, systems, and computer readable media for message validation in fifth generation (5G) communications networks
JP7466053B2 (ja) セキュリティエッジ保護プロキシ（ｓｅｐｐ）を使用して５ｇローミングセキュリティ攻撃を緩和するための方法、システム、およびコンピュータ読取可能媒体
US11943616B2 (en) Methods, systems, and computer readable media for utilizing network function identifiers to implement ingress message rate limiting
JP2024505791A (ja) 予想されるユーザ機器（ＵＥ）挙動パターンに基づいてインターネット・オブ・シングス（ＩｏＴ）デバイスへの５Ｇローミング攻撃を緩和するための方法、システム、およびコンピュータ読取可能媒体
JP2024507577A (ja) アクセスおよびモビリティ管理機能（ＡＭＦ）位置サービスを利用する位置追跡攻撃およびサービス妨害（ＤｏＳ）攻撃を緩和するための方法、システム、およびコンピュータ読取可能媒体
US11695563B2 (en) Methods, systems, and computer readable media for single-use authentication messages
JPWO2022066228A5 (ja)
JPWO2022098404A5 (ja)
US11582258B2 (en) Methods, systems, and computer readable media for mitigating denial of service (DoS) attacks at network functions (NFs)
US20230072290A1 (en) METHODS, SYSTEMS, AND COMPUTER READABLE MEDIA FOR REDUCING THE LIKELIHOOD OF SUCCESSFUL DENIAL OF SERVICE (DoS) ATTACKS BY VALIDATING OVERLOAD CONTROL INFORMATION (OCI) SCOPE AGAINST NETWORK FUNCTION (NF) PROFILE INFORMATION OBTAINED USING TARGET RESOURCE IDENTIFICATION INFORMATION
CN116491140A (zh) 用于入口消息速率限制的方法、系统和计算机可读介质
US20240163660A1 (en) Methods, systems, and computer readable media for providing shared security edge protection proxy (sepp) for roaming aggregators
CN116530053A (zh) 用于减轻对安全边缘保护代理（sepp）公共陆地移动网络间（plmn间）转发接口的假冒攻击的方法、系统和计算机可读介质

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240207

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240207