JP2016092700A - ユーザ装置、及び重複パケット処理方法 - Google Patents

Abstract

【課題】１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおいて、ユーザ装置が重複パケットを受信した場合に、その後のパケット伸張処理を考慮して、当該重複パケットの処理を適切に行う。【解決手段】前記ユーザ装置において、前記複数の基地局から前記ベアラのパケットを順次受信する受信部と、前記受信部により受信したパケットから、あるパケットと重複する重複パケットを検出した場合に、前記ユーザ装置において、ヘッダ圧縮伸張プロトコルを含む所定のパケット通信プロトコルの再設定が行われているかどうかを判定し、当該所定のパケット通信プロトコルの再設定が行われていない場合に、前記重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する重複パケット処理部とを備える。【選択図】図１４

Description

本発明は、ユーザ装置が複数の基地局と通信を行うように構成される移動通信システムに関連するものである。

ＬＴＥシステムでは、所定の帯域幅（最大２０ＭＨｚ）を基本単位として、複数のキャリアを同時に用いて通信を行うキャリアアグリゲーション（ＣＡ：Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ）が採用されている。キャリアアグリゲーションにおいて基本単位となるキャリアはコンポーネントキャリア（ＣＣ：Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ）と呼ばれる。

ＣＡが行われる際には、ユーザ装置ＵＥに対して、接続性を担保する信頼性の高いセルであるＰＣｅｌｌ（Ｐｒｉｍａｒｙ ｃｅｌｌ）及び付随的なセルであるＳＣｅｌｌ（Ｓｅｃｏｎｄａｒｙ ｃｅｌｌ）が設定される。ユーザ装置ＵＥは、第１に、ＰＣｅｌｌに接続し、必要に応じて、ＳＣｅｌｌを追加することができる。ＰＣｅｌｌは、ＲＬＭ（Ｒａｄｉｏ Ｌｉｎｋ Ｍｏｎｉｔｏｒｉｎｇ）及びＳＰＳ（Ｓｅｍｉ-Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）等をサポートする単独のセルと同様のセルである。

ＳＣｅｌｌは、ＰＣｅｌｌに追加されてユーザ装置ＵＥに対して設定されるセルである。ＳＣｅｌｌの追加及び削除は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングによって行われる。ＳＣｅｌｌは、ユーザ装置ＵＥに対して設定された直後は、非アクティブ状態（ｄｅａｃｔｉｖａｔｅ状態）であるため、アクティブ化することで初めて通信可能（スケジューリング可能）となるセルである。

図１に示すように、ＬＴＥのＲｅｌ−１０までのＣＡでは、同一基地局ｅＮＢ配下の複数のＣＣを用いている。

一方、Ｒｅｌ−１２ではこれを拡張し、異なる基地局ｅＮＢ配下のＣＣを用いて同時通信を行い、高スループットを実現するＤｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ（二重接続）が提案されている（非特許文献１）。つまり、Ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙでは、ＵＥは、２つの物理的に異なる基地局ｅＮＢの無線リソースを同時に使用して通信を行う。

Ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙは、ＣＡの一種であり、Ｉｎｔｅｒ ｅＮＢ ＣＡ（基地局間キャリアアグリゲーション）とも呼ばれ、Ｍａｓｔｅｒ−ｅＮＢ（ＭｅＮＢ）と、Ｓｅｃｏｎｄａｒｙ−ｅＮＢ（ＳｅＮＢ）が導入される。図２に、Ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙの例を示す。図２の例では、ＭｅＮＢがＣＣ＃１でユーザ装置ＵＥと通信を行い、ＳｅＮＢがＣＣ＃２でユーザ装置ＵＥと通信を行うことでＤｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ（以下、ＤＣ）を実現している。

ＤＣにおいて、ＭｅＮＢ配下のセル（１つ又は複数）で構成されるセルグループをＭＣＧ（Ｍａｓｔｅｒ Ｃｅｌｌ Ｇｒｏｕｐ、マスターセルグループ）、ＳｅＮＢ配下のセル（１つ又は複数）で構成されるセルグループをＳＣＧ（Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ Ｇｒｏｕｐ、セカンダリセルグループ）と呼ぶ。ＳＣＧのうちの少なくとも１つのＳＣｅｌｌにはＵＬのＣＣが設定され、そのうちの１つにＰＵＣＣＨが設定される。このＳＣｅｌｌをＰＳＣｅｌｌ（ｐｒｉｍａｒｙ ＳＣｅｌｌ）と呼ぶ。

このようなＤＣにおける通信形態の１つとして、１つのベアラ（パケットの通信路）を複数ｅＮＢに分配するスプリットベアラ（Ｓｐｌｉｔ Ｂｅａｒｅｒ）がある。基地局ＭｅＮＢがベアラを分配するアンカーノードとして利用される場合、図３に示されるように、基地局ＭｅＮＢは、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）から受信したダウンリンクパケットを、ＭＣＧを介しユーザ装置ＵＥに送信するパケットと、ＳＣＧ（基地局ＳｅＮＢ）を経由してユーザ装置ＵＥに送信するパケットとに分配する。基地局ＭｅＮＢをアンカーノードとしたスプリットベアラが設定される場合、図４に示されるように、ユーザ装置ＵＥは、基地局ＭｅＮＢのための物理レイヤ（ＰＨＹ）、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ（ｍ−ＭＡＣ）及びＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ（ｍ−ＲＬＣ）と、基地局ＳｅＮＢのためのＰＨＹレイヤ、ｓ−ＭＡＣレイヤ及びｓ−ＲＬＣレイヤと、ｍ−ＲＬＣレイヤ及びｓ−ＲＬＣレイヤに接続されるＰＤＣＰレイヤとを有する。

ところで、ＬＴＥシステムでは、通常ＲＬＣレイヤで順序を保った送信（ｉｎ−ｓｅｑｕｅｎｃｅ ｄｅｌｉｖｅｒ）が担保されるが、ＲＬＣレイヤでｉｎ−ｓｅｑｕｅｎｃｅ ｄｅｌｉｖｅｒｙが担保できないケース（ハンドオーバ（ＨＯ）、再接続時等）では、ＰＤＣＰレイヤで重複検出やｒｅｏｒｄｅｒｉｎｇ処理を行っている。スプリットベアラの場合も基本的な処理は同様であり、図４には、例として、ＰＤＣＰレイヤにおけるリオーダリング処理が示されている。

ＰＤＣＰレイヤの動作について概要を説明すると、送信側では、ＰＤＣＰエンティティが、上位レイヤから受信したパケット、すなわち、ＰＤＣＰ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）に対して、秘匿処理、改ざん検出及びヘッダ圧縮を実行し、ＰＤＣＰ ＳＮをヘッダに付与してＰＤＣＰ ＰＤＵ（Ｐａｃｋｅｔ Ｄａｔａ Ｕｎｉｔ）としてＲＬＣレイヤに送出する。一方、受信側（例としてＲＬＣ−ＡＭを想定）では受信ｗｉｎｄｏｗ（ウィンドウ）を管理し、送信側から受信したパケットのＰＤＣＰ ＳＮが受信ウィンドウの範囲内である場合、推定したＨＦＮとヘッダのＰＤＣＰ ＳＮとから構成されるＣＯＵＮＴ値に基づき受信したパケットのペイロード（ＰＤＣＰ ＳＤＵ）に対して解匿処理（秘匿解除処理）を実行する。その後、ＰＤＣＰエンティティは、処理後のパケットを上位レイヤに送出し、受信ウィンドウを更新する。

リオーダリングを実施する時には、ＰＤＣＰエンティティはリオーダリングタイマ（ｒｅｏｒｄｅｒｉｎｇ ｔｉｍｅｒ）を用いる。ユーザ装置ＵＥは、抜けを検知した時点で、リオーダリングタイマを起動し、当該タイマ起動中は後続のＰＤＣＰ ＰＤＵの処理を中断（ｓｕｓｐｅｎｄ）し、タイマ満了までに抜けパケットの受信ができない場合は、当該パケットの受信を諦め、処理を再開する。

３ＧＰＰ ＴＲ ３６．８４２ Ｖ１２．０．０ （２０１３−１２） ３ＧＰＰ ＴＳ ３６．３２３ Ｖ１２．１．０ （２０１４−０９） ３ＧＰＰ ＴＳＧ−ＲＡＮ ＷＧ２ ＃８７，Ｒ２−１４３４１７

次に、ＰＤＣＰレイヤでの重複検出に関して説明する。ＲＬＣレイヤにおける重複検出においては、単に重複部分を破棄するだけであるが、ＰＤＣＰレイヤにおいては重複パケットを一旦処理し、その後破棄を行っている（非特許文献２）。

上記の「処理」とは、パケットの秘匿解除、及びＲＯＨＣ（ＲＯｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）伸張処理（ｄｅｃｏｍｐｒｅｓｓｉｏｎ）である。重複パケットを一旦処理する理由について説明する前に、ＲＯＨＣの概要について説明する。

ＲＯＨＣは、ＬＴＥのＰＤＣＰレイヤで使用されるヘッダ圧縮技術であり、ＲＴＰ／ＵＤＰ／ＩＰヘッダフィールドの内で、パケット間で変化のある部分のみを送信することで、実際に無線で送信するビット数を低減することを可能としている。

例えば、変化しないフィールド（Ｓｔａｔｉｃ ｐａｒｔ）として、ＳＳＲＣ（ＲＴＰレイヤの識別子）、ＩＰアドレス等があり、変化するフィールド（ｄｙｎａｍｉｃ ｐａｒｔ）として、ＲＴＰ ｔｉｍｅｓｔａｍｐやＲＴＰ−Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ、ＵＤＰ ｃｈｅｃｋｓｕｍ等がある。図５に示すように、ほぼ変化しないフィールドを圧縮することで、ヘッダのビット数を大幅に削減することができる。

ＲＯＨＣによるヘッダ圧縮／復元を実行する装置は、各ＲＴＰセッション（パケットストリーム）のコンテクストを記憶し、当該コンテクストに基づいてパケットのヘッダを圧縮／復元する。コンテクストに含まれる情報は、例えば上記Ｓｔａｔｉｃ ｐａｒｔの情報である。コンテクストは、コンテクストＩＤ（ＣＩＤ）で識別される。

ＲＯＨＣが行われる場合のヘッダ圧縮を行う側（例：下りでの基地局ｅＮＢ）をＣｏｍｐｒｅｓｓｏｒと呼び、圧縮されたヘッダを復元する側（例：下りでのユーザ装置ＵＥ）をＤｅｃｏｍｐｒｅｓｓｏｒと呼ぶ。

ＲＯＨＣでは、上記の圧縮／復元を可能とするために、まずはＣｏｍｐｒｅｓｓｏｒからＤｅｃｏｍｐｒｅｓｓｏｒに対して、圧縮していないヘッダの全ての情報を送信する初期化／リフレッシュ処理が行われる。この状態のときに送信されるＲＯＨＣパケットをＩＲパケットと呼ぶ。ＩＲパケットにより初期化／リフレッシュ処理が行われ、コンテクストが確立された後に、圧縮／復元を行う状態に移行するのである。

また、ＲＯＨＣでは、ＩＲパケット以外にも、ＩＲ−ＤＹＮパケット、パケットタイプ０、パケットタイプ１、パケットタイプ２等が規定されており、当該パケットによりコンテクストの一部やプロファイル等の更新を行うことができる。ＲＯＨＣにおけるコンテクスト、コンテクストＩＤ、プロファイル等、ヘッダ圧縮／復元処理を行うために必要な情報を総称してＲＯＨＣ情報と呼ぶことにする。

さて、ＰＤＣＰレイヤにおいて重複パケットを一旦処理する理由は、同一ＰＤＣＰ ＳＤＵであっても、ＨＯ前後では、ＰＤＣＰ ＳＤＵに関連付いているＲＯＨＣ情報が異なるためである。すなわち、ＨＯ後のｅＮＢとの通信においては、ＨＯ後のｅＮＢとの間で確立されるＲＯＨＣ情報を用いるべきであり、当該ＲＯＨＣ情報を取得するために、重複パケットを一旦処理するのである。このことを図６の例を参照して説明する。

図６は、Ｓ−ｅＮＢ（Ｓｏｕｒｃｅ−ｅＮＢ）からＴ−ｅＮＢ（Ｔａｒｇｅｔ−ｅＮＢ）へＨＯする場合の例を示している。ＨＯ手順が起動された状態において、Ｓ−ｅＮＢは、ＲＯＨＣ情報Ａを用いて圧縮を行ったＳＮ＝Ｘのパケット（ＰＤＣＰ ＰＤＵ）をユーザ装置ＵＥに送信する（ステップ１）。ユーザ装置ＵＥは当該パケットを受信するが、ＨＯが起動中であるため、Ｓ−ｅＮＢはＡＣＫを受信しない（ステップ２）。Ｓ−ｅＮＢはＡＣＫを受信していない当該パケットの情報をＴ−ｅＮＢに転送する（ステップ３）。

Ｔ−ｅＮＢは、当該情報に関してＲＯＨＣ情報Ｂを用いて圧縮を行い、ＳＮ＝Ｘを付したパケットをユーザ装置ＵＥに送信する（ステップ４）。ユーザ装置ＵＥは、ＳＮ＝ＸのパケットをＴ−ｅＮＢから受信するが、既にＳ−ｅＮＢからＳＮ＝Ｘのパケットを受信しているため、Ｔ−ｅＮＢから受信したＳＮ＝Ｘのパケットは重複パケットであると判断する。ただし、Ｔ−ｅＮＢから受信したＳＮ＝Ｘのパケットをそのまま破棄してしまうと、Ｔ−ｅＮＢとの間でヘッダ圧縮／復元に使用されるＲＯＨＣ情報（初期化情報、更新情報等）を取得できず、Ｔ−ｅＮＢとの間でヘッダ圧縮／復元のためのコンテクストを確立するまでに遅延が生じる可能性がある。そのため、重複パケットをそのまま破棄せず、一旦処理（秘匿解除、ＲＯＨＣ伸張処理）してから、破棄を行う（ステップ５）。ＲＯＨＣ伸張処理には、例えば、ＲＯＨＣ情報の更新処理が含まれ、ここでの処理により、ＲＯＨＣ情報Ｂを取得できる。

なお、ＨＯや再接続時、ＰＤＣＰエンティティでは、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＰＤＣＰ再設定）が行われる（非特許文献２の「５．２ Ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ ｐｒｏｃｅｄｕｒｅ」）。つまり、上記のような重複検出処理は、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを行う場合に実施される。

しかし、スプリットベアラが設定されている場合、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施しない場合においても重複検出が発生し得る。例えば、リオーダリングタイマ満了前に抜けたパケット（ＰＤＣＰ ＰＤＵ）を受信できなかったが、その後、抜けていたパケットが受信されたケースが該当する。

このケースにおいて、ユーザ装置ＵＥは、ＰＤＣＰレイヤにおいて従来通りにＲＯＨＣ処理＝＞破棄を行うと、過去のＲＯＨＣ情報（リオーダリングタイマ満了後に到来したＰＤＣＰ ＰＤＵが保持する情報）を取得してしまうため、誤った情報でＲＯＨＣ情報の更新を行い、その後適切な伸張処理を行うことができない等の問題がある。

本発明は上記の点に鑑みてなされたものであり、１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおいて、ユーザ装置が重複パケットを受信した場合に、その後のパケット伸張処理を考慮して、当該重複パケットの処理を適切に行うことを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおける前記ユーザ装置であって、
前記複数の基地局から前記ベアラのパケットを順次受信する受信部と、
前記受信部により受信したパケットから、あるパケットと重複する重複パケットを検出した場合に、前記ユーザ装置において、ヘッダ圧縮伸張プロトコルを含む所定のパケット通信プロトコルの再設定が行われているかどうかを判定し、当該所定のパケット通信プロトコルの再設定が行われていない場合に、前記重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する重複パケット処理部とを備えるユーザ装置が提供される。

また、本発明の実施の形態によれば、１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおける前記ユーザ装置が実行する重複パケット処理方法であって、
前記複数の基地局から前記ベアラのパケットを順次受信する受信ステップと、
前記受信ステップにより受信したパケットから、あるパケットと重複する重複パケットを検出した場合に、前記ユーザ装置において、ヘッダ圧縮伸張プロトコルを含む所定のパケット通信プロトコルの再設定が行われているかどうかを判定し、当該所定のパケット通信プロトコルの再設定が行われていない場合に、前記重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する重複パケット処理ステップとを備える重複パケット処理方法が提供される。

本発明の実施の形態によれば、１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおいて、ユーザ装置が重複パケットを受信した場合に、その後のパケット伸張処理を考慮して、当該重複パケットの処理を適切に行うことを可能とする技術が提供される。

Ｒｅｌ−１０までのＣＡを示す図である。 Ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙの例を示す図である。 基地局ＭｅＮＢをアンカーノードとするスプリットベアラを説明するための図である。 スプリットベアラにおけるプロトコル構成を示す図である。 ＲＯＨＣを説明するための図である。 ハンドオーバ時の処理例を説明するための図である。 本発明の実施の形態における通信システムの構成図である。 パケットの流れの例を示す図である。 重複検出時における処理の例を説明するための図である。 ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施される場合の例を説明するための図である。 構成変更の手順例を示す図である。 ＳｅＮＢ変更（ハンドオーバ）の手順例を示す図である。 ユーザ装置ＵＥの構成図である。 ユーザ装置ＵＥの動作例を示すフローチャートである。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、以下では、ヘッダ圧縮プロトコルとしてＲＯＨＣを用いるが、これは例であり、他のヘッダ圧縮プロトコルを用いてもよい。また、本実施の形態では、ＬＴＥの移動通信システムを対象とするが、本発明はＬＴＥに限らず他の移動通信システムにも適用可能である。また、本明細書及び特許請求の範囲では、特に断らない限り、「ＬＴＥ」の用語は３ＧＰＰのＲｅｌ−１２、もしくは、Ｒｅｌ−１２以降の方式の意味で使用する。

（システム全体構成）
図７は、本発明の実施の形態における通信システムの構成例を示す図である。図７に示すように、当該通信システムは、Ｓ−ＧＷ１０とＳ１インターフェースで通信を行う基地局ＭｅＮＢと、基地局ＳｅＮＢとを含み、ユーザ装置ＵＥとの間でＤＣを実行することを可能としている。基地局ＭｅＮＢと基地局ＳｅＮＢとの間は、Ｘ２インターフェースにより通信可能であり、基地局ＭｅＮＢにおいてベアラのパケットが分配（ｓｐｌｉｔ）されることで、スプリットベアラが実現される。以下、記述を簡潔にするために、基地局ＭｅＮＢ、基地局ＳｅＮＢはそれぞれ、ＭｅＮＢ、ＳｅＮＢと記述する。

図７に示す通信システムにおいて、例えば、ＭＣＧをマクロセルとし、ＳＣＧをスモールセルとして、ＰＣｅｌｌ、ＳＣｅｌｌ（ＰＳＣｅｌｌを含む）の設定を行うことができる。ユーザ装置ＵＥにおけるＳＣＧ追加、スプリットベアラ設定、ＳＣＧ ｃｈａｎｇｅ、ｉｎｔｒａ−ＭｅＮＢ ＨＯ等は、ＭｅＮＢからのＲＲＣシグナリングで行うこととするが、これに限られるわけではない。

（動作例１）
図８、図９を参照して、本実施の形態における動作例１を説明する。図８に示す例において、ＭｅＮＢとＳｅＮＢによるＤＣがユーザ装置ＵＥに設定（ｃｏｎｆｉｇｕｒｅ）されているとともに、ＭｅＮＢからユーザ装置ＵＥへのパス、及びＳｅＮＢからユーザ装置ＵＥへのパスを用いたスプリットベアラがユーザ装置ＵＥに設定されている。

図８のステップ１０１において、ＭｅＮＢからユーザ装置ＵＥにＳＮ＝０のパケット（ＰＤＣＰ ＰＤＵ、以下同様）が送信される。ステップ１０２において、ＳＮ＝１のパケットがＭｅＮＢからＳｅＮＢに転送される。ただし、何等かの事情（例：ＳｅＮＢとＵＥ間の無線品質悪化）により、ＳｅＮＢにおいてＳＮ＝１のパケットのユーザ装置ＵＥへの送信のためのスケジューリングに遅延が発生しており、ＳＮ＝１のパケットはすぐにはユーザ装置ＵＥに送信されない。

ＳＮ＝１のパケットがＳｅＮＢからユーザ装置ＵＥに送信される前に、ＳＮ＝２のパケットがＭｅＮＢからユーザ装置ＵＥに送信される（ステップ１０３）。ユーザ装置ＵＥは、ＳＮ＝０のパケット受信後、ＳＮ＝１のパケットを受信する前にＳＮ＝２のパケットを受信することで、ＳＮ＝１のパケットの抜けを検知し、リオーダリングタイマを起動する。

図８の例では、ユーザ装置ＵＥは、リオーダリングタイマの満了前に、ＭｅＮＢからＳＮ＝３のパケットを受信するが（ステップ１０４）、抜けているＳＮ＝１のパケットを受信しない。

ユーザ装置ＵＥは、リオーダリングタイマの満了により、ＳＮ＝１のパケットの受信を諦め、中断していたパケットの処理を再開する。ここでは、ＳＮ＝２のパケット、及びＳＮ＝３のパケットについての解匿処理、ＲＯＨＣ伸張処理が行われる。なお、ＳＮ＝１のパケットの受信を諦めるとは、ＳＮ＝１のパケットを受信したことと見なして、中断していた処理を再開すると言い換えてもよい。

図８の例において、リオーダリングタイマの満了後に、ＳＮ＝１のパケットがＳｅＮＢからユーザ装置ＵＥに送信され、ユーザ装置ＵＥはこれを受信する（ステップ１０５）。ユーザ装置ＵＥは、ステップ１０５よりも前に、ＳＮ＝１のパケットを受信していないが、リオーダリングタイマの満了によりＳＮ＝１のパケットを受信したことと見なして処理を進めていることから、ステップ１０５においてＳｅＮＢから受信したＳＮ＝１のパケットを、既に受信したパケットに対する重複パケット（ＰＤＣＰ ＰＤＵ）であると判断する。

そして、動作例１では、図６を参照して説明した場合と異なり、重複パケットに対する処理（秘匿解除、ＲＯＨＣ伸張処理）を行わずに、当該パケットを破棄する。

すなわち、スプリットベアラにおけるパケットの重複検出時においては、パケットを処理せずに破棄する。このような処理を行う理由は、ＨＯや再接続を行わない通常ケースでは、重複パケットが持つＲＯＨＣ情報は、既に取得済みか、或いは古い不要な情報であるためである。

図８のケースにおいて、仮に、ＨＯや再接続の場合と同様に、重複パケットを一旦処理してから破棄する場合、古いＲＯＨＣ情報で更新を行ってしまう可能性があり、その結果、伸張処理を適切に行うことができず、伸張処理を適切に行うためのコンテクストの確立までに遅延が発生する可能性がある。一方、動作例１ではこのような問題は生じない。

図９は、図８の例を、ユーザ装置ＵＥにおける受信パケットに着目して表した図である。図９に示すように、ユーザ装置ＵＥは、ＳＮ＝１のパケットの抜けを検出した時点でリオーダリングタイマを起動し、ＳＮ＝１のパケットを受信ぜずにタイマが満了するので、ＳＮ＝１のパケットの受信を諦めて、ＳＮ＝２、３のパケットを処理することによりＲＯＨＣ情報を更新する。タイマ満了後、ＳＮ＝１のパケットが遅れて到来すると、当該パケットを処理しないで破棄する。これにより、最新のＲＯＨＣ情報により、ＲＯＨＣ処理を継続できる。

（動作例２）
本実施の形態において、スプリットベアラが設定されている場合であっても、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ（ＨＯ、再接続等に起因）が実施される場合には、当該ＨＯ等の手順後に検出される重複パケットについては一旦処理して破棄を行うこととしている。ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔの際には、ヘッダ圧縮プロトコル（ＲＯＨＣ）のリセットが行われるため、後から受信する重複パケット（既に受信したＳＮと同じＳＮを持つパケット）が、新規のＲＯＨＣ情報を持つと考えられるからである。

スプリットベアラが設定されており、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施される場合の動作例である動作例２を、図１０を参照して説明する。図１０は、ＭｅＮＢのＨＯに伴ってＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施される場合の例である。図１０は、ＭｅＮＢ−Ａのセル１からＭｅＮＢ−Ｂのセル２に移行することを示している。図１０の例でもスプリットベアラが設定されているが、ＳｅＮＢは図示されていない。

図１０の例において、ＭｅＮＢ−ＡがＨＯ手順を起動するとともに、ＳＮ＝０のパケットをユーザ装置ＵＥに送信する。ユーザ装置ＵＥからＭｅＮＢ−ＡへはＡＣＫが返されないため、ＭｅＮＢ−ＡからＭｅＮＢ−Ｂに当該パケットの情報が転送され（ステップ２０２）、ＨＯ手順後に、ＭｅＮＢ−Ｂからユーザ装置ＵＥにＳＮ＝０のパケットが送信され（ステップ２０３）、ユーザ装置ＵＥは当該パケットを受信する。

ステップ２０３で受信したパケットのＳＮが０であることから、ユーザ装置ＵＥは、当該パケットがステップ２０１で受信したパケットに対する重複パケットであること検出し、一旦処理（秘匿解除、ＲＯＨＣ伸張処理）を行った後に当該パケットを破棄する。

図１０では、スプリットベアラが設定され、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施される場合の例として、異なるＭｅＮＢ間のハンドオーバを示したが、スプリットベアラが設定され、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施される場合は、異なるＭｅＮＢ間のハンドオーバに限られるものではなく、例えば、ＳｅＮＢ ＨＯ、ＳｅＮＢ追加、ｉｎｔｒａ−ＭｅＮＢ ＨＯ（セクタ変更等）、再接続等の構成変更全般においてＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施され得る。

図１１は、構成変更手順の概要例を示す図である。図１１は、シグナリングフローの一部を示すものである。なお、図１１に関連するＤＣにおけるシグナリングフローの例が非特許文献３に記載されている。

図１１において、例えばＭｅＮＢが構成変更（例：ＳｅＮＢ追加）を決定すると、ＭｅＮＢは、構成変更要求をＳｅＮＢに送信する（ステップ３０１）。構成変更要求を受信したＳｅＮＢは、確認応答をＭｅＮＢに送信する（ステップ３０２）。なお、確認応答には、例えば、当該構成変更においてＳｅＮＢがユーザ装置ＵＥに設定することを希望するＳＣＧコンフィギュレーションを含む。

ＭｅＮＢは、例えばＭＣＧコンフィギュレーションとＳＣＧコンフィギュレーションを含む構成変更指示（例：ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）をユーザ装置ＵＥに送信する（ステップ３０３）。

ユーザ装置ＵＥは、構成変更の設定が完了すると、完了応答（例：ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ｃｏｍｐｌｅｔｅ）をＭｅＮＢに返す（ステップ３０４）。ユーザ装置ＵＥから完了応答を受信したＭｅＮＢは、確認応答をＳｅＮＢに送信する（ステップ３０５）。

構成変更のより具体的な例として、ＳｅＮＢ ｃｈａｎｇｅ（Ｓ−ＳｅＮＢからＴ−ＳｅＮＢへのハンドオーバ）の例を図１２に示す（詳細は非特許文献３）。図１２はシグナリングフローの一部を示すものである。また、図１２に示すフローは一例である。

図１２に示すように、ＭｅＮＢは、ＳｅＮＢ Ａｄｄｉｔｉｏｎ ＲｅｑｕｅｓｔをＴ−ＳｅＮＢ（Ｔａｒｇｅｔ−ＳｅＮＢ）に送信し（ステップ４０１）、Ｔ−ＳｅＮＢはＭｅＮＢに対してＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅを送信する（ステップ４０２）。ＭｅＮＢはＳ−ＳｅＮＢ（Ｓｏｕｒｃｅ−ＳｅＮＢ）に対してＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｑｕｅｓｔを送信し（ステップ４０３）、ユーザ装置ＵＥに対してＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎを送信する（ステップ４０４）。ユーザ装置ＵＥは、ＭｅＮＢに対してＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ｃｏｍｐｌｅｔｅを送信し（ステップ４０５）、ＭｅＮＢはＴ−ＳｅＮＢに対してＳｅＮＢ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ｃｏｍｐｌｅｔｅを送信する（ステップ４０６）。また、ユーザ装置ＵＥとＴ−ＳｅＮＢ間ではランダムアクセス手順が実行され（ステップ４０７）、ユーザ装置ＵＥはＴ−ＳｅＮＢと通信可能となる。

更に、Ｓ−ＳｅＮＢからＭｅＮＢに対してＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒ（データの転送）が行われ（ステップ４０８）、ＭｅＮＢからＴ−ＳｅＮＢに対して当該データの転送が行われる（ステップ４０９）。

図１１、図１２に示したような構成変更の中で、例えば、ユーザ装置ＵＥは、構成変更指示（ＲＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信したことをトリガにしてＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施することを決定してもよいし、完了応答（ＲＣ ｃｏｎｎｅｃｔｉｏｎ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ｃｏｍｐｌｅｔｅ）を送信することをトリガにしてＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施することを決定してもよいし、その他のトリガでＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施することを決定してもよい。

また、上記のシグナリングシーケンスによる構成変更のとき、もしくは、構成変更のシグナリングシーケンスの有無にかかわらずに、ＭｅＮＢからユーザ装置ＵＥに対してＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを明示的に指示し、ユーザ装置ＵＥは、当該指示を受けたことをトリガにしてＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを行ってもよい。

（装置構成、処理フロー）
図１３に、本実施の形態に係るユーザ装置ＵＥの機能構成図を示す。図１３に示すように、ユーザ装置ＵＥは、ＤＬ信号受信部１０１、ＵＬ信号送信部１０２、重複パケット処理部１０３、ＲＯＨＣ管理部１０４、ＲＲＣ（無線リソース制御）処理部１０５を含む。図１３は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１３に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

ＤＬ信号受信部１０１は、各ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。ＵＬ信号送信部１０２は、ユーザ装置ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。

重複パケット処理部１０３は、本実施の形態において動作例１、動作例２として説明した重複パケットに関する処理を行う。すなわち、重複パケット処理部１０３は、重複パケットの検出、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔの実施有無判定、重複パケットの処理方法決定（一旦処理して破棄、ｏｒ、処理せずに破棄）を実施する。

ＤＬ信号受信部１０１とＵＬ信号送信部１０２はそれぞれ、パケットバッファを備え、レイヤ１（ＰＨＹ）及びレイヤ２（ＭＡＣ、ＲＬＣ、ＰＤＣＰ）の処理を行うことを想定している（ただし、これに限られるわけではない）。すなわち、ＤＬ信号受信部１０１は、複数の基地局から順次受信するベアラのパケットに抜けがあることを検出した場合に、リオーダリングタイマを起動し、パケットの処理を中断し、当該タイマが満了するまでの間、抜けのパケットの受信を待ち、当該抜けのパケットを受信することなくタイマが満了した場合、当該パケットの受信を諦め、パケットの処理を再開する機能を含む。

ＤＬ信号受信部１０１とＵＬ信号送信部１０２が、レイヤ１（ＰＨＹ）及びレイヤ２（ＭＡＣ、ＲＬＣ、ＰＤＣＰ）の処理を行う場合において、例えば、重複パケット処理部１０３が上記の判定／決定を行って、当該判定等の結果に基づいて、ＤＬ信号受信部１０１がパケット（ＰＤＣＰ ＰＤＵ）の秘匿解除、ＲＯＨＣ伸張処理、破棄を行う。また、重複パケット処理部１０３が、上記の判定／決定に加えて、パケット（ＰＤＣＰ ＰＤＵ）の秘匿解除、ＲＯＨＣ伸張処理、破棄等を行うこととしてもよい。

ＲＯＨＣ管理部１０４は、ＲＯＨＣのコンテクスト等、ＲＯＨＣによるヘッダ圧縮／伸張を行うために必要な情報を格納しており、この情報はＤＬ信号受信部１０１／ＵＬ信号送信部１０２におけるＲＯＨＣ処理機能部から参照される。また、ＲＯＨＣ管理部１０４が、上記の情報を格納するとともに、ＲＯＨＣによるヘッダ圧縮／復元機能を備えることとしてもよい。

ＲＲＣ処理部１０５は、ＤＣやスプリットベアラの設定／変更／管理、構成変更等の処理を行う。また、ＲＲＣ処理部１０３は、ユーザ装置ＵＥにおけるＲＲＣに関する状態を管理（格納）する機能を含む。例えば、重複パケット処理部１０３は、ＲＲＣ処理部１０５を参照することで、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施されている状態（例：ＨＯ手順実施中、あるいはＨＯ手順の直後等）かどうかを把握することができる。なお、これは一例であり、重複パケット処理部１０３はその他の方法でＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが実施中かどうかを判定してもよい。例えば、重複パケット処理部１０３は、ＤＬ信号受信部１０１におけるＰＤＣＰエンティティを参照し、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔに基づくパケットの流れを検知したときにＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中であると判定してもよい。また、ＲＯＨＣのリセット等、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔに付随する処理が行われているか否かを検知することでＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中であるか否かを判定してもよい。

図１４に上記構成を有するユーザ装置ＵＥが実行する処理フローの例を示す。図１４に示す処理フローの前提として、ユーザ装置ＵＥのＲＲＣ処理部１０５により、スプリットベアラが設定されているものとする。

ステップ５０１において、重複パケット処理部１０３は、重複パケット（ＰＤＣＰ ＰＤＵ）を検出する。ステップ５０１は、例えば、図８に示すように、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中でない場合の、リオーダリングタイマ満了後の重複パケット検出の場合もあるし、図１０に示すように、ＨＯに伴うＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中である場合の重複パケット検出の場合もある。また、ＨＯに伴うＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中であって、かつ、リオーダリングタイマ満了後の重複パケット検出の場合もあり得る。

重複パケット処理部１０３は、重複パケットを検出すると、ユーザ装置ＵＥにおいてＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中か否かを判定する（ステップ５０２）。ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中である場合（ステップ５０２のＹｅｓ）、ステップ５０３にて重複パケットを処理し（秘匿解除、ＲＯＨＣ伸張処理を行い）、重複パケットを破棄する（ステップ５０４）。

一方、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中でない場合（実施中であると判定されない場合）（ステップ５０２のＮｏ）、重複パケットを処理することなく破棄する（ステップ５０４）。なお、本実施の形態において、「ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを実施中」とは、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔを過去に実施し、ＰＤＣＰ ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔ後のパケットを受信し始める場合等を含む。

以上、説明したように、本実施の形態により、１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおける前記ユーザ装置であって、前記複数の基地局から前記ベアラのパケットを順次受信する受信部と、前記受信部により受信したパケットから、あるパケットと重複する重複パケットを検出した場合に、前記ユーザ装置において、ヘッダ圧縮伸張プロトコルを含む所定のパケット通信プロトコルの再設定が行われているかどうかを判定し、当該所定のパケット通信プロトコルの再設定が行われていない場合に、前記重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する重複パケット処理部とを備えるユーザ装置が提供される。

上記の構成により、１つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおいて、ユーザ装置が重複パケットを受信した場合に、その後のパケット伸張処理を考慮して、当該重複パケットの処理を適切に行うことが可能となる。

前記所定のパケット通信プロトコルの再設定が行われている場合に、前記重複パケット処理部は、前記重複パケットのヘッダ復元処理を行った後に、当該重複パケットを破棄する。この構成により、例えばＨＯや再接続時に、前記重複パケットのヘッダ復元処理を行うことができるので、ヘッダ復元用の新たな情報（例：ＲＯＨＣ情報）を取得できる。

前記受信部が、前記複数の基地局から順次受信する前記ベアラのパケットに抜けがあることを検出したときに、タイマを起動し、当該タイマが満了するまでの間、前記抜けのパケットの受信を待ち、当該タイマが満了した後に当該抜けのパケットを受信した場合に、前記重複パケット処理部は、当該タイマが満了した後に受信した抜けのパケットを前記重複パケットであると判定し、当該重複パケットのヘッダ復元処理を行うことなく、当該重複パケットを破棄することとしてもよい。この構成により、例えば、ＨＯや再接続を行わないケースにおいて、ヘッダ復元用の古い情報（例：ＲＯＨＣ情報）を取得して、これにより更新が行われることを回避できる。

前記ユーザ装置と前記複数の基地局との間でデュアルコネクティビティが設定されており、前記重複パケット処理部は、当該デュアルコネクティビティにおける構成変更指示に基づいて、前記所定のパケット通信プロトコルの再設定が行われていると判定するようにしてもよい。この構成により、前記所定のパケット通信プロトコルの再設定が行われているか否かを適切に判定できる。

前記デュアルコネクティビティにおけるＭｅＮＢの変更又はＳｅＮＢの変更が行われる場合に、前記重複パケット処理部は、前記所定のパケット通信プロトコルの再設定が行われていると判定することとしてもよい。この構成により、前記所定のパケット通信プロトコルの再設定が行われているか否かを適切に判定できる。

前記所定のパケット通信プロトコルは、例えばＰＤＣＰである。これにより、ＰＤＣＰ ＰＤＵの重複検出時において、古いＲＯＨＣ情報で更新を行うことを回避できる。

本実施の形態で説明したユーザ装置ＵＥは、ＣＰＵとメモリを備え、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。

以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、ユーザ装置ＵＥは機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置ＵＥが有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。

本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

ＭｅＮＢ、ＳｅＮＢ 基地局
ＵＥ ユーザ装置
１０ Ｓ−ＧＷ
１０１ ＤＬ信号受信部
１０２ ＵＬ信号送信部
１０３ 重複パケット処理部
１０４ ＲＯＨＣ管理部
１０５ ＲＲＣ処理部

Claims (7)

1. １つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおける前記ユーザ装置であって、
   前記複数の基地局から前記ベアラのパケットを順次受信する受信部と、
   前記受信部により受信したパケットから、あるパケットと重複する重複パケットを検出した場合に、前記ユーザ装置において、ヘッダ圧縮伸張プロトコルを含む所定のパケット通信プロトコルの再設定が行われているかどうかを判定し、当該所定のパケット通信プロトコルの再設定が行われていない場合に、前記重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する重複パケット処理部と
   を備えることを特徴とするユーザ装置。
2. 前記所定のパケット通信プロトコルの再設定が行われている場合に、前記重複パケット処理部は、前記重複パケットのヘッダ復元処理を行った後に、当該重複パケットを破棄する
   ことを特徴とする請求項１に記載のユーザ装置。
3. 前記受信部が、前記複数の基地局から順次受信する前記ベアラのパケットに抜けがあることを検出したときに、タイマを起動し、当該タイマが満了するまでの間、前記抜けのパケットの受信を待ち、当該タイマが満了した後に当該抜けのパケットを受信した場合に、前記重複パケット処理部は、当該タイマが満了した後に受信した抜けのパケットを前記重複パケットであると判定し、当該重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する
   ことを特徴とする請求項１又は２に記載のユーザ装置。
4. 前記ユーザ装置と前記複数の基地局との間でデュアルコネクティビティが設定されており、前記重複パケット処理部は、当該デュアルコネクティビティにおける構成変更指示に基づいて、前記所定のパケット通信プロトコルの再設定が行われていると判定する
   ことを特徴とする請求項１ないし３のうちいずれか１項に記載のユーザ装置。
5. 前記デュアルコネクティビティにおけるＭｅＮＢの変更又はＳｅＮＢの変更が行われる場合に、前記重複パケット処理部は、前記所定のパケット通信プロトコルの再設定が行われていると判定する
   ことを特徴とする請求項４に記載のユーザ装置。
6. 前記所定のパケット通信プロトコルはＰＤＣＰであることを特徴とする請求項１ないし５のうちいずれか１項に記載のユーザ装置。
7. １つのベアラのパケットが複数の基地局間で分配され、当該分配されたベアラのパケットが当該複数の基地局からユーザ装置に送信される移動通信システムにおける前記ユーザ装置が実行する重複パケット処理方法であって、
   前記複数の基地局から前記ベアラのパケットを順次受信する受信ステップと、
   前記受信ステップにより受信したパケットから、あるパケットと重複する重複パケットを検出した場合に、前記ユーザ装置において、ヘッダ圧縮伸張プロトコルを含む所定のパケット通信プロトコルの再設定が行われているかどうかを判定し、当該所定のパケット通信プロトコルの再設定が行われていない場合に、前記重複パケットのヘッダ伸張処理を行うことなく、当該重複パケットを破棄する重複パケット処理ステップと
   を備えることを特徴とする重複パケット処理方法。

Images