(57)【特許請求の範囲】
【請求項１】
ＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤにおいて各ＰＤＣＰ  ＳＤＵ（Service  Data  Unit）にシーケンス番号を関連付け当該シーケンス番号から計算されるＣＯＵＮＴ値を用いて秘匿処理してＰＤＣＰ  ＰＤＵ（Protocol  Data  Unit）を生成しＲＬＣ（Radio  Link  Control）レイヤへ送出するＰＤＣＰ処理部と、
前記ＰＤＣＰ処理部で処理する前記ＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウを超えないように制御するウインドウ管理部と、を備え、
前記ウインドウ管理部は、ＲＬＣ  ＰＤＵを送信したＲＬＣレイヤに対する確認応答であるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを、前記ＰＤＣＰ送信ウインドウを更新する契機として用いると共に、さらに前記ＰＤＣＰ送信ウインドウを更新する契機が、前記ＲＬＣレイヤが前記ＰＤＣＰレイヤから通知されるポーリングに応答することによって供給されることを特徴とする送信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ（Long  Term  Evolution）システムにおけるＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤのＰＤＣＰデータユニットを送信制御する送信機及び通信システムに関する。
【背景技術】
【０００２】
ＬＴＥシステムは、既存のＵＭＴＳ（Universal  Mobile  Telecommunications  System）システムから進化したシステムであり、標準化作業が３ＧＰＰにより行われている。図１はＬＴＥシステムのネットワーク構成を示す図である。ＬＴＥの無線ネットワークは、無線基地局であるｅＮｏｄｅＢ（ｅＮＢ：evolved  Node  B）のみで構成され、ユーザ端末であるＵＥとの間でエアインタフェースを介して通信する。ｅＮＢはＬＴＥを収容するコアネットワークであるＥＰＣ(Evolved  Packet  Core)とＳ１インタフェースを介して接続される。具体的には、Ｃ−ＰｌａｎｅがＳ１−ＭＭＥ(Mobility  Management  Entity)インタフェースにてＭＭＥに接続され、Ｕ−ＰｌａｎｅがＳ１−ＵインタフェースにてＳ−ＧＷ(Serving  Gateway)に接続される。隣接するｅＮＢはＸ２インタフェースにて接続される。
【０００３】
図２は、３ＧＰＰ規格に準拠したＵＥとＥ−ＵＴＲＡＮ（ｅＮＢ）間の無線インタフェースプロトコルの構造を示す図である。図２ＡはＵ−Ｐｌａｎｅのプロトコルスタックであり、図２ＢはＣ−Ｐｌａｎｅのプロトコルスタックである。プロトコルスタックは、ＵＥとＥ−ＵＴＲＡＮ（ｅＮＢ）に対で存在し、無線区間のデータ送信を担っている。Ｕ−Ｐｌａｎｅは、ＰＨＹ（Physical）からなるレイヤ１と、ＭＡＣ（Medium  Access  Control）、ＲＬＣ（Radio  Link  Control）、ＰＤＣＰからなるレイヤ２とで構成され、Ｃ−Ｐｌａｎｅは、Ｕ−Ｐｌａｎｅと同様のプロトコルであるレイヤ１及び２と、ＲＲＣ（Radio  Resource  Control）からなるレイヤ３とで構成されている。なお、ＮＡＳはＵＥとコアネットワークとの間の機能レイヤである。
【０００４】
ＰＤＣＰレイヤでは、ベアラごとにＰＤＣＰｅｎｔｉｔｙが設定される。送信側は、ユーザデータ用ベアラであるＤＲＢ(Data  Radio  Bearer)にてユーザデータ（ＩＰパケット）のヘッダ圧縮処理と秘匿処理とを施し、制御メッセージ用ベアラであるＳＲＢ(Signaling  Radio  Bearer)にてＲＲＣメッセージの改ざん防止用の秘匿処理と完全性保護（Integrity  protection）とを施し、ＲＬＣレイヤへＰＤＣＰ  ＰＤＵ(Protocol  Data  Unit)として送出する。受信側は、対応するヘッダ復元、秘匿解除、改ざん検出を行う。ＰＤＣＰレイヤにおける秘匿処理及び改ざん検出には、ＣＯＵＮＴ値が用いられる。図３に示すように、ＣＯＵＮＴ値は、ＨＦＮ(Hyper  Frame  Number)とＰＤＣＰ  ＳＮ(Sequence  Number)から構成される。ＰＤＣＰ  ＳＮは、ＣＯＵＮＴ値の下位１２ｂｉｔ(又は７ｂｉｔ)を構成する。ＰＤＣＰ  ＳＮは、ＰＤＣＰ  ＰＤＵ（パケット）をＲＬＣレイヤへ送出する度にインクリメントされ、１２ｂｉｔ(又は７ｂｉｔ)で表現できる最大値までインクリメントしたら最小値に戻る周回を繰り返すように制御される。ＨＦＮは、ＣＯＵＮＴ値の上位２０ｂｉｔ(又は２５ｂｉｔ)を構成する。ＨＦＮは、ＰＤＣＰ  ＳＮが周回するたびにインクリメントされる。
【０００５】
ＲＬＣレイヤでは、ベアラごとにＲＬＣｅｎｔｉｔｙが設定される。３ＧＰＰ規格では、ＲＬＣについて、ＡＭ(Acknowledged  Mode)、ＵＭ(Unacknowledged  Mode)と、ＴＭ(Transparent  Mode)の３つのモードが定義されている。ＲＬＣ-ＡＭ/ＵＭの場合は、送信側は、図４に示すように、上位レイヤからのＰＤＣＰ  ＰＤＵであるＲＬＣ  ＳＤＵを適応的に分割・統合して、ＴＴＩごとのトランスポートブロックサイズに適合した長さのＲＬＣ  ＰＤＵへマッピングし、ＭＡＣレイヤへ送出する。受信側は、対応するＰＤＣＰ  ＰＤＵの再構築を行う。また、ＲＬＣ−ＡＭでは、受信側からの送達確認信号（ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔ）に基づいて、送信側がＲＬＣ  ＰＤＵを再送するＡＲＱ(Automatic  Repeat  reQuest)制御が実施され、ＭＡＣレイヤにおけるＨＡＲＱ(Hybrid  ARQ)の残留誤りを補うことができる。
【０００６】
ここで、図５を参照して、ＰＤＣＰレイヤの動作について説明する。送信側では、上位レイヤからパケット（ＰＤＣＰ  ＳＤＵ）を受け取り、各ＰＤＣＰ  ＳＤＵにシーケンス番号であるＰＤＣＰ  ＳＮを順番に関連付け、ＰＤＣＰ  ＳＮが周回するとＨＦＮをインクリメントする。各ＰＤＣＰ  ＳＤＵに対して対応するＣＯＵＮＴ値を用いて秘匿処理を施し、当該パケットに関連付けたＰＤＣＰ  ＳＮをヘッダに付与してＰＤＣＰ  ＰＤＵとしてＲＬＣレイヤへと送出する。受信側では、ＰＤＣＰレイヤにおいてＰＤＣＰ受信ウインドウを管理しており、受信したパケットのＰＤＣＰ  ＳＮがＰＤＣＰ受信ウインドウ外であれば、当該受信パケットを破棄する。また、受信したパケットのＰＤＣＰ  ＳＮがＰＤＣＰ受信ウインドウ内である場合には、現在の受信状態から当該パケットの解匿処理に用いるＨＦＮを推測し、推測したＨＦＮを上位ｂｉｔとし、受信したパケットのＰＤＣＰ  ＳＮを下位ｂｉｔとしたＣＯＵＮＴ値を用いて秘匿解除処理を実施して元のパケットを抽出する。ＣＯＵＮＴ値が送信側と受信側で同期していなければ、正しいデータを抽出することができない。正しく抽出された受信パケットは上位レイヤへ送出し、受信ウインドウを更新する。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】3GPP  TS  36.323  V12.2.0  “Technical  Specification  Group  Access  Network；  Evolved  Universal  Terrestrial  Radio  Access  (E-UTRA)；  Packet  Data  Convergence  Protocol(PDCP)  specification(Release  12)”
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、送信側で受信ウインドウサイズに相当する数のＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）が連続的に破棄されると、受信側の受信ウインドウを更新することができずに、ｅＮＢ-ＵＥ間でＨＦＮの認識不一致が発生し、ＵＥ側で解匿処理失敗により正常なＰＤＣＰ  ＳＤＵを抽出することができない問題が生じる(ＨＦＮ  ｄｅ−ｓｙｎｃ問題)。
【０００９】
図６はＨＦＮ  ｄｅ−ｓｙｎｃが発生した状況を示す概念図である。同図では、説明を簡単にするために受信側のＰＤＣＰレイヤにおける受信ウインドウサイズのＰＤＣＰ  ＳＮで表現できるサイズ（０−４０９５）にしている。送信側においてＰＤＣＰ受信ウインドウ分の数のＰＤＣＰ  ＰＤＵが連続して破棄された状態が示されている。例えば、ＰＤＣＰ  ＳＮは、１２ｂｉｔ構成として考えると、０番から４０９５番まで表現することができる。ＰＤＣＰ受信ウインドウのサイズは、ＰＤＣＰ  ＳＮで表現できるサイズ（０−４０９５）であるとすれば、ＰＤＣＰ受信ウインドウ分（４０９６）の数のＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）が連続的に破棄された時点で、ＨＦＮ  ｄｅ−ｓｙｎｃが発生する。この結果、送信側では４０９６個のＰＤＣＰ  ＰＤＵ化が終了した時点でＨＦＮがインクリメントしてＨＦＮ＝１に変化しているが、受信側では４０９６個のＰＤＣＰ  ＳＤＵを受信できていないので、受信状態から推定されるＨＦＮはＨＦＮ＝０のままである。受信側は、ＨＦＮ＝０で秘匿解除を試みるが、誤ったＨＦＮ値のため不正パケットとして処理される。
【００１０】
本発明者等は、送信側のＰＤＣＰ  ｅｎｔｉｔｙにおいて一度にＰＤＣＰ  ＰＤＵ化するＰＤＣＰ  ＰＤＵ数に制限を持たせる送信ウインドウ（以下、「ＰＤＣＰ送信ウインドウ」という）を設定することが、ＨＦＮ  ｄｅ−ｓｙｎｃ問題を解決するために有効であると考えている。送信側のＰＤＣＰ  ｅｎｔｉｔｙにおいて、送信したＰＤＣＰ  ＰＤＵに対するＲＬＣ−ＡＣＫの受信状況によって受信側のＰＤＣＰ受信ウインドウの位置を推測し、それに応じてＰＤＣＰ送信ウインドウを更新するスキームが想定される。
【００１１】
ここで、３ＧＰＰ仕様（TS  36.323）に準拠した動作に基づいてＰＤＣＰ送信ウインドウを設定する場合について検討する。ＰＤＣＰ送信ウインドウの下端は、その全てに対してＲＬＣ−ＡＣＫを受けたＰＤＣＰ  ＰＤＵのうち最新のＰＤＣＰ  ＰＤＵに関連付けられたＰＤＣＰ  ＳＮに１プラスした値と一致させ、送信ウインドウサイズはＰＤＣＰ受信ウインドウのサイズとすることが想定される。そして、ＰＤＣＰ送信ウインドウは、受信したＲＬＣ−ＡＣＫに基づいて更新される。即ち、送信側のＲＬＣレイヤはＲＬＣ−ＡＣＫを受けた時点でＰＤＣＰレイヤに対して通知を行い、ＰＤＣＰレイヤはこれに応答して、ＰＤＣＰ送信ウインドウを更新する。
【００１２】
しかしながら、上記したＲＬＣ−ＡＣＫベースのＰＤＣＰ送信ウインドウの更新では、更新頻度が不足してＰＤＣＰ送信ウインドウｓｔａｌｌｉｎｇによるスループットの低下が懸念される。例えば、図１３に示すように、受信側のＲＬＣレイヤ（ＲｘＲＬＣ）が無線送信するＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔ（ＲＬＣ−ＡＣＫ／ＮＡＣＫ）が無線で欠落する場合が考えられる（図１３Ｂ）。送信側のＲＬＣレイヤ（ＴｘＲＬＣ）は受信側のＲＬＣレイヤから送信されたＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを受け取ると、送信側のＰＤＣＰレイヤ（ＴｘＰＤＣＰ）へＲＬＣ−ＡＣＫを通知してＸを更新する契機を与えている。しかし、図１３Ｂに示すようにＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔが無線で欠落すると、次にＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔが送信されるまでＲＬＣ−ＡＣＫをＰＤＣＰレイヤ（ＴｘＰＤＣＰ）へ通知する契機が現れない。その結果、図１３Ａに示すように送信側のＰＤＣＰレイヤではＰＤＣＰ送信ウインドウサイズを超えてＰＤＣＰ  ＰＤＵを生成できない状態が長時間継続する（ＰＤＣＰウインドウｓｔａｌｌｉｎｇ）。ＰＤＣＰウインドウｓｔａｌｌｉｎｇは、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔが無線で欠落する場合に限らず、ＰＤＣＰ送信ウインドウサイズに相当するデータを送信するのに必要な時間が、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔの受信間隔よりも短い場合にも発生し得る。
【００１３】
本発明はかかる点に鑑みてなされたものであり、ＰＤＣＰ送信ウインドウを用いてＨＦＮ  ｄｅ-ｓｙｎｃを防止すると共に、ＰＤＣＰ送信ウインドウの更新契機をＲＬＣ−ＡＣＫの受信間隔よりも高頻度にＰＤＣＰレイヤへ供給してスループットの低下を防止できる送信機及び通信システムを提供することを目的の１つとする。
【課題を解決するための手段】
【００１４】
本発明の送信機の一態様は、ＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤにおいて各ＰＤＣＰ  ＳＤＵ（Service  Data  Unit）にシーケンス番号を関連付け当該シーケンス番号から計算されるＣＯＵＮＴ値を用いて秘匿処理してＰＤＣＰ  ＰＤＵ（Protocol  Data  Unit）を生成しＲＬＣ（Radio  Link  Control）レイヤへ送出するＰＤＣＰ処理部と、前記ＰＤＣＰ処理部で処理する前記ＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウを超えないように制御するウインドウ管理部と、を備え、前記ウインドウ管理部は、ＲＬＣ  ＰＤＵを送信したＲＬＣレイヤに対する確認応答であるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを、前記ＰＤＣＰ送信ウインドウを更新する契機として用いると共に、さらに前記ＰＤＣＰ送信ウインドウを更新する契機が、前記ＲＬＣレイヤが前記ＰＤＣＰレイヤから通知されるポーリングに応答することによって供給されることを特徴とする。
【発明の効果】
【００１５】
本発明によれば、ＰＤＣＰ送信ウインドウを用いてＨＦＮ  ｄｅ−ｓｙｎｃを防止できると共に、ＰＤＣＰ送信ウインドウの更新契機をＲＬＣ−ＡＣＫの受信間隔よりも高頻度にＰＤＣＰレイヤへ供給してスループットの低下を防止できる。
【図面の簡単な説明】
【００１６】
【図１】ＬＴＥシステムのネットワーク構成を示す図である。
【図２】無線インタフェースプロトコルの構造を示す図である。
【図３】ＣＯＵＮＴ値の構成を示す図である。
【図４】ＲＬＣサブレイヤにおけるＲＬＣ  ＳＤＵの分割・統合を示す図である。
【図５】ＰＤＣＰサブレイヤの動作概要を説明する図である。
【図６】ＨＦＮ  ｄｅ−ｓｙｎｃが発生した状況を示す概念図である。
【図７】本実施の形態に適用される送信機の機能ブロック図である。
【図８】送信機のＰＤＣＰレイヤにおける処理フロー図である。
【図９】ＰＤＣＰ  ＰＤＵ化、ＰＤＣＰ  ＳＮの関連付けの停止処理の概念図である。
【図１０】ＰＤＣＰ  ＰＤＵ化、ＰＤＣＰ  ＳＮの関連付けの再開処理の概念図である。
【図１１】Ｘの更新処理とＰＤＣＰ  ＰＤＵ化動作についての説明図である。
【図１２】バッファ溢れが発生した場合のパケット破棄についての説明図である。
【図１３】ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔが欠落する状態の説明図である。
【図１４】ＰＤＣＰレイヤへ送信処理の完了を通知するタイミング図である。
【図１５】ＰＤＣＰ送信ウインドウとＰＤＣＰ受信ウインドウの関係説明図である。
【発明を実施するための形態】
【００１７】
以下、本発明の一実施の形態について詳細に説明する。本実施の形態は、図１にネットワーク構成を示すＬＴＥシステムに適用した一例であり、図２Ａ，図２Ｂに示すプロトコルスタックがＵＥとＥ−ＵＴＲＡＮ（ｅＮＢ）に対で存在する。以下の説明ではｅＮＢが送信機として動作し、ＵＥが受信機として動作する場合について説明するが、上りリンクのデータ送信のようにＵＥが送信機として動作する場合にも適用可能である。
【００１８】
図７は本実施の形態に適用される送信機の機能ブロックである。
送信機のＰＤＣＰレイヤの機能には、ＰＤＣＰバッファ１１、ＰＤＣＰ処理部１２及びＰＤＣＰウインドウ管理部１３を有している。ＰＤＣＰバッファ１１は、上位レイヤから受信したＰＤＣＰ  ＳＤＵ及びＰＤＣＰ処理部１２で生成したＰＤＣＰ  ＰＤＵを一旦保存する送信バッファとしての機能を提供する。
【００１９】
ＰＤＣＰ処理部１２は、各ＰＤＣＰ  ＳＤＵにＰＤＣＰ  ＳＮを関連付け当該ＰＤＣＰ  ＳＮから計算されるＣＯＵＮＴ値を用いて秘匿処理してＰＤＣＰ  ＰＤＵを生成しＲＬＣレイヤへ送出するといった一連の処理フローを実行する機能を備えている。ＰＤＣＰ処理部１２は、ＰＤＣＰ送信ウインドウを設定し、ＰＤＣＰ処理部１２において処理するＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウサイズを超えないように制限する。ＰＤＣＰ処理部１２において一度に処理するＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウサイズを超える場合は、ＰＤＣＰ  ＰＤＵ化又はＰＤＣＰ  ＳＮとの関連付けを停止し、送信ウインドウが更新されたら処理を再開する。
【００２０】
ＰＤＣＰウインドウ管理部１３は、ＰＤＣＰ処理部１２に設定されるＰＤＣＰ送信ウインドウを更新する機能を有する。ＰＤＣＰ送信ウインドウサイズは、Ｘを基準にしてＹ個のＰＤＣＰ  ＳＤＵが最大数となるように設定される。すなわち、ＹがＰＤＣＰウインドウサイズとなり、ＰＤＣＰ  ＳＮで表現できる値の半分の値（１２ｂｉｔであれば２０４８）で規定される。ＰＤＣＰ送信ウインドウの下端ＸはＰＤＣＰ  ＳＮで与えられ、このＸを更新することによりＰＤＣＰ送信ウインドウがシフトされる。Ｘは、ＲＬＣレイヤで分割されて一部でもＲＬＣ  ＰＤＵへマッピングされたＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＰＤＵ）のうち最新のＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＰＤＵ）に関連付けられたＰＤＣＰ  ＳＮに１プラスした値である。ＰＤＣＰウインドウ管理部１３が管理するＰＤＣＰ送信ウインドウを用いて、ＰＤＣＰ処理部１２において最大Ｙ個（Ｘ番から（Ｘ＋Ｙ−１）番まで）のＰＤＣＰ  ＰＤＵを生成し又はＳＤＵにＸ番から（Ｘ＋Ｙ−１）番までのＰＤＣＰ  ＳＮを関連付ける。ＰＤＣＰ処理部１２はＰＤＣＰ送信ウインドウサイズを超えたところで、ＰＤＣＰ  ＰＤＵの生成又はＰＤＣＰ  ＳＮの関連付けを一旦停止し、Ｘが更新されることで処理を再開する。ＰＤＣＰウインドウ管理部１３は、ＰＤＣＰ送信ウインドウの下端Ｘを更新する契機として、無線送信したＲＬＣ  ＰＤＵの確認応答であるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを用いる。さらに、ＰＤＣＰウインドウ管理部１３は、ＲＬＣレイヤにおいてＲＬＣ  ＳＤＵを廃棄した場合、ＲＬＣレイヤにおいて上位レイヤへ供給するＲＬＣ  ＳＤＵが組み上がった場合、ＲＬＣ  ＰＤＵへ未マッピングのＰＤＣＰ  ＰＤＵの数が所定値を下回った場合の少なくとも１つを、ＰＤＣＰ送信ウインドウを更新する契機として用いる。これにより、ＰＤＣＰ送信ウインドウの更新契機をＲＬＣ−ＡＣＫの受信間隔よりも高頻度にすることができる。
【００２１】
送信機のＲＬＣレイヤの機能には、ＲＬＣバッファ２１、送信側ＲＬＣ処理部２２、受信側ＲＬＣ処理部２３、ＲＬＣコントローラ２４及び通知部２５を有している。ＲＬＣバッファ２１は、ＰＤＣＰ処理部１２から送出されるＰＤＣＰ  ＰＤＵをＲＬＣ  ＳＤＵとして一旦保存する送信バッファとしての機能を提供する。
【００２２】
送信側ＲＬＣ処理部２２は、ＲＬＣ  ＳＤＵを適応的に分割・統合して、ＴＴＩごとのトランスポートブロックサイズに適合した長さのＲＬＣ  ＰＤＵにマッピングし、ＭＡＣレイヤへ送出する一連の処理フローを実行する機能を備えている。ＲＬＣ  ＳＤＵは分割されて一部がＲＬＣ  ＰＤＵにマッピングされることがあるが、一部でもＲＬＣ  ＰＤＵにマッピングされたＲＬＣ  ＳＤＵはＲＬＣでロスレスが担保される。送信側ＲＬＣ処理部２２は、論理チャネルにマッピングしたＲＬＣ  ＰＤＵのコピーをＲＬＣバッファ２１に保持しておき、ＲＬＣ−ＡＭでは、受信側ＲＬＣレイヤにおけるＲＬＣ  ＰＤＵの確認応答（ＲＬＣ−ＡＣＫ／ＮＡＣＫ）であるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを受けて、ＲＬＣ−ＡＣＫを確認してから破棄する。また、送信側ＲＬＣ処理部２２は、ＲＬＣ  ＰＤＵへ未マッピングのＰＤＣＰ  ＰＤＵの数が所定値を下回った場合は、通知部２５に対してその旨を通知する機能を有する。
【００２３】
受信側ＲＬＣ処理部２３は、受信機として機能する場合のＲＬＣレイヤにおける機能ブロックであるが、ここではＰＤＣＰ送信ウインドウの更新に関連する機能について主に説明する。受信側ＲＬＣ処理部２３は、受信側（ＵＥ側）ＲＬＣレイヤにおけるＲＬＣ  ＰＤＵの確認応答であるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを受信して、ＲＬＣ−ＡＣＫ／ＮＡＣＫを検出する機能と、下位レイヤからＲＬＣレイヤに供給される正常に受信できたＲＬＣ  ＰＤＵに基づいてＲＬＣ  ＳＤＵを組み上げて上位レイヤへ供給する機能とを有する。受信側ＲＬＣ処理部２３は、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを受信した場合、ＲＬＣ  ＳＤＵを組み上げた場合に、通知部２５へその旨を通知する機能をさらに有する。
【００２４】
ＲＬＣコントローラ２４は、ＲＬＣ  ＰＤＵにマッピングされていないでバッファ中のＲＬＣ  ＳＤＵを破棄するバッファ破棄の事象が発生した時に、バッファ破棄をＲＬＣバッファ２１に指示すると共に、通知部２５に対してバッファ破棄を知らせる機能を有する。
【００２５】
通知部２５は、ＰＤＣＰレイヤのＰＤＣＰウインドウ管理部１３に対して、ＰＤＣＰ送信ウインドウを更新する契機を与える機能を有する。通知部２５は、ＰＤＣＰウインドウ管理部１３に対してＰＤＣＰ送信ウインドウの更新契機を通知する際に、前回の更新時にＲＬＣ  ＰＤＵへ未マッピングであったＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）のうち現時点までにＲＬＣ  ＰＤＵへマッピングしたＰＤＣＰ  ＰＤＵに関する情報をＰＤＣＰウインドウ管理部１３へ伝える。通知部２５は、ＲＬＣレイヤが自律的にＰＤＣＰレイヤへＰＤＣＰ送信ウインドウの更新契機を与えるように構成してもよい。また、通知部２５は、ＰＤＣＰレイヤ（ＰＤＣＰウインドウ管理部１３）からポーリングを受けたら当該ポーリングに応答してＰＤＣＰレイヤへＰＤＣＰ送信ウインドウの更新契機を与えるように構成してもよい。さらに、通知部２５は、ＲＬＣレイヤが自律的に更新契機を与える構成とポーリングに応答して更新契機を与える構成とを適宜組み合わせてもよい。通知部２５は、受信側ＲＬＣ処理部２３がＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを受信すると、それを受けてＰＤＣＰウインドウ管理部１３に対してＰＤＣＰ送信ウインドウを更新する契機を与える。このとき、ＰＤＣＰウインドウ管理部１３には、前回更新時にＲＬＣ  ＰＤＵへ未マッピングであったＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）のうち現時点までにＲＬＣ  ＰＤＵへマッピングしたＰＤＣＰ  ＰＤＵであって受信側からＲＬＣ−ＡＣＫが通知されたＰＤＣＰ  ＰＤＵ（ＲＬＣ-ＰＤＵ）の情報が併せて伝えられる。さらに、通知部２５は、送信側ＲＬＣ処理部２２からＲＬＣ  ＰＤＵへ未マッピングのＰＤＣＰ  ＰＤＵの数が所定値を下回ったことが通知された場合、受信側ＲＬＣ処理部２３からＲＬＣ  ＳＤＵを組み上げたことが通知された場合、ＲＬＣコントローラ２４からＲＬＣ  ＰＤＵにマッピングされないでバッファ中のＲＬＣ  ＳＤＵを破棄するバッファ破棄が通知された場合に、それぞれＰＤＣＰウインドウ管理部１３に対してＰＤＣＰ送信ウインドウを更新する契機を与える。なお、３つのうち少なくとも１つを契機に用いるように構成してもよい。また、通知部２５は、ＲＬＣレイヤから最後にＰＤＣＰレイヤへ更新の契機を与えてから次の契機を与えることなく所定期間が経過した場合、ＲＬＣレイヤから最後にＰＤＣＰレイヤへ更新の契機を与えてから、ＰＤＣＰレイヤから流入したＰＤＣＰ  ＰＤＵの総数又は総バイト数が所定値を超過する場合、ＲＬＣレイヤから最後にＰＤＣＰレイヤへ更新の契機を与えてからＲＬＣ  ＰＤＵへマッピングしたＰＤＣＰ  ＰＤＵの数又はバイト数が所定値を超過する場合、の少なくとも１つをＰＤＣＰ送信ウインドウが更新される契機としてＰＤＣＰウインドウ管理部１３に対して通知してもよい。また、通知部２５は、ＰＤＣＰウインドウ管理部１３からポーリングを受けたら当該ポーリングに応答して、ＰＤＣＰウインドウ管理部１３へ更新契機を通知すると共に、前回の更新時にＲＬＣ  ＰＤＵへ未マッピングであったＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）のうち現時点までにＲＬＣ  ＰＤＵへマッピングしたＰＤＣＰ  ＰＤＵを通知してもよい。
【００２６】
送信機のＭＡＣレイヤ及びＰＨＹレイヤの機能は、下りリンクに関してはＤＬ信号送信部３１が担い、上りリンクに関してはＵＬ信号受信部３２が担う。ＤＬ信号送信部３１のＭＡＣレイヤは、ハイブリッドＡＲＱ再送と上りリンクと下りリンクのスケジューリングを行う機能の他に、ＲＬＣレイヤに論理チャネル形式のサービスを提供する機能を有する。
【００２７】
次に、以上のように構成された送信機のＰＤＣＰレイヤにおける処理フローについて、図８に示す処理フローを参照しながら具体的に説明する。図８は、３ＧＰＰ  ＴＳ  ３６．３２３  Ｖ１２．２．０  ４．２．２  ＰＤＣＰ  ｅｎｔｉｔｉｅｓに示されるＰＤＣＰレイヤにおける処理フローを原文のまま示している。送信側ＰＤＣＰｅｎｔｉｔｙが生成するＰＤＣＰ  ＰＤＵは、データＰＤＵと制御ＰＤＵの２つある。データＰＤＵはＰＤＣＰレイヤが上位レイヤから受信したＰＤＣＰ  ＳＤＵから生成するデータブロックであり、制御ＰＤＵは、ＰＤＣＰレイヤがピアｅｎｔｉｔｙに制御情報を送信するために独自に生成するデータブロックである。
【００２８】
本実施の形態における送信側ＰＤＣＰレイヤにおける処理フローは次の通りである。ｅＮＢが送信機となるのでｅＮＢのＰＤＣＰレイヤの処理として説明する。まず、ＰＤＣＰレイヤは、受信したＰＤＣＰ  ＳＤＵをＰＤＣＰバッファ１１に保存し、各ＰＤＣＰ  ＳＤＵにＰＤＣＰ  ＳＮを個々に割り当てる“ＰＤＣＰ  ＳＮの関連付け”を行う（Sequence  numbering）。Ｕ-Ｐｌａｎｅの無線ベアラ（ＤＲＢ）が設定されている場合は、ＰＤＣＰ  ＳＤＵに対してヘッダ圧縮を行う（Header  Compression）。一方、Ｃ−Ｐｌａｎｅの無線ベアラ（ＳＲＢ）が設定されている場合は、ＰＤＣＰ  ＳＤＵに対して完全性保護を行う（Integrity  Protection）。次に、Ｕ−Ｐｌａｎｅ及びＣ−Ｐｌａｎｅのいずれに対しても上記処理の結果生成されたデータブロックに対してＣＯＵＮＴ値を用いて暗号化を行う（Ciphering）。ＣＯＵＮＴ値は、暗号化対象になっているＰＤＣＰ  ＳＤＵに関連付けたＰＤＣＰ  ＳＮと当該ＰＤＣＰ  ＳＮを関連付けた時のＨＦＮとで構成される。そして、暗号化が行われたデータブロックに対して、当該ＰＤＣＰ  ＳＤＵに関連付けたＰＤＣＰ  ＳＮを明示的に含んだヘッダを付加してＰＤＣＰ  ＰＤＵを構成する（Add  PDCP  header）。以上のようにＰＤＣＰ  ＰＤＵを構成するＰＤＣＰレイヤにおける処理のことを“ＰＤＣＰ  ＰＤＵ化”と呼ぶこととする。最後にＰＤＣＰ  ＰＤＵは、ＲＬＣレイヤへ送出される。Ｕ−Ｐｌａｎｅに関しては宛先に応じた宛先制御が行われる(Routing)。
【００２９】
受信側ＰＤＣＰレイヤにおける処理フローは次の通りである。ＵＥが受信機となるのでＵＥのＰＤＣＰレイヤの処理として説明する。まず、ＰＤＣＰレイヤは、受信したＰＤＣＰ  ＰＤＵからヘッダを除去する（Remove  PDCP  Header）。次に、ヘッダが除去されたＰＤＣＰ  ＰＤＵに対して復号化を行う（Deciphering）。復号化対象のＰＤＣＰ  ＰＤＵヘッダに明示的に含まれていたＰＤＣＰ  ＳＮと、現在の受信状況を判断（何個目までのＰＤＣＰ  ＰＤＵまで受信しているかを判断）してＨＦＮを推測し、推測したＨＦＮとヘッダに含まれていたＰＤＣＰ  ＳＮとからなるＣＯＵＮＴ値を用いて復号化対象のＰＤＣＰ  ＰＤＵを復号処理している。このように、受信側ＰＤＣＰレイヤにおいて推測されるＨＦＮは、現実に受信したパケット（ＰＤＣＰ  ＳＤＵ）数に基づいているので、送信側において多数のＰＤＣＰ  ＰＤＵが連続破棄されると、送信側と受信側とでＨＦＮが一致しないＨＦＮ  ｄｅ−ｃｙｎｃが発生する可能性がある。Ｕ−Ｐｌａｎｅの無線ベアラ（ＤＲＢ）が設定されている場合、復号化が行われたＰＤＣＰ  ＰＤＵに対してヘッダ復元を行う（Header  Decompression）。一方、Ｃ−Ｐｌａｎｅの無線ベアラ（ＳＲＢ）が設定されている場合、復号化が行われたＰＤＣＰ  ＰＤＵに対して完全性確認（integrity  verification）を行う。次に、ヘッダ復元又は完全性確認がなされた受信データブロック（すなわち、ＰＤＣＰ  ＳＤＵ）を上位レイヤに送信する（In  order  delivery  and  duplicate  detection）。必要に応じて、ＰＤＣＰ  ＳＤＵを、受信バッファに保存して並び替えを行った後（Reordering）、上位レイヤに送信する。
【００３０】
図１５を参照して、ＰＤＣＰ送信ウインドウとＰＤＣＰ受信ウインドウの関係について説明する。送信側のＰＤＣＰレイヤは、ＰＤＣＰ送信ウインドウを設定しており、ウインドウの下端Ｘは、直前の更新時にＲＬＣ  ＰＤＵへ未マッピングであった最先のＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）に関連付けられたＰＤＣＰ  ＳＮ（又はＣＯＵＮＴ値）が設定されている。図１５に示す例では直前の更新時にＲＬＣ  ＰＤＵへ未マッピングであったＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）のうち現時点までに２つのＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）がＲＬＣ  ＰＤＵへマッピングされている。
【００３１】
受信側のＰＤＣＰレイヤは、ＰＤＣＰ受信ウインドウを設定している。受信パケットのＰＤＣＰ  ＳＮがＰＤＣＰ受信ウインドウ外であれば破棄し、ＰＤＣＰ受信ウインドウ内であれば破棄せずに上記フロー処理を実行し、さらにＰＤＣＰ受信ウインドウを更新する。図１５に示す例では、送信側のＲＬＣレイヤにおいて直前の更新時にＲＬＣ  ＰＤＵへ未マッピングであったＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）のうち現時点までに２つのＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）がＲＬＣ  ＰＤＵへマッピングされているが、その２つのＲＬＣ  ＰＤＵを受信してＰＤＣＰ受信ウインドウを２つ分だけシフトしている。例えば、ＰＤＣＰ  ＳＮを１２ｂｉｔ構成と仮定し、ウインドウサイズをＰＤＣＰ  ＳＮで表現できるサイズ（０−４０９５）の半分（２０４８）とする。更新前のＰＤＣＰ受信ウインドウが［０−２０４７］であり、ＰＤＣＰ  ＳＮが０番、１番の２つのパケットを受信したとすると、更新後のＰＤＣＰ受信ウインドウは２つシフトして［２−２０４９］となる。このように、受信側のＰＤＣＰレイヤでは、ＰＤＣＰ受信ウインドウ内のＰＤＣＰ  ＳＮのパケットを受信するたびに、ＰＤＣＰ受信ウインドウを更新（シフト）する。
【００３２】
受信側のＲＬＣレイヤでは、下位レイヤから受信パケットを受け取ると、ＰＤＣＰ  ＰＤＵを再構築する。そして、当該受信パケットに付加されたＲＬＣシーケンス番号でパケット（ＰＤＣＰ  ＰＤＵ）を特定して、送信側のＲＬＣレイヤに対する確認応答となるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔ（ＲＬＣ−ＡＣＫ又はＮＡＣＫ）を送信する。
【００３３】
次に、送信機のＰＤＣＰレイヤにおいて上記処理フロー上で実行されるＰＤＣＰ送信ウインドウの更新処理について具体的に説明する。本実施の形態は、送信機のＰＤＣＰレイヤにおいて、送信側ＰＤＣＰｅｎｔｉｔｙにおいて、ＰＤＣＰ送信ウインドウを設定し、ＰＤＣＰ処理部１２において処理するＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウサイズを超えないように制限する。ＰＤＣＰ処理部１２において一度に処理するＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウサイズを超えたところで、“ＰＤＣＰ  ＰＤＵ化”を一旦停止する。又は、ＰＤＣＰ  ＳＮと関連付けるＰＤＣＰ  ＳＤＵの数が所定個数になったところで、“ＰＤＣＰ  ＳＮの関連付け”を一旦停止する。そして、ＰＤＣＰ送信ウインドウが更新されることにより処理が再開される。
【００３４】
図１４を参照してＰＤＣＰ送信ウインドウの更新頻度の改善について説明する。
本実施の形態では、上記した通りＰＤＣＰウインドウ管理部１３が通知部２５からＰＤＣＰ送信ウインドウを更新する契機を与えられる。図１４Ｂに示すように、ＰＤＣＰウインドウ管理部１３は、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔの受信を１つの更新契機として用いている。しかし、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔの受信だけを更新契機として用いたのでは、ＰＤＣＰ送信ウインドウの更新頻度が不足してスループットが低減するので、追加の更新契機（図１４Ｂ中で点線で示す）を提供する仕組みを提案する。追加の更新契機を提供することで、図１４Ａに示すようにＰＤＣＰ送信ウインドウｓｔａｌｌｉｎｇの発生を効果的に防止できる。
【００３５】
ＰＤＣＰ送信ウインドウの更新頻度を改善する追加の更新契機として以下の事象のすべて又は一部を用いることができる。ＲＬＣ  ＰＤＵにマッピングされないでバッファ中のＲＬＣ  ＳＤＵを破棄するバッファ破棄を更新契機として用いることができる。バッファ破棄が発生した場合は、ＨＦＮ  ｄｅ−ｓｙｎｃが発生する可能性が高くなるので、これを契機にしてＰＤＣＰ送信ウインドウの下端Ｘを適切に再設定することでＨＦＮ  ｄｅ−ｓｙｎｃの発生を防止できる。
【００３６】
また、ＰＤＣＰウインドウ管理部１３は、ＲＬＣレイヤにおいてＲＬＣ  ＰＤＵへ未マッピングのＰＤＣＰ  ＰＤＵの数（或いはデータサイズ）が所定値を下回ったことを契機としてＰＤＣＰ送信ウインドウを更新することができる。即ち、ＲＬＣ  ＳＤＵが枯渇する場合にＰＤＣＰ送信ウインドウの更新契機を与えて追加のＲＬＣ  ＳＤＵが供給されるように制御する。これにより、ＲＬＣレイヤにおけるＲＬＣ  ＰＤＵへのマッピング状況に応じてＲＬＣ  ＳＤＵが枯渇しないようにＰＤＣＰ送信ウインドウを更新でき、スループット改善が期待できる。
【００３７】
また、ＰＤＣＰウインドウ管理部１３は、受信パケットからＲＬＣ  ＳＤＵを組み上げたことを更新契機として用いることができる。また、ＰＤＣＰウインドウ管理部１３は、ＲＬＣレイヤから最後にＰＤＣＰレイヤへ更新の契機を与えてから次の契機を与えることなく所定期間が経過したことを更新契機として用いることができる。これにより、ＰＤＣＰ送信ウインドウの更新を所望の頻度に制御することができる。また、ＰＤＣＰウインドウ管理部１３は、ＲＬＣレイヤから最後にＰＤＣＰレイヤへ更新の契機を与えてから、ＰＤＣＰレイヤから流入したＰＤＣＰ  ＰＤＵの総数又は総バイト数が所定値を超過する場合をＰＤＣＰ送信ウインドウの更新契機に用いることができる。これにより、ＰＤＣＰレイヤにおける処理レートに連動してＰＤＣＰ送信ウインドウの更新契機を得ることができ、ＰＤＣＰ送信ウインドウｓｔａｌｌｉｎｇを抑制でき、スループットの低下を防止できる。また、ＰＤＣＰウインドウ管理部１３は、ＲＬＣレイヤから最後にＰＤＣＰレイヤへ通知したＲＬＣ  ＰＤＵへマッピング済のＰＤＣＰ  ＳＮと、現在のＲＬＣ  ＰＤＵへマッピング済のＰＤＣＰ  ＳＮの値が所定値Ｑ以上離れたら、ＰＤＣＰ送信ウインドウを更新する契機としてもよい。これにより、ＲＬＣレイヤにおいて所定数のまとまった無線送信が完了するたびに、ＰＤＣＰ送信ウインドウを更新することができ、所定値Ｑを適切に設定することで、１パケット単位で無線送信が完了するたびに更新する場合に比べて、大幅に負荷を軽減できる。
【００３８】
ＰＤＣＰ送信ウインドウを更新する契機は、ＲＬＣレイヤが自律的に行うこととしてもよい。或いは、ＰＤＣＰレイヤからのＰｏｌｌｉｎｇに応答する形でＲＬＣレイヤが行っても良い。Ｐｏｌｌｉｎｇは以下のいずれの契機で行われても良い。１つ目の手法は、送信側のＰＤＣＰレイヤが最後にＲＬＣレイヤへＰｏｌｌｉｎｇを行ってから又は最後にＲＬＣレイヤからフィードバックをもらってから、所定期間（Ｔ１）が経過したら、Ｐｏｌｌｉｎｇを行う。２つ目の手法は、送信側のＰＤＣＰレイヤが最後にＲＬＣレイヤへＰｏｌｌｉｎｇを行ってから又は最後にＲＬＣレイヤからフィードバックをもらってから、ＲＬＣレイヤへ送出したＰＤＣＰ  ＰＤＵの個数、或いは、総バイト数が所定値（Ｍ）を超過する場合にＰｏｌｌｉｎｇを行う。なお、上記いずれの所定期間（Ｔ１）又は所定値（Ｍ）も、ベアラ／論理チャネル毎、ＵＥ毎に異なる値が適用されてもよい。
【００３９】
このように、ＰＤＣＰ送信ウインドウを更新する契機として、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔの受信だけでなく、その他の事象を追加の更新契機として適宜組み合わせることにより、ＰＤＣＰ送信ウインドウの更新頻度を上げることができ、ＰＤＣＰ送信ウインドウｓｔａｌｌｉｎｇによるスループットの低下を防止できる。
【００４０】
次に、ＰＤＣＰ処理部１２におけるＰＤＣＰ送信ウインドウを用いたＰＤＣＰ  ＳＤＵ数の制限について説明する。図９ＡはＰＤＣＰ送信ウインドウで規制される前の状況を例示しており、図９ＢはＰＤＣＰ送信ウインドウサイズを超えたことによる処理停止中の状況を例示している。図９Ａに示すように、ＰＤＣＰレイヤにおいてＰＤＣＰ  ＳＤＵを上位レイヤから受け取り、ＰＤＣＰバッファ１１に保存する。ＰＤＣＰ処理部１２によってＰＤＣＰ  ＳＤＵのＰＤＣＰ  ＳＮが順次関連付けられ、ＣＯＵＮＴ値に基づいて秘匿処理がされてＰＤＣＰ  ＰＤＵとしてＲＬＣレイヤへ送出される。ＲＬＣレイヤにおいてＰＤＣＰ  ＰＤＵがＲＬＣ  ＳＤＵとしてＲＬＣバッファ２１に保存される。ＲＬＣバッファ２１にはＰＤＣＰ  ＳＮとしてＸ番が関連付けられたＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）を先頭にして複数のＰＤＣＰ  ＰＤＵがＲＬＣ  ＳＤＵとして保持されている。そして、図９Ｂに示すように、ＲＬＣレイヤにおいてＲＬＣ  ＰＤＵへ未マッピングのＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）が所定個数（Ｙ個）になった時点（（Ｘ＋Ｙ−１）番に到達した段階）で処理を停止する（ＰＤＣＰ送信ウインドウサイズによる最大数の制限）。
【００４１】
“ＰＤＣＰ  ＰＤＵ化”又は“ＰＤＣＰ  ＳＮの関連付け”を一旦停止すると、更新契機がＰＤＣＰレイヤに与えられるまではＰＤＣＰレイヤに新規パケットが供給されてもＰＤＣＰ  ＰＤＵは生成されない状態が維持される。この結果、送信側のＰＤＣＰレイヤでは再開契機が与えられて処理が再開されるまで、新規パケットであるＰＤＣＰ  ＳＤＵに対するＰＤＣＰ  ＳＮの関連付けが実行されないので、新規パケットが供給されてもＰＤＣＰ  ＳＮのインクリメントはされず、ＨＦＮのインクリメントも行われない。一方、ＲＬＣ  ＰＤＵにマッピングされた最新のＲＬＣ  ＳＤＵ（ＰＤＣＰ  ＰＤＵ）はＲＬＣレイヤでロスレスが担保されるため必ず受信側に届くと考えることができる。すなわち、受信側のＰＤＣＰレイヤでは（Ｘ−１）番のＲＬＣ  ＳＤＵまでは受信パケットとして受け取るので、適切な更新契機を受けてＰＤＣＰ受信ウインドウの下端はＸ番まで更新され、同時に受信側ＰＤＣＰレイヤで認識するＰＤＣＰ  ＳＮもＸ番までインクリメントされる。その結果、図９Ｂに示す停止状態においては、送信側のＰＤＣＰレイヤで関連付けられたＰＤＣＰ  ＳＮの最新は（Ｘ＋Ｙ−１）番であり、受信側のＰＤＣＰレイヤで受信されるパケットに関連付けられるＰＤＣＰ  ＳＮの最新はＸ番である。すなわち、図９Ｂに示す停止状態においては、受信側のＰＤＣＰレイヤは、Ｘ番以降のパケットを受信できればＨＦＮ  ｄｅ−ｓｙｎｃは発生しないことになる。
【００４２】
本実施の形態では、ＰＤＣＰウインドウ管理部１３が、基準となるＸと、最大個数となるＹとを管理している。Ｘは、ＲＬＣレイヤで分割されて一部でも論理チャネルへマッピングされた最新のＲＬＣ  ＰＤＵに対応したＰＤＣＰ  ＰＤＵのＰＤＣＰ  ＳＮに１プラスした番号であるので、受信側のＰＤＣＰｅｎｔｉｔｙが管理するＰＤＣＰ受信ウインドウの下端を管理することになる。Ｙは、受信側のＰＤＣＰｅｎｔｉｔｙが管理するＰＤＣＰ受信ウインドウのサイズ（２０４８）に相当する数値とする。
【００４３】
ＰＤＣＰ処理部１２は、設定したＰＤＣＰ送信ウインドウに基づいて、ＰＤＣＰ処理部１２において処理するＰＤＣＰ  ＳＤＵの数がＰＤＣＰ送信ウインドウサイズに相当するＹ個（（Ｘ＋Ｙ−１）番）を超えないように制限する。したがって、図９Ｂに示す停止状態においてＲＬＣバッファ２１に保持されているＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）が全て破棄されたとしても、Ｘを破棄直前のＰＤＣＰ  ＳＮに再設定し、再設定したＸ番からＰＤＣＰ  ＳＮを再開することで、ＨＦＮ  ｄｅ−ｓｙｎｃが発生していない状態から“ＰＤＣＰ  ＰＤＵ化”又は“ＰＤＣＰ  ＳＮの関連付け”を再開できる。このように、ＰＤＣＰウインドウ管理部１３が管理している破棄直前のＸからＰＤＣＰ  ＳＮを開始することにより、送信側ＰＤＣＰと受信側ＰＤＣＰとでＣＯＵＮＴ値の同期を維持することができる。
【００４４】
図１０Ａに示すように、ＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔの受信を契機としてＰＤＣＰ送信ウインドウを更新する動作について説明する。送信側のＲＬＣレイヤにおいてＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）がＲＬＣ  ＰＤＵへマッピングされて無線送信されると、ＲＬＣ−ＡＭでは、受信機である受信側のＲＬＣレイヤから、受信側ＲＬＣレイヤにおけるＲＬＣ  ＰＤＵの確認応答（ＲＬＣ−ＡＣＫ／ＮＡＣＫ）であるＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔが送信される。送信側のＲＬＣレイヤにおいて、受信側ＲＬＣ処理部２３がＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔを受け取ると、通知部２５は前回の更新時から新たにＲＬＣ  ＰＤＵへマッピングしたＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）の情報（例えば、個数、ＲＬＣ-ＡＣＫ／ＮＡＣＫ、又は無線送信したパケットのＰＤＣＰ  ＳＮ／ＣＯＵＮＴ値）と共にＰＤＣＰ送信ウインドウの更新契機をＰＤＣＰウインドウ管理部１３へ通知する。図１０Ａに示す例では、Ｘ番、（Ｘ＋１）番の各ＰＤＣＰ  ＳＮに関連付けられたパケットが前回のウインドウ更新以降にＲＬＣ  ＰＤＵへマッピングされて無線送信されていて、今回のＲＬＣ  ｓｔａｔｕｓ  ｒｅｐｏｒｔでＲＬＣ−ＡＣＫがそれぞれ通知されている。ＰＤＣＰウインドウ管理部１３は、ＰＤＣＰ処理部１２に設定されるＰＤＣＰ送信ウインドウの下端Ｘを、更新前の値から２つインクリメントする（ＰＤＣＰ送信ウインドウの更新）。ＰＤＣＰ処理部１２は、ＰＤＣＰ送信ウインドウの更新に応じて、ＰＤＣＰ  ＳＮが更新後の（Ｘ＋Ｙ-１）番になるまでＰＤＣＰ  ＰＤＵを追加転送する。
【００４５】
また、ＰＤＣＰ  ｒｅ−ｅｓｔａｂｌｉｓｈｍｅｎｔが発生する場合（ハンドオーバ／再接続時）においては、Ｘには未だ受信側のＲＬＣレイヤからその一部でもＲＬＣ−ＡＣＫを受けていない最古のＰＤＣＰ  ＰＤＵのＰＤＣＰ  ＳＮ（又はＣＯＵＮＴ値）が設定される。これは、一旦生成していたＰＤＣＰ  ＰＤＵを無効とし、ＰＤＣＰ  ＳＤＵから再度ＰＤＣＰ  ＰＤＵを生成するためである。
【００４６】
次に、図１０Ｂに示すように、バッファ破棄を契機としてＰＤＣＰ送信ウインドウを更新する動作について説明する。図９Ｂに示す停止状態においてバッファ破棄が発生したとする。バッファ破棄が発生する要因は限定されないが、以下にいくつか例示する。例えば、送信側のＰＤＣＰレイヤは、以下を契機にＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）の破棄を行うことがある。１つはバッファ溢れによる破棄である。流入するデータが、搭載するレイヤ２バッファ（ＰＤＣＰバッファ１１、ＲＬＣバッファ２１）を超過する場合である。ＲＬＣレイヤが担うユーザ（ＰＤＣＰ  ＰＤＵ化が停止対象となっているベアラ、ユーザに限らない）のデータが大量にバッファリングされて破棄されてバッファ溢れが発生する場合が考えられる。また、Ｄｉｓｃａｒｄ  ｔｉｍｅｒによる破棄も考えられる。より具体的には、音声やビデオベアラのリアルタイム性を担保するために、所定期間スケジューリングされなかったデータは破棄する。図９Ｂに示す停止状態においてバッファ破棄が発生した場合、送信側のＰＤＣＰレイヤにおいてＸ番から（Ｘ＋Ｙ−１）番までのパケットが失われる。バッファ破棄が発生した場合、本実施の形態では、ＲＬＣレイヤにおいて、ＲＬＣコントローラ２４からＲＬＣバッファ２１に対してバッファ廃棄の指示が出され、ＲＬＣバッファ２１にＲＬＣ  ＰＤＵに未マッピングのまま保持されている全てのＰＤＣＰ  ＰＤＵ（ＲＬＣ  ＳＤＵ）が破棄される。図１０Ｂに示すように、通知部２５は、このバッファ破棄をＰＤＣＰウインドウ管理部１３へ通知してＰＤＣＰ送信ウインドウの更新契機を与える。ＰＤＣＰウインドウ管理部１３は、バッファ破棄の通知を受けると、ＰＤＣＰバッファ１１にコピーしておいた破棄対象となったオリジナルのＰＤＣＰ  ＳＤＵを破棄するように制御する。さらに、ＰＤＣＰウインドウ管理部１３は、ＰＤＣＰ処理部１２に設定されるＰＤＣＰ送信ウインドウの下端Ｘを、バッファ破棄直前のＸに再設定する。ＰＤＣＰ処理部１２は、再設定されたバッファ破棄直前のＸからＰＤＣＰ  ＳＮを開始して“ＰＤＣＰ  ＰＤＵ化”又は“ＰＤＣＰ  ＳＮの関連付け”を再開する。これにより、受信側のＰＤＣＰレイヤにおいて受信している最新のＰＤＣＰ  ＳＮにプラス１した数であるＸから“ＰＤＣＰ  ＰＤＵ化”又は“ＰＤＣＰ  ＳＮの関連付け”を再開するので、送信側ＰＤＣＰと受信側ＰＤＣＰとでＣＯＵＮＴ値の同期を維持することができる。
【００４７】
次に、図１１を参照してＰＤＣＰウインドウ管理部１３におけるＸの更新処理フローについて説明する。ｋは生成されるＰＤＣＰ  ＰＤＵの個数をカウントするパラメータである。初期状態においてｋ＝０として（Ｓ１）、ｋ＜Ｙであれば（Ｓ２）、（Ｘ＋Ｙ−１）番を超えないと判断してＰＤＣＰ  ＰＤＵを生成する（Ｓ３）。ＰＤＣＰ  ＰＤＵを１つ生成するとｋをインクリメントする（Ｓ４）。上記した更新契機によってＸが更新されれば（Ｓ５）、ｋを０にリセットする（Ｓ６）。処理対象のＰＤＣＰ  ＳＤＵが存在すれば（Ｓ７）、ステップＳ２へ処理が戻る。一方、ステップＳ２の判断においてｋ＜Ｙが成立しなければ、Ｙ個（（Ｘ＋Ｙ−１）番）に到達したと判断してＰＤＣＰ  ＰＤＵの生成を停止させる（Ｓ８）。
【００４８】
図１２は上位レイヤからのデータ流入によりＰＤＣＰレイヤにバッファ溢れが発生した場合のパケット破棄について説明する図である。ＰＤＣＰ  ＰＤＵ化処理が停止されている状態で（図１２Ａ）、上位レイヤからデータ流入があるとバッファ溢れが発生する（図１２Ｂ）。バッファ溢れが発生する場合には、データを破棄する必要がある。このようにＰＤＣＰレイヤにおけるデータの破棄が発生する場合、ＰＤＣＰバッファ１１内においてＰＤＣＰ  ＳＮとの関連付けが未だ行われていないＰＤＣＰ  ＳＤＵが優先的に破棄されるようにする（図１２Ｃ）。
【００４９】
上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェアおよびソフトウェアの任意の組み合わせによって実現される。各機能ブロックの実現手段は特に限定されない。各機能ブロックは、物理的に結合した１つの装置により実現されてもよいし、物理的に分離した２つ以上の装置を有線または無線で接続し、これら複数の装置により実現されてもよい。
【００５０】
たとえば、送信機（例えば、ｅＮＢ）、受信機（例えば、ＵＥ）の各機能の一部またはすべては、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＰＬＤ（Programmable  Logic  Device）、ＦＰＧＡ（Field  Programmable  Gate  Array）などのハードウェアを用いて実現されてもよい。送信機、受信機は、プロセッサ（ＣＰＵ）と、ネットワーク接続用の通信インタフェースと、メモリと、プログラムを保持したコンピュータ読み取り可能な記憶媒体と、を含むコンピュータ装置によって実現されてもよい。
【００５１】
プロセッサやメモリなどは情報を通信するためのバスで接続される。コンピュータ読み取り可能な記録媒体は、たとえば、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ、ＣＤ−ＲＯＭ、ＲＡＭ、ハードディスクなどの記憶媒体である。プログラムは、電気通信回線を介してネットワークから送信されてもよい。無線基地局１０やユーザ端末２０は、入力キーなどの入力装置や、ディスプレイなどの出力装置を含んでいてもよい。
【００５２】
送信機、受信機の機能構成は、上述のハードウェアによって実現されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実現されてもよいし、両者の組み合わせによって実現されてもよい。プロセッサは、オペレーティングシステムを動作させて装置の全体を制御する。プロセッサは、記憶媒体からプログラム、ソフトウェアモジュールやデータをメモリに読み出し、これらに従って各種の処理を実行する。当該プログラムは、上記の各実施形態で説明した各動作を、コンピュータに実行させるプログラムであればよい。
【００５３】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。例えば、上述の各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【符号の説明】
【００５４】
１１  ＰＤＣＰバッファ
１２  ＰＤＣＰ処理部
１３  ＰＤＣＰウインドウ管理部
２１  ＲＬＣ  バッファ
２２  送信側ＲＬＣ処理部
２３  受信側ＲＬＣ処理部
２４  ＲＬＣコントローラ
２５  通知部
【図１】
0006654828.tif 000002
【図２】
0006654828.tif 000003
【図３】
0006654828.tif 000004
【図４】
0006654828.tif 000005
【図５】
0006654828.tif 000006
【図６】
0006654828.tif 000007
【図７】
0006654828.tif 000008
【図８】
0006654828.tif 000009
【図９】
0006654828.tif 000010
【図１０】
0006654828.tif 000011
【図１１】
0006654828.tif 000012
【図１２】
0006654828.tif 000013
【図１３】
0006654828.tif 000014
【図１４】
0006654828.tif 000015
【図１５】
0006654828.tif 000016