JP2020502873A - パケット送信方法および装置、チップ、ならびに端末 - Google Patents

パケット送信方法および装置、チップ、ならびに端末 Download PDF

Info

Publication number
JP2020502873A
JP2020502873A JP2019522717A JP2019522717A JP2020502873A JP 2020502873 A JP2020502873 A JP 2020502873A JP 2019522717 A JP2019522717 A JP 2019522717A JP 2019522717 A JP2019522717 A JP 2019522717A JP 2020502873 A JP2020502873 A JP 2020502873A
Authority
JP
Japan
Prior art keywords
packet
baseband processor
terminal
information
processor
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
JP2019522717A
Other languages
English (en)
Other versions
JP6924830B2 (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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2020502873A publication Critical patent/JP2020502873A/ja
Application granted granted Critical
Publication of JP6924830B2 publication Critical patent/JP6924830B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/189Transmission or retransmission of more than one copy of a message
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1628List acknowledgements, i.e. the acknowledgement message consisting of a list of identifiers, e.g. of sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/187Details of sliding window management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1896ARQ related signaling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/27Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0205Traffic management, e.g. flow control or congestion control at the air interface
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0273Traffic management, e.g. flow control or congestion control adapting protocols for flow control or congestion control to wireless environment, e.g. adapting transmission control protocol [TCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0289Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/188Time-out mechanisms

Abstract

本発明の実施形態は、パケット送信方法および装置、チップ、ならびに端末を記録する。本方法は、端末に適用され、端末はベースバンドプロセッサと、アプリケーションプロセッサと、通信インタフェースとを備え、本方法は、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップであり、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップであり、第2のパケットは第1のパケットと同一である、ステップと、ベースバンドプロセッサにより、通信インタフェースを使用して第2のパケットをネットワークデバイスに送信するステップとを含む。これにより、端末によるパケットの再送信の際の遅延をある程度減少することができ、端末とネットワークとの間のデータ通信がより円滑になる。

Description

本発明は、通信分野に関し、特に、パケット送信方法および装置、チップ、ならびに端末に関する。
モバイルインターネットアクセスが端末の主な特徴となるにつれて、ネットワークにアクセスするために端末によって使用される技術的解決策が発達している。これにより、端末製品の情報取得率が大幅に向上する。モバイル通信分野で一般的に使用されているTCP/IP(Transmission Control Protocol/Internet Protocol、伝送制御プロトコル/インターネットプロトコル)は、コネクション対応型であり、信頼性があり、かつバイトストリームベースのトランスポート層通信プロトコルである。
端末がTCP/IPプロトコルを用いてネットワークにアクセスする処理において、パケットは破棄されることが多い(これはパケットロスとも呼ばれる)。現在の処理方法は、通常、送信側がデータを再送信することである。現在の処理方法では、パケットが失われたかどうかは、受信側からのフィードバックによって判断される。例えば、送信側が、指定された時間内に、受信側によって送信されたACKなどのフィードバックメッセージを受信しなかった場合、パケットが失われたと判断され、失われたパケットのデータを含むパケットが再送される。この解決法では、パケット損失に応答するときに端末では比較的大きな遅延があり、端末とネットワークデバイスとの間のデータ伝送の停止時間は比較的長く、リアルタイムの通信品質は比較的深刻な影響を受ける。
これを考慮し、本発明の実施形態は、ベースバンドプロセッサによって破棄された送信対象パケットを端末により再送する際の遅延を減少し、また端末によるパケット損失に対する応答の際の遅延をある程度改善し、端末とネットワークとの間のデータ伝送がより円滑になるようなパケット送信方法および装置、チップ、ならびに端末を提供する。
第1の態様によれば、本発明の実施形態は、端末に適用されるパケット送信方法であって、端末はベースバンドプロセッサと、アプリケーションプロセッサと、通信インタフェースとを備え、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップであり、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、第1のパケットに関する情報は第1のパケットの識別子および第1のパケットが属するTCP接続の識別子を含む、ステップと、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップであり、第2のパケットは第1のパケットと同一である、ステップと、ベースバンドプロセッサにより、通信インタフェースを使用して第2のパケットをネットワークデバイスに送信するステップとを含む、パケット送信方法を提供する。
なお、ベースバンドプロセッサによって破棄された送信対象パケットは、アプリケーションプロセッサによってベースバンドプロセッサに配信され、かつベースバンドプロセッサによる通信インタフェースを使用したネットワークデバイスへの送信が失敗するパケットとして理解され得る。
ネットワークデバイスは、基地局またはサーバなどのデバイスとし得ることに留意されたい。
第2のパケットは、第1のパケットのコピーとして理解されてもよい。
このようにして、送信対象パケットを破棄した後、ベースバンドプロセッサは、アプリケーションプロセッサに、ベースバンドプロセッサによって破棄された送信対象パケットに関する情報をレポートし得るため、アプリケーションプロセッサは、レポートされた情報に従って、ベースバンドプロセッサによって破棄されたパケットのコピーをベースバンドプロセッサに再配信する。パケットのタイムアウトタイマーが満了し、確認応答パケットがピアエンドから受信されないと判定される前に、パケットが廃棄され、パケットがベースバンドプロセッサに再送信されることを決定することができる。これにより、ベースバンドプロセッサによって廃棄された送信対象パケットを端末により再送信する際の遅延を減少することができ、端末によるパケット損失に応答する際の遅延をある程度改善することができるため、端末とネットワークとの間のデータ送信はより滑らかになる。無線セルラネットワークの状態はしばしば変化するので、ベースバンドプロセッサが送信対象パケットを廃棄する事例が頻繁に発生する。
第1の態様を参照すると、第1の態様の第1の実装において、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップは、端末のデータ接続が利用可能な場合、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップを含む。
データ接続は、データサービスを実行するために使用される接続である。端末のデータ接続は、端末と基地局との間のデータ接続として理解され得る。
第1の態様または第1の態様の第1の実装を参照すると、別の実装において、
端末のデータ接続が利用不可である場合、ベースバンドプロセッサは、第1のパケットに関する情報をキャッシングし、端末のデータ接続が利用不可から利用可能に切り替えられた場合、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートする。
端末は、定期的な検出、イベントトリガ、命令トリガなどによって、端末のデータ接続が利用可能か利用不可かを判定し得ると理解されたい。以下のいずれかの場合、すなわち、端末が切断状態にある、端末が通常いずれのサービングセルにもキャンプオンし損なう、端末のデータサービスが無効状態にある、または2GへのCSFB(Circuit Switched Fallback、回線交換フォールバック)の場合に端末が2Gコールシナリオにある場合、端末のデータ接続は利用できない。
端末のデータ接続が利用不可から利用可能に切り替えられると、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに留意されたい。これは、端末のデータ接続が利用不可から利用可能に切り替わった後、ベースバンドプロセッサが第1のパケットに関する情報をアプリケーションプロセッサにレポートすることを示す。命令の読み出し、関連操作の実行などには時間がかかるため、同時性は厳密には要求されない。すなわち、端末のデータ接続が利用不可から利用可能に切り替わる状態切り替えの後の比較的短い時間(例えば、数ミリ秒または数秒)内に、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサへレポートする動作を完了する。
第1の態様および第2の態様において、ベースバンドプロセッサは、データ接続が利用可能な場合にのみ、廃棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートするので、再送信の有効性を改善することができる。破棄された送信対象パケットに関する情報が、データ接続が利用可能であるときにのみアプリケーションプロセッサにレポートされる場合、端末のエネルギー消費量は減少されることが可能である。
上記の実装のいずれか1つによれば、別の実装において、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップの後で、本方法はさらに、アプリケーションプロセッサにより、輻輳ウインドウを増大するステップを含む。
アプリケーションプロセッサが第2のパケットをベースバンドプロセッサに送信した後、輻輳ウインドウは縮小され得る。これにより、タイムアウト再送による影響が排除されることができ、端末により送信されるパケット量が確保されることができ、また端末の送信スループットを向上させることができる。
上記の実装のいずれか1つによれば、別の実装において、第1のパケットの識別子は、第1のパケットのシーケンス番号であり、第1のパケットが属するTCP接続の識別子は、第1のパケットが位置するTCP接続のソースポート番号であり、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップは、アプリケーションプロセッサにより、第1のパケットと同じシーケンス番号を有する第2のパケットをソースポート番号に応じてベースバンドプロセッサに送信するステップを含む。
第2の態様によれば、本発明の実施形態は、パケット送信装置を提供し、パケット送信装置は、ベースバンドプロセッサと、アプリケーションプロセッサと、送信器とを備える。ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成され、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、第1のパケットに関する情報は第1のパケットの識別子および第1のパケットが属するTCP接続の識別子を含み、アプリケーションプロセッサは、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同一であり、ベースバンドプロセッサはさらに、送信器を使用して第2のパケットをネットワークデバイスに送信するように構成される。
第2の態様は第1の態様に対応する装置であるため、様々な実装、説明、および技術的効果については、第1の態様の説明を参照されたい。
第3の態様によれば、チップが提供される。チップは、無線周波数コンポーネントを使用してネットワークデバイスに対するデータ接続を確立し、チップは、アプリケーションプロセッサおよびベースバンドプロセッサを備え、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成され、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、第1のパケットに関する情報は第1のパケットの識別子および第1のパケットが属するTCP接続の識別子を含み、アプリケーションプロセッサは、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同一であり、ベースバンドプロセッサはさらに、無線周波数コンポーネントを使用して第2のパケットをネットワークデバイスに送信するように構成される。
第3の態様は、第2の態様の具体的な製品形態である。第3の態様の様々な実装、説明、および技術的効果については、第2の態様を参照し、詳細は本明細書では再度説明されない。
第4の態様によれば、端末が提供される。端末は、アプリケーションプロセッサと、ベースバンドプロセッサと、メモリと、通信インタフェースとを備える。アプリケーションプロセッサ、ベースバンドプロセッサ、および通信インタフェースはメモリに接続され、アプリケーションプロセッサ、ベースバンドプロセッサ、および通信インタフェースは、メモリに格納された命令を呼び出すことによって、第1の態様の上記実装のいずれか一つの方法を実行する。
第5の態様によれば、格納媒体が提供され、第1の態様の上記実装のいずれか1つを実現し得る任意の方法を格納するように構成される。
第4の態様および第5の態様の様々な実装、説明、および技術的効果については、第1の態様を参照し、詳細は本明細書では再度説明されない。
本発明の実施形態の技術的解決策をより明確に説明するために、以下、実施形態を説明するために必要な添付図面を簡単に説明する。明らかに、以下の説明における添付図面は、単に本発明のいくつかの実施形態を示しており、当業者は創造的な努力なしにこれらの添付図面から他の図面をなお導出し得る。
図1は、本発明の実施形態によるシステムのネットワークの模式図である。 図2は、本発明の実施形態による端末のハードウェア構成の模式図である。 図3は、本発明の実施形態による端末のソフトウェアアーキテクチャの模式図である。 図4は、本発明の実施形態によるTCPパケットフォーマットの模式図である。 図5は、本発明の実施形態によるパケット送信方法の模式図である。 図6は、本発明の実施形態によるパケット送信装置の模式図である。 図7は、本発明の実施形態による端末の模式図である。 図8Aは、本発明の実施形態による送信側と受信側との間のパケット送信中のカプセル化処理の模式図である。 図8Bは、本発明の実施形態による送信側と受信側との間のパケット送信中のカプセル化処理の模式図である。
本発明の実施形態は、パケット送信方法および装置、チップ、および端末を提供する。以下、本発明の実施形態における技術的解決策を本発明の実施形態における添付図面を参照して明確かつ十分に説明する。明らかに、説明される実施形態は、単に本発明の実施形態のいくつかではあるがすべてではない。創造的な努力をせずに本発明の実施形態に基づいて当業者によって得られる他のすべての実施形態は、本発明の保護範囲に包含されるべきものである。
以下は、本発明の実施形態における技術用語の一部である。
輻輳ウインドウは、輻輳制御の場合に、TCPデータ送信中に1つのRTT期間内にデータのソース側によって送信されことができるデータパケットの最大量である。輻輳ウインドウのバックオフとは、ネットワークが輻輳しているときにデータの送信側が輻輳ウインドウを減少することを意味する。
モバイル通信サービスは、データサービス(Data Service)と音声サービスとに分類される。データサービスは、モバイル通信CS(Circuit Switched、回線交換)方式ドメイン音声サービス以外の他のサービスを含む。データ接続は、端末と基地局との間のデータ接続として理解されてもよく、端末と基地局との間の接続であり、データサービスを処理するために使用される接続を示す。端末と基地局との間のデータ接続が利用可能であることは、端末がデータサービスを処理するためにセルラネットワークを使用することを示し、すなわち、端末はセルラネットワーク内の基地局から信号を受信することができ、端末は、データサービスにおいて基地局とデータまたは命令を交換する機能を使用することができる。端末と基地局との間のデータ接続が利用不可であることは、端末がデータサービスを処理するためにセルラネットワークを使用できないことを示し、すなわち、端末はセルラネットワークから信号を受信できない、または端末は音声サービスを処理する必要があり、したがって、データサービスにおいてセルラネットワーク内の基地局とデータまたは命令を同時に交換することができない。現在、端末のデータ接続が利用不可であるという既知の事例には、以下のもの、すなわち、端末が切断状態にある、端末が通常いずれのサービングセルにもキャンプオンし損なう、端末のデータサービスが無効状態にある、または2GへのCSFB(Circuit Switched Fallback、回線交換フォールバック)の場合に端末がGコールシナリオにある場合が含まれる。
送信対象パケットとは、端末から基地局に送信されるパケットであり、通常、端末上で動作するアプリケーションによって生成され、基地局に送信する必要があるデータをプロトコルスタックを用いてカプセル化したTCPパケットである。送信対象パケット内のデータは、ユーザの何らかの行動または行為によって生成されることがある。例えば、アプリケーションはブラウザである。ユーザは、ブラウザに表示されたリンクをタップするか、WEBサイトのアカウントやパスワードを入力する。リンク上のデータまたはユーザによって入力されたアカウントまたはパスワードは、ブラウザが基地局に送信する必要があるデータである。送信対象パケット内のデータは、代替的に、実行中のプロセスにおいてタスクを実行するためのアプリケーションによって生成されてもよい。例えば、アプリケーションはブラウザである。ホームページ上のニュースウィンドウを定期的に更新するために、ブラウザは、基地局に送信する必要がある要求データを生成する。プロトコルスタックを用いてデータをカプセル化して得たパケットは、端末の無線周波数コンポーネント(例えば、アンテナ)を用いて端末により送信される前の送信対象パケットである。当業者は、端末が送信対象パケットを生成または決定し得ることを理解するべきである。送信対象パケットの生成方法は、本発明において限定されない。
同一性:本発明の実施形態における同一性は、完全な同一性または本質的な同一性を示す。例えば、第1のパケットと第2のパケットがTCPパケットである場合、第1のパケットと第2のパケットが同一であることは、少なくともデータ部、ソースポート番号、および宛先ポート番号などの情報に関して第1のパケットと第2のパケットが同一であることを示す。第2のパケットは第1のパケットのコピーとして理解されてもよく、それにより第1のパケットと第2のパケットのパケットヘッダまたはパケットトレーラの間の無視可能な差が許容される。これらの差は、例えば、タイムスタンプが異なる、またはいくつかのランダムに生成された値が異なるなどの理由により、パケットの生成中に端末によって生成されることがある。
本発明の実施形態において提供される技術的解決策は、典型的には、無線通信システム、例えば、モバイル通信用のグローバルシステム(GSM、Global System of Mobile Communication)ネットワーク、符号分割多重アクセス(CDMA、Code Division Multiple Access)ネットワーク、時分割同期符号分割多重アクセス(TDSCDMA、Time Division−Synchronous Code Division Multiple Access)ネットワーク、広帯域符号分割多重アクセス(WCDMA、Wideband Code Division Multiple Access Wireless)ネットワーク、汎用パケット無線サービス(GPRS、General Packet Radio Service)ネットワーク、ロングタームエボリューション(LTE、Long Term Evolution)ネットワーク、ソフトウェア定義ネットワーク(SDN、Software Defined Network)、またはワイヤレスセンサネットワーク(Wireless Sensor Network)に適用され得る。
図2は、本発明の実施形態による通信システム100の簡略ブロック図である。通信システム100は、本発明のアプリケーションシナリオとしてのみ使用される。これは、本発明のアプリケーションシナリオに対する限定として解釈されるべきではない。
本発明の明細書、特許請求の範囲、および添付の図面において、用語「第1の」、「第2の」、「第3の」、「第4の」など(存在する場合)は、類似の対象を区別することを意図しており、必ずしも特定の順番やシーケンスを示すとは限らない。
図2に示すように、通信システム100は、端末10と、アクセスポイント11と、ゲートウェイ12と、広域ネットワーク13と、サーバ20とを含む。本発明のこの実施形態における端末10は、モバイル端末(Mobile Terminal)、例えば、携帯電話、タブレット型コンピュータ、スポーツ射撃デバイス、またはノート型コンピュータなどの携帯型、ウェアラブル、または車載型のモバイルデバイスでもよく、またはセルラネットワークにアクセス可能なコンピュータまたはサーバなどのデバイス、またはセルラネットワークにアクセス可能なルータまたはゲートウェイ、例えば、SIM(Subscriber Identification Module、加入者識別モジュール)カードを使用可能なルータまたはゲートウェイなどのネットワークデバイスであってもよい。本発明のこの実施形態では、携帯電話が説明例として使用される。サーバ20は、アプリケーションサーバ、サーバエージェント、データセンタサーバ、またはルータやゲートウェイなどのネットワークデバイスとすることができる。
当業者であれば、通信システムは通常、図2に示すものより少ないかまたは多い構成要素を含み得る、または、図2に示すものと異なる構成要素も含み得ることを理解するであろう。図2は、本発明のこの実施形態で開示された実装により関連する構成要素のみを示す。例えば、図2は1つのサーバ20を示しているが、当業者は1つの通信システムが任意の数のサーバを含み得ることを理解するであろう。
広域ネットワーク14は、公衆ネットワーク、専用ネットワーク、またはインターネットの一部、および/またはそれらの任意の組み合わせを含み得る。アクセスポイントは、基地局、無線ローカルエリアネットワーク(WLAN)アクセスポイント、または他の形態のアクセスポイントであってもよい。ゲートウェイ12およびアクセスポイント11は無線ネットワークに含まれてもよい。簡潔にするために、無線ネットワークの他の部分は説明されない。
図2は、端末10のハードウェア構成をさらに示している。図2によると、端末10は、アプリケーションプロセッサ110、メモリ120、通信サブシステム130、および電力管理サブシステム140を含む。メモリ120は実行可能プログラムを格納し、実行可能プログラムはオペレーティングシステムおよびアプリケーションプログラムを含む。アプリケーションプロセッサ(Application Processor)110は、オペレーティングシステムやアプリケーションプログラムを実行するように構成されたプロセッサである。
実施形態では、アプリケーションプログラムはウェブブラウザであり、サーバ20はウェブコンテンツプロバイダのサーバである。別の実施形態では、第1のアプリケーションプログラムはオンラインビデオプレーヤであり、サーバ20はビデオコンテンツプロバイダのサーバである。別の実施形態では、第1のアプリケーションプログラムはインスタントメッセージングソフトウェアであり、サーバ20はインスタントメッセージングサービスプロバイダのサーバである。
通信サブシステム130は、主に、ベースバンド処理、変調および復調、信号増幅およびフィルタリング、ならびに平衡化などの機能を実施する。通信サブシステム130は、無線周波数モジュール132、アンテナ133、および無線モデム(Modem)とも呼ばれるベースバンドプロセッサ131(Communication Processor、CP)を含む。ベースバンドプロセッサ131およびWi−Fiモジュール150は1つのチップに統合されてもよいことに留意されたい。また、ベースバンドプロセッサ131とアプリケーションプロセッサ110とを1つのチップに集積してもよいし、それぞれ独立したチップであってもよい。図2は単なる例示的表現である。電力管理サブシステム140は、システムに電力を供給するように構成されている。
メモリ120は通常、内部メモリと外部ストレージとを含む。内部メモリは、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、キャッシュ(CACHE)などであってもよい。外部ストレージは、ハードディスク、光ディスク、USBフラッシュドライブ、フロッピーディスク、テープドライブなどであってもよい。実行可能プログラムは通常、外部ストレージに格納されており、アプリケーションプロセッサ110は、実行可能プログラムを外部ストレージから内部メモリにロードした後にそのプログラムを実行する。
オプションで、端末10はさらにWi−Fi(Wireless Fidelity、ワイヤレスフィデリティ)モジュール150を含み、Wi−Fiモジュール150はIEEE802.11シリーズのプロトコルをサポートし、端末10はWi−Fiモジュール150を使用してWLANにアクセスし得る。
オプションで、端末10は、ユーザによって入力された情報またはユーザに対して提供された情報を表示するように構成されたディスプレイ160と、端末10の様々なメニューインタフェースとをさらに含む。ディスプレイ160は、液晶ディスプレイ(英語:Liquid Crystal Display, LED)、有機発光ダイオード(英語:Organic Light−Emitting Diode、OLED)などであってもよい。いくつかの他の実施形態では、タッチパネルがディスプレイ160を覆ってタッチディスプレイスクリーンを形成してもよい。
また、端末10は、写真またはビデオを撮影するためのカメラ180と、重力センサ、加速度センサ、または光学センサなどの1つまたは複数のセンサ170とをさらに含み得る。
さらに、当業者は、端末10が図2に示されるものより少ないかまたは多い構成要素を含んでもよいことを理解しえ得る。また図2に示す端末10では、本発明のこの実施形態において開示されている複数の実装により関連する構成要素のみが示されている。
以下、端末10のハードウェアおよびソフトウェア環境についてさらに説明する。端末10は、論理レベルに従って、ハードウェア層、オペレーティングシステム、およびオペレーティングシステム上で動作するアプリケーション層(ユーザモードとも呼ばれる)に分割し得る。ハードウェア層は、図2に関する実施形態で説明したハードウェア、例えば、アプリケーションプロセッサ110、メモリ120、およびWi−Fiモジュール150を含む。オペレーティングシステムは、アンドロイド(登録商標)オペレーティングシステム、リナックス(登録商標)オペレーティングシステム、ウィンドウズ(登録商標)オペレーティングシステム、または他のタイプのオペレーティングシステムであってもよい。これは、本発明のこの実施形態においては限定されない。
実施形態では、オペレーティングシステムは、フレームワーク(フレームワーク)層、カーネルモード、およびドライバ層を含む。ドライバ層は、センサドライバ、Wi−Fiドライバ、ディスプレイドライバなどのハードウェアデバイスのドライバを含む。カーネルモードは、TCPプロトコルスタック、IPプロトコルスタックなどを含む。以下、本発明のこの実施形態における方法手順を参照してカーネルモードをさらに説明する。フレームワーク層は、ユーザ層とカーネルモードとの間の通信用のインタフェース、およびいくつかのサービス、例えば、グラフィックサービス(Graphic Service)224、システムサービス(System service)221、ウェブサービス(Web Service)222、およびユーザサービス(Customer Service)223などのアプリケーション層で動作するアプリケーションを含む。これらのアプリケーションは通常、ディスプレイを使用してユーザと直接相互作用することができ、これらのアプリケーションはギャラリー、メディアプレーヤ(Media Player)、ブラウザ(Browser)、WeChat(wechat)などである。オペレーティングシステム内のアプリケーションプログラムおよびアプリケーション層のアプリケーションプログラムは、実行可能プログラムとしてメモリ120に格納され得る。本発明のこの実施形態で使用される用語「プログラム」は、命令、命令セット、コード、コードセグメント、サブルーチン、ソフトウェアモジュール、アプリケーション、ソフトウェアパッケージスレッド、プロセス、機能、ファームウェア、ミドルウェアなどを含むがこれらに限定されないと広く解釈されるべきである。図2に示すように、端末10は、通信サブシステム130を使用してセルラネットワークにアクセスし、次いで広域ネットワーク13を使用してサーバ20と通信し得る。別の実施形態では、端末10はまた、Wi−Fiモジュール150を使用してWLANにアクセスし、次いで広域ネットワーク13を使用してサーバ20と通信し得る。具体的には、端末10は、ネットワークにアクセスした後、TCP/IPプロトコルスタック(TCPプロトコルスタックおよびIPプロトコルスタック)を使用してサーバ20に対するTCP接続を確立し、次いでTCP接続を使用してデータを送信し得る。TCP/IPプロトコルスタックは、TCP/IP参照モデルで定義されているTCP/IPプロトコルスイートのミドルウェアを実装するために使用される。TCPプロトコルスタックは、端末10上のソフトウェア、ハードウェア、および/またはファームウェアの適切な組み合わせによって実行され得る。TCP/IPプロトコルスイートは、2つのコアプロトコル、すなわちTCP(Transmission Control Protocol)およびIP(Internet Protocol)を含む。端末10とサーバ20との間のTCP接続の確立は、端末10上で動作しているアプリケーションプログラムによって開始し得る。図3におけるブラウザ213は、例として使用される。ブラウザ213はソケットオープン(socket open)コマンドを生成し、そのコマンドは端末10のTCPプロトコルスタックに転送され、TCPプロトコルスタックを起動して3方向メッセージ交換(「スリーウェイハンドシェイク」とも呼ばれる)によるサーバ20へのTCP接続を確立する。そして、TCPプロトコルスタックは、接続が確立されたことをブラウザ213に通知する。
次いで、確立されたTCP接続に基づいてTCPパケットがブラウザ213とサーバ20との間で送信され得る。TCPパケットフォーマットを図4に示す。ソースポートおよび宛先ポートは送信側および受信側のアプリケーションプロセスを決定するように構成され、TCP接続はソースポート、宛先ポート、ソースIPアドレス、および宛先IPアドレスを使用して一意に決定され得る。TCPパケットヘッダ内のシーケンス番号(Sequence Number、通常略してseqと称される)フィールドは、パケットロード内の第1のデータバイトのシーケンス番号を搬送する。TCPパケットを受信した後、受信側は肯定応答(Acknowledgement、略してACK)パケットを送信側に送信する。ACKヘッダの確認応答番号(Acknowledge Number、略してackと称される)フィールド値は、受信側が受信したパケットの「シーケンス番号」フィールドの値を表し、受信側が「シーケンス番号」値がACKパケットの「確認応答番号」の値より小さい全てのパケットを受信したことを意味する。ウインドウサイズは、受信側の現在の受信バッファのサイズを示すために使用される。さらに、TCPパケットヘッダには6つのフラグビットと1つのカスタマイズ可能なオプション(Option)フィールドがあり、オプションフィールドは追加情報を伝達するために使用し得る。6つのフラグビットの定義は以下の通りである。
URGは、緊急ポインタが有効であることを示す。
ACKは、確認応答番号が有効であることを示す。
PSHは、処理するためにデータをアプリケーション層に直ちにプッシュすることを示す。
RSTは異常リセットを示す。
SYNは同期フラグであり、SYNが1に設定されると接続が確立される。
FINは、コネクションを解除することを要求するために使用される終了フラグである。
以下、TCP再送信メカニズムと輻輳制御メカニズムについて簡単に説明する。説明を簡単にするために、本発明のいくつかの実施形態においてその間で通信接続が確立されている2つのデバイスのうちの一方を送信側と呼び、他方を受信側と呼ぶ。送信側および受信側はそれぞれ、データ受信および送信能力を有する任意のデバイスであり得ることを理解されよう。例えば、送信側はサーバ20であってもよく、受信側は端末10あってもよい。さらに、送信側および受信側は2つの相対的な役割であり、そして交換可能であり得る、すなわち、異なるシナリオにおいて、同じデバイスが送信側になることも、または受信側になることもあり得る。
TCP再送信メカニズムはパケットの信頼できる送信を保証し、再送信メカニズムは主に、タイムアウト再送信および高速再送信を含む。タイムアウト再送信の基本プロセスは次のとおりである。パケットを送信した後、送信側はタイムアウトタイマーを開始し、タイムアウトタイマーが満了した後もパケットが正しく受信されたことを示す確認応答パケットを送信側が受信しない場合、送信側はパケットを再送信する。タイムアウトタイマーの値は、通常、RTO(Retransmission TimeOut)として表される。RTOは通常、RTT(Round Trip Time)、すなわち、パケットの送信からパケットの受信までに費やされる時間に設定される。RTTは、サンプリングによって得てもよい。
しかしながら、無線通信システムは端末にサービスを提供し、技術の発展と共に、端末は通常、2G、3G、および4Gネットワークなどの複数の種類の通信プロトコルをサポートすることを理解されたい。端末の位置が変わるなどの理由で、ネットワークは通常、不安定になったり、または信号強度が変化する。例えば、エレベータや地下駐車場のように信号が弱い領域、あるいは新幹線や高速鉄道のような高速輸送手段に端末があるようなシナリオでは、ネットワーク信号が不安定なため、端末の接続状態が変化する。例えば、端末は、例えばLTEからWCDMAへのような異なるタイプのセルラネットワークでハンドオーバされてもよく、あるいはある期間内に、端末はネットワークから切断されてネットワークに再接続されてもよいが、この種の変化は、ある期間には頻繁になる。そのようなシナリオでは、端末が送信側として使用されるとき、セルラネットワークに送信されることになっているパケットの送信中に、端末のモデムはパケットを破棄し得る。この場合に生じるパケット損失は、アクティブパケット廃棄とも呼ばれる。したがって、アクティブパケット廃棄は、セルラネットワークを使用する端末で頻繁に発生する。
アクティブパケット廃棄は、パケットが送信のためにネットワークに入力する前に発生する行為であり、データはネットワーク送信プロセスにおいて失われないことが分かるだろう。上記の説明によれば、TCP再送信メカニズムでは、パケット損失の原因は区別されない。通常、再送は、ネットワーク側からのフィードバックを受信した後に実行される必要があり、したがって、モバイル端末は、アクティブなパケット破棄に応答するときに比較的大きな遅延を有する。本発明のこの実施形態では、アプリケーションプロセッサ110内のTCPプロトコルスタックがベースバンドプロセッサ131内の送信対象データのパケット損失を感知することができるように最適化が主に実行され、アクティブなパケット廃棄に対するモバイル端末による応答の遅延を低減する。本発明のこの実施形態における方法は、パケット再送信メカニズムを含む別の信頼できるトランスポートプロトコルにも適用可能であることを理解されるだろう。本発明のこの実施形態では、説明例としてTCPパケットが使用される。
図3はさらに、図1のアプリケーションプロセッサ110およびベースバンドプロセッサ131の関連ソフトウェアアーキテクチャであり、本発明のこの実施形態におけるデータ処理プロセスを実施するために使用される関連ソフトウェアアーキテクチャを説明する。アプリケーションプロセッサ110はプロセッサコアと見なし得る。ベースバンドプロセッサ131(モデムとも呼ばれる)は別のプロセッサコアと見なされる。ソフトウェアアーキテクチャは、2つのコア間のデータ通信用メカニズムをサポートできる。2つのコア間の通信は、特定のコア間通信プロトコルに適合している。コア間通信プロトコルの種類は、本発明のこの実施形態において限定されない。本発明のこの実施形態における端末がデータパケットをネットワーク側デバイスに送信するためのデータのソース側として使用されるプロセスは、図3を参照して以下に簡単に説明される。アプリケーションプロセッサ110では、アプリケーション層のアプリケーション(APP、application)がTCP接続のソース側のソケットインタフェースを使用してデータパケットをTCPプロトコルスタックとカーネル(カーネルモードとも呼ばれる)のIPプロトコルスタックを介して転送した後、アプリケーションプロセッサ110およびモデムのそれぞれのタスク(スレッドとしても理解され得るタスク)であり、コア間通信に使用されるタスクは、データパケットをモデム内の3GPP(3rd Generation Partnership Project、第3世代パートナーシッププロジェクト)プロトコルスタック(タスクまたはスレッドとしても理解され得る)に転送するために使用され、次いで3GPPプロトコルスタックは、通信サブシステム130内のハードウェアを使用して端末からデータパケットを送信する。3GPPプロトコルスタックは、主に様々なセルラネットワークに使用される通信プロトコルである、データリンク層および物理層での1つまたは複数の通信プロトコルを実施するために使用され、3Gネットワークの様々な通信プロトコルに限定されず、例えば、GSM、CDMA、またはLTEであってもよい。これは本発明において限定されない。本発明のこの実施形態では、端末のカーネルの種類は、端末のオペレーティングシステムの種類によって決定され、本発明では限定されない。例えば、カーネルは、Linuxカーネル(Andriodカーネル)またはWindowsカーネルであってもよい。実装において、比較的大きなデータ量のデータ(データパケットなど)をアプリケーションプロセッサ110とモデムとの間で送信するために使用されるコア間通信タスクは、比較的小さいデータ量の情報(ハートビート情報または制御命令など)をアプリケーションプロセッサ110とモデムとの間で送信するために使用されるものとは異なる。さらに、比較的小さいデータ量の情報を送信するために使用されるコア間通信タスクは、次のように実施されてもよい。1つのタスクはアプリケーションプロセッサ110およびベースバンドプロセッサ131のそれぞれで動作し、比較的小さいデータ量の情報は2つのタスク間で送信されてもよく、2つのプロセッサ間の情報伝送は2つのタスク間の通信によって実施されてもよい。
具体的には、モデムでは、3GPPプロトコルスタックおよびアプリケーションプロセッサ110との間でデータパケットを送信するために使用されるタスクは、それぞれのデータパケットキャッシュキューを有しており、タイマは通常、これらのデータパケットキャッシュキューを監視するように構成される。具体的には、3GPPプロトコルスタック内の異なるプロトコルは通常、異なるデータパケットキャッシュキューに対応している。例えば、PDCP(Packet Data Convergence Protocol、パケットデータコンバージェンスプロトコル)キューがLTEプロトコルでは用いられ、PDCPキューまたはRLC(Radio Link Control、無線リンク制御)キューがWCDMAまたはTDSCDMAプロトコルでは用いられる。複数の場合において、データパケットキャッシュキュー内のデータパケットはモデムによって能動的に破棄され、ネットワークデバイスに送信されることができない。以下、いくつかの典型的なパケット破棄シナリオを簡単に列挙する。本発明のこの実施形態におけるパケット破棄シナリオは、以下の例に限定されないことを理解されたい。
例えば、モデム内にあり、プロセッサ110にデータパケットを送信するために使用されるタスクにおいて、アプリケーションプロセッサ110からデータパケットを受信した後、通常、RRC接続が確立されているかどうかが判定される。RRC接続が確立されていた場合、受信データパケットは処理するために3GPPプロトコルスタックに送信される。RRC接続が確立されていなかった場合、データパケットはタスクのキューにキャッシュされ、RRC接続が正常に確立された後に送信される。タスクでは、データパケットがキャッシュキューに保存されなかった場合、またはタスクのキャッシュキューのタイマが満了になり、かつRRC接続が確立されなかった場合、データパケットが破棄される、あるいはタスクでは、タスクのデータパケットキャッシュキューを消去するために使用されるERABM(E−utran Radio Access Bearer Mange、E−UTRAN無線アクセスベアラ管理)メッセージが受信された後で、キャッシュキュー内のデータパケットが能動的に消去される。
3GPPプロトコルスタックは、端末のデータ接続が利用可能であるかどうかを判断するために、端末がデータサービスを処理するためにセルラネットワークを使用することができない原因となるイベントを検出手段によって検出し得る。例えば、端末は切断状態にある、端末はいずれのサービングセルにも普通にキャンプオンすることができない、端末のデータサービスは無効状態にある、または端末は2Gに対するCSFB(Circuit Switched Fallback、回線切り替えフォールバック)の場合には2Gコールシナリオにある。前述のいくつかのシナリオでは、端末のデータ接続は利用不可である。端末のデータ接続を利用できなくするイベントは、本発明のこの実施形態においては限定されない。あるいは、3GPPプロトコルスタックは、端末によって受信されるセルラネットワーク信号の強度や、端末によってアクセスされるセルラネットワークの種類、および端末が音声サービスを実行しているかどうかなど、端末がデータサービスを処理するためにセルラネットワークを使用できるかどうかを表すためにに使用されるいくつかのパラメータを収集し得る。ベースバンドプロセッサは、事前設定されたアルゴリズムによる計算によって、端末の現在のデータ接続が利用可能であるかどうかを判定する。特定のパラメータおよび特定のアルゴリズムは、本発明のこの実施形態においては限定されない。前述の検出または計算は、3GPPプロトコルスタックによって定期的に実行されてもよく、またはいくつかの命令によって起動されてもよく、または前述のイベントによって起動されてもよい。端末のデータ接続が利用可能であるかどうかを3GPPプロトコルスタックがどのように決定するかは、本発明のこの実施形態においては限定されない。端末がセルラネットワークを使用してデータサービスを処理するプロセスでは、RRC(Radio Resource Control、無線リソース制御)リンク確立および切断を伴い、端末と基地局との間のデータサービスインタラクションプロセスでしばしば実行され、端末と基地局との間のデータ接続が利用可能である場合、TCP接続、すなわち、物理層(Physical Layer)とメディアアクセス制御(Medium Access Control)層との間の接続をさらに確立するプロセスである。したがって、本発明のこの実施形態では、端末のデータ接続が利用可能であるという前提で、RRCリンク確立および切断の両方が発生する。データ接続が利用可能であるかどうかを端末が判断することは、RRCリンク確立および切断とは無関係である。
さらに、3GPPプロトコルスタックは、以下の場合に送信対象パケットを能動的に破棄し得る。
端末は、異なる無線セルラネットワーク間でハンドオーバされる。例えば、端末は、LTEネットワークからWCDMAネットワーク、TDSCDMAネットワーク、またはGSMネットワークにハンドオーバされる。これは、実際のシナリオでは不安定な4Gネットワークに起因して端末が4G基地局に接続できない、あるいはVoLTE(Voice over LTE)技術が現在使用されていないシナリオでは音声通信がLTEネットワーク(例えば、CSFBシナリオ)で開始されるために引き起こされる。端末が3Gネットワークまたは2Gネットワークにハンドオーバされるとき、このイベントはL2層(すなわち、MAC層、RLC層、およびPDCP層を含むLTE層2)で解除を引き起こす可能性がある。例えば、PDCPキューが解除され、モデムはPDCPキュー内の送信予定のパケットをクリアする。他の例では、端末は、WCDMAまたはTDSCDMAからLTEにハンドオーバされる。この出来事はまた、L2層で解除を引き起こす可能性がある。
ネットワークパラメータの設定が不適切である。例えば、端末がLTEネットワークを使用している場合、不適切なパラメータはPDCPの再設定を起こす可能性があり、モデムはPDCPキュー内の送信対象パケットをクリアする。端末がWCDMAまたはTDSCDMAネットワークを使用するとき、不適切なパラメータはRLC(無線リンク制御、無線リンク制御)再構成を引き起こす可能性がある。RLC層はMAC(Media Access Control、媒体アクセス制御)層の上方に位置し、MAC層と共にL2層の一部であり、そしてモデムは送信対象パケットをクリアする。
端末がWCDMAまたはTDSCDMAネットワークを使用するとき、RNC(Radio Network Controller、無線ネットワークコントローラ)ハンドオーバはRLC再確立を引き起こす可能性があり、モデムは送信対象パケットをクリアする。
PDCPキューは一杯であり、アプリケーションプロセッサ110によって配信されたパケットはキューに挿入されることができず、モデムにより廃棄される。この場合は、LTEネットワークまたはWCDMAまたはTDSCDMAネットワークで発生する可能性がある。
セルラネットワークでは、複数の無線ベアラ(すなわち、3GPPプロトコルスタック内のデータリンク層によって確立されたリンク)は、アプリケーションの複数のサービスを提供し得る。通常、1つのサービスが1つのベアラを使用する。各ベアラは、1つのPDCPキューにキャッシュされた送信対象パケットに対応する。ベアラ上のサービスがネットワークの問題により異常中断された場合、モデムはそのサービスに対応するPDCPキュー内の送信予定パケットを能動的にクリアする。
理解を容易にするために、図4は、TCPパケットフォーマットの模式図である。
図5を参照して、以下、本発明の実施形態で提供されるパケット送信方法を説明する。本方法は端末に適用され、端末はアプリケーションプロセッサ、ベースバンドプロセッサ、および通信インタフェースを含み、本方法は以下のステップを含む。
S502:ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートし、ここで第1のパケットは、ベースバンドプロセッサによって破棄される送信対象パケットである。
第1のパケットに関する情報は、第1のパケットの識別子と、第1のパケットが属するTCPコネクションの識別子とを含む。
ベースバンドプロセッサによって破棄された送信対象パケットはまた、アプリケーションプロセッサによりベースバンドプロセッサに配信され、ベースバンドプロセッサにより通信インタフェースを使用してネットワークデバイスへの送信ができないパケットとして理解し得ることに留意されたい。
ベースバンドプロセッサは、複数の送信対象パケットを破棄してもよい。前述の説明から、送信対象パケットが多くの場合破棄される可能性があることを知り得る。具体的には、ベースバンドプロセッサは、破棄された送信対象パケットを決定するために、破棄された送信対象パケットに関する情報を記録してもよく、またはベースバンドプロセッサが送信対象パケットを破棄する原因となるイベント、例えば、異なるセルラネットワーク間のハンドオーバを監視してもよい。ベースバンドプロセッサが廃棄される送信対象パケットに関する情報をどのように取得するかは、本発明のこの実施形態においては限定されない。
ベースバンドプロセッサは、破棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートし得る。説明を簡単にするために、第1のパケットがTCPパケットである例として第1のパケットを使用して説明が提供される。第1のパケットに関する情報は、第1のパケットの識別子と、第1のパケットが属するTCP接続の識別子とを含む。実装形態では、第1のパケットの識別子はパケットのシーケンス番号であってもよい。第1のパケットが属するTCP接続の識別子は、TCP接続のソースポート番号であってもよい。TCPパケットフォーマット(図4に示すように)によれば、ベースバンドプロセッサは、送信対象パケットを処理するプロセスにおいて解析することによってシーケンス番号およびソースポート番号を取得し得る。
当業者は、ベースバンドプロセッサがパケットに関する情報でありレポートされる必要がある情報を決定してもよく、特定の実装は本発明のこの実施形態では限定されないことを理解すべきである。具体的な伝送プロトコルはTCPプロトコルに限定されない。
実装では、ベースバンドプロセッサは、破棄された送信対象パケットに関する情報をレポートするための適切な機会を選択し、パケットが破棄された後でアプリケーションプロセッサへのレポートを直ちに実行する代わりに、適切な機会に複数の破棄されたパケットに関する情報をレポートし得る。具体的には、端末のデータ接続が利用可能であるとき、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにレポートする。あるいは、端末のデータ接続が利用不可である場合、ベースバンドプロセッサは第1のパケットに関する情報をキャッシュし、端末のデータ接続が利用不可から利用可能に切り替えられる場合、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにレポートする。前述の2つの方法を一緒に使用できることを理解されたい。
ベースバンドプロセッサのキャッシュキューは、アプリケーションプロセッサにレポートされるべき情報をキャッシュし得るが、その情報は、ベースバンドプロセッサにより破棄された送信対象パケットに関する情報である。
データ接続は、データサービスを実施するために使用される接続である。端末のデータ接続は、端末と基地局との間のデータ接続として理解され得る。詳細については、前述の説明を参照されたし。
端末のデータ接続が利用不可から利用可能に切り替えられると、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにリポートすることに留意されたい。これは、端末のデータ接続が利用不可から利用可能に切り替わった後、ベースバンドプロセッサが第1のパケットに関する情報をアプリケーションプロセッサにリポートすることを示す。命令の読み取り、関連する操作の実行などには時間がかかるので、同時性は厳密には要求されない。すなわち、端末のデータ接続である状態切り替えが利用不可から利用可能に切り替わった後の比較的短い期間(例えば、数ミリ秒または数秒)内に、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにリポートする動作を完了する。
この実装において、ベースバンドプロセッサは、端末のデータ接続が利用可能であるかどうかを決定する必要があることが理解され得る。
端末は、周期的な検出、イベントトリガ、命令トリガなどによって、端末のデータ接続が利用可能か利用不可かを判定し得ることを理解されたい。データ接続が利用可能であるかどうかを決定するために使用されるイベント、その分析で使用される特定の分析プロセスおよびアルゴリズム、ならびに端末のデータ接続が利用可能であるかどうかを判定するためにベースバンドプロセッサを起動する方法は本発明の実施形態では限定される。さらなる説明については、前述の関連説明を参照されたい。
ベースバンドプロセッサはステップS502を実行して、データパケットをベースバンドプロセッサに時間内に再送するようにパケットが廃棄されたことをアプリケーションプロセッサに知らせ、ベースバンドプロセッサは再送されたデータパケットを取得してデータパケットを受信側に送信する。したがって、端末のデータ接続が利用できないときに再送信が実行されると、データ接続が利用できないためにベースバンドプロセッサは再びパケットを能動的に破棄し、アプリケーションプロセッサのこの再送信は無効になる。したがって、データ接続が利用可能である場合にのみベースバンドプロセッサが破棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートすれば、再送有効性を改善することができる。さらに、ステップS502を実行するとき、ベースバンドプロセッサはアプリケーションプロセッサを起動する必要がある。パケットが廃棄された直後にベースバンドプロセッサが情報をレポートする場合、アプリケーションプロセッサは頻繁に起動され、その結果、端末のエネルギー消費は非常に増大する。モバイル端末は通常電池を使用しており、消費電力はできるだけ少なく、待機時間はできるだけ長くすることが必要となる。したがって、廃棄された送信対象パケットに関する情報が、ネットワークが利用可能であるときにだけアプリケーションプロセッサにレポートされる場合、端末のエネルギー消費量が減少されることが可能である。
もちろん、別の実装では、ベースバンドプロセッサは代替として、端末のデータ接続が利用可能であるかどうかを考慮せず、再送信が必要なパケットに関する情報が決定されると、情報をアプリケーションプロセッサにレポートする。これは、本発明のこの実施形態においては限定されない。
S504:アプリケーションプロセッサは、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信し、ここで第2のパケットは第1のパケットと同一である。
実装では、アプリケーションプロセッサは、受信した第1のパケットに関する情報に従って、第1のパケットと第1のパケットが配置されているTCP接続のソースポートとを取得し、アプリケーションプロセッサはソースポートを使用して第1のパケットをベースバンドプロセッサに再送信する。
第2のパケットは、第1のパケットのコピーとして理解し得る。
TCP伝送プロトコルによれば、送信側のTCPプロトコルスタックがパケットを下位層に送信した後、パケットのコピーがTCP接続のキューに保存されることを理解されたい。パケットのコピーは、TCP接続の受信側から返されたACK(Acknowledgement、確認応答文字)が受信され、パケットが受信側で正常に受信されたことを確認するまで削除されない。そうでなければ、パケットのコピーは送信タイムアウトの場合に再送信のために記憶される。したがって、アプリケーションプロセッサは、第1のパケットに関するものであり、ベースバンドプロセッサによってレポートされた情報に従って、第2のパケットをベースバンドプロセッサに再送信し得る。
S506:ベースバンドプロセッサは、通信インタフェースを使用して第2のパケットをネットワークデバイスに送信する。
ネットワークデバイスは、セルラネットワーク内の基地局またはサーバなどのネットワークデバイスとし得る。これは、本発明のこの実施形態において限定されない。
結論として、送信対象パケットを破棄した後、ベースバンドプロセッサは、アプリケーションプロセッサにベースバンドプロセッサによって破棄された送信対象パケットに関する情報をレポートし得る。その結果、アプリケーションプロセッサは、レポートされた情報に従ってベースバンドプロセッサに、ベースバンドプロセッサによって破棄されたパケットのコピーを再配信することができる。パケットのタイムアウトタイマーが満了し、いかなる確認応答パケットもピアエンドから受信されないことが判定される前に、パケットが廃棄され、パケットがベースバンドプロセッサに再送信されることが決定可能である。これにより、ベースバンドプロセッサによって廃棄された送信対象パケットを端末が再送信する際の遅延を減少することができ、端末によるパケット損失に応答する遅延をある程度改善することができ、その結果、端末とネットワークとの間のデータ伝送はより滑らかになる。無線セルラネットワークの状態はしばしば変化するので、ベースバンドプロセッサが送信対象パケットを廃棄する場合が頻繁に発生する。
さらに、上述のように、実装において、電力消費を考慮して、端末によってアクセスされるセルラネットワークの状態が利用可能になるまで、ベースバンドプロセッサは破棄された送信対象パケットに関する情報をレポートしない。この場合、破棄された送信対象パケットに関する情報は、レポートされる前に特定時間待機する必要がある。これにより、以下の2つのケースが発生し得る。1つのケースでは、パケットに関する情報がベースバンドプロセッサによってレポートされる前に、廃棄された送信対象パケットのタイムアウトタイマが満了する。この場合、破棄されたパケットと同じパケットは、TCP接続とタイムアウト再送信メカニズムを使用して再送信された可能性がある。ベースバンドプロセッサは、もはや廃棄されたパケットに関する情報をアプリケーションプロセッサにレポートする必要がない。ベースバンドプロセッサは、廃棄されたパケットと同じ受信されたパケットに従って、廃棄されたパケットに関する情報をフィルタ除去し得る。それによって電力消費の浪費および端末トラフィックの浪費を回避することができる。他のケースでは、アプリケーションプロセッサが破棄されたパケットと同じパケットを配信するとき、破棄されたパケットのタイムアウトタイマーは満了する。この場合もタイムアウト再送要件を同等に満たしているため、TCP接続の輻輳制御方式が起動され得る。
TCP再送信メカニズムは信頼できるパケット送信を保証することができるが、従来技術の再送信メカニズムでは、ネットワーク輻輳が原因でパケット損失が引き起こされることがデフォルトで考慮されることに留意されたい。通常、ネットワーク伝送中のパケット損失の最も一般的な原因は、ネットワーク負荷が高すぎることである。ネットワークデバイスは、現時点でネットワークにおいて送信される必要があるデータ量の負担を担うことができず、ネットワークの輻輳が引き起こされ、したがってネットワーク内で送信されるいくつかのパケットは破棄される。したがって、輻輳制御方法を再送信メカニズムと共に使用してネットワーク内の輻輳を低減し、再送信されたパケットによってピアエンドに到達する成功率を向上させる。輻輳制御アルゴリズムは主に、スロースタート(Slow Start)、輻輳回避(Congestion Avoidance)などを含む。簡単に言えば、パケットが損失し、再送信する必要があることが分かると、アプリケーションプロセッサは、輻輳ウインドウ(cwnd, congestion window)の値やスロースタート閾値(ssthresh、slow start threshold)などの、端末によってネットワークに送信されるパケットの量を制限するためのいくつかのパラメータの値を減少する。アプリケーションプロセッサは通常、調整されたパラメータを使用して、再送信されたパケットをベースバンドプロセッサに配信する速度と、後続の送信対象パケットをベースバンドプロセッサに配信する速度とを制御する。
例えば、パケット損失がタイムアウト再送信を引き起こす場合、送信側はスロースタート閾値をCWND/2に減少し、次いでCWNDを1に設定し、そしてスロースタートプロセスに再び入り得る。別の例では、送信側がACKに従って、パケットが損失されたと判断して高速再送信を開始する場合、送信側は輻輳ウインドウを半分に減少し、スロースタート閾値を更新された輻輳ウインドウサイズに設定してもよい。異なるアルゴリズムでは、輻輳ウインドウおよびスロースタート閾値を減少させる振幅および方法は異なるが、ほとんどの場合、パケット廃棄バックオフ規則が基礎として使用される、すなわち、送信側がネットワーク内でパケットが損失していると判断する場合、輻輳ウインドウサイズとスロースタート閾値が能動的に減少される。
しかしながら、本発明のこの実施形態における能動的なパケット廃棄はネットワーク輻輳によって引き起こされないので、端末によって無線ネットワークに送信されるパケットの量を減少する必要はなく、またパケットはベースバンドプロセッサによって能動的に廃棄されるため、できるだけ早くピアエンドにパケットを送信するために、特定量の送信パケットを確保する必要がある。しかしながら、本発明のこの実施形態における方法は通常、既存のTCPメカニズムで使用され、CWNDが減少されるという前述の問題は避けられない。
したがって、本発明のこの実施形態の実装では、アプリケーションプロセッサが第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信した後、アプリケーションプロセッサは補償として輻輳ウインドウを増加させる。
例えば、CWNDは、輻輳ウインドウの指定された初期値まで増加、または輻輳ウインドウの減少が再送信によって引き起こされる前に使用される、輻輳ウインドウの値に戻し得る。本発明のこの実施形態では、アプリケーションプロセッサが輻輳ウインドウを増加させる値、およびアプリケーションプロセッサが輻輳ウインドウを増加させるために使用するポリシーなどは限定されない。これにより、タイムアウト再送信による影響を排除でき、端末により送信されるパケット量を確保することができ、また端末の送信スループットを向上させることができる。
別の実施形態では、アプリケーションプロセッサとベースバンドプロセッサ(モデムとも呼ばれる)とを同一チップの同一コアに統合することさえ可能であり、上述の方法はそのようなチップにも適用可能である。説明を容易にするために、この実装では、チップは集合的にプロセッサと呼ばれ、TCPプロトコルスタックおよび3GPPプロトコルスタックは、プロセッサ上で動作する2つのタスク(またはスレッド)として理解されることもあり、この2つのタスクは異なるプロセスまたは同一のプロセスに属してもよく、TCPプロトコルスタックと3GPPプロトコルスタックは、スレッド間またはプロセス間の通信メカニズムを使用して情報を交換する。アプリケーションプログラムはさらに、アプリケーションプロセッサ上で動作する。アプリケーションプログラムはさらに、TCPプロトコルスタックおよび3GPPプロトコルスタックを使用してパケット、例えば、アプリケーションプログラムによって生成されたデータまたはアプリケーションプログラムからの要求であり、ユーザ操作によって起動される要求を基地局に送信する。3GPPプロトコルスタックは、アプリケーションプログラムの破棄されたパケットに関する、パケットの識別子およびパケットが位置するTCP接続の識別子などの情報をスレッド間またはプロセス間の通信メカニズムを使用してTCPプロトコルスタックに転送し、その結果、TCPプロトコルスタックは、破棄されたパケットに関する受信した情報に従って、破棄されたパケットと同じパケットを3GPPプロトコルスタックに転送する。プロセッサは、3GPPプロトコルスタックによって受信され、廃棄されたパケットと同じパケットを通信インタフェースを使用して基地局に送信する。この実装における他の詳細については、本発明の上述の実施形態を参照されたい。詳細は本明細書では再度説明されない。このようにして、ベースバンドプロセッサによって破棄されたパケットの端末による再送信の際の遅延を減少させることができ、端末とネットワークデバイスとの間の遅延をある程度減少させ、端末とネットワークとの間のデータ伝送がより円滑になる。
実施形態において、ベースバンドプロセッサが送信対象パケットを破棄した後に、アプリケーションプロセッサがベースバンドプロセッサとどのように協働して再送信を完了させるかについて、図3のソフトウェアアーキテクチャを参照しながらAndroidシステムを備える端末を例として使用して以下に説明する。アプリケーションプロセッサとベースバンドプロセッサは、2つのコアまたは2つの独立したチップである。本実施形態において、上述した内容については、前述の説明を参照されたい。詳細は本明細書では再度説明しない。
この実装では、ベースバンドプロセッサは、3GPPプロトコルスタックと、アプリケーションプロセッサとの間でデータパケットを送信するために使用されるタスク(略してコア間データ送信タスクと称す)とを含み、さらに比較的少量のデータを送信するためのコア間通信タスクを含む。アプリケーションプロセッサは、ベースバンドプロセッサ内のコア間通信タスクに対応する別のコア間通信タスクと、TCPプロトコルスタックと、IPプロトコルスタックと、アプリケーションプロセッサのアプリケーション層で動作するアプリケーションとを含む。
ベースバンドプロセッサ内の3GPPプロトコルスタックは、ベースバンドプロセッサによって破棄された送信対象パケットと、端末によって現在アクセスされているセルラネットワークの状態とを監視する。具体的には、3GPPプロトコルスタックは、廃棄された送信対象パケットを決定するために、ベースバンドプロセッサが送信対象パケットを破棄する原因となるイベント、例えば、異なるセルラネットワーク間のハンドオーバを監視し得る。
3GPPプロトコルスタックは、ベースバンドプロセッサによって廃棄された送信対象パケットに関する情報(廃棄されたパケットのシーケンス番号および廃棄されたパケットが位置するTCP接続のソースポート番号を含む)を生成しその情報をキューに格納し、端末のデータ接続が利用可能であるかどうかを示す情報(接続が利用可能であるかどうかを示すために使用されるいくつかのパラメータ、または異なる値が利用可能または利用不可を示す、特設的にはブール値であり得る情報)を生成し、上記2種類の情報をベースバンドプロセッサ内のコア間通信タスクに転送する、例えば、共有メモリを用いてその情報を転送する。
また、ベースバンドプロセッサ内にあり、かつアプリケーションプロセッサとの間でデータパケットを送信するために使用されるタスクにおいても、タスク内で破棄されたパケットが検出される。3GPPプロトコルスタックと同様に、タスクは、ベースバンドプロセッサにより破棄された送信対象パケットに関する生成された情報(破棄されたパケットのシーケンス番号および破棄されたパケットが配置されているTCP接続のソースポート番号を含む)をベースバンドプロセッサ内のコア間通信タスクに転送する、例えば、共有メモリを用いてその情報を転送する。
コア間通信タスクは、廃棄されたパケットに関する取得した情報をタスクのキューを用いて管理する。キューが一杯になると、キューは破棄されたパケットに関する情報であり、キューが一杯になった後に得られる情報を破棄し、コア間通信タスクは3GPPプロトコルスタックによって提供される端末のデータ接続に関する情報に従って端末のデータ接続が利用可能か利用不可かを判断する。
端末のデータ接続が利用可能の場合、コア間通信タスクはキュー内の破棄されたパケットに関する情報をアプリケーションプロセッサ内のコア間通信タスクに送信し、それによりアプリケーションプロセッサは破棄されたパケットに関する情報を学習する。
端末のデータ接続が利用不可の場合、コア間通信タスクのキューのタイマが開始され、タイマが満了するとき、再び3GPPプロトコルスタックによって提供される情報に従ってタイマにより計時された時間の後で端末のデータ接続が利用可能かどうかが判定される。データ接続が利用可能である場合、コア間通信タスクは、キュー内の破棄されたパケットに関する情報をアプリケーションプロセッサ内のコア間通信タスクに送信し、タイマがリセットされる。データ接続がまだ利用できない場合、タイマがリセットされ、タイマが次に満了になるときに判定が実行される。
アプリケーションプロセッサは、破棄された送信対象パケットに関するものであり、ベースバンドプロセッサによって送信された情報を解析して、破棄されたパケットのシーケンス番号および破棄されたパケットが位置するTCP接続のソースポート番号を取得する。
アプリケーションプロセッサは、ソースポート番号を使用してLinuxネットワークプロトコルスタック内の対応するTCP接続を見つけ、廃棄された送信対象パケットのシーケンス番号と、TCP接続の送信キュー内のパケットのシーケンス番号とを比較して破棄された送信対象パケットのコピーを見つけ、TCP/IPプロトコルスタックを使用して、破棄された送信対象パケットのコピーをベースバンドプロセッサに送信する。
また、廃棄された送信対象パケットのコピーをアプリケーションプロセッサによって送信するプロセスにおいて、例えば、送信対象パケットのコピーが再送された後で、TCP輻輳制御が起動された場合、端末のCWNDは1に減少し、アプリケーションプロセッサは現在のCWND値を端末の初期CWND値(TCP_INIT_CWND)とCWNDが1に減少する前に使用されていた値のうち小さい方の値に設定する。このようにして、タイムアウト再送による影響を排除しかつ端末のスループットを向上させるために輻輳ウインドウの不必要な減少が回避されることが可能であり、この結果、時間的により多くのパケットが送信されることができ、それによりパケット損失に対する再送に起因する遅延を低減する。
ベースバンドプロセッサは、送信対象パケットのコピーであって、アプリケーションプロセッサによって送信されるコピーを受信し、アンテナなどの無線周波数回路を使用してそのコピーを送信ネットワークデバイスに送信する。
このようにして、送信対象パケットを破棄した後、ベースバンドプロセッサは、ベースバンドプロセッサによって破棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートすることが可能であり、それにより、アプリケーションプロセッサは、レポートされた情報に従ってベースバンドプロセッサに、ベースバンドプロセッサにより破棄されたパケットを再配信できる。パケットのタイムアウトタイマーが満了し、いかなる確認応答パケットもピアエンドから受信されないことが判断される前に、パケットが廃棄され、パケットがベースバンドプロセッサに再送信されることが決定されることが可能である。これにより、ベースバンドプロセッサにより破棄されたパケットを端末により再送信する際の遅延を減少することができ、端末の再送遅延をある程度改善することができるので、端末とネットワークとの間のデータ伝送はより円滑になる。無線セルラネットワークの状態はしばしば変化するので、ベースバンドプロセッサが送信対象パケットを廃棄するケースが頻繁に発生する。
以下、テスト結果を用いて、上記実施の形態における方法の効果について説明する。上記実施形態の方法を用いることで端末の再送メカニズムが改善され、再送遅延を比較的大幅に減少することができ、アップリンク送信のデータスループットが向上される。弱電界シナリオとセルラネットワークの高速移動シナリオを実証するために、広州から深センまでの高速鉄道でチャイナユニコムの無線セルラネットワークの使用が選択されてテストを実行した。
伝送遅延については、テストツールiPerfが使用され、サンプリング方法は、アプリケーションプロセッサを用いてデータパケットを伝送するタスクにおいて引き起こされる3GPPプロトコルスタックにおけるパケット損失について能動的にレポートされたパケット伝送遅延を計算することである。ソースエンドは、ピアエンドがサーバである携帯電話である。最適化前は、平均伝送遅延は約75秒である。最適化後は、平均伝送遅延は約45秒である。廃棄されたパケットに対する平均再送遅延は、40%最適化されている。
アップリンク伝送スループット(アップリンク伝送方向は携帯電話端末からサーバ方向)は、テストツールiPerfを用いる。サンプリング方法は、各iPerfテスト中にカウントされた平均スループット(1ラウンドあたり100秒または200秒であり、サーバ側でカウントされる)を計算することである。最適化前は、平均スループットは約1.5Mbpsである。最適化後は、平均スループットは約3.3Mbpsである。平均スループットは、約2.2倍に向上される。
本発明の実施形態はさらにパケット送信装置600を提供し、パケット送信装置600の概略構造図は図9である。本装置は、ベースバンドプロセッサ、アプリケーションプロセッサ、および送信器を含む。ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。第1パケットは、ベースバンドプロセッサによって破棄される送信対象パケットであり、第1パケットに関する情報は、第1パケットの識別子と、第1パケットが属するTCPコネクションの識別子とを含む。アプリケーションプロセッサは、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同じである。ベースバンドプロセッサはさらに、送信器を使用して第2のパケットをネットワークデバイスに送信するように構成される。
実装において、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、装置のデータ接続が利用可能であるときに、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
本実施形態の上述の様々な実装を参照すると、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、装置のデータ接続が利用できないとき、第1のパケットの情報をキャッシュし、装置のデータ接続が利用不可から利用可能に切り替えられたとき、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
この実施形態の上述の様々な実装を参照すると、アプリケーションプロセッサはさらに、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信した後に輻輳ウインドウを増大するように構成される。
本実施形態の上述の様々な実装を参照すると、第1のパケットの識別子は第1のパケットのシーケンス番号であり、第1のパケットが属するTCP接続の識別子は、第1のパケットが配置されているTCP接続のソースポート番号であり、第1のパケットに関する情報に従って第2のパケット番号をベースバンドプロセッサに送信することに関して、アプリケーションプロセッサは、ソースポート番号に従って第1のパケットと同じシーケンス番号を有する第2のパケットをベースバンドプロセッサに送信するように構成される。
この実施形態における名詞およびステップの具体的な説明および関連する有益な効果については、上述の説明を参照し、詳細は本明細書では再度説明されないことに留意されたい。
上述の方法の実施形態で説明した装置は、セルラネットワークによって提供されるデータサービスを使用してデータサービスを送信または実行する任意のデバイスによって実装され得ることは理解されよう。本発明はさらに、上述の方法の実施形態における方法を実施するための端末を提供する。端末の概略構成図を図7に示す。端末300は、処理回路302と、処理回路302に接続された通信インタフェース304および記憶媒体320とを含む。図6の実施形態の送信器は、通信インタフェース304内の送信器回路に相当する。
処理回路302は、データを処理し、データアクセスおよびストレージを制御し、コマンドを送信し、他の装置を制御して動作を実行するように構成される。処理回路302は、1つまたは複数のプロセッサ、1つまたは複数のコントローラ、および/またはプログラムを実行するために使用され得る別の構造として実装され得る。処理回路302は、特に、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他のプログラマブルロジックコンポーネントのうちの少なくとも1つを含み得る。汎用プロセッサは、マイクロプロセッサ、および任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械を含み得る。処理回路302は、代替的に、DSPとマイクロプロセッサとの組み合わせなどのコンピューティングコンポーネントとして実装されてもよい。
本発明のこの実施形態では、処理回路はアプリケーションプロセッサ309とベースバンドプロセッサ310とを含む。
記憶媒体306は、(ハードディスク、フロッピー(登録商標)ディスク、または磁気ストライプなどの)磁気記憶装置などのコンピュータ可読記憶媒体、(デジタル多用途ディスク(DVD)などの)光学記憶媒体、スマートカード、フラッシュメモリデバイス、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、プログラマブルROM(PROM)、消去可能PROM(EPROM)、レジスタ、またはそれらの任意の組み合わせを含み得る。記憶媒体306は、処理回路302が情報を読み取り、その情報を記憶媒体306に書き込むことが可能なように処理回路302に結合され得る。具体的には、記憶媒体306は、処理回路302に統合されてもよく、または媒体306と処理回路302は分離されてもよい。
通信インタフェース304は、ユーザ機器300と1つまたは複数の無線ネットワークデバイス(例えば、基地局またはサーバ)との間の双方向通信を実施するための回路および/またはプログラムを含み得る。通信インタフェース304は、1つまたは複数のアンテナ(図7には図示せず)に結合されてもよく、少なくとも1つの受信器回路316および/または少なくとも1つの送信器回路318を含む。
実施形態において、記憶媒体306はプロトコルスタックプログラム320を記憶し、処理回路302はプロトコルスタックプログラム320を実行してプロトコルスタックの機能を実現する。プロトコルスタックと各アプリケーションプロセッサ309およびベースバンドプロセッサ310との関係については、図3の関連説明を参照されたい。
プロトコルスタックは、アプリケーションプログラムのデータをTCP/IPプロトコル仕様に従って特定のデータフォーマットの複数のパケットにカプセル化し、送信器回路318を使用して複数のパケットをアプリケーションサーバに送信するために使用される。また、プロトコルスタックはさらに、受信器回路316が受信したパケットをデカプセル化して、最終的にアプリケーションプログラムのデータを取得する。プロトコルスタックによるパケットのカプセル化およびデカプセル化のプロセスを図8Aおよび図8Bに示す。パケットカプセル化プロセスは、本質的にプロトコルスタックがパケットにヘッダおよび/またはフレームトレーラを追加するプロセスであり、パケットデカプセル化プロセスは、本質的にパケットからヘッダおよび/またはフレームトレーラを削除するプロセスであることがわかる。通信インタフェース304により受信されたデータを復号および/またはデカプセル化した後で、プロトコルスタックは、データを上位層のアプリケーションプログラムに転送するか、またはアプリケーションプログラムのデータをカプセル化して通信インタフェースを使用することにより別のデバイスに送信し得る。
実施形態では、プロトコルスタックは、層のプロトコルを実装するために、物理層、データリンク層、ネットワーク層、トランスポート層、およびアプリケーション層を含み得る。例えば、物理層は、物理デバイスインタフェース機能、伝送媒体タイプ、伝送速度、伝送モードなどを定義し、物理層で信号処理を実施するために使用される。同様に、データリンク層は、データリンク層の機能を実行するために使用され、例えば、ネットワーク層で生成されたシグナリングを分配し、物理層によって生成された情報を処理することを担当する。データリンク層は、それぞれMAC層、RLC層、およびLLC層の機能を実装するように構成されているメディアアクセス制御(Media Access Control、MAC)層モジュール、無線リンク制御(RLC)層モジュール、および論理リンク制御(LLC)層モジュールなどの1つまたは複数のサブモジュールを含み得る。例えば、MAC層モジュールは、物理層によって提供されるサービスを使用して上位層プロトコルデータを送信し、上位層とエアインタフェースとの間のデータアクセスを管理するように構成される。RLC層モジュールは、データの分割と再構成に使用される。LLC層モジュールは、フロー制御、シーケンス制御、およびエラー制御機能を提供するように構成されている。さらに、ネットワーク層は、論理アドレス指定およびルーティング選択などの機能を実装するように構成されている。トランスポート層は、ポートアドレス指定、セグメント化および再構成、接続制御、フロー制御、およびエラー制御などの機能を実施するように構成されている。アプリケーション層は、上位層においてアプリケーションプログラム用のインタフェースを提供するように構成されている。
本発明のこの実施形態の1つまたは複数の態様によれば、処理回路302は、プロトコルスタックの機能を実装するように、記憶媒体306に格納されたプロトコルスタックプログラム320を実行するように適合されている。アプリケーションプロセッサ309内のプロトコルスタックおよびベースバンドプロセッサ310内のプロトコルスタックは、前述の方法の実施形態におけるステップの一部またはすべてを実施する。
本発明の実施形態はさらにチップを提供する。チップは無線周波数コンポーネントを使用してネットワークデバイスへのデータ接続を確立し、チップはアプリケーションプロセッサとベースバンドプロセッサとを含む。ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。第1パケットは、ベースバンドプロセッサによって破棄される送信対象パケットであり、第1パケットに関する情報は、第1パケットの識別子と、第1パケットが属するTCP接続の識別子とを含む。アプリケーションプロセッサは、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同じである。ベースバンドプロセッサは、無線周波数コンポーネントを使用して第2のパケットをネットワークデバイスに送信するようにさらに構成される。
すなわち、本発明のこの実施形態で説明するチップは、実際には、図7に示す端末に配置されて使用される処理回路302である。
実装において、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、チップのデータ接続が利用可能であるときに、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
本発明のこの実施形態の前述の実装を参照すると、別の実装では、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、チップのデータ接続が利用できない場合、第1のパケットに関する情報をキャッシュし、チップのデータ接続が利用不可から利用可能に切り替わったときに、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
本発明のこの実施形態の前述の実装を参照すると、別の実装では、アプリケーションプロセッサはさらに、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信した後に輻輳ウインドウを増大するよう構成される。
本発明のこの実施形態の前述の実装を参照すると、別の実装では、第1のパケットの識別子は第1のパケットのシーケンス番号であり、第1のパケットが属するTCP接続の識別子は、第1のパケットが配置されているTCP接続のソースポート番号であり、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信することに関して、アプリケーションプロセッサは第1のパケットと同じシーケンス番号を有する第2のパケットをソースポート番号に従ってベースバンドプロセッサに送信するように構成される。
本実施形態で説明するチップの詳細については、図8Aと図8Bに示した端末および上述のチップに実装されることができる方法の実施形態の説明を参照し、詳細については、本明細書では再び説明しない。
本発明の実施形態はさらに、記憶媒体を提供し、この媒体は、本発明で説明されたパケット送信方法を実施するためのコードを記憶するように構成される。
本発明の実施形態で提供されるパケット送信方法および装置は、上記で詳細に説明されている。本明細書では、本発明の原理および実装を説明するために具体的な例が適用され、前述の実施形態の説明は、本発明の方法および核となる概念を理解する手助けとすることだけを意図している。さらに、当業者であれば、本発明の思想に従って具体的な実装および適用範囲を変更することができる。結論として、本明細書の内容は本発明に対する限定として解釈されるべきではない。
本発明は、通信分野に関し、特に、パケット送信方法および装置、チップ、ならびに端末に関する。
モバイルインターネットアクセスが端末の主な特徴となるにつれて、ネットワークにアクセスするために端末によって使用される技術的解決策が発達し続けている。これにより、端末製品の情報取得率が大幅に向上する。モバイル通信分野で一般的に使用されている伝送制御プロトコル/インターネットプロトコル(TCP/IP)は、コネクション対応型であり、信頼性があり、かつバイトストリームベースのトランスポート層通信プロトコルである。
端末がTCP/IPプロトコルを用いてネットワークにアクセスする処理において、パケットは破棄されることが多い(これはパケットロスとも呼ばれる)。現在の処理方法は、通常、送信側がデータを再送信することである。現在の処理方法では、パケットが失われたかどうかは、受信側からのフィードバックによって判断される。例えば、送信側が、指定された時間内に、受信側によって送信されたACKなどのフィードバックメッセージを受信しなかった場合、パケットが失われたと判断され、失われたパケットのデータを含むパケットが再送される。この解決法では、パケット損失に応答するときに端末では比較的大きな遅延があり、端末とネットワークデバイスとの間のデータ伝送の停止時間は比較的長く、リアルタイムの通信品質は比較的深刻な影響を受ける。
これを考慮し、本出願は、ベースバンドプロセッサによって破棄された送信対象パケットを端末により再送する際の遅延を減少し、また端末によるパケット損失に対する応答の際の遅延をある程度減少し、端末とネットワークとの間のデータ伝送がより円滑になるようなパケット送信方法および装置、チップ、ならびに端末を提供する。
第1の態様によれば、本発明の実施形態は、端末に適用されるパケット送信方法であって、端末はベースバンドプロセッサと、アプリケーションプロセッサと、通信インタフェースとを備え、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップであり、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、第1のパケットに関する情報は第1のパケットの識別子および第1のパケットが送信されるのに使用されたTCP接続の識別子を含む、ステップと、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップであり、第2のパケットは第1のパケットと同一である、ステップと、ベースバンドプロセッサにより、通信インタフェースを使用して第2のパケットをネットワークデバイスに送信するステップとを含む、パケット送信方法を提供する。
なお、ベースバンドプロセッサによって破棄された送信対象パケットは、アプリケーションプロセッサによってベースバンドプロセッサに配信され、かつベースバンドプロセッサによる通信インタフェースを使用したネットワークデバイスへの送信が失敗するパケットとして理解され得る。
ネットワークデバイスは、基地局またはサーバなどのデバイスとし得ることに留意されたい。
第2のパケットは、第1のパケットのコピーとして理解されてもよい。
このようにして、送信対象パケットを破棄した後、ベースバンドプロセッサは、アプリケーションプロセッサに、ベースバンドプロセッサによって破棄された送信対象パケットに関する情報をレポートし得るため、アプリケーションプロセッサは、レポートされた情報に従って、ベースバンドプロセッサによって破棄されたパケットのコピーをベースバンドプロセッサに再配信する。パケットのタイムアウトタイマーが満了し、確認応答パケットがピアエンドから受信されないと判定される前に、パケットが廃棄され、パケットがベースバンドプロセッサに再送信されることを決定することができる。これにより、ベースバンドプロセッサによって廃棄された送信対象パケットを端末により再送信する際の遅延を減少することができ、端末によるパケット損失に応答する際の遅延をある程度減少することができるため、端末とネットワークとの間のデータ送信はより滑らかになる。無線セルラネットワークの状態はしばしば変化するので、ベースバンドプロセッサが送信対象パケットを廃棄する事例が頻繁に発生する。
第1の態様を参照すると、第1の態様の第1の実装において、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップは、端末のデータ接続が利用可能な場合、ベースバンドプロセッサにより、第1のパケットに関する情報をアプリケーションプロセッサにレポートするステップを含む。
データ接続は、データサービスを実行するために使用される接続である。端末のデータ接続は、端末と基地局との間のデータ接続として理解され得る。
第1の態様または第1の態様の第1の実装を参照すると、別の実装において、
端末のデータ接続が利用不可である場合、ベースバンドプロセッサは、第1のパケットに関する情報をキャッシングし、端末のデータ接続が利用不可から利用可能に切り替えられた場合、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートする。
端末は、定期的な検出、イベントトリガ、命令トリガなどによって、端末のデータ接続が利用可能か利用不可かを判定し得ると理解されたい。以下のいずれかの場合、すなわち、端末が切断状態にある、端末がいずれのサービングセルにも正常にキャンプオンし損なう、端末のデータサービスが無効状態にある、または回線交換ドメインが2Gへフォールバックしている(回線交換フォールバック、CSFB)時に端末が2Gコールシナリオにある場合、端末のデータ接続は利用できない。
端末のデータ接続が利用不可から利用可能に切り替えられると、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに留意されたい。これは、端末のデータ接続が利用不可から利用可能に切り替わった後、ベースバンドプロセッサが第1のパケットに関する情報をアプリケーションプロセッサにレポートすることを示す。命令の読み出し、関連操作の実行などには時間がかかるため、同時性は厳密には要求されない。すなわち、端末のデータ接続が利用不可から利用可能に切り替わった後の比較的短い時間(例えば、数ミリ秒または数秒)内に、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサへレポートする動作を完了する。
第1の態様および第2の態様において、ベースバンドプロセッサは、データ接続が利用可能な場合にのみ、廃棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートするので、再送信の有効性を改善することができる。破棄された送信対象パケットに関する情報が、データ接続が利用可能であるときにのみアプリケーションプロセッサにレポートされる場合、端末のエネルギー消費量は減少されることが可能である。
上記の実装のいずれか1つによれば、別の実装において、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップの後で、本方法はさらに、アプリケーションプロセッサにより、TCP接続の輻輳ウインドウの値を増大するステップを含む。
アプリケーションプロセッサが第2のパケットをベースバンドプロセッサに送信した後、輻輳ウインドウは縮小され得る。輻輳ウインドウが増大された後、タイムアウト再送による影響が排除されることができ、端末により送信されるパケット量が確保されることができ、また端末の送信スループットを向上させることができる。
上記の実装のいずれか1つによれば、別の実装において、第1のパケットの識別子は、第1のパケットのシーケンス番号であり、第1のパケットが送信されるのに使用されたTCP接続の識別子は、TCP接続のソースポート番号であり、アプリケーションプロセッサにより、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するステップは、アプリケーションプロセッサにより、第1のパケットと同じシーケンス番号を有する第2のパケットをソースポート番号に応じてベースバンドプロセッサに送信するステップを含む。
第2の態様によれば、本発明の実施形態は、パケット送信装置を提供し、パケット送信装置は、ベースバンドプロセッサと、アプリケーションプロセッサと、送信器とを備える。ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成され、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、第1のパケットに関する情報は第1のパケットの識別子および第1のパケットが送信されるのに使用されたTCP接続の識別子を含み、アプリケーションプロセッサは、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同一であり、ベースバンドプロセッサはさらに、送信器を使用して第2のパケットをネットワークデバイスに送信するように構成される。
第2の態様は第1の態様に対応する装置であるため、様々な実装、説明、および技術的効果については、第1の態様の説明を参照されたい。
第3の態様によれば、チップが提供される。チップは、無線周波数コンポーネントを使用してネットワークデバイスに対するデータ接続を確立し、チップは、アプリケーションプロセッサおよびベースバンドプロセッサを備え、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成され、第1のパケットはベースバンドプロセッサによって破棄された送信対象パケットであり、第1のパケットに関する情報は第1のパケットの識別子および第1のパケットが送信されるのに使用されたTCP接続の識別子を含み、アプリケーションプロセッサは、第2のパケットを第1のパケットに関する情報に応じてベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同一であり、ベースバンドプロセッサはさらに、無線周波数コンポーネントを使用して第2のパケットをネットワークデバイスに送信するように構成される。
第3の態様は、第2の態様の具体的な製品形態である。第3の態様の様々な実装、説明、および技術的効果については、第2の態様を参照し、詳細は本明細書では再度説明されない。
第4の態様によれば、端末が提供される。端末は、アプリケーションプロセッサと、ベースバンドプロセッサと、メモリと、通信インタフェースとを備える。アプリケーションプロセッサ、ベースバンドプロセッサ、および通信インタフェースはメモリに接続され、アプリケーションプロセッサ、ベースバンドプロセッサ、および通信インタフェースは、メモリに格納された命令を呼び出すことによって、第1の態様の上記実装のいずれか一つの方法を実行する。
第5の態様によれば、格納媒体が提供され、第1の態様の上記実装による方法のいずれか1つを実現し得るコードを格納するように構成される。
第4の態様および第5の態様の様々な実装、説明、および技術的効果については、第1の態様を参照し、詳細は本明細書では再度説明されない。
出願の技術的解決策をより明確に説明するために、以下、実施形態を説明するために必要な添付図面を簡単に説明する。明らかに、以下の説明における添付図面は、単に本出願のいくつかの実施形態を示しており、当業者は創造的な努力なしにこれらの添付図面から他の図面をなお導出し得る。
図1は、本発明の実施形態によるシステムのネットワークの模式図である。 図2は、本発明の実施形態による端末のハードウェア構成の模式図である。 図3は、本発明の実施形態による端末のソフトウェアアーキテクチャの模式図である。 図4は、本発明の実施形態によるTCPパケットフォーマットの模式図である。 図5は、本発明の実施形態によるパケット送信方法の模式図である。 図6は、本発明の実施形態によるパケット送信装置の模式図である。 図7は、本発明の実施形態による端末の模式図である。 図8Aは、本発明の実施形態による送信側と受信側との間のパケット送信中のカプセル化処理の模式図である。 図8Bは、本発明の実施形態による送信側と受信側との間のパケット送信中のカプセル化処理の模式図である。
出願は、パケット送信方法および装置、チップ、および端末を提供する。以下、本出願における技術的解決策を本出願における添付図面を参照して明確に説明する。明らかに、説明される実施形態は、単に本出願のいくつかではあるがすべてではない。創造的な努力をせずに本出願に基づいて当業者によって得られる他のすべての実施形態は、本発明の保護範囲に包含されるべきものである。
以下は、本出願における技術用語の一部である。
輻輳ウインドウは、輻輳制御の場合に、TCPデータ送信中に1つのRTT期間内にデータのソース側によって送信されことができるデータパケットの最大量である。輻輳ウインドウのバックオフとは、ネットワークが輻輳しているときにデータの送信側が輻輳ウインドウを減少することを意味する。
モバイル通信サービスは、データサービス(Data Service)と音声サービスとに分類される。データサービスは、モバイル通信CS(Circuit Switched、回線交換)方式ドメイン音声サービス以外の他のサービスを含む。データ接続は、端末と基地局との間のデータ接続として理解されてもよく、端末と基地局との間の接続であり、データサービスを処理するために使用される接続を示す。端末と基地局との間のデータ接続が利用可能であることは、端末がデータサービスを処理するためにセルラネットワークを使用することを示し、すなわち、端末はセルラネットワーク内の基地局から信号を受信することができ、端末は、データサービスにおいて基地局とデータまたは命令を交換する機能を使用することができ、ここにおけるデータおよび命令とはデータサービスにおけるものである。端末と基地局との間のデータ接続が利用不可であることは、端末がデータサービスを処理するためにセルラネットワークを使用できないことを示し、すなわち、端末はセルラネットワークから信号を受信できない、または端末は音声サービスを処理する必要があり、したがって、データサービスにおいてセルラネットワーク内の基地局とデータまたは命令を同時に交換することができない。現在、端末のデータ接続が利用不可であるという既知の事例には、以下のもの、すなわち、端末が切断状態にある、端末がいずれのサービングセルにも正常にキャンプオンし損なう、端末のデータサービスが無効状態にある、または回線交換ドメインが2Gへフォールバックしている(回線交換フォールバック、CSFB)時に端末がGコールシナリオにある場合が含まれる。
送信対象パケットとは、端末から基地局に送信されるパケットであり、通常、端末上で動作するアプリケーションによって生成され、基地局に送信する必要があるデータをプロトコルスタックを用いてカプセル化したTCPパケットである。送信対象パケット内のデータは、ユーザの何らかの行動または行為によって生成されることがある。例えば、アプリケーションはブラウザである。ユーザは、ブラウザに表示されたリンクをタップするか、WEBサイトのアカウントやパスワードを入力する。リンク上のデータまたはユーザによって入力されたアカウントまたはパスワードは、ブラウザが基地局に送信する必要があるデータである。送信対象パケット内のデータは、代替的に、実行中のプロセスにおいてタスクを実行するためのアプリケーションによって生成されてもよい。例えば、アプリケーションはブラウザである。ホームページ上のニュースウィンドウを定期的に更新するために、ブラウザは、基地局に送信する必要がある要求データを生成する。プロトコルスタックを用いてデータをカプセル化して得たパケットは、端末の無線周波数コンポーネント(例えば、アンテナ)を用いて端末により送信される前の送信対象パケットである。当業者は、端末が送信対象パケットを生成または決定し得ることを理解するべきである。送信対象パケットの生成方法は、本発明において限定されない。
同一性:本出願における同一性は、完全な同一性または本質的な同一性を示す。例えば、第1のパケットと第2のパケットがTCPパケットである場合、第1のパケットと第2のパケットが同一であることは、少なくともデータ部、ソースポート番号、および宛先ポート番号などの情報に関して第1のパケットと第2のパケットが同一であることを示す。第2のパケットは第1のパケットのコピーとして理解されてもよく、それにより第1のパケットと第2のパケットのパケットヘッダまたはパケットトレーラの間の無視可能な差が許容される。これらの差は、例えば、タイムスタンプが異なる、またはいくつかのランダムに生成された値が異なるなどの理由により、パケットの生成中に端末によって生成されることがある。
出願において提供される技術的解決策は、典型的には、無線通信システム、例えば、モバイル通信用のグローバルシステム(GSM、Global System of Mobile Communication)ネットワーク、符号分割多重アクセス(CDMA、Code Division Multiple Access)ネットワーク、時分割同期符号分割多重アクセス(TDSCDMA、Time Division−Synchronous Code Division Multiple Access)ネットワーク、広帯域符号分割多重アクセス(WCDMA、Wideband Code Division Multiple Access Wireless)ネットワーク、汎用パケット無線サービス(GPRS、General Packet Radio Service)ネットワーク、ロングタームエボリューション(LTE、Long Term Evolution)ネットワーク、ソフトウェア定義ネットワーク(SDN、Software Defined Network)、またはワイヤレスセンサネットワーク(Wireless Sensor Network)に適用され得る。
図2は、本発明の実施形態による通信システム100の簡略ブロック図である。通信システム100は、本発明のアプリケーションシナリオとしてのみ使用される。これは、本発明のアプリケーションシナリオに対する限定として解釈されるべきではない。
本発明の明細書、特許請求の範囲、および添付の図面において、用語「第1の」、「第2の」、「第3の」、「第4の」など(存在する場合)は、類似の対象を区別することを意図しており、必ずしも特別の順番やシーケンスを示すとは限らない。
図2に示すように、通信システム100は、端末10と、アクセスポイント11と、ゲートウェイ12と、広域ネットワーク13と、サーバ20とを含む。本発明のこの実施形態における端末10は、モバイル端末(Mobile Terminal)、例えば、携帯電話、タブレット型コンピュータ、スポーツ射撃デバイス、またはノート型コンピュータなどの携帯型、ウェアラブル、または車載型のモバイルデバイスでもよく、またはセルラネットワークにアクセス可能なコンピュータまたはサーバなどのデバイス、またはセルラネットワークにアクセス可能なルータまたはゲートウェイ、例えば、SIM(Subscriber Identification Module、加入者識別モジュール)カードを使用可能なルータまたはゲートウェイなどのネットワークデバイスであってもよい。本発明のこの実施形態では、携帯電話が説明例として使用される。サーバ20は、アプリケーションサーバ、サーバエージェント、データセンタサーバ、またはルータやゲートウェイなどのネットワークデバイスとすることができる。
当業者であれば、通信システムは通常、図2に示すものより少ないかまたは多い構成要素を含み得る、または、図2に示すものと異なる構成要素も含み得ることを理解するであろう。図2は、本発明のこの実施形態で開示された実装により関連する構成要素のみを示す。例えば、図2は1つのサーバ20を示しているが、当業者は1つの通信システムが任意の数のサーバを含み得ることを理解するであろう。
広域ネットワーク13は、公衆ネットワーク、専用ネットワーク、またはインターネットの一部、および/またはそれらの任意の組み合わせを含み得る。アクセスポイントは、基地局、無線ローカルエリアネットワーク(WLAN)アクセスポイント、または他の形態のアクセスポイントであってもよい。ゲートウェイ12およびアクセスポイント11は無線ネットワークに含まれてもよい。簡潔にするために、無線ネットワークの他の部分は説明されない。
図2は、端末10のハードウェア構成をさらに示している。図2によると、端末10は、アプリケーションプロセッサ110、メモリ120、通信サブシステム130、および電力管理サブシステム140を含む。メモリ120は実行可能プログラムを格納し、実行可能プログラムはオペレーティングシステムおよびアプリケーションプログラムを含む。アプリケーションプロセッサ(Application Processor)110は、オペレーティングシステムやアプリケーションプログラムを実行するように構成されたプロセッサである。
実施形態では、アプリケーションプログラムはウェブブラウザであり、サーバ20はウェブコンテンツプロバイダのサーバである。別の実施形態では、プリケーションプログラムはオンラインビデオプレーヤであり、サーバ20はビデオコンテンツプロバイダのサーバである。別の実施形態では、プリケーションプログラムはインスタントメッセージングソフトウェアであり、サーバ20はインスタントメッセージングサービスプロバイダのサーバである。
通信サブシステム130は、主に、ベースバンド処理、変調および復調、信号増幅およびフィルタリング、ならびに平衡化などの機能を実施する。通信サブシステム130は、無線周波数モジュール132、アンテナ133、および無線モデム(Modem)とも呼ばれるベースバンドプロセッサ(Baseband Processor、BP)131を含む。ベースバンドプロセッサ131およびWi−Fiモジュール150は1つのチップに統合されてもよいことに留意されたい。また、ベースバンドプロセッサ131とアプリケーションプロセッサ110とを1つのチップに集積してもよいし、それぞれ独立したチップであってもよい。図2は単なる例示的表現である。電力管理サブシステム140は、システムに電力を供給するように構成されている。
メモリ120は通常、内部メモリと外部ストレージとを含む。内部メモリは、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、キャッシュ(CACHE)などであってもよい。外部ストレージは、ハードディスク、光ディスク、USBフラッシュドライブ、フロッピーディスク、テープドライブなどであってもよい。実行可能プログラムは通常、外部ストレージに格納されており、アプリケーションプロセッサ110は、実行可能プログラムを外部ストレージから内部メモリにロードした後にそのプログラムを実行する。
オプションで、端末10はさらにWi−Fi(Wireless Fidelity、ワイヤレスフィデリティ)モジュール150を含み、Wi−Fiモジュール150はIEEE802.11シリーズのプロトコルをサポートし、端末10はWi−Fiモジュール150を使用してWLANにアクセスし得る。
オプションで、端末10は、ユーザによって入力された情報またはユーザに対して提供された情報を表示するように構成されたディスプレイ160と、端末10の様々なメニューインタフェースとをさらに含む。ディスプレイ160は、液晶ディスプレイ(Liquid Crystal Display, LED)、有機発光ダイオード(Organic Light−Emitting Diode、OLED)などであってもよい。いくつかの他の実施形態では、タッチパネルがディスプレイ160を覆ってタッチディスプレイスクリーンを形成してもよい。
また、端末10は、写真またはビデオを撮影するためのカメラ180と、重力センサ、加速度センサ、または光学センサなどの1つまたは複数のセンサ170とをさらに含み得る。
さらに、当業者は、端末10が図2に示されるものより少ないかまたは多い構成要素を含んでもよいことを理解しえ得る。また図2に示す端末10では、本発明のこの実施形態において開示されている複数の実装により関連する構成要素のみが示されている。
以下、端末10のハードウェアおよびソフトウェア環境についてさらに説明する。端末10は、論理レベルに従って、ハードウェア層、オペレーティングシステム、およびオペレーティングシステム上で動作するアプリケーション層(ユーザモードとも呼ばれる)に分割し得る。ハードウェア層は、図2に関する実施形態で説明したハードウェア、例えば、アプリケーションプロセッサ110、メモリ120、およびWi−Fiモジュール150を含む。オペレーティングシステムは、アンドロイド(登録商標)オペレーティングシステム、リナックス(登録商標)オペレーティングシステム、ウィンドウズ(登録商標)オペレーティングシステム、または他のタイプのオペレーティングシステムであってもよい。これは、本発明のこの実施形態においては限定されない。
実施形態では、オペレーティングシステムは、フレームワーク(フレームワーク)層、カーネルモード、およびドライバ層を含む。ドライバ層は、センサドライバ、Wi−Fiドライバ、ディスプレイドライバなどのハードウェアデバイスのドライバを含む。カーネルモードは、TCPプロトコルスタック、IPプロトコルスタックなどを含む。以下、本発明のこの実施形態における方法手順を参照してカーネルモードをさらに説明する。フレームワーク層は、ユーザモードとカーネルモードとの間の通信用のインタフェース、およびいくつかのサービス、例えば、グラフィックサービス(Graphic Service)224、システムサービス(System service)221、ウェブサービス(Web Service)222、およびユーザサービス(User Service)223などのアプリケーション層で動作するアプリケーションを含む。これらのアプリケーションは通常、ディスプレイを使用してユーザと直接相互作用することができ、これらのアプリケーションはギャラリー、メディアプレーヤ(edia layer)、ブラウザ(rowser)、WeChat(WeChat)などである。オペレーティングシステム内のアプリケーションプログラムおよびアプリケーション層のアプリケーションプログラムは、実行可能プログラムとしてメモリ120に格納され得る。本発明のこの実施形態で使用される用語「プログラム」は、命令、命令セット、コード、コードセグメント、サブルーチン、ソフトウェアモジュール、アプリケーション、ソフトウェアパッケージスレッド、プロセス、機能、ファームウェア、ミドルウェアなどを含むがこれらに限定されないと広く解釈されるべきである。図2に示すように、端末10は、通信サブシステム130を使用してセルラネットワークにアクセスし、次いで広域ネットワーク13を使用してサーバ20と通信し得る。別の実施形態では、端末10はまた、Wi−Fiモジュール150を使用してWLANにアクセスし、次いで広域ネットワーク13を使用してサーバ20と通信し得る。具体的には、端末10は、ネットワークにアクセスした後、TCP/IPプロトコルスタック(TCPプロトコルスタックおよびIPプロトコルスタック)を使用してサーバ20に対するTCP接続を確立し、次いでTCP接続を使用してデータを送信し得る。TCP/IPプロトコルスタックは、TCP/IP参照モデルで定義されているTCP/IPプロトコルスイートを実装するために使用されるミドルウェアである。TCPプロトコルスタックは、端末10上のソフトウェア、ハードウェア、および/またはファームウェアの適切な組み合わせによって実行され得る。TCP/IPプロトコルスイートは、2つのコアプロトコル、すなわちTCP(Transmission Control Protocol)およびIP(Internet Protocol)を含む。端末10とサーバ20との間のTCP接続の確立は、端末10上で動作しているアプリケーションプログラムによって開始し得る。図3におけるブラウザ213は、例として使用される。ブラウザ213はソケットオープン(socket open)コマンドを生成し、そのコマンドは端末10のTCPプロトコルスタックに転送され、TCPプロトコルスタックを起動して3方向メッセージ交換(「スリーウェイハンドシェイク」とも呼ばれる)によるサーバ20へのTCP接続を確立する。そして、TCPプロトコルスタックは、接続が確立されたことをブラウザ213に通知する。
次いで、確立されたTCP接続に基づいてTCPパケットがブラウザ213とサーバ20との間で送信され得る。TCPパケットフォーマットを図4に示す。ソースポートおよび宛先ポートは送信側および受信側のアプリケーションプロセスを決定するように構成され、TCP接続はソースポート、宛先ポート、ソースIPアドレス、および宛先IPアドレスを使用して一意に決定され得る。TCPパケットヘッダ内のシーケンス番号(Sequence Number、通常略してseqと称される)フィールドは、パケットロード内の第1のデータバイトのシーケンス番号を搬送する。TCPパケットを受信した後、受信側は肯定応答(Acknowledgement、略してACK)パケットを送信側に送信する。ACKヘッダの確認応答番号(Acknowledgement Number、略してackと称される)フィールド値は、受信側が受信したパケットの「シーケンス番号」フィールドの値を表し、受信側が「シーケンス番号」値がACKパケットの「確認応答番号(Acknowledgement Number)」の値より小さい全てのパケットを受信したことを意味する。ウインドウサイズは、受信側の現在の受信バッファのサイズを示すために使用される。さらに、TCPパケットヘッダには6つのフラグビットと1つのカスタマイズ可能なオプション(Option)フィールドがあり、オプションフィールドは追加情報を伝達するために使用し得る。6つのフラグビットの定義は以下の通りである。
URGは、緊急ポインタが有効であることを示す。
ACKは、確認応答番号が有効であることを示す。
PSHは、処理するためにデータをアプリケーション層に直ちにプッシュすることを示す。
RSTは異常リセットを示す。
SYNは同期フラグであり、SYNが1に設定されると接続が確立される。
FINは、コネクションを解除することを要求するために使用される終了フラグである。
以下、TCP再送信メカニズムと輻輳制御メカニズムについて簡単に説明する。説明を簡単にするために、本出願においてその間で通信接続が確立されている2つのデバイスのうちの一方を送信側と呼び、他方を受信側と呼ぶ。送信側および受信側はそれぞれ、データ受信および送信能力を有する任意のデバイスであり得ることを理解されよう。例えば、送信側はサーバ20であってもよく、受信側は端末10あってもよい。さらに、送信側および受信側は2つの相対的な役割であり、そして交換可能であり得る、すなわち、異なるシナリオにおいて、同じデバイスが送信側になることも、または受信側になることもあり得る。
TCP再送信メカニズムはパケットの信頼できる送信を保証し、再送信メカニズムは主に、タイムアウト再送信および高速再送信を含む。タイムアウト再送信の基本プロセスは次のとおりである。パケットを送信した後、送信側はタイムアウトタイマーを開始し、タイムアウトタイマーが満了した後もパケットが正しく受信されたことを示す確認応答パケットを送信側が受信しない場合、送信側はパケットを再送信する。タイムアウトタイマーの値は、通常、RTO(Retransmission Timeut)として表される。RTOは通常、RTT(Round Trip Time)、すなわち、パケットの送信からそのパケットの肯定応答(Acknowledgement)の受信までに費やされる時間として設定される。RTTは、サンプリングによって得てもよい。
しかしながら、無線通信システムは端末にサービスを提供し、技術の発展と共に、端末は通常、2G、3G、および4Gネットワークなどの複数の種類の通信プロトコルをサポートすることを理解されたい。端末の位置が変わるなどの理由で、ネットワークは通常、不安定になったり、または信号強度が変化する。例えば、エレベータや地下駐車場のように信号が弱い領域、あるいは新幹線や高速鉄道のような高速輸送手段に端末があるようなシナリオでは、ネットワーク信号が不安定なため、端末のネットワーク接続ステータスが変化する。例えば、端末は、例えばLTEからWCDMAへのような異なるタイプのセルラネットワークでハンドオーバされてもよく、あるいはある期間内に、端末はネットワークから切断されてネットワークに再接続されてもよいが、この種の変化は、ある期間には頻繁になる。そのようなシナリオでは、端末が送信側として使用されるとき、セルラネットワークに送信されることになっているパケットの送信中に、端末のモデムはパケットを破棄し得る。この場合に生じるパケット損失は、アクティブパケット廃棄とも呼ばれる。したがって、アクティブパケット廃棄は、セルラネットワークを使用する端末で頻繁に発生する。
アクティブパケット廃棄は、パケットが送信のためにネットワークに入力する前に発生する行為であり、データはネットワーク送信プロセスにおいて失われないことが分かるだろう。上記の説明によれば、TCP再送信メカニズムでは、パケット損失の原因は区別されない。通常、再送は、ネットワーク側からのフィードバックを受信した後に実行される必要があり、したがって、モバイル端末は、アクティブなパケット破棄に応答するときに比較的大きな遅延を有する。本発明のこの実施形態では、アプリケーションプロセッサ110内のTCPプロトコルスタックがベースバンドプロセッサ131内の送信対象データのパケット損失を感知することができるように最適化が主に実行され、アクティブなパケット廃棄に対するモバイル端末による応答の遅延を低減する。本発明のこの実施形態における方法は、パケット再送信メカニズムを含む別の信頼できるトランスポートプロトコルにも適用可能であることを理解されるだろう。本発明のこの実施形態では、説明例としてTCPパケットが使用される。
図3はさらに、図1アプリケーションプロセッサ110およびベースバンドプロセッサ131、本発明のこの実施形態において協調してデータ処理するプロセスに使用されるフトウェアアーキテクチャを示す。アプリケーションプロセッサ110はプロセッサコアと見なし得る。ベースバンドプロセッサ131(モデムとも呼ばれる)は別のプロセッサコアと見なされる。ソフトウェアアーキテクチャは、2つのコア間のデータ通信用メカニズムをサポートできる。2つのコア間の通信は、特定のコア間通信プロトコルに適合している。コア間通信プロトコルの種類は、本発明のこの実施形態において限定されない。本発明のこの実施形態における端末がデータパケットをネットワーク側デバイスに送信するためのデータのソース側として使用されるプロセスは、図3を参照して以下に簡単に説明される。アプリケーションプロセッサ110では、アプリケーション層のアプリケーション(APP、application)がTCP接続のソース側のソケットインタフェースを使用してデータパケットをTCPプロトコルスタックとカーネル(カーネルモードとも呼ばれる)のIPプロトコルスタックを介して転送した後、アプリケーションプロセッサ110およびモデムのそれぞれのタスク(スレッドとしても理解され得るタスク)であり、コア間通信に使用されるタスクは、データパケットをモデム内の3GPP(3rd Generation Partnership Project、第3世代パートナーシッププロジェクト)プロトコルスタック(タスクまたはスレッドとしても理解され得る)に転送するために使用され、次いで3GPPプロトコルスタックは、通信サブシステム130内のハードウェアを使用して端末からデータパケットを送信する。
3GPPプロトコルスタックは、データリンク層および物理層において、1つまたは複数の通信プロトコルを搬送するために使用される。搬送される通信プロトコルは主に様々なセルラネットワークに使用される通信プロトコルであり、3Gネットワークの様々な通信プロトコルに限定されず、例えば、GSM、CDMA、またはLTEであってもよい。これは本発明において限定されない。
本発明のこの実施形態では、端末のカーネルの種類は、端末のオペレーティングシステムの種類によって決定され、本発明では限定されない。例えば、カーネルは、Linuxカーネル(Androidカーネル)またはWindowsカーネルであってもよい。実装において、比較的大きなデータ量のデータ(データパケットなど)をアプリケーションプロセッサ110とモデムとの間で送信するために使用されるコア間通信タスクは、比較的小さいデータ量の情報(ハートビート情報または制御命令など)をアプリケーションプロセッサ110とモデムとの間で送信するために使用されるコア間通信タスクとは異なる。さらに、比較的小さいデータ量の情報を送信するために使用されるコア間通信タスクは、次のように実施されてもよい。1つのタスクはアプリケーションプロセッサ110およびベースバンドプロセッサ131のそれぞれで動作し、比較的小さいデータ量の情報は2つのタスク間で送信されてもよく、2つのプロセッサ間の情報伝送は2つのタスク間の通信によって実施されてもよい。
具体的には、モデムでは、3GPPプロトコルスタックおよびアプリケーションプロセッサ110との間でデータパケットを送信するために使用されるタスクは、それぞれのデータパケットキャッシュキューを有しており、タイマは通常、これらのデータパケットキャッシュキューを監視するように構成される。具体的には、3GPPプロトコルスタック内の異なるプロトコルは通常、異なるデータパケットキャッシュキューに対応している。例えば、PDCP(Packet Data Convergence Protocol、パケットデータコンバージェンスプロトコル)キューがLTEプロトコルでは用いられ、PDCPキューまたはRLC(Radio Link Control、無線リンク制御)キューがWCDMAまたはTDSCDMAプロトコルでは用いられる。複数の場合において、データパケットキャッシュキュー内のデータパケットはモデムによって能動的に破棄され、ネットワークデバイスに送信されることができない。以下、いくつかの典型的なパケット破棄シナリオを簡単に列挙する。本発明のこの実施形態におけるパケット破棄シナリオは、以下の例に限定されないことを理解されたい。
例えば、モデム内にあり、プロセッサ110にデータパケットを送信するために使用されるタスクにおいて、アプリケーションプロセッサ110からデータパケットを受信した後、通常、RRC接続が確立されているかどうかが判定される。RRC接続が確立されていた場合、受信データパケットは処理するために3GPPプロトコルスタックに送信される。RRC接続が確立されていなかった場合、データパケットはタスクのキューにキャッシュされ、RRC接続が正常に確立された後に送信される。タスクでは、データパケットがキャッシュキューに保存されなかった場合、またはタスクのキャッシュキューのタイマが満了になり、かつRRC接続が確立されなかった場合、データパケットが破棄される、あるいはタスクでは、タスクのデータパケットキャッシュキューを消去するために使用されるERABM(E−UTRAN無線アクセスベアラ管理)メッセージが受信された後で、キャッシュキュー内のデータパケットが能動的に消去される。
3GPPプロトコルスタックは、端末のデータ接続が利用可能であるかどうかを判断するために、端末がデータサービスを処理するためにセルラネットワークを使用することができない原因となるイベントを検出手段によって発見し得る。例えば、端末は切断状態にある、端末はいずれのサービングセルにも正常にキャンプオンすることができない、端末のデータサービスは無効状態にある、または端末は回線交換ドメインが2Gへフォールバックしている(回線交換フォールバック、CSFB)時の場合には2Gコールシナリオにある。前述のいくつかのシナリオでは、端末のデータ接続は利用不可である。端末のデータ接続を利用できなくするイベントは、本発明のこの実施形態においては限定されない。あるいは、3GPPプロトコルスタックは、端末によって受信またはアクセスされるセルラネットワーク信号の強度や、端末によってアクセスされるセルラネットワークの種類、および端末が音声サービスを実行しているかどうかのような、端末がデータサービスを処理するためにセルラネットワークを使用できるかどうかを表すためにに使用されるいくつかのパラメータを収集し得る。ベースバンドプロセッサは、事前設定されたアルゴリズムによる計算によって、端末の現在のデータ接続が利用可能であるかどうかを判定する。特定のパラメータおよび特定のアルゴリズムは、本発明のこの実施形態においては限定されない。前述の検出または計算は、3GPPプロトコルスタックによって定期的に実行されてもよく、またはいくつかの命令によって起動されてもよく、または前述のイベントによって起動されてもよい。端末のデータ接続が利用可能であるかどうかを3GPPプロトコルスタックがどのように決定するかは、本発明のこの実施形態においては限定されない。端末がセルラネットワークを使用してデータサービスを処理するプロセスでは、RRC(Radio Resource Control、無線リソース制御)リンク確立および切断を伴い、端末と基地局との間のデータサービスインタラクションプロセスでしばしば実行され、端末と基地局との間のデータ接続が利用可能である場合、TCP接続、すなわち、物理層(Physical Layer)とメディアアクセス制御(Medi Access Control)層との間の接続をさらに確立するプロセスである。したがって、本発明のこの実施形態では、端末のデータ接続が利用可能であるという前提で、RRCリンク確立および切断の両方が発生する。データ接続が利用可能であるかどうかを端末が判断することは、RRCリンク確立および切断とは無関係である。
さらに、3GPPプロトコルスタックは、以下の場合に送信対象パケットを能動的に破棄し得る。
端末は、異なる無線セルラネットワーク間でハンドオーバされる。例えば、端末は、LTEネットワークからWCDMAネットワーク、TDSCDMAネットワーク、またはGSMネットワークにハンドオーバされる。これは、実際のシナリオでは不安定な4Gネットワークに起因して端末が4G基地局に接続できない、あるいはVoLTE(Voice over LTE)技術が現在使用されていないシナリオでは音声通信がLTEネットワーク(例えば、CSFBシナリオ)で開始されるために引き起こされる。端末が3Gネットワークまたは2Gネットワークにハンドオーバされるとき、このイベントはL2層(すなわち、MAC層、RLC層、およびPDCP層を含むLTE層2)で解除を引き起こす可能性がある。例えば、PDCPキューが解除され、モデムはPDCPキュー内の送信予定のパケットをクリアする。他の例では、端末は、WCDMAまたはTDSCDMAからLTEにハンドオーバされる。この出来事はまた、L2層で解除を引き起こす可能性がある。
ネットワークパラメータの設定が不適切である。例えば、端末がLTEネットワークを使用している場合、不適切なパラメータはPDCPの再設定を起こす可能性があり、モデムはPDCPキュー内の送信対象パケットをクリアする。端末がWCDMAまたはTDSCDMAネットワークを使用するとき、不適切なパラメータはRLC(無線リンク制御、無線リンク制御)再構成を引き起こす可能性がある。RLC層はMAC(Media Access Control、媒体アクセス制御)層の上方に位置し、MAC層と共にL2層の一部であり、そしてモデムは送信対象パケットをクリアする。
端末がWCDMAまたはTDSCDMAネットワークを使用するとき、RNC(Radio Network Controller、無線ネットワークコントローラ)ハンドオーバはRLC再確立を引き起こす可能性があり、モデムは送信対象パケットをクリアする。
PDCPキューは一杯であり、アプリケーションプロセッサ110によって配信されたパケットはキューに挿入されることができず、モデムにより廃棄される。この場合は、LTEネットワークまたはWCDMAまたはTDSCDMAネットワークで発生する可能性がある。
セルラネットワークでは、複数の無線ベアラ(すなわち、3GPPプロトコルスタック内のデータリンク層によって確立されたリンク)は、アプリケーションの複数のサービスを提供し得る。通常、1つのサービスが1つのベアラを使用する。各ベアラは、1つのPDCPキューにキャッシュされた送信対象パケットに対応する。ベアラ上のサービスがネットワークの問題により異常中断された場合、モデムはそのサービスに対応するPDCPキュー内の送信予定パケットを能動的にクリアする。
理解を容易にするために、図4は、TCPパケットフォーマットの模式図である。
図5を参照して、以下、本発明の実施形態で提供されるパケット送信方法を説明する。本方法は端末に適用され、端末はアプリケーションプロセッサ、ベースバンドプロセッサ、および通信インタフェースを含み、本方法は以下のステップを含む。
S502:ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートし、ここで第1のパケットは、ベースバンドプロセッサによって破棄される送信対象パケットである。
第1のパケットに関する情報は、第1のパケットの識別子と、第1のパケットが送信されるのに使用されたTCPコネクションの識別子とを含む。
ベースバンドプロセッサによって破棄された送信対象パケットはまた、アプリケーションプロセッサによりベースバンドプロセッサに配信され、ベースバンドプロセッサにより通信インタフェースを使用してネットワークデバイスへの送信ができないパケットとして理解し得ることに留意されたい。
ベースバンドプロセッサは、複数の送信対象パケットを破棄してもよい。前述の説明から、送信対象パケットが多くの場合破棄される可能性があることを知り得る。具体的には、ベースバンドプロセッサは、破棄された送信対象パケットを決定するために、破棄された送信対象パケットに関する情報を記録してもよく、またはベースバンドプロセッサが送信対象パケットを破棄する原因となるイベント、例えば、異なるセルラネットワーク間のハンドオーバを監視してもよい。ベースバンドプロセッサが廃棄される送信対象パケットに関する情報をどのように取得するかは、本発明のこの実施形態においては限定されない。
ベースバンドプロセッサは、破棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートし得る。説明を簡単にするために、第1のパケットがTCPパケットである例として第1のパケットを使用して説明が提供される。第1のパケットに関する情報は、第1のパケットの識別子と、第1のパケットが送信されるのに使用されたTCP接続の識別子とを含む。実装形態では、第1のパケットの識別子はパケットのシーケンス番号であってもよい。第1のパケットが送信されるのに使用されたTCP接続の識別子は、TCP接続のソースポート番号であってもよい。TCPパケットフォーマット(図4に示すように)によれば、ベースバンドプロセッサは、送信対象パケットを処理するプロセスにおいて解析することによってシーケンス番号およびソースポート番号を取得し得る。
当業者は、ベースバンドプロセッサがパケットに関する情報でありレポートされる必要がある情報を決定してもよく、特定の実装は本発明のこの実施形態では限定されないことを理解すべきである。具体的な伝送プロトコルはTCPプロトコルに限定されない。
実装では、ベースバンドプロセッサは、破棄された送信対象パケットに関する情報をレポートするための適切な機会を選択し、パケットが破棄された後でアプリケーションプロセッサへのレポートを直ちに実行する代わりに、適切な機会に複数の破棄されたパケットに関する情報をレポートし得る。具体的には、端末のデータ接続が利用可能であるとき、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにレポートする。あるいは、端末のデータ接続が利用不可である場合、ベースバンドプロセッサは第1のパケットに関する情報をキャッシュし、端末のデータ接続が利用不可から利用可能に切り替えられる場合、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにレポートする。前述の2つの方法を一緒に使用できることを理解されたい。
ベースバンドプロセッサのキャッシュキューは、アプリケーションプロセッサにレポートされるべき情報をキャッシュし得るが、その情報は、ベースバンドプロセッサにより破棄された送信対象パケットに関する情報である。
データ接続は、データサービスを実施するために使用される接続である。端末のデータ接続は、端末と基地局との間のデータ接続として理解され得る。詳細については、前述の説明を参照されたし。
端末のデータ接続が利用不可から利用可能に切り替えられると、ベースバンドプロセッサは第1のパケットに関する情報をアプリケーションプロセッサにリポートすることに留意されたい。これは、端末のデータ接続が利用不可から利用可能に切り替わった後、ベースバンドプロセッサが第1のパケットに関する情報をアプリケーションプロセッサにリポートすることを示す。命令の読み取り、関連する操作の実行などには時間がかかるので、同時性は厳密には要求されない。すなわち、端末のデータ接続が利用不可から利用可能に切り替わった後の比較的短い時間(例えば、数ミリ秒または数秒)内に、ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにリポートする動作を完了する。
この実装において、ベースバンドプロセッサは、端末のデータ接続が利用可能であるかどうかを決定する必要があることが理解され得る。
端末は、周期的な検出、イベントトリガ、命令トリガなどによって、端末のデータ接続が利用可能か利用不可かを判定し得ることを理解され得る。データ接続が利用可能であるかどうかを決定するために使用されるイベント、その分析で使用される特定の分析プロセスおよびアルゴリズム、ならびに端末のデータ接続が利用可能であるかどうかを判定するためにベースバンドプロセッサを起動する方法は本発明の実施形態では限定されない。さらなる説明については、前述の関連説明を参照されたい。
ベースバンドプロセッサはステップS502を実行して、データパケットをベースバンドプロセッサに時間内に再送するようにパケットが廃棄されたことをアプリケーションプロセッサに知らせ、ベースバンドプロセッサは再送されたデータパケットを取得してデータパケットを受信側に送信する。したがって、端末のデータ接続が利用できないときに再送信が実行されると、データ接続が利用できないためにベースバンドプロセッサは再びパケットを能動的に破棄し、アプリケーションプロセッサのこの再送信は無効になる。したがって、データ接続が利用可能である場合にのみベースバンドプロセッサが破棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートすれば、再送有効性を改善することができる。さらに、ステップS502を実行するとき、ベースバンドプロセッサはアプリケーションプロセッサを起動する必要がある。パケットが廃棄された直後にベースバンドプロセッサが情報をレポートする場合、アプリケーションプロセッサは頻繁に起動され、そしてそれゆえに、端末のエネルギー消費は非常に増大する。モバイル端末は通常電池を使用しており、消費電力はできるだけ少なく、待機時間はできるだけ長くすることが必要となる。したがって、廃棄された送信対象パケットに関する情報が、ネットワークが利用可能であるときにだけアプリケーションプロセッサにレポートされる場合、端末のエネルギー消費量が減少されることが可能である。
もちろん、別の実装では、ベースバンドプロセッサは代替として、端末のデータ接続が利用可能であるかどうかを考慮せず、再送信が必要なパケットに関する情報が決定されると、情報をアプリケーションプロセッサにレポートする。これは、本発明のこの実施形態においては限定されない。
S504:アプリケーションプロセッサは、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信し、ここで第2のパケットは第1のパケットと同一である。
実装では、アプリケーションプロセッサは、受信した第1のパケットに関する情報に従って、その情報が含む第1のパケットと第1のパケットが配置されているTCP接続のソースポートとを取得し、アプリケーションプロセッサはソースポートを使用して第1のパケットをベースバンドプロセッサに再送信する。
第2のパケットは、第1のパケットのコピーとして理解し得る。
TCP伝送プロトコルによれば、送信側のTCPプロトコルスタックがパケットを下位層に送信した後、パケットのコピーがTCP接続のキューに保存されることを理解されたい。パケットのコピーは、TCP接続の受信側から返されたACK(Acknowledgement、確認応答)が受信され、パケットが受信側で正常に受信されたことを確認するまで削除されない。そうでなければ、もしTCP接続の受信側から返されたACKが受信されない場合は、パケットのコピーは送信タイムアウトの場合における再送信のために記憶される。したがって、アプリケーションプロセッサは、第1のパケットに関するものであり、ベースバンドプロセッサによってレポートされた情報に従って、第2のパケットをベースバンドプロセッサに再送信し得る。
S506:ベースバンドプロセッサは、通信インタフェースを使用して第2のパケットをネットワークデバイスに送信する。
ネットワークデバイスは、セルラネットワーク内の基地局またはサーバなどのネットワークデバイスとし得る。これは、本発明のこの実施形態において限定されない。
結論として、送信対象パケットを破棄した後、ベースバンドプロセッサは、アプリケーションプロセッサにベースバンドプロセッサによって破棄された送信対象パケットに関する情報をレポートし得る。その結果、アプリケーションプロセッサは、レポートされた情報に従ってベースバンドプロセッサに、ベースバンドプロセッサによって破棄されたパケットのコピーを再配信することができる。パケットのタイムアウトタイマーが満了し、いかなる確認応答パケットもピアエンドから受信されないことが判定される前に、パケットが廃棄され、パケットがベースバンドプロセッサに再送信されることが決定可能である。これにより、ベースバンドプロセッサによって廃棄された送信対象パケットを端末が再送信する際の遅延を減少することができ、端末によるパケット損失に応答する遅延をある程度減少することができ、その結果、端末とネットワークとの間のデータ伝送はより滑らかになる。無線セルラネットワークの状態はしばしば変化するので、ベースバンドプロセッサが送信対象パケットを廃棄する場合が頻繁に発生する。
さらに、上述のように、実装において、電力消費を考慮して、端末によってアクセスされるセルラネットワークの状態が利用可能になるまで、ベースバンドプロセッサは破棄された送信対象パケットに関する情報をレポートしない。この場合、破棄された送信対象パケットに関する情報は、レポートされる前に特定時間待機する必要がある。これにより、以下の2つのケースが発生し得る。1つのケースでは、パケットに関する情報がベースバンドプロセッサによってレポートされる前に、廃棄された送信対象パケットのタイムアウトタイマが満了する。この場合、破棄されたパケットと同じパケットは、TCP接続とタイムアウト再送信メカニズムを使用して再送信された可能性がある。ベースバンドプロセッサは、もはや廃棄されたパケットに関する情報をアプリケーションプロセッサにレポートする必要がない。ベースバンドプロセッサは、廃棄されたパケットと同じ受信されたパケットに従って、廃棄されたパケットに関する情報をフィルタ除去し得る。それによって電力の浪費および端末トラフィックの浪費を回避することができる。他のケースでは、アプリケーションプロセッサが破棄されたパケットと同じパケットを配信するとき、破棄されたパケットのタイムアウトタイマーは満了する。この場合もタイムアウト再送要件を同等に満たしているため、TCP接続の輻輳制御方式が起動され得る。
TCP再送信メカニズムは信頼できるパケット送信を保証することができるが、従来技術の再送信メカニズムでは、ネットワーク輻輳が原因でパケット損失が引き起こされることがデフォルトで考慮されることに留意されたい。通常、ネットワーク伝送中のパケット損失の最も一般的な原因は、ネットワーク負荷が高すぎることである。ネットワークデバイスは、現時点でネットワークにおいて送信される必要があるデータ量を捌くことができず、ネットワークの輻輳が引き起こされ、したがってネットワーク内で送信されるいくつかのパケットは破棄される。したがって、輻輳制御方法を再送信メカニズムと共に使用してネットワーク内の輻輳を低減し、再送信されたパケットによってピアエンドに到達する成功率を向上させる。輻輳制御アルゴリズムは主に、スロースタート(Slow Start)、輻輳回避(Congestion Avoidance)などを含む。簡単に言えば、パケットが損失し、再送信する必要があることが分かると、アプリケーションプロセッサは、輻輳ウインドウ(CWND, congestion window)の値やスロースタート閾値(ssthresh、slow start threshold)などの、端末によってネットワークに送信されるパケットの量を制限するためのいくつかのパラメータの値を減少する。アプリケーションプロセッサは通常、調整されたパラメータを使用して、再送信されたパケットをベースバンドプロセッサに配信する速度と、後続の送信対象パケットをベースバンドプロセッサに配信する速度とを制御する。
例えば、パケット損失がタイムアウト再送信を引き起こす場合、送信側はスロースタート閾値をCWND/2に減少し、次いでCWNDを1に設定し、そしてスロースタートプロセスに再び入り得る。別の例では、送信側がACKに従って、パケットが損失されたと判断して高速再送信を開始する場合、送信側は輻輳ウインドウを半分に減少し、スロースタート閾値を更新された輻輳ウインドウサイズに設定してもよい。異なるアルゴリズムでは、輻輳ウインドウおよびスロースタート閾値を減少させる振幅および方法は異なるが、ほとんどの場合、パケット廃棄バックオフ規則が基礎として使用される、すなわち、送信側がネットワーク内でパケットが損失していると判断する場合、輻輳ウインドウサイズとスロースタート閾値が能動的に減少される。
しかしながら、本発明のこの実施形態における能動的なパケット廃棄はネットワーク輻輳によって引き起こされないので、端末によって無線ネットワークに送信されるパケットの量を減少する必要はなく、またパケットはベースバンドプロセッサによって能動的に廃棄されるため、できるだけ早くピアエンドにパケットを送信するために、特定量の送信パケットを確保する必要がある。しかしながら、本発明のこの実施形態における方法は通常、既存のTCPメカニズムで使用され、CWNDが減少されるという前述の問題は避けられない。
したがって、本発明のこの実施形態の実装では、アプリケーションプロセッサが第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信した後、アプリケーションプロセッサは補償として輻輳ウインドウを増加させる。
例えば、CWNDは、輻輳ウインドウの指定された初期値まで増加、または輻輳ウインドウの減少が再送信によって引き起こされる前に使用される、輻輳ウインドウの値に戻し得る。本発明のこの実施形態では、アプリケーションプロセッサが輻輳ウインドウを増加させる値、およびアプリケーションプロセッサが輻輳ウインドウを増加させるために使用するポリシーなどは限定されない。これにより、タイムアウト再送信による影響を排除でき、端末により送信されるパケット量を確保することができ、また端末の送信スループットを向上させることができる。
別の実施形態では、アプリケーションプロセッサとベースバンドプロセッサ(モデムとも呼ばれる)とを同一チップの同一コアに統合することさえ可能であり、上述の方法はそのようなチップにも適用可能である。説明を容易にするために、この実装では、チップはプロセッサと呼ばれ、TCPプロトコルスタックおよび3GPPプロトコルスタックは、プロセッサ上で動作する2つのタスク(またはスレッド)として理解されることもあり、この2つのタスクは異なるプロセスまたは同一のプロセスに属してもよく、TCPプロトコルスタックと3GPPプロトコルスタックは、スレッド間またはプロセス間の通信メカニズムを使用して情報を交換する。アプリケーションプログラムはさらに、アプリケーションプロセッサ上で動作する。
アプリケーションプログラムはさらに、例えば、アプリケーションプログラムによって生成されたデータまたはアプリケーションプログラムからの要求であり、ユーザ操作によって起動された要求を、TCPプロトコルスタックおよび3GPPプロトコルスタックを使用してパケットとして、基地局に送信する。3GPPプロトコルスタックは、アプリケーションプログラムの破棄されたパケットに関する、パケットの識別子およびパケットが位置するTCP接続の識別子などの情報をスレッド間またはプロセス間の通信メカニズムを使用してTCPプロトコルスタックに転送し、その結果、TCPプロトコルスタックは、破棄されたパケットに関する受信した情報に従って、破棄されたパケットと同じパケットを3GPPプロトコルスタックに転送する。プロセッサは、3GPPプロトコルスタックによって受信され、廃棄されたパケットと同じパケットを通信インタフェースを使用して基地局に送信する。
この実装における他の詳細については、上述の本出願を参照されたい。詳細は本明細書では再度説明されない。このようにして、ベースバンドプロセッサによって破棄されたパケットの端末による再送信の際の遅延を減少させることができ、端末とネットワークデバイスとの間の遅延をある程度減少させ、端末とネットワークとの間のデータ伝送がより円滑になる。
実施形態において、ベースバンドプロセッサが送信対象パケットを破棄した後に、アプリケーションプロセッサがベースバンドプロセッサとどのように協働して再送信を完了させるかについて、図3のソフトウェアアーキテクチャを参照しながらAndroidシステムを備える端末を例として使用して以下に説明する。アプリケーションプロセッサとベースバンドプロセッサは、2つのコアまたは2つの独立したチップである。本実施形態において、上述した内容については、前述の説明を参照されたい。詳細は本明細書では再度説明しない。
この実装では、ベースバンドプロセッサは、3GPPプロトコルスタックと、アプリケーションプロセッサとの間でデータパケットを送信するために使用されるタスク(略してコア間データ送信タスクと称す)とを含み、さらに比較的少量のデータを送信するためのコア間通信タスクを含む。アプリケーションプロセッサは、ベースバンドプロセッサ内のコア間通信タスクに対応する別のコア間通信タスクと、TCPプロトコルスタックと、IPプロトコルスタックと、アプリケーションプロセッサのアプリケーション層で動作するアプリケーションとを含む。
ベースバンドプロセッサ内の3GPPプロトコルスタックは、ベースバンドプロセッサによって破棄された送信対象パケットと、端末によって現在アクセスされているセルラネットワークの状態とを監視する。具体的には、3GPPプロトコルスタックは、廃棄された送信対象パケットを決定するために、ベースバンドプロセッサが送信対象パケットを破棄する原因となるイベント、例えば、異なるセルラネットワーク間のハンドオーバを監視し得る。
3GPPプロトコルスタックは、ベースバンドプロセッサによって廃棄された送信対象パケットに関する情報(廃棄されたパケットのシーケンス番号および廃棄されたパケットが位置するTCP接続のソースポート番号を含む)を生成しその情報をキューに格納し、端末のデータ接続が利用可能であるかどうかを示す情報(接続が利用可能であるかどうかを示すために使用されるいくつかのパラメータ、または異なる値が接続の利用可能または利用不可を示す、直接的にはブール値であり得る情報)を生成し、上記2種類の情報をベースバンドプロセッサ内のコア間通信タスクに転送する、例えば、共有メモリを用いてその情報を転送する。
また、ベースバンドプロセッサ内にあり、かつアプリケーションプロセッサとの間でデータパケットを送信するために使用されるタスクにおいても、タスク内で破棄されたパケットが検出される。3GPPプロトコルスタックと同様に、タスクは、ベースバンドプロセッサにより破棄された送信対象パケットに関する生成された情報(破棄されたパケットのシーケンス番号および破棄されたパケットが配置されているTCP接続のソースポート番号を含む)をベースバンドプロセッサ内のコア間通信タスクに転送する、例えば、共有メモリを用いてその情報を転送する。
コア間通信タスクは、廃棄されたパケットに関する取得した情報をタスクのキューを用いて管理する。キューが一杯になると、キューは破棄されたパケットに関する情報であり、キューが一杯になった後に得られる情報を破棄し、コア間通信タスクは3GPPプロトコルスタックによって提供される端末のデータ接続に関する情報に従って端末のデータ接続が利用可能か利用不可かを判断する。
端末のデータ接続が利用可能の場合、コア間通信タスクはキュー内の破棄されたパケットに関する情報をアプリケーションプロセッサ内のコア間通信タスクに送信し、それによりアプリケーションプロセッサは破棄されたパケットに関する情報を学習する。
端末のデータ接続が利用不可の場合、コア間通信タスクのキューのタイマが開始され、タイマが満了するとき、再び3GPPプロトコルスタックによって提供される情報に従ってタイマにより計時された時間の後で端末のデータ接続が利用可能かどうかが判定される。データ接続が利用可能である場合、コア間通信タスクは、キュー内の破棄されたパケットに関する情報をアプリケーションプロセッサ内のコア間通信タスクに送信し、タイマがリセットされる。データ接続がまだ利用できない場合、タイマがリセットされ、タイマが次に満了になるときに判定が実行される。
アプリケーションプロセッサは、破棄された送信対象パケットに関するものであり、ベースバンドプロセッサによって送信された情報を解析して、破棄されたパケットのシーケンス番号および破棄されたパケットが位置するTCP接続のソースポート番号を取得する。
アプリケーションプロセッサは、ソースポート番号を使用してLinuxネットワークプロトコルスタック内の対応するTCP接続を見つけ、廃棄された送信対象パケットのシーケンス番号と、TCP接続の送信キュー内のパケットのシーケンス番号とを比較して破棄された送信対象パケットのコピーを見つけ、TCP/IPプロトコルスタックを使用して、破棄された送信対象パケットのコピーをベースバンドプロセッサに送信する。
また、廃棄された送信対象パケットのコピーをアプリケーションプロセッサによって送信するプロセスにおいて、例えば、送信対象パケットのコピーが再送された後で、TCP輻輳制御が起動された場合、端末のCWNDは1に減少し、アプリケーションプロセッサは現在のCWND値を端末の初期CWND値(TCP_INIT_CWND)とCWNDが1に減少する前に使用されていた値のうち小さい方の値に設定する。このようにして、タイムアウト再送による影響を排除しかつ端末のスループットを向上させるために輻輳ウインドウの不必要な減少が回避されることが可能であり、この結果、時間的により多くのパケットが送信されることができ、それによりパケット損失に対する再送に起因する遅延を低減する。
ベースバンドプロセッサは、送信対象パケットのコピーであって、アプリケーションプロセッサによって送信されコピーを受信し、アンテナなどの無線周波数回路を使用してそのコピーをネットワークデバイスに送信する。
このようにして、送信対象パケットを破棄した後、ベースバンドプロセッサは、ベースバンドプロセッサによって破棄された送信対象パケットに関する情報をアプリケーションプロセッサにレポートすることが可能であり、それにより、アプリケーションプロセッサは、レポートされた情報に従ってベースバンドプロセッサに、ベースバンドプロセッサにより破棄されたパケットを再配信できる。パケットのタイムアウトタイマーが満了し、いかなる確認応答パケットもピアエンドから受信されないことが判断される前に、パケットが廃棄され、パケットがベースバンドプロセッサに再送信されることが決定されることが可能である。これにより、ベースバンドプロセッサにより破棄されたパケットを端末により再送信する際の遅延を減少することができ、端末の再送遅延をある程度減少することができるので、端末とネットワークとの間のデータ伝送はより円滑になる。無線セルラネットワークの状態はしばしば変化するので、ベースバンドプロセッサが送信対象パケットを廃棄するケースが頻繁に発生する。
以下、テスト結果を用いて、上記実施の形態における方法の効果について説明する。上記実施形態の方法を用いることで端末の再送メカニズムが改善され、再送遅延を比較的大幅に減少することができ、アップリンク送信のデータスループットが向上される。弱電界シナリオとセルラネットワークの高速移動シナリオを実証するために、広州から深センまでの高速鉄道でチャイナユニコムの無線セルラネットワークの使用が選択されてテストを実行した。
伝送遅延については、テストツールiPerfが使用され、サンプリング方法は、アプリケーションプロセッサを用いてデータパケットを伝送するタスクにおいて引き起こされる3GPPプロトコルスタックにおけるパケット損失について能動的にレポートされたパケット伝送遅延を計算することである。ソースエンドは、ピアエンドがサーバである携帯電話である。最適化前は、平均伝送遅延は約75秒である。最適化後は、平均伝送遅延は約45秒である。廃棄されたパケットに対する平均再送遅延は、40%最適化されている。
アップリンク伝送スループット(アップリンク伝送方向は携帯電話端末からサーバ方向)は、テストツールiPerfを用いる。サンプリング方法は、各iPerfテスト中にカウントされた平均スループット(1ラウンドあたり100秒または200秒であり、サーバ側でカウントされる)を計算することである。最適化前は、平均スループットは約1.5Mbpsである。最適化後は、平均スループットは約3.3Mbpsである。平均スループットは、約2.2倍に向上される。
本発明の実施形態はさらにパケット送信装置600を提供し、パケット送信装置600の概略構造図は図9である。本装置は、ベースバンドプロセッサ、アプリケーションプロセッサ、および送信器を含む。ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。第1パケットは、ベースバンドプロセッサによって破棄される送信対象パケットであり、第1パケットに関する情報は、第1パケットの識別子と、第1パケットが送信されるのに使用されたTCPコネクションの識別子とを含む。アプリケーションプロセッサは、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同じである。ベースバンドプロセッサはさらに、送信器を使用して第2のパケットをネットワークデバイスに送信するように構成される。
実装において、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、装置のデータ接続が利用可能であるときに、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
本実施形態の上述の様々な実装を参照すると、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、装置のデータ接続が利用できないとき、第1のパケットの情報をキャッシュし、装置のデータ接続が利用不可から利用可能に切り替えられたとき、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
この実施形態の上述の様々な実装を参照すると、アプリケーションプロセッサはさらに、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信した後にRRCするように構成される。
本実施形態の上述の様々な実装を参照すると、第1のパケットの識別子は第1のパケットのシーケンス番号であり、第1のパケットが送信されるのに使用されたTCP接続の識別子は、第1のパケットが配置されているTCP接続のソースポート番号であり、第1のパケットに関する情報に従って第2のパケット番号をベースバンドプロセッサに送信することに関して、アプリケーションプロセッサは、ソースポート番号に従って第1のパケットと同じシーケンス番号を有する第2のパケットをベースバンドプロセッサに送信するように構成される。
この実施形態における名詞およびステップの具体的な説明および関連する有益な効果については、上述の説明を参照し、詳細は本明細書では再度説明されないことに留意されたい。
上述の方法の実施形態で説明した装置は、セルラネットワークによって提供されるデータサービスを使用してデータサービスを送信または実行する任意のデバイスによって実装され得ることは理解されよう。本発明はさらに、上述の方法の実施形態における方法を実施するための端末を提供する。端末の概略構成図を図7に端末300として示す。端末300は、処理回路302と、処理回路302に接続された通信インタフェース304および記憶媒体306とを含む。図6の実施形態の送信器は、通信インタフェース304内の送信器回路318に相当する。
処理回路302は、データを処理し、データアクセスおよびストレージを制御し、コマンドを送信し、他の装置を制御して動作を実行するように構成される。処理回路302は、1つまたは複数のプロセッサ、1つまたは複数のコントローラ、および/またはプログラムを実行するために使用され得る別の構造として実装され得る。処理回路302は、特に、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他のプログラマブルロジックコンポーネントのうちの少なくとも1つを含み得る。汎用プロセッサは、マイクロプロセッサ、および任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械を含み得る。処理回路302は、代替的に、DSPとマイクロプロセッサとの組み合わせなどのコンピューティングコンポーネントとして実装されてもよい。
本発明のこの実施形態では、処理回路はアプリケーションプロセッサ309とベースバンドプロセッサ310とを含む。
記憶媒体306は、(ハードディスク、フロッピー(登録商標)ディスク、または磁気ストライプなどの)磁気記憶装置などのコンピュータ可読記憶媒体、(デジタル多用途ディスク(DVD)などの)光学記憶媒体、スマートカード、フラッシュメモリデバイス、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、プログラマブルROM(PROM)、消去可能PROM(EPROM)、レジスタ、またはそれらの任意の組み合わせを含み得る。記憶媒体306は、処理回路302が情報を読み取り、その情報を記憶媒体306に書き込むことが可能なように処理回路302に結合され得る。具体的には、記憶媒体306は、処理回路302に統合されてもよく、または媒体306と処理回路302は分離されてもよい。
通信インタフェース304は、端末300と1つまたは複数の無線ネットワークデバイス(例えば、基地局またはサーバ)との間の双方向通信を実施するための回路および/またはプログラムを含み得る。通信インタフェース304は、1つまたは複数のアンテナ(図7には図示せず)に結合されてもよく、少なくとも1つの受信器回路316および/または少なくとも1つの送信器回路318を含む。
実施形態において、記憶媒体306はプロトコルスタックプログラム320を記憶し、処理回路302はプロトコルスタックプログラム320を実行してプロトコルスタックの機能を実現する。プロトコルスタックと各アプリケーションプロセッサ309およびベースバンドプロセッサ310との関係については、図3の関連説明を参照されたい。
プロトコルスタックは、アプリケーションプログラムのデータをTCP/IPプロトコル仕様に従って特定のデータフォーマットの複数のパケットにカプセル化し、送信器回路318を使用して複数のパケットをアプリケーションサーバに送信するために使用される。また、プロトコルスタックはさらに、受信器回路316が受信したパケットをデカプセル化して、最終的にアプリケーションプログラムのデータを取得する。プロトコルスタックによるパケットのカプセル化およびデカプセル化のプロセスを図8Aおよび図8Bに示す。パケットカプセル化プロセスは、本質的にプロトコルスタックがパケットにヘッダおよび/またはフレームトレーラを追加するプロセスであり、パケットデカプセル化プロセスは、本質的にパケットからヘッダおよび/またはフレームトレーラを削除するプロセスであることがわかる。通信インタフェース304により受信されたデータを復号および/またはデカプセル化した後で、プロトコルスタックは、データを上位層のアプリケーションプログラムに転送するか、またはアプリケーションプログラムのデータをカプセル化して通信インタフェースを使用することにより別のデバイスに送信し得る。
実施形態では、プロトコルスタックは、層のプロトコルを実装するために、物理層、データリンク層、ネットワーク層、トランスポート層、およびアプリケーション層を含み得る。例えば、物理層は、物理デバイスインタフェース機能、伝送媒体タイプ、伝送速度、伝送モードなどを定義し、物理層で信号処理を実施するために使用される。同様に、データリンク層は、データリンク層の機能を実行するために使用され、例えば、ネットワーク層で生成されたシグナリングを分配し、物理層によって生成された情報を処理することを担当する。データリンク層は、それぞれMAC層、RLC層、およびLLC層の機能を実装するように構成されているメディアアクセス制御(Media Access Control、MAC)層モジュール、無線リンク制御(RLC)層モジュール、および論理リンク制御(LLC)層モジュールなどの1つまたは複数のサブモジュールを含み得る。例えば、MAC層モジュールは、物理層によって提供されるサービスを使用して上位層プロトコルデータを送信し、上位層とエアインタフェースとの間のデータアクセスを管理するように構成される。RLC層モジュールは、データの分割と再構成に使用される。LLC層モジュールは、フロー制御、シーケンス制御、およびエラー制御機能を提供するように構成されている。さらに、ネットワーク層は、論理アドレス指定およびルーティング選択などの機能を実装するように構成されている。トランスポート層は、ポートアドレス指定、セグメント化および再構成、接続制御、フロー制御、およびエラー制御などの機能を実施するように構成されている。アプリケーション層は、上位層においてアプリケーションプログラム用のインタフェースを提供するように構成されている。
本発明のこの実施形態の1つまたは複数の態様によれば、処理回路302は、プロトコルスタックの機能を実装するように、記憶媒体306に格納されたプロトコルスタックプログラム320を実行するように適合されている。アプリケーションプロセッサ309内のプロトコルスタックおよびベースバンドプロセッサ310内のプロトコルスタックは、前述の方法の実施形態におけるステップの一部またはすべてを具体的に実施する。
本発明の実施形態はさらにチップを提供する。チップは無線周波数コンポーネントを使用してネットワークデバイスへのデータ接続を確立し、チップはアプリケーションプロセッサとベースバンドプロセッサとを含む。ベースバンドプロセッサは、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。第1パケットは、ベースバンドプロセッサによって破棄される送信対象パケットであり、第1パケットに関する情報は、第1パケットの識別子と、第1パケットが送信されるのに使用されるTCP接続の識別子とを含む。アプリケーションプロセッサは、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信するように構成され、第2のパケットは第1のパケットと同じである。ベースバンドプロセッサは、無線周波数コンポーネントを使用して第2のパケットをネットワークデバイスに送信するようにさらに構成される。
すなわち、本発明のこの実施形態で説明するチップは、実際には、図7に示す端末に配置されて使用される処理回路302である。
実装において、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、チップのデータ接続が利用可能であるときに、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
本発明のこの実施形態の前述の実装を参照すると、別の実装では、第1のパケットに関する情報をアプリケーションプロセッサにレポートすることに関して、ベースバンドプロセッサは、チップのデータ接続が利用できない場合、第1のパケットに関する情報をキャッシュし、チップのデータ接続が利用不可から利用可能に切り替わったときに、第1のパケットに関する情報をアプリケーションプロセッサにレポートするように構成される。
本発明のこの実施形態の前述の実装を参照すると、別の実装では、アプリケーションプロセッサはさらに、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信した後に輻輳ウインドウを増大するよう構成される。
本発明のこの実施形態の前述の実装を参照すると、別の実装では、第1のパケットの識別子は第1のパケットのシーケンス番号であり、第1のパケットが送信されるのに使用されるTCP接続の識別子は、TCP接続のソースポート番号であり、第1のパケットに関する情報に従って第2のパケットをベースバンドプロセッサに送信することに関して、アプリケーションプロセッサは第1のパケットと同じシーケンス番号を有する第2のパケットをソースポート番号に従ってベースバンドプロセッサに送信するように構成される。
本実施形態で説明するチップの詳細については、図8Aと図8Bに示した端末および上述のチップに実装されることができる方法の実施形態の説明を参照し、詳細については、本明細書では再び説明しない。
本発明の実施形態はさらに、記憶媒体を提供し、この媒体は、本発明で説明されたパケット送信方法を実施するためのコードを記憶するように構成される。
出願で提供されるパケット送信方法および装置は、上記で詳細に説明されている。本明細書では、本発明の原理および実装を説明するために具体的な例が適用され、前述の実施形態の説明は、本発明の方法および核となる概念を理解する手助けとすることだけを意図している。さらに、当業者であれば、本発明の思想に従って具体的な実装および適用範囲を変更することができる。結論として、本明細書の内容は本発明に対する限定として解釈されるべきではない。

Claims (16)

  1. 端末に適用されるパケット送信方法であって、前記端末はベースバンドプロセッサと、アプリケーションプロセッサと、通信インタフェースとを備え、
    前記ベースバンドプロセッサにより、第1のパケットに関する情報を前記アプリケーションプロセッサにレポートするステップであり、前記第1のパケットは前記ベースバンドプロセッサによって破棄された送信対象パケットであり、前記第1のパケットに関する前記情報は前記第1のパケットの識別子および前記第1のパケットが属するTCP接続の識別子を含む、ステップと、
    前記アプリケーションプロセッサにより、第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信するステップであり、前記第2のパケットは前記第1のパケットと同一である、ステップと、
    前記ベースバンドプロセッサにより、前記通信インタフェースを使用して前記第2のパケットをネットワークデバイスに送信するステップと
    を含む、パケット送信方法。
  2. 前記ベースバンドプロセッサにより、第1のパケットに関する情報を前記アプリケーションプロセッサにレポートする前記ステップは、
    前記端末のデータ接続が利用可能な場合、前記ベースバンドプロセッサにより、前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートするステップを含む、請求項1に記載の方法。
  3. 前記ベースバンドプロセッサにより、第1のパケットに関する情報を前記アプリケーションプロセッサにレポートするステップは、
    前記端末の前記データ接続が利用不可である場合、前記ベースバンドプロセッサにより、前記第1のパケットに関する前記情報をキャッシングし、前記端末の前記データ接続が利用不可から利用可能に切り替えられた場合、前記ベースバンドプロセッサにより、前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートするステップを含む、請求項1または2に記載の方法。
  4. 前記アプリケーションプロセッサにより、第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信する前記ステップの後で、前記方法はさらに、
    前記アプリケーションプロセッサにより、輻輳ウインドウを増大するステップを含む、請求項1から3のいずれか一項に記載の方法。
  5. 前記第1のパケットの前記識別子は、前記第1のパケットのシーケンス番号であり、前記第1のパケットが属する前記TCP接続の前記識別子は、前記第1のパケットが位置する前記TCP接続のソースポート番号であり、
    前記アプリケーションプロセッサにより、第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信する前記ステップは、
    前記アプリケーションプロセッサにより、前記第1のパケットと同じシーケンス番号を有する前記第2のパケットを前記ソースポート番号に応じて前記ベースバンドプロセッサに送信するステップを含む、請求項1から4のいずれか一項に記載の方法。
  6. ベースバンドプロセッサと、アプリケーションプロセッサと、送信器とを備えるパケット送信装置であって、
    前記ベースバンドプロセッサは、第1のパケットに関する情報を前記アプリケーションプロセッサにレポートするように構成され、前記第1のパケットは前記ベースバンドプロセッサによって破棄された送信対象パケットであり、前記第1のパケットに関する前記情報は前記第1のパケットの識別子および前記第1のパケットが属するTCP接続の識別子を含み、
    前記アプリケーションプロセッサは、第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信するように構成され、前記第2のパケットは前記第1のパケットと同一であり、
    前記ベースバンドプロセッサはさらに、前記送信器を使用して前記第2のパケットをネットワークデバイスに送信するように構成される、パケット送信装置。
  7. 前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートすることに関し、前記ベースバンドプロセッサは、前記装置のデータ接続が利用可能な場合、前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートするように構成される、請求項6に記載の装置。
  8. 前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートすることに関し、
    前記ベースバンドプロセッサは、前記装置の前記データ接続が利用不可である場合、前記第1のパケットに関する前記情報をキャッシングし、前記装置の前記データ接続が利用不可から利用可能に切り替えられた場合、前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートするように構成される、請求項6または7に記載の装置。
  9. 前記アプリケーションプロセッサはさらに、前記第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信した後で、輻輳ウインドウを増大するように構成される、請求項6から8のいずれか一項に記載の装置。
  10. 前記第1のパケットの前記識別子は、前記第1のパケットのシーケンス番号であり、前記第1のパケットが属する前記TCP接続の前記識別子は、前記第1のパケットが位置する前記TCP接続のソースポート番号であり、前記第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信することに関し、前記アプリケーションプロセッサは、前記第1のパケットと同じシーケンス番号を有する前記第2のパケットを前記ソースポート番号に応じて前記ベースバンドプロセッサに送信するように構成される、請求項6から9のいずれか一項に記載の装置。
  11. 無線周波数コンポーネントを使用してネットワークデバイスに対するデータ接続を確立するチップであって、前記チップは、アプリケーションプロセッサおよびベースバンドプロセッサを備え、前記ベースバンドプロセッサは、第1のパケットに関する情報を前記アプリケーションプロセッサにレポートするように構成され、前記第1のパケットは前記ベースバンドプロセッサによって破棄された送信対象パケットであり、前記第1のパケットに関する前記情報は前記第1のパケットの識別子および前記第1のパケットが属するTCP接続の識別子を含み、前記アプリケーションプロセッサは、第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信するように構成され、前記第2のパケットは前記第1のパケットと同一であり、前記ベースバンドプロセッサはさらに、前記無線周波数コンポーネントを使用して前記第2のパケットを前記ネットワークデバイスに送信するように構成される、チップ。
  12. 前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートすることに関し、前記ベースバンドプロセッサは、前記チップのデータ接続が利用可能な場合、前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートするように構成される、請求項11に記載のチップ。
  13. 前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートすることに関し、前記ベースバンドプロセッサは、前記チップの前記データ接続が利用不可である場合、前記第1のパケットに関する前記情報をキャッシングし、前記チップの前記データ接続が利用不可から利用可能に切り替えられた場合、前記第1のパケットに関する前記情報を前記アプリケーションプロセッサにレポートするように構成される、請求項11または12に記載のチップ。
  14. 前記アプリケーションプロセッサはさらに、前記第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信した後で、輻輳ウインドウを増大するように構成される、請求項11から13のいずれか一項に記載のチップ。
  15. 前記第1のパケットの前記識別子は、前記第1のパケットのシーケンス番号であり、前記第1のパケットが属する前記TCP接続の前記識別子は、前記第1のパケットが位置する前記TCP接続のソースポート番号であり、前記第2のパケットを前記第1のパケットに関する前記情報に応じて前記ベースバンドプロセッサに送信することに関し、前記アプリケーションプロセッサは、前記第1のパケットと同じシーケンス番号を有する前記第2のパケットを前記ソースポート番号に応じて前記ベースバンドプロセッサに送信するように構成される、請求項11から14のいずれか一項に記載のチップ。
  16. アプリケーションプロセッサと、ベースバンドプロセッサと、メモリと、通信インタフェースとを備える端末であって、前記アプリケーションプロセッサ、前記ベースバンドプロセッサ、および前記通信インタフェースは前記メモリに接続され、前記アプリケーションプロセッサ、前記ベースバンドプロセッサ、および前記通信インタフェースは、前記メモリに格納された命令を呼び出すことによって、請求項1から5のいずれか一項に記載の前記方法を実行する、端末。
JP2019522717A 2016-11-02 2017-11-02 パケット送信方法および装置、チップ、ならびに端末 Active JP6924830B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201610946705.1A CN108023683B (zh) 2016-11-02 2016-11-02 一种发送报文的方法、装置、芯片及终端
CN201610946705.1 2016-11-02
PCT/CN2017/109133 WO2018082615A1 (zh) 2016-11-02 2017-11-02 一种发送报文的方法、装置、芯片及终端

Publications (2)

Publication Number Publication Date
JP2020502873A true JP2020502873A (ja) 2020-01-23
JP6924830B2 JP6924830B2 (ja) 2021-08-25

Family

ID=62070043

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019522717A Active JP6924830B2 (ja) 2016-11-02 2017-11-02 パケット送信方法および装置、チップ、ならびに端末

Country Status (9)

Country Link
US (1) US10771595B2 (ja)
EP (1) EP3522417A4 (ja)
JP (1) JP6924830B2 (ja)
KR (2) KR102350444B1 (ja)
CN (2) CN112713970B (ja)
BR (1) BR112019008916A2 (ja)
CA (1) CA3042605C (ja)
RU (1) RU2752652C2 (ja)
WO (1) WO2018082615A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021199162A1 (ja) * 2020-03-30 2021-10-07 日本電信電話株式会社 監視装置、通信システム、通信制御方法、及び監視プログラム
JPWO2021199161A1 (ja) * 2020-03-30 2021-10-07

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108011834A (zh) * 2016-10-28 2018-05-08 华为技术有限公司 Tcp拥塞窗口的确定方法和装置
CN112713970B (zh) * 2016-11-02 2022-05-13 华为技术有限公司 一种发送报文的方法、装置、芯片及终端
CN108289007B (zh) 2017-01-10 2022-04-15 中兴通讯股份有限公司 数据包传输方法及装置
CN108667560B (zh) 2017-03-31 2020-12-04 华为技术有限公司 一种调整终端发送数据的速率的方法及装置
US10931587B2 (en) * 2017-12-08 2021-02-23 Reniac, Inc. Systems and methods for congestion control in a network
CN109302575A (zh) * 2018-08-21 2019-02-01 广州市保伦电子有限公司 一种基于IOT模块的wifi会议系统
CN109743142A (zh) * 2018-09-30 2019-05-10 比亚迪股份有限公司 消息通信方法及装置
CN110049050B (zh) * 2019-04-22 2021-03-19 中国科学院计算机网络信息中心 一种通信的方法及装置
US10880211B2 (en) 2019-05-06 2020-12-29 Seth Gregory Friedman Transaction encoding and verification by way of data-link layer fields
CN110391956B (zh) * 2019-07-23 2021-08-13 中国工商银行股份有限公司 网络服务进程状态的识别监控方法及装置
CN112311725B (zh) * 2019-07-26 2022-01-11 华为技术有限公司 一种数据处理方法、装置及终端
US10868707B1 (en) 2019-09-16 2020-12-15 Liquid-Markets-Holdings, Incorporated Zero-latency message processing with validity checks
WO2021252423A1 (en) 2020-06-08 2021-12-16 Liquid-Markets-Holdings, Incorporated Hardware-based transaction exchange
CN114765690B (zh) * 2020-12-31 2023-09-12 华为技术有限公司 数据包传输方法、通信装置及存储介质
CN115085890A (zh) * 2022-06-23 2022-09-20 杭州云合智网技术有限公司 数据中心网络芯片优化tcp rto重传等待时间的方法
CN117856985A (zh) * 2024-03-08 2024-04-09 珠海星云智联科技有限公司 用于报文重传的方法、计算机设备、介质及程序

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012034407A (ja) * 2007-12-20 2012-02-16 Ntt Docomo Inc 移動局、基地局装置、通信制御方法及び移動通信システム
JP2012508532A (ja) * 2008-11-10 2012-04-05 クアルコム,インコーポレイテッド 欠落したメディアアクセスコントロールフレームのためにアプリケーションにより構成されるコンテンツベースの再送信スキーム
WO2012132283A1 (ja) * 2011-03-28 2012-10-04 日本電気株式会社 通信装置およびその通信制御方法
JP2014507817A (ja) * 2011-01-12 2014-03-27 日本電気株式会社 通信装置、パケット再送制御方法、パケット再送制御プログラム
JP2014239470A (ja) * 2010-07-30 2014-12-18 クゥアルコム・インコーポレイテッドQualcomm Incorporated 複数のモデムを有するモバイルデバイス上でのデータ呼の調整

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1200368C (zh) 2000-08-18 2005-05-04 清华大学 一种将tcp用于不可靠传输网络的局域重传方法
SE0103853D0 (sv) * 2001-11-15 2001-11-15 Ericsson Telefon Ab L M Method and system of retransmission
US7551561B2 (en) * 2003-05-15 2009-06-23 Panasonic Corporation Packet communication terminal
CN1520104B (zh) * 2003-09-02 2010-04-28 中国科学院计算技术研究所 提高tcp在异构网络中传输性能的方法
JP4580770B2 (ja) * 2005-02-01 2010-11-17 株式会社エヌ・ティ・ティ・ドコモ 通信システム及び受信装置
US20090019460A1 (en) * 2007-05-03 2009-01-15 Qualcomm Incorporated Application programming interface (api) for handling errors in packets received by a wireless communications receiver
CN101052006B (zh) * 2007-05-14 2010-06-09 华为技术有限公司 报文上送的方法及实现该方法的接口板及路由器
US20090168723A1 (en) * 2007-11-27 2009-07-02 Qualcomm Incorporated Method and apparatus for handling out-of-order packets during handover in a wireless communication system
CN101232446A (zh) * 2008-02-01 2008-07-30 华为技术有限公司 报文处理方法及装置
CN101860435B (zh) * 2009-04-13 2012-10-31 中国移动通信集团公司 报文发送、接收以及确定网络节点的方法及装置
US9100459B2 (en) * 2010-04-30 2015-08-04 Qualcomm Incorporated Exchanging data associated with a communication session within a communications system
CN102833783B (zh) * 2012-07-02 2015-04-08 北京邮电大学 一种优化无线环境下tcp协议的方法
CN103001885B (zh) * 2012-12-25 2015-08-26 中国科学院深圳先进技术研究院 数据报文传输方法和系统
CN103986548B (zh) 2013-02-07 2018-02-23 华为技术有限公司 一种确定丢包原因的方法和终端
CN105075323B (zh) * 2013-03-29 2019-02-05 Vid拓展公司 早期分组丢失检测和反馈
US9510242B2 (en) * 2013-05-17 2016-11-29 Nvidia Corporation Reducing superfluous traffic in a network
US9258834B2 (en) * 2013-09-05 2016-02-09 Spreadtrum Communications (Shanghai) Co., Ltd. Method of mobile terminal internal communications
CN112713970B (zh) * 2016-11-02 2022-05-13 华为技术有限公司 一种发送报文的方法、装置、芯片及终端

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012034407A (ja) * 2007-12-20 2012-02-16 Ntt Docomo Inc 移動局、基地局装置、通信制御方法及び移動通信システム
JP2012508532A (ja) * 2008-11-10 2012-04-05 クアルコム,インコーポレイテッド 欠落したメディアアクセスコントロールフレームのためにアプリケーションにより構成されるコンテンツベースの再送信スキーム
JP2014239470A (ja) * 2010-07-30 2014-12-18 クゥアルコム・インコーポレイテッドQualcomm Incorporated 複数のモデムを有するモバイルデバイス上でのデータ呼の調整
JP2014507817A (ja) * 2011-01-12 2014-03-27 日本電気株式会社 通信装置、パケット再送制御方法、パケット再送制御プログラム
WO2012132283A1 (ja) * 2011-03-28 2012-10-04 日本電気株式会社 通信装置およびその通信制御方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021199162A1 (ja) * 2020-03-30 2021-10-07 日本電信電話株式会社 監視装置、通信システム、通信制御方法、及び監視プログラム
JPWO2021199162A1 (ja) * 2020-03-30 2021-10-07
JPWO2021199161A1 (ja) * 2020-03-30 2021-10-07
WO2021199161A1 (ja) * 2020-03-30 2021-10-07 日本電信電話株式会社 監視装置、通信システム、通信制御方法、及び監視プログラム

Also Published As

Publication number Publication date
RU2019116616A3 (ja) 2021-02-01
BR112019008916A2 (pt) 2019-12-24
JP6924830B2 (ja) 2021-08-25
CN112713970B (zh) 2022-05-13
RU2019116616A (ru) 2020-12-03
KR102397347B1 (ko) 2022-05-13
CN108023683A (zh) 2018-05-11
KR20210016084A (ko) 2021-02-10
EP3522417A4 (en) 2019-10-16
CN112713970A (zh) 2021-04-27
EP3522417A1 (en) 2019-08-07
KR102350444B1 (ko) 2022-01-14
RU2752652C2 (ru) 2021-07-29
CA3042605A1 (en) 2018-05-11
US20190268445A1 (en) 2019-08-29
WO2018082615A1 (zh) 2018-05-11
CN108023683B (zh) 2020-12-25
US10771595B2 (en) 2020-09-08
CA3042605C (en) 2023-07-18
KR20190073479A (ko) 2019-06-26

Similar Documents

Publication Publication Date Title
JP6924830B2 (ja) パケット送信方法および装置、チップ、ならびに端末
US11153041B2 (en) Packet transmission method and user equipment
US20190319889A1 (en) Packet transmission method, terminal, network device, and communications system
TWI477166B (zh) 於通信網路中用於節制協定引發後移之裝置與方法
WO2019246350A1 (en) Efficient buffer management in multi-hops data forwarding
US20060007862A1 (en) Method and apparatus for managing packet data loss in a wireless network
US11044630B2 (en) Method and apparatus for adjusting data sending rate of terminal
EP4002954A1 (en) Reliable data delivery over non-access stratum
CN111448826B (zh) 用于在低延迟移动通信网络中减少切换过程中数据包重传的方法及装置
EP2996275B1 (en) Link processing method and mobile terminal in multiplexing control protocol
EP3713299A1 (en) Method and device for data transmission
EP3949680B1 (en) Methods and arrangements for managing round trip time associated with provision of a data flow via a multi-access communication network
WO2023061588A1 (en) Radio access retransmission control

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190604

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190604

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200515

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200526

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200826

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210126

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210802

R150 Certificate of patent or registration of utility model

Ref document number: 6924830

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150