JP7148435B2 - パケット通信システム及び方法 - Google Patents

パケット通信システム及び方法 Download PDF

Info

Publication number
JP7148435B2
JP7148435B2 JP2019032737A JP2019032737A JP7148435B2 JP 7148435 B2 JP7148435 B2 JP 7148435B2 JP 2019032737 A JP2019032737 A JP 2019032737A JP 2019032737 A JP2019032737 A JP 2019032737A JP 7148435 B2 JP7148435 B2 JP 7148435B2
Authority
JP
Japan
Prior art keywords
packet
packet number
bits
small size
significant
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.)
Active
Application number
JP2019032737A
Other languages
English (en)
Other versions
JP2020137093A (ja
Inventor
恒太 井手口
英里子 安藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2019032737A priority Critical patent/JP7148435B2/ja
Priority to US16/564,426 priority patent/US11252265B2/en
Publication of JP2020137093A publication Critical patent/JP2020137093A/ja
Application granted granted Critical
Publication of JP7148435B2 publication Critical patent/JP7148435B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/021—Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/164—Adaptation or special uses of UDP protocol

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Communication Control (AREA)

Description

本発明は、概して、パケット通信に関する。
パケット通信の一例として、ＩｏＴ（Internet of things）サーバとＩｏＴ機器間で行われるパケット通信がある。ＩｏＴサーバが、パケット通信におけるサーバの一例であり、ＩｏＴ機器が、パケット通信におけるクライアントの一例である。ＩｏＴでは、センサー機器等の多くのＩｏＴ機器がクライアントとなり得る。
あらゆるモノがインターネットに繋がるＩｏＴ化が進む中、ＩｏＴ機器のセキュリティを担保することが重要な社会課題の一つとなっている。ＩｏＴは例えば以下の特徴を持つため、それに合わせたセキュリティ技術が求められている。
（１）低スペック。ＩｏＴ機器のプロセッサ速度、メモリ容量及びバッテリ容量等は一般に低い。故に、少ないリソースでセキュリティを実現できることが求められる。
（２）多数のＩｏＴ機器。ＩｏＴ機器は２０２０年には数百億台に達するともいわれており、それに伴いネットワークを流れる通信データ量も増大する。通信インフラを効率的に利用するためには、少ない通信データ量でセキュリティを実現することが求められる。
（３）リアルタイム性。ＩｏＴ機器が典型的に利用されるユースケースの一例として、センサデータやプローブデータの送信がある。このようなデータは、リアルタイム性が重視される。このため、ＩｏＴに関するパケット通信では、パケット到達保証のあるプロトコルである高信頼プロトコル（例えばＴＣＰ（Transmission Control Protocol））ではなく、パケット到達保証が無いが故に信頼性は低いが高信頼プロトコルに比して高速なパケット通信が可能なプロトコルである高速プロトコル、例えばＵＤＰ（User Datagram Protocol）が採用される。
このような特徴によれば、高速プロトコル上でセキュアなパケット通信を実現することが望まれる。
セキュアなパケット通信を実現する方法の一例として、暗号化を挙げることができる。暗号化に関する技術として、例えば特許文献１に開示の技術が知られている。
特開2014-147099号公報
ＵＤＰ上でセキュアなパケット通信を可能にするプロトコルとして、ＤＴＬＳ（Datagram Transport Layer Security）がある。ＤＴＬＳは、ＵＤＰ上で動作するＴＬＳであると言うことができる。具体的には、ＵＤＰを用いて送信されるデータが暗号化される場合、暗号化されたデータを含んだパケットの欠落が発生すると、同期ずれが起こり、故に、パケット内のデータを復号できなくなるが、ＤＴＬＳでは、ＤＴＬＳヘッダにパケット番号が記述されるようになっており、当該パケット番号を用いて同期ずれからの復帰が可能である。ＤＴＬＳでは、パケット番号は、典型的には、セッションの更新の都度に更新されるepochと、セッションにおける通し番号であるsequence_numberとから構成されており、故に、一つのセッションでは、パケット番号は、シーケンス番号に相当する。
ＤＴＬＳには次の課題がある。すなわち、本来ＵＤＰは、ＴＣＰよりも処理負荷の軽いプロトコルであるが、ＤＴＬＳ／ＵＤＰ（DTLS over UDP）は、ＴＬＳ／ＴＣＰ（TLS over TCP）には無かったパケット番号がヘッダに付加される。このため、ＤＴＬＳ／ＵＤＰに従うパケットは、ＴＬＳに従うパケットよりも通信負荷の重いパケットとなってしまう。結果として、パケット通信効率が低下する。上述のような逆転現象を解消することが望まれる。このような課題は、ＤＴＬＳ／ＵＤＰに限らず、高速プロトコル（具体的には、パケット番号が付加されずパケット到達保証の無いプロトコル）上でセキュアなプロトコル（具体的には、パケット番号をヘッダに記述しセキュアなパケット通信を可能にするプロトコル）を用いたパケット通信についてもあり得る。
特許文献１には、フルシーケンス番号から導かれる部分シーケンス番号を出力パケットが含むこと、及び、パケットのオーバヘッドの低減といった記述がある。
しかし、特許文献１の技術は、「ここでは、暗号化及び再配列のために単一のフルシーケンス番号を用いる技術が、記述される。これら技術は、各パケットのオーバヘッドを低減し、ハンドオーバの間、ＲＬＣについて同期化されたシーケンス番号を提供しうる。」及び「受信パケットの再配列、欠落したパケットの検出、誤って受信された又は欠落した受信パケットの再送信のような様々なパケットのためにラジオリンク制御（ＲＬＣ）を利用しうる。」とあるように、送達確認機能（言い換えればパケット到達保証機能）のあるＲＬＣに関する技術である。特許文献１は、上述の課題を開示も示唆もしていない。このため、特許文献１の技術を利用して、上述の課題を解決することはできない。
高速プロトコル上のセキュアなプロトコルに従うパケットが、小サイズヘッダを有する。受信システムにおいて、小サイズヘッダを有するパケットの処理に用いられるパケット番号が、受信されたパケットについてのパケット番号を示す情報を基に推定される。Ｎ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである小サイズヘッダである。小サイズヘッダが第１のヘッダの場合、Ｎ個のパケットの各々におけるヘッダが第１のヘッダである。小サイズヘッダが第２のヘッダの場合、Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが第２のヘッダである。
高速プロトコル上のセキュアなプロトコルに従うパケットの通信効率の低下を低減することができる。
実施例１に係るクライアントサーバシステムの構成を示す。 ＩｏＴサーバの構成を示す。 ＩｏＴ機器の構成を示す。 ＩｏＴサーバが有するサーバパケットＤＢの構成を示す。 ＩｏＴ機器が有するサーバパケットＤＢの構成を示す。 ＩｏＴサーバが有するクライアントパケットＤＢの構成を示す。 ＩｏＴ機器が有するクライアントパケットＤＢの構成を示す。 比較例に従うパケットの構成を示す。 実施例１に係るパケットの構成を示す。 実施例１に係るパケット送受信処理の流れを示す。 実施例２に係るＩｏＴサーバ及びＩｏＴ機器の機能を示す。 大サイズパケットの構成を示す。 小サイズパケットの構成を示す。 実施例２に係るパケット送受信処理の流れを示す。
以下の説明では、「インターフェース部」は、１以上のインターフェースでよい。当該１以上のインターフェースは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
また、以下の説明では、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。
また、以下の説明では、「ＰＤＥＶ部」は、１以上のＰＤＥＶであり、典型的には補助記憶デバイスでよい。「ＰＤＥＶ」は、物理的な記憶デバイス（Physical storage DEVice）を意味し、典型的には、不揮発性の記憶デバイス、例えばＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。
また、以下の説明では、「記憶部」は、メモリ部とＰＤＥＶ部の少なくとも一部とのうちの少なくとも１つ（典型的には少なくともメモリ部）である。
また、以下の説明では、「演算部」は、１以上の演算モジュールである。少なくとも１つの演算モジュールは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種の演算モジュールでもよい。少なくとも１つの演算モジュールとしてのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも１つの演算モジュールは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義の演算モジュールでもよい。
また、以下の説明では、「ｘｘｘＤＢ」といった表現にて（「ＤＢ」はデータベースの略）、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。
また、以下の説明では、「ｋｋｋ部」（インターフェース部、記憶部及び演算部を除く）の表現にて機能を説明することがあるが、機能は、１以上のコンピュータプログラムが演算部によって実行されることで実現されてもよいし、１以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよい。プログラムが演算部によって実行されることで機能が実現される場合、定められた処理が、適宜に記憶部及び／又はインターフェース部等を用いながら行われるため、機能は演算部の少なくとも一部とされてもよい。機能を主語として説明された処理は、演算部あるいはその演算部を有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が１つの機能にまとめられたり、１つの機能が複数の機能に分割されたりしてもよい。
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通部分を使用し、同種の要素を区別する場合は、参照符号を使用することがある。例えば、受信処理部を区別しない場合には、「受信処理部１３０」と言い、受信処理部を区別する場合には、「受信処理部１３０Ｓ」、「受信処理部１３０Ｃ」のように言うことがある。
以下、図面を参照して、本発明の幾つかの実施例を説明する。なお、以下の実施例では、ＤＴＬＳ／ＵＤＰが採用される。すなわち、高速プロトコルとしてＵＤＰが採用され、高速プロトコル上のセキュアなプロトコルとしてＤＴＬＳが採用される。従って、以下の実施例で送受信されるパケットは、ＤＴＬＳ／ＵＤＰに従うパケットである。しかし、本発明は、ＤＴＬＳ／ＵＤＰ以外にも適用可能である。
図１は、実施例１に係るクライアントサーバシステムの構成を示す。
複数のＩｏＴ機器１０１の各々がクライアントの一例として存在し、ＩｏＴサーバ１０３が、サーバの一例として存在する。複数のＩｏＴ機器１０１の各々とＩｏＴサーバ１０３との間で、無線通信ネットワークのような通信ネットワーク１０２を介して、通信が行われる。
ＩｏＴ機器１０１として、種々の機器を採用し得る。例えば、各ＩｏＴ機器１０１は、工場に設置されているセンサー機器（及び他種の機器）でよく、ＩｏＴサーバ１０３は、当該工場内の各ＩｏＴ機器１０１からデータを収集するサーバでよい。
本実施例では、ＩｏＴ機器１０１とＩｏＴサーバ１０３のいずれも、パケットを送信することとパケットを受信することのいずれも可能である。すなわち、ＩｏＴ機器１０１は、送信システムの一例としても受信システムの一例としても動作可能であり、同様に、ＩｏＴサーバ１０３は、受信システムの一例としても送信システムの一例としても動作可能である。しかし、それに限らず、ＩｏＴ機器１０１は、送信システムの一例として動作可能であるが受信システムの一例としては動作不可能であってもよい。また、ＩｏＴサーバ１０３は、受信システムの一例として動作可能であるが送信システムの一例としては動作不可能でもよい。
また、「受信システム」及び「送信システム」のうちの少なくとも一つは、インターフェース部、記憶部及びそれらに接続された演算部を有する計算機システム（例えば、一つ以上の物理的な計算機）でもよいし、クラウド基盤のような計算機システム上に実現されるシステム（例えばクラウドコンピューティングサービス）でもよい。なお、本発明は、ＩｏＴが有する上述した特徴と同様の特徴（低スペック、多数の送信システム、リアルタイム性）を有するパケット通信システムに特に有用である。
図２は、ＩｏＴサーバ１０３の構成を示す。
ＩｏＴサーバ１０３は、典型的には計算機システム（１以上の計算機）であり、インターフェース部２０１、記憶部２０２及びそれらに接続された演算部２０３を有する。
インターフェース部２０１経由で、各ＩｏＴ機器１０１と通信が行われる。
記憶部２０２は、演算部２０３により実行される１以上のコンピュータプログラムや演算部２０３により参照又は更新される情報を格納する。そのような情報の一例として、サーバパケットＤＢ２１１Ｃ、及び、クライアントパケットＤＢ２１２Ｓがある。ＩｏＴサーバ１０３にとっては、サーバパケットＤＢ２１１Ｃが、送信時のパケット番号が記録される送信パケット情報の一例であり、クライアントパケットＤＢ２１２Ｓが、受信したパケットについてのパケット番号が記録される受信パケット情報の一例である。
演算部２０３が１以上のコンピュータプログラムを実行することにより、送信処理部１１０Ｓ及び受信処理部１３０Ｓといった機能が実現される。
送信処理部１１０Ｓは、パケットの送信を行う。具体的には、例えば、送信処理部１１０Ｓは、パケット生成部２２１Ｓと、パケット送信部２２２Ｓとを有する。パケット生成部２２１Ｓは、ＤＴＬＳ／ＵＤＰに従うパケットを生成する。パケット送信部２２２Ｓは、当該生成されたパケットを送信する。
受信処理部１３０Ｓは、パケットを受信し、当該パケットを処理する。具体的には、例えば、受信処理部１３０Ｓは、パケット番号制御部２３１Ｓと、パケット処理部２３２Ｓとを有する。パケット番号制御部２３１Ｓは、クライアントパケットＤＢ２１２Ｓを基に、小サイズヘッダを有する受信したパケットについてのパケット番号を推定する。パケット処理部２３２Ｓは、当該推定されたパケット番号を用いて、受信されたパケットの処理を行う。
図３は、ＩｏＴ機器１０１の構成を示す。
ＩｏＴ機器１０１は、典型的にはセンサー機器のように少なくともＩｏＴ機器１０１に比べて低スペックの機器であり、インターフェース部３０１、記憶部３０２及びそれらに接続された演算部３０３を有する。
インターフェース部３０１経由で、ＩｏＴサーバ１０３と通信が行われる。
記憶部３０２は、演算部３０３により実行される１以上のコンピュータプログラムや演算部３０３により参照又は更新される情報を格納する。そのような情報の一例として、クライアントパケットＤＢ２１１Ｃ、及び、サーバパケットＤＢ２１２Ｃがある。ＩｏＴ機器１０１にとって、クライアントパケットＤＢ２１１Ｃが、送信時のパケット番号が記録される送信パケット情報の一例であり、サーバパケットＤＢ２１２Ｃが、受信したパケットについてのパケット番号が記録される受信パケット情報の一例である。
演算部３０３が１以上のコンピュータプログラムを実行することにより、送信処理部１１０Ｃ及び受信処理部１３０Ｃといった機能が実現される。送信処理部１１０Ｃ及び受信処理部１３０Ｃは、上述の送信処理部１１０Ｓ及び受信処理部１３０Ｓと同様である。すなわち、送信処理部１１０Ｃは、パケット生成部２２１Ｃと、パケット送信部２２２Ｃとを有する。受信処理部１３０Ｃは、パケット番号制御部２３１Ｃと、パケット処理部２３２Ｃとを有する。
図４は、ＩｏＴサーバ１０３が有するサーバパケットＤＢ２１１Ｓの構成を示す。図５は、ＩｏＴ機器１０１が有するサーバパケットＤＢ２１１Ｃの構成を示す。
サーバパケットＤＢ２１１は、例えばセッション毎にエントリを有する。各エントリは、例えば、セッション＃４０１、パケット＃４０２及びＯＴＨＥＲＳ４０３といった情報を保持する。セッション＃４０１は、セッションの番号を示す。パケット＃４０２は、パケットのパケット番号を示す。ＯＴＨＥＲＳ４０３は、セッションの番号とパケットの番号以外の情報である。少なくともＯＴＨＥＲＳ４０３は、無くてもよい。サーバパケットＤＢ２１１は、セッション毎にエントリを有するものに限られず、例えば、セッションとパケット番号の一部毎にエントリを有するものであってもよい。
ＤＴＬＳ／ＵＤＰでは、パケット番号は、epochと、sequence_numberで構成される番号である。epochは、セッションにおけるコネクションの生成に応じて更新される番号であり、第１種の番号の一例である。sequence_numberは、同一のコネクションにおいて送信の都度に更新される番号であり、第２種の番号の一理である。epochは、例えば２バイト（１６ビット）であり、sequence_numberは、例えば６バイト（４８ビット）である。
ＩｏＴサーバ１０３が有するサーバパケットＤＢ２１１Ｓに記録されるパケット＃４０２Ｓは、ＩｏＴサーバ１０３から送信されるパケットについてのパケット番号を示す。ＩｏＴ機器１０１が有するサーバパケットＤＢ２１１Ｃに記録されるパケット＃４０２Ｃは、ＩｏＴサーバ１０３から送信されるパケットについてのパケット番号を示す。
図６は、ＩｏＴサーバ１０３が有するクライアントパケットＤＢ２１２Ｓの構成を示す。図７は、ＩｏＴ機器１０１が有するクライアントパケットＤＢ２１２Ｃの構成を示す。
クライアントパケットＤＢ２１２は、例えばセッション毎にエントリを有する。各エントリは、例えば、セッション＃６０１、パケット＃６０２及びＯＴＨＥＲＳ６０３といった情報を保持する。情報６０１～６０３は、情報４０１～４０３と同様である。クライアントパケットＤＢ２１１は、セッション毎にエントリを有するものに限られず、例えば、セッションとパケット番号の一部毎にエントリを有するものであってもよい。
ＩｏＴサーバ１０３が有するクライアントパケットＤＢ２１１Ｓに記録されるパケット＃４０２Ｓは、ＩｏＴクライアント１０３から送信されるパケットについてのパケット番号を示す。ＩｏＴ機器１０１が有するクライアントパケットＤＢ２１１Ｃに記録されるパケット＃４０２Ｃは、ＩｏＴクライアント１０３から送信されるパケットについてのパケット番号を示す。
本実施例では、説明を簡単にするために、ＩｏＴ機器１０１とセッションＩＤは１：１であるが（１つのＩｏＴ機器１０１とＩｏＴサーバ１０３との間では１つのセッションが行われるが）、ＩｏＴ機器１０１とセッションＩＤは１：多でもよい。
図８は、比較例に従うパケットの構成を示す。
図８に例示するように、比較例に従うパケット８００は、ヘッダ１５とopaque８０６とを有する。opaque８０６は、パケットの本体に相当し、典型的には暗号化データである。暗号化データが復号されたデータを「メッセージ」と言うことができる。
ヘッダ１５は、例えば、ContentType８０１、ProtocolVersion８０２、パケット番号８１０（epoch８０３及びsequence_number８０４）、及びlength８０５を有する。
ContentType８０１は、メッセージのコンテンツのタイプを示し、例えば１バイトの情報である。ProtocolVersion８０２は、ＤＴＬＳのバージョンを示し、例えば２バイトの情報である。epoch８０３は、例えば２バイトの情報である。sequence_number８０４は、例えば６バイトの情報である。従って、パケット番号８１０は、例えば８バイトの情報である。length８０５は、パケット全体の長さを示す。
図９は、実施例１に係るパケットの構成を示す。
実施例１に係るパケット９００は、ヘッダ２５とopaque８０６とを有する。ヘッダ２５は、第１のヘッダの一例である。第１のヘッダは、小サイズヘッダの一例である。「小サイズヘッダ」は、ヘッダ１５よりも小サイズのヘッダである。
ヘッダ２５は、パケット番号８１０に代えて、パケット番号８１０の一部分である部分パケット番号９１０を有する。部分パケット番号９１０は、パケット番号８１０を構成するＰビット（ここではＰ＝６４）のうちの最下位ｎビット（ｎ＜Ｐ）を含む（ここではｎ＝６）。ｎの値は、許容される同期ずれを基に決定されればよい。すなわち、この構成は、本願発明者が鋭意検討した結果によれば、同期ずれが生じたとしても当該同期ずれが許容される同期ずれを超えなければ、パケット番号の一部分を用いて、許容される同期ずれを超える同期ずれを防ぐことができるという知見に至る。そして、パケット番号の一部分は、パケット番号の最下位ｎビットである。これにより、パケットのヘッダのサイズを小さくすることができるため、高効率なパケット通信を実現すること、具体的には、許容される同期ずれを超える同期ずれの防止を高効率に実現することができる。また、本実施例では、高効率且つセキュアなパケット通信を実現することができるが、本実施例でいう「セキュア」は、特に、機密性及び完全性に相当する。
本実施例では、部分パケット番号９１０は、lsb_epoch９０３、及び、lsb_sequence_number９０４で構成される。lsb_epoch９０３は、epochを構成するＶビット（ここではＶ＝１６）のうちの最下位ｍビット（ｍ＜Ｖ）である（ここではｍ＝２）。lsb_sequence_number９０４は、上述の最下位ｎビットは、sequence_numberを構成するＷビット（ここではＷ＝４８ビット）のうちの最下位ｎビットである（ｎ＜Ｗ＜Ｐ）。これにより、後述するように、部分パケット９１０から、セッションを推定し、推定されたセッションにおいて、高効率なパケット通信を実現することができる。なお、上記ｎ、ｍ、Ｐ、Ｖ及びＷの各々は自然数である。特に、少なくともＰは、２以上の整数である。また、ｎ及びｍのうちの少なくとも一つの値は、ＩｏＴ機器１０１毎に異なってもよいしセッション毎に異なってもよい。
図１０は、実施例１に係るパケット送受信処理の流れを示す。
ＩｏＴ機器１０１の送信処理部１１０ＣとＩｏＴサーバ１０３の受信処理部１３０Ｓとの間でセッションｘ（セッション番号ｘのセッション）の確立のためのハンドシェークが行われる。当該ハンドシェークにおいて、例えば下記が行われる（図示せず）。
・送信処理部１１０Ｃ（例えばパケット生成部２２１Ｃ）は、クライアントパケットＤＢ２１２Ｃのエントリに、セッションｘの番号を示すセッション＃６０１Ｃと、初期値（例えば全ビットが“０”）を示すパケット＃６０２Ｃとを記述する。例えば、送信処理部１１０Ｃは、確立前のセッション（ｘ－１）に対応したパケット＃６０２Ｃを初期値（例えば全ビットが“０”）に更新し、且つ、当該確立前のセッション（ｘ－１）に対応したセッション＃６０１Ｃを、セッションｘに対応したセッション＃６０１Ｃに更新する。
・受信処理部１１０Ｓ（例えばパケット番号制御部２３１Ｓ）は、クライアントパケットＤＢ２１２Ｓのエントリに、セッションｘの番号を示すセッション＃６０１Ｓと、初期値（例えば全ビットが“０”）を示すパケット＃６０２Ｓとを記述する。例えば、受信処理部１１０Ｓは、確立前のセッション（ｘ－１）に対応したパケット＃６０２Ｓを初期値（例えば全ビットが“０”）に更新し、且つ、当該確立前のセッション（ｘ－１）に対応したセッション＃６０１Ｓを、セッションｘに対応したセッション＃６０１Ｓに更新する。
その後、パケットの送受信の都度に、下記が行われる。
ＩｏＴ機器１０１において、パケット生成部２２１Ｃが、パケット＃６０２Ｃをインクリメントする、言い換えれば、パケット＃６０２Ｃが示す番号を次の番号に更新する（Ｓ１００１）。パケット生成部２２１Ｃが、パケット＃６０２Ｃから部分パケット番号９１０（epochのうちの最下位ｍビットとsequence_numberのうちの最下位ｎビットで構成された情報）を取得する（Ｓ１００２）。パケット生成部２２１Ｃが、取得した部分パケット番号９１０を含んだヘッダ２５と、opaque８０６（メッセージの暗号化データ）とを含んだパケット９００を生成する（Ｓ１００３）。パケット送信部２２２Ｃが、生成されたパケット９００をＩｏＴサーバ１０３に送信する（Ｓ１００４）。
なお、メッセージは、例えば、パケット＃６０２Ｃ（フルサイズのパケット番号）を用いて暗号化される。また、パケットには、パケット＃６０２Ｃ（フルサイズのパケット番号）とメッセージとの連結を含む連結データのＭＡＣ（例えば、ＨＭＡＣ（Hash-based MAC（Message Authentication Code））が含まれてよい。
ＩｏＴサーバ１０３において、受信処理部１３０Ｓが、パケット９００を受信する（Ｓ１０１１）。
パケット番号制御部２３１Ｓが、受信したパケット９００のヘッダ２５から部分パケット番号９１０を取得する（Ｓ１０１２）。また、パケット番号制御部２３１Ｓが、パケット＃６０２Ｓから部分パケット番号１０１０を取得する（Ｓ１０１３）。
パケット番号制御部２３１Ｓが、部分パケット番号９１０における上記最下位ｎビットが示す値が、部分パケット番号１０１０における上記最下位ｎビットが示す値より大きいか否かを判断する（Ｓ１０１４）。
Ｓ１０１４の判断結果が偽の場合（Ｓ１０１４：Ｎｏ）、すなわち、部分パケット番号９１０における上記最下位ｎビットが示す値が、部分パケット番号１０１０における上記最下位ｎビットよりも小さい場合、パケット番号制御部２３１Ｓは、パケット＃６０２Ｓのsequence_numberのうち、最下位ｎビットの上位（Ｗ－ｎ）ビット（ここでは上位４２ビット）をインクリメントする（Ｓ１０１５）。つまり、最下位ｎビットが示す最大値を超えていわゆる桁上がりが生じたと推定される。
Ｓ１０１４の判断結果が真の場合（Ｓ１０１４：Ｙｅｓ）、パケット番号制御部２３１Ｓが、受信したパケット９００についてのパケット番号が、パケット＃６０２Ｓの上位（Ｗ－ｎ）ビットと、取得された部分パケット番号９１０における上記最下位ｎビットとの結合であると推定する。一方、Ｓ１０１４の判断結果が偽の場合（Ｓ１０１４：Ｎｏ）、Ｓ１０１５が行われたため、パケット番号制御部２３１Ｓは、受信したパケット９００についてのパケット番号が、パケット＃６０２Ｓのインクリメント後の上位（Ｗ－ｎ）ビットと、取得された部分パケット番号９１０における上記最下位ｎビットとの結合であると推定する。
パケット処理部２３２Ｓは、推定されたパケット番号を用いてパケット９００の処理を行う。具体的には、例えば、以下の通りである。
すなわち、パケット処理部２３２Ｓは、推定されたパケット番号がＯＫか否かを判断する（Ｓ１０１６）。具体的には、例えば、下記が行われる。
・パケット処理部２３２Ｓは、推定されたパケット番号を用いてopaque８０６（暗号化データ）を復号する。
・パケット処理部２３２Ｓは、当該復号により得られたメッセージと、推定されたパケット番号を用いて、ＭＡＣを算出する。
・パケット処理部２３２Ｓは、算出されたＭＡＣと、受信したパケット９００が含むＭＡＣとが一致するか否かを判断する。ＭＡＣが一致すれば、推定されたパケット番号がＯＫである。別の言い方をすれば、許容される同期ずれを超えた同期ずれが生じている場合、ＭＡＣは不一致である。
Ｓ１０１６の判断結果が真の場合（Ｓ１０１６：Ｙｅｓ）、パケット処理部２３２Ｓが、パケット＃６０２Ｓを、推定されたパケット番号に更新する（Ｓ１０１７）。
Ｓ１０１６の判断結果が偽の場合（Ｓ１０１６：Ｎｏ）、パケット処理部２３２Ｓが、同期ずれ用処理を行う（Ｓ１０１８）。同期ずれ用処理は、例えば下記うちのいずれかを含んだ処理でよい。
・パケット＃６０２Ｓを元に戻す（ロールバック）。
・パケット＃６０２Ｓを、Ｓ１０１６の判断結果が偽のケースにおける推定されたパケット番号に更新する。
以上が、実施例１の説明である。
なお、実施例１では、同期ずれが生じていない状況では、パケット送信前には、パケット＃６０２Ｃとパケット＃６０２Ｓは一致している。しかし、本発明はそのような例に限らず、同期ずれが生じていない状況で、パケット送信前には、パケット＃６０２Ｃはパケット＃６０２Ｓよりも１だけ大きくてもよい。例えば、ＩｏＴ機器１０１において、パケット生成部２２１Ｃは、パケットの生成前にパケット＃６０２Ｃを更新せず、更新前のパケット＃６０２Ｃから部分パケット番号を取得し、当該取得した部分パケット番号９１０を含んだヘッダ９１０を有するパケット９００を生成し、その後パケット＃６０２Ｃを更新してもよい。
また、上記ｍ及びｎのうちの少なくとも一つの値は可変でよい。例えば、ＩｏＴ機器１０１とＩｏＴサーバ１０３とのハンドシェークにおいて、送信処理部１１０Ｃ及び受信処理部１３０Ｓは、ＩｏＴ機器１０１とＩｏＴサーバ１０３間の通信品質を特定することができる。そこで、上記ｍ及びｎのうちの少なくとも一つの値（例えば、sequence_numberのうちの最下位ｎビットにおけるｎの値）が、当該ハンドシェークにおいて、送信処理部１１０Ｃ及び受信処理部１３０Ｓの少なくとも一方により（例えば受信処理部１３０Ｓ内のパケット番号制御部２３１Ｓにより）、特定された通信品質と、許容された同期ずれとに基づいて、決定されてよい。
また、詳細な説明は省略されているが、ＩｏＴ機器においては、Ｓ１００１の前に、パケット生成部２２１Ｃは、セッション番号とepochをキーにクライアントパケットＤＢ２１２Ｃを検索し、パケット＃６０２Ｃを取得してもよい。ＩｏＴサーバにおいては、Ｓ１０１３の前に、セッション番号とepoch最下位ｍビットをキーにクライアントパケットＤＢ２１２Ｓを検索し、検索結果のうち最も大きな＃６０２Ｓを取得してもよい。
実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略又は簡略する。
図１１は、実施例２に係るＩｏＴサーバ及びＩｏＴ機器の機能を示す。
ＩｏＴサーバ１１０３の送信処理部１１１０Ｓ（パケット生成部１２２１Ｓ及びパケット送信部１２２２Ｓ）及び受信処理部１１３０Ｓ（パケット番号制御部１２３１Ｓ及びパケット処理部１２３２Ｓ）が、実施例１での送信処理部１１０Ｓ及び受信処理部１３０Ｓと異なる。
同様に、ＩｏＴ機器１１０１の送信処理部１１１０Ｃ（パケット生成部１２２１Ｃ及びパケット送信部１２２２Ｃ）及び受信処理部１１３０Ｃ（パケット番号制御部１２３１Ｃ及びパケット処理部１２３２Ｃ）が、実施例１での送信処理部１１０Ｃ及び受信処理部１３０Ｃと異なる。
実施例２では、小サイズヘッダとして、パケット番号に代えて部分パケット番号を有するヘッダに代えて、パケット番号及び部分パケット番号のいずれも有しないヘッダが採用される。具体的には、実施例２では、Ｎ回のパケット送信のうちの１回のパケット送信では、図１２に示す大サイズパケット１２００が送信され、Ｎ回のパケット送信のうちの残りのパケット送信の各々では、図１３に示す小サイズパケット１３００が送信される。
図１２は、大サイズパケット１２００の構成を示す。
大サイズパケット１２００は、大サイズヘッダ３５（第３のヘッダの一例）とopaque８０６とを有する。大サイズヘッダ３５は、パケット番号８１０（具体的には、図８に示した比較例に従う情報８０１～８０６）と、パケット番号８１０を有するか否かを示すflag１２とを有する。パケット番号８１０がある場合、flag１２の値は“０”である。パケット番号８１０が無い場合、flag１２の値は“１”である。
図１３は、小サイズパケット１３００の構成を示す。
小サイズパケット１２００は、小サイズヘッダ４５（第２のヘッダの一例）とopaque８０６とを有する。小サイズヘッダ４５は、大サイズヘッダ３５が有する情報のうち、パケット番号８１０以外を有する。言い換えれば、小サイズヘッダ４５は、パケット番号８１０のサイズ分（パケット番号８１０を有さない分）、大サイズヘッダ３５よりもサイズが小さい。
上述したように、Ｎ回のパケット送信のうち１回のパケット送信でのみ、大サイズパケット１２００が送信され、それ以外のパケット送信では小サイズパケット１３００が送信される。これにより、Ｎ回のパケット送信全体について、ヘッダのデータ量を削減することができ、故に、ＤＴＬＳ／ＵＤＰの効率的なパケット通信が可能である。なお、Ｎの値は、例えば記憶部３０２（及び２０２）に設定される。Ｎの値は、ＩｏＴ機器１０１毎に異なってもよいしセッション毎に異なってもよい。
図１４は、実施例２に係るパケット送受信処理の流れを示す。
ＩｏＴ機器１１０１の送信処理部１１１０ＣとＩｏＴサーバ１１０３の受信処理部１１３０Ｓとの間で実施例１と同様のハンドシェークが行われた後、パケットの送受信の都度に、下記が行われる。
ＩｏＴ機器１１０１において、パケット生成部１２２１Ｃが、パケット＃６０２Ｃをインクリメントする（Ｓ１４０１）。パケット生成部１２２１Ｃが、パケット＃６０２Ｃを取得する（Ｓ１４０２）。パケット生成部１２２１Ｃが、パケット送信回数ＸがＮに達しているか否かを判断する（Ｓ１４０３）。パケット送信回数Ｘは、例えば記憶部３０２に格納されている。
Ｓ１４０３の判断結果が真の場合（Ｓ１４０３：Ｙｅｓ）、パケット生成部１２２１Ｃが、Ｘを０（初期値）に戻し（Ｓ１４０４）、大サイズパケット１２００を生成する（Ｓ１４０５）。パケット送信部１２２２Ｃが、生成された大サイズパケット１２００をＩｏＴサーバ１１０３に送信する（Ｓ１４０６）。
Ｓ１４０３の判断結果が偽の場合（Ｓ１４０３：Ｎｏ）、パケット生成部１２２１Ｃが、Ｘをインクリメントし（Ｓ１４０７）、小サイズパケット１３００を生成する（Ｓ１４０８）。パケット送信部１２２２Ｃが、生成された小サイズパケット１３００をＩｏＴサーバ１１０３に送信する（Ｓ１４０９）。
ＩｏＴサーバ１１０３において、受信処理部１１３０Ｓが、パケット１２００又は１３００を受信する（Ｓ１４１１）。パケット番号制御部１２３１Ｓが、flag１２が“０”か否かを判断する（Ｓ１４１２）。
Ｓ１４１２の判断結果が偽の場合（Ｓ１４１２：Ｎｏ）、Ｓ１４１３が行われる。すなわち、パケット番号制御部１２３１Ｓが、セッションＩＤをキーにパケット＃６０２Ｓを取得する。この取得されたパケット＃６０２Ｓが、受信されたパケット１３００についての推定されたパケット番号に相当する。パケット処理部１２３２Ｓは、当該推定されたパケット番号を用いて、opaque８０６（暗号化データ）を復号する。
Ｓ１４１２の判断結果が真の場合（Ｓ１４１２：Ｙｅｓ）、Ｓ１４１４が行われる。すなわち、パケット番号制御部１２３１Ｓが、大サイズヘッダ３５からパケット番号８１０を取得する。パケット番号制御部１２３１Ｓが、パケット＃６０２Ｓを取得し、パケット番頭のsequence number（Ｃ）とパケット＃６０２Ｓのsequence number（Ｄ）を比較する（Ｓ１４１５）。
Ｓ１４１５の判断結果が真の場合（Ｓ１４１５：Ｙｅｓ）、Ｓ１４１６が行われる。すなわち、パケット処理部１２３２Ｓは、当該パケット番号８１０を用いて、opaque８０６（暗号化データ）を復号する。
Ｓ１４１５の判断結果が偽の場合（Ｓ１４１５：Ｎｏ）、パケット処理部１２３２Ｓが、同期ずれ用処理を行う（Ｓ１４１８）。同期ずれ用処理は、例えば下記うちのいずれかを含んだ処理でよい。
・パケット＃６０２Ｓを変更しない（パケット＃６０２Ｓを維持する）。
・パケット＃６０２Ｓをインクリメントする。
Ｓ１４１３又はＳ１４１５の後、パケット処理部１２３２Ｓは、推定されたパケット番号がＯＫか否かを判断する（Ｓ１４１６）。具体的には、例えば、下記が行われる。
・パケット処理部１２３２Ｓは、Ｓ１４１３又はＳ１４１５の復号により得られたメッセージと、推定されたパケット番号を用いて、ＭＡＣを算出する。
・パケット処理部１２３２Ｓは、算出されたＭＡＣと、受信したパケット１２００又は１３００が含むＭＡＣとが一致するか否かを判断する。ＭＡＣが一致すれば、推定されたパケット番号がＯＫである。別の言い方をすれば、許容される同期ずれを超えた同期ずれが生じている場合、ＭＡＣは不一致である。
Ｓ１４１６の判断結果が真の場合（Ｓ１４１６：Ｙｅｓ）、パケット処理部１２３２Ｓが、パケット＃６０２Ｓをインクリメントする（Ｓ１４１７）。
Ｓ１４１６の判断結果が偽の場合（Ｓ１４１６：Ｎｏ）、パケット処理部１２３２Ｓが、同期ずれ用処理を行う（Ｓ１４１８）。同期ずれ用処理は、例えば下記うちのいずれかを含んだ処理でよい。
・パケット＃６０２Ｓを変更しない（パケット＃６０２Ｓを維持する）。
・パケット＃６０２Ｓをインクリメントする。
以上が、実施例２の説明である。
また、Ｎの値（言い換えれば、flag１２の値が“０”となる頻度）は可変でよい。例えば、ＩｏＴ機器１１０１とＩｏＴサーバ１１０３とのハンドシェークにおいて、送信処理部１１１０Ｃ及び受信処理部１１３０Ｓは、ＩｏＴ機器１１０１とＩｏＴサーバ１１０３間の通信品質を特定することができる。そこで、Ｎの値が、当該ハンドシェークにおいて、送信処理部１１１０Ｃ及び受信処理部１１３０Ｓの少なくとも一方により（例えば受信処理部１１３０Ｓ内のパケット番号制御部１２３１Ｓにより）、特定された通信品質と、許容された同期ずれとに基づいて、決定されてよい。
以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、上述の実施例では、ＩｏＴでのクライアントサーバ間の通信が例として採用されているが、本発明は、他のクライアントサーバ間通信にも適用可能であるし、クライアントサーバ間通信以外のデータ通信（例えばＰ２Ｐのデータ通信）にも適用可能である。
１０３…ＩｏＴサーバ

Claims (6)

  1. 高速プロトコル上のセキュアなプロトコルに従うパケットを送信する送信システムから当該パケットを受信する受信システムであって、
    前記送信システムから受信されたパケットについてのパケット番号を推定するパケット番号推定部と、
    前記推定されたパケット番号を用いて当該パケットの処理を行うパケット処理部と
    を備え、
    前記送信システムにより送信されるＮ個のパケット（Ｎは２以上の整数）の各々における小サイズヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有するヘッダであり、
    前記小サイズヘッダにおける前記部分パケット番号は、前記パケット番号を構成するＰビットのうちの最下位ｎビット（ｎ＜Ｐ）を含み、
    前記パケット番号推定部は、
    前記送信システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報に記録されているパケット番号を取得し、
    前記小サイズヘッダにおける前記最下位ｎビットと当該取得されたパケット番号のうちの最下位ｎビットとの関係から、前記小サイズヘッダを有するパケットについてのパケット番号を推定する、
    受信システム。
  2. 前記パケット番号は、セッションの更新に応じて更新される番号である第１種の番号と、同一のセッションにおいて送信の都度に更新される番号である第２種の番号とを含み、
    前記部分パケット番号は、前記第１種の番号を構成するＶビットのうちの最下位ｍビットを更に含み、
    前記最下位ｎビットは、前記第２種の番号を構成するＷビットのうちの最下位ｎビットである、
    請求項１に記載の受信システム。
  3. 高速プロトコル上のセキュアなプロトコルに従うパケットを送信する送信システムから当該パケットを受信する受信システムとしてコンピュータを動作させるコンピュータプログラムであって、
    前記送信システムから受信されたパケットについてのパケット番号を推定するパケット番号推定ステップと、
    前記推定されたパケット番号を用いて当該パケットの処理を行うパケット処理ステップと
    を前記コンピュータに実行させ、
    前記送信システムにより送信されるＮ個のパケット（Ｎは２以上の整数）の各々における小サイズヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有するヘッダであり、
    前記小サイズヘッダにおける前記部分パケット番号は、前記パケット番号を構成するＰビットのうちの最下位ｎビット（ｎ＜Ｐ）を含み、
    前記パケット番号推定ステップでは、
    前記送信システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報に記録されているパケット番号を取得し、
    前記小サイズヘッダにおける前記最下位ｎビットと当該取得されたパケット番号のうちの最下位ｎビットとの関係から、前記小サイズヘッダを有するパケットについてのパケット番号を推定する、
    コンピュータプログラム。
  4. 高速プロトコル上のセキュアなプロトコルに従うパケットを送信する送信システムから当該パケットを受信する受信システムが行う受信方法であって、
    前記送信システムから受信されたパケットについてのパケット番号を推定するパケット番号推定ステップと、
    前記推定されたパケット番号を用いて当該パケットの処理を行うパケット処理ステップと
    を有し、
    前記送信システムにより送信されるＮ個のパケット（Ｎは２以上の整数）の各々における小サイズヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有するヘッダであり、
    前記小サイズヘッダにおける前記部分パケット番号は、前記パケット番号を構成するＰビットのうちの最下位ｎビット（ｎ＜Ｐ）を含み、
    前記パケット番号推定ステップでは、
    前記送信システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報に記録されているパケット番号を取得し、
    前記小サイズヘッダにおける前記最下位ｎビットと当該取得されたパケット番号のうちの最下位ｎビットとの関係から、前記小サイズヘッダを有するパケットについてのパケット番号を推定する、
    受信方法。
  5. パケットを送信する送信システムに実現される送信処理部と、
    当該パケットを受信する受信システムに実現される受信処理部と
    を有し、
    前記送信処理部は、高速プロトコル上のセキュアなプロトコルに従うパケットを前記受信システムに送信し、
    前記受信処理部は、前記送信システムから前記受信システムが受信したパケットについてのパケット番号を推定し、当該推定されたパケット番号を用いて当該パケットの処理を行い、
    前記送信処理部により送信されるＮ個のパケット（Ｎは２以上の整数）の各々における小サイズヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有するヘッダであり、
    前記小サイズヘッダにおける前記部分パケット番号は、前記パケット番号を構成するＰビットのうちの最下位ｎビット（ｎ＜Ｐ）を含み、
    前記受信処理部は、
    前記送信システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報に記録されているパケット番号を取得し、
    前記小サイズヘッダにおける前記最下位ｎビットと当該取得されたパケット番号のうちの最下位ｎビットとの関係から、前記小サイズヘッダを有するパケットについてのパケット番号を推定する、
    パケット通信システム。
  6. 送信システムにより、高速プロトコル上のセキュアなプロトコルに従うパケットを受信システムに送信する送信ステップと、
    前記受信システムにより、小サイズヘッダを有するパケットを受信する受信ステップと、
    前記受信システムにより、当該受信したパケットについてのパケット番号を推定するパケット番号推定ステップと、
    前記受信システムにより、当該推定されたパケット番号を用いて当該パケットの処理を行うパケット処理ステップと
    を有し、
    前記送信システムにより送信されるＮ個のパケット（Ｎは２以上の整数）の各々における前記小サイズヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有するヘッダであり、
    前記小サイズヘッダにおける前記部分パケット番号は、前記パケット番号を構成するＰビットのうちの最下位ｎビット（ｎ＜Ｐ）を含み、
    前記パケット番号推定ステップでは、
    前記送信システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報に記録されているパケット番号を取得し、
    前記小サイズヘッダにおける前記最下位ｎビットと当該取得されたパケット番号のうちの最下位ｎビットとの関係から、前記小サイズヘッダを有するパケットについてのパケット番号を推定する、
    パケット通信方法。
JP2019032737A 2019-02-26 2019-02-26 パケット通信システム及び方法 Active JP7148435B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2019032737A JP7148435B2 (ja) 2019-02-26 2019-02-26 パケット通信システム及び方法
US16/564,426 US11252265B2 (en) 2019-02-26 2019-09-09 Packet communication system and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019032737A JP7148435B2 (ja) 2019-02-26 2019-02-26 パケット通信システム及び方法

Publications (2)

Publication Number Publication Date
JP2020137093A JP2020137093A (ja) 2020-08-31
JP7148435B2 true JP7148435B2 (ja) 2022-10-05

Family

ID=72142807

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019032737A Active JP7148435B2 (ja) 2019-02-26 2019-02-26 パケット通信システム及び方法

Country Status (2)

Country Link
US (1) US11252265B2 (ja)
JP (1) JP7148435B2 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008539678A (ja) 2005-04-26 2008-11-13 クゥアルコム・インコーポレイテッド 無線通信システムにおいてパケットを暗号化及び再配列すること

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7613185B2 (en) * 2004-03-17 2009-11-03 Verizon Corporate Services Group Inc. Packet header compression for lossy channels
US8155156B2 (en) * 2006-09-15 2012-04-10 Alcatel Lucent Synchronization recovery for multiple-link communications
US8825900B1 (en) * 2011-04-05 2014-09-02 Nicira, Inc. Method and apparatus for stateless transport layer tunneling
KR102011171B1 (ko) * 2012-05-04 2019-10-21 인터디지탈 패튼 홀딩스, 인크 효율적인 매체 접근 제어 (ｍａｃ) 헤더
US10542457B2 (en) * 2015-04-20 2020-01-21 Qualcomm Incorporated Enhanced compression formats for data compression
GB2571576B (en) * 2018-03-02 2022-06-15 Ssh Communications Security Oyj Processing packets in a computer system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008539678A (ja) 2005-04-26 2008-11-13 クゥアルコム・インコーポレイテッド 無線通信システムにおいてパケットを暗号化及び再配列すること

Also Published As

Publication number Publication date
JP2020137093A (ja) 2020-08-31
US20200274951A1 (en) 2020-08-27
US11252265B2 (en) 2022-02-15

Similar Documents

Publication Publication Date Title
US9906630B2 (en) Processing data packets in performance enhancing proxy (PEP) environment
US10341302B2 (en) Optimized transport layer security
US9094374B2 (en) Bandwidth optimization for remote desktop protocol
US8200957B1 (en) Using SYN-ACK cookies within a TCP/IP protocol
US7636767B2 (en) Method and apparatus for reducing network traffic over low bandwidth links
US7948921B1 (en) Automatic network optimization
US8224966B2 (en) Reproxying an unproxied connection
US8954525B2 (en) Method and apparatus of performing remote computer file exchange
US10491329B1 (en) Transfer of data-redundancy encoded data via unreliable, connectionless protocol
US6983382B1 (en) Method and circuit to accelerate secure socket layer (SSL) process
US20090240764A1 (en) Network storage system for a download intensive environment
US11777915B2 (en) Adaptive control of secure sockets layer proxy
US10594661B1 (en) System and method for recovery of data packets transmitted over an unreliable network
CN113221146A (zh) 区块链节点间数据传输的方法和装置
US8386595B2 (en) Method and system of securing data over networks
JP7148435B2 (ja) パケット通信システム及び方法
CN115361455B (zh) 一种数据传输存储方法、装置以及计算机设备
EP3408989B1 (en) Detecting malware on spdy connections
US8176545B1 (en) Integrated policy checking system and method
US11943367B1 (en) Generic cryptography wrapper
KR100565774B1 (ko) 트랜스미션 컨트롤 프로토콜의 연결요청신호 포화를이용한 서비스거부공격의 차단방법
KR20230142147A (ko) 2단계 커밋 트랜잭션 처리 기반 샤드 간 트랜잭션 합의 프로토콜
Al-Hakeem et al. Development of Fast Reliable Secure File Transfer Protocol (FRS-FTP)
WO2024137079A1 (en) Methods for establishing a connection to a server with a cached certificate and devices thereof
Sipahioglu Modernizing Deep Space Network Security

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210430

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220301

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220428

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220906

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220922

R150 Certificate of patent or registration of utility model

Ref document number: 7148435

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150