JP6262991B2

JP6262991B2 - ユーザ装置及び方法

Info

Publication number: JP6262991B2
Application number: JP2013227129A
Authority: JP
Inventors: 徹内野; 明人花木
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2013-10-31
Filing date: 2013-10-31
Publication date: 2018-01-17
Anticipated expiration: 2033-10-31
Also published as: EP3065456A1; JP2015089009A; EP3065456A4; US20160249232A1; WO2015064318A1

Description

本発明は、無線通信システムに関する。

ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）システムでは、パケットベースの無線通信が利用される。このようなパケットベース無線通信では、無線通信のための各種機能を階層化された複数のレイヤが実行することによって、無線通信が実現される。ＬＴＥシステムでは、図１に示されるようなレイヤ構造により無線通信を実現することが規定されている。図１に示されるように、ＰＨＹ（Ｐｈｙｓｉｃａｌ）レイヤ、ＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）レイヤ、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）レイヤ、ＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）レイヤ及びＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）レイヤが使用される。

このうち、ＰＤＣＰレイヤは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）パケットの秘匿処理、改ざん検出及びヘッダ圧縮などの機能を提供している。秘匿処理及び改ざん検出には、ＨＦＮ（ＨｙｐｅｒＦｒａｍｅＮｕｍｂｅｒ）とＰＤＣＰＳＮ（ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ）とから構成されるＣＯＵＮＴ値が利用される。

ＰＤＣＰＳＮは、ＰＤＣＰレイヤからＲＬＣレイヤにＰＤＣＰパケットを送出する毎にインクリメントされ、"０"から"４０９５"までの範囲のＰＤＣＰＳＮが、ＰＤＣＰパケットに巡回的に付与される。例えば、シーケンス番号"４０９５"のＰＤＣＰパケットの次にＲＬＣレイヤに送出されるＰＤＣＰパケットには、シーケンス番号"０"が付与される。ＨＦＮは、ＰＤＣＰＳＮが周回する毎にインクリメントされ、"０"から"１０４８５７６"までの範囲のＨＦＮが、ＰＤＣＰパケットに付与される。ＣＯＵＮＴ値は、上位ビットにＨＦＮを有し、下位ビットにＰＤＣＰＳＮを有するよう構成される。ＬＴＥシステムでは、ＣＯＵＮＴ値のＰＤＣＰＳＮのみが受信側に送信され、ＨＦＮは送信されない。このため、受信側は、受信状況から受信したパケットのＨＦＮを推測する必要がある。

ＰＤＣＰレイヤの動作について概略すると、送信側では、ＰＤＣＰエンティティが、上位レイヤから受信したパケット、すなわち、ＰＤＣＰＳＤＵ（ＳｅｒｖｉｃｅＤａｔａＵｎｉｔ）に対して、ＣＯＵＮＴ値を用いて秘匿処理、改ざん検出及びヘッダ圧縮を実行し、ＰＤＣＰＳＮをヘッダに付与してＰＤＣＰパケット、すなわち、ＰＤＣＰＰＤＵ（ＰａｃｋｅｔＤａｔａＵｎｉｔ）としてＲＬＣレイヤに送出する。

一方、受信側では、ＰＤＣＰエンティティは、図２に示されるように、受信したパケットの順序を補正するための受信ウィンドウを管理する。ＬＴＥシステムでは、受信ウィンドウのサイズは、ＰＤＣＰＳＮの上限値"４０９５"の１／２である２０４７に設定される。送信側から受信したパケットのＰＤＣＰＳＮが受信ウィンドウの範囲内である場合、ＰＤＣＰエンティティは、現在の受信状況から当該パケットの解匿処理に用いるＨＦＮを推測し、推測したＨＦＮとヘッダのＰＤＣＰＳＮとから構成されるＣＯＵＮＴ値に基づき受信したパケットに対して解匿処理を実行する。その後、ＰＤＣＰエンティティは、処理後のパケットを上位レイヤに送出し、受信ウィンドウを更新する。他方、送信側から受信したパケットのＰＤＣＰＳＮが受信ウィンドウの範囲外である場合、ＰＤＣＰエンティティは、当該パケットを破棄する。

３ＧＰＰＴＳ３６．３２３Ｖ８．６．０（２００９−０６）

現状のＬＴＥシステムでは、ＰＤＣＰの受信ウィンドウはＰＤＣＰＰＤＵ受信時にのみ更新されることが規定されている。このため、送信側のＰＤＣＰエンティティにおいて大量のＰＤＣＰＰＤＵが破棄されると、受信側のＰＤＣＰエンティティにおいて受信ウィンドウが適切に更新されない可能性がある。送信側のＰＤＣＰエンティティでは、例えば、以下のようなケースにおいてＰＤＣＰＰＤＵが破棄されることがある。

第１のケースとして、送信側のＰＤＣＰエンティティによる大量のＰＤＣＰＰＤＵの破棄が考えられる。送信側のＰＤＣＰエンティティは、バッファ溢れやＤｉｓｃａｒｄＴｉｍｅｒの満了によりＰＤＣＰＰＤＵを破棄している。ＰＤＣＰＰＤＵが大量に破棄された場合、ユーザ装置（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ＵＥ）と基地局（ｅｖｏｌｖｅｄＮｏｄｅＢ：ｅＮＢ）との間でＣＯＵＮＴ値（ＨＦＮ＋ＰＤＣＰＳＮ）のミスマッチが発生し、Ｕ−ｐｌａｎｅが不通になる可能性がある。具体的には、最後にトランスポートブロックにマッピングしたＰＤＣＰＰＤＵのＣＯＵＮＴ値に受信ウィンドウのサイズ２０４７を加えたＣＯＵＮＴ値を有するＰＤＣＰＰＤＵまで連続して破棄されると、以降のＰＤＣＰＰＤＵは受信側の受信ウィンドウの範囲外となってしまい、以降の全てのＰＤＣＰＰＤＵが破棄されることになる。このため、送信側のＰＤＣＰエンティティは、送信するＰＤＣＰＰＤＵが常に受信ウィンドウ内に入るように、受信側のＰＤＣＰエンティティに受信ウィンドウを適切に更新させる必要がある。

第２のケースとして、基地局間キャリアアグリゲーション（Ｉｎｔｅｒ−ｅＮＢＣＡ）におけるパケット破棄が考えられる。３ＧＰＰＲｅｌｅａｓｅ１２では、異なるｅＮＢ間でキャリアアグリゲーションを実行することによって、スループットを向上させるためのＩｎｔｅｒ−ｅＮＢＣＡが検討されている。Ｉｎｔｅｒ−ｅＮＢＣＡにおけるＵ−ｐｌａｎｅアーキテクチャの１つとして、図３に示されるようなものが検討されている。図示されるアーキテクチャでは、Ｍａｓｔｅｒ−ｅＮＢのＰＤＣＰエンティティが、Ｓ１インタフェースを介しネットワーク装置などからデータを受信すると、所定の分配規則に従ってＸｎインタフェースを介しＳｅｃｏｎｄａｒｙ−ｅＮＢにデータを分配する。Ｍａｓｔｅｒ−ｅＮＢとＳｅｃｏｎｄａｒｙ−ｅＮＢとのキャリアアグリゲーションによって、ユーザ装置のスループットを向上させることができる。この場合、受信側であるユーザ装置のＰＤＣＰエンティティは、Ｍａｓｔｅｒ−ｅＮＢとＳｅｃｏｎｄａｒｙ−ｅＮＢとから送信される２つのＲＬＣストリームを順序補正する必要がある。

このようなＩｎｔｅｒ−ｅＮＢＣＡでは、送信側からｏｕｔ−ｏｆ−ｓｅｑｕｅｎｃｅでＰＤＣＰＰＤＵを受信すると、受信側のＰＤＣＰエンティティは、欠落しているＰＤＣＰＰＤＵがｅＮＢで破棄されたのか、あるいは無線送信中であるか判断することができない。このため、ユーザ装置は、所定の期間当該欠落しているＰＤＣＰＰＤＵを待機し、受信済みの後続のＰＤＣＰＰＤＵを一時的にバッファリングする必要がある。その後、Ｍａｓｔｅｒ−ｅＮＢとＳｅｃｏｎｄａｒｙ−ｅＮＢとの双方から後続のＰＤＣＰＰＤＵを受信すると、受信側のＰＤＣＰエンティティは、欠落しているＰＤＣＰＰＤＵが無線送信中でなく、破棄されたことがわかる。

しかしながら、Ｍａｓｔｅｒ−ｅＮＢとＳｅｃｏｎｄａｒｙ−ｅＮＢとの何れかのｅＮＢにおいて全てのＰＤＣＰＰＤＵが破棄されてしまうと、受信側のＰＤＣＰエンティティは、当該ｅＮＢから後続のＰＤＣＰＰＤＵを受信することができず、当該ｅＮＢにおけるＰＤＣＰＰＤＵの破棄を検出することができない。このため、受信側のＰＤＣＰエンティティは、破棄されたＰＤＣＰＰＤＵを所定の期間待機することになる。この場合、ＴＣＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）レイヤでのＳＡＣＫ（ＳｅｌｅｃｔｉｖｅＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）送信が遅延し、最悪のケースではＲＴＯ（ＲｅｔｒａｎｓｍｉｓｓｉｏｎＴｉｍｅＯｕｔ）となり、スループットが著しく低下する可能性がある。

具体例を用いてＩｎｔｅｒ−ｅＮＢＣＡにおけるパケット破棄を説明する。図４は、一例となるＩｎｔｅｒ−ｅＮＢＣＡのパケット送信を示す概略図である。図４に示されるように、ユーザ装置は、Ｍａｓｔｅｒ−ｅＮＢ（ＭｅＮＢ）とＳｅｃｏｎｄａｒｙ−ｅＮＢ（ＳｅＮＢ）とＩｎｔｅｒ−ｅＮＢＣＡを利用して通信している。ネットワーク装置などの上位局から受信したパケットについて、ＭｅＮＢは、ＰＤＣＰＳＮが偶数であるＰＤＣＰＰＤＵについては自局からユーザ装置に送信し、ＰＤＣＰＳＮが奇数であるＰＤＣＰＰＤＵについてはＳｅＮＢに転送し、ＳｅＮＢからユーザ装置に送信する。このような分配規則によると、パケットが破棄されない場合、図示されるように、ユーザ装置は、ＭｅＮＢからＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵをＲＬＣＳＮ＝０としてまず受信し、その後にＰＤＣＰＳＮ＝２のＰＤＣＰＰＤＵをＲＬＣＳＮ＝１として受信する。他方、ユーザ装置は、ＳｅＮＢからＰＤＣＰＳＮ＝１のＰＤＣＰＰＤＵをＲＬＣＳＮ＝０としてまず受信し、その後にＰＤＣＰＳＮ＝３のＰＤＣＰＰＤＵをＲＬＣＳＮ＝１として受信する。仮に、ＭｅＮＢからＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵを受信する前にＳｅＮＢからＰＤＣＰＳＮ＝１のＰＤＣＰＰＤＵを受信した場合、ユーザ装置は、ＰＤＣＰレイヤでＲｅｏｒｄｅｒｉｎｇＴｉｍｅｒを起動し、ＭｅＮＢからのＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵを待機する。この待機時間は、最悪のケースでは、ＲＬＣ最大再送回数分となる。

図５は、一例となるＭａｓｔｅｒ−ｅＮＢで一部のデータが破棄されるケースを示す概略図である。図５に示されるように、ＭｅＮＢにおいてＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵが破棄されたと仮定する。この場合、ユーザ装置は、ＭｅＮＢからＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵを受信する前にＳｅＮＢからＰＤＣＰＳＮ＝１のＰＤＣＰＰＤＵを受信するため、ＰＤＣＰレイヤでＲｅｏｒｄｅｒｉｎｇＴｉｍｅｒを起動する。その後、ＭｅＮＢからＰＤＣＰＳＮ＝２のＰＤＣＰＰＤＵを受信した時点で、ユーザ装置は、ＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵが破棄されたと判断することができ、ＲｅｏｒｄｅｒｉｎｇＴｉｍｅｒを停止し、ＰＤＣＰＳＮ＝２によりＰＤＣＰレイヤにおける受信ウィンドウを更新する。

図６は、一例となるＭａｓｔｅｒ−ｅＮＢで全てのデータが破棄されるケースを示す概略図である。図６に示されるように、ＭｅＮＢにおいてＰＤＣＰＳＮ＝０，２のＰＤＣＰＰＤＵが破棄されたと仮定する。この場合、ユーザ装置は、ＭｅＮＢからＰＤＣＰＳＮ＝０のＰＤＣＰＰＤＵを受信する前にＳｅＮＢからＰＤＣＰＳＮ＝１のＰＤＣＰＰＤＵを受信するため、ＰＤＣＰレイヤでＲｅｏｒｄｅｒｉｎｇＴｉｍｅｒを起動する。しかしながら、後続するＰＤＣＰＳＮ＝２のＰＤＣＰＰＤＵもまた受信できないため、ユーザ装置は、ＲｅｏｒｄｅｒｉｎｇＴｉｍｅｒが満了するまでＰＤＣＰＳＮ＝０，２のＰＤＣＰＰＤＵが破棄されたと判断することができない。この結果、ＴＣＰレイヤのＳＡＣＫ返送が遅延し、スループットが著しく低下する可能性がある。

このように送信側のＰＤＣＰエンティティにおいてＰＤＣＰＰＤＵが連続破棄されると、受信側のＰＤＣＰエンティティにおいて受信ウィンドウが適切に更新されない可能性がある。

上記問題点を鑑み、本発明の１つの課題は、パケットの破棄によるユーザ装置におけるＰＤＣＰ受信ウィンドウの更新遅延を回避するための技術を提供することである。

上記課題を解決するため、本発明の１つの態様は、基地局との間でパケットを送受信する送受信部と、前記基地局から受信したＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）パケットに対して前記ＰＤＣＰパケットのシーケンス番号が受信ウィンドウの範囲内であるか判断し、前記受信ウィンドウの範囲内のシーケンス番号を有するＰＤＣＰパケットに対してＰＤＣＰレイヤの処理を実行するＰＤＣＰレイヤ処理部と、前記基地局から受信したパケットが前記受信ウィンドウを更新させるための所定の更新トリガパケットであるか判定し、前記受信したパケットが前記更新トリガパケットである場合、前記ＰＤＣＰレイヤ処理部に前記受信ウィンドウを更新させる受信ウィンドウ更新判定部とを有するユーザ装置に関する。

本発明によると、パケットの破棄によるユーザ装置におけるＰＤＣＰ受信ウィンドウの更新遅延を回避することが可能になる。

図１は、ＬＴＥにおけるレイヤ構造を示す概略図である。図２は、ＰＤＣＰレイヤにおける一例となる動作を示す概略図である。図３は、一例となるＭａｓｔｅｒ−ｅＮＢ及びＳｅｃｏｎｄａｒｙ−ｅＮＢのＵ−ｐｌａｎｅアーキテクチャを示す概略図である。図４は、一例となるＩｎｔｅｒ−ｅＮＢＣＡのパケット送信を示す概略図である。図５は、一例となるＭａｓｔｅｒ−ｅＮＢで一部のデータが破棄されるケースを示す概略図である。図６は、一例となるＭａｓｔｅｒ−ｅＮＢで全てのデータが破棄されるケースを示す概略図である。図７は、本発明の一実施例による無線通信システムを示す概略図である。図８は、本発明の一実施例によるユーザ装置の構成を示すブロック図である。図９は、本発明の一実施例によるユーザ装置における受信ウィンドウ更新処理を示すフロー図である。

以下、図面に基づいて本発明の実施の形態を説明する。

後述する本発明の実施例を概略すると、基地局におけるパケットの破棄に対して、ＰＤＣＰレイヤにおける受信ウィンドウの更新遅延を回避するユーザ装置が開示される。後述される実施例では、受信ウィンドウを更新させるため、所定の更新トリガパケットが基地局からユーザ装置に送信される。基地局から受信したパケットが当該更新トリガパケットであると判定すると、ユーザ装置はＰＤＣＰレイヤにおける受信ウィンドウを更新する。これにより、基地局においてパケットが破棄されたとしても、ユーザ装置は、破棄されたパケットを待機することなく、受信ウィンドウを更新することが可能になり、ユーザ装置と基地局との間のＨＦＮのミスマッチの発生を回避することが可能になる。また、Ｉｎｔｅｒ−ｅＮＢＣＡでは、受信ウィンドウの更新遅延により、パケットを破棄していない基地局から受信したパケットが受信ウィンドウの範囲外であるとしてユーザ装置において破棄される可能性を回避することが可能になる。

まず、図７を参照して、本発明の一実施例による無線通信システムを説明する。後述される実施例では、無線通信システムはＬＴＥシステム又はＬＴＥ−Ａｄｖａｎｃｅｄシステムであるが、本発明はこれに限定されるものでない。本発明は、ＬＴＥシステム又はＬＴＥ−Ａｄｖａｎｃｅｄシステムと同様のレイヤ構造を有する他の何れかの無線通信システムに適用可能である。

図７は、本発明の一実施例による無線通信システムを示す概略図である。図７に示されるように、無線通信システム１０は、ユーザ装置（ＵＥ）１００、基地局（ｅＮＢ）２０１，２０２、ネットワーク装置３００及びネットワーク４００を有する。図示された実施例では、無線通信システム１０は、基地局間キャリアアグリゲーション（Ｉｎｔｅｒ−ｅＮＢＣＡ）をサポートし、図示されるように、ユーザ装置１００は、基地局（Ｍａｓｔｅｒ−ｅＮＢ）２０１と基地局（Ｓｅｃｏｎｄａｒｙ−ｅＮＢ）２０２との間でＩｎｔｅｒ−ｅＮＢＣＡにより通信する。しかしながら、無線通信システム１０は、これに限定されるものでなく、Ｉｎｔｅｒ−ｅＮＢＣＡをサポートしないが、ＬＴＥ−Ａｄｖａｎｃｅｄシステムと同様に、図１に示されるようなレイヤ構造を有するＬＴＥシステムなどの他の何れかの無線通信システムであってもよい。

ユーザ装置１００は、典型的には、図示されるように、携帯電話、スマートフォン、タブレット、モバイルルータなどの無線通信機能を備えた何れか適切な情報処理装置であってもよい。ユーザ装置１００は、ＰＤＣＰレイヤにおいて、受信したパケットの順序を補正するための受信ウィンドウを管理する。ＬＴＥ標準仕様では、当該受信ウィンドウのサイズは、ＰＤＣＰＳＮの上限値"４０９５"の１／２である２０４７に設定される。基地局２０１，２０２から受信したパケットのＰＤＣＰＳＮがウィンドウの範囲内である場合、ユーザ装置１００は、ＰＤＣＰレイヤにおいて、現在の受信状況に基づき当該パケットの解匿処理に用いるＨＦＮを推測し、推測したＨＦＮとヘッダに付与されたＰＤＣＰＳＮとから構成されるＣＯＵＮＴ値に基づき、受信したパケットに対して解匿処理を実行する。ＰＤＣＰレイヤの処理を実行した後、ユーザ装置１００は、受信ウィンドウを更新又はシフトする。他方、基地局２０１，２０２から受信したパケットのＰＤＣＰＳＮが受信ウィンドウの範囲外である場合、ユーザ装置１００は当該パケットを破棄する。

典型的なハードウェア構成では、ユーザ装置１００は、プロセッサなどのＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）やフラッシュメモリなどのメモリ装置、基地局２０１，２０２との間で無線信号を送受信するための無線通信装置などから構成される。例えば、後述されるユーザ装置１００の各機能及び処理は、メモリ装置に格納されているデータやプログラムをＣＰＵが処理又は実行することによって実現される。

基地局２０１，２０２は、ユーザ装置１００と無線接続することによって、ネットワーク４００上に通信接続された上位局やサーバなどのネットワーク装置３００から受信したダウンリンク（ＤＬ）パケットをユーザ装置１００に送信すると共に、ユーザ装置１００から受信したアップリンク（ＵＬ）パケットをネットワーク装置３００に送信する。

ＰＤＣＰレイヤにおいて、基地局２０１，２０２は、上位レイヤから受信したＰＤＣＰＳＤＵに対して秘匿処理、改ざん検出及びヘッダ圧縮などのＰＤＣＰレイヤ処理を実行し、ＰＤＣＰＰＤＵとして生成されたＰＤＣＰパケットをＲＬＣレイヤに送出する。秘匿処理及び改ざん検出には、ＨＦＮとＰＤＣＰＳＮとから構成されるＣＯＵＮＴ値が利用される。ＰＤＣＰＳＮは、ＰＤＣＰレイヤからＲＬＣレイヤにＰＤＣＰパケットを送出する毎にインクリメントされ、"０"から"４０９５"までの範囲のＰＤＣＰＳＮが、ＰＤＣＰパケットに巡回的に付与される。また、ＨＦＮは、ＰＤＣＰＳＮが周回する毎にインクリメントされ、"０"から"１０４８５７６"までの範囲のＨＦＮがＰＤＣＰパケットに付与される。ＣＯＵＮＴ値は、上位ビットにＨＦＮを有し、下位ビットにＰＤＣＰＳＮを有するよう構成される。ＬＴＥシステムでは、ＰＤＣＰＳＮのみがＰＤＣＰパケットのヘッダに記述され、受信側のユーザ装置１００に通知される。他方、ＨＦＮはＰＤＣＰパケットに記述されず、受信側のユーザ装置１００は、受信状況とＰＤＣＰＳＮとに基づき、受信したパケットを解匿処理するためのＨＦＮを推測する必要がある。

また、基地局２０１，２０２は、ネットワーク装置３００から受信したユーザ装置１００宛てのパケットを一時的にバッファに格納する一方、所定の破棄イベントに応答してバッファに滞留するパケットを破棄する。例えば、基地局２０１，２０２のバッファにおけるＰＤＣＰ／ＲＬＣＳＤＵが閾値以上滞留した場合、基地局２０１，２０２は、ＰＤＣＰ／ＲＬＣＳＤＵをバッファから破棄する。また、リアルタイム性を必要とする音声データパケットについては、基地局２０１，２０２は、滞留時間を計時するためのタイマ（ＤｉｓｃａｒｄＴｉｍｅｒ）を利用し、当該タイマが所定時間経過すると、ＰＤＣＰ／ＲＬＣＳＤＵをバッファから破棄する。

無線通信システム１０はＩｎｔｅｒ−ｅＮＢＣＡをサポートし、図示された実施例では、基地局２０１がＭａｓｔｅｒ−ｅＮＢ（ＭｅＮＢ）として機能し、基地局２０２がＳｅｃｏｎｄａｒｙ−ｅＮＢ（ＳｅＮＢ）として機能する。すなわち、マスタ基地局２０１がユーザ装置１００との間のＩｎｔｅｒ−ｅＮＢＣＡ通信を制御し、ネットワーク装置３００から受信したユーザ装置１００宛てのパケットの一部をセカンダリ基地局２０２に分配し、マスタ基地局２０１とセカンダリ基地局２０２とを介しユーザ装置１００に送信する。この分配規則は、ネットワーク装置３００から受信したパケットのＰＤＣＰＰＤＵのＰＤＣＰＳＮに基づくものであってもよい。例えば、ＰＤＣＰＳＮが偶数であるＰＤＣＰＰＤＵは、セカンダリ基地局２０２に分配されてセカンダリ基地局２０２からユーザ装置１００に送信される一方、ＰＤＣＰＳＮが奇数であるＰＤＣＰＰＤＵは、マスタ基地局２０１からユーザ装置１００に送信されるようにしてもよい。当該分配規則は、単なる一例にすぎず、他の何れか適切な分配規則が利用されてもよい。

ネットワーク装置３００は、ネットワーク４００上のサービスプロバイダのサーバ、ユーザ装置１００及び基地局２０１，２０２を管理するための管理ノードなどである。ネットワーク装置３００は、ユーザ装置１００に提供する各種データを基地局２０１，２０２に送信する。

ネットワーク４００は、無線通信システム１０のオペレータのネットワークやインターネットなどである。基地局２０１，２０２とネットワーク装置３００とは、ネットワーク４００を介しＩＰパケットをやりとりする。

次に、図８を参照して、本発明の一実施例によるユーザ装置の構成を説明する。図８は、本発明の一実施例によるユーザ装置の構成を示すブロック図である。

図８に示されるように、ユーザ装置１００は、送受信部１１０、ＰＤＣＰレイヤ処理部１２０及び受信ウィンドウ更新判定部１３０を有する。

送受信部１１０は、基地局２０１，２０２との間でパケットを送受信する。具体的には、送受信部１１０は、送信対象のデータを基地局２０１，２０２宛ての無線信号に変換するため、符号化処理、変調処理、多重化処理などの各種無線処理を実行し、生成した無線信号を基地局２０１，２０２に送信する。また、送受信部１１０は、基地局２０１，２０２から受信した無線信号に対して逆多重化処理、復調処理、復号化処理などの各種無線処理を実行し、データを取得する。

ＰＤＣＰレイヤ処理部１２０は、基地局２０１，２０２から受信したＰＤＣＰパケットに対して当該ＰＤＣＰパケットのシーケンス番号（ＰＤＣＰＳＮ）が受信ウィンドウの範囲内であるか判断し、受信ウィンドウの範囲内のシーケンス番号を有するＰＤＣＰパケットに対してＰＤＣＰレイヤの処理を実行する。ＰＤＣＰレイヤ処理部１２０は、ＰＤＣＰレイヤにおいて、受信したパケットの順序を補正するための受信ウィンドウを管理する。ＬＴＥ標準仕様では、当該受信ウィンドウのサイズは、ＰＤＣＰＳＮの上限値"４０９５"の１／２である２０４７に設定される。基地局２０１，２０２から受信したパケットのＰＤＣＰＳＮが受信ウィンドウの範囲内である場合、ＰＤＣＰレイヤ処理部１２０は、ＰＤＣＰレイヤにおいて、現在の受信状況に基づき当該パケットの解匿処理に用いるＨＦＮを推測し、推測したＨＦＮとヘッダに付与されたＰＤＣＰＳＮとから構成されるＣＯＵＮＴ値に基づき、受信したパケットに対して解匿処理を実行する。ＰＤＣＰレイヤの処理を実行した後、ＰＤＣＰレイヤ処理部１２０は、当該ＰＤＣＰＳＮにより受信ウィンドウを更新又はシフトする。他方、基地局２０１，２０２から受信したパケットのＰＤＣＰＳＮが受信ウィンドウの範囲外である場合、ＰＤＣＰレイヤ処理部１２０は当該パケットを破棄する。

受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信したパケットが受信ウィンドウを更新させるための所定の更新トリガパケットであるか判定し、受信したパケットが更新トリガパケットである場合、ＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。このような更新トリガパケットとして、後述するような特殊なＰＤＣＰＰＤＵが規定されてもよいし、又はＲＲＣシグナリングにより受信ウィンドウを更新させるためのＲＲＣメッセージが利用されてもよい。

一実施例では、更新トリガパケットは、ヘッダ部分のみを有するＰＤＣＰパケットであってもよい。すなわち、当該ＰＤＣＰパケットは、ペイロード部分を有さず、ヘッダ部分のみからなる特殊なＰＤＣＰパケットとして構成される。更新トリガパケットとしてこのような特殊なＰＤＣＰパケットが利用される場合、受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信したＰＤＣＰパケットのサイズがＰＤＣＰヘッダサイズに等しいか判定し、受信したＰＤＣＰパケットのサイズがＰＤＣＰヘッダサイズに等しい場合、ＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。すなわち、当該更新トリガパケットはペイロード部分を有さず、ヘッダ部分のみから構成されるため、当該パケットのサイズは通常のＰＤＣＰパケットのヘッダサイズに等しくなる。このため、受信ウィンドウ更新判定部１３０は、受信したＰＤＣＰパケットのサイズが通常のＰＤＣＰパケットのヘッダサイズに等しいと判定すると、受信したＰＤＣＰパケットを更新トリガパケットと判定することができる。受信したＰＤＣＰパケットが更新トリガパケットであると判定すると、受信ウィンドウ更新判定部１３０は、当該ＰＤＣＰパケットのヘッダ部分からＰＤＣＰＳＮを抽出し、抽出したＰＤＣＰＳＮにより受信ウィンドウを更新するようＰＤＣＰレイヤ処理部１２０に指示する。本実施例によると、現状のＰＤＣＰ制御を大きく変更することなく受信ウィンドウを適宜更新することが可能になり、基地局２０１，２０２においてパケットが連続的に破棄されても、ユーザ装置１００と基地局２０１，２０２との間のＨＦＮのミスマッチを回避することが可能になる。

一実施例では、更新トリガパケットは、受信ウィンドウを更新させるための所定の更新トリガパケットであることを示すビットを含むヘッダ部分を有するＰＤＣＰデータパケットであってもよい。すなわち、ＰＤＣＰデータパケットのヘッダ部分に、受信ウィンドウを更新させるための所定の更新トリガパケットであることを示す所定のビットが設けられる。例えば、ＰＤＣＰデータパケットが更新トリガパケットである場合、基地局２０１，２０２において当該ビットが「１」に設定され、ＰＤＣＰデータパケットが更新トリガパケットでない場合、基地局２０１，２０２において当該ビットが「０」に設定されるようにしてもよい。更新トリガパケットとしてこのようなＰＤＣＰデータパケットが利用される場合、受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信したＰＤＣＰデータパケットのヘッダ部分の所定のビットが更新トリガパケットであることを示しているか判定し、当該ビットが更新トリガパケットであることを示す場合、ＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。すなわち、受信ウィンドウ更新判定部１３０は、Ｕ−ｐｌａｎｅにおいて受信したＰＤＣＰデータパケットのヘッダ部分の所定のビットを判定することによって、受信したＰＤＣＰデータパケットが更新トリガパケットであるか判定することができる。受信したＰＤＣＰデータパケットが更新トリガパケットであると判定すると、受信ウィンドウ更新判定部１３０は、当該ＰＤＣＰデータパケットのヘッダ部分からＰＤＣＰＳＮを抽出し、抽出したＰＤＣＰＳＮにより受信ウィンドウを更新するようＰＤＣＰレイヤ処理部１２０に指示する。本実施例によると、現状のＰＤＣＰ制御を大きく変更することなく受信ウィンドウを適宜更新することが可能になり、基地局２０１，２０２においてパケットが連続的に破棄されても、ユーザ装置１００と基地局２０１，２０２との間のＨＦＮのミスマッチを回避することが可能になる。

上述したヘッダ部分のみを有するＰＤＣＰパケットや更新トリガパケットであることを示す所定のビットを備えたＰＤＣＰデータパケットは、他のＰＤＣＰパケットよりも高い優先度によりユーザ装置１００に送信されるようにしてもよい。これにより、より確実にユーザ装置１００に受信ウィンドウを更新させることが可能になる。

一実施例では、更新トリガパケットは、ＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を含むＰＤＣＰ制御パケットであってもよい。すなわち、当該ＰＤＣＰ制御パケットは、Ｃ−ｐｌａｎｅにおいて、更新後の受信ウィンドウを通知するためのものである。更新トリガパケットとしてこのようなＰＤＣＰ制御パケットが利用される場合、受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信した当該ＰＤＣＰ制御パケットにおいてＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を検出すると、検出した上端又は下端の値によってＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。本実施例によると、パケットを破棄した基地局２０１，２０２により適切に指定されたＰＤＣＰＳＮにより受信ウィンドウを更新することが可能になり、基地局２０１，２０２においてパケットが連続的に破棄されても、ユーザ装置１００と基地局２０１，２０２との間のＨＦＮのミスマッチを回避することが可能になる。

一実施例では、更新トリガパケットは、基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を含むＰＤＣＰ制御パケットであってもよい。ここで、破棄情報とは、送信側である基地局２０１，２０２のＰＤＣＰエンティティにより破棄されたＰＤＣＰパケットに関する情報であり、例えば、破棄されたＰＤＣＰパケットの個数、シーケンス番号及び／又はＣＯＵＮＴ値を含むものであってもよい。なお、当該破棄情報は、既存のＰＤＣＰＳｔａｔｕｓＲｅｐｏｒｔにより通知されてもよい。受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信したＰＤＣＰ制御パケットにおいて基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を検出した場合、検出した破棄情報に基づきＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。例えば、検出した破棄情報が、基地局２０１において連続してＸ個のＰＤＣＰパケットが破棄されることを示す場合、ＰＤＣＰレイヤ処理部１２０は、基地局２０１から直近に受信したＰＤＣＰパケットから以降のＸ個のＰＤＣＰパケットを待機することなく、基地局２０２から受信したＰＤＣＰパケットのシーケンス番号に従って受信ウィンドウを更新することができる。本実施例によると、基地局２０１，２０２におけるパケットの破棄による受信ウィンドウの更新遅延を回避することができ、更新遅延によって受信ウィンドウの範囲外であると判定されることによるユーザ装置１００における受信ＰＤＣＰパケットの破棄を回避することが可能になる。

ユーザ装置１００が上述した各種更新トリガパケットをサポートしているということは、Ｃａｐａｂｉｌｉｔｙにより基地局２０１，２０２に明示的に通知されてもよいし、あるいは、ユーザ装置１００がサポートしている更新トリガパケットを基地局２０１，２０２に送信することによって、基地局２０１，２０２に暗示的に通知されてもよい。すなわち、送受信部１１０は、ユーザ装置１００が更新トリガパケットにより受信ウィンドウを更新可能であることを通知するため、Ｃａｐａｂｉｌｉｔｙによって基地局２０１，２０２に通知するか、又は更新トリガパケットを送信することによって基地局２０１，２０２に通知するようにしてもよい。

なお、ユーザ装置１００が更新トリガパケットをサポートしているということをＣａｐａｂｉｌｉｔｙにより基地局２０１，２０２に明示的に通知する場合、送受信部１１０は、ＲＬＣＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）とＲＬＣＵＭ（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）との各モードについて、当該Ｃａｐａｂｉｌｉｔｙを基地局２０１，２０２に通知してもよい。ここで、ＲＬＣＵＭベアラについては、現状ではＰＤＣＰレイヤにおけるＲｅｏｒｄｅｒｉｎｇ処理が規定されていない。このため、ＲＬＣＵＭのベアラは、ＰＤＣＰレイヤにおいて順序補正機能を有するようにしてもよい。

一実施例では、更新トリガパケットは、ＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を含むＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）メッセージであってもよい。すなわち、当該ＲＲＣメッセージは、Ｃ−ｐｌａｎｅにおいて、更新後の受信ウィンドウを通知するためのものである。更新トリガパケットとしてこのようなＲＲＣメッセージが利用される場合、受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信したＲＲＣメッセージにおいてＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を検出すると、検出した上端又は下端の値によってＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。本実施例によると、パケットを破棄した基地局２０１，２０２により適切に指定されたＰＤＣＰＳＮにより受信ウィンドウを更新することが可能になり、基地局２０１，２０２においてパケットが連続的に破棄されても、ユーザ装置１００と基地局２０１，２０２との間のＨＦＮのミスマッチを回避することが可能になる。

一実施例では、更新トリガパケットは、基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を含むＲＲＣメッセージであってもよい。ここで、破棄情報とは、送信側である基地局２０１，２０２のＰＤＣＰエンティティにより破棄されたＰＤＣＰパケットに関する情報であり、例えば、破棄されたＰＤＣＰパケットの個数、シーケンス番号及び／又はＣＯＵＮＴ値を含むものであってもよい。なお、当該破棄情報は、既存のＰＤＣＰＳｔａｔｕｓＲｅｐｏｒｔのフォーマットを利用して通知されてもよい。受信ウィンドウ更新判定部１３０は、基地局２０１，２０２から受信したＲＲＣメッセージにおいて基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を検出した場合、検出した破棄情報に基づきＰＤＣＰレイヤ処理部１２０に受信ウィンドウを更新させる。本実施例によると、基地局２０１，２０２におけるパケットの破棄による受信ウィンドウの更新遅延を回避することができ、更新遅延によって受信ウィンドウの範囲外であると判定されることによるユーザ装置１００における受信ＰＤＣＰパケットの破棄を回避することが可能になる。

上述したＲＲＣシグナリングによる更新トリガパケットの送信は、セル内ハンドオーバを伴うようにしてもよい。この場合、Ｕ−ｐｌａｎｅ伝送が一旦停止されるため、他のＰＤＣＰパケットが不要に割り込み、当該ＲＲＣメッセージが受信ウィンドウの範囲外になって破棄されるという事態を回避することが可能になる。

次に、図９を参照して、本発明の一実施例によるユーザ装置における受信ウィンドウ更新処理を説明する。図９は、本発明の一実施例によるユーザ装置における受信ウィンドウ更新処理を示すフロー図である。

当該処理は、ユーザ装置１００による基地局２０１，２０２からのＰＤＣＰパケットの受信中に開始される。当該受信処理において、ユーザ装置１００は、基地局２０１，２０２から受信したＰＤＣＰパケットに対して、当該ＰＤＣＰパケットのシーケンス番号が受信ウィンドウの範囲内であるか判断し、受信ウィンドウの範囲内のシーケンス番号を有するＰＤＣＰパケットに対してＰＤＣＰレイヤの処理を実行し、受信ウィンドウを更新している。

図９に示されるように、ステップＳ１０１において、ユーザ装置１００は、基地局２０１，２０２から受信したパケットが受信ウィンドウを更新させるための所定の更新トリガパケットであるか判定する。更新トリガパケットとして、例えば、ヘッダ部分のみを有するＰＤＣＰパケット、更新トリガパケットであることを示すビットを含むヘッダ部分を有するＰＤＣＰデータパケット、ＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を含むＰＤＣＰ制御パケット、基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を含むＰＤＣＰ制御パケット、ＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を含むＲＲＣメッセージ、又は基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を含むＲＲＣメッセージが利用されてもよい。ユーザ装置１００は、受信したパケットが上述した更新トリガパケットの何れかである場合、当該パケットを更新トリガパケットであると判定する。なお、ユーザ装置１００は、Ｃａｐａｂｉｌｉｔｙにより予め通知することによって、又はサポートする更新トリガパケットを予め送信することによって、ユーザ装置１００が上述した何れの更新トリガパケットをサポートしているか基地局２０１，２０２に通知してもよい。

ステップＳ１０２において、ユーザ装置１００は、受信したパケットが更新トリガパケットである場合、受信ウィンドウを更新する。例えば、更新トリガパケットがヘッダ部分のみを有するＰＤＣＰパケット又は更新トリガパケットであることを示すビットを含むヘッダ部分を有するＰＤＣＰデータパケットである場合、ユーザ装置１００は、当該パケットのシーケンス番号により受信ウィンドウを更新してもよい。あるいは、更新トリガパケットがＰＤＣＰレイヤ処理部１２０によって設定されるべき受信ウィンドウの上端又は下端の値を含むＰＤＣＰ制御パケット又はＲＲＣメッセージである場合、ユーザ装置１００は、当該上端又は下端の値により受信ウィンドウを更新してもよい。あるいは、更新トリガパケットが基地局２０１，２０２により破棄されたＰＤＣＰパケットに関する破棄情報を含むＰＤＣＰ制御パケット又はＲＲＣメッセージである場合、ユーザ装置１００は、破棄情報に基づき受信ウィンドウを更新してもよい。

なお、上述した実施例では各種の更新トリガパケットが説明されたが、これらの何れか２つ以上が利用されてもよい。

以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０無線通信システム
１００ユーザ装置
１１０送受信部
１２０ＰＤＣＰレイヤ処理部
１３０受信ウィンドウ更新判定部
２０１，２０２基地局

Claims

基地局との間でパケットを送受信する送受信部と、
前記基地局から受信したＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）パケットに対して前記ＰＤＣＰパケットのシーケンス番号が受信ウィンドウの範囲内であるか判断し、前記受信ウィンドウの範囲内のシーケンス番号を有するＰＤＣＰパケットに対してＰＤＣＰレイヤの処理を実行するＰＤＣＰレイヤ処理部と、
前記基地局から受信したパケットが前記受信ウィンドウを更新させるための所定の更新トリガパケットであるか判定し、前記受信したパケットが前記更新トリガパケットである場合、前記ＰＤＣＰレイヤ処理部に前記受信ウィンドウを更新させる受信ウィンドウ更新判定部と、
を有するユーザ装置であって、
前記更新トリガパケットは、ヘッダ部分のみを有するＰＤＣＰパケットであり、
前記受信ウィンドウ更新判定部は、前記基地局から受信したＰＤＣＰパケットのサイズがＰＤＣＰヘッダサイズに等しいか判定し、前記受信したＰＤＣＰパケットのサイズが前記ＰＤＣＰヘッダサイズに等しい場合、前記ＰＤＣＰレイヤ処理部に前記受信ウィンドウを更新させるユーザ装置。
前記送受信部は、当該ユーザ装置が前記更新トリガパケットにより前記受信ウィンドウを更新可能であることを通知するため、Ｃａｐａｂｉｌｉｔｙによって前記基地局に通知するか、又は前記更新トリガパケットを送信することによって前記基地局に通知する、請求項１記載のユーザ装置。
前記送受信部は、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）ＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）とＲＬＣＵＭ（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）との各モードについて、前記Ｃａｐａｂｉｌｉｔｙを前記基地局に通知する、請求項２記載のユーザ装置。
前記ＲＬＣＵＭのベアラは、前記ＰＤＣＰレイヤにおいて順序補正機能を有する、請求項３記載のユーザ装置。
ユーザ装置に受信ウィンドウを更新させるための方法であって、
前記ユーザ装置は、基地局から受信したＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）パケットに対して前記ＰＤＣＰパケットのシーケンス番号が受信ウィンドウの範囲内であるか判断し、前記受信ウィンドウの範囲内のシーケンス番号を有するＰＤＣＰパケットに対してＰＤＣＰレイヤの処理を実行し、
当該方法は、
前記基地局から受信したパケットが前記受信ウィンドウを更新させるための所定の更新トリガパケットであるか判定するステップと、
前記受信したパケットが前記更新トリガパケットである場合、前記受信ウィンドウを更新するステップと、
を有する方法であって、
前記更新トリガパケットは、ヘッダ部分のみを有するＰＤＣＰパケットであり、
前記判定するステップは、前記基地局から受信したＰＤＣＰパケットのサイズがＰＤＣＰヘッダサイズに等しいか判定し、
前記更新するステップは、前記受信したＰＤＣＰパケットのサイズが前記ＰＤＣＰヘッダサイズに等しい場合、前記受信ウィンドウを更新する方法。