JP2020536416A - サービス品質を決定するための方法および装置、ならびにプログラム - Google Patents

サービス品質を決定するための方法および装置、ならびにプログラム Download PDF

Info

Publication number
JP2020536416A
JP2020536416A JP2020517777A JP2020517777A JP2020536416A JP 2020536416 A JP2020536416 A JP 2020536416A JP 2020517777 A JP2020517777 A JP 2020517777A JP 2020517777 A JP2020517777 A JP 2020517777A JP 2020536416 A JP2020536416 A JP 2020536416A
Authority
JP
Japan
Prior art keywords
packet
length
mptcp
target
header
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.)
Granted
Application number
JP2020517777A
Other languages
English (en)
Other versions
JP6968990B2 (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
Application filed by ホアウェイ・テクノロジーズ・カンパニー・リミテッド filed Critical ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Publication of JP2020536416A publication Critical patent/JP2020536416A/ja
Application granted granted Critical
Publication of JP6968990B2 publication Critical patent/JP6968990B2/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5006—Creating or negotiating SLA contracts, guarantees or penalties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2876—Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • 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/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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/24—Multipath
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • 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/08—Protocols for interworking; Protocol conversion
    • 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/14—Multichannel or multilink protocols
    • 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]
    • 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
    • H04L2212/00—Encapsulation of packets
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本発明の実施形態は、サービス品質を決定するための方法および装置、ならびに記憶媒体を開示する。本方法は、第１のインターネットプロトコルＩＰパケットを受信する段階であって、第１のＩＰパケットが、ユーザデータグラムプロトコルＵＤＰパケットおよび第１のＩＰヘッダを含む、段階と、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象サービス品質ＱｏＳレベルを決定する段階と、ＵＤＰパケットを少なくとも２つのセグメントに分割する段階と、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化する段階と、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階であって、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、段階と、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して、少なくとも１つの第２のＩＰパケットを送信することにより、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定する段階とを含む。

Description

本発明は、通信技術の分野に関し、特に、サービス品質を決定するための方法および装置、ならびに記憶媒体に関する。
マルチパス伝送制御プロトコル（Ｍｕｌｔｉｐａｔｈ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＭＰＴＣＰ）は、同時伝送のために複数のパスが使用されることにより、エンドツーエンドスループットを増加させることができるように、かつネットワーク利用率を向上させることができるトランスポート層プロトコルである。ネットワーク上のサービスは主に、伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＴＣＰ）サービスおよびユーザデータグラムプロトコル（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、ＵＤＰ）サービスを含む。ＴＣＰサービスおよびＵＤＰサービスは、異なるプロトコルを用いる。したがって、ＴＣＰサービスストリームおよびＵＤＰサービスストリームは、ＭＰＴＣＰでは異なる方式で伝送される。
ＵＤＰサービスストリームは、通常、トンネリング技術を使用してＭＰＴＣＰで伝送される。具体的には、ＵＤＰパケットを受信した後、ルータ等のデバイスは、ＭＰＴＣＰヘッダと、ＵＤＰパケットがカプセル化されているインターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、ＩＰ）パケットの外側の新たなＩＰヘッダとをカプセル化して新たなパケットを取得し、その後、ＭＰＴＣＰ接続を使用してこの新たなパケットをピアエンドに送信する。ＵＤＰパケットがカプセル化されている元のＩＰパケット（例えば、元のＩＰパケットのＩＰヘッダまたはＵＤＰパケットのＵＤＰヘッダ）は、サービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ、ＱｏＳ）情報を含む。ＱｏＳ情報は、ＵＤＰパケットのＱｏＳレベルを決定するのに用いられてよい。
ＵＤＰサービスストリームがＭＰＴＣＰ内で伝送されると、新たなＴＣＰヘッダおよび新たなＩＰヘッダが元のＵＤＰパケットの外側でカプセル化されるが、ＵＤＰパケットの最も外側でカプセル化されたＩＰヘッダ内にはＱｏＳ情報が存在しない。したがって、ＵＤＰパケットを受信するピアデバイスは、ＵＤＰパケットを受信した後、ＱｏＳ情報を取得することができず、その結果、ＵＤＰパケットのＱｏＳレベルを決定することができない。結果として、ピアデバイスは、ＵＤＰパケットに対して対応するＱｏＳ処理を正確に実施することができない。
本出願は、ＵＤＰパケットに対して対応するＱｏＳ処理を正確に実施することができないという問題を解決するために、サービス品質を決定するための方法および装置、ならびに記憶媒体を提供する。
第１の態様によれば、本出願は、サービス品質を決定するための方法を提供する。本方法は、第１のインターネットプロトコルＩＰパケットを受信する段階であって、第１のＩＰパケットが、ユーザデータグラムプロトコルＵＤＰパケットおよび第１のＩＰヘッダを含む、段階と、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象サービス品質ＱｏＳレベルを決定する段階と、ＵＤＰパケットを少なくとも２つのセグメントに分割する段階と、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化する段階と、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階であって、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、段階と、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して、少なくとも１つの第２のＩＰパケットを送信して、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定できるようにする、段階とを含む。
本出願では、受信されたＵＤＰパケットは、少なくとも２つのセグメントに分割される。各セグメントがＭＰＴＣＰパケットにカプセル化された後、ＭＰＴＣＰパケットは、少なくとも１つの第２のＩＰパケットにカプセル化される。さらに、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長は、対象ＱｏＳレベルに対応するバイト長と等しい。言い換えれば、同じＭＰＴＣＰパケットの対象ＱｏＳレベルは、対象ＩＰパケットのペイロード長を使用して示される。したがって、本出願では、カプセル化を通して取得された第２のＩＰパケットがＭＰＴＣＰ接続を使用してピアデバイスに送信された後、ピアデバイスは、対象ＩＰパケットのペイロード長に基づき同じＭＰＴＣＰパケットの対象ＱｏＳレベルを正確に決定し、ＵＤＰパケットに対して対応するＱｏＳ処理を正確に実施することができる。これにより、ＵＤＰパケットの最も外側にカプセル化されたＩＰヘッダ内にＱｏＳ情報が存在しないために、ピアデバイスがＵＤＰパケットに対して対応するＱｏＳ処理を決定することができないという問題が回避される。
第１の態様に関連して、第１の態様の第１の実装例では、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階は、すべてのＭＰＴＣＰパケット内の第１のＭＰＴＣＰパケットについて、第１のＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割する段階であって、少なくとも２つのＭＰＴＣＰパケットフラグメント内の対象ＭＰＴＣＰパケットフラグメントの長さが、対象ＱｏＳレベルに対応するバイト長と等しく、第１のＭＰＴＣＰパケットの長さが、対象ＱｏＳレベルに対応するバイト長より長い、段階と、少なくとも２つのＭＰＴＣＰパケットフラグメントを対応する第２のＩＰパケットにカプセル化する段階であって、対象ＭＰＴＣＰパケットフラグメントに対応する第２のＩＰパケットが、対象ＩＰパケットである、段階とを含む。
第１の態様または上記の任意の実装例に関連して、第１の態様の第２の実装例では、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階は、すべてのＭＰＴＣＰパケット内の第２のＭＰＴＣＰパケットについて、第２のＭＰＴＣＰパケットにパディングデータを追加することにより、パディングデータが追加された第２のＭＰＴＣＰパケットの長さを対象ＱｏＳレベルに対応するバイト長と等しくする段階であって、第２のＭＰＴＣＰパケットの長さが、対象ＱｏＳレベルに対応するバイト長より短い、段階と、パディングデータが追加された第２のＭＰＴＣＰパケットを対応する第２のＩＰパケットにカプセル化する段階であって、パディングデータが追加された第２のＭＰＴＣＰパケットに対応する第２のＩＰパケットが、対象ＩＰパケットである、段階とを含む。
第１の態様または上記の任意の実装例に関連して、第１の態様の第３の実装例では、対象ＩＰパケットは、少なくとも１つの第２のＩＰパケット内の開始ＩＰパケットである。
第１の態様または上記の任意の実装例に関連して、第１の態様の第４の実装例では、少なくとも２つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、最大伝送単位ＭＴＵと第１の長さとの差より小さいまたはそれと等しく、第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和である。
第１の態様または上記の任意の実装例に関連して、第１の態様の第５の実装例では、少なくとも１つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、事前設定された長さより短いまたはそれと等しく、事前設定された長さは、ＭＴＵと第１の事前設定値との差であり、第１の事前設定値は、ＭＰＴＣＰヘッダ長の最大値とＩＰヘッダ長の最大値との和である。
第１の態様または上記の任意の実装例に関連して、第１の態様の第６の実装例では、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階の前に、本方法はさらに、ＱｏＳレベルとバイト長との対応関係に基づき、対象ＱｏＳレベルに対応するバイト長を決定する段階を含む。
第１の態様または上記の任意の実装例に関連して、第１の態様の第７の実装例では、ＱｏＳレベルとバイト長との対応関係は事前設定されており、対応関係内の各ＱｏＳレベルに対応するバイト長の最大値が、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しい。
第１の態様または上記の任意の実装例に関連して、第１の態様の第８の実装例では、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化する段階は、セグメントごとに第１のＩＰヘッダをカプセル化する段階であって、第１のＩＰヘッダ内のペイロード長指示フィールドが、対応するセグメントの長さに修正される、段階と、第１のＩＰヘッダがカプセル化された後に各セグメントをＭＰＴＣＰパケットにカプセル化する段階とを含む。
第２の態様によれば、本出願は、サービス品質を決定するための方法を提供する。本方法は、ピアデバイスとのマルチパス伝送制御プロトコルＭＰＴＣＰ接続を使用して、同じＭＰＴＣＰパケットに属し、かつピアデバイスにより送信された少なくとも１つのインターネットプロトコルＩＰパケットを受信する段階と、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得する段階と、対象ＩＰパケットのペイロード長に基づき、少なくとも１つのＩＰパケットの対象サービス品質ＱｏＳレベルを決定する段階と、を含む。
本出願では、ピアデバイスは、対象ＩＰパケットのペイロード長を使用して、同じＭＰＴＣＰパケットの対象ＱｏＳレベルを示す。したがって、同じＭＰＴＣＰパケットに属する少なくとも１つのＩＰパケットが受信された後、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長に基づき、同じＭＰＴＣＰパケットの対象ＱｏＳレベルが正確に決定され得、対応するＱｏＳ処理が、ＵＤＰパケットに対して正確に実施され得る。これにより、ＵＤＰパケットの最も外側にカプセル化されたＩＰヘッダ内にＱｏＳ情報が存在しないためにＵＤＰパケットに対する対応するＱｏＳ処理を決定することができないという問題が回避される。
第２の態様に関連して、第２の態様の第１の実装例では、対象ＩＰパケットは、少なくとも１つのＩＰパケット内の開始ＩＰパケットである。
第２の態様または第２の態様の第１の実装例に関連して、対象ＩＰパケットのペイロード長は、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しい。
第３の態様によれば、本出願は、サービス品質を決定するための装置を提供する。本装置は、第１のインターネットプロトコルＩＰパケットを受信するように構成された受信ユニットであって、第１のＩＰパケットが、ユーザデータグラムプロトコルＵＤＰパケットおよび第１のＩＰヘッダを含む、受信ユニットと、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属するサービス品質対象ＱｏＳレベルを決定するように構成された決定ユニットと、ＵＤＰパケットを少なくとも２つのセグメントに分割するように構成された分割ユニットと、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化するように構成されたカプセル化ユニットであって、カプセル化ユニットがさらに、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化するように構成され、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、カプセル化ユニットと、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して少なくとも１つの第２のＩＰパケットを送信することにより、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定するように構成された送信ユニットとを含む。
第３の態様に関連して、第３の態様の第１の実装例では、少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、カプセル化ユニットは、特に、すべてのＭＰＴＣＰパケット内の第１のＭＰＴＣＰパケットについて、第１のＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割することであって、少なくとも２つのＭＰＴＣＰパケットフラグメント内の対象ＭＰＴＣＰパケットフラグメントの長さが、対象ＱｏＳレベルに対応するバイト長と等しく、第１のＭＰＴＣＰパケットの長さが、対象ＱｏＳレベルに対応するバイト長より長い、分割することと、少なくとも２つのＭＰＴＣＰパケットフラグメントを対応する第２のＩＰパケットにカプセル化することであって、対象ＭＰＴＣＰパケットフラグメントに対応する第２のＩＰパケットが、対象ＩＰパケットである、カプセル化することとを行うように構成されている。
第３の態様または上記の任意の実装例に関連して、第３の態様の第２の実装例では、少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、カプセル化ユニットは、特に、すべてのＭＰＴＣＰパケット内の第２のＭＰＴＣＰパケットについて、第２のＭＰＴＣＰパケットにパディングデータを追加することにより、パディングデータが追加された第２のＭＰＴＣＰパケットの長さを対象ＱｏＳレベルに対応するバイト長と等しくすることであって、第２のＭＰＴＣＰパケットの長さが、対象ＱｏＳレベルに対応するバイト長より短い、等しくすることと、パディングデータが追加された第２のＭＰＴＣＰパケットを対応する第２のＩＰパケットにカプセル化することであって、パディングデータが追加された第２のＭＰＴＣＰパケットに対応する第２のＩＰパケットが、対象ＩＰパケットである、カプセル化することとを行うように構成されている。
第３の態様または上記の任意の実装例に関連して、第３の態様の第３の実装例では、対象ＩＰパケットは、少なくとも１つの第２のＩＰパケット内の開始ＩＰパケットである。
第３の態様または上記の任意の実装例に関連して、第３の態様の第４の実装例では、少なくとも２つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、最大伝送単位ＭＴＵと第１の長さとの差より小さいまたはそれと等しく、第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和である。
第３の態様または上記の任意の実装例に関連して、第３の態様の第５の実装例では、少なくとも１つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、事前設定された長さより短いまたはそれと等しく、事前設定された長さは、ＭＴＵと第１の事前設定値との差であり、第１の事前設定値は、ＭＰＴＣＰヘッダ長の最大値とＩＰヘッダ長の最大値との和である。
第３の態様または上記の任意の実装例に関連して、第３の態様の第６の実装例では、カプセル化ユニットが各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する前に、決定ユニットはさらに、ＱｏＳレベルとバイト長との対応関係に基づき、対象ＱｏＳレベルに対応するバイト長を決定するように構成されている。
第３の態様または上記の任意の実装例に関連して、第３の態様の第７の実装例では、ＱｏＳレベルとバイト長との対応関係は事前設定されており、対応関係内の各ＱｏＳレベルに対応するバイト長の最大値が、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しい。
第３の態様または上記の任意の実装例に関連して、第３の態様の第８の実装例では、少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、カプセル化ユニットが、特に、セグメントごとに第１のＩＰヘッダをカプセル化することであって、第１のＩＰヘッダ内のペイロード長指示フィールドが、対応するセグメントの長さに修正される、カプセル化することと、第１のＩＰヘッダがカプセル化された後に各セグメントをＭＰＴＣＰパケットにカプセル化することとを行うように構成されている。
第４の態様によれば、本出願は、サービス品質を決定するための装置を提供する。本装置は、ピアデバイスとのマルチパス伝送制御プロトコルＭＰＴＣＰ接続を使用して、同じＭＰＴＣＰパケットに属し、かつピアデバイスにより送信された少なくとも１つのインターネットプロトコルＩＰパケットを受信するように構成された受信ユニットと、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得するように構成された取得ユニットと、対象ＩＰパケットに含まれるＭＰＴＣＰパケットの長さに基づき、少なくとも１つのＩＰパケットの対象サービス品質ＱｏＳレベルを決定するように構成された決定ユニットとを含む。
第４の態様に関連して、第４の態様の第１の実装例では、対象ＩＰパケットは、少なくとも１つのＩＰパケット内の開始ＩＰパケットである。
第４の態様または第４の態様の第１の実装例に関連して、対象ＩＰパケットのペイロード長は、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しい。
第５の態様によれば、本出願は、サービス品質を決定するためのデバイスを提供する。本デバイスは、メモリと、プロセッサと、通信インタフェースと、バスとを含み、メモリ、プロセッサ、および通信インタフェースは互いに接続されており、バスを使用して互いに通信する。メモリはプログラムコードを記憶するように構成され、プロセッサは、メモリに記憶された実行可能なプログラムコードを読み取ることにより、実行可能なプログラムコードに対応するプログラムを実行して、第１の態様に係る方法を実施する。
第６の態様によれば、本出願は、サービス品質を決定するためのデバイスを提供する。本デバイスは、メモリと、プロセッサと、通信インタフェースと、バスとを含み、メモリ、プロセッサ、および通信インタフェースは互いに接続されており、バスを使用して互いに通信する。メモリはプログラムコードを記憶するように構成され、プロセッサは、メモリに記憶された実行可能なプログラムコードを読み取ることにより、実行可能なプログラムコードに対応するプログラムを実行して、第２の態様に係る方法を実施する。
第７の態様によれば、本出願は、データ処理システムを提供する。本システムは、第５の態様に係る、サービス品質を決定するためのデバイスと、第６の態様に係る、サービス品質を決定ためのデバイスとを含む。
第８の態様によれば、本出願は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、その命令がコンピュータで動作すると、コンピュータが、第１の態様に係る方法を実施することが可能になる。
第９の態様によれば、本出願は、コンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は命令を記憶し、その命令がコンピュータで動作すると、コンピュータが、第２の態様に係る方法を実施することが可能になる。
本発明の実施形態における技術的解決策をより明確に説明するために、以下に、実施形態を明らかに説明するために必要な添付の図面を簡潔に説明する。
本発明の実施形態に係るネットワークアーキテクチャの概略図である。
本発明の実施形態に係る、サービス品質を決定するための方法の概略フローチャートである。
本発明の実施形態に係る、フラグメント長とＱｏＳ値との間のマッピング曲線の概略図である。
本発明の実施形態に係る、第１のＩＰパケットを処理するプロセスの概略図である。
本発明の実施形態に係る、サービス品質を決定するための装置の概略ブロック図である。
本発明の別の実施形態に係る、サービス品質を決定するための装置の概略ブロック図である。
本発明の実施形態に係る、サービス品質を決定するためのデバイスの概略ブロック図である。
本発明の別の実施形態に係る、サービス品質を決定するためのデバイスの概略ブロック図である。
本発明の実施形態の目的、技術的解決策、および利点を明確にするために、以下に、本発明の実施形態の添付図面を参照しながら本発明の実施形態の技術的解決策を明確かつ十分に説明する。矛盾が生じない場合、本出願における実施形態および実施形態における特徴を互いに組み合わせてもよい。
本発明の実施形態は、サービス品質を決定するシナリオに適用され得る。図１は、本発明の実施形態に係るネットワークアーキテクチャの概略図である。図１に示すように、ＭＰＴＣＰネットワークに基づくデータ伝送が、ＴＣＰプロキシを使用してクライアントとサーバとの間に実装される。図１において、クライアントは、ＵＤＰプロトコルを使用して第１のプロキシデバイスと通信する。マルチパスネットワークが第１のプロキシデバイスと第２のプロキシデバイスとの間にある。マルチパスネットワークには、デジタル加入者線（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ、ＤＳＬ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ、ロングタームエボリューション）、およびワイヤレスフィデリティ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ、Ｗｉ−Ｆｉ）接続等が含まれ得る。マルチパスネットワークでＵＤＰパケットを伝送するために、第１のプロキシデバイスと第２のプロキシデバイスとの間にＭＰＴＣＰ接続が確立される。第２のプロキシデバイスは、ＵＤＰプロトコルを使用してサーバと通信する。第１のプロキシデバイスおよび第２のプロキシデバイスは、互いのピアデバイスの役割を果たし得る。
具体的には、図１に示すアーキテクチャは、ボンディングアクセス（Ｂｏｎｄｉｎｇ Ａｃｃｅｓｓ、ＢＡ）シナリオまたはソフトウェア定義型広域ネットワーク（Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ、ＳＤ−ＷＡＮ）シナリオに適用され得る。ＢＡシナリオでは、クライアントは、ＵＤＰプロトコルを使用してアプリケーションをホストするクライアント、例えば、ホームユーザのコンピュータまたは携帯電話であってもよい。クライアントは、外部ＵＤＰサーバ上のアプリケーション、例えば、ビデオの生放送にアクセスすることができる。第１のプロキシデバイスは、事業者によりユーザの自宅に設置されたネットワークアクセスデバイスであってもよい。例えば、第１のプロキシデバイスは、ホームゲートウェイ（Ｈｏｍｅ Ｇａｔｅｗａｙ、ＨＧ）であってもよい。第１のプロキシデバイスには、非対称デジタル加入者線（Ａｓｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ、ＡＤＳＬ）インタフェース、Ｗｉ−Ｆｉインタフェース、およびＬＴＥインタフェース等の複数のインタフェースが含まれ得る。これらのインタフェースは、複数のパスで伝送されたデータへのハイブリッドアクセスを実装するために、ＭＰＴＣＰマルチパス伝送用の異なる出力インタフェースとして第１のプロキシデバイスにより使用され得る。第２のプロキシデバイスは、ハイブリッドアクセスアグリゲーションポイント（Ｈｙｂｒｉｄ Ａｃｃｅｓｓ Ａｇｇｒｅｇａｔｉｏｎ Ｐｏｉｎｔ、ＨＡＡＰ）であってもよく、異なるＨＧからハイブリッドアクセス要求を受信するように構成されている。サーバは、ＵＤＰプロトコルを使用してアプリケーションをホストするサーバであってもよい。ＳＤ−ＷＡＮシナリオでは、クライアントは、企業の支社（Ｂｒａｎｃｈ）にあり、かつＵＤＰプロトコルを使用してアプリケーションをホストするクライアントであってもよく、企業の本社（Ｈｅａｄ−ｑｕａｒｔｅｒ、ＨＱ）にあり、かつＵＤＰプロトコルを使用してアプリケーションをホストするサーバ上のアプリケーションにアクセスするように構成され得る。第１のプロキシデバイスおよび第２のプロキシデバイスはアクセスルーティングデバイスであってもよく、このアクセスルーティングデバイスには、ＡＤＳＬインタフェース、Ｗｉ−Ｆｉインタフェース、およびＬＴＥインタフェース等の複数のインタフェースが含まれ得る。これらのインタフェースは、複数のパス上で伝送されたデータへのハイブリッドアクセスを実装するために、ＭＰＴＣＰマルチパス伝送用の異なる出力インタフェースとして使用され得る。サーバは、企業の本社にあり、かつＵＤＰプロトコルを使用してアプリケーションをホストするデータセンタサーバであってもよい。
本発明の実施形態は、サービス品質を決定するための方法を提供する。本方法は、図１に示すネットワークアーキテクチャに適用され得る。図２に示すように、本方法は、以下の段階を含む。
１０１．第１のプロキシデバイスが第１のＩＰパケットを受信する。
クライアントがサーバと通信する必要があるとき、クライアントは、クライアントと第１のプロキシデバイスとの間のＵＤＰプロトコルを使用して第１のＩＰパケットを第１のプロキシデバイスに送信する。第１のＩＰパケットは、ＵＤＰパケットおよび第１のＩＰヘッダを含む。言い換えれば、ＵＤＰパケットは、第１のＩＰパケットのペイロードである。ＵＤＰパケットは、ペイロードおよびＵＤＰヘッダを含む。第１のＩＰヘッダは、ＱｏＳ情報およびペイロード長指示フィールドを含む。この場合、第１のＩＰヘッダ内のペイロード長指示フィールドは、ＵＤＰパケットの長さを示す。第１のプロキシデバイスは第１のＩＰパケットを受信し、第１のＩＰパケットのＵＤＰパケットおよび第１のＩＰヘッダを別々に記憶してもよい。
１０２．第１のプロキシデバイスが、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象ＱｏＳレベルを決定する。
第１のプロキシデバイスは、第１のＩＰヘッダおよび／またはＵＤＰパケットのパケットヘッダ（すなわち、ＵＤＰヘッダ）に含まれるＱｏＳ情報に基づき、ＵＤＰパケットが属する対象ＱｏＳレベルを決定してもよい。ＱｏＳ情報は、具体的には、第１のＩＰパケットに含まれる情報、例えば、送信元ＩＰアドレス、宛先ＩＰアドレス、または差別化サービスコードポイント（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ、ＤＳＣＰ）のうちの１つまたは任意の組み合わせを含んでもよい。
具体的には、第１のプロキシデバイスにおいてＱｏＳレベル分類ルールが事前設定されていてもよい。例えば、ＱｏＳレベル分類ルールは、ＱｏＳレベルと送信元ＩＰアドレスおよび／または宛先ＩＰアドレスとの対応関係であってもよい。第１のＩＰパケットが受信された後、第１のＩＰヘッダに含まれる情報（例えば、送信元ＩＰアドレスおよび宛先ＩＰアドレス）および事前設定されたＱｏＳレベル分類ルールに基づき、ＵＤＰパケットが属する対象ＱｏＳレベルが決定され得る。ＱｏＳレベル分類ルールは、複数のＱｏＳレベルを含んでもよい。異なるＱｏＳレベルが、異なる処理方式に対応する。例えば、異なる優先順位の伝送キューが伝送に使用される。さらに、第１のプロキシデバイスにおいて各ＱｏＳレベルに対応するＱｏＳ値がさらに設定されてもよく、このＱｏＳ値を使用してＱｏＳレベルが示され得る。例えば、８つのＱｏＳレベルがある場合、ＱｏＳレベルに対応するＱｏＳ値は、順番に１〜８の数字に設定され得る。
１０３．第１のプロキシデバイスがＵＤＰパケットを少なくとも２つのセグメントに分割する。
第１のプロキシデバイスは、第１のプロキシデバイスと第２のプロキシデバイスとの間でＭＰＴＣＰ接続を使用してデータを伝送する。したがって、第１のＩＰパケットを第２のプロキシデバイスに送信するとき、第１のプロキシデバイスは、第１のＩＰパケットの外側にＭＰＴＣＰヘッダおよび新たなＩＰヘッダ（以下、第２のＩＰヘッダと称される）を連続的にカプセル化する必要がある。これにより、第１のプロキシデバイスと第２のプロキシデバイスとの間でＭＰＴＣＰ接続を使用して伝送が実施され得る。
パケットがデバイス間で伝送されるとき、最大伝送単位（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ、ＭＴＵ）が設定される。これは、デバイス間で伝送されるパケットの最大長を示す。一般に、ＭＴＵにより許容される長さがデバイス間の伝送に使用される。したがって、第１のＩＰパケットの長さは通常、ＭＴＵに達し得る。しかしながら、ＭＰＴＣＰヘッダおよび第２のＩＰヘッダが第１のＩＰパケットの外側にカプセル化された後、長さはＭＴＵよりもはるかに長くなる。この場合、第１のプロキシデバイスは、ＭＰＴＣＰヘッダおよび第２のＩＰヘッダが外側にカプセル化されている第１のＩＰパケットを伝送することができない。したがって、本発明のこの実施形態では、第１のプロキシデバイスは、第１のＩＰパケット内のＵＤＰパケットを少なくとも２つのセグメントに分割し、その後、伝送のために少なくとも２つのセグメントの各々の外側に第１のＩＰヘッダ、ＭＰＴＣＰヘッダ、および第２のＩＰヘッダをカプセル化する。このようにして、カプセル化後に取得されたセグメントはＭＴＵより短いか、またはＭＴＵと同じ長さとなることができ、第１のプロキシデバイスはパケットを伝送することができる。
第１のＩＰヘッダ、ＭＰＴＣＰヘッダ、および第２のＩＰヘッダがカプセル化された後の少なくとも２つのセグメントの各々の長さがＭＴＵより長くないことを保証するために、セグメントが分割されたときに、各セグメントの長さと第１のＩＰヘッダの長さとの和がＭＴＵと第１の長さとの差より小さいまたはそれと等しいことを保証する必要がある。第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰヘッダの長さとの和である。
第１のＩＰヘッダ、ＭＰＴＣＰヘッダ、および第２のＩＰヘッダがカプセル化された後の各セグメントの長さがＭＴＵより短いまたはそれと等しい場合、ＭＴＵにより許容されるバイト長が満たされ得る。言い換えれば、各セグメントの長さと、第１のＩＰヘッダの長さと、ＭＰＴＣＰヘッダの長さと、第２のＩＰヘッダの長さとの和は、ＭＴＵより小さいまたはそれと等しい。したがって、ＵＤＰパケットが複数のセグメントに分割される場合、各セグメントの長さと第１のＩＰヘッダの長さとの和が、ＭＴＵと第１の長さとの差より小さいまたはそれと等しくなり得る。第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰヘッダの長さとの和である。
第１のプロキシデバイスは、第１のＩＰパケットを使用して第１のＩＰヘッダの長さを決定することができる。ＭＰＴＣＰヘッダの長さおよび第２のＩＰヘッダの長さは、第１のＩＰパケットの関数を参照して計算され得る。したがって、ＵＤＰパケットを複数のセグメントに分割する場合、第１のプロキシデバイスは、ＭＴＵ、第１のＩＰヘッダの長さ、ＭＰＴＣＰヘッダの長さ、および第２のＩＰヘッダの長さに基づき、各セグメントの長さの最大値を決定することができる。
第１のプロキシデバイスのデータ処理プロセスを単純化するために、本発明のこの実施形態では、具体的な設定は以下のとおりであってよい。すなわち、少なくとも１つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、事前設定された長さより短いまたはそれと等しく、事前設定された長さは、ＭＴＵと第１の事前設定値との差であり、第１の事前設定値は、ＭＰＴＣＰヘッダ長の最大値とＩＰヘッダ長の最大値との和である。
各セグメントに対応するＭＰＴＣＰヘッダの長さは必ず、ＭＰＴＣＰヘッダ長の最大値より短いまたはそれと等しく、各セグメントに対応する第２のＩＰヘッダの長さは必ず、ＩＰヘッダ長の最大値より短いまたはそれと等しい。したがって、第１の事前設定値は必ず、第１の長さより大きいまたはそれと等しい。具体的には、ＭＴＵと第１の事前設定値との差は必ず、ＭＴＵと第１の長さとの差より小さいまたはそれと等しい。したがって、本発明のこの実施形態では、第１のプロキシデバイスは、ＭＴＵ、ＭＰＴＣＰヘッダ長の最大値、およびＩＰヘッダ長の最大値に基づき、各セグメントの長さと第１のＩＰパケットの長さとの和を決定することができ、各セグメントの長さと第１のＩＰパケットの長さとの決定された和は必ず、ＭＴＵと第１の長さとの差より小さいまたはそれと等しい。したがって、第１のＩＰヘッダ、ＭＰＴＣＰヘッダ、および第２のＩＰヘッダがカプセル化された後の各セグメントの長さがＭＴＵより大きくないことが保証され得る。
通常、ＭＰＴＣＰヘッダ長の最大値およびＩＰヘッダ長の最大値はいずれも６０バイトである。したがって、本発明のこの実施形態では、第１の事前設定値は１２０バイトに設定され得る。
各セグメントの長さと第１のＩＰヘッダの長さとの和が、ＭＴＵと第１の長さとの差より小さいまたはそれと等しいことを条件として、第１のプロキシデバイスがＵＤＰパケットを複数のセグメントに分割する方式は限定されないことに留意すべきである。第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰヘッダの長さとの和である。第１のプロキシデバイスは、第１のＩＰパケット内のＵＤＰパケットを少なくとも２つのセグメントに分割し、少なくとも２つのセグメントの各々に含まれるＵＤＰパケットの対象ＱｏＳレベルは、第１のＩＰパケット内のＵＤＰパケットの対象ＱｏＳレベルと同じである。
１０４．第１のプロキシデバイスが少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化する。
ステップ１０３でＵＤＰパケットを少なくとも２つのセグメントに分割した後、第１のプロキシデバイスは、各セグメントをＭＰＴＣＰパケットにカプセル化する。
少なくとも２つのセグメントの各々をカプセル化するとき、第１のプロキシデバイスは、第１のＩＰヘッダをまずカプセル化する必要がある。これにより、各セグメントは、第１のＩＰヘッダ内の宛先アドレスに伝送され得る。この場合、各セグメントは、第１のＩＰヘッダに対応するペイロードである。したがって、第１のＩＰヘッダ内のペイロード長指示フィールドは、各セグメントの長さに修正される。具体的には、セグメントごとに第１のＩＰヘッダがカプセル化されているとき、第１のＩＰヘッダ内のペイロード長指示フィールドは、第１のＩＰヘッダ内の情報の正確さを保証するために、セグメントの長さに修正される。
セグメントごとに、第１のプロキシデバイスは、ペイロード長指示フィールドが修正された第１のＩＰヘッダをカプセル化し、その後、ＭＰＴＣＰヘッダをカプセル化する、すなわち、少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化する。
１０５．第１のプロキシデバイスが各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する。
少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長は、対象ＱｏＳレベルに対応するバイト長と等しい。本発明のこの実施形態では、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化するとき、第１のプロキシデバイスは、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長を使用して、各ＭＰＴＣＰパケットの対象ＱｏＳレベルを反映する。通常、ＩＰパケットのペイロード長は、ＩＰヘッダで搬送される。したがって、対象ＩＰパケットの第２のＩＰヘッダは、ペイロード長を搬送してもよい。
対象ＩＰパケットは、少なくとも１つの第２のＩＰパケット内の事前設定された位置にあるパケットであってもよく、例えば、少なくとも１つの第２のＩＰパケット内の開始ＩＰパケットまたは少なくとも１つの第２のＩＰパケット内の最後のＩＰパケットであってもよい。
ＭＰＴＣＰパケットの長さは異なり、ＭＰＴＣＰパケットの長さが対象ＱｏＳレベルに対応するバイト長に達することができないことがある。この場合、ＭＰＴＣＰパケットにパディングデータを追加する必要がある。
具体的には、各ＭＰＴＣＰパケットをカプセル化するとき、第１のプロキシデバイスはさらに、ＭＰＴＣＰパケットの長さを対象ＱｏＳレベルに対応するバイト長と比較してもよい。
ＭＰＴＣＰパケット内にあり、かつその長さが対象ＱｏＳレベルに対応するバイト長より長い第１のＭＰＴＣＰパケットについて、第１のＭＰＴＣＰパケットは、少なくとも２つのＭＰＴＣＰパケットフラグメントに分割されてもよく、少なくとも２つのＭＰＴＣＰパケットフラグメント内の対象ＭＰＴＣＰパケットフラグメントの長さが、対象ＱｏＳレベルに対応するバイト長と等しい。少なくとも２つのＭＰＴＣＰパケットフラグメントは、対応する第２のＩＰパケットにカプセル化され、対象ＭＰＴＣＰパケットフラグメントに対応する第２のＩＰパケットが対象ＩＰパケットである。ＭＰＴＣＰパケット内にあり、かつその長さが対象ＱｏＳレベルに対応するバイト長より短い第２のＭＰＴＣＰパケットについて、パディングデータが第２のＭＰＴＣＰパケットに追加されてもよく、これにより、パディングデータが追加された第２のＭＰＴＣＰパケットの長さは対象ＱｏＳレベルに対応するバイト長と等しくなる。パディングデータが追加された第２のＭＰＴＣＰパケットは対応する第２のＩＰパケットにカプセル化され、パディングデータが追加された第２のＭＰＴＣＰパケットに対応する第２のＩＰパケットが対象ＩＰパケットである。ＭＰＴＣＰパケット内にあり、かつその長さが対象ＱｏＳレベルに対応するバイト長と等しい第３のＭＰＴＣＰパケットについて、第３のＭＰＴＣＰパケットは、対応する第２のＩＰパケット、すなわち、対象ＩＰパケットに直接カプセル化されてもよい。
ＭＰＴＣＰパケットの長さが対象ＱｏＳレベルに対応するバイト長より長い場合、対象ＭＰＴＣＰパケットフラグメントの長さは対象ＱｏＳレベルに対応するバイト長と等しい必要があるため、第１のプロキシデバイスは、ＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割してもよい。分割時に、対象ＭＰＴＣＰパケットフラグメントの長さは、対象ＱｏＳレベルに対応するバイト長と等しくなり、残りのフラグメントの長さおよび数は、実際のシナリオにおける要件またはＭＰＴＣＰパケットの長さに基づき決定されてよい。ＭＰＴＣＰパケットを複数のＭＰＴＣＰパケットフラグメントに分割した後、第１のプロキシデバイスは、これらのＭＰＴＣＰパケットフラグメントの各々を対応する第２のＩＰパケットにカプセル化する。対象ＩＰパケットは、対象ＭＰＴＣＰパケットフラグメントがカプセル化された後に取得された第２のＩＰパケットであり、これらのＭＰＴＣＰパケットフラグメントの各々は、対応する第２のＩＰパケットのペイロードである。
ＭＰＴＣＰパケットの長さが対象ＱｏＳレベルに対応するバイト長より短い場合、ＭＰＴＣＰパケットの長さは、対象ＱｏＳレベルに対応するバイト長に達することができない。したがって、ＭＰＴＣＰパケットにパディングデータが追加される必要があり、これにより、パディングデータが追加されたＭＰＴＣＰパケットの長さを、対象ＱｏＳレベルに対応する長さと等しくする。この場合、パディングデータが追加されたＭＰＴＣＰパケットは、対象ＩＰパケットのペイロードである。次に、第１のプロキシデバイスは、パディングデータが追加されたＭＰＴＣＰパケットを対応する第２のＩＰパケット、すなわち、対象ＩＰパケットにカプセル化する。
ＭＰＴＣＰパケットの長さが対象ＱｏＳレベルに対応する長さと等しい場合、第１のプロキシデバイスは、ＭＰＴＣＰパケットを対応する第２のＩＰパケット、すなわち、対象ＩＰパケットに直接カプセル化してもよい。
ＭＰＴＣＰパケットにパディングデータが追加される場合、パディングデータは、第１のＩＰヘッダに対応するペイロードの後ろに追加され得ることに留意すべきである。これに応じて、パディングデータが追加される前に、第１のＩＰヘッダ内のペイロード長指示フィールドは対応するセグメントの長さを示してもよい。パディングデータが追加されるとき、第１のＩＰヘッダ内のペイロード長指示フィールドは、対応するセグメントの長さと追加されたパディングデータの長さとの和を示してもよいし、対応するセグメントの長さを示してもよい。パディングデータは、数字であってもよく、具体的には、０であってもよい。
本発明のこの実施形態では、第１のプロキシデバイスは、ＱｏＳレベルとバイト長との対応関係を事前設定してもよい。したがって、ステップ１０５が実施される前に、第１のプロキシデバイスは、ＱｏＳレベルとバイト長との対応関係に基づき、対象ＱｏＳレベルに対応するバイト長を決定してもよい。さらに、第１のプロキシデバイスがＱｏＳレベルに対応するＱｏＳ値を設定する場合、ＱｏＳ値とバイト長との対応関係がさらに設定され得る。
本発明のこの実施形態では、ＱｏＳレベルとバイト長との対応関係は、事前設定された関数または対応表を使用して設定され得る。具体的なサービスストリームに基づき具体的な対応関係が設定されてよい。例えば、表１に示す対応表を確立することができる。この場合の、ＱｏＳレベルとバイト長との間のマッピング曲線を図３に示す。図３では、水平座標は長さを表し、垂直座標はＱｏＳレベルを表す。
Figure 2020536416
第２のＩＰパケットのペイロード長が対応するＱｏＳレベルを示すのに使用されるため、この設定における任意のＱｏＳレベルに対応する長さは、ＭＴＵの長さ１５００とＩＰヘッダ長の最大値６０との差１４４０より小さい必要がある。表１に示すように、ＱｏＳレベルに対応する最大長が１４４０である。
ＱｏＳレベルとバイト長との対応関係は、以下の要件を満たす必要があることに留意すべきである。すなわち、この対応関係は、プロトコル原理に準拠し、プロトコルルールに違反できず、かつＱｏＳレベルとバイト長との対応関係は一対一の対応関係である。
ＭＰＴＣＰパケットにパディングデータを追加する処理を低減し、各ＭＰＴＣＰパケットの長さを対象ＱｏＳレベルに対応するバイト長より長くするために、第１のプロキシデバイスは、ＱｏＳレベルに対応するバイト長を比較的小さい値に設定し得る。具体的には、ＱｏＳレベルに対応するバイト長の最大値が、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しくてよい。
ＭＰＴＣＰパケットは、セグメントごとに第１のＩＰヘッダおよびＭＰＴＣＰヘッダがカプセル化された後に取得されるため、ＭＰＴＣＰパケットの長さが必ず、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より大きい。したがって、ＱｏＳレベルに対応するバイト長の最大値がＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しい場合、対象ＩＰパケットのペイロード長はＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より短く、ＭＰＴＣＰパケットの長さは必ず、ＱｏＳレベルに対応するバイト長の最大値より長いまたはそれと等しい。言い換えれば、ＭＰＴＣＰパケットの長さは必ず、対象ＱｏＳレベルに対応するバイト長より長いまたはそれと等しい。したがって、ＭＰＴＣＰパケットにパディングデータを追加する処理を減少または低減させて、データ処理プロセスを単純化することができる。
ＭＰＴＣＰヘッダ長の最小値およびＩＰヘッダ長の最小値はいずれも、２０バイトである。したがって、対象ＱｏＳレベルに対応する長さは、４０バイトより短いまたはそれと等しくてよい。
本発明のこの実施形態では、ＱｏＳレベルに対応するバイト長を設定することにより、ＭＰＴＣＰパケットの長さが必ず対象ＱｏＳレベルに対応するバイト長より長いまたはそれと等しいことが保証されていることに留意すべきである。したがって、このステップでは、第１のプロキシデバイスは、ＭＰＴＣＰパケットの長さを対象ＱｏＳレベルに対応するバイト長と比較しなくてもよく、第１のＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割する処理を直接実施してもよい。
このステップでは、第１のプロキシデバイスが各ＭＰＴＣＰパケットを対応する第２のＩＰパケットにカプセル化するときに第１のプロキシデバイスにより追加されるＩＰヘッダが、ステップ１０３の第２のＩＰヘッダであることに留意すべきである。言い換えれば、第２のＩＰヘッダは、ステップ１０３で取得された各セグメントに対応する第２のＩＰパケットの最も外側のＩＰヘッダである。
１０６．第１のプロキシデバイスが、第２のプロキシデバイスとのＭＰＴＣＰ接続を使用して少なくとも１つの第２のＩＰパケットを第２のプロキシデバイスに送信する。
各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化した後、第１のデバイスは、第１のプロキシデバイスと第２のプロキシデバイスとの間でＭＰＴＣＰ接続を使用して少なくとも１つの第２のＩＰパケットを送信し得る。
本発明のこの実施形態では、第２のＩＰパケット内のＭＰＴＣＰヘッダは通常、送信元ポート情報および宛先ポート情報を含み、第２のＩＰパケットの最も外側の第２のＩＰヘッダは通常、送信元アドレス情報および宛先アドレス情報を含む。
１０７．第１のプロキシデバイスとのＭＰＴＣＰ接続を使用して、同じＭＰＴＣＰパケットに属する少なくとも１つの第２のＩＰパケットを受信した後、第２のプロキシデバイスが、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長を取得する。
第１のプロキシデバイスとのＭＰＴＣＰ接続を使用して第２のＩＰパケットを受信した後、第２のプロキシデバイスは、第２のＩＰパケット内の第２のＩＰヘッダに基づき、同じＭＰＴＣＰパケットに属する第２のＩＰパケットを識別することができる。同じＭＰＴＣＰパケットの第２のＩＰパケット内の対象ＩＰパケットの位置は、第２のプロキシデバイスに事前設定されている。したがって、同じＭＰＴＣＰパケットに属する第２のＩＰパケット内の対象ＩＰパケットを決定することができ、対象ＩＰパケットのペイロード長を取得することができる。具体的には、対象ＩＰパケットのペイロード長を対象ＩＰパケットのＩＰヘッダから取得することができる。
１０８．対象ＩＰパケットのペイロード長に基づき、第２のプロキシデバイスが少なくとも１つの第２のＩＰパケットの対象ＱｏＳレベルを決定する。
本発明のこの実施形態では、第１のプロキシデバイスは、受信されたＵＤＰパケットを少なくとも２つのセグメントに分割する。各セグメントがＭＰＴＣＰパケットにカプセル化された後、ＭＰＴＣＰパケットは少なくとも１つの第２のＩＰパケットにカプセル化され、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長は、対象ＱｏＳレベルに対応するバイト長と等しい。言い換えれば、同じＭＰＴＣＰパケットの対象ＱｏＳレベルは、対象ＩＰパケットのペイロード長を使用して示される。したがって、本発明のこの実施形態では、第１のプロキシデバイスが、ＭＰＴＣＰ接続を使用して、カプセル化を通して取得された少なくとも１つの第２のＩＰパケットを第２のプロキシデバイスに送信した後、第２のプロキシデバイスは、対象ＩＰパケットのペイロード長に基づき同じＭＰＴＣＰパケットの対象ＱｏＳレベルを正確に決定し、同じＭＰＴＣＰパケットに属する少なくとも１つの第２のＩＰパケットに対して、対応するＱｏＳ処理を正確に実施することができる。これにより、ＵＤＰパケットの最も外側にカプセル化されたＩＰヘッダ内にＱｏＳ情報が存在しないために、ピアデバイスがＵＤＰパケットに対して対応するＱｏＳ処理を決定することができないという問題が回避される。
本発明のこの実施形態では、ステップ１０３からステップ１０５における、第１のプロキシデバイスにより第１のＩＰパケットを処理するプロセスを、図４に示す概略図を一例として使用することにより説明する。ステップ１０１において、第１のプロキシデバイスは第１のＩＰパケットを受信する。第１のＩＰパケットは、ＵＤＰパケットおよび第１のＩＰヘッダを含む。図４では、ＩＰヘッダ１は第１のＩＰヘッダを表し、ＵＤＰパケットは２つの部分、すなわち、ＵＤＰヘッダおよびペイロードを含む。ステップ１０３において、第１のプロキシデバイスは、ＵＤＰパケットを少なくとも２つのセグメントに分割する。図４に示すように、例えば、ＵＤＰパケットは、第１のプロキシデバイスにより２つのセグメントに分割される。ＵＤＰヘッダおよびペイロードを含むＵＤＰパケットは破線Ａにより分割されて、２つのセグメント、すなわち、セグメント１およびセグメント２が得られる。各セグメントの長さとＩＰヘッダ１の長さとの和は、ＭＴＵと第１の長さとの差より小さいまたはそれと等しい。第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰヘッダの長さとの和である。次に、ステップ１０４が実施される。具体的には、第１のプロキシデバイスが各セグメントをＭＰＴＣＰパケットにカプセル化する。図４に示すように、ＩＰヘッダ１およびＭＰＴＣＰヘッダは、セグメント１およびセグメント２のそれぞれにカプセル化される。言い換えれば、第１のＩＰヘッダおよびＭＰＴＣＰヘッダがカプセル化される。ＩＰヘッダ１がカプセル化されると、ＩＰヘッダ１内のペイロード長指示フィールドは、各セグメントの長さに修正される。次に、ステップ１０５が実施される。具体的には、第１のプロキシデバイスが各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する。図４に示すように、例えば、セグメント２がカプセル化された後に取得されたＭＰＴＣＰパケットが２つの第２のＩＰパケットにカプセル化され、対象ＩＰパケットは、２つの第２のＩＰパケット内の開始ＩＰパケットである。第１のプロキシデバイスは、破線Ｂにより、セグメント２がカプセル化された後に取得されたＭＰＴＣＰパケットを２つのＭＰＴＣＰパケットフラグメント、すなわち、フラグメント１およびフラグメント２に分割する。フラグメント２は、開始ＭＰＴＣＰパケットフラグメント、すなわち、対象ＭＰＴＣＰパケットフラグメントである。次に、これらのＭＰＴＣＰパケットフラグメントの各々が第２のＩＰパケットにカプセル化される。図４では、ＩＰヘッダ２が第２のＩＰヘッダを表し、フラグメント２および対応するＩＰヘッダ２を含む第２のＩＰパケットが対象ＩＰパケットである。
図５は、本発明の実施形態に係る、サービス品質を決定するための装置２００の概略ブロック図である。図５に示すように、装置２００は、第１のインターネットプロトコルＩＰパケットを受信するように構成された受信ユニット２０１であって、第１のＩＰパケットが、ユーザデータグラムプロトコルＵＤＰパケットおよび第１のＩＰヘッダを含む、受信ユニット２０１と、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象ＱｏＳレベルを決定するように構成された決定ユニット２０２と、ＵＤＰパケットを少なくとも２つのセグメントに分割するように構成された分割ユニット２０３と、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化するように構成されたカプセル化ユニット２０４であって、カプセル化ユニット２０４がさらに、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化するように構成され、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、カプセル化ユニット２０４と、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して少なくとも１つの第２のＩＰパケットを送信するように構成された送信ユニット２０５であって、これにより、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定する、送信ユニット２０５とを含む。
本発明のこの実施形態では、受信されたＵＤＰパケットは、少なくとも２つのセグメントに分割される。各セグメントがＭＰＴＣＰパケットにカプセル化された後、ＭＰＴＣＰパケットは、少なくとも１つの第２のＩＰパケットにカプセル化される。さらに、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長は、対象ＱｏＳレベルに対応するバイト長と等しい。言い換えれば、同じＭＰＴＣＰパケットの対象ＱｏＳレベルは、対象ＩＰパケットのペイロード長を使用して示される。したがって、本発明のこの実施形態では、カプセル化を通して取得された第２のＩＰパケットがＭＰＴＣＰ接続を使用してピアデバイスに送信された後、ピアデバイスは、対象ＩＰパケットのペイロード長に基づき同じＭＰＴＣＰパケットの対象ＱｏＳレベルを正確に決定し、ＵＤＰパケットに対して対応するＱｏＳ処理を正確に実施することができる。これにより、ＵＤＰパケットの最も外側にカプセル化されたＩＰヘッダ内にＱｏＳ情報が存在しないために、ピアデバイスがＵＤＰパケットに対して対応するＱｏＳ処理を決定することができないという問題が回避される。
少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、カプセル化ユニット２０４は、特に、すべてのＭＰＴＣＰパケット内の第１のＭＰＴＣＰパケットについて、第１のＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割することであって、少なくとも２つのＭＰＴＣＰパケットフラグメント内の対象ＭＰＴＣＰパケットフラグメントの長さが、対象ＱｏＳレベルに対応するバイト長と等しく、第１のＭＰＴＣＰパケットの長さが、対象ＱｏＳレベルに対応するバイト長より長い、分割することと、少なくとも２つのＭＰＴＣＰパケットフラグメントを対応する第２のＩＰパケットにカプセル化することであって、対象ＭＰＴＣＰパケットフラグメントに対応する第２のＩＰパケットが、対象ＩＰパケットである、カプセル化することとを行うように構成されていることが理解され得る。
少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、カプセル化ユニット２０４は、特に、すべてのＭＰＴＣＰパケット内の第２のＭＰＴＣＰパケットについて、第２のＭＰＴＣＰパケットにパディングデータを追加することにより、パディングデータが追加された第２のＭＰＴＣＰパケットの長さを対象ＱｏＳレベルに対応するバイト長と等しくすることであって、第２のＭＰＴＣＰパケットの長さが、対象ＱｏＳレベルに対応するバイト長より短い、等しくすること段階と、パディングデータが追加された第２のＭＰＴＣＰパケットを対応する第２のＩＰパケットにカプセル化することであって、パディングデータが追加された第２のＭＰＴＣＰパケットに対応する第２のＩＰパケットが、対象ＩＰパケットである、カプセル化することとを行うように構成されていることが理解され得る。
対象ＩＰパケットは、少なくとも１つの第２のＩＰパケット内の開始ＩＰパケットであることが理解され得る。
少なくとも２つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和が、最大伝送単位ＭＴＵと第１の長さとの差より小さいまたはそれと等しく、第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和であることが理解され得る。
少なくとも１つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、事前設定された長さより短いまたはそれと等しく、事前設定された長さは、ＭＴＵと第１の事前設定値との差であり、第１の事前設定値は、ＭＰＴＣＰヘッダ長の最大値とＩＰヘッダ長の最大値との和であることが理解され得る。
決定ユニット２０２はさらに、ＱｏＳレベルとバイト長との対応関係に基づき、対象ＱｏＳレベルに対応するバイト長を決定するように構成されていることが理解され得る。
ＱｏＳレベルとバイト長との対応関係は事前設定されており、対応関係内の各ＱｏＳレベルに対応するバイト長の最大値は、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しいことが理解され得る。
少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、カプセル化ユニットが、特に、セグメントごとに第１のＩＰヘッダをカプセル化することであって、第１のＩＰヘッダ内のペイロード長指示フィールドが、対応するセグメントの長さに修正される、カプセル化することと、第１のＩＰヘッダがカプセル化された後に各セグメントをＭＰＴＣＰパケットにカプセル化することとを行うように構成されていることが理解され得る。
本発明のこの実施形態に係る、サービス品質を決定するための装置２００は、本発明の前述の実施形態に係る、サービス品質を決定するための方法を実行するためのエンティティに対応してもよく、サービス品質を決定するための装置２００におけるモジュールの前述および他の動作および／または機能は、図２の第１のプロキシデバイスにより実行される方法の対応する手順を実装するために別々に使用される。簡潔さのために、詳細はここで再度説明しない。
図６は、本発明の別の実施形態に係る、サービス品質を決定するための装置３００の概略ブロック図である。図６に示すように、装置３００は、ピアデバイスとのマルチパス伝送制御プロトコルＭＰＴＣＰ接続を使用して、同じＭＰＴＣＰパケットに属し、かつピアデバイスにより送信された少なくとも１つのインターネットプロトコルＩＰパケットを受信するように構成された受信ユニット３０１と、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得するように構成された取得ユニット３０２と、対象ＩＰパケットのペイロード長に基づき、少なくとも１つのＩＰパケットの対象ＱｏＳレベルを決定するように構成された決定ユニット３０３とを含む。
本発明のこの実施形態では、ピアデバイスは、対象ＩＰパケットのペイロード長を使用して、同じＭＰＴＣＰパケットの対象ＱｏＳレベルを示す。したがって、同じＭＰＴＣＰパケットに属する少なくとも１つのＩＰパケットが受信された後、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長に基づき、同じＭＰＴＣＰパケットの対象ＱｏＳレベルが正確に決定され得、対応するＱｏＳ処理が、ＵＤＰパケットに対して正確に実施され得る。これにより、ＵＤＰパケットの最も外側にカプセル化されたＩＰヘッダ内にＱｏＳ情報が存在しないためにＵＤＰパケットに対する対応するＱｏＳ処理を決定することができないという問題が回避される。
対象ＩＰパケットは、少なくとも１つのＩＰパケット内の開始ＩＰパケットであることが理解され得る。
対象ＩＰパケットのペイロード長は、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたはそれと等しいことが理解され得る。
本発明のこの実施形態に係る、サービス品質を決定するための装置３００は、本発明の前述の実施形態に係る、サービス品質を決定するための方法を実行するためのエンティティに対応してもよく、サービス品質を決定するための装置３００におけるモジュールの前述および他の動作および／または機能は、図２の第２のプロキシデバイスにより実行される方法の対応する手順を実装するために別々に使用される。簡潔さのために、詳細はここで再度説明しない。
図７は、本発明の実施形態に係る、サービス品質を決定するためのデバイス４００の概略ブロック図である。デバイス４００は、複数のハードディスクに接続されている。図７に示すように、デバイス４００は、プロセッサ４０１と、メモリ４０２と、通信インタフェース４０３とを含む。メモリ４０２は、実行可能なプログラムコードを記憶するように構成されている。プロセッサ４０１は、メモリ４０２に記憶された実行可能なプログラムコードを読み取ることにより、実行可能なプログラムコードに対応するプログラムを実行する。通信インタフェース４０３は、外部デバイスと通信するように構成されている。デバイス４００は、バス４０４をさらに含んでもよい。バス４０４は、プロセッサ４０１、メモリ４０２、および通信インタフェース４０３を接続するように構成されているので、プロセッサ４０１、メモリ４０２、および通信インタフェース４０３は、バス４０４を使用して互いと通信する。
本発明のこの実施形態に係るデバイス４００は、本発明の前述の実施形態に係る、サービス品質を決定するための方法を実行するためのエンティティに対応してもよく、デバイス４００における前述の動作および／または機能は、図２の第１のプロキシデバイスにより実行される方法の対応する手順を実装するために別々に使用される。簡潔さのために、詳細はここで再度説明しない。
図８は、本発明の別の実施形態に係る、サービス品質を決定するためのデバイス５００の概略ブロック図である。デバイス５００は、複数のハードディスクに接続されている。図８に示すように、デバイス５００は、プロセッサ５０１と、メモリ５０２と、通信インタフェース５０３とを含む。メモリ５０２は、実行可能なプログラムコードを記憶するように構成されている。プロセッサ５０１は、メモリ５０２に記憶された実行可能なプログラムコードを読み取ることにより、実行可能なプログラムコードに対応するプログラムを実行する。通信インタフェース５０３は、外部デバイスと通信するように構成されている。デバイス５００は、バス５０４をさらに含んでもよい。バス５０４は、プロセッサ５０１、メモリ５０２、および通信インタフェース５０３を接続するように構成されているので、プロセッサ５０１、メモリ５０２、および通信インタフェース５０３は、バス５０４を使用して互いと通信する。
本発明のこの実施形態に係るデバイス５００は、本発明の前述の実施形態に係る、サービス品質を決定するための方法を実行するためのエンティティに対応してもよく、デバイス５００における前述の動作および／または機能は、図２の第１のプロキシデバイスにより実行される方法の対応する手順を実装するために別々に使用される。簡潔さのために、詳細はここで再度説明しない。
上述の実施形態のすべてまたは一部は、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせを使用することによって実装されてよい。これらの実施形態を実装するためにソフトウェアが使用される場合、これらの実施形態は、コンピュータプログラム製品の形態で完全にまたは部分的に実装されてよい。コンピュータプログラム製品は、１または複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ実行されると、本発明の実施形態に係る手順または機能のすべてまたは一部が行われる。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または別のプログラム可能な装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されても、あるコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体へ伝送されてもよい。例えば、コンピュータ命令は、あるウェブサイト、コンピュータ、サーバ、またはデータセンタから別のウェブサイト、コンピュータ、サーバ、またはデータセンタに有線方式（例えば、同軸ケーブル、光ファイバ、もしくはデジタル加入者線（ＤＳＬ））または無線方式（例えば、赤外線、電波、もしくはマイクロ波）で伝送され得る。コンピュータ可読記憶媒体は、コンピュータがアクセス可能な任意の使用可能な媒体であっても、１または複数の使用可能な媒体を統合したサーバまたはデータセンタ等のデータ記憶デバイスであってもよい。使用可能な媒体は、磁気媒体（例えば、フロッピディスク、ハードディスク、または磁気テープ）、光媒体（例えば、ＤＶＤ）、または半導体媒体（例えば、ソリッドステートディスク（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｉｓｋ、ＳＳＤ））等であってよい。
本発明は、通信技術の分野に関し、特に、サービス品質を決定するための方法および装置、ならびにプログラムに関する。
本出願は、ＵＤＰパケットに対して対応するＱｏＳ処理を正確に実施することができないという問題を解決するために、サービス品質を決定するための方法および装置、ならびにプログラムを提供する。
第１の態様によれば、本出願は、サービス品質を決定するための方法を提供する。本方法は、第１のインターネットプロトコル（ＩＰ）パケットを受信する段階であって、第１のＩＰパケットが、ユーザデータグラムプロトコル（ＵＤＰ）パケットおよび第１のＩＰヘッダを含む、段階と、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象サービス品質（ＱｏＳ）レベルを決定する段階と、ＵＤＰパケットを少なくとも２つのセグメントに分割する段階と、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコル（ＭＰＴＣＰ）パケットにカプセル化する段階と、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階であって、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、段階と、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して、少なくとも１つの第２のＩＰパケットを送信して、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定できるようにする、段階とを含む。
第１の態様または上記の任意の実装例に関連して、第１の態様の第４の実装例では、少なくとも２つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、最大伝送単位（ＭＴＵ）と第１の長さとの差より小さいまたはそれと等しく、第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和である。
第１の態様または上記の任意の実装例に関連して、第１の態様の第８の実装例では、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコル（ＭＰＴＣＰ）パケットにカプセル化する段階は、セグメントごとに第１のＩＰヘッダをカプセル化する段階であって、第１のＩＰヘッダ内のペイロード長指示フィールドが、対応するセグメントの長さに修正される、段階と、第１のＩＰヘッダがカプセル化された後に各セグメントをＭＰＴＣＰパケットにカプセル化する段階とを含む。
第２の態様によれば、本出願は、サービス品質を決定するための方法を提供する。本方法は、ピアデバイスとのマルチパス伝送制御プロトコル（ＭＰＴＣＰ）接続を使用して、同じＭＰＴＣＰパケットに属し、かつピアデバイスにより送信された少なくとも１つのインターネットプロトコル（ＩＰ）パケットを受信する段階と、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得する段階と、対象ＩＰパケットのペイロード長に基づき、少なくとも１つのＩＰパケットの対象サービス品質（ＱｏＳ）レベルを決定する段階と、を含む。
第３の態様によれば、本出願は、サービス品質を決定するための装置を提供する。本装置は、第１のインターネットプロトコル（ＩＰ）パケットを受信するように構成された受信ユニットであって、第１のＩＰパケットが、ユーザデータグラムプロトコル（ＵＤＰ）パケットおよび第１のＩＰヘッダを含む、受信ユニットと、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象サービス品質ＱｏＳレベルを決定するように構成された決定ユニットと、ＵＤＰパケットを少なくとも２つのセグメントに分割するように構成された分割ユニットと、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコル（ＭＰＴＣＰ）パケットにカプセル化するように構成されたカプセル化ユニットであって、カプセル化ユニットがさらに、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化するように構成され、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、カプセル化ユニットと、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して少なくとも１つの第２のＩＰパケットを送信することにより、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定するように構成された送信ユニットとを含む。
第３の態様または上記の任意の実装例に関連して、第３の態様の第４の実装例では、少なくとも２つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和は、最大伝送単位（ＭＴＵ）と第１の長さとの差より小さいまたはそれと等しく、第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和である。
第４の態様によれば、本出願は、サービス品質を決定するための装置を提供する。本装置は、ピアデバイスとのマルチパス伝送制御プロトコル（ＭＰＴＣＰ）接続を使用して、同じＭＰＴＣＰパケットに属し、かつピアデバイスにより送信された少なくとも１つのインターネットプロトコル（ＩＰ）パケットを受信するように構成された受信ユニットと、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得するように構成された取得ユニットと、対象ＩＰパケットに含まれるＭＰＴＣＰパケットの長さに基づき、少なくとも１つのＩＰパケットの対象サービス品質（ＱｏＳ）レベルを決定するように構成された決定ユニットとを含む。
図５は、本発明の実施形態に係る、サービス品質を決定するための装置２００の概略ブロック図である。図５に示すように、装置２００は、第１のインターネットプロトコル（ＩＰ）パケットを受信するように構成された受信ユニット２０１であって、第１のＩＰパケットが、ユーザデータグラムプロトコル（ＵＤＰ）パケットおよび第１のＩＰヘッダを含む、受信ユニット２０１と、第１のＩＰパケット内の情報に基づき、ＵＤＰパケットが属する対象ＱｏＳレベルを決定するように構成された決定ユニット２０２と、ＵＤＰパケットを少なくとも２つのセグメントに分割するように構成された分割ユニット２０３と、少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコル（ＭＰＴＣＰ）パケットにカプセル化するように構成されたカプセル化ユニット２０４であって、カプセル化ユニット２０４がさらに、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化するように構成され、少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、対象ＱｏＳレベルに対応するバイト長と等しい、カプセル化ユニット２０４と、ピアデバイスに対して、ピアデバイスとのＭＰＴＣＰ接続を使用して少なくとも１つの第２のＩＰパケットを送信するように構成された送信ユニット２０５であって、これにより、ピアデバイスが、対象ＩＰパケットのペイロード長に基づき、対象ＱｏＳレベルを決定する、送信ユニット２０５とを含む。
少なくとも２つのセグメントの各々の長さと第１のＩＰヘッダの長さとの和が、最大伝送単位（ＭＴＵ）と第１の長さとの差より小さいまたはそれと等しく、第１の長さは、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和であることが理解され得る。
図６は、本発明の別の実施形態に係る、サービス品質を決定するための装置３００の概略ブロック図である。図６に示すように、装置３００は、ピアデバイスとのマルチパス伝送制御プロトコル（ＭＰＴＣＰ）接続を使用して、同じＭＰＴＣＰパケットに属し、かつピアデバイスにより送信された少なくとも１つのインターネットプロトコル（ＩＰ）パケットを受信するように構成された受信ユニット３０１と、少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得するように構成された取得ユニット３０２と、対象ＩＰパケットのペイロード長に基づき、少なくとも１つのＩＰパケットの対象ＱｏＳレベルを決定するように構成された決定ユニット３０３とを含む。

Claims (26)

  1. サービス品質を決定するための方法であって、
    第１のインターネットプロトコルＩＰパケットを受信する段階であって、前記第１のＩＰパケットが、ユーザデータグラムプロトコルＵＤＰパケットおよび第１のＩＰヘッダを含む、段階と、
    前記第１のＩＰパケット内の情報に基づき、前記ＵＤＰパケットが属する対象サービス品質ＱｏＳレベルを決定する段階と、
    前記ＵＤＰパケットを少なくとも２つのセグメントに分割する段階と、
    前記少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化する段階と、
    各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する段階であって、前記少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、前記対象ＱｏＳレベルに対応するバイト長と等しい、段階と、
    ピアデバイスに対して、前記ピアデバイスとのＭＰＴＣＰ接続を使用して、前記少なくとも１つの第２のＩＰパケットを送信することにより、前記ピアデバイスが、前記対象ＩＰパケットの前記ペイロード長に基づき、前記対象ＱｏＳレベルを決定する段階と
    を含む、方法。
  2. 各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する前記段階が、
    すべての前記ＭＰＴＣＰパケット内の第１のＭＰＴＣＰパケットについて、前記第１のＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割する段階であって、前記少なくとも２つのＭＰＴＣＰパケットフラグメント内の対象ＭＰＴＣＰパケットフラグメントの長さが、前記対象ＱｏＳレベルに対応する前記バイト長と等しく、前記第１のＭＰＴＣＰパケットの長さが、前記対象ＱｏＳレベルに対応する前記バイト長より長い、段階と、
    前記少なくとも２つのＭＰＴＣＰパケットフラグメントを対応する第２のＩＰパケットにカプセル化する段階であって、前記対象ＭＰＴＣＰパケットフラグメントに対応する第２のＩＰパケットが、前記対象ＩＰパケットである、段階と
    を含む、請求項１に記載の方法。
  3. 各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する前記段階が、
    すべての前記ＭＰＴＣＰパケット内の第２のＭＰＴＣＰパケットについて、前記第２のＭＰＴＣＰパケットにパディングデータを追加することにより、前記パディングデータが追加された前記第２のＭＰＴＣＰパケットの長さを前記対象ＱｏＳレベルに対応する前記バイト長と等しくする段階であって、前記第２のＭＰＴＣＰパケットの長さが、前記対象ＱｏＳレベルに対応する前記バイト長より短い、段階と、
    前記パディングデータが追加された前記第２のＭＰＴＣＰパケットを対応する第２のＩＰパケットにカプセル化する段階であって、前記パディングデータが追加された前記第２のＭＰＴＣＰパケットに対応する前記第２のＩＰパケットが、前記対象ＩＰパケットである、段階と
    を含む、請求項１または２に記載の方法。
  4. 前記対象ＩＰパケットが、前記少なくとも１つの第２のＩＰパケット内の開始ＩＰパケットである、請求項１から３のいずれか一項に記載の方法。
  5. 前記少なくとも２つのセグメントの各々の長さと前記第１のＩＰヘッダの長さとの和が、最大伝送単位ＭＴＵと第１の長さとの差より小さいまたは前記差と等しく、前記第１の長さが、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和である、請求項１から４のいずれか一項に記載の方法。
  6. 前記少なくとも１つのセグメントの各々の長さと前記第１のＩＰヘッダの前記長さとの和が、事前設定された長さより短いまたは前記事前設定された長さと等しく、前記事前設定された長さが、前記ＭＴＵと第１の事前設定値との差であり、前記第１の事前設定値が、ＭＰＴＣＰヘッダ長の最大値とＩＰヘッダ長の最大値との和である、請求項５に記載の方法。
  7. 各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化する前記段階の前に、前記方法がさらに、
    ＱｏＳレベルとバイト長との対応関係に基づき、前記対象ＱｏＳレベルに対応する前記バイト長を決定する段階を含む、請求項１から６のいずれか一項に記載の方法。
  8. ＱｏＳレベルとバイト長との前記対応関係が事前設定されており、前記対応関係内の各ＱｏＳレベルに対応するバイト長の最大値が、前記ＭＰＴＣＰヘッダ長の最小値と前記ＩＰヘッダ長の最小値との和より小さいまたは前記和と等しい、請求項７に記載の方法。
  9. 前記少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化する前記段階が、
    セグメントごとに前記第１のＩＰヘッダをカプセル化する段階であって、前記第１のＩＰヘッダ内のペイロード長指示フィールドが、前記対応するセグメントの長さに修正される、段階と、
    前記第１のＩＰヘッダがカプセル化された後に各セグメントをＭＰＴＣＰパケットにカプセル化する段階と
    を含む、請求項１から８のいずれか一項に記載の方法。
  10. サービス品質を決定するための方法であって、
    ピアデバイスとのマルチパス伝送制御プロトコルＭＰＴＣＰ接続を使用して、同じＭＰＴＣＰパケットに属し、かつ前記ピアデバイスにより送信された少なくとも１つのインターネットプロトコルＩＰパケットを受信する段階と、
    前記少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得する段階と、
    前記対象ＩＰパケットの前記ペイロード長に基づき、前記少なくとも１つのＩＰパケットの対象サービス品質ＱｏＳレベルを決定する段階と
    を含む、方法。
  11. 前記対象ＩＰパケットが、前記少なくとも１つのＩＰパケット内の開始ＩＰパケットである、請求項１０に記載の方法。
  12. 前記対象ＩＰパケットの前記ペイロード長が、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたは前記和と等しい、請求項１０または１１に記載の方法。
  13. サービス品質を決定するための装置であって、
    第１のインターネットプロトコルＩＰパケットを受信するように構成された受信ユニットであって、前記第１のＩＰパケットが、ユーザデータグラムプロトコルＵＤＰパケットおよび第１のＩＰヘッダを含む、受信ユニットと、
    前記第１のＩＰパケット内の情報に基づき、前記ＵＤＰパケットが属する対象サービス品質ＱｏＳレベルを決定するように構成された決定ユニットと、
    前記ＵＤＰパケットを少なくとも２つのセグメントに分割するように構成された分割ユニットと、
    前記少なくとも２つのセグメントの各々をマルチパス伝送制御プロトコルＭＰＴＣＰパケットにカプセル化するように構成されたカプセル化ユニットであって、前記カプセル化ユニットがさらに、各ＭＰＴＣＰパケットを少なくとも１つの第２のＩＰパケットにカプセル化するように構成され、前記少なくとも１つの第２のＩＰパケット内の対象ＩＰパケットのペイロード長が、前記対象ＱｏＳレベルに対応するバイト長と等しい、カプセル化ユニットと、
    ピアデバイスに対して、前記ピアデバイスとのＭＰＴＣＰ接続を使用して、前記少なくとも１つの第２のＩＰパケットを送信することにより、前記ピアデバイスが、前記対象ＩＰパケットの前記ペイロード長に基づき、前記対象ＱｏＳレベルを決定するように構成された送信ユニットと
    を備える、装置。
  14. 前記少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、前記カプセル化ユニットが、特に、
    すべての前記ＭＰＴＣＰパケット内の第１のＭＰＴＣＰパケットについて、前記第１のＭＰＴＣＰパケットを少なくとも２つのＭＰＴＣＰパケットフラグメントに分割することであって、前記少なくとも２つのＭＰＴＣＰパケットフラグメント内の対象ＭＰＴＣＰパケットフラグメントの長さが、前記対象ＱｏＳレベルに対応する前記バイト長と等しく、前記第１のＭＰＴＣＰパケットの長さが、前記対象ＱｏＳレベルに対応する前記バイト長より長い、分割することと、
    前記少なくとも２つのＭＰＴＣＰパケットフラグメントを対応する第２のＩＰパケットにカプセル化することであって、前記対象ＭＰＴＣＰパケットフラグメントに対応する第２のＩＰパケットが、前記対象ＩＰパケットである、カプセル化することと
    を行うように構成されている、請求項１３に記載の装置。
  15. 前記少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、前記カプセル化ユニットが、特に、
    すべての前記ＭＰＴＣＰパケット内の第２のＭＰＴＣＰパケットについて、前記第２のＭＰＴＣＰパケットにパディングデータを追加することにより、前記パディングデータが追加された前記第２のＭＰＴＣＰパケットの長さを前記対象ＱｏＳレベルに対応する前記バイト長と等しくすることであって、前記第２のＭＰＴＣＰパケットの長さが、前記対象ＱｏＳレベルに対応する前記バイト長より短い、等しくすることと、
    前記パディングデータが追加された前記第２のＭＰＴＣＰパケットを対応する第２のＩＰパケットにカプセル化することであって、前記パディングデータが追加された前記第２のＭＰＴＣＰパケットに対応する前記第２のＩＰパケットが、前記対象ＩＰパケットである、カプセル化することと
    を行うように構成されている、請求項１３または１４に記載の装置。
  16. 前記対象ＩＰパケットが、前記少なくとも１つの第２のＩＰパケット内の開始ＩＰパケットである、請求項１３から１５のいずれか一項に記載の装置。
  17. 前記少なくとも２つのセグメントの各々の長さと前記第１のＩＰヘッダの長さとの和が、最大伝送単位ＭＴＵと第１の長さとの差より小さいまたは前記差と等しく、前記第１の長さが、各セグメントに対応するＭＰＴＣＰヘッダの長さと各セグメントに対応する第２のＩＰパケットのＩＰヘッダの長さとの和である、請求項１３から１６のいずれか一項に記載の装置。
  18. 前記少なくとも１つのセグメント２の各々の長さと前記第１のＩＰヘッダの前記長さとの和が、事前設定された長さより短いまたは前記事前設定された長さと等しく、前記事前設定された長さが、前記ＭＴＵと第１の事前設定値との差であり、前記第１の事前設定値が、ＭＰＴＣＰヘッダ長の最大値とＩＰヘッダ長の最大値との和である、請求項１７に記載の装置。
  19. 前記決定ユニットがさらに、ＱｏＳレベルとバイト長との対応関係に基づき、前記対象ＱｏＳレベルに対応する前記バイト長を決定するように構成されている、請求項１３から１８のいずれか一項に記載の装置。
  20. ＱｏＳレベルとバイト長との前記対応関係が事前設定されており、前記対応関係内の各ＱｏＳレベルに対応するバイト長の最大値が、前記ＭＰＴＣＰヘッダ長の最小値と前記ＩＰヘッダ長の最小値との和より小さいまたは前記和と等しい、請求項１９に記載の装置。
  21. 前記少なくとも２つのセグメントの各々をＭＰＴＣＰパケットにカプセル化するとき、前記カプセル化ユニットが、特に、
    セグメントごとに前記第１のＩＰヘッダをカプセル化することであって、前記第１のＩＰヘッダ内のペイロード長指示フィールドが、前記対応するセグメントの長さに修正される、カプセル化することと、
    前記第１のＩＰヘッダがカプセル化された後に各セグメントをＭＰＴＣＰパケットにカプセル化することと
    を行うように構成されている、請求項１３から２０のいずれか一項に記載の装置。
  22. サービス品質を決定するための装置であって、
    ピアデバイスとのマルチパス伝送制御プロトコルＭＰＴＣＰ接続を使用して、同じＭＰＴＣＰパケットに属し、かつ前記ピアデバイスにより送信された少なくとも１つのインターネットプロトコルＩＰパケットを受信するように構成された受信ユニットと、
    前記少なくとも１つのＩＰパケット内の対象ＩＰパケットのペイロード長を取得するように構成された取得ユニットと、
    前記対象ＩＰパケットの前記ペイロード長に基づき、前記少なくとも１つのＩＰパケットの対象サービス品質ＱｏＳレベルを決定するように構成された決定ユニットと
    を備える、装置。
  23. 前記対象ＩＰパケットが、前記少なくとも１つのＩＰパケット内の開始ＩＰパケットである、請求項２２に記載の装置。
  24. 前記対象ＩＰパケットの前記ペイロード長が、ＭＰＴＣＰヘッダ長の最小値とＩＰヘッダ長の最小値との和より小さいまたは前記和と等しい、請求項２２または２３に記載の装置。
  25. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体が命令を記憶し、前記命令がコンピュータで動作すると、前記コンピュータが、請求項１から９のいずれか一項に記載の方法を実施することが可能になる、コンピュータ可読記憶媒体。
  26. コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体が命令を記憶し、前記命令がコンピュータで動作すると、前記コンピュータが、請求項１０から１２のいずれか一項に記載の方法を実施することが可能になる、コンピュータ可読記憶媒体。
JP2020517777A 2017-09-30 2018-07-03 サービス品質を決定するための方法および装置、ならびにプログラム Active JP6968990B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201710944073.X 2017-09-30
CN201710944073.XA CN109600248B (zh) 2017-09-30 2017-09-30 服务质量的确定方法、装置及存储介质
PCT/CN2018/094294 WO2019062252A1 (zh) 2017-09-30 2018-07-03 服务质量的确定方法、装置及存储介质

Publications (2)

Publication Number Publication Date
JP2020536416A true JP2020536416A (ja) 2020-12-10
JP6968990B2 JP6968990B2 (ja) 2021-11-24

Family

ID=65900526

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020517777A Active JP6968990B2 (ja) 2017-09-30 2018-07-03 サービス品質を決定するための方法および装置、ならびにプログラム

Country Status (6)

Country Link
US (1) US11405489B2 (ja)
EP (1) EP3678332B1 (ja)
JP (1) JP6968990B2 (ja)
KR (1) KR102397029B1 (ja)
CN (1) CN109600248B (ja)
WO (1) WO2019062252A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111416794B (zh) * 2019-01-08 2022-07-29 华为技术有限公司 一种数据传输方法及电子设备
CN113014483B (zh) * 2019-12-19 2023-04-18 华为技术有限公司 一种多路径传输的方法及设备
TWI739256B (zh) * 2019-12-26 2021-09-11 威聯通科技股份有限公司 跨越不同傳輸協定的網路系統及轉換裝置
CN114666265B (zh) * 2022-03-28 2024-04-02 阿里巴巴（中国）有限公司 数据传输方法、装置、计算设备及介质

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070104224A1 (en) * 2005-11-04 2007-05-10 Conner Keith F Differentiated quality of service transport protocols
US20070297450A1 (en) * 2006-06-21 2007-12-27 Motorola, Inc. Method and apparatus for passing an application description to lower layer packet data protocol
WO2008021182A2 (en) 2006-08-09 2008-02-21 Interdigital Technology Corporation Method and apparatus for providing differentiated quality of service for packets in a particular flow
CN101282282B (zh) 2007-04-06 2010-08-25 杭州华三通信技术有限公司 服务质量等级确定方法、系统及终端
US8315241B2 (en) * 2008-03-31 2012-11-20 Lockheed Martin Corporation Method and apparatus for providing quality of service in wireless networks and sensor networks
US8310924B2 (en) * 2008-05-15 2012-11-13 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for providing QoS for MP subscribers at the subscriber level
JP5173786B2 (ja) 2008-12-22 2013-04-03 株式会社日立製作所 無線基地局装置および無線通信システム
WO2011153415A1 (en) * 2010-06-04 2011-12-08 Interdigital Patent Holdings, Inc. Mptcp and mobil ip interworking
EP3150019B1 (en) * 2014-06-02 2020-07-22 Nokia Solutions and Networks Oy Multipath tcp with lte connections
CN104995950A (zh) 2014-06-25 2015-10-21 华为技术有限公司 一种数据传输方法及设备
CN106507696B (zh) * 2015-06-26 2018-10-12 瑞典爱立信有限公司 用于确定是否要发起第二多路径传输控制协议连接的第一网络节点及其中的方法
EP3119057A1 (en) * 2015-07-16 2017-01-18 Deutsche Telekom AG Packet conversion device and method for allowing transparent packet-based multipath bundling
US20170063699A1 (en) * 2015-08-26 2017-03-02 Electronics And Telecommunications Research Institute Method and apparatus for configuring multi-paths using segment list
CN105490933B (zh) * 2015-12-28 2019-06-11 中国电子科技集团公司第五十四研究所 基于多路径传输协议mptcp的路径管理方法及装置
US10805846B2 (en) * 2016-03-29 2020-10-13 Lg Electronics Inc. Method and terminal for supporting service continuity after performing handover
KR20170133165A (ko) * 2016-05-25 2017-12-05 삼성전자주식회사 다중 링크를 이용해 신호를 전송하는 방법 및 장치
EP3625944B1 (en) * 2017-05-19 2021-07-07 Telefonaktiebolaget LM Ericsson (publ) Technique for enabling multipath transmission
CN110915290B (zh) * 2017-07-07 2023-09-01 诺基亚通信公司 支持多供应方4g/5g网络的多空中接口聚合

Also Published As

Publication number Publication date
CN109600248B (zh) 2020-09-08
US20200228633A1 (en) 2020-07-16
KR102397029B1 (ko) 2022-05-12
EP3678332A1 (en) 2020-07-08
EP3678332A4 (en) 2020-10-28
JP6968990B2 (ja) 2021-11-24
US11405489B2 (en) 2022-08-02
KR20200052972A (ko) 2020-05-15
CN109600248A (zh) 2019-04-09
WO2019062252A1 (zh) 2019-04-04
EP3678332B1 (en) 2023-09-06

Similar Documents

Publication Publication Date Title
US11277313B2 (en) Data transmission method and corresponding device
US20170302724A1 (en) Virtual Channel Joining
JP6968990B2 (ja) サービス品質を決定するための方法および装置、ならびにプログラム
CN109792621B (zh) 用于评估聚合的连接的网络性能的方法和系统
US20160150055A1 (en) Hardware-based packet forwarding for the transport layer
US9438496B2 (en) Monitoring link quality between network devices
US8976813B2 (en) Secure quality of service
US20170063699A1 (en) Method and apparatus for configuring multi-paths using segment list
EP3637703B1 (en) Message transmission methods and proxy servers
KR102442083B1 (ko) Tcp 터널들 및 고유 tcp 정보를 기초로 하는 번들링 시나리오에서 패킷들의 스케줄링을 위한 방법 및 시스템
US9071984B1 (en) Modifying a data flow mechanism variable in a communication network
WO2016180188A1 (zh) 分发建链方法、装置和系统
CN111211933B (zh) 一种确定传输链路的质量的方法及装置
CN106330386A (zh) 一种传输层参数调整方法和装置
US11979230B1 (en) Method and system for transmitting data over multiple paths
US20220070736A1 (en) Traffic steering device
WO2015096734A1 (zh) 一种业务数据的下行传输方法及分组数据网关
US10805219B2 (en) Methods and systems for evaluating network performance of an aggregated connection
US20190190835A1 (en) Methods and systems for evaluating network peformance of an aggregated connection
US20240236196A1 (en) Data transmission method and device
JP2024127482A (ja) 制御装置、制御方法及びプログラム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200507

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200507

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210527

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210615

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210908

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: 20210928

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211027

R150 Certificate of patent or registration of utility model

Ref document number: 6968990

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150